[도커] 스웜모드 & 스웜모드의서비스 장애 복구 & 서비스 컨테이너에 설정 정보 전달(secret,config) & 도커 스웜 네트워크 & 서비스 디스커버리

1. 스웜모드 서비스

도커 vs 스웜 모드

도커 명령어의 제어 단위 >> 컨테니어

스웜모드 명령어의 제어 단위 >> 서비스

 

 

서비스 

같은 이미지에서 생성된 컨테이너의 집합

서비스를 제어하면 래당 서비스 내의 컨테이너에 같은 명령이 실행됨

서비스 내에 컨테이너는 한 개 이상 존재할 수 있으며, 컨테이너들은 각 워커 노트와 매니저 노드에 할당됨

 

각 노드에 할당된 컨테이너들을 태스트(task)라고 함

 

#1 서비스 생성

root@swarm-manager:~# docker service create ubuntu:14.04 bin/sh -c "while
o echo hello world; sleep 1; done"
ino0zze9ppiltcngzhune9cw1
overall progress: 1 out of 1 tasks
1/1: running
verify: Service converged

 

#2 서비스 조회

root@swarm-manager:~# docker service ls
ID                  NAME                MODE                REPLICAS IMAGE               PORTS
ino0zze9ppil        sad_diffie          replicated          1/1      ubuntu:14.04

 

#3 서비스 상세 정보 조회

root@swarm-manager:~# docker service ps ino0zze9ppil
ID                  NAME                IMAGE               NODE ESIRED     STATE       CURRENT STATE         ERROR     PORTS
8npprhtqavnr        sad_diffie.1        ubuntu:14.04        swarm-manager   running     Running 55 seconds ago

 

#4 서비스 삭제

root@swarm-manager:~# docker service rm ino0zze9ppil
ino0zze9ppil
root@swarm-manager:~# docker service ls
ID         NAME          MODE         REPLICAS       IMAGE          PORTS

 

#5 nginx 웹 서버 서비스 생성

root@swarm-manager:~# docker service create --name myweb --replicas 2 -p
inxu5ybd66fhwgs2qfyw6rqlpjp4
overall progress: 2 out of 2 tasks
1/2: running
2/2: running
verify: Service converged

root@swarm-manager:~# docker service ps myweb
ID                  NAME                IMAGE               NODE           DESIRED STATE       CURRENT STATE            ERROR               PORTS
jgifl9yggb2n        myweb.1             nginx:latest        swarm-manager  running             Running 43 seconds ago
x9bc2aw4f01t        myweb.2             nginx:latest        swarm-worker1  running             Running 39 seconds ago

- NODE --> 컨테이너가 할당된 노드의 위치

 

 

#6 스웜 클러스터 내의 어떤 노드로 접근해도 서비스에 접근이 가능

nginx 컨테이너가 없는 노드로 접근해도 서비스에 접근할 수 있음

 

swarm-manager node -> http://192.168.xxx.100 

swarm-worker1 node -> http://192.168.xxx.101

swarm-worker2 node -> http://192.168.xxx.102 

 

 

#7 레플리카셋 추가

 

컨테이너 수를 늘린 뒤 서비스 내의 컨테이너 목록 확인

 

root@swarm-manager:~# docker service scale myweb=4 
myweb scaled to 4 
overall progress: 4 out of 4 tasks 
1/4: running 
2/4: running 
3/4: running 
4/4: running 
verify: Service converged 

root@swarm-manager:~# docker service ps myweb 
ID                NAME                IMAGE               NODE           DESIRED STATE       CURRENT STATE            ERROR               PORTS 
jgifl9yggb2n      myweb.1             nginx:latest        swarm-manager  running             Running 2 minutes ago 
x9bc2aw4f01t      myweb.2             nginx:latest        swarm-worker1  running             Running 2 minutes ago 
fmpr1wegsjvz      myweb.3             nginx:latest        swarm-worker2  running             Running 49 seconds ago 
y24x7aoflzah      myweb.4             nginx:latest        swarm-worker2  running             Running 51 seconds ago

 

서비스 모드

1) 복제(replicated) 모드

- 레플리카 셋의 수를 정의해 그만큼의 같은 컨테이너를 생성

- 실제 서비스 제공에 일반적으로 사용하는 모드

 

2) 글로벌(global) 모드

- 스웜 클러스터 내에서 사용할 수 있는 모든 노드에 컨테이너를 반드시 하나씩 생성

- 레플리카 셋의 수를 별도로 지정하지 않음

- 스웜 클러스터를 모니터링 하기 위한 에이전트 컨테이너 등을 생성해야할 때 유용

- docker service create --mode global 명령으로 생성

 

글로벌 모드 서비스 생성 및 확인

root@swarm-manager:~# docker service create --name global_web --mode glob
mhktv0h7gqcai3f1i3ni6fa1x
overall progress: 3 out of 3 tasks
v28z2jx9qbie: running
5rcn5syugyub: running
cg65udxjx418: running
verify: Service converged


root@swarm-manager:~# docker service ls
ID                  NAME                MODE                REPLICAS   IMAGE               PORTS
mhktv0h7gqca        global_web          global              3/3        nginx:latest
u5ybd66fhwgs        myweb               replicated          4/4        nginx:latest        *:80->80/tcp


root@swarm-manager:~# docker service ps global_web
ID                  NAME                                   IMAGE          MODE                DESIRED STATE       CURRENT STATE            ERROR       PORTS
1w74c5d7ipmi        global_web.v28z2jx9qbie9pz4egbluhxxf   nginx:latest   swarm-manager       Running             Running 40 seconds ago

hzk58wy1b3g5        global_web.5rcn5syugyubin6tymlnhwo23   nginx:latest   swarm-worker2       Running             Running 41 seconds ago

udpsjlpstiea        global_web.cg65udxjx418ljekgeff71axu   nginx:latest   swarm-worker1       Running             Running 41 seconds ago

 

 

1. 스웜모드 서비스

2. 스웜모드의 서비스 장애 복구

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

 

#1 특정노드에서 myweb서비스에 속한 컨테이너를 삭제하면 자동으로 다시 생성되는 것을 확인

 

#1-1 swarm-manager노드에서 실행중인 컨테이너 목록 확인

 

 

#1-2 swarm-manager노드에서 실행중인 컨테이너 강제로 삭제

 

#1-3 myservice 서비스의 태스크(task)확인 -> 새로운 태스크가 생성된 것을 확인

 

 

 

#2 특정 노드가 다운되면 해당 노드의 컨테이너가 종료되고 다른 노드에 컨테이너가 생성되는 것을 확인

 

#2-1 swarm-worker1 노드의 도커 데몬 프로세스를 종료

 

#2-2 매니저 노드(swarm-manager)에서 노드 상태 확인 --> swarm-worker1노드가 다운 상태

 

#2-3 매니저 노드에서 myservice서비스의 태스크 상태 확인 --> 실행중인 다른 노드에서 태스크가 생성되었음

 

#3 다운되었던 노드를 재시작해도 재균형(rebalance)작업은 자동으로 일어나지 않음

 

#3-1 다운되었던 swarm-worker1노드를 재시작

 

#3-2 매니저 노드에서 노드 상태 확인 --> swarm-worker1 노드가 Active상태

 

#3-3 매니저 노드에서 myservice 서비스의 태스크 상태 확인 --> 여전히 myweb.2태스크가 swarm-manager노드에서 실행 중

 

 

#3-4 docker service scale 명령으로 컨테이너 수를 줄이고 다시 늘리는 방식으로 서비스의 컨테이너 할당의 균형을 맞춤

 

 

 

#4 서비스 롤링 업데이트 (스웜 모드에서 자체적으로 지원)

 

#4-1 서비스 생성

 

#4-2 docker service update 명령으로 생성된 서비스의 설정 변경

 

 

#4-3 서비스를 생성할 롤링 업데이트 설정 가능

 

롤링 업데이트 주기, 업데이트를 동시에 진행할 컨테이너 개수, 업데이트에 실패했을 때 어떻게 할 것인지를 설정

 

 

 

#4-4 서비스의 롤링 업데이트 설정 확인

 

#4-5 롤링 업데이트 중 오류가 발생해도 계속 롤링 업데이트를 진행하도록 설정

#4-6 서비스를 롤링 업데이트 이전으로 되돌리는 롤백

 

 

 

 

교재 121 페이지에 나와 있는 Visualizer 를 이용하면 스웜 클러스터의 컨테이너 배치 상태를 시각화할 수 있습니다. 

https://hub.docker.com/r/dockersamples/visualizer

 

vagrant@swarm-manager:~$ docker service create \

>   --name=viz \

>   --publish=8080:8080/tcp \

>   --constraint=node.role==manager \

>   --mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \

>   dockersamples/visualizer

emrk6zvniul9apwwjoerdvjmj

overall progress: 1 out of 1 tasks

1/1: running   [==================================================>]

verify: Service converged

 

3. 서비스 컨테이너에 설정 정보 전달

컨테이너에 설정 정보 전달

 

방법1. -v옵션을 통해 호스트에 위치한 설정 파일이나 값을 볼륨으로 공유

방법2. -e 옵션을 통해 환경 변수로 전달

 

스웜모드는 secret과 config기능을 제공

• 스웜보드와 같은 서버 클러스터에서 파일 공유를 위해 설정 파일을 호스트마다 마련해두는 것은 매우 비효율적
• 비밀번호와 같이 민감한 정보를 환경변수로 설정하는 것은 보안상 바람직하지 않음
• 스웜보드에서 사용할 수 있는 secret, config기능을 제공
• secret => 비밀번호, SSH키, 인증서 키와 같은 보안에 민감한 데이터를 전송하기 위한 용도
• config => nginx나 레지스트리 설정 파일과 같이 암호화할 필요가 없는 설정값들에 사용

 

#1 secret 사용하기

#1-1 secret생성

• 생성된 secret는 조회해도 실제 값을 확인할 수 없음
• secret값은 매니저 노드 간에 암호화된 상태로 저장

#1-2 생성한 secret을 통해 MySQL 컨테이너 생성

• --secret옵션을 통해 컨테이너로 공유된 값은 기본적으로 컨테이너 내부에 /run/secrets/ 디렉터리에 마운트됨
• --secret source=my_mysql_password,target=/home/mysql_root_password 처럼 마운트될 디렉터리 지정도 가능

 

#2 config 사용하기

#2-1 사설 레지스트리 설정 파일 생성

 

#2-2 설정 파일로 config 생성

#2-3 config 생성 확인

 

#2-4 config는 입력된 값을 BASE64로 인코딩해서 저장

 

#2-5 BASE64로 디코딩해서 입력된 값 확인

 

 

#2-6 config로 사설 레지스트리 생성

 

BASE64 인코딩

       ~~~~~~

       일정한 규칙에 따라 데이터를 다른 형태로 변형

 

0~63 → 영문자(대문자, 소문자), 숫자, +, / 글자로 변경

~~~~ 6비트

4. 도커 스웜 네트워크 

#1 매니저 노드에서 네트워크 목록 확인

 

#2 ingress 네트워크

- 스웜 클러스터를 생성하면 자동으로 등록되는 네트워크

- 스웜 모드를 사용할 때만 유효

- 스웜 클러스터에 등록된 모든 노드에 ingress 네트워크가 생성

 

ingress 네트워크는 어떤 스웜 노드에 접근하더라도 서비스 내의 컨테이너에 접근할 수 있게 설정하는 라우팅 메시를 구성하고, 서비스 내의 컨테이너에 대한 접근을 라운드 로빈 방식으로 분산하는 로드밸런딩을 담당

 

#2-1 임의로 할당된 16진수를 출력하는 PHP파일이 들어있는 웹서버 이미지로 서비스 생성

#2-2 생성된 컨테이너 목록 확인 --> replicas를 4로 설정했으므로 4개의 컨테이너가 생성

 

#2-3 각 노드 주소로 접근 --> 접속하는 노드에 존재하지 않는 컨테이너 이름도 출력되고, 요청을 반복하며 실행중인 컨테이너가 돌아가면서 응답하는 것을 확인

http://192.168.xxx.100:8000 

 

http://192.168.xxx.100:8000

 

http://192.168.xxx.100:8000

 

 

#2-4 ingress 네트워크를 사용하지 않고 호스트의 8080 포트를 직접 컨테이너의 80포트로 연결하는 방법

 

=> 어느 호스트에서 컨테이너가 생성될지 알 수 없어 포트 및 서비스 관리가 어렵다는 단점이 있음

=> 가급적이면 ingress 네트워크를 사용해 외부로 서비스를 노출하는 것이 좋음

 

 

#3 오버레이 네트워크

오버레이 네트워크는 여러 개의 도커 데몬을 하나의 네트워크 풀로 만드는 네트워크 가상화 기술의 하나로, 도커에 오버레이 네트워크를 적용하면 여러 도커 데몬에 존재하는 컨테이너가 서로 통작할 수 있음

 

여러 개의 스웜 노드에 할당된 컨테이너는 오버레이 네트워크의 서브넷에 해당하는 IP 대역을 할당받고 이 IP를 통해 서로 통신

 

#3-1  스웜 클러스터 내의 컨테이너가 할당받은 IP 주소 확인

--> eth0: ingress 네트워크와 연결된 NIC

--> ingress 네트워크는 오버레이 네트워크 드라이버를 사용

 

 

#3-2 별도의 포트포워딩을 설정하지 않아도 컨테이너 간 전송이 가능

 

 

#4 docker_gwbridge 네트워크

오버레이 네트워크를 사용하지 않는 컨테이너는 기본적으로 존재하는 브리지(bridge) 네트워크를 사용해 외부와 연결

 

그러나, ingress를 포함한 모든 오버레이 네트워크는 브리지 네트워크와 다른 docker_gwbridge네트워크와 함께 사용됨

 

docker_gwbridge네트워크는 외부로 나가는 통신 및 오버레이 네트워크의 트래픽 종단점(VTEP)역할을 담당

 

docker_gwbridge네트워크는 컨테이너 내부의 네트워크 인터페이스 카드 중 ech1과 연결

 

 

#5 사용자 정의 오버레이 네트워크

#5-1 사용자 정의 오버레이 네트워크 생성

 

#5-2 생성한 오버레이 네트워크 확인

#5-3 오버레이 네트워크를 서비스에 적용(--network 옵션 이용)해 컨테이너 생성

 

#5-4 생성된 컨테이너에 할당된 오버레이 네트워크 IP주소 확인(eth0)

 

 

5. 서비스 디스커버리

 

같은 컨테이너를 여러 개 만들어 사용할 때 새로 생성된 컨테이너 발견(Service Descovery) 혹은 없어진 컨테이너 감지가 중요

 

일반적으로 주키퍼, etcd등의 분산 코디네이터를 외부에 두고 사용해서 해결하지만 스웜 모드는 서비스 발견 기능을 자체적으로 지원

 

스웜 모드에서는 서비스 이름으로 해당 서비스의 모든 컨테이너에 접근이 가능 => 서비스의 컨테이너 IP주소를 알 필요도 없고 새롭게 생성된 사실을 알 필요 없음

 

 

#1 예제 서비스에서 사용할 오버레이 네트워크 생성

 

 

#2 server 서비스 생성 - 컨테이너의 호스트 이름을 출력하는 웹서버 컨테이너 2개를 생성

 

#3 client 서비스 생성 - server 서비스에 http요청을 보낼 컨테이너를 생성

 

#4 client 서비스 컨테이너 실행 노드 확인

 

#5 client 서비스 컨테이너가 생성된 노드에서 컨테이너 ID확인 후 컨테이너 내부로 진입

 

#6 컨테이너 내부에서 curl명령으로 server 서비스에 접근

 

-> 오버레이 네트워크에 속하도록 서비스를 생성했다면 도커 스웜의 DNS가 이를 자동으로 변환(resolve)

-> 요청을 보내래 때 마다 다른 컨테이너에 접근하는 것을 확인

-> server라는 호스트 이름을 자동으로 server서비스의 컨테이너 IP중 하나로 라운드 로빈 방식으로 변환

 

#7 swarm-manager노드에서 server서비스의 컨테이너 레플리카 수를 3개로 늘림

 

#8 #6과 같이 컨테이너 내부에서 curl 명령으로 server서비스로 접근하면 새롭게 생성된 컨테이너에 접근할 수 있음

 

#9 server서비스의 VIP확인

 

-> server라는 호스트 이름이 3개의 IP를 가지고 있는 것이 아니라 서비스의 VIP(Virtual IP)를 가지고 있음

-> 스웜 모드가 활성화된 도커 엔진의 내장 DNS서버는 server라는 호스트 이름을 10.0.1.2 라는 IP로 변환

-> 컨테이너의 네트워크 네임스페이스 내부에서 실제 server서비스의 컨테이너의 IP로 포워딩

 

#10 VIP방식이 아닌 도커의 내장 DNS 서버 기반으로 라운드 로빈 적용

--> 애플리케이션에 따라 캐시 문제로 인해 서비스 발견이 정상적으로 작동하지 않을 때가 있으므로 가급적 VIP를 사용

 

 

 

 

6. 스웜 모드 볼륨 

도커 데몬 명령어 중 run명령어에서 -v옵션을 사용할 때는 호스트와 디렉터리를 공유하는 경우와 볼륨을 사용하는 경우에 대한 구분이 없음

 

스웜 모드에서는 서비스를 생성할 때 도커 볼륨을 사용할지, 호스트와 디렉터리를 공유할지를 명확하게 명시

 

volume 타입의 볼륨 생성

--> --mount 옵션의  type값에 volume을 지정 => 도커 볼륨을 사용하는 서비스를 생성
--> source => 사용할 볼륨(도커 데몬에 해당 볼륨이 존재하면 해당 볼륨을 사용하고 없으면 새로 생성)

--> target => 컨테이너 내부에 마운트될 디렉터리 위치

 

source옵션을 명시하지 않으면 임으의 16진수로 구성된 익명의 이름을 가진 볼륨을 생성

 

서비스의 컨테이너에서 볼륨에 공유할 컨테이너의 디렉터리에 파일이 이미 존재하면 이 파일들은 볼륨에 복사되고, 호스트에서 별도의 공간을 차지하게 됨

 

생성된 서비스, 컨테이너, 볼륨 삭제

 

서비스를 생성할 볼륨 옵션에 volume-nocopy를 추가하면 컨테이너의 파일들이 볼륨에 복사되지 않음

 

bind 타입의 볼륨 생성

바인드 타입은 호스트와 디렉터리를 공유할 때 사용

type옵션의 값을 bind로 설정

볼륨 타입과 달리 공유될 호스트의 디렉터리를 설정해야 하므로 source옵션을 반드시 명시해야 함

 

호스트의 /root/host 디렉터리를 서비스 컨테이너의 /root/container 디렉터리에 마운트

 

스웜보드에서 볼륨의 한계점

서비스를 할당받을 수 있는 모든 노드가 볼륨 데이터를 가지고 있어야 하므로 스웜 클러스터에서 볼륨을 사용하는 것은 어려움

 

=> 로컬 볼륨이 존재하지 않는 노드에는 컨테이너가 할당될 수 없음

 

일반적인 해법은 어느 노드에서도 접근 가능한 퍼시스턴스 스토리지(Persistence Storage)를 사용하는 것

 

퍼시스턴트 스토리지

=> 호스트와 컨테이너와 별개로 외부에 존재해 네트워크로 마운트할 수 있는 스토리지

=> 도커 자체가 제공하지 않으므로 서드파티 플러그인을 사용하거나 nfs, dfs 등을 별도로 구성해야 함

 

 

 

vagrant@swarm-manager:~$ docker service rm $(docker service ls -q)

vagrant@swarm-manager:~$ docker container rm -f $(docker container ls -aq) ⇐ 모든 노드에서 수행

vagrant@swarm-manager:~$ docker volume rm $(docker volume ls --format {{.Name}}) ⇐ 모든 노드에서 수행

 

 

7. 도커 스웜 모드 노드 다루기

마스터 노드는 최대한 부하를 받지 않도록 서비스를 할당받지 않게 하거나, 문제가 발생한 특정 노드를 유지보수할 때 해당 노드에 컨테이너를 할당하지 않게 만들고 싶을 때 등 docker node update --availability 명령으로 노드의 상태를 변경할 수 있음

 

구축한 스웜 클러스터의 노드 상태 확인

 

Active 상태 

$ docker node update --availability active node_name

새로운 노드가 스웜 클러스터에 추가되면 기본적으로 설정되는 상태

노드가 서비스의 컨테이너를 할당받을 수 있음을 의미

 

Drain 상태

$ docker node update --availability drain node_name

스웜 매니저의 스케줄러는 컨테이너를 해당 노드에 할당하지 않음

일반적으로 매니저 노드 또는 노드에 문제가 생겨 일시적으로 사용하지 않는 상태로 설정할 때 사용

 

노드를 Drain상태로 변경하면 해당 노드에서 실행 중이던 서비스의 컨테이너는 전부 중지되고 Active상태의 노드로 다시 할당됨

 

Drain상태의 노드를 Active상태로 다시 변경한다고 해서 서비스의 컨테이너가 다시 분산되어 할당되지는 않으므로 docker service scale 명령어를 사용해 컨테이너의 균형을 재조정해야함

 

 

Pause 상태

$ docker node update --availability pause node_name

서비스의 컨테이너를 더는 할당받지 않는다는 점에서 Drain과 같지만 실행 중인 컨테이너가 중지되지 않는다는 점에서 다름

 

노드 라벨 추가

특정 노드에 라벨을 추가하면 서비스를 할당할 때 컨테이너를 생성할 노드의 그룹을 선택하는 것이 가능

 

docker node update --label-add 옵션을 사용해 라벨을 설정

 

 

서비스 제약 설정

docker service create 명령어에 --constraint옵션을 추가해 서비스의 컨테이너가 할당될 노드의 종류를 선택할 수 있음

 

 

#1 node.labels 제약조건

 

storage키의 값이 ssd로 설정된 노드에 서비스의 컨테이너를 할당하도록 제한

=> storage 라벨이 ssd로 설정된 swarm-worker1 노드에만 컨테이너가 생성되었음

=> 제약 조건을 만족하는 노드를 찾지 못할 경우 서비스의 컨테이너는 생성되지 않음

 

 

#2 node.id 제약조건

 

노드 ID를 명시해 서비스의 컨테이너를 할당할 노드를 선택

 

다른 도커 명령어와 달리 docker node ls 명령어에 출력된 ID를 전부 입력해야 함

 

 

#3 node.hostname과 node.role 제약조건

 

스웜 클러스트에 등록된 호스트 이름 및 역할로 제한 조건을 설정

 

 

#4 engine.labels 제약조건

 

도커 엔진, 즉 도커 데몬 자체에 라벨을 설정해 제한 조건을 설정(도커 데몬 실행 옵션을 변경해야 함)

 

 

 

 

### 노드의 상태를 확인

vagrant@swarm-manager:~$ docker node ls

ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION

wn5j8nymx704prelscdq8fw54 *   swarm-manager       Ready               Active              Leader              19.03.6

i2boml3wjv87wjv35mpi0okgt     swarm-worker1       Ready               Active                                  19.03.6

repfyu4iazgigfjed6hvvz63i     swarm-worker2       Ready               Active                                  19.03.6

 

### swarm-worker2 노드를 Drain 상태로 변경

vagrant@swarm-manager:~$ docker node update --availability drain swarm-worker2

swarm-worker2

 

### swarm-worker2 노드가 Drain 상태인 것을 확인

vagrant@swarm-manager:~$ docker node ls

ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION

wn5j8nymx704prelscdq8fw54 *   swarm-manager       Ready               Active              Leader              19.03.6

i2boml3wjv87wjv35mpi0okgt     swarm-worker1       Ready               Active                                  19.03.6

repfyu4iazgigfjed6hvvz63i     swarm-worker2       Ready               Drain                                   19.03.6

 

### nginx 서비스를 생성 (5개의 컨테이너를 기동)

vagrant@swarm-manager:~$ docker service create --name nginx --replicas 5 nginx

8ea3yhrleozvp86dmox67uiy2

overall progress: 5 out of 5 tasks

1/5: running

2/5: running

3/5: running

4/5: running

5/5: running

verify: Service converged

 

### 서비스 생성 여부 확인

vagrant@swarm-manager:~$ docker service ls

ID                  NAME                MODE                REPLICAS            IMAGE               PORTS

8ea3yhrleozv        nginx               replicated          5/5                 nginx:latest

b6a9hd7z886s        ubuntu              replicated          1/1                 ubuntu:14.04

 

### 서비스 실행 노드를 확인 (worker2는 빠져가 있음)

vagrant@swarm-manager:~$ docker service ps nginx

ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS

iitha8j1mcn1        nginx.1             nginx:latest        swarm-worker1       Running             Running 27 seconds ago

sbj2bo45kqxs        nginx.2             nginx:latest        swarm-worker1       Running             Running 27 seconds ago

0dfoouoik06k        nginx.3             nginx:latest        swarm-manager       Running             Running 27 seconds ago

oqk0mx61mpnq        nginx.4             nginx:latest        swarm-manager       Running             Running 27 seconds ago

u7bp6unfc9hg        nginx.5             nginx:latest        swarm-worker1       Running             Running 27 seconds ago

 

### swarm-worker2 노드를 Active 상태로 전환

vagrant@swarm-manager:~$ docker node update --availability active swarm-worker2

swarm-worker2

 

### swarm-worker2 노드가 Active된 것을 확인

vagrant@swarm-manager:~$ docker node ls

ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION

wn5j8nymx704prelscdq8fw54 *   swarm-manager       Ready               Active              Leader              19.03.6

i2boml3wjv87wjv35mpi0okgt     swarm-worker1       Ready               Active                                  19.03.6

repfyu4iazgigfjed6hvvz63i     swarm-worker2       Ready               Active                                  19.03.6

 

### swarm-worker2 노드가 활성화되어도 nignx 서비스가 re-balance(재할당, 재배치)되지 않은 것을 확인

vagrant@swarm-manager:~$ docker service ps nginx

ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE           ERROR               PORTS

iitha8j1mcn1        nginx.1             nginx:latest        swarm-worker1       Running             Running 4 minutes ago

sbj2bo45kqxs        nginx.2             nginx:latest        swarm-worker1       Running             Running 4 minutes ago

0dfoouoik06k        nginx.3             nginx:latest        swarm-manager       Running             Running 4 minutes ago

oqk0mx61mpnq        nginx.4             nginx:latest        swarm-manager       Running             Running 4 minutes ago

u7bp6unfc9hg        nginx.5             nginx:latest        swarm-worker1       Running             Running 4 minutes ago

 

### 스케일 다운

vagrant@swarm-manager:~$ docker service scale nginx=1

nginx scaled to 1

overall progress: 1 out of 1 tasks

1/1: running

verify: Service converged

 

### 남아있는 컨테이너를 확인

vagrant@swarm-manager:~$ docker service ps nginx

ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE           ERROR               PORTS

iitha8j1mcn1        nginx.1             nginx:latest        swarm-worker1       Running             Running 5 minutes ago

 

### 스케일 업

vagrant@swarm-manager:~$ docker service scale nginx=5

nginx scaled to 5

overall progress: 5 out of 5 tasks

1/5: running

2/5: running

3/5: running

4/5: running

5/5: running

verify: Service converged

 

### Active 상태인 노드에 컨테이너가 골고루 배치된 것을 확인

vagrant@swarm-manager:~$ docker service ps nginx

ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS

iitha8j1mcn1        nginx.1             nginx:latest        swarm-worker1       Running             Running 5 minutes ago

3jtzfabrqixn        nginx.2             nginx:latest        swarm-manager       Running             Running 11 seconds ago

8d729he3n5hs        nginx.3             nginx:latest        swarm-worker1       Running             Running 11 seconds ago

vpg5moj4s1uh        nginx.4             nginx:latest        swarm-worker2       Running             Running 11 seconds ago

ohhpesotjz0l        nginx.5             nginx:latest        swarm-worker2       Running             Running 10 seconds ago

 

---

 

토커 컴포스 : 하나의 컨테이너에서 쉽게 조작할 떄 쓰는것
(연관성 있는것들 띄울때)
dind : docker in docker 도커안에서 도커를 띄우는 개념
pods : 컨테이너를 묶어줌. 여러개의 컨테이너를 연관이 있는 
컨테이너들끼리. 혼자서 서비스 하는게 아닌 동작할 때
항상 같이 엮여야 하는것. 워드프레스 + 디비같이
쿠퍼네티스는 pods로 관리되는거지 컨테이너단위로 관리되는게 아님
컨테이너가 하나여도 pods라고 함

 

 

컴포즈 : 하나의 노드에서 여러개의 컨테이너를 쉽게 조작할때

일반적으로 연관성있는 컨테이너 동시에 띄울때

==> 단일 노드 : 하나의 머신에서 여러개의 컨테이너 연결



dind : docker in docker 

컨테이너 안에서 컨테이너를 띄운다



pod: 여러개 컨테이너를 묶어서 감싸는 느낌?

kubenetes에서 쓰는 개념

컨테이너와 개념 동일한데

연관이 있는 컨테이너를 연합시키기 위해서 사용

===> 마지막 예제를 보고 왜 포드를 사용해야하는지

===> 여러개의 노드에서 사용가능 :  여러 머신에서 여러 컨테이너를 연결



wordpress 이용하려면 db랑 연동해야 한다

ip 주소 넣어서 하면 복잡해진다... => 포드로 연결