[Docker] - 006. Docker Swarm 이란

Docker Swarm 이란

도커에서 만든 컨테이너 오케스트레이션 툴이다. 

컨테이너 오케스트레이션이란 여러 호스트의 컨테이너 배포, 관리, 네트워킹, 확장 제어를 자동화하는 것을 의미한다. 

비슷한 예로는 AWS ECS, K8S, Apache Mesos 등이 있다. 

 

 

Docker Swarm 을 사용하는 이유 

도커는 기본적으로 단일 호스트에서 동작한다.

하지만 단일 호스트로 구성된 환경은 확장성(Scalability)과 가용성(Availabilty), 장애 허용성(Fault Tolerance) 측면에서 많은 한계점을 가지기에 단일 호스트에서 운영을 하다 보면 문제가 발생할 수 있다. 

 

이 문제를 해결하기 위해, 서버의 스팩을 더 높여 수직 확장을 하거나, 여러개의 컨테이너를 올려 수평 확장하는 방법이 있으며, 서버나 컨테이너를 수평 확장할 수 있다. 하지만 수평 확장했을 때 아래와 같은 고민을 할 수 있다. 

• 서로 다른 각각의 호스트들을 어떻게 연결하고 관리할 것인가?
• 어떤 컨테이너를 어느 호스트에 배치하여 구동시킬 것인가?
• 각기 다른 호스트에 배치된 컨테이너들의 상호 통신을 어떻게 제어할 것인가?

이때 도커 스웜과 같은 오케스트레이션툴을 사용하여 여러 서버를 하나의 클러스터로 묶어 제어할 할 수 있다. 

즉, 서로 다른 서버에 여러 컨테이너를 클러스터로 묶어 서비스 운영이 가능하다. 

Docker Swarm 의 기능

• 쿠버네티스 만큼은 아니더라도 여러 대의 호스트로 구성된 중소 규모의 클러스터에서 컨테이너 기반 애플리케이션 구동을 제어하기에 충분한 기능을 갖추고 있다.
• 도커 엔진(Docker Engine)이 설치된 환경이라면 별도의 구축 비용 없이 스웜 모드(Swarm Mode)를 활성화하는 것만으로 시작할 수 있다.
• 도커 컴포즈(Docker Compose)를 사용해 본 사람이라면 도커 스웜(Docker Swarm)의 스택(Stack)을 이용한 애플리케이션 운영에 곧바로 적응할 수 있다.
• 도커 데스크탑(Docker Desktop)으로도 클러스터 관리와 배포가 모두 가능한 단일 노드 클러스터를 바로 만들 수 있다. 따라서 최소한의 자원으로 컨테이너 오케스트레이션 환경을 만들어 시험해볼 수 있다.

현재 쿠버네티스가 컨테이너 오케스트레이션의 표준 기술로 자리 잡은 상태이다 보니 Docker Swarm 은 각광받지 못하고 있다. 

Docker Swarm 의 구성

분산 코디네이터, 에이전트 등이 도커 엔진에 내장되어 있다. 

분류	설명
분산 코디네이터	여러 개의 도커 서버를 하나의 클러스터로 구성하기 위해 각종 정보를 저장 및 동기화
에이전트	각 서버를 제어하는 역할
매니저 노드	클러스터 내의 워커 노드를 관리  무조건 1개 이상 존재 해야함  워커 노드의 역할도 포함
워커 노드	실제 컨테이너가 생성되고 관리되는 도커 서버, 워커 노드는 없을 수도 있다

매니저 노드와 워커 노드

Manager Node

매니저 노드는 클러스터의 상태를 유지 및 관리하고 서비스들을 스캐줄링하며 스웜 모드의 HTTP API 엔드포인트 제공한다.

Raft 를 사용하여 전체 스웜과 스웜에서 실행되는 모든 서비스의 일관된 상태를 유지한다. 

일관된 상태를 예시로 들자면, Nginx 컨테이너를 3개 생성하라는 요청이 들어오면 스웜의 매니저 노드는 3개의 컨테이너를 유지하려고 한다. 워커 노드에게 Task를 Dispatch 했는데 컨테이너가 생성이 안되면 다시 생성하거나, Task 가 실행되고 있는 노드가 다운 되었을 경우 다른 노드에게 Task 를 주어서 서비스의 상태를 유지하려고 한다. 

 

매니저 노드도 워커 노드와 동일하게 동작한다. 하지만 매니저 노드에 컨테이너를 올리지 않고 관리용으로만 동작하길 원할 경우 매니저 노드의 상태를 Drain Mode로 설정을 하면 매니저 노드에서는 Task가 실행하지 않는다. 

Worker Node

워커 노드는 매니저 노드로부터 Dispatch 받은 Task를 실행시킨다. 워커 노드에는 Agent 가 실행되고 할당된 Task에 대해 보고한다. 이로 인해 매니저 노드는 할당된 Task 의 상태를 확인하여 워커 노드의 원하는 상태를 유지할 수 있다.

Service,  Task, Container 란 

Service 

매니저 노드나 워커노드에서 실행할 작업을 정의한다. 스웜 시스템에서 사용자의 Interact 하는 단위이다. 

도커 엔진에서 컨테이너를 실행하는 것처럼 도커 스웜모드에서 서비스를 생성하기 위해 도커 이미지와 컨테이너 안에서 실행해야 할 명령어와 포트, 복제본 수 등을 설정해줘야한다. 

Task

Task 라는 것은 Docker Container 와 Container 내부에서 실행되는 명령어를 합친 것이라 볼 수 있으며, Task 는 스왐의 Atomic Scheduling Unit 이다.Task 를 통해 도커 컨테이너와 컨테이너 안에서 실행할 명령어를 전달한다. 매니저 노드는 서비스 규모에 설정된 복제본 수에 따라 워커 노드에 Task 를 할당한다. Task 가 노드에 할당되면 다른 노드로 이동할 수 없다. 할당된 노드만 실행되거나 실패할 수 있다. 

Container

Container 는 격리된 Process 이다. Swarm 모드에서는 각 Task 는 하나의 Container만 생성한다. Container 의 활성 여부로 스케쥴러가 Task 가 잘 동작하고 있는지 확인할 수 있다. 

Replicated 와 global services 란 

서비스를 배포할 때 replicated 와 global 가 있다. 

Replicated Service 란

Replicated Service 의 경우 사용자가 직접 얼마나 복제할지 명시를 해줘야 한다. 이러면 매니저 노드가 해당 숫자 만큼 Task를 만들어서 워커노드에 배포한다. 

docker service create --name my_web --replicas 3 nginx

Global Service 란

Global Service 는 모든 Node 에서는 한개의 Task 가 실행하도록 하는 것이다. 숫자를 미리 지정하지 않고, 각 노드에 1개씩 생성되며, 스웜에 노드가 추가(Join)될 경우 자동으로 Task 가 추가되어 실행된다. 주로 모니터링이나 Anti-virus Scanner 로 많이 사용된다. 또한 노드가 Drain 상태인 경우 Global Service 라고 하여도 Task 가 생성되지 않는다. 다시 Active 모드로 변경할 경우 자동으로 Task 가 실행된다. 

docker service create --name myservice --mode global alpine top

Swarm Classic 과 Swarm Mode

도커 스웜에는스웜 클래식과 스왐 모드 두가지가 있다. 이 둘의 차이는 목적에 나타난다. 

스왐 클래식은 여러대의 도커 서버를 하나의 지점에서 사용할 수 있도록 단일 접근점을 제공한다면, 스왐 모드는 마이크로서비스 아키텍처의 컨테이너를 다루기 위한 클러스터링 기능에 초점을 맞추고 있다. 

Swarm Classic

• 도커 버전 1.6 이후부터 사용 가능 
• docker run, docker ps 등 일반적인 도커 명령어와 도커 API로 클러스터의 서버를 제어하고 관리할 수 있는 기능 제공
• 분산 코디네이터, 에이전트 등을 별도로 실행해야 함 

Swarm Mode

• 도커 버전 1.12 이후부터 사용 가능 
• 같은 컨테이너를 여러개 생성해 필요에 따라 유동적으로 컨테이너의 수 조절 가능 
• 컨테이너로의 연결을 분산하는 로드밸런싱 기능을 자체적으로 지원
• 분산 코디네이터, 에이전트 등이 모두 도커 엔진 자체에 내장됨 

스웜 모드가 서비스 확장성과 안정성 등 여러 측면에서 스웜 클래식보다 뛰어나며 Swarm Classic 은  2018년 6월 6일 이후 적극적으로 개발되고 있지 않기 때문에 Swarm Mode 를 더 많이 사용한다. 

Manager Node 권장 수 

매니저 노드는 클러스터를 관리한다. 만약 매니저 노드가 한개일 때 발생할 수 있는 문제를 생각해 봐야한다.

한개의 매니저 노드에 접근하지 못하더라도 서비스는 워커노드에 실행될 수 있다. 하지만 워커노드를 복구를 하기 위해서는 새로운 클러스터를 생성해야 한다. Docker Swarm 모드의 장애 허용점(fault-tolerance) 장점을 활용하기 위해 도커에서는 홀수의 매니저 노드를 사용하기를 권장한다. 여러 개의 매니저 노드를 사용하면 고가용성과 매니저 노드의 장애로부터 Downtime 없이 복구가 가능하다. 

Docker recommends a maximum of seven manager nodes for a swarm.

3개의 Manager Swarm은 1개의 Manager Node의 장애까지 수용할 수 있다. N개의 Manager Cluster 있을 경우(N-1)/2개의 매니저 손실을 수용한다. 도커 공식 문서를 보면 스웜 모드에서 최대 7개 매니저 노드까지 사용할 것을 권장하고 있다. 더 많은 매니저 노드를 사용하는 것이 확장성이나 성능을 향상시키는 것이 아니기 때문이라고 한다. 

Docker Swarm 에서 사용하는 포트

아래 포트의 경우 호스트간의 통신을 위해 열어주여아 한다. 열어주지 않으면 도커 스웜으로 운영이 불가능하다. 

호스트 OS 또는 사용중인 방화벽에 따라 포트를 열어주는 방법이 다르다. 이때 여기를 참고하면 된다. 

[Docker] - 007. Docker Swarm Port 열기 (2376/2377/7946/4789)

• TCP 2376 Port : 도커 머신이 동작하기 위해 사용되는 포트이며, 도커 클라이언트가 통신할 때 사용됨 
• TCP 2377 Port : Docker Swarm 또는 클러스터의 노드 간의 관리를 위해 사용되며 매니저 노드에서만 열어야 함
• TCP/UDP 7946 Port : 노드 간의 통신
• UDP 4789 Port : 클러스터에서 사용되는 Ingress 오버레이 네트워크 트래픽

Docker Swarm 의 주요 Command

노드 생성, 조회, 관리 

• docker swarm init : Swarm 생성하며 해당 명령어를 실행하는 노드가 첫 번째 관리자가 되며 Swarm Mode 가 활성화 됨
• docker swarm join-token : Worker와 Manager 를 Swarm 에 포함시키기는 명령어 
• docker node ls : Swarm 의 노드 조회 

서비스 생성, 조회, 관리 

• docker service create ~~: 새로운 서비스를 만드는 명령어
• docker service ls: 실행 중인 서비스 조회 및 서비스 상태, 실행중인 replicas 의 기본 정보 조회 
• docker service ps <service> : 특정 서비스의 replicas 정보 조회 
• docker service inspect <service> : 서비스의 상세한 정보 조회 
• docker service inspect <service> --pretty : 서비스의 중요 정보만 조회
• docker service scale <service>:<number> : 서비스의 복제본 수를 확장하거나 수축
• docker service update ~~ : 실행 중인 서비스의 속성 업데이트
• docker service logs <service>: 서비스 로그 조회
• docker service rm <service> : 서비스의 모든 정보 삭제

서비스 스택 생성, 조회, 관리 

• docker stack deploy -c <YAML> <Name> : -c 옵션으로 배포할 서비스가 정의된 YAML 파일을 지정하여 서비스 배포 
• docker stack ls : 실행중인 stack 조회 
• docker stack services :  stack 에 포함된 리스트 조회 
• docker stack ps : stack 에 포함된 리스트의 service 정보 조회 (services 조회) 
• docker stack rm : stack 삭제 (services 삭제)