애플리케이션 구성을 어디에 두어야합니까?


17

최근에 " 환경에 의존하는 속성은 어디에 저장해야합니까? " 대한 토론을 읽었습니다 .

고전적인 방법은 환경에 따라 여러 개의 특성 파일을 보유하고 환경 변수 (DEV, PROD ...)를 기반으로 애플리케이션을 시작할 때 (스프링 프로파일과 같이) 파일을 읽을 위치를 선택하는 것입니다.

반면에 컨테이너를 사용하여 응용 프로그램을 배포하는 경우 이러한 종류의 구성은 환경 자체에서 가져와야하며 (응용 프로그램이 읽는 환경 변수를 사용하여) 이미지가 환경간에 변경되지 않습니다.

각 접근법의 장단점은 무엇입니까? 컨테이너 시나리오에 대한 "최상의"접근 방식이 있습니까?


환경 변수를 기반으로 파일을 선택하는 것이 환경 변수를 사용하지 않아 이미지가 변경되지 않는다고 생각하는 이유는 무엇입니까? (주된 단점은 dev 및 qa 컨테이너에 prod 자격 증명을 다른 것보다 많이
남기는

답변:


6

상호 배타적 인 속성 파일과 환경 변수는 누가 말했습니까?

" 앱 구성을 어디에 저장 합니까?" 사이에는 차이점이 있습니다. 그리고 "앱 소스 는 어디 에서 구성합니까?"

가장 가능성이 높은 결과는 모든 사람 이 구성 파일을 사용하여 수행하는 작업을 스토리지 메커니즘 으로 유지 해야한다는 것입니다 (환경이 존재하는 한 장기적이고 지속적인 상태를 생각하십시오).

그러나 해당 구성 파일을 응용 프로그램 컨텍스트로 가져 와서 응용 프로그램을 실행시키지 않고 시작시 환경에서 해당 변수를 이미 사용할 수있을 것으로 기대할 수 있습니다.

따라서 두 가지 배포 작업 흐름이 필요합니다.

  1. X 변경 제어 프로세스를 수행하고 Z 도구로 Y 검토를 수행하여 환경에 응용 프로그램을 배포 할 수 있습니다.
  2. A 변경 제어 프로세스를 수행하고 C 도구, 동일한 프로세스, 다른 결과로 B 검토를 수행하여 환경 구성을 환경에 배치합니다.

consul과 같은 도구에서 환경 변수를 키 값 쌍으로 관리하는 예를 사용하려면 git에 구성 파일을 저장하는 경우 git2consul과 같은 도구를 사용하여 업데이트 될 때 해당 구성을 환경으로 가져옵니다.

구성 파일로 사용 가능한 구성이있을 것으로 예상되는 앱이있는 경우 컨설테이션 템플릿과 같은 배포 프로세스를 구축하여 앱을 구성 할 수있는 구성 파일의 여러 복사본을 앱과 함께 제공하지 않아도됩니다. 영사 값을 파일로 다시 보냅니다.


0

 우리가하는 방법은 실행중인 모든 응용 프로그램마다 3 개의 조각 (또는 아티팩트)이 있습니다.

  1. 우리가 개발중인 응용 프로그램. 환경에 관계없이 동일합니다. 귀하의 예와 일치하게, 그것은 단지 jar / war로서 Spring 어플리케이션이 될 것입니다.
  2. 응용 프로그램을 실행할 컨테이너입니다. 환경에 관계없이 동일합니다. Spring Boot를 사용하는 경우 더 이상 Tomcat이 필요 없으며 Java 런타임 만 필요합니다. 따라서 openjdk Docker 컨테이너를 사용하십시오.
  3. 응용 프로그램에 필요한 구성입니다. 이것은 환경마다 다른 유일한 것입니다. Spring 앱에서는 속성 파일을 사용하고있을 것입니다.

구성 파일은 별도의 소스 제어에 있습니다. 이전에는 Git 이었지만 http://www.configapp.com 에서 Config라는 SaaS를 사용하고 있습니다. 구성의 핵심 기능은 환경 별 구성을 쉽게 처리하는 것입니다. 새 서버에서 애플리케이션을 실행하기 위해 Docker 컨테이너, 애플리케이션 아티팩트 및 해당 환경의 구성 파일을 가져옵니다. 컨테이너에서 컨테이너 실행의 일부로 응용 프로그램 및 구성 파일이 저장된 디렉토리를 마운트합니다. 우리의 응용 프로그램은 동일합니다. 컨테이너 / 이미지는 동일합니다. 구성 파일 만 다릅니다.

구성 파일 대 환경 변수와 관련하여. 가장 오랫동안 구성 파일을 사용하고있었습니다. PaaS / 클라우드를 사용할 때는 환경 변수를 사용했습니다. 구성이 많으면 추가 작업이 완료되었으므로 환경 변수를 사용하여 올바른 구성 파일을 결정했습니다. 속성을 환경 변수로 바꾸는 응용 프로그램이 하나 있지만 비정형입니다. 회사에서 중앙 집중식 구성 서버를 승인 한 경우에는이를 사용하고, 그렇지 않으면 구성 파일의 단순성을 좋아합니다.

요약하자면 app.jar, app.properties, openjdk Docker를 가져옵니다. 그런 다음 app.jar 및 app.properties의 위치를 ​​마운트하는 openjdk Docker를 실행합니다. 유일한 환경은 app.properties입니다. 속성 키, 환경, 클러스터 / 지역 인스턴스 수에 관계없이 app.properties를 쉽게 관리하기 위해 Config를 사용합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.