16일차_롤링 업데이트

• 롤링 업테이트가 기본 상태에서 어떻게 동작하는지 이해해야만 한다.

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

• (step 1)
• 배포 주기는 단순 앱 버전 외에 크게 의존 모듈이 업데이트 된 경우, 앱 코드 컴파일에 사용하는 SDK가 업데이트 된 경우, 앱 플랫폼이 업데이트 된 경우, 운영체제가 업데이트 된 경우 최소 4가지 주기를 고려해야한다.
• 성공적인 빌드 자동화를 위해서는 헬스 체크가 가장 중요하다. 아래는 첫 배포 코드이다

# 1. 빌드 자동화를 이용하기 위해 첫 배포부터 차근차근 이해해보자
cd ch14/exercises

# 코어 컴포즈 파일과 오버라이드 파일 병합(stack.yml 생성)_ 스택을 배포하려면 컴포즈 파일이 단일 파일이어야 한다.
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/prod.yml config > stack.yml

# 병합한 컴포즈 파일로 스택 배포
docker stack deploy -c stack.yml numbers

# 스택 서비스 정보 확인_여기 replicated모드가 아닌 global모드로 동작하는 서비스가 있는데, 리버스 프록시 등을 위해 인그레스 네트워크를 우회하기 위한.. 그냥 이상없다.
docker stack services numbers

• 아래는 웹 서비스 기본 설정 코드이다.

# 2. 웹 서비스 기본 설정 코드
numbers-web:
	ports:
    	- target: 80
          published: 80
          mode: host # 서비스를 인그레스 네트워크가 아닌 호스트의 80번 포트와 연결한다.
    deploy:
    	mode: global # 서비스를 한 노드에서 한 개의 컨테이너만 실행

• 여기까지의 코드는 헬스 체크가 없기에, 버그 발생 시 스스로 수복하지 못한다.
• (step 2)
• 헬스 체크 코드를 추가해보자

# 3. 헬스 체크 코드를 추가하여 배포
# 헬스체크, 운영 환경 설정 오버라이드, v2버전 파일 병합 및 로그레벨 설정하여 stack.yml단일파일로 생성
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/prod.yml -f ./numbers/prod-healthcheck.yml -f ./numbers/v2.yml --log-level ERROR config > stack.yml

# 스택 업데이트. 이 때 global모드는 하나의 래플리카만 사용가능하기에, 새 래플리카 실행 전 기존 래플리카가 먼저 종료되어 서비스 중단이 2초간 발생!
docker stack deploy -c stack.yml numbers

# 스택 레플리카 상태 확인
docker stack ps numbers

• 도커 스웜의 롤링 업데이트는 하나의 래플리카씩 교체하며, 정상적으로 실행되는지 확인 후에 다음 컨테이너 업데이트를 수행한다. 하나라도 실패하면 업데이트를 중단한다.

14-2. 운영 환경을 위한 롤링 업데이트 설정하기

• 헬스 체크를 추가했기에 버그 시 20초 안에 스웜이 이상을 일으킨 래플리카를 교체하고 다시 회복시킨다. 하지만 롤링 업데이트의 속도가 느리기에 비교적 안전하지 않다는 단점이 존재한다. 이를 해결하기 위한 세세한 업데이트 커스텀은 컴포즈 파일 서비스 정의의 deploy 항목을 사용한다.

# 4. 롤링 업데이트 커스텀 설정
numbers-api:
	deploy:
    	update_config: # 롤링 업데이트 과정 설정
        	parallelism: 3 # 한 번에 교체하는 래플리카 수. default 1
            monitor: 60s # 다음 컨테이너 교체 전 새로 실행한 컨테이너의 이상여부 모니터링 시간. default 0
            failure_action: rollback # monitor시간내에 헬스체크가 실패하거나 실행되지 않을 시 취할 조치. default중지, 현재는 이전 버전으로 롤백
            order: start-first # 래플리카 교체 절차의 순서. default stop-first로 실행중인 래플리카 수가 서비스 정의에서 지정한 수를 넘지 않게 함. 현재는 추가적인 시스템 자원이 있는 경우임.

• parallelism은 전체 래플리카 수의 30% 정도로 설정하면 빠른 롤링 업데이트가 가능하다. monitor는 헬스체크가 두세번 수행하게 하는게 좋다.

# 5. 배포 반영
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/prod.yml -f ./numbers/prod-healthcheck.yml -f ./numbers/prod-updateconfig.yml -f ./numbers/v3.yml --log-level ERROR config > stack.yml

docker stack deploy -c stack.yml numbers

docker stack ps numbers

docker service inspect --pretty numbers_numbers-api # 스웜 서비스 정보에서 서비스 정의, 업데이트 설정, 최근 업데이트 결과 등을 쉽게 볼 수 있는 명령어

14-3. 서비스 롤백 설정하기

• 롤백 설정만 잘 해두면 레플리카 오류발생시에도 신규 기능이 나타나지 않을 뿐이다. 다만 서비스 중단 시간의 차이가 있다. 문제 발생 시 롤링 업데이트 start-first방식이었다면 이전 버전으로 자동 롤백할 것이다.
• 아래는 서비스 중단 속도를 줄이기 위해 문제 발생 시 최대한 빨리 이전 버전으로 돌아가는 롤백 설정 코드이다

numbers-api:
	deploy:
    	rollback_config:
        	parallelism: 6
        	monitor: 0s # 롤백 실패 시 어차피 레플리카 교체할거라 모니터링 필요없다
            failure_action: continue # 롤백 작업 중에 오류가 있더라도 이전 버전을 믿고 그냥 롤백을 마저 진행
            order: start-first # ㅇㅎ! 일단 새 버전의 레플리카고 자시고 이전버전부터 실행하게 한다

• (대게 오버라이드 파일이 많으면 업데이트 마다 순서를 지정해야하기에 여러 파일로 분할하지 않는게 좋다.)
• 업데이트 시작->새 버전 레플리카 실행->완전히 실행되면 네트워크 트래픽을 받으며 모니터링->이상없으면 다음 세트 교체

14-4. 클러스터의 중단 시간

• (온라인 실습 환경으로 Play with Docker 웹 싸이트를 이용하여 가상머신 구축 및 도커 설치 없이 여러 노드를 가진 스웜을 맞춰 노드 관리와 애플리케이션 배포를 연습할 수 있다.)
• 고가용성 스웜을 위해 3개 노드를 매니저, 2개를 워커로 지정.
• 노드의 실행 중인 컨테이너를 안전히 종료하고 교체하기 위해 스웜의 유지보수 모드인 드레인 모드로 설정한다.

# 1. 드레인 모드로 노드를 설정
docker node update --availability drain node5
docker node update --availability drain node3

docker node ls

• 여러 매니저를 지정하더라도, 실제로 클러스터를 통제하는 매니저는 리더 매니저 노드이다. 나머지 매니저 노드는 리더 매니저가 고장나면 자리를 이어받기에 항상 리더는 홀수여야한다. 만약 매니저 노드가 아예 죽어버리면 워커 노드 중 하나를 매니저로 승격시킬 수도 있다.

# 2. 리더 매니저 자리를 매니저 노드 중 하나가 승계 및 워커 노드 하나를 승격
docker swarm leave --force # node1의 강제 이탈(나머지 매니저 노드가 알아서 리더를 승게함)

docker node update --availability active node5 # node5의 드레인 모드 해제

docker node promote node5 # 매니저 노드 승격하여 매니저 홀수로 유지 == 고가용성

docker node ls # 노드 목록 확인

• 만약 node1이 다시 복구되면 node demote로 매니저 노드 중 하나를 워커 노드로 강등시켜 홀수를 유지하면 된다.
• 다음의 몇가지 문제 시나리오를 스윽 보자. 모든 매니저 고장 시 워커로도 작동은 한다. 하나의 매니저만 남아있다면 강제로 리더로 만들어야한다. 노드 간 래플리카를 고르게 재배치하기 위해 service update --force로 변경사항 없이 강제로 업데이트 시켜 재배치 가능하다.

14-5. 스웜 클러스터의 고가용성

• 아직 다루지 않은 여러 지역의 데이터 센터로 하나의 클러스터를 구성하면 (어느 지역은 매니저, 어디는 워커 등) 네트워크 지연 시간 탓에 연락 두절로 판단하여 모든 컨테이너를 한 곳의 데이터 센터로 재배치하고 각각의 매니저가 자신이 리더라 판단해 분열될 가능성이 있다.
• 가장 좋은 방법은 클러스터를 여러 개 구성하는 것이다. (그냥 같은걸 여러개 돌려서 로드 밸런싱_가까운 곳으로 라우팅)