응용 프로그램은 일반적으로 환경 변수와 디스크에서 읽은 파일의 조합인 실행 중인 환경에서 구성을 로드해야 합니다. Docker는 컨테이너에서 실행되는 앱을 위한 환경을 만들고 환경 변수를 설정하고 다양한 소스에서 파일 시스템을 구성할 수 있습니다. 앱에 대한 유연한 구성 접근 방식을 구축하는 데 도움이 되는 모든 요소가 있으므로 프로덕션에 배포할 때 모든 테스트 단계를 통과한 동일한 이미지를 사용하게 됩니다. 여러 위치의 구성 값을 병합하도록 앱을 설정하고 조각을 하나로 모으기 위해 몇 가지 작업을 수행하기만 하면 됩니다.
이 장에서는 .NET Core, Java, Go 및 Node.js의 예제를 사용하여 권장되는 접근 방식(및 일부 대안)을 안내합니다. 여기에서 일부 작업은 구성 관리를 제공하기 위해 라이브러리를 가져오는 개발자 공간에 있으며 나머지는 통신에 의존하는 개발 및 운영 사이의 회색 영역에 있으므로 양측이 구성 모델의 작동 방식을 알 수 있습니다.
18.1 앱 구성에 대한 다계층 접근 방식
구성 모델은 일반적으로 세 가지 유형 중 하나인 저장 중인 데이터의 구조를 반영해야 합니다.
- 주어진 릴리스의 모든 환경에 대해 동일한 릴리스 수준 설정
- 환경마다 다른 환경 수준 설정
- 릴리스 간 동작을 변경하는 데 사용할 수 있는 기능 수준 설정
그 중 일부는 상당히 정적이고 일부는 알려진 변수 집합과 함께 동적이며 다른 일부는 알려지지 않은 변수 집합과 함께 동적입니다. 그림 18.1은 몇 가지 샘플 구성 설정과 환경에서 읽을 수 있는 위치를 보여줍니다.
그림 18.1 이미지, 파일 시스템 및 환경 변수의 설정이 있는 구성 계층
첫 번째 예제는 node-config라는 인기 있는 구성 관리 라이브러리가 있는 Node.js입니다. 라이브러리를 사용하면 계층의 여러 파일 위치에서 구성을 읽고 환경 변수로 모두 재정의할 수 있습니다. 이 장의 연습에서 액세스 로그 샘플 앱은 node-config 라이브러리를 사용하고 구성 파일을 읽을 두 개의 디렉토리를 설정합니다.
config-- 이것은 Docker 이미지의 기본 설정으로 패키징됩니다.config-override-- 이미지에는 없지만 볼륨, 구성 개체 또는 비밀에서 컨테이너 파일 시스템에 프로비저닝할 수 있습니다.
TRY 이미지의 기본 구성으로 샘플 앱을 실행한 다음 개발 환경에 대한 재정의 파일이 있는 동일한 이미지를 실행합니다.
- run a container with the default config in the image:
docker container run -d -p 8080:80 diamol/ch18-access-log- run a container loading a local config file override:
docker container run -d -p 8081:80 -v "$(pwd)/config/dev:/app/config-override" diamol/ch18-access-log- check the config APIs in each container:
curl http://localhost:8080/config
curl http://localhost:8081/config18.5 유연한 구성 모델이 효과가 있는 이유
11장과 15장에서 Docker를 사용하여 CI/CD 파이프라인을 다루었으며 해당 파이프라인의 핵심 설계는 하나의 이미지를 빌드하고 배포 프로세스는 환경을 통해 해당 이미지를 프로덕션으로 승격하는 것입니다. 앱은 각 환경에서 약간 다르게 작동해야 하며 단일 이미지 접근 방식을 유지하면서 이를 지원하는 방법은 다중 계층 구성 모델을 사용하는 것입니다.
실제로는 거의 모든 경우에 컨테이너 플랫폼에서 제공하는 환경 수준 재정의 파일과 함께 컨테이너 이미지에 빌드된 릴리스 수준 설정을 사용하지만 환경 변수로 기능 수준 구성을 설정하는 기능은 유용한 추가 기능입니다. . 이는 프로덕션 문제에 신속하게 대응할 수 있음을 의미합니다. 성능 문제인 경우 로깅 수준을 낮추거나 보안 허점이 있는 기능을 끌 수 있습니다. 또한 개발 시스템에서 프로덕션과 유사한 환경을 만들어 버그를 복제하고, 비밀이 제거된 프로덕션 구성 재정의를 사용하고, 대신 환경 변수를 사용할 수 있음을 의미합니다.
모든 환경에서 정확히 동일한 이미지를 실행할 수 있는 능력은 구성 모델에 시간을 투자한 것에 대한 보상입니다. 그림 18.13은 CI/CD 파이프라인 이후의 이미지 수명 주기를 보여줍니다.
그림 18.13 CI/CD 파이프라인은 하나의 이미지를 생성하고 구성 모델을 사용하여 동작을 변경합니다.
이 유연한 구성 모델을 생성하는 과정에서 수행하는 작업은 앱의 미래 경쟁력을 확보하는 데 큰 도움이 될 것입니다. 모든 컨테이너 런타임은 구성 개체 또는 비밀에서 컨테이너로 파일을 로드하고 환경 변수를 설정하는 것을 지원합니다. 이 장의 이미지 갤러리 앱에 대한 Docker 이미지는 Docker Compose, Docker Swarm 또는 Kubernetes와 동일한 방식으로 작동합니다. 그리고 컨테이너 런타임만이 아닙니다. 표준 구성 파일과 환경 변수는 PAAS(Platform-as-a-Service) 제품과 서버리스 기능에서도 사용되는 모델입니다.
18.6 연구실
새 앱의 구성 모델을 자세히 살펴보고 재정의 파일을 설정하고 기능 재정의를 구성하는 방법을 알아내는 것은 까다로울 수 있으므로 이 실습에서 몇 가지 연습을 하게 될 것입니다. 동일한 이미지 갤러리 앱을 사용할 것입니다. 이 장의 실습 폴더에는 앱 구성 요소가 지정되었지만 구성이 없는 Docker Compose 파일이 있습니다. 당신의 임무는 모든 구성 요소를 다음과 같이 설정하는 것입니다.
- 볼륨을 사용하여 구성 재정의 파일을 로드합니다.
- 테스트 환경에 대한 구성 재정의를 로드합니다.
- 릴리스 주기를 "19.12" 대신 "20.01"로 재정의합니다.
이것은 매우 간단해야 하지만 앱을 변경하지 않고 앱 구성을 조정하는 데 시간을 할애하는 것이 유용할 것입니다. docker-compose up 으로 앱을 실행할 때 http://localhost:8010으로 이동할 수 있어야 하며 앱이 작동해야 합니다. 그리고 세 가지 구성 API를 모두 탐색하고 릴리스 이름이 20.01이고 환경이 TEST임을 확인할 수 있어야 합니다.
