Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

 

docker swarm

한글 문서

https://subicura.com/2017/02/25/container-orchestration-with-docker-swarm.html 

소스코드 : https://github.com/subicura/docker-swarm-demo

한글로 된 문서로 docker swarm 기초에 대해서 설명하고 있음. Traefik 리버스 프록시 서버 도 설명을 하고 있음.

docker swarm 공식 문서를 기반으로 만든 듯.

vagrant 를 이용하여 coreos  3대 설치하여 연습을 함.

 

아래는 위 페이지의 내용을 docker stack 파일로 만들어서 실행을 해 본 것임. 몇가지 주의사항

  • traefik 의 명령어 옵션에 --logLevel=DEBUG 추가를 해서 디버그 메시지를 볼 수 있도록 하였음.
  • stack file에서 (compose format) version은 3으로 해도 되는데 특정 network에 테스팅을 위해서 컨테이너를 불이려면 networks에 attachable 옵션이 필요하며 이 옵션은 3.4에서 지원이 되어서 명시를 하였다.
  • stack deploy 이용할 경우 traefik.port 등은 deploy 에 지정을 해야 함. (service labels와 container labels가 다름. https://docs.docker.com/compose/compose-file/#labels-1 참고.
  • 여러 개의  networks에 속한 counter 서비스의 경우 labels에 traefik.docker.network 를 지정해 주어야 통신이 가능함. stack deploy를 할 경우 prefix로 stack 이름이 붙는데 이걸 변수로 처리하는것은 아직 잘 모르겠다. (  com.docker.stack.namespace label 로 나오기는 하는데 어떻게 써야하는지는 모르겠음)
  • traefik 과 연동을 할때 docker service 를 이용하면 자동으로 해당 서비스명 도메인을 만든다. 그런데  stack deploy 이용할 경우 prefix로 stack 이름이 붙으므로 traefik.frontend.rule 을 지정하여 처리하면 된다.

 

사전에 network 구성

 

traefik-compose.yml

 

위의 stack 실행

 

Docker swarm 구성하기

https://docs.docker.com/engine/swarm/

https://docs.docker.com/engine/swarm/swarm-tutorial/ 기초 사용법. 

docker-machine 이용하여  manager, worker1, worker2 구성하기

이제 swarm 을 구성하면 된다.

swarm manager를 구성을 하면 worker 역할도 함께 한다. manager에 부하를 주지 않으려면 manager 상태를 Drain으로 바꾸어서 task를 실행하지 않도록 하는게 좋다.

https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/# 

 

새로 node를 만들면 worker node 나 manager node 로만 swarm cluster에 추가를 할 수 있다.  현재 사용중인 worker node를 manager node로도 구성을 하려면 Promote or demote 을 이용한다.

https://docs.docker.com/engine/swarm/manage-nodes/#promote-or-demote-a-node

swarm manager

swarm manager는 홀수로 구성을 할 것을 권장하고 있다.

https://docs.docker.com/engine/swarm/admin_guide/

https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/#manager-nodes

  • A three-manager swarm tolerates a maximum loss of one manager.
  • A five-manager swarm tolerates a maximum simultaneous loss of two manager nodes.
  • An N manager cluster will tolerate the loss of at most (N-1)/2 managers.
  • Docker recommends a maximum of seven manager nodes for a swarm.

3개의  manager 가 있는 경우 1개의  manager에 문제가 생겨도 swarm 을 사용할 수 있다.

 

service 

docker swarm 에서 service 를 배포하는 것과 관련해서는 아래 문서가 상세하게 나와 있다.

https://docs.docker.com/engine/swarm/services/

service 생성 업데이트 삭제하기.

service 상세 설정하기 : env, 실행중 service command update, image version, 생성 후 service image update, 공개할 포트, overlay network 연결,  secrets에 연결,  scale/placement 조정, 할당된 메모리나 cpu 이슈, server placement preferences, service update 설정 조정,  roll back 조정,  volumes 이나 bind mount  설정, templates 이용하기 등.

 

특정 node에서 컨테이너 실행하는 방법은 constrains를 이용할 수 있다. 아래 cli 예제가 잘 나와 있다.

https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints-constraint

Admin guide

swarm 에 node 를 추가하거나 일정기간 사용하지 않았던 노드를 다시 추가해 주는 경우 swarm에서 자동으로 여유있는 node에 부하를 주지 않는다. 이와 관련된 내용.

https://docs.docker.com/engine/swarm/admin_guide/#force-the-swarm-to-rebalance

일반적으로는 강제로 swarm에서 task를 재분배(rebalance)하는 것은 필요하지 않다. swarm 에 새로운 노드를 추가하거나 일정 기간동안 사용하지 않다가 다시 swarm에 연결된 노드의 경우 swarm에서 자동으로 놀고 있는 노드에 부하를 주지는 않는다. 이것은 디자인(설계) 결정이다. swarm 에서 균형을 위해서 주기적으로 task를 다른 노드로 옮기면 해당 task를 사용하는 클라이언트에서는 문제가 있을 수 있다. 목적은 swarm 에서 균형을 위해서 실행중인 서비스에 문제를 발생시키는 것은 피해야 한다. 새로운 task가 시작되거나 실행중인 task의 노드에 문제가 생긴 경우 해당 태스크는 덜 바쁜 노드에 할당이 된다. The goal is eventual balance, with minimal disruption to the end user. 목적은 eventual balance 로 최종 사용자에게는 최소한의 방해만 주는 것이다.

Docker 1.13 과 그 이후 버전의 경우 docker service update 에서 --force 옵션을 이용할 수 있다. 이 옵션을 이용하면 서비스가 task를 현재 사용 가능한 worker nodes에  재배포한다. 해당 service tasks는 재시작된다. 클라이언트 애플리케이션에서는 문제가 생길 것이다.  rolling update를 설정했다면 서비스에서 rolling update를 이용할 것이다. 

그 이전 Docker 버전을 쓰고 있고 worker  에 부하를 분산시키려고 하며 실행중인 task 가 중지되어도 상관이 없다면 service scale을 올려서 강제로 조정을 할 수 있다. docker service scale 을 사용하면 task가 더 적은 node가 새로운 부하를 받게 된다. 현재 쓰고 있는 swarm에서 부하를 적게 받고 있는 노드가 여러 개 있을 것이다. 모든 노드에 걸쳐서 원하는 균형을 달성하기 위해서 여러 번 적절하게 serivce scale을 조정해야 한다. 

원하는 대로 부하가 분산이 되면 이제 다시 원래의 sclae로 service를 조정해야 한다. docker service ps 를 보면서 조정을 하면 된다.

 

docker service update 에서  –force 옵션을 안 주고 실행하는 경우에는 service에 변경사항이 없다면 아무런 변화가 없었다.

 

위 문서를 읽고나서 생각을 해보면 노드를 swarm에서 뺐다가 다시 넣을 경우 service task를 꼭 재조정할 필요는 없을 것으로 판단이 든다. 이 부분은 swarm 에서 클러스터를 관리하면서 알아서  조정을 해도 될 듯하다. 

만약 노드별로 분산을 하고 싶다면  docker service update 에서 --force 옵션을 이용하는 것이 더 간단하다. 

related information

swarm vs kubernets : https://blog.codeship.com/docker-and-kubernetes/

여기 글을 보면 scheduler로는 k8s과 swarm을 둘다 지원하고 node management는 swarm 을 계속 쓴다고 나왔네요. 아는 사람 왈 " K8S는 Node level이 강력해서 쓰는거라..."

Labels
  • No labels