14.1.도커를 사용한 애플리케이션 업그레이드 프로세스

  • 빌드에 대한 신뢰감은 성공적인 배포가 계속돼야만 쌓을 수 있으며 이 과정의 핵심은 애플리케이션 헬스 체크다.
  • 헬스 체크 없이는 애플리케이션이 자기 수복성을 가질 수 없고 안전한 업데이트와 롤백도 불가능하다.

실습 먼저 무작위 숫자 애플리케이션의 첫 빌드를 배포하는 것부터 시작해 보자. 웹 서비스는 한 개 컨테이너. API 서비스는 여섯 개 레플리카로 실행한다. 컨테이너 상태를 통해 롤링 업데이트의 진행 과정을 알 수 있을 것이다. 도커 엔진은 스웜 모드로 전환한다. 그리고 컴포즈 파일을 병합하고 병합한 파일로 스택을 배포한다.

  • 여러 개로 나뉜 컴포즈 파일은 스택 배포에 사용할 수 없다.
  • 먼저 오버라이드 파일을 하나의 컴포즈 파일로 병합해야 한다.
001) ➜ cd ch14/exercises
002) 
003) # 코어 컴포즈 파일과 오버라이드 파일을 병합한다
004) ➜ docker-compose -f ./numbers/docker-compose.yml -f ./numbers/prod.yml config > stack.yml
005) 
006) # 병합된 컴포즈 파일로 스택을 배포한다
007) ➜ docker stack deploy -c stack.yml numbers
008) 
009) # 스택의 서비스 정보를 확인한다.
010) ➜ docker stack services numbers
011) ID             NAME                  MODE         REPLICAS   IMAGE                            PORTS
012) z7kotrvq3c4h   numbers_numbers-api   replicated   6/6        diamol/ch08-numbers-api:latest   
013) lfsxdoojepil   numbers_numbers-web   global       1/1        diamol/ch08-numbers-web:latest
  1. 004: 스택을 배포하려면 컴포즈 파일이 단일 파일이어야 한다. 도커 컴포즈 config 명령으로 컴포즈 파일을 단일 파일로 병합할 수 있다.

  2. 012~013: 스택을 배포하면 한 노드에 레플리카 한 개만 실행되는 global 모드 서비스와 레플리카 여섯 개로 실행되는 replicated 모드 서비스가 각각 하나씩 실행된다.

  3. API 서비스는 일반적인 replicated 모드로 실행 중인데, 웹 서비스는 gobal 모드로 실행 중이라고 나 온다.

  4. global 모드로 동작하는 서비스는 한 노드에 레플리카를 하나만 실행한다.
  5. 이 모드는 인그레스 네트워크를 우회하기 위한 목적으로 사용하는데, 리버스 프록시 같은 상황에서 유용하게 사용할 수 있는 모드다.
  6. 여기서는 롤링 업데이트 과정에서 replicated 모드와의 차이를 보여 주기 위한 목적으로 사용했다.

예제 14-1 global 모드 서비스는 인그레스 네트워크 대신 호스트 네트워크를 사용할 수 있다.

001) numbers-web:
002)   ports:
003)     - target: 80
004)       published: 80
005)       mode: host
006)   deploy:
007)     mode: global
  1. 005: ports 항목에 이 필드 설정을 추가하면 해당 서비스를 인그레스 네트워크 대신 호스트의 80번 포트와 연결한다. 한 노드에 레플리카 하나만으로도 무방한 가벼운 웹 애플리케이션이거나 네트워크 성능이 매우 중요해서 인그레스 네트워크 내 라우팅에 따른 오버헤드를 제거하고 싶다면 유용하게 사용할 수 있는 설정 패턴이다.
  2. 007: deploy 항목에 이 필드 설정을 추가하면 해당 서비스는 한 노드에서 한 개의 컨테이너만 실행된다. 레플리카의 수는 노드의 수와 같으므로 클러스터에 새로 추가된 노드에도 컨테이너가 실행된다.

실습 이제 버전 v2 컴포즈 파일과 헬스 체크 설정이 추가된 오버라이드 파일, 운영 환경용 오버라이드 파일을 병합해 보자. 그리고 스택을 다시 배포하라.

  • 헬스 체크가 없으면 클러스터가 컨테이너의 이상 상태를 확인하지 못하므로 정상적으로 컨테이너를 교체하지 못한다.
  • 또한 롤링 업데이트에서 헬스 체크가 없다면 그 업데이트가 성공했는지 클러스터에서 알 방법이 없다.
001) # 헬스 체크, 운영 환경 설정 오버라이드 파일과 v2 버전 파일을 병합한다.
002) ➜ docker-compose -f ./numbers/docker-compose.yml -f ./numbers/prod.yml -f ./numbers/prod-healthcheck.yml -f ./numbers/v2.yml config > stack.yml       
003) 
004) # 스택을 업데이트한다.
005) ➜ docker stack deploy -c stack.yml numbers
006) 
007) # 스택의 레플리카 상태를 확인한다.
008) ➜ docker stack ps numbers
  • 도커 스웜의 롤링 업데이트는 섬세하게 결정된 기본값을 따라 동작한다.
  • 레플리카는 하나씩 교체되며 새 컨테이너가 정상적으로 실행되는지 확인이 끝난 후 다음 컨테이너 업데이트에 들어간다.
  • 또 볼링 업데이트는 새 컨테이너를 실행하기 전에 먼저 기존 컨테이너를 종료하는데, 새 컨테이너가 정상적으로 시작되지 않으면 전체 업데이트가 중단된다.
  • 책에서 이러이러하다라고 설명하는 것만 읽으면 얼핏 논리적이고 당연하게 느껴질 수도 있지만, 사실 잘 생각해 보면 이상한 부분이 많다.
  • 왜 새 컨테이너를 실행하기도 전 에 먼저 기존 컨테이너를 제거하는 것일까? 새 컨테이너가 제대로 동작한다는 보장도 없는데 말이다.
  • 그리고 또 롤링 업데이트가 실패한 경우에는 왜 반쯤 망가졌을 수도 있는 시스템을 그대로 두고 업데이트를 중단하는 것일까? 다행히 롤링 업데이트는 이러한 동작 방식에 이르기까지 세세한 설정 옵션을 제공한다.

links

social