[Docker] 도커 스웜

3.1 도커 스웜을 사용하는 이유

• 자원이 부족하면 서버를 새로 사기 보다 여러대의 서버를 클러스터로 만들어서 자원 병렬로 확장
• 적당한 성능의 서버 여러대를 하나의 자원 풀 Pool로 만들어 사용 가능

3.2 스웜 클래식과 도커 스웜 모드

1. 컨테이너로서의 스웜
   • 1.6 이후 버전부터
   • 스웜 클래식
   • 여러대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근법 제공
   • docker run, docker ps 등 일반적인 도커 명령어와 도커 API로 클러스터 서버를 제어하고 관리할 수 있는 기능 제공
   • 연산 코디네이터 에이전트 등이 별도로 실행
2. 도커스웜 모드
   • 1.12 버전 이후부터
   • 마이크로서비스 아키텍쳐의 컨테이너를 다루기 위한 클러스터링 기능에 초점
   • 같은 컨테이너를 동시에 여러개 생성해 필요에 따라 자체적으로 지원
     • 서비스 확장성과 안정성 등 여러 측면에서 스원 클래식보다 뛰어나기 때문에 일반적으로 스웜모드를 더 많이 사용
   • 클러스터링을 위한 모든 도구가 도커 엔진 자체에 내장되있기 떄문에 더욱 쉽게 서버 클러스터 구축
   • 대규모 클러스터 서비스 운영시 스웜 클래식보다 스웜 모드가 유리
     • 스웜모드는 마이크로 서비스 아키텍처 애플리케이션을 컨테이너로 구축 도우ㅏ줌
     • 서비스 장애에 대한 고가용성
     • 부하 분산을 위한 로드밸런싱
   • 쿠버네티스는 스웜모드와 비슷하지만 더욱 복잡하고 많은 기능을 제공함

3.3 스웜모드

• 별도 설치 x

• docker info

  grep swarm 으로 확인

• 클러스터링 시 NTP 등의 틀을 이용해 동기화 필요

3.3.1 도커 스웜 모드의 구조

• 매니저 노드와 워커 노드
  • 매니저는 워커 노드를 관리하기 위한 도커 서버
    • 기본적으로 워커노드의 역할 포함
  • 노드는 실제로 컨테이너가 생성되고 관리되는 도커서버
• 매니저노드는 1개 이상 but 워커노드는 필요 x
  • 매니저 노드만으로 스웜 클러스터 구성 가능 but 일반적으로 워커노드와 매니저 노드 구분해서 사용 권장
• 매니저 노드를 다중화 하는 것을 권장
  • 매니저 부하 분산, 특정 매니저 노드가 다운됐을 때 정상적으로 스웜 클러스터 유지
  • but 매니저 수 늘린다고 스웜 클러스터의 성능이 좋아지는 것은 아님
• 스웜모드는 매니저 노드의 절반 이상에 장애가 생겨 정상적으로 작동하지 못할 경우 장애가 생긴 매니저 노드가 복구될 때 까지 클러스터의 운영 중단
  • 네트워크 파티셔닝과 같은 현상 발생시 짝수개의 매니저로 구성한 클러스터는 운영이 중단될 수 도 있지만 홀수개로 구성했을 경우에는 과반수 이상이 유지되는 쿼럼(quorum) 매니저에서 운영을 계속할 수 있음 => 홀수개 권장

3.3.2 도커 스웜 모드 클러스터 구축

• 도커 노드를 추가할 떄 사용되는 토큰을 주기적으로 변경해줘야함

3.3.3 스웜 모드 서비스

3.3.3.1 스웜 모드 서비스 개념

• 도커 클라이언트에서 사용하는 명령어가 제어하는 것은 컨테이너 -> 스웜모드에서 제어하는 단위는 컨테이너가 아닌 서비스
• 서비스는 같은 이미지에서 생성된 컨테이너의 집합체
• 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령 수행됨
• 서비스 내에 컨테이너 1개 이상 존재 가능
• 함께 생성된 컨테이너를 레플리카라고 하며 서비스에 설정된 레플리카의 수 만큼의 컨테이너가 스웜 클러스터 내에 존재해야함
• 서비스는 롤링 업데이트 기능도 제공
  • 서비스 내 컨테이너들의 이미지를 일괄적으로 업데이트해야 할 때 컨테이너들의 이미지를 순서대로 변경해 서비스 자체가 다운되는 시간 없이 컨테이너의 업데이트 진행
• 서비스 모드는 2가지가 있음
  1. replicated 모드
     • 컨테이너를 정의된 수 만큼 복제 생성
     • 실제 서비스를 제공하기 위해
  2. global 모드
     • 레플리카 셋의 수 지정 x
     • 스웜 클러스터를 모니터링하기 위한 에이전트 컨테이너 등을 생성해야 할 때 유용

3.3.3.3 스웜 모드의 서비스 장애 복구

• 복제 모드의 설정된 서비스 컨테이너가 정지하거나 특정 노드가 다운되면 스웜 매니저가 새로운 컨테이너를 생성해 자동으로 복구
• rebalance 작업이 일어나지는 않음

3.3.3.4 서비스 롤링 업데이트

• 롤링 업데이트를 자체적으로 지원

3.3.3.5 서비스 컨테이너에 설정 정보 전달하기

• secret: 비밀번호나 ssh키, 인증서 키와 같이 보안에 민감한 데이터를 전송하기 위해서
• config: nginx나 레지스트리 설정 파일과 같이 암호화할 필요가 없는 설정값들에 대해

=> 스웜모드에서만 가능 docker run 명령어에서는 사용 x

• secret은 매니저 노드 간에 암호화된 상태로 저장됨
  • 파일 컨테이너에 배포된 뒤에도 파일 시스템이 아닌 메모리에 저장되기 때문에 서비스 컨테이너가 삭제될 경우 secret도 함꼐 삭제됨
• config와 secret값을 수정할 수는 없지만 추가 삭제 가능

=> 이미지를 다시 빌드할 필요 없이도 여러 설정값의 애플리케이션 쉽게 활용 가능

3.3.3.6 도커 스웜 네트워크

• 여러개의 도커 엔진에 같은 컨테이너를 분산해서 할당하기 때문에 각 도커 데몬의 네트워크가 하나로 묶인 네트워크 풀이 필요

3.3.3.6 서비스 디스커버리

• 새로 생성된 컨테이너 생성의 발견 혹은 없어짐 감지 자체적으로 지원
• 서비스 A의 컨테이너 입장에서는 서비스 B의 컨테이너 IP주소를 알 필요도 없이 서비스 B라는 이름으로 모두 접근 가능

3.3.3.7 스웜 모드 볼륨

• 스웜 모드에서 볼륨 사용하기 까다로움
  • 서비스를 할당받을 수 있는 모든 노드가 볼륨 데이터를 갖고 있어야함

=> 어느 노드에서도 접근 가능한 퍼시스턴트 스토리지를 사용해 해결

3.3.4 도커 스웜 모드 노드 다루기

3.3.4.1 노드 AVAILABILITY 변경하기

• 마스터노드는 서비스를 할당받지 않도록 설정
  1. Active
  • 새로운 노드가 스웜 클러스터에 추가되면 기본적으로 설정되는 상태
  • 노드가 서비스의 컨테이너를 할당받을 수 있음을 의미
    1. Drain
  • drain 상태로 설정하면 스웜매니저의 스케줄러는 컨테이너를 해당 노드에 할당 x
  • 일반적으로 매니저 노드에 설정
  • 노드에 문제가 생겨 일시적으로 사용하지 않는 상태로 설정해야 할 때
  • drain 상태로 변경하면 해당 노드에서 실행중이던 서비스의 컨테이너는 전부 중지되고 active 상태의 노드로 다시 할당 됨
    1. Pause
  • 더는 할당받지 않는다는 점에서 drain과 같음
  • but 실행중인 컨테이너가 중지되지 않는다는 점에서 다름

3.3.4.2 노드 라벨 추가

• 노드를 분류하는 것과 비슷
• 서비스 제약 설정
  • –contraint 옵션을 추가해 서비스의 컨테이너가 할당될 노드의 종류 선택 가능