[THE SOPT 도커 스터디] Week5 - 3. 도커 스웜
Dev

[THE SOPT 도커 스터디] Week5 - 3. 도커 스웜

1) 도커 스웜을 사용하는 이유

  • 도커 엔진을 구동하다가, CPU나 메모리, 디스크 용량과 같은 자원이 부족해지는 경우
  • 현실적으로 새로운 서버를 새로 사는 것은 매우 어려움
  • 가장 많이 사용하는 방법은 여러 대의 서버를 클러스터로 만들어 자원을 병렬로 확장하는 것
  • 도커에서 제공하는 이를 위한 공식 솔루션이 바로 ‘도커 스웜’과 ‘스웜 모드’

2) 스웜 클래식과 도커 스웜 모드

  • 도커 스웜의 두 가지 종류
    • 컨테이너로서의 스웜 (도커 버전 1.6 이후부터 사용 가능) : 스웜 클래식
      • 여러 대의 도커 서버 하나의 지점에서 사용하도록 단일 접근점 제공
      • 일반적인 도커 명령어, 도커 API로 클러스터의 서버 제어, 관리 가능
      • 분산 코디네이터(각종 정보 저장, 동기화), 매니저(클러스터 내 서버 관리, 제어), 에이전트(각 서버 제어) 별도로 실행
    • 도커 스웜 모드 (도커 버전 1.12 이후부터 사용 가능) : 스웜 모드
      • 마이크로서비스 아키텍처의 컨테이너를 다루기 위한 클러스릴 기능에 초점
      • 같은 컨테이너 동시에 여러 개 생성해 필요에 따라 유동적으로 컨테이너 수 조절 가능
      • 컨테이너 연결 분산하는 로드밸런싱 자체적으로 지원
      • 일반적으로 스웜 모드가 서비스 확장성과 안정성에서 더 뛰어나 더 많이 사용
      • 클러스터링을 위한 모든 도구가 도커 엔진에 내장
  • 스웜 모드를 사용하면 더욱 많은 기능을 손쉽게 사용 가능. 가능하다면 스웜 모드 사용이 추천됨

3) 스웜 모드

docker info | grep Swarm
# 스웜 모드 클러스터 정보 확인

(1) 도커 스웜 모드의 구조

  • 워커 노드 : 실제로 컨테이너가 생성되고 관리되는 도커 서버
  • 매니저 노드 : 워커 노드들을 관리하기 위한 도커 서버. 매니저 노드에서 컨테이너가 생성될 수는 있음 (기본적으로 워커 노드의 역할을 포함)
  • 실제 운영 환경에서는 홀수 개의 매니저 노드로 다중화하는 것을 권장
  • 스웜 모드는 매니저 노드의 절반 이상에 장애가 생길 경우, 장애가 생긴 매니저 노드가 복구될 때까지 클러스터 운영을 중단

(2) 도커 스웜 모드 클러스터 구축

docker swarm init --advertise-addr 192.168.0.100
# 매니저 노드 생성. --advertise-adder 뒤에 다른 도커 서버가 매니저 노드에 접근하기 위한 IP 주소 입력

docker swarm join \\ --token 'TOKEN' \\ 192.168.0.100:2377
# 워커 노드 추가. 'TOKEN' 자리에는 실제 토큰이 들어가야 함

docker swarm join-token manager
# 매니저 노드를 추가하기 위한 토큰 확인

docker swarm join-token worker
# 워커 노드를 추가하기 위한 토큰 확인

docker swarm join-token --rotate manager
# 매니저 노드에서 수행. 매니저 노드를 추가하는 토큰 변경

docker swarm leave
# 추가된 워커 노드에서 수행. 해당 워커 노드 해제 (아직 삭제 완료되는 것 아님)

docker rm 'WORKER_NODE_NAME'
# 매니저 노드에서 수행. 해당 워커 노드 삭제

docker swarm leave --force
# 매니저 노드 삭제

docker node promote 'WORKER_NODE_NAME'
# 워커 노드 매니저 노드로 승격

docker node demote 'MANAGER_WORKER_NAME'
# 매니저 노드 워커 노드로 강등

(3) 스웜 모드 서비스

  • 스웜 모드 서비스 개념
    • 스웜 모드에서 제어하는 단위는 컨테이너가 아닌 서비스
    • 서비스는 같은 이미지에서 생성된 컨테이너의 집합
    • 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령 수행
    • 서비스 내에 컨테이너는 1개 이상 존재 가능, 컨테이너들은 각각 워커 노드와 매니저 노드에 할당. 이러한 컨테이너들이 바로 태스크(Task)
    • 서비스 생성 시, 스웜 스케줄러가 서비스의 정의에 따라 컨테이너를 노드에 분산해서 할당
    • 이 때 함께 생성된 컨테이너가 레플리카(Replica). 서비스에 설정된 레플리카의 수만큼의 컨테이너가 스웜 클러스터 내에 존재해야 함
    • 스웜은 컨테이너 상태를 계속 확인하다가, 이 조건을 만족하지 않으면 스스로 새로운 컨테이너를 클러스터에 새롭게 생성
    • 롤링 업데이트 : 서비스 내 컨테이너들의 이미지 일괄적으로 업데이트할 때 컨테이너들의 이미지를 순차적으로 변경해 서비스 자체가 다운되는 일 방지 (무중단 배포랑 비슷한듯?)
  • 스웜 서비스 생성
    • 서비스를 제어하는 도커 명령어는 전부 매니저 노드에서만 사용 가능
    docker service create \\ ubuntu: 14.04 \\ 'command'
    # docker run 명령어와 비슷하게 동작. 뒤에 셸 명령어 설정 가능
    # 컨테이너는 detatched 모드로 실행되어야 함 (컨티어너 내부에 프로세스가 있어야 함)
    # 이름을 명시하지 않으면 이름 무작위로 설정
    
    docker service ls
    # 스웜 클러스터 내의 서비스 목록 확인
    
    docker service ps 'SERVICE_NAME'
    # 서비스 내의 컨테이너 목록, 상태, 컨테이너가 할당된 노드의 위치 등 파악 가능
    
    docker service rm 'SERVICE_NAME'
    # 서비스 상태와 관계 없이 서비스의 컨테이너 삭제
    
  • nginx 웹 서비스 생성
  • docker service create --name myweb \\ --replicas 2 \\ -p 80:80 \\ nginx # myweb이라는 이름 사용, 2개의 레플리카, 80번 포트 개방, nginx 이미지 사용 # 스웜 클러스터 자체에 80번 포트 개방. 다른 노드로 접근해도 위 웹 서버에 접근 가능 docker service scale myweb=4 # myweb 서비스의 컨테이너 4개로 증가 docker service create --name global_web \\ --mode_global # --mode-globaldm을 사용하면 모든 노드에 컨테이너 하나씩 생성. default는 복제 모드
  • 스웜 모드의 서비스 장애 복구
    • 컨테이너가 삭제, 다운될 경우 서비스가 자동으로 컨테이너 생성
    • 다운됐던 노드가 회복한다 해도 다시 그 노드에 컨테이너가 할당되지는 않음
  • 서비스 롤링 업데이트
  • docer service update \\ --image nginx:1.11 \\ myweb2 # 서비스를 생성할 때 업데이트 관련 설정 조작 가능 docker service inspect docker service insperct --type service # 롤링 업데이트 설정 확인
  • 서비스 컨테이너에 설정 정보 전달 : config, secret
    • 컨테이너 내부에서 공통적으로 사용되는 설정 값, 보안 값. 스웜 모드에서만 사용 가능
    • secret : 비밀번호, SSH 키, 인증서 키
      • 화생성된 secret을 조회해도 실제 값을 확인할 수는 없음
      • 매니저 노드 간에 암호화된 상태로 저장되고, 메모리에 저장되기 때문에 서비스 컨테이너가 삭제될 경우 secret도 함께 삭제됨
    • docker secret create password - 'INPUT' # password라는 이름의 secret 생성 docker secret ls # secret 목록 조회 docker secret inspect password # password secret 상세 조회 docker service create \\ --name mysql \\ --replicas 1 \\ --secret source=password, target=password \\ mysql: 5.7 # source(서비스의 secret)을 통해 target(컨테이너 내부의 secret) 생성
    • config : nginx, 레지스트리 설정 파일