[Docker] 여러 호스트의 도커를 관리하자, Docker Swarm

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.

 

Docker

---

저번 포스팅까지는 하나의 호스트 안에서의 도커 엔진을 사용하는 방법에 대해 알아보았다. 이번 포스팅에서는 이제 여러 호스트 즉, 여러 개의 호스트 머신들 각각에 설치되어 있는 도커 엔진들을 관리하는 방법 중 하나인 도커 스웜에 대해 알아보도록 하자.

1. 왜 도커 스웜을 쓸까?

실제 프로덕션 환경에서는 하나의 호스트에 설치되어 있는 도커 엔진으로만 모든 컨테이너를 관리하지는 않는다. 이유는 생각보다 간단하다. 그 도커 엔진이 설치되어 있는 호스트 즉, 물리 머신이 갑자기 다운되거나 장애가 발생하면 그 즉시 프로덕션은 더 이상 사용자들에게 서비스를 제공할 수 없게 된다. 뿐만 아니라 하나의 호스트 머신에서 만약 CPU나 메모리 디크스 용량과 같은 리소스 부족 문제가 발생할 수도 있기 때문이다.

 

이러한 문제를 해결하기 위해서 가장 심플한 방법은 매우 성능이 좋은 서버를 사는 것이다. 하지만 아무리 좋은 성능의 서버를 산다고 하더라도 그 서버의 성능을 100% 활용하기에는 힘들 것이다. 분명 남아서 놀고 있는 리소스도 존재할 것이다. 따라서 확장성 측면이나 서버 유지 비용 측면에서도 이런 해결법은 합리적이지 못하다. 따라서 요즘 이런 문제를 해결하기 위해 가장 자주 사용하는 방법으로 여러 대의 서버를 클러스터로 만들어서 자원을 병렬로 확장하는 것이다. 예를 들어, 현재 각 메모리가 4GB인 물리 머신 3대를 서버로 활용하고 있다고 해보자. 그러면 총 가용 메모리는 12GB이다. 프로덕션으로 운영하던 중 트래픽이 증가해 또 4GB 메모리를 갖는 서버 1대를 추가적으로 증설해야 할 필요가 생겼다. 그러면 이 때, 이미 갖고 있는 3대의 서버에 병렬적으로 1대의 서버만 추가해주어 일종의 자원(리소스) Pool을 만들어 사용할 수 있다. 

 

이렇게 여러 서버를 자원 Pool로 만드는 작업 또한 쉽지 않다. 새로운 서버나 컨테이너가 추가되었을 때 이를 발견하는 작업(Service Discovery)부터 어떤 서버에 컨테이너를 할당할 것인가에 대한 스케쥴러, 로드밸런서 문제, 또한 클러스터 내의 서버가 다운되었을 때 고가용성을 최대한 보장하기 위해서는 어떻게 해야할지 등.. 관리적인 측면에서 여러가지 고민이 발생한다. 하지만 현대에는 이러한 고민들도 쉽게 해결할 수 있도록 해주는 여러 오픈소스 툴이 존재한다. 그 중 대표적인 것이 바로 도커 스웜과 쿠버네티스가 있다. 

 

요즘 실제 환경에서는 도커 스웜보다는 쿠버네티스를 매우 자주 사용하는 추세다. 그렇다면 이번 포스팅에서는 대체 왜 도커 스웜에 대해서 배울까? 더 이상 사용하지 않는 기술이라고도 할 수 있는 도커 스웜은 배울 필요가 없지 않을까? 할 수도 있겠다. 하지만 책의 저자분은 서버 클러스터를 접해본 적이 없는 초보자라면 도커 스웜을 먼저 사용해보면서 기초를 익히길 권장한다. 도커 스웜이 서커 클러스터에서 컨테이너를 어떻게 다루는지에 대한 기초 지식을 쌓기에 적합하다고 한다. 따라서 클러스터를 생애 처음(?) 접해보는 필자이기에 도커 스웜을 배워보고자 한다. 그러면 이제 도커 스웜에 대해 살펴보자.

2. 도커 스웜 모드

도커 스웜은 별도의 설치 과정이 필요 없이 도커 엔진 자체에 내장되어 있다. 즉, 저번 포스팅까지해서 우리가 사용해본 도커는 도커 스웜 모드가 비활성화된 상태에서 다루어본 것이였다. 실제로, 도커가 설치된 호스트에서 아래 명령어를 실행해보자.

 

$ docker info | grep -E "Swarm"

 

 

위처럼 inactive 라고 나오며 도커 스웜 모드가 비활성화된 상태임을 알 수 있다. 그러면 이제 도커 스웜 모드의 용어와 구조에 대해서 알아보자.

3. 도커 스웜 모드의 구조

스웜 모드에는 매니저(manager) 노드와 워커(worker) 노드로 구성되어 있다. 워커 노드는 실제적으로 컨테이너가 생성되고 관리되는 도커 서버이고, 매니저 노드는 워커 노드를 관리하기 위한 도커 서버이다. 물론 매니저 노드에서도 워커 노드처럼 컨테이너를 생성할 수는 있다. 그래서 워커 노드 없이 매니저 노드만으로 스웜 클러스터를 구성할 수는 있다. 하지만 보통은 매니저 노드와 워커 노드를 분리해서 사용한다. 왜냐하면 스웜 클러스터(서버 클러스터)를 구성할 수 있는 것은 매니저 노드에서만 가능하기 때문이다. 매니저 노드와 워커 노드의 특징과 관계를 도식화해보면 아래와 같다.

 

스웜은 매니저 노드와 워커 노드로 구성되어 있음

 

우선 위 그림에서 VM 아이콘이 의미하는 바는 물리 머신을 의미한다. 즉, 매니저 노드1에 물리 머신 1대, 워커 노드 1~3에 물리 머신 3대, 총 물리 머신이 4대가 존재하는 상황이다. 그리고 워커 노드들 안에 있는 컨테이너 아이콘들은 워커 노드 안에서 실제 생성된 컨테이너들을 의미한다. 위 사진에서는 매니저 노드가 1개 이지만, 실제 프로덕션 환경에서는 매니저 노드를 N개를 두어 다중화를 한다. 그래야 매니저의 부하를 분산시키고, 혹여나 특정 매니저 노드가 다운되었다고 한들 다른 매니저 노드가 있기 때문에 정상적으로 스웜 클러스터를 유지할 수 있기 때문이다.

 

도커 스웜 모드는 매니저 노드의 절반 이상이 장애가 생길 경우, 장애가 생긴 매니저 노드가 복구될 때까지 클러스터의 운영을 중단한다. 이와 같은 특성 때문에 짝수 개수의 매니저 노드로 운영할 경우 문제가 생기기에 홀수 개수로 매니저 노드를 구성하여 과반수 이상이 유지되는 쿼럼 매니저에서 클러스터 운영을 계속할 수 있다. 따라서 매니저 노드의 개수는 홀수 개로 구성하는 것이 권장된다고 한다.

 

참고로 매니저 노드는 2가지로 더 분류되는데, 일반적인 매니저 역할을 하는 노드와 리더 역할을 하는 노드로 나뉜다. 리더 매니저 노드는 모든 매니저 노드에 대한 데이터 동기화와 관리를 담당하므로 항상 작동할 수 있는 상태여야 한다. 만약 리더 매니저 노드의 서버가 다운되거나 장애가 생기면 나머지의 일반적인 매니저 노드들 중에서 리더 매니저 노드를 다시 선출하게 되는데, 이 때는 Raft Consensus 알고리즘을 활용해 선출한다고 한다. 이 알고리즘에 대해서는 해당 책에서 깊게 다루지는 않는다.

4. 스웜 모드의 서버 클러스터 구축

그러면 이제 도커 스웜 모드에서 서버 클러스터를 구축하여 여러 개의 호스트에서 도커 엔진을 활용해는 방법에 대해 배워보자. 우선 물리 머신 3대를 아래와 같은 Hostname 과 IP 주소로 사용하였다. 물리 머신 3대를 구축하는 방법으로는 VM을 3대 설치하여도 좋고, 클라우드 서비스를 이용하여도 좋을 것 같다.(참고로 IP 주소는 원본과 다른 임의의 주소로 변환하였다) 또한 사용하는 머신 3대에는 모두 반드시 docker가 설치되어 있어야 한다.

 

HOSTNAME       IP Address
swarm-manager  123.456.789.12
swarm-worker1  123.456.789.13
swarm-worker2  123.456.789.14

 

위 환경이 마련되었다고 가정하고, 가장 먼저 할 일은 매니저 역할을 하는 서버 즉, HOSTNAME이 swarm-manager인 머신으로 들어가 스웜 클러스터를 생성(시작) 해준다. 아래 명령어 형식을 활용하면 된다. 참고로 --advertise-addr 옵션에는 다른 도커 서버(또 다른 매니저 노드이거나 워커 노드)가 해당 매니저 노드에 접근할 수 있도록 매니저 노드의 IP 주소를 명시해준다.

 

$ docker swarm init --advertise-addr 123.456.789.12

 

 

위 명령어가 잘 동작했다면 위와 같은 출력화면이 나타날 것이다. 주목할 부분은 2가지이다. 첫 번째는 사진의 맨 오른쪽 끝에 IP 주소에 2377번이라는 포트번호가 개방되었음에 주목하자. 즉, 우리는 워커 노드를 생성할 때 매니저 노드의 IP 주소의 2377번 포트번호를 이용할 것이다. 두 번째는 워커 노드 생성 시 사용할 토큰이다. 이 토큰을 활용해야만 워커 노드를 생성할 수 있다. 이 토큰을 확인할 수 있는 명령어도 있는데, 이는 아래와 같다.

 

$ docker swarm join-token worker

 

매니저 노드를 만들어보았으니, 이제 워커 노드를 생성해보자. HOSTNAME이 swarm-worker1인 머신으로 들어가 아래 명령어를 실행해보자.

 

$ docker swarm join \
--token [YOUR TOKEN] \
123.456.789:2377

 

위 명령어가 성공적으로 동작했다면 터미널의 표준출력에 "This node joined a swarm as a worker." 이라는 문장이 보일 것이다. 그리고 난 뒤 swarm-manager 머신으로 돌아가 클러스터에 추가된 노드가 무엇이 있는지 아래 명령어를 입력해보자.

 

$ docker node ls

 

 

위 화면을 보면 swarm-worker1 이라는 워커 노드가 하나 생겼음을 볼 수 있다. 방금했던 것처럼 swarm-worker2 라는 워커 노드도 같이 추가해보도록 하자.

 

다음은 매니저 노드를 추가하는 방법에 대해 알아보자. 매니저 노드를 추가하기 위해서는 워커 노드를 추가할 때 활용하는 토큰을 동일하게 사용할 수 없다. 즉, 매니저 노드를 추가할 때 활용하기 위한 별도의 토큰이 필요하다. 이 토큰을 확인하는 방법은 아래 명령어를 활용하면 된다.

 

$ docker swarm join-token manager

 

위 명령어로 출력되는 토큰은 외부에 노출되지 않도록 주의해야 한다. 왜냐하면 이 토큰을 알게 되면 아무나 매니저 노드를 생성하여 클러스터에 워커 노드를 임의로 추가할 수 있게 되고 그 워커 노드 안에 악성코드를 심은 컨테이너를 설치하는 등 여러가지 보안 이슈가 발생할 수 있기 때문이다. 실제 운영환경에서는 보안을 위해 매니저 노드를 생성하기 위한 토큰을 주기적으로 갱신해준다고 한다. 토큰을 갱신해주는 방법은 --rotate 옵션을 활용한 아래 명령어를 이용하면 된다.

 

$ docker swarm join-token --rotate manager

 

다음은 생성된 워커 노드를 삭제해보도록 하자. 삭제하고 싶은 워커 노드가 있는 머신으로 들어가 아래 명령어를 입력하면 된다.

 

$ docker swarm leave

 

leave 라는 키워드를 사용해서 해당 워커 노드는 스웜 모드를 해제하게 된다. 이렇게 되면 매니저 노드는 이 워커 노드를 Down이라는 상태로 인지하게 된다. 실제로 해당 워커 노드가 스웜 모드를 해제하기 전/후의 매니저 노드 화면을 보면 아래와 같이 변한 것을 볼 수 있다.

 

 

하지만 위처럼 Down 이라는 상태가 워커 노드를 삭제한 것은 아니다. 위 상태로 변경된 이후, 반드시 매니저 노드에서 해당 워커 노드를 삭제해주어야 한다. 삭제 명령어는 아래와 같다.

 

$ docker node rm swarm-worker1

 

즉, 워커 노드를 실질적으로 삭제하는 단계는 다음과 같다.

 

1. 삭제할 워커 노드 머신으로 들어가 스웜 모드 해제
2. 매니저 노드 머신으로 다시 돌아가 삭제 명령어를 통해 해당 워커 노드를 삭제

매니저 노드를 삭제하기 위해서는 매니저 노드 머신에서 아래 명령어를 입력해주면 된다.

 

$ docker swarm leave --force

 

매니저 노드를 삭제할 경우에는 항상 주의를 기울여야 한다. 매니저 노드를 스웜 클러스터에서 삭제하게 되면 해당 매니저 노드에 저장되어 있던 클러스터 정보도 모두 삭제된다. 그렇다면 스웜 클러스터에 매니저 노드가 1개가 있는 상태인데, 이 매니저 노드를 삭제가 가능할까? 안될 것 같지만.. 가능하다. 그리고 삭제가 되는 순간 스웜 클러스터에 매니저 노드가 0개가 되므로 해당 스웜 클러스터는 더이상 사용하지 못하는 상태가 된다. 

 

마지막으로, 워커 노드를 매니저 노드로 변경하는 방법, 반대로 매니저 노드를 워커 노드로 변경하는 방법에 대해 알아보자. 먼저 워커 노드를 매니저 노드로 변경하는 명령어는 아래와 같다.

 

$ docker node promote swarm-worker1

 

그리고 반대로 매니저 노드를 워커 노드로 변경하는 명령어는 아래와 같다.

 

$ docker node demote swarm-worker1

 

매니저 노드가 1개일 때, 그 매니저 노드에 대해서 demote 명령어를 적용해 워커 노드로 변경할 수는 없다. 또한 매니저 노드가 여러개일 때, 리더 매니저 노드에 demote 명령어를 사용하게 되면 다른 매니저 노드 중 새로운 리더를 선출하게 된다.

5. 스웜 모드 서비스

스웜 모드를 배우기 이전까지에서의 도커 명령어의 제어 단위는 컨테이너였다. 즉, 도커 클라이언트를 활용해서, 예를 들어, docker run, docker rm 등과 같은 명령어들의 제어 단위는 컨테이너였다. 하지만 도커 스웜에서의 제어 단위는 서비스(Service)이다. 서비스를 생성해보기 전에 이와 관련된 개념인 서비스, 태스크, 레플리카와 같은 용어의 개념이 무엇인지 숙지하고 넘어가보도록 하자. 아래 그림을 보자.

 

서비스, 태스크, 레플리카의 개념

 

먼저 서비스(Service)는 같은 이미지로부터 생성된 1개 이상의 컨테이너 집합을 의미한다. 그래서 서비스를 제어하면 같은 서비스 내의 모든 컨테이너들에 같은 명령이 수행된다. 이후 스웜 스케쥴러가 서비스 내의 컨테이너들을 알아서 워커 노드 또는 매니저 노드에 분산하여 할당해준다. 이 때 테스크와 레플리카의 개념이 등장한다. 먼저 각 노드에 할당되어 있는 컨테이너들 모두를 가리켜 태스크(Task)라고 부른다. 그리고 이 태스크를 구성하는 컨테이너 하나를 레플리카(Replica) 하나라고 부른다. 그래서 위의 서비스에서는 서비스 레플리카셋이 총 4개라고 할 수 있다.

 

스웜은 위와 같이 서비스 내의 컨테이너들에 대한 상태를 계속 확인하면서 모니터링 하고 있다가 서비스 내에 정의된 레플리카셋의 수만큼 컨테이너 개수가 존재하지 않으면 새로운 컨테이너 레플리카를 생성한다. 또한 특정 노드의 서버가 다운되거나 특정 노드 내의 컨테이너가 동작을 하지 않고 멈춰있다면 그 때도 레플리카셋의 수와 컨테이너 수가 불일치한다고 간주하여 매니저 노드는 새로운 컨테이너 레플리카를 생성하게 된다.

 

Container3 컨테이너가 다운되거나 동작이 멈췄을 경우

 

서비스는 롤링 업데이트(Rolling Update) 기능도 제공한다. 롤링 업데이트란, 여러 개의 서버, 컨테이너 등으로 구성된 클러스터의 설정이나 데이터 등을 변경하기 위해서 서버 또는 컨테이너를 1개씩 재시작하는 기능을 의미한다. 이렇게 하면 제공하는 서비스의 다운 시간이 생기지 않고 지속적인 서비스가 가능하다. 물론 재시작하는 서버, 클러스터가 있기 때문에 트래픽이 나머지 서버, 클러스터에 몰리긴 하겠지만, 한 번에 재시작하는 방법보다는 훨씬 더 합리적일 것이다. 그러면 이제 서비스에 대한 개념에 대해서도 알아보았으니, 서비스를 생성해보도록 하자.

5-1. 서비스 생성

우선, 서비스를 제어하는 도커 명령어는 반드시 매니저 노드에서만 가능하다. 따라서 앞으로의 실습 명령어는 매니저 노드 호스트 머신에서 입력되었음을 알아두자. 우선 docker service create 명령어를 사용해서 서비스를 생성해보자. 명령어 형식은 아래와 같다.

 

$ docker service create [OPTIONS] IMAGE [COMMAND]

 

생성할 서비스의 컨테이너는 컨테이너 내부에서 반드시 하나의 프로세스를 포그라운드 잡으로 계속 수행되고 있는 상태여야 한다. 다시 말해, 매니저 노드입장에서는 서비스의 컨테이너를 반드시 detached 모드로 실행할 수 있어야 한다. 위 명령어 형식의 COMMAND 부분에는 인자로 준 IMAGE를 기반으로 하는 컨테이너 생성 후 즉시 실행할 명령어를 입력해준다. 그래서 아래 예시 명령어에서는 무한루프로 "Hello zedd"를 출력하는 셸 스크립트를 실행하도록 했다. 

 

$ docker service create \
ubuntu:14.04 \
/bin/sh -c "while true; do echo Hello zedd; sleep 1; done"

 

서비스가 잘 생성이 되었다면 아래 출력화면 처럼 보일 것이다. 필자는 생성한 서비스 정보를 출력해보기도 하였다. 아래 화면에서의 REPLICAS는 방금 위 명령어로 생성한 레플리카 즉, 컨테이너의 숫자를 의미한다.

 

 

서비스와 관련된 명령어는 아래와 같다. 보통 컨테이너를 제어할 때 사용한 명령어와 비슷하다. 

 

명령어	의미	특징
docker service ls	생성한 서비스의 정보들을 출력
docker service ps [SERVICE]	명시한 서비스의 상세 정보를 출력
docker service rm [SERVICE]	명시한 서비스를 삭제	컨테이너 때와는 달리 서비스는 해당 서비스의 상태(동작 중이던 말던..)에 상관없이 바로 삭제 가능
docker service scale [SERVICE]=[숫자]	명시한 서비스의 레플리카 컨테이너를 [숫자]만큼 늘리거나 줄임
docker service create --with-registry-with-auth 옵션 사용	서비스 생성을 위한 기반 이미지를 깃헙과 같은 Private 저장소 또는 사설 레지스트리에서 받아올 경우, 로그인 인증하는 옵션	매니저 노드에서 해당 옵션을 사용해 서비스 생성하면 워커 노드에서는 그 이미지가 있는 저장소 또는 레지스트리에 별도로 로그인 하는 절차를 거치지 않아도 됨

 

위에서는 간단한 셸 스크립트를 활용해서 서비스를 생성해보았다. 이번엔 Nginx 라는 웹 서버 서비스를 서비스로 생성해보는 실습을 해보자. 우선 명령어부터 살펴보자.

 

$ docker service create \
--name zeddweb
--replicas 2 \
-p 80:80 \
nginx

 

이번 실습에서 생성할 레플리카 컨테이너 개수는 2개로 설정하였다. 그리고 위 명령어로 생성될 컨테이너들로 외부에서 접근가능하도록 하기 위해 -p 옵션을 주어 포트포워딩을 수행해주었다. 그리고 생성한 서비스에 대한 상세 정보 출력을 보자.

 

 

zeddweb 이라는 서비스는 총 2개의 레플리카 컨테이너를 생성했고, 그 컨테이너들의 이름은 각각 zeddweb.1 과 zeddweb.2 이다. 그리고 NODE 항목을 살펴보면, 이 컨테이너들은 각각 swarm-worker1, swarm-worker2 라는 노드에 할당되었음을 알 수 있다. 실제로 워커 노드 머신으로 들어가 컨테이너 단위를 제어하는 명령어인 docker ps 명령어를 각각 쳐보면 스웜에서 할당한 컨테이너가 실행중인(Up) 상태임을 알 수 있다.

 

워커 노드 머신에 각각 들어가 실행중인 컨테이너 정보를 출력해본 화면

 

방금 위에서 2개의 레플리카 컨테이너가 각 워커노드에 할당되었음을 알았다. swarm-manager인 매니저 노드에는 해당 컨테이너가 할당되지 않았다. 그렇다면 매니저 노드에서는 생성한 레플리카 켄테이너 즉, Nginx 웹 서버로 접근이 불가능할까? 아니다. -p 옵션을 통한 포트번호 개방은 레플리카 컨테이너가 할당된 노드인지 아닌지에 상관없이 스웜 클러스터 내에 있는 모든 노드는 해당 포트번호로 접근이 가능하다. 다시 말해, 위 명령어에서 사용한 -p 80:80 이라는 옵션에서의 앞의 80 숫자는 스웜 클러스터 서버 자체 포트를 개방했다고 생각하면 된다. 

 

$ docker service create \
--replicas 2 \
-p [스웜 클러스터 자체 PORT]:[생성할 컨테이너 PORT] \
[IMAGE]

 

실제로, 아래 사진은 워커 노드 2개, 매니저 노드 1개에서 모두 Nginx 웹 서버로 curl 테스트를 수행했고, 정상적인 HTTP status code인 200이 반환된 것을 알 수가 있다.

 

 

다음으로, 위에서 설정한 레플리카 컨테이너 수를 늘리거나 증가시켜보자. 사용하는 명령어는 docker service scale 명령어이다.

 

$ docker service scale zeddweb=4

 

 

레플리카셋을 4개로 scale 했더니 2개의 레플리카 컨테이너가 추가로 생성되었다. 위 화면을 보면 추가된 컨테이너들 2개 중 하나는 swarm-manager라는 매니저 노드에, 나머지 하나는 swarm-worker1 노드에 할당되었다. 그런데 한 가지 생각해볼 문제가 있다. 위 화면 기준으로 한다면 Nginx 웹 서버 컨테이너가 swarm-worker1 에는 2개가 자리잡고 있고, 이 2개의 컨테아너 모두 80/tcp 포트 번호를 사용할 것이다. swarm-worker1 노드 서버의 80/tcp 포트 번호를 2개의 컨테이너가 같이 사용하는 것은 불가능할텐데.. 어떻게 가능한 걸까?

 

위 상황을 예시로 들어보자. 현재 swarm-worker1 이라는 워커 노드에 동일한 포트 번호를 개방한 Nginx 컨테이너 2개가 있고 swarm-worker2 노드에 1개, swarm-manager 노드에 1개의 Nginx 컨테이너가 있다. 운영을 하던 중 스웜 클러스터의 80번 포트로 트래픽 1개 요청이 들어왔다. 이 때, 들어온 요청 1개를 4개의 컨테이너 중 1개로 리다이렉트하게 된다.

 

결국 동일한 포트 번호를 점유하고 있다고 하더라도 트래픽 요청 1개에는 반드시 1개의 컨테이너로만 요청이 들어가게 된다. 물론 이 과정에서 들어온 트래픽 요청을 어떤 컨테이너를 선택할 것이냐에 대해서, 도커 스웜은 기본적으로 라운드 로빈 알고리즘을 택하고 있다. 하지만 트래픽이나 리소스 사용량 등을 고려해야 한다면 이러한 알고리즘에 기반한 컨테이너 선택은 비합리적일 수도 있음을 알아두자.

 

다음은 global(글로벌) 서비스를 생성해보도록 하자. 위에서 소개한 도커 스웜 개념 중 서비스의 종류로는 2가지가 존재한다. 하나는 우리가 지금까지 Nginx 실습을 하면서 알아본 복제 모드(Replicated) 서비스이다. 나머지 하나는 보통 스웜 클러스터 모니터링을 하기 위한 용도로 사용하는 global 서비스가 존재한다. global 서비스는 복제 모드와는 달리 특이하게 사전에 생성할 레플리카 셋 개수를 지정하지 않는다. 왜냐하면 global 서비스는 스웜 클러스터 내에 있는 모든 노드에 각각 한개씩 컨테이너를 생성하기 때문이다. global 서비스를 생성하는 명령어는 --mode 라는 옵션에 global 키워드를 넣어주면 된다. 명령어 예시는 아래와 같다.

 

$ docker service create \
--name global_zedd \
--mode global \
nginx

 

 

출력화면을 보면 global_zedd 이라는 이름의 global 서비스 내에 레플리카 컨테이너가 총 3개 생겼고, 각 노드마다 1개씩 생긴 것을 볼 수 있다. 이 때 레플리카 컨테이너 개수가 3개인 이유는 노드가 총 3개이기 때문!

5-2. 서비스 장애 복구

도커 스웜은 노드 서버가 다운되거나 노드 내의 컨테이너가 동작을 멈출 시 자동으로 컨테이너를 생성해주어 장애 복구를 수행해준다고 했다. 이번엔 이에 대해서 한번 실습을 하면서 어떻게 동작하는 것인지 살펴보자. 우선 현재 상황은 아래와 같다. zeddweb 이라는 서비스를 하나 운영 중이고, 이 서비스 내에 할당된 컨테이너 정보는 아래와 같다.

 

 

위 상황에서 swarm-worker1 호스트로 들어가 컨테이너 zeddweb.1 이라는 이름의 컨테이너를 하나 삭제시켜보자.

 

 

위 화면을 보자. 빨간색 네모칸이 바로 방금 swarm-worker1 노드에 있는 컨테이너를 삭제함으로써 발생한 것이다. swarm-manager 라는 매니저 노드에서 zeddweb.1 이라는 동일한 이름의 컨테이너가 생성된 것을 볼 수가 있다.(물론 컨테이너 이름 끝의 hash 값은 달라져서 재생성됨) 따라서, 위와 같이 컨테이너에 장애가 발생했을 때 도커 스웜은 알아서 다른 노드에서 동일한 컨테이너를 생성해 복구시키는 동작을 수행한다는 것을 알 수 있다.

 

그렇다면 이제 컨테이너가 아닌 노드 서버를 다운시켜보도록 하자. 현재 스웜 클러스터 내의 노드 상태값은 아래와 같다. 

 

 

그러면 이번엔 swarm-worker2 호스트로 들어가 도커 데몬 서버를 종료시켜보도록 하자. 도커 데몬 서버를 종료시키는 명령어는 아래와 같다.

 

$ service docker stop && systemctl stop docker.socket

 

다시 노드 상태값을 봐보자. swarm-worker2 노드의 STATUS 값이 DOWN으로 변한 것을 볼 수 있다.

 

 

그리고 난 뒤 운영중인 서비스의 노드 내의 컨테이너 정보를 출력해보자.

 

 

swarm-worker2 노드의 도커 데몬 서버를 종료시켰기 때문에 위 화면에서 swarm-worker2 노드에 할당되어 있는 컨테이너가 종료되었고 이후, swarm-worker1 노드에서 컨테이너를 복구한 것을 볼 수 있다. 

 

다만, 도커 스웜은 만약 장애가 난 컨테이너들이 복구되더라도 복구하기 전의 컨테이너 구성 환경으로 되돌려 놓지 않는다.(재균형 작업이 일어나지 않는다라고도 함) 예를 들어, swarm-worker1 노드에 있는 컨테이너가 동작이 멈추었을 때, 도커 스웜은 swarm-manager 노드에 컨테이너를 생성시켰다. 그리고 시간이 흘러 동작이 멈추었던 swarm-worker1 노드의 컨테이너가 다시 정상 상태로 돌아온다고 하여도 swarm-manager 노드에 복구를 위해 생성했던 컨테이너를 삭제하는 등과 같이 재균형을 맞추는 과정을 수행하지는 않는다는 것이다.

 

만약 재균형 작업을 해주려고 한다면 사람이 직접 해주어야 하는데, scale 명령어로 컨테이너 수를 줄이고 다시 늘려주어야 한다.

5-3. 서비스 롤링 업데이트

다음으로 알아볼 기능은 스웜 모드의 서비스 롤링 업데이트 기능이다. 스웜 모드는 자체적으로 롤링 업데이트 기능을 제공하며 docker service update 명령어를 활용해 기존에 운영중인 서비스에 대해 롤링 업데이트가 가능하다. 

 

실습 예시로, 우선 새로운 서비스를 하나 생성해보자. Nginx 1.10 버전의 이미지를 가지고 레플리카 컨테이너는 3개를 지정하여 서비스를 아래처럼 생성해보자.

 

$ docker service create \
--name nginx_service \
--replicas 3 \
nginx:1.10

 

 

위 명령어로 만든 새로운 서비스 내에 각 노드에 할당된 컨테이너는 위와 같다. 이제 아래 명령어를 사용해서 업데이트해보자. 업데이트할 사항은 각 레플리카 컨테이너의 Nginx 이미지를 1.10 버전에서 1.11 버전으로 업데이트할 것이다.

 

$ docker service update \
--image nginx1.11 \
nginx_service

 

그리고 난 뒤 해당 서비스 내에 각 노드에 할당된 컨테이너 정보는 아래처럼 갱신된 것을 볼 수 있다.

 

 

" \_ " 라는 문자열이 존재하는데, 이 문자열이 붙어있는 컨테이너는 동작을 멈춘 컨테이너로서, 서비스에서의 컨테이너 변경 기록을 의미한다. 그래서 위 화면을 해석하면 각 컨테이너 마다 1번씩 변경이 된 흔적이 보이고, 변경사항은 Nginx 이미지가 1.10 에서 1.11 버전으로 변경된 것을 알 수 있다.

 

추가로, 롤링 업데이트를 진행할 때 여러가지 설정을 해줄 수 있다. 이 설정들은 서비스를 생성할 때 설정해주어야 한다. 예를 들어, 업데이트 진행을 하다가 실패했을 경우 어떻게 할지 또는 하나의 레플리카 컨테이너를 몇 초 단위로 업데이트를 할지, 업데이트 작업을 한 번에 수행할 때 몇 개의 레플리카 컨테이너를 같이 진행할지 등을 설정할 수 있다. 이에 대한 정리는 아래와 같다. 보다 자세한 옵션은 공식 문서를 참조하자.

 

명령어	옵션	의미
docker service create	--update-delay 10s	각 컨테이너 레플리카를 10초 단위로 업데이트
	--update-paralleism 2	업데이트 수행 시 2개의 컨테이너 레플리카를 한 번에 업데이트 진행
	--update-failuer-action continue	업데이트 수행 시 오류가 발생했을 때 어떻게 할지에 대한 액션.  디폴트는 pause로 업데이트를 중지하는 설정이지만 continue로 설정 시 오류가 발생해도 계속 다음 롤링 업데이트를 진행하도록 설정

 

마지막으로, 롤링 업데이트를 하기 전으로 되돌리는 롤백(Rollback) 기능도 제공한다. 아래 명령어 형식을 이용해 수행이 가능하다. 참고로 롤백을 수행하고 난 뒤의 컨테이너는 최초 롤링 업데이트를 하기 전의 컨테이너와 똑같은 ID 값을 갖는 것으로 복구하는 것이 아닌 별도의 컨테이너를 새롭게 생성하여 롤백을 수행한다.

 

$ docker service rollback [SERVICE]

 

롤백을 수행한 후의 서비스 내 노드의 컨테이너 정보 출력 화면

5-4. 서비스 컨테이너에 설정 정보를 전달, secret과 config

여러 애플리케이션을 외부에 노출시키고 운영하려면 각 서버마다 적절한 환경을 설정해주어야 한다. 단적인 예로, 서버마다 어떤 환경인지(개발 환경인지, 운영 환경인지, ...)를 의미하는 환경변수 값부터 DB 서버를 사용한다면 그 DB 서버의 루트 계정 비밀번호 같은 값까지 여러 설정값들이 존재한다.

 

스웜을 배우기 이전의 컨테이너 단위로 도커를 제어할 때는 -v 옵션을 활용한 호스트 볼륨 공유를 통해 특정 설정 파일을 컨테이너에 공유하거나 -e 옵션을 사용하여 특정 환경 변수 값을 설정하는 등과 같이 수행했었다. 이런 방법은 컨테이너 1개 마다 설정을 해주어야 하는 것이고, 여러 개의 컨테이너들을 관리해야 하는 스웜 모드에서 이와 같은 방법을 사용하려면 매 컨테이너 마다 설정을 매번 해주어야 하는 귀찮음이 발생한다. 또한 DB 서버의 계정 비밀번호와 같은 보안에 민감한 값들을 -e 옵션에 적어주게 되면 보안 이슈도 발생하기 마련이다. 이러한 문제점들을 해결하기 위해 비밀번호나 SSH 키와 같은 보안에 민감한 데이터를 전송하기 위한 secret 기능이, 보안 이슈가 발생하지 않을 만한 기타 설정 값들을 전송하기 위해서는 config 기능이 도커 스웜에 존재한다. 이에 대해 하나씩 알아보도록 하자. 참고로 secret, config 기능은 스웜 모드에서만 적용이 가능하며 단일 컨테이너 단위로 제어할 때(docker run ~ 과 같은 명령어 사용)는 사용이 불가능하다.

 

먼저 secret 기능에 대해 알아보자. secret을 생성하는 명령어는 아래와 같다.

 

$ docker secret create [secret 이름] [값]

 

아래처럼 "1d2w3e4r" 이라는 텍스트를 secret으로 아래처럼 생성해보고 생성한 secret 정보를 출력해보자.

 

 

그리고 해당 secret의 상세 정보를 출력해보면 아래와 같은 내용을 확인할 수 있다.

 

 

그런데 생성한 secret의 상세 정보를 출력하더라도 위에서 생성한 값인 "1d2w3e4r"를 어디에서도 확인할 수가 없다. 왜냐하면 secret 값은 매니저 노드 간에 암호화된 상태로 저장이 되며 컨테이너에 secret 값이 적용되어 배포되어도 컨테이너 내부의 파일 시스템이 아닌 메모리에 저장되기 때문이다. 그래서 해당 컨테이너가 삭제될 경우 secret도 함께 삭제되게 된다. 그러면 이제 secret이 적용된 컨테이너를 생성해보도록 하자. 예시는 MySQL 이미지를 사용했다. 우선 명령어를 살펴보자.

 

$ docker service create \
--name mysql \
--replicas 1 \
--secret source=mysql_pw,target=mysql_root_password \
--secret source=mysql_pw,target=mysql_password \
-e MYSQL_ROOT_PASSWORD_FILE="/run/secrets/mysql_root_password" \
-e MYSQL_PASSWORD_FILE="/run/secrets/mysql_password" \
-e MYSQL_DATABASE="wordpress" \
mysql:5.7

 

위 명령에서 주목할 부분은 --secret 옵션과 그 옵션에 붙어 있는 source, target 인자에 있는 값이다. 형식은 아래와 같다.

 

$ docker service create --secret source=[secret 이름],target=[컨테이너 내부에서 보여질 secret 이름]

 

--secret 옵션은 source에 지정해준 secret 값을, target에는 지정해준 이름으로 컨테이너 내부에 마운트 시켜준다. 이 때 기본적으로는 컨테이너 내부의 "/run/secrets/" 라는 지정된 경로에 secret을 마운트한다. 그래서 컨테이너 내부로 들어가 "/run/secrets/" 라는 경로로 들어가보면 target에다가 지정해준 이름의 secret이 있는 것을 발견할 수 있다. 그리고 secret을 마운트 해줄 컨테이너 내부 경로는 절대경로로 target에다가 직접 입력해주면 "/run/secrets/" 경로가 아닌 사용자가 직접 입력한 경로에다가 secret을 생성해준다. 참고로 콤마(,)와 target 키워드 사이에 공백이 있다면 에러가 나므로 반드시 붙여 쓰는 걸 잊지말자. 

 

지금까지 secret을 알아보았다. 이제 config에 대해 알아보자. 위에서 secret 을 서비스에 적용하면서 입력한 명령어에 -e 옵션을 넣어 특정 경로를 컨테이너 내부의 환경변수로 지정해주었다. 그런데 위 예시만 해도 -e 옵션을 3번씩 써가며 일일이 설정해주었다. 설정해야 할 환경변수 값이 점점 많아지면 헷갈리거나 오타가 발생할 여지가 있다. 이를 위해 config가 등장한다. config 역할을 하는 미리 생성해둔 파일에 -e 옵션에 넣어줄 값들을 미리 정의해놓는 것이다.

 

그러면 config를 생성하고 적용하는 방법에 대해 배워보자. secret 사용 때와 매우 비슷하다. 명령어 형식은 다음과 같다.

 

$ docker config create [config 이름] [미리 정의해둔 config 관련 파일]

 

예시에서 생성할 config 파일은 아래와 같다.

 

# config.yml
version: 0.1
log:
  level: info
storage:
  filesystem:
    rootdirectory: /registry_data
  delete:
    enabled: true
http:
  addr: 0.0.0.0:5000

 

위 파일로 해서 config를 새로 생성 후, inspect 명령어로 config의 상세 정보를 출력해보자. secret 때와는 달리 Data 라는 항목에 값이 생긴 것을 볼 수 있다.

 

 

Data 항목에는 우리가 위에서 정의한 config.yml 파일의 내용이며 위 출력화면에서는 현재 base64 인코딩된 상태로 데이터가 들어가 있는 것이다. 만약 궁금하다면 해당 값을 아래 명령어를 수행해서 표준출력을 확인해보자.

 

$ echo dmVyc2lvbjogMC4xCmxvZzoKICBsZXZlbDogaW5mbwpzdG9yYWdlOgogIGZpbGVzeXN0ZW06CiAgICByb290ZGlyZWN0b3J5OiAvcmVnaXN0cnlfZGF0YQogIGRlbGV0ZToKICAgIGVuYWJsZWQ6IHRydWUKaHR0cDoKICBhZGRyOiAwLjAuMC4wOjUwMDAK | base64 -d

 

생성한 config를 서비스에 적용하는 방법도 secret 과 동일하다. source 와 target 인자에 적절한 값을 넣어주면 된다. 

 

$ docker service create \
--name yml_registry \
-p 5000:5000 \
--config source=registry-config,target=/etc/docker/registry/config.yml \
registry:2.6

 

만약 이미 설정한 secret, config 값을 다른 것으로 바꾸기 위해 추가하거나 삭제하려면 --secret-add, --secret-rm, --config-rm, --config-add 와 같은 옵션을 살펴보도록 하자. 참고로 이미 설정한 secret, config 값을 수정하는 것은 불가능하다. 단지 새로운 secret, config 값을 추가한 뒤 기존의 값을 삭제하는 방법으로 교체해야 한다. 

 

이렇게 secret, config를 잘 활용하면 환경이 변경됨에 따라 애플리케이션 빌드를 별도로 할 필요 없이 애플리케이션이 운영 중인 상태에서 설정 값만 바꾸어 주면 된다. 이렇게 하면 롤링 업데이트도 할 필요가 없어질 것이고 이에 따라 서비스가 중단되는 시간 없이도 운영이 가능해진다.

5-5. 도커 스웜 네트워크

이전에 도커 컨테이너 다루기 포스팅에서 컨테이너들 간에 통신을 가능케 하도록 하기 위해 도커 네트워크라는 것에 대해 배웠던 적이 있다. 그리고 그 때 브리지, 호스트, 논, 컨테이너 네트워크에 대해 배웠다. 이처럼 이번에는 도커 스웜에서 사용하는 네트워크에 대해서 알아보도록 하자.

 

기본적으로 도커 스웜의 네트워크는 이전에 배웠던 도커 네트워크랑 다른 방법을 사용한다. 왜냐하면 도커 스웜은 여러 개의 서버 즉, 여러 개의 도커 엔진에 같은 컨테이너를 분산하여 할당하기 때문이다. 그렇기 때문에 각각의 도커 엔진의 도커 데몬의 네트워크가 하나로 묶인 네트워크 풀(Pool)이 필요하게 된다. 그리고 컨테이너로 배포한 서비스를 외부로 노출했을 때, 스웜 클러스터 내의 어떤 노드로 접근하더라도 해당 컨테이너에 접근할 수 있도록 하는 라우팅 기능이 필요하다. 일례로, 위 예시에서 우리는 특정 컨테이너가 워커 노드에만 할당되었더라도 매니저 노드에서도 접근이 가능한 것을 살펴본 것이 바로 그것이다.

 

그러면 도커 스웜 모드를 활성화한 상태에서 도커 네트워크가 무엇이 있는지 살펴보자.

 

 

위에서 주목할 네트워크는 docker_gwbridge 와 ingress 라는 이름의 네트워크이다. docker_gwbridge 네트워크는 스웜에서 오버레이(overlay) 네트워크를 사용할 때 사용하는 네트워크이며, ingress 네트워크는 로드 밸런싱과 라우팅 메시(Routing Mesh)에 사용되는 네트워크이다. 이에 대해 하나씩 이해해보자.

5-5-1. 어떤 노드에서도 접근할 수 있도록 해주자, ingress 네트워크

ingress 네트워크는 스웜 클러스터가 생성이 되면 자동으로 등록되는 네트워크로서, 스웜 모드를 사용할 때만 적용되는 네트워크이다. 그래서 위에서 ingress 라는 이름의 네트워크의 SCOPE 항목을 보면 swarm 이라는 키워드가 적혀 있는 것을 볼 수 있다. 먼저 ingress 네트워크를 사용하는 구조를 그림으로 도식화해보면 아래와 같다.

 

 

스웜 클러스터 서버가 위와 같은 구조를 가진다고 해보자. ingress 네트워크는 어떤 노드에서도 어떤 컨테이너에 접근 가능하도록 설정해주는 라우팅 메시를 구성한다. 예를 들어, 위 그림에서 매니저 노드에서는 ingress 네트워크 덕분에 Container 3,4,5 이름의 컨테이너들에 대해 언제든지 접근이 가능하다. 또한 ingress 네트워크는 들어오는 트래픽을 적절하게 컨테이너들에 대해 분산하는 로드 밸런싱을 담당하기도 한다.(이 때, '적절하게'란 기본적으로 라운드 로빈 방식으로 트래픽을 여러 컨테이너들로 분산하는 방법을 채택한다)

 

그러면 이제 ingress 네트워크를 실습을 통해서 알아보자. 책 저자분이 이미 만들어두신 도커 허브의 이미지를 사용할텐데, 해당 이미지는 컨테이너의 호스트 이름, 즉 임의로 할당된 16진수를 할당하는 PHP 파일이 들어있는 웹서버이다. 아래 명령어를 통해서 해당 이미지를 기반으로 하는 컨테이너 레플리카셋을 4개로 하는 서비스를 만들어보자. 참고로 스웜  클러스터 서버 내 노드는 매니저 노드 1개, 워커 노드 2개인 상태이다.

 

$ docker service create \
--name zedd_hostname \
--replicas 4 \
-p 80:80 \
docker.io/alicek106/book:hostname

 

위 명령어로 서비스를 생성하는 데 성공했다면 해당 서비스의 스웜 클러스터 내에 생성된 컨테이너들이 어떤 노드에 할당되었는지 살펴보자.

 

 

위 화면을 보면 swarm-manager 라는 이름의 매니저 노드에 2개의 컨테이너가, 그리고 워커 노드에 각각 1개씩 컨테이너가 할당된 것을 알 수 있다. 이제 그러면 ingress 네트워크의 효과를 알아보기 위해서 일부러 다른 노드에 있는 컨테이너로 접근을 해보자. 현재 상황에서 swarm-worker1 이라는 노드에서 swarm-manager 노드 내의 컨테이너 2개로 curl 테스트를 날려보자. 우선, swarm-manger에 할당된 컨테이너들의 정보는 아래와 같다.

 

 

이제 swarm-worker1 이름의 노드로 이동해야 하니 해당 노드로 설정된 VM 터미널로 돌아간 뒤, curl 명령어를 테스트해보자.

 

 

response로 HTML 파일이 반환이 되었고, 하늘색 네모칸을 보면 컨테이너 ID가 반환된 것을 볼 수 있다. 그리고 이 컨테이너 ID는 바로 위에서 살펴본 swam-manager에 할당된 컨테이너 ID 중 한 개임을 알 수가 있다. 만약 처음 curl 테스트를 했을 때 swarm-manger 노드가 아닌 다른 노드에 할당된  컨테이너 ID가 나올 수도 있다. 이는 ingress 네트워크의 부가적인 특성인 로드 밸런싱 기능으로 다른 노드의 컨테이너로 접근하도록 되어 있기 때문이다. 따라서 몇 번 반복해서 curl 테스트를 날리면 위 사진처럼 swam-manager 노드에 할당된 컨테이너 ID가 response로 반환되는 현상을 관찰할 수 있다.

 

그러면 노드에 할당된 각 컨테이너들이 할당받는 IP 주소는 어떻게 설정되어 있을까? 특이한 점은 서로 다른 노드에 있음에도 불구하고 IP 주소가 순차적으로 할당되었다는 것이다. 이것은 곧 서로 다른 노드에 있는 컨테이너들 간에 별도의 포트포워딩을 설정하지 않아도 통신이 가능하다는 이야기이다. 실제로, 필자가 실습을 수행했을 때도 마찬가지였다.

 

이것이 가능한 이유는 ingress 네트워크가 오버레이 네트워크 드라이버를 사용하기 때문이다. 오버레이 네트워크는 여러 개의 도커 엔진에 있는 도커 데몬을 하나의 네트워크 풀로 만드는 네트워크 가상화 기술 중 하나이다. 따라서 이러한 오버레이 네트워크의 기능 덕분에 오버레이 네트워크를 드라이버로서 사용하는 ingress 네트워크가 서로 다른 노드의 컨테이너들 간에 통신을 가능하게 해줄 수 있는 것이다.

 

참고로, docker exec 명령어로 특정 컨테이너 내부에서 ifconfig 명령어를 수행하면 해당 컨테이너의 네트워크 인터페이스가 출력이 되는데, 컨테이너 모두 각각 eth0, eth1, lo 라는 총 3개의 네트워크 인터페이스를 갖고 있음을 볼 수 있다. 여기서 ingress 네트워크와 연결된 네트워크 카드는 eth0 이다.

5-5-2. 스웜 모드에서의 새로운 브리지 네트워크, docker_gwbridge 네트워크

스웜 모드에서 사용하는 네트워크 중 ingress 말고도 또 하나의 네트워크가 있는데, 바로 docker_gwbridge 네트워크이다. 이전에 스웜모드가 아닌 일반적인 모드에서의 도커 네트워크 중 컨테이너들 간에 통신을 가능케 해주는 브리지 네트워크(ex. "docker0" 이름의 네트워크)에 대해 배운적이 있었다.

 

이 브리지 네트워크는 스웜모드에서는 사용이 불가능하다. 그래서 ingress 네트워크를 포함한 오버레이 네트워크 드라이버를 사용하는 네트워크들은 docker_gwbridge 라는 새로운 유형의 브리지 네트워크를 함께 사용함으로써 서로 다른 노드들 내의 컨테이너들 간에 통신이 가능하도록 해준다. 참고로 docker_gwbridge 와 컨테이너 간에 연결해주는 네트워크 인터페이스는 eth1 로 연결이 된다.

5-5-3. 사용자가 직접 정의한 오버레이 네트워크

[목차 5-5-1]에서 오버레이 네트워크 드라이버를 활용하는 ingress 네트워크에 대해 알아보았다. 이번에는 ingress 네트워크를 사용하지 않고 사용자가 직접 생성해 만든 일명 '사용자 정의 오버레이 네트워크'를 사용해서 서로 다른 노드의 컨테이너들 간에 통신이 가능하도록 하는 방법에 대해 배워보자. 우선 스웜 모드는 자체적인 key-value 저장소를 갖고 있기 때문에 별도의 구성 없이 사용자 정의 오버레이 네트워크를 생성하고 사용할 수 있다고 한다. 기존에 배웠던 도커 네트워크를 생성하는 명령어와 -d 옵션을 사용해서 오버레이 네트워크를 아래처럼 생성할 수 있다.

 

$ docker network create \
--subnet 11.22.33.44/24 \
-d overlay \
zedd_overlay

 

참고로 오버레이 네트워크를 생성할 때는 스웜 클러스터 내의 어떤 노드에서도 생성하여도 다른 노드에 모두 적용이 된다. 그리고 생성한 오버레이 네트워크가 실질적으로 적용될 때는 해당 오버레이 네트워크가 적용된 서비스를 생성할 때 즉, 컨테이너가 생성될 때이다. 그러면 이제 방금 생성한 zedd_overlay 라는 이름의 사용자 정의 오버레이 네트워크가 적용된 서비스를 생성해보자. --network 옵션을 사용해서 생성한 오버레이 네트워크를 적용해주면 된다. 서비스 생성 시 사용할 이미지는 위 실습 때 사용한 것과 동일하다.

 

$ docker service create \
--network zedd_overlay \
--replicas 2 \
alicek106/book:hostname

 

 

위 명령어로 생성된 레플리카 컨테이너 중 하나에다가 ifconfig 명령어를 적용하여 그 컨테이너가 사용하는 네트워크 인터페이스들을 출력해보자. 출력된 화면 중 eth0 라는 이름의 네트워크 인터페이스를 보면 IP 주소(inet address 라고 되어있는 부분)를 보면 위에서 사용자 정의 오버레이 네트워크를 생성할 때 명시해준 subnet IP 주소가 입력된 것을 볼 수 있다.

 

그리고 위에서 사용자 정의 오버레이 네트워크를 적용해서 서비스를 생성할 때는 포트 포워딩을 하는 -p(--publish) 옵션을 사용하지 않은 것을 볼 수 있다. 이는 곧 ingress 네트워크를 사용하지 않도록 설정됨을 의미한다. 그래서 만약 ingress 네트워크를 사용하지 않고 사용자 정의한 오버레이 네트워크만을 사용하려고 한다면 위처럼 --network 옵션을 사용하되 -p 옵션을 명시해주지 않으면 된다.

5-6. 서비스 디스커버리(Discovery)

서비스 디스커버리란, 도커 스웜과 같은 컨테이너 오케스트레이션 툴을 사용할 때, 새로 생성된 컨테이너를 발견(Discovery)하거나 없어진 컨테이너를 자동으로 감지하는 것을 의미한다. 일반적으로 이러한 동작은 주키퍼나 etcd 등의 분산 코디네이터를 외부에 두고 사용해 해결하지만 스웜 모드는 자체적으로 서비스 디스커버리 기능을 지원한다. 예를 들어, Service A,B라는 2개의 서비스가 존재하고, A 서비스 안에서는 B 서비스를 참조하고 있다고 해보자. 

 

 

Service B 내에 새로운 컨테이너 1개가 추가로 생성되었다. 그렇다면 Service A에서는 새롭게 생성된 컨테이너를 어떻게 감지하고 Request를 요청할 수 있게 되는 걸까? Service A는 Service B의 어떤 컨테이너에도 접근이 가능하다. 그렇기 때문에 Service A는 새롭게 생성된 컨테이너가 Service B 내에 있는 컨테이너다 라는 것만 알면 된다. 이것이 가능한 이유는 스웜 모드의 서비스 발견이 오버레이 네트워크를 사용하는 서비스에 대해 동작하기 때문이다. 이를 실습을 통해서 알아보자. 아래처럼 server 라는 이름의 서버 역할을 하는 서비스와 client 라는 이름의 클라이언트 역할을 하는 서비스를 각각 생성하자.

 

$ docker service create \
--name server \
--network zedd_overlay \
--replicas 2 \
alicek106/book:hostname

$ docker service create \
--name client \
--network zedd_overlay \
alicek106/book:curl \
ping docker.com

 

그런 다음 client 서비스 내에 할당된 레플리카 컨테이너 내부로 들어간 뒤, 아래의 curl 명령어로 server 라는 이름의 도메인 네임으로 테스트를 해보자. 참고로 여기서 server 라는 도메인 네임은 위에서 생성한 서비스 이름을 의미한다.

 

$ curl server | grep -E "Hello"

 

위 명령어를 치면 HTML 형식의 Response가 반환되는데, 이 때 컨테이너 ID 값이 보일 것이다. 이 컨테이너는 바로 server 라는 이름의 서비스 내에 할당된 레플리카 컨테이너의 ID이다. 이제 그러면 server 이름의 서비스 레플리카 컨테이너를 2개에서 3개로 늘려보자. 명령어는 아래와 같다.

 

$ docker service scale server=3

 

그런 다음 다시 아까 내부로 들어갔던 client 서비스 내에 할당된 레플리카 컨테이너로 가서 curl 명령어로 다시 테스트를 몇 번 해보면 새롭게 생성된 컨테이너 ID가 반환되는 것을 볼 수 있다. 즉, 스웜 모드가 알아서 서비스 발견을 수행한 것이다.

 

그렇다면 server 라는 서비스 이름은 어떻게 각 컨테이너의 IP로 변환될 수 있었을까? 사실상 server 라는 서비스 이름은 (위 예시에서) 총 3개의 IP 주소를 갖는 것이 아닌 서비스 자체에 할당된 1개의 VIP(Virtual IP, 가상 IP 주소)를 가지게 되는 것이다. 이는 이전 포스팅에서 도커 브리지 네트워크를 배우면서 --net-alias 옵션에서 알아보았던 도커 내장 DNS 서버와 유사하다. 단, --net-alias 옵션을 사용할 때의 기능과 유사할 뿐 구체적인 동작 방식은 다르다고 한다.

 

참고로 서비스 자체에 할당된 VIP 주소가 무엇인지 알아보려면 해당 서비스의 구체적인 정보 중 'VirtualIPs' 라는 항목을 보면 알 수 있다.

5-7. 스웜 모드에서 볼륨 사용하기

도커 스웜을 비활성화한 모드 즉, 컨테이너를 단위로 제어할 때 볼륨을 사용할 때는 호스트 볼륨 공유나 자체적으로 생성한 볼륨을 사용하나 -v 옵션을 사용할 때 명령어 형식 상으로는 잘 구분이 안갔다.(잘 모른다면 이전 포스팅 참고)

 

하지만 스웜 모드에서는 호스트 볼륨 공유를 활용해서 볼륨을 사용할지, 자체적으로 생성한 도커 볼륨을 사용할지 좀 더 명확히 구분지어 정의해주어야 한다. 먼저 자체적으로 생성한 도커 볼륨을 사용할 때의 도커 스웜에 대해 알아보자.

 

도커 스웜에서 볼륨을 사용하려면 서비스를 생성할 때 적용해주어야 한다. --mount 옵션을 사용하는데, 아래와 같은 형식으로 정의해준다. 참고로 이전 포스팅에서 컨테이너 단위를 제어할 때의 볼륨을 사용할 때도 --mount 옵션을 사용한 명령어를 배웠었는데, 그 때의 형식이랑 똑같다.

 

$ docker serivce create \
--name zedd_service \
--mount type=volume,source=[생성한볼륨],target=[컨테이너 내부 디렉토리] \
ubuntu:14.04 \
ping.docker.com

 

만약 source 인자에 [생성한볼륨]을 명시해주지 않으면 알아서 16진수의 해쉬값을 이름으로 하는 볼륨을 자체적으로 생성해 할당한다. 위와 같이 명령어를 입력하게 되면 [컨테이너 내부 디렉토리]에 명시한 경로에 있는 데이터 파일들이 볼륨에 복사되고, 호스트에서는 해당 데이터 파일들을 차지하는 별도의 공간이 생긴다.

 

예를 들어서, 아래와 같이 ubuntu:14.04 이미지의 /etc/vim/ 이라는 디렉터리 경로를 볼륨할 경로로 결정했다고 하자. 아래 명령어를 활용해서 볼륨을 생성해보자.

 

$ docker service create \
--name zedd_ubuntu \
--mount type=volume,source=volume_for_test,target=/etc/vim \
ubuntu:14.04
ping docker.com

 

위처럼 서비스가 만들어지면서 볼륨이 생성되었을 것이다. 그러면 이제 이 볼륨을 사용하는 컨테이너를 생성하여 볼륨 대상인 /etc/vim 디렉토리에 있는 파일들이 잘 공유되는지 살펴보자. 아래 명령어로 간단한 컨테이너 1개를 생성하고 내부로 들어보자.

 

$ docker run -it --name volume_for_test_cont \
-v volume_for_test:/root \
ubuntu:14.04

 

내부로 들어가보면 root 디렉토리가 새롭게 생기고 그 안에 /etc/vim 안에 있는 vimrc, vimrc.tiny 라는 파일들이 공유되고 있을 것이다.

 

다음은 스웜 모드에서 호스트 볼륨을 공유하는 방법이다. 이를 bind 타입의 볼륨 생성이라고도 하는데, 여기서 bind가 방금 배운 --mount 옵션의 type 인자에 들어갈 키워드이다. 예시 명령어는 다음과 같다.

 

$ docker service create \
--name zedd_ubuntu \
--mount type=bind,source=[호스트 디렉토리],target=[컨테이너 내부 디렉토리] \
ubuntu:14.04
ping docker.com

 

스웜 모드에서의 볼륨 생성은 이와 같다. 하지만 스웜 모드에서의 볼륨은 아쉽게도 까다롭고 불편한 점이 많다. 왜냐하면 스웜 모드가 바로 여러 컨테이너들을 관리하는 것이기 때문이다. 예를 들어, 스웜 모드에서 총 10개의 컨테이너들을 관리해주고 있다고 하자. 그런데 이 10개의 컨테이너 각각 내부에 있는 데이터들이 삭제될까 두려워 호스트 볼륨 공유를 통해 호스트에 데이터를 이중으로 안전하게 잘 보관하고 싶다고 하자. 이런 상황에서 도커 스웜의 볼륨을 사용하려면 일단 스웜 클러스터를 구성하는 모든 노드가 볼륨으로 공유하는 데이터를 가지고 있어야 한다. 즉, 일일이 각 노드 내에 공유할 데이터의 볼륨을 명시해주어야 하는데, 이는 여간 까다로운 작업이 아니다.

 

그래서 보통은 스웜 모드에서 볼륨을 공유해야 하는 상황이라면 스웜 클러스터 내의 모든 노드에서도 접근이 가능한 퍼시스턴드(Persistent) 스토리지를 사용하는 것이다. 퍼시스턴트 스토리지란, 스웜 클러스터와는 별개로 외부에 존재하여 네트워크를 활용해서 스웜 클러스터 내의 컨테이너들과 마운트할 수 있는 스토리지를 의미한다.

 

출처: https://theworkaround.com/2019/05/15/docker-swarm-persistent-storage/

 

그런데 이러한 퍼시스턴트 스토리지는 도커에서 자체적으로 제공해주지 않는다. 그렇기 때문에 써드파티의 플러그인을 이용하거나 NFS(Network File System) 또는 DFS(Distributed File System)을 별도로 구성해야 한다.

5-8. 스웜 모드 노드 다루기

포스팅 앞 부분에서 스웜 모드에서의 노드를 생성하거나 삭제 또는 워커 노드에서 매니저노드로 업그레이드(promote) 하거나 매니저 노드에서 워커노드로 다운그레이드(demote)하는 방법에 대해서도 배웠었다. 그 이외에 스웜 모드는 자체적으로 노드를 다루는 전략을 세우기 위한 몇 가지 추가적인 기능을 제공한다.

5-8-1. 컨테이너를 할당 받을 수 있는 노드인지 결정하는 AVAILABILITY 변경

먼저 노드의 AVAIABILITY 항목은 해당 노드가 컨테이너를 할당 받을 수 있는 노드인지 나타내는 값이다. 이게 왜 필요한 걸까? 여러 개의 노드를 운영하다 보면 매니저 노드, 워커 노드에 따라 노드의 역할이 다양해질 수 있다. 일례로, 레플리카 컨테이너를 실질적으로 운영하는 노드는 매니저 노드 보다는 워커 노드일 것이다. 따라서 경우에 따라 매니저 노드에는 레플리카 컨테이너가 할당 되지 않도록 할 수도 있다. 다시 말해, AVAIABILITY 항목을 이용해서 특정 노드가 컨테이너를 할당 받을 수 있도록 할지 말지를 결정할 수 있다는 것이다.

 

생성한 스웜 클러스터 내에 존재하는 노드들의 리스트를 출력해보면 아래와 같이 나오며, 그 중에 AVAIABILITY 라는 항목이 있는 것을 볼 수 있다.

 

 

위 화면을 보면 현재 나머지 워커 노드가 있는 VM들을 꺼둔 상태라 STATUS가 DOWN으로 나오긴 하지만, AVAIABILITY 항목을 보면 모든 노드가 Active인 것을 알 수 있다. Active는 말 그대로 컨테이너를 할당 받을 수 있는 상태이다. 보통 노드가 생성되면 기본적으로 적용되는 값이다. 아래의 명령어 형식을 이용해 Active가 아닌 노드를 Active 상태로 변환할 수 있다.

 

$ docker node update \
--availability active \
[NODE NAME]

 

다른 종류의 STATUS로는 Drain이 있다. Drain 상태의 노드는 컨테이너를 할당하는 주체인 스웜 매니저의 스케쥴러가 컨테이너를 해당 노드로 할당하지 않게 된다. 그래서 보통 매니저 노드에 Drain 상태로 설정하는 경우가 많다. 또한 특정 노드에 문제가 생겼을 경우에 문제가 생긴 노드에 컨테이너를 할당하지 못하도록 하기 위해서도 이용할 때가 있다.

 

그리고 해당 노드가 이미 실행시키고 있던 컨테이너들은 즉시 중지된다. 예를 들어, 어떤 노드가 Drain 상태로 변하기 이전의 Active 상태일 때 할당받고 있던 컨테이너가 몇 개 있다고 하자. 이럴 경우에 해당 노드를 Drain 상태로 바꾸게 되면 해당 노드에 할당받은 컨테이너는 전부 중지된 후, 스웜 클러스터 내의 Active 상태의 노드로 할당된다. 참고로 Drain 시켜놓은 노드를 다시 Active로 변경한다고 한들 Drain 상태일 때 다른 노드로 할당되었던 컨테이너가 다시 생기는 즉, 컨테이너를 Re-balancing 작업을 해주진 않는다. 만약 하려고 한다면 사용자가 직접 docker service scale ~ 명령어로 적용해주어야 한다.

 

Drain 상태로 변경하는 명령어 형식은 아래와 같다. --availability 항목만 변경해주면 된다.

 

$ docker node update \
--availability drain \
[NODE NAME]

 

다음의 STATUS 종류로는 Pause가 있다. Pause 상태는 해당 노드가 더 이상 컨테이너를 할당받지 않는다는 것이다. 이렇게만 보면 Drain 상태와 똑같아 보이지만 분명한 차이점이 있다. Drain 상태는 할당받았던 실행중인 컨테이너가 중지되지만 Pause는 중지되지 않고 여전히 컨테이너를 실행한다. 그래서 Pause는 "지금까지 할당받은 컨테이너들만 실행할거야. 더 추가할 컨테이너들은 다른 노드에다가 줘" 인 셈이다.

5-8-2. 노드에게 이름표를 붙여 분류하자, --lablel-add 옵션

이전의 도커 이미지 다루기 포스팅에서 이미지에 라벨을 붙일 수 있었다. 똑같이 노드에서도 라벨을 붙여 그 노드가 어떤 의미를 갖는 노드인지 사용자가 직접 노드를 분류해 정리할 수 있다. 이미지 때와 마찬가지로 라벨은 <key>=<value> 형태를 지닌다. 만약 노드에 라벨을 붙인다면 서비스를 생성하면서 할당할 레플리카 컨테이너들을 원하는 라벨을 갖는 노드에만 할당하는 것이 가능해진다. 

 

노드에 라벨을 추가하는 것은 --label-add 옵션을 사용할 수 있다. 예를 들어서, 아래와 같이 워커 노드에 라벨을 부여해보자.

 

$ docker node update \
--label-add username=zedd \
swarm-worker1

 

그리고 inspect 명령어로 해당 노드의 상세 정보를 살펴보면 아래처럼 Labels 항목에 방금 정의한 라벨이 생성되었음을 확인할 수 있다.

 

5-8-3. 서비스 제약을 설정해 특정 노드에만 컨테이너를 할당하도록 하자, --constraint 옵션

다음은 스웜 클러스터에 서비스를 생성할 때 제약(Constraint)을 설정하여 서비스의 컨테이너가 할당될 노드만을 선택할 수도 있다. 특정 노드 ID나 노드의 호스트 이름, 도커 데몬의 라벨, (직전에 배운) 노드의 라벨 등으로 다양한 제약 조건을 설정할 수도 있다.

 

우선 직전에 배운 노드에 붙혀진 라벨을 기준으로 제약을 설정해보자. 아래와 같은 명령어 형식으로 적용할 수 있다. 붙인 라벨은 위에서 정의한 username=zedd 라고 가정해보자.

 

$ docker service create \
--name node_label_constraint \
--replicas 5 \
--constraint 'node.labels.username == zedd' \
ubuntu:14.04 \
ping docker.com

 

특이한 것은 제약을 설정할 때 동일한지 아닌지를 의미하는 논리 연산자가 Python처럼 == 와 != 를 사용하는 것이다. 그리고 만약 위와 같이 설정한 제약조건을 만족하는 노드를 찾지 못할 경우 서비스의 컨테이너는 생성되지 않는다.

 

다음은 노드의 ID로 제약조건을 거는 것이다. 여기서 하나 주의할 점이 있다.기존에 도커 엔진은 이미지 ID나 컨테이너 ID 등과 같이 ID 값들이 긴 해쉬값으로 되어 있으면 앞의 몇자리만 입력해도 도커 엔진이 알아서 잘 찾아주었다. 하지만 제약조건을 걸어줄 때 만큼은 노드 ID를 입력해줄 때 반드시 긴 해쉬값 전부를 입력해주어야 한다. 명령어 예시는 다음과 같다.

 

$ docker service create \
--constraint 'node.id == MIIBajCCARCgAwIBAgIUW3RulxTWTziz' \
--replicas 5
ubuntu:14.04 \
ping docker.com

 

다음은 노드의 호스트 이름과 노드의 역할을 기준으로 세우는 제약 조건이다. 우선 호스트 이름은 그야말로 노드 VM의 호스트 이름이다. 지금까지 해온 실습을 기준으로 한다면 swarm-manager, swarm-worker1, swarm-worker2 라 호스트 이름이 되겠다. 다음은 노드의 역할인데, 역할이라 함은 매니저 노드인지 워커 노드인지이다. 매니저 노드이면 manager를 워커 노드이면 worker를 키워드로 쓰면 된다. 명령어 예시는 아래와 같다.

 

$ docker service create \
--constraint 'node.hostname == swarm-worker1' \
--replicas 3 \
ubuntu:14.04 \
ping docker.com

$ docker service create \
--constraint 'node.role != manager' \
--replicas 3 \
ubuntu:14.04 \
ping docker.com

 

마지막으로 도커 데몬 자체에 설정된 라벨을 기준으로 하는 제한 조건이다. 도커 데몬에 라벨을 붙여주려면 도커 데몬의 실행 옵션을 변경해야 한다. 참고로 이미 도커 데몬에 설정된 라벨을 확인하고 싶다면 docker info 명령어의 Labels 항목으로 확인이 가능하다. 예시는 아래와 같다.

 

$ docker service create \
--constraint 'engine.labels.[key] == [value] \
--replicas 2 \
ubuntu:14.04 \
ping docker.com

 

그리고 지금까지 소개한 여러 제약 조건들을 서로 섞어 동시에(AND 조건 처럼) 사용할 수도 있다. 이렇게 여러가지 제약 조건을 활용하면 어떤 노드들은 어떤 목적을 위해 사용할지 등 노드를 다루는 전략을 세울 수가 있다.

---

지금까지 긴.. 여정인 도커 스웜에 대해 알아보았다. 다음 포스팅에서는 드디어 도커의 마지막 부분인 도커 컴포즈(Compose)에 대해 다룬다. 도커의 마지막 목차로 달려나가보자.