13.2.컨피그 객체를 이용한 설정값 관리

도커 컨피그(config) * 스웜에서는 운영 환경에서 애플리케이션에 설정값를 제공하기 위해 클러스터에 저장되는 도커 컨피그(config) 객체를 사용한다. * 컨피그 객체는 컨테이너가 설정값을 클러스터에서 읽어올 수 있게 해 주는 강력한 기능을 가진 리소스이자 애플리케이션 배포와 설정 관리를 분리해 주는 역할도 한다. * 기존 설정 파일에서 컨피그 객체를 생성해 클러스터에 로드시키면 된다.

실습 to-do 애플리케이션은 설정값을 JSON 파일로 전달한다. 이미지에 패키징된 기본 설정값에는 데이터 저장을 위해 로컬 데이터베이스 파일을 사용하도록 돼 있으나, 애플리케이션을 실행하는 레플리카의 수가 많아지면 각기 데이터베이스 파일을 따로 갖기 때문에 사용자마다 제각기 다른 할 일 목록을 보게 될 것이므로 이를 사용할 수 없다. 이 문제를 해결하기 위해 우선 클러스터에 새로운 설정 파일을 배포한다.

  • 객체의 이름과 설정값이 담긴 파일 경로를 지정하면 컨피그 객체를 만들 수 있다.
  • 이 애플리케이션은 JSON 포맷을 사용하지만, 컨피그 객체는 JSON 외에도 XML, 키-값 쌍, 바이너리 파일까지 다양한 데이터 포맷을 담을 수 있다.
  • 컨피그 객체는 스웜에 의해 컨테이너 파일 시스템 내의 파일로서 전달된다.
001) ➜ cd ch13/exercises
002) 
003) # 로컬에 위치한 JSON 파일로 컨피그 객체를 만든다.
004) ➜ docker config create todo-list-config ./todo-list/configs/config.json 
005) amtdj9w5qydn8658ni8vll7sj
006) 
007) # 컨피그 객체의 설정값을 확인한다.
008) ➜ docker config ls
009) ID                          NAME               CREATED         UPDATED
010) amtdj9w5qydn8658ni8vll7sj   todo-list-config   9 seconds ago   9 seconds ago
  1. 004: 스웜에 로컬 설정 파일의 내용을 담은 컨피그 객체를 생성한다.

  2. 010: 컨피그 객체의 목록에는 식별자, 이름, 객체 생성 후 경과 시간 등이 함께 표시된다.

  3. 컨피그 객체는 다른 도커 리소스와 사용 방법이 같다.

  4. 명령행 도구로 생성, 삭제, 확인이 모두 가능하며, 컨피그 객체를 확인하면 설정 파일의 내용을 그대로 볼 수 있기 때문에 특히 유용하다.
  5. 이 점이 의미하는 바가 상당히 큰데, 컨피그 객체는 민감한 데이터를 보관하기 위한 수단이 아니라는 점이다.
  6. 스웜 데이터베이스에서도 이 파일 내용은 암호화 되지 않으며, 매니저 노드에서 레플리카를 실행할 노드로 전송할 때도 마찬가지다.

실습 컨피그 객체를 확인하면 객체의 내용을 모두 볼 수 있다. 이 내용은 컨피그 객체를 사용하는 컨테이너 파일 시스템에 전달될 파일의 내용과 동일하다.

001) # 컨피그 객체 확인 시 pretty 플래그를 사용하면 객체의 내용을 볼 수 있다
002) ➜ docker config inspect --pretty todo-list-config
003) ID:                     amtdj9w5qydn8658ni8vll7sj
004) Name:                   todo-list-config
005) Created at:             2023-07-22 05:44:25.174569919 +0000 utc
006) Updated at:             2023-07-22 05:44:25.174569919 +0000 utc
007) Data:
008) {
009)   "Logging": {
010)     "LogLevel": {
011)       "Default": "Information",
012)       "Microsoft": "Warning",
013)       "Microsoft.Hosting.Lifetime": "Warning"
014)     }
015)   },
016)   "AllowedHosts": "*",
017)   "Database": {
018)     "Provider": "Postgres"
019)   }
020) }
  1. 002: 스웜 매니저 노드에 접근할 수 있다면 컨피그 객체의 내용을 모두 볼 수 있다.
  2. 008~020: 이 내용은 컨피그 객체를 생성하기 위해 업로드한 파일의 전체 내용이다. 컨테이너 파일 시스템에 로드되는 데이터와 내용이 동일하다.

예제 13-3 컨피그 객체는 컨테이너 파일 시스템을 통해 서비스에 전달된다.

001) services:
002)   todo-web:
003)     image: diamol/ch06-todo-list
004)     ports:
005)       - 8080:80
006)     configs:
007)       - source: todo-list-config
008)         target: /app/config/config.json
009) 
010) # ...
011) 
012) configs:
013)   todo-list-config:
014)     external: true
  1. 012~014: 컨피그 객체 자체를 정의한 것

  2. 014: external 플래그는 해당 리소스가 이미 클러스터에 저장돼 있음을 의미한다.

  3. 이 서비스의 레플리카가 될 컨테이너의 실행과 함께 컨피그 객체의 내용이 컨테이너 파일 시스템의 /app/config/config.json 파일로 옮겨진다.

  4. 이 파일은 애플리케이션이 설정값을 읽는 경로 중 하나다.
  5. 배포 워크플로는 컨피그 객체를 먼저 배포하고 그다음에 애플리케이션을 배포하도록 돼 있다.
  6. v3 컴포즈 파일을 배포하면, SQL 데이터베이스 서비스의 정의가 포함돼 있으므로 웹 컨테이너를 여러 개 생성해도 이들 모두가 같은 데이터를 공유하게 할 수 있다.

실습 YAML 파일을 배포해 애플리케이션을 업데이트하라. 그대로 stack 명령을 사용하면 된다. 명령을 실행하면 새로운 데이터베이스 서비스를 구성할 레플리카와 웹 애플리케이션의 레플리카가 추가로 생성된다.

001) # 수정된 정의에 따라 애플리케이션 배포
002) ➜ docker stack deploy -c ./todo-list/v3.yml todo
003) Creating network todo_app-net
004) Creating service todo_todo-web
005) Creating service todo_todo-db
006) 
007) # 스택에 포함된 서비스 목록을 확인한다.
008) ➜ docker stack services todo
009) ID             NAME            MODE         REPLICAS   IMAGE                          PORTS
010) 1dku4wwx3m8f   todo_todo-db    replicated   1/1        diamol/postgres:11.5           
011) kvr2ij57ccj7   todo_todo-web   replicated   1/1        diamol/ch06-todo-list:latest   *:8080->80/tcp
  1. 002: 신규 배포이므로 리소스가 새로 생성된다. 컨피그 객체는 이미 존재하는 외부 리소스이므로 여기에 나타나지 않는다.

  2. 011: 웹 서비스는 하나의 레플리카로 구성된다. 마찬가지로 하나의 레플리카로 구성된 데이터베이스 서비스를 사용한다.

  3. 민갑한 데이터는 컨피크 객체에 보관해서는 안 된다.

  4. 컨피그 객체는 암호화되지 않으며 클러스터 접근 권한이 있는 사람이면 누구든 전체 내용을 볼 수 있기 때문이다.
  5. 외부 인원이 클러스터 접근 권한을 알게 될 가능성은 그리 높지 않지만, 클러스터 내부에 보관됐다 해도 민감한 데이터는 암호화해야 한다.
  6. 도시 스웜에 비밀값 리소스가 있는 것도 이런 정보를 보관하기 위한 것이다.

links

social