다양한 스테이징 환경에서 Java 웹앱을 어떻게 유지합니까?
https://stackoverflow.com/questions/93944
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
개발자 컴퓨터에서 사용되는 속성 집합이 있을 수 있습니다. 이 속성 집합은 개발자마다 다르며 스테이징 환경에 대한 속성 집합과 프로덕션 환경에 대한 속성 집합도 있습니다.
Spring 애플리케이션에는 프로덕션 환경이 아닌 로컬 환경에 로드하려는 Bean이 있을 수도 있으며 그 반대의 경우도 마찬가지입니다.
이것을 어떻게 처리합니까?별도의 파일, ant/maven 리소스 필터링 또는 기타 접근 방식을 사용합니까?
해결책
저는 JNDI에 다양한 속성을 넣었습니다.이렇게 하면 각 서버를 구성할 수 있고 하나의 war 파일을 가질 수 있습니다.속성 목록이 크면 다른 서버에서 속성(또는 XML) 파일을 호스팅하겠습니다.JNDI를 사용하여 사용할 파일의 URL을 지정하겠습니다.
각 환경에 대해 서로 다른 앱 파일(war/ear)을 생성하는 경우 테스트 중인 동일한 war/ear를 배포하지 않는 것입니다.
내 앱 중 하나에서는 여러 REST 서비스를 사용합니다.JNDI에 루트 URL을 넣었습니다.그런 다음 각 환경에서 해당 환경에 적합한 REST 서비스와 통신하도록 서버를 구성할 수 있습니다.
다른 팁
저는 단지 각 머신마다 서로 다른 Spring XML 구성 파일을 사용하고, 머신마다 달라지는 모든 구성 데이터가 해당 Spring 구성 파일에서 로드되는 Bean에 의해 참조되는지 확인합니다.
예를 들어, 다른 앱의 Java RMI 인터페이스에 연결하는 웹앱이 있습니다.내 앱은 Spring XML 구성 파일에 구성된 Bean을 통해 다른 앱의 RMI 인터페이스 주소를 가져옵니다.내 앱과 다른 앱에는 모두 개발, 테스트 및 프로덕션 인스턴스가 있으므로 내 앱에 대한 세 가지 구성 파일이 있습니다. 하나는 프로덕션 인스턴스에 적합한 구성에 해당하고, 하나는 테스트 인스턴스에, 다른 하나는 개발에 해당합니다. 사례.
그런 다음 내가 정확히 알아야 할 유일한 것은 어떤 구성 파일이 어떤 시스템에 배포되는지입니다.지금까지 WAR 파일을 생성하기 전에 올바른 구성 파일을 제자리에 복사하는 Ant 작업을 생성하는 전략에 문제가 없었습니다.따라서 위의 예에는 세 가지 Ant 작업이 있습니다. 하나는 프로덕션 WAR을 생성하고, 하나는 개발 WAR을 생성하고, 다른 하나는 테스트 WAR을 생성합니다.세 가지 작업 모두 올바른 구성 파일을 올바른 위치에 복사한 후 앱을 컴파일하고 WAR을 생성하는 동일한 다음 단계를 호출합니다.
이것이 의미가 있기를 바랍니다 ...
우리는 환경에 특정한 속성 파일을 사용하고 jar/war을 빌드할 때 개미 빌드가 올바른 세트를 선택하도록 합니다.
환경별 사항은 앱 서버에 따라 디렉터리 서비스(JNDI)를 통해 처리될 수도 있습니다.우리는 Tomcat을 사용하고 DataSource는 Tomcat의 읽기 전용 JNDI 구현에 정의되어 있습니다.Spring은 조회를 매우 쉽게 만듭니다.
또한 동일한 소스 프로젝트에서 다양한 사이트(다른 콘텐츠, 보안 역할 등)를 구축하기 위해 Ant 전략을 사용합니다.
이 빌드 전략에 약간의 문제를 일으키는 한 가지가 있는데, 그것은 빌드가 실행될 때까지 파일과 디렉터리가 존재하지 않는 경우가 많기 때문에 진정한 통합 테스트를 작성하기 어렵게 만들 수 있다는 것입니다(동일한 스프링 세트 사용). IDE 내에서 실행할 수 있습니다.또한 파일 존재 등을 확인하는 IDE의 기능 중 일부를 놓치게 됩니다.
저는 Maven을 사용하여 프로젝트의 src/main/resources 아래에 있는 리소스를 필터링합니다.저는 이것을 속성 파일과 함께 사용하여 Spring 기반 프로젝트에서 사용자 정의된 속성을 가져옵니다.
기본 빌드의 경우 Maven이 재정의로 사용하는 홈 디렉터리에 속성 파일이 있습니다(따라서 로컬 Tomcat 설치와 같은 항목을 올바르게 찾을 수 있음).테스트 서버와 프로덕션 서버는 나의 다른 프로필입니다.간단한 -Pproduction 프로덕션 서버용 애플리케이션을 구축하는 데 필요한 전부입니다.
다른 속성 파일을 사용하고 빌드가 완료된 환경에 따라 교체를 수행하는 개미 교체 필터를 사용하십시오.보다 http://www.devrecipes.com/2009/08/14/environment-특이적-configuration-for-java-applications/
소스 제어 저장소에 저장되고 수동으로 업데이트되는 별도의 구성 파일입니다.일반적으로 구성은 한 버전과 다음 버전 사이에서 근본적으로 변경되지 않으므로 동기화(수작업으로도)는 실제로 큰 문제가 되지 않습니다.
프로덕션 환경에서 확장성이 뛰어난 시스템의 경우 진지하게 구성 파일이 템플릿에 보관되는 방식을 권장하고, 빌드 스크립트의 일부로 이러한 템플릿을 사용하여 "최종" 구성 파일을 렌더링합니다(모든 환경은 동일한 프로세스를 사용해야 함).
최근에는 라이브 또는 스테이징 환경을 위한 대체 구성에도 Maven을 사용했습니다. Maven 프로필을 사용한 프로덕션 구성.도움이 되길 바랍니다.
나는 Ant의 사본을 필터 파일과 함께 사용합니다.변수가 있는 구성 파일이 있는 디렉터리에는 각 환경에 대한 파일이 있는 디렉터리가 있습니다.빌드 스크립트는 환경을 알고 올바른 변수 파일을 사용합니다.
대상 배포에 대한 구성을 보관하는 다양한 구성 폴더가 있으며 ANT를 사용하여 파일 복사 단계에서 사용할 폴더를 선택합니다.
우리는 다양한 환경에 대해 다양한 개미 대상을 사용합니다.우리가 하는 방식은 약간 우아하지 않을 수도 있지만 작동합니다.우리는 특정 개미 대상에게 다양한 리소스 파일을 필터링하고(특정 빈이 로드되지 않도록 제외하는 방법), 다양한 데이터베이스 속성을 로드하고, 다양한 시드 데이터를 데이터베이스에 로드하도록 지시할 것입니다.우리에게는 실제로 개미 '전문가'가 없지만 단일 명령으로 다양한 구성으로 빌드를 실행할 수 있습니다.
제가 본 솔루션 중 하나는 프로덕션 환경과 동일하도록 스테이징 환경을 구성하는 것입니다.이는 각 환경에 동일한 IP 범위를 갖는 VLAN과 동일한 IP 주소에 대한 머신 역할이 있음을 의미합니다(예:db 클러스터 IP는 각 환경에서 항상 192.168.1.101입니다.방화벽은 외부 주소를 웹 서버에 매핑하므로 PC의 호스트 파일을 교환하여 동일한 URL을 사용할 수 있습니다. http://www.myapp.com/webapp/file.jsp 교체한 호스트 파일에 따라 스테이징 또는 프로덕션으로 이동합니다.
이것이 이상적인 솔루션인지는 확실하지 않습니다. 유지 관리가 꽤 까다롭지만 주목할만한 흥미로운 솔루션입니다.
Caleb P와 JeeBee가 아마도 가장 빠른 솔루션을 갖고 있을 것입니다.또한 다른 서비스를 설정하거나 다른 시스템의 파일을 가리킬 필요가 없습니다.${user.name} 변수를 사용하거나 Ant 또는 Maven에 대한 -D 인수에 프로필을 지정하여 환경을 지정할 수 있습니다.
또한 이 설정에서는 일반 속성 파일과 특정 환경에 대한 재정의 속성 파일을 가질 수 있습니다.Ant와 Maven 모두 이러한 기능을 지원합니다.
PropertyPlaceholderConfigurer를 조사하는 것을 잊지 마십시오. 이는 JNDI를 사용할 수 없는 환경에서 특히 유용합니다.
