도커 교과서 18장 컨테이너의 애플리케이션 설정 관리

18장 컨테이너의 애플리케이션 설정 관리

18.1 다단 애플리케이션 설정

설정 데이터 종류는 세 가지다.

• 버전에 따라 달리지는 설정
  • 모든 환경에서 동일하지만 버전별로 달라지는 설정
• 환경에 따라 달라지는 설정
• 기능 설정
  • 버전별로 애플리케이션의 동작을 달리하기 위한 설정

애플리케이션에 설정 주입하기

• 버전에 따라 달라지는 설정값은 이미지의 기본 설정에 포함시킨다.
• 환경별로 달라지는 설정값은 컨테이너 파일 시스템에 주입되는 오버라이드 파일에 넣는다.
• 기능 설정은 환경 변수 형태로 다룬다.

$ docker container run -d -p 8080:80 diamol/ch18-access-log

$ docker container run -d -p 8081:80 -v "$(pwd)/config/dev:/app/config-override" diamol/ch18-access-log

• 미리 정의된 경로에서 오버라이드 설정 파일을 읽어 들이도록 해두면, 어떤 경로로든 컨테이너 파일 시스템에 설정 파일을 주입하기만 하면 해당 설정을 적용할 수 있다.
• 이런 설정은 개발자의 워크플로를 부드럽게 유지할 수 있는 좋은 사례다.

18.2 환경별 설정 패키징하기

• 애플리케이션 프레임워크에서 환경별 설정 파일을 모두 배포에 포함시킬 수 있는 기능을 제공한다.
• 해당 기능을 통해 환경 이름 선택만으로 해당 환경 설정을 적용할 수 있다.

appsettings.json: 모든 환경 공통
appsettings.{ENV}.json: 환경별 오버라이드 설정

$ docker container run -d -p 8083:80 diamol/ch18-todo-list

$ docker container run -d -p 8084:80 -e DOTNET_ENVIRONMENT=test diamol/ch18-todo-list

만약, 설정 파일과 소스 코드를 별돌의 시스템으로 관리한다면

• CI/CD 파이프라인에서 설정 파일을 소스 코드로 가져와 이미지를 빌드하는 방법으로 개발과 설정 관리를 분리할 수 있다.
• 그러나, 이미지에 포함시킬 수 없는 민감정보 때문에 외부에서 컨테이너에 주입해야 되는 데이터가 존재한다.
• 레지스트리는 항상 외부에 노출될 위험이 있다고 생각하고 보안에 신경써야 한다.

18.3 런타임에서 설정 읽어 들이기

Go 언어의 Viper

• Go 언어에서는 Viper 라는 설정 모듈이 주로 사용된다.
• 패키지 목록에 바이퍼를 추가하고, 코드에서 오버라이드 파일을 읽어 올 설정 디렉토리를 지정하기만 하면 된다.
• 이미지에 포함된 config 디렉터리에서 기본 설정 파일을 읽고, 환경별 설정 파일은 config-override 디렉터리에서 읽어 들인다.
• 해당 config-override 는 파일 시스템 마운트로 외부에서 주입된다.

TOML

Viper 에서는 TOML 이라는 형식을 사용한다

• 구조가 간결하기 때문에 개발자가 설정을 이해하고 수정하기 쉽다.
• 명확한 데이터 타입 시스템을 제공한다.
• 계층형 구조로 복잡한 데이터를 표시하기 좋다.

release = "19.12"
environment = "UNKNOWN"

[metrics]
enabled = true

[apis]

[api.image]
url = "<http://iotd/inmage>"

[api.access]
url = "<http://accesslog/access-log>"

설정값을 반환하는 API 설계 시 주의사항

• 전체 설정을 공개하지 않는다.
• 민감한 정보는 절대 포함시키지 않는다.
• 허가받은 사용자만이 접근할 수 있도록 엔드포인트 보안을 설정한다.
• 설정 API의 사용 여부를 설정할 수 있도록 한다.

궁긍한점.

• 설정 API 는 단 한번도 만들어본적이 없다. 언제 어떤 이유로 만들어서 사용하는거지?
• 애플리케이션 버전 ( 0.5.2 와 같은) 정보도 설정 API 인가?
• 그렇다면, 해당 버전 정보는 사용자에게 공개되면 안되는지?

18.4 레거시 애플리케이션에 설정 전략 적용하기

• 레거시 애플리케이션은 환경 변수나 설정 파일 병합을 통한 설정 구성은 일반적으로 지원하지 않는다.
• 레거시 애플리케이션은 특정 경로에 위치한 XML 파일을 설정 파일을 주로 사용한다.
• 루트 디렉토리 외부에 위치한 설정 파일이나 환경 변수의 값을 설정에 도입할수는 없다.
• 이를 컨테이너에 주입된 설정 파일을 애플리케이션의 설정 전력에 맞춰 변환하는 유티리티 또는 스크립트를 이미지에 포함시켜 해결할 수 있다.

A. 컨테이너에 지정된 오버라이드 파일을 읽어 들이기.

B. 환경 변수에서 오버라이드 설정을 읽어 들이기.

C. 오버라이드 설정 파일과 환경 변수 설정을 병합하기. 이떄, 환경 변수 갓이 우선.

D. 병합된 오버라이드 설정을 컨테이너 내 대상 설정 파일에 추가.

$ docker container run -d -p 8090:80 -v "$(pwd)/config/dev:/config-override" -e CONFIG_SOURCE_PATH="/config-override/application.properties" diamol/ch18-image-of-the-day

Java 설정 변환 유틸리티의 빌드 및 실행

FROM diamol/maven AS builder
RUN mvn package

FROM diamol/maven as utility-builder
WORKDIR /usr/src/utilities
COPY ./src/utilities/ConfigLoader.java .
RUN javac ConfigLoader.java

FROM diamol/openjdk
ENV CONFIG_SOURCE_PATH="" \\
	CONFIG_TARGET_PATH="7app/config/application.properties"

CMD java ConfigLoader && \\
	java -jar /app/iotd-service-0.1.0.jar

WORKDIR /app
COPY --from=utility-builder /usr/src/utilities/ConfigLoader.java
COPY -from=builder /usr/src/iotd/target/iotd-service-0.1.0.jar

• 도커 이미지를 확장해 기존 애플리케이션에 현대적 설정 모델을 도입할 수 있다.
• 애플리케이션 시작 로직을 수정해 실제 애플리케이션이 실행되기 전에 원하는 작업을 수행할 수 있다.
• 다만, 해당 작업으로 인해 컨테이너 시작과 애플리케이션 실행 사이에 시간 간격이 생기며, 컨테이너가 실패할 확률도 높아진다.
• 따라서, 더욱 헬스 체크에 신경을 써야 한다.

18.5 유연한 설정 모델의 이점

• 계층별 설정 모델은 애플리케이션 동작 환경마다 조금씩 다르게 하면서도 단일 이미지 원칙을 유지할 수 있게 해준다.
• 버전에 따라 달라지는 설정은 이미지 포함.
• 환경별로 달라지는 설정은 컨테이너 플랫폼에서 제공하는 오버라이드 파일을 통해 적용.
• 환경 변수를 통해 통제하는 기능별 설정 추가.
• 이를 통해 운영 환경과 유사항 환경 재현이 가능하여 운영 환경 이슈 대응이 쉬워진다.