19일차_컨테이너의 애플리케이션 설정 관리

18-1. 다단 어플리케이션 설정

• The Twelve-Factor App은 환경 변수에 포함된 설정값을 최우선 순위에 두는 현대적 어플리케이션 설계 스타일을 말한다. 이 방법은 컨테이너를 교체해야만 환경 변수를 수정할 수 있다.
• 우리가 다루는 설정 데이터의 종류는 버전에 따른 설정, 환경에 따른 설정, 기능에 따른 설정이다.

# 1. 볼륨 마운트로 개발 환경 설정을 주입하고, 환경변수 설정 오버라이드로 정보 수집 여부를 지정.
cd ch18/exercise/access-log

docker container run -d -p 8082:80 -v "$(pwd)/config/dev:/app/configoverride" -e NODE_CONFIG='{\"metrics\": {\"enabled\":\"true\"}}' diamol/ch18-access-log

curl http://localhost:8082/config

18-2. 환경별 설정 패키징하기

• 모든 프레임워크 환경 별 설정파일을 배포에 포함시킬 수 도 있다.
  appsetting.json 모든 환경에 공통적으로 설정
  appsettings.{env}.json 환경별 오버라이드 설정 파일
  환경 변수 환경 이름 정의 및 오버라이드 설정

# 2. 기본 설정이 아닌 테스트 환경 설정으로 실행. appsettings.Development.json파일의 설정이 오버라이드 된다.
docker container run -d -p 8084:80 -e DOTNET_ENVIRONMENT=Test diamol/ch18-todo-list

• 위 방법을 이용하면 환경 설정 파일에 대한 값을 외부에서 주입하지 않아도 되기에 안전하지만, 어차피 이미지에 포함시킬 수 없는 패스워드, API 키 등이 이미지에 유출되게 된다.
• 환경 변수 값은 모든 설정 파일에 우선된다(docker run 인자)

18-3. 런타임에서 설정 읽어 들이기

• Go 언어에서는 설정모듈 Viper를 이용해 오버라이드 파일을 읽을 설정 디렉터리를 지정시켜 적용한다.
• GO 언어는 JSON, YAML외에도 TOML을 이용하여 편리하고 가독성이 좋다.

# 3. Go lang TOML 설정 파일(config.toml)
release="19.12"
environment="UNKNOWN"

[metrics]
enabled=true

[apis]
	[apis.image]
    url="http://iotd/image"
    
    [apis.access]
    url="http://accesslog/access-log"

• 설정 API는 현재 설정 내용이 담긴 JSON문자열을 반환하는데, 이 때 민감 정보가 노출될 수 있기에 아래를 따른다.
  설정 전체를 공개하는 것이 아닌, 민감하지 않은 정보만 선택하여 반환시킨다.
  엔드포인트에 보안을 설정하여 허가받은 사용자만 접근 가능케한다.
  설정 API 사용 여부를 on off 할 수 있게 한다.
• Viper 설정에 사용되는 환경 변수의 이름을 지을 때, 다른 환경 변수와의 충돌을 피하기 위해 ID를 붙여 아래와 같이 사용한다.

# 4. 환경 변수를 이용해 GO설정 오버라이드를 적용하여 컨테이너 실행
docker container run -d -p 8088:80 =v "$(pwd)/config/dev:/app/configoverride" -e IG_METRICS.ENABLED=TRUE diamol/ch18-image-gallery

18-4. 레거시 애플리케이션에 설정 전략 적용하기

• 윈도의 닷넷 어플리케이션과 같은 레거시(기존에 개발되어 오래된 코드) 어플리이션은 환경 변수나 설정 파일 병합을 통한 일반적인 설정 구성을 지원하지 않고 특정 경로에 위치한 XML만을 설정 파일로 사용한다.
• 이런 경우 컨테이너에 주입된 설정 파일을 어플리케이션 설정 전략에 맞추어 변환하는 유틸리티나 스크립트를 이미지에 포함시켜야 한다. 다만 컨테이너 시작과 어플리케이션 사이 시간 간격이 생기기에 헬스 체크를 통해 오류에 대처 가능해야한다.

# 5. 설정 변환 유틸리티의 빌드 및 실행 스크립트. 대충 condifLoader를 만들고 이를 먼저 실행시킨 뒤 어플리케이션 실행
FROM diamol/maven AS builder
# ...
RUN mvn package

# 설정 변환 유틸리티
FROM diamol/maven as utility-builder
WORKDIR /usr/src/utilities
COPY ./src/utlities/ConfigLoader.java .
RUN javac ConfigLoader.java

# 애플리케이션
FROM diamol/openjdk
ENV CONFIG_SOURCE-PATH="" \
	CONFIG_TARGET_PATH="/app/config/application/peoperties"

CMD java ConfigLoader && \
	java -jar /app/iotd-service-0.1.0.jar
    
WORKDIR /app
COPY --from=utility-builder /usr/src/utilities/ConfigLoader.class .
COPY --from=builder /usr/src/iotd-services-0.1.0.jar .

# 6. 오버라이드 설정 파일과 환경 변수 설정을 적용해 컨테이너 실행
docker run -d -p 8091:80 -v "$(pwd)/config/dev:/config-override" \
	-e CONFIG_SOURCE_PATH="/config-override/application.peoperties" \
    -e IOTD_ENVIRONMENT="custom" diamol/ch18-image-of-the-day

• 위와 같이 유틸리티를 사용한 설정 파일을 레거시 애플리케이션에 그대로 적용시켜 사용자는 환경 변수 설정과 오버라이드 설정 파일을 볼륨을 통해 주입하기만 하면 된다.
• 현재 잠시 점검하면, 컨테이너를 실행하며 환경 변수 전달하는 방식을 주로 사용해왔는데 실제로 이 값만 지정해준다고 해서 모든 환경에서 항상 작동하는 것은 아니다. 이 때는 문서화를 시켜 애플리케이션 플랫폼의 동작이 서로 다르기에 회색지대가 존재한다는 것을 전달하는 것이 중요하다. 컴포즈 파일에 환경 별 설정 파일에 일괄적으로 작성이 되어있는지 잘 검토하자.

18-5. 유연한 설정 모델의 이점

• 현재까지 단일 이미지 원칙을 유지하기 위해 환경마다 조금씩 다르게 설정해왔다.
• 실무에서는 버전에 따라 달라지는 설정은 이미지에, 환경별 설정은 컨테이너 플랫폼 오버라이드에, 환경변수는 기능별 설정을 추가한다.