소프트웨어 배포 강화 - Docker Swarm 튜토리얼

컨테이너 내부에 거주하지 않는 한 컨테이너에 대해 들어본 적이 있을 것입니다. 업계는 영구 인프라에서 임시 인프라로 뚜렷한 움직임을 보이고 있으며 컨테이너는 그 중심에 있습니다. 그 이유는 매우 간단합니다. 컨테이너는 개발 팀이 신속하게 시작하고 실행하는 데 확실히 도움이 되지만 운영 측면을 완전히 바꿀 수 있는 잠재력이 훨씬 더 많습니다.

그러나 정확히 어떻게 생겼습니까? 컨테이너를 로컬로 실행하거나 몇 대의 서버에서 수동으로 실행할 준비가 되면 어떻게 됩니까? 이상적인 세계에서는 애플리케이션을 서버 클러스터에 던지고 "실행해!"라고 말하고 싶을 것입니다.

감사하게도 그것이 오늘의 우리가 있는 곳입니다.

이 기사에서는 Docker Swarm이 무엇이며 제공해야 하는 몇 가지 훌륭한 기능을 살펴보겠습니다. 그런 다음 실제로 Swarm 모드를 사용하고 Swarm에 배포하는 방법을 살펴보고 배포된 Swarm의 일일 작업에 대한 몇 가지 예를 마무리하겠습니다. Docker 및 컨테이너에 대한 기본 지식은 확실히 권장되지만 컨테이너를 처음 접하는 경우 이 훌륭한 블로그 게시물을 먼저 확인할 수 있습니다.

도커 스웜이란?

첫 번째 무리를 만들고 배포하기 전에 Docker Swarm이 무엇인지 이해하는 것이 좋습니다. Docker 자체는 수년 동안 사용되어 왔으며 오늘날 대부분의 사람들은 Docker를 컨테이너 런타임으로 생각합니다. 그러나 실제로 Docker는 모두 함께 작동하는 여러 조각으로 구성되어 있습니다. 예를 들어, 해당 컨테이너 런타임 부분은 runC 및 containerd라는 두 개의 작은 구성 요소에 의해 처리됩니다. Docker가 발전하고 커뮤니티에 다시 제공됨에 따라 이러한 더 작은 구성 요소를 만드는 것이 기능을 빠르게 확장하고 추가하는 가장 좋은 방법이라는 것을 알게 되었습니다. 따라서 이제 SwarmKit과 Docker에 직접 내장된 Swarm 모드가 있습니다.

Docker Swarm은 컨테이너 오케스트레이션 엔진입니다. 높은 수준에서 서로 다른 호스트에서 실행되는 여러 Docker 엔진을 사용하여 함께 사용할 수 있습니다. 사용법은 간단합니다. 애플리케이션을 서비스 스택으로 선언하고 나머지는 Docker가 처리하도록 합니다. 서비스는 애플리케이션 인스턴스에서 데이터베이스 또는 Redis 또는 RabbitMQ와 같은 유틸리티에 이르기까지 무엇이든 될 수 있습니다. 개발 단계에서 docker-compose로 작업한 적이 있다면 이는 완전히 동일한 개념이므로 친숙하게 들릴 것입니다. 사실, 스택 선언은 말 그대로 버전 3.1 구문을 사용하는 docker-compose.yml 파일입니다. 이것은 개발 및 떼 배치를 위해 유사한(그리고 많은 경우에 동일한) 작성 구성을 사용할 수 있음을 의미하지만 여기에서는 약간 앞서가고 있습니다. Swarm 모드에 Docker 인스턴스가 있으면 어떻게 됩니까?

뗏목에서 떨어지지 마십시오

Swarm 세계에는 관리자와 작업자라는 두 가지 유형의 노드(서버)가 있습니다. 관리자도 근로자라는 사실을 기억하는 것이 중요합니다. 관리자는 계속해서 일을 계속할 책임이 있습니다. 모든 스웜은 리더로 지정된 하나의 관리자 노드로 시작합니다. 거기에서 하나의 명령을 실행하여 노드를 떼에 안전하게 추가하기만 하면 됩니다.

Swarm은 Raft 알고리즘의 구현 덕분에 가용성이 높습니다. Raft가 작동하는 방식에 대한 훌륭한 튜토리얼이 이미 있기 때문에 Raft에 대해 너무 자세히 설명하지는 않겠지만 일반적인 아이디어는 다음과 같습니다. 리더 노드는 동료 관리자 노드와 지속적으로 확인하고 상태를 동기화하고 있습니다. 상태 변경이 "수락"되기 위해서는 관리자 노드가 대부분의 노드가 상태 변경을 승인할 때 발생하는 합의에 많이 도달합니다.

이것의 장점은 관리자 노드가 떼의 합의를 손상시키지 않고 산발적으로 떨어질 수 있다는 것입니다. 상태 변경이 합의에 도달하면 대다수의 관리자 노드에 존재하는 것이 보장되며 현재 리더가 실패하더라도 유지됩니다.

A, B, C라는 세 개의 관리자 노드가 있다고 가정해 보겠습니다. 물론 A는 우리의 두려움 없는 리더입니다. 어느 날 일시적인 네트워킹 오류로 인해 A가 오프라인 상태가 되고 B와 C만 남게 됩니다. 오랜 시간(수백 밀리초) 동안 A의 소식을 듣지 못한 B와 C는 무작위로 생성된 일정 시간을 기다렸다가 스스로 선거에 출마해 서로를 알린다. 물론 이 경우 가장 먼저 선거에 출마한 사람이 선출됩니다. 이 예에서 B는 새 리더가 되고 쿼럼이 복원됩니다. 하지만 반전이 있습니다. A가 다시 온라인에 접속하면 어떻게 될까요? 여전히 리더라고 생각할 것입니다. 그렇죠? 각 선거에는 관련된 기간이 있으므로 A는 실제로 임기 1에서 선출되었습니다. A가 온라인으로 다시 돌아와 B와 C를 주문하기 시작하면 B가 2학기의 리더임을 친절하게 알릴 것입니다. A는 물러날 것이다.

물론 이 동일한 프로세스가 훨씬 더 큰 규모로 작동합니다. 세 개 이상의 관리자 노드를 가질 수 있습니다. 그래도 간단한 메모를 하나 더 추가하겠습니다. 각 Swarm은 특정 수의 관리자 손실만 받을 수 있습니다. n개의 관리자 노드로 구성된 무리는 쿼럼을 잃지 않고 (n-1)/2 관리자를 잃을 수 있습니다. 즉, 3명의 관리자 무리의 경우 1명을 잃을 수 있고, 5명의 경우 2명을 잃을 수 있습니다. 이에 대한 근본적인 이유는 다수의 합의에 대한 아이디어로 돌아가며, 이는 프로덕션으로 이동할 때 확실히 염두에 두어야 할 사항입니다.

작업 예약 및 조정

지금까지 우리는 관리자들이 동기화 상태를 유지하는 데 정말 능숙하다는 것을 확인했습니다. 엄청난! 그러나 그들은 실제로 무엇을 하고 있습니까? Swarm에 서비스 스택을 배포한다고 내가 말한 것을 기억하십니까? 서비스를 선언할 때 실제로 서비스를 실행하는 방법에 대한 중요한 정보를 Swarm에 제공합니다. 여기에는 각 서비스에 대해 원하는 복제본 수, 복제본 배포 방법, 특정 노드에서만 실행해야 하는지 여부 등과 같은 매개변수가 포함됩니다.

서비스가 배포되면 설정한 배포 요구 사항이 계속 충족되도록 하는 것이 관리자의 작업입니다. Nginx 서비스를 배포하고 3개의 복제본이 있어야 한다고 지정한다고 가정해 보겠습니다. 관리자는 실행 중인 컨테이너가 없음을 확인하고 사용 가능한 노드에 세 개의 컨테이너를 고르게 배포합니다.

하지만 더 멋진 점은 컨테이너에 장애가 발생하거나 전체 노드가 오프라인 상태가 되는 경우 Swarm이 나머지 노드에 컨테이너를 자동으로 생성하여 차이를 만회한다는 것입니다. 세 개의 컨테이너를 실행하고 싶다고 말하면 세 개의 컨테이너가 실행되는 반면 Swarm은 모든 핵심 세부 사항을 처리합니다. 또한 Swarm에 새로운 복제 설정을 제공하는 것만큼 쉽게 확장 또는 축소할 수 있다는 점이 큰 장점입니다.

서비스 검색 및 로드 밸런싱

마지막 예에서 중요하지만 미묘한 세부 사항을 지적하고 싶습니다. Swarm이 선택한 노드에서 지능적으로 컨테이너를 시작하는 경우 해당 컨테이너가 실행될 위치를 반드시 알 수는 없습니다. 처음에는 무섭게 들릴 수 있지만 실제로는 Swarm의 가장 강력한 기능 중 하나입니다.

동일한 Nginx 예제를 계속해서 Docker에 해당 컨테이너가 포트 80을 노출해야 한다고 말했습니다. 브라우저에서 포트 80에서 해당 컨테이너를 실행하는 노드를 가리키면 해당 컨테이너의 콘텐츠가 표시됩니다. 거기에는 놀라운 일이 없습니다. 하지만 놀라운 점은 해당 컨테이너를 실행하지 않는 노드에 요청을 보내도 동일한 내용이 계속 표시된다는 것입니다! 무슨 일이야?

Swarm은 실제로 수신 네트워크를 사용하여 해당 컨테이너를 실행하는 사용 가능한 노드에 요청을 보내고 동시에 로드 밸런싱을 수행합니다. 따라서 동일한 노드에 3개의 요청을 하면 3개의 다른 컨테이너에 도달할 가능성이 높습니다. Swarm에 있는 단일 노드의 IP를 알고 있는 한, Swarm에서 실행 중인 모든 항목에 액세스할 수 있습니다. 반대로, 이를 통해 어디에서 실행 중인 항목에 대해 걱정할 필요 없이 Swarm의 모든 노드에서 로드 밸런서(예: ELB)를 가리킬 수 있습니다.

외부 연결에서 멈추지 않습니다. 동일한 스택에서 실행되는 서비스에는 서로 통신할 수 있는 오버레이 네트워크가 있습니다. 코드에 IP 주소를 하드 코딩하는 대신 서비스 이름을 연결하려는 호스트 이름으로 간단히 사용할 수 있습니다. 예를 들어 앱이 "redis"라는 Redis 서비스와 통신해야 하는 경우 호스트 이름으로 "redis"를 사용하면 Swarm이 요청을 적절한 컨테이너로 라우팅합니다. 이것은 docker-compose를 사용한 개발 및 Docker Swarm을 사용한 프로덕션에서 원활하게 작동하므로 앱을 배포할 때 걱정할 필요가 한 가지 줄어듭니다.

롤링 업데이트

작전 중이라면 프로덕션 업데이트가 끔찍하게 잘못되었을 때 공황 발작을 경험했을 것입니다. 잘못된 코드 업데이트일 수도 있고 단순한 구성 오류일 수도 있지만 갑자기 생산이 중단됩니다! 보스가 어느 쪽이든 상관하지 않을 가능성이 있습니다. 그들은 그것이 당신의 잘못이라는 것을 알게 될 것입니다. 걱정하지 마세요. Swarm도 이 문제를 지지합니다.

서비스를 업데이트할 때 한 번에 업데이트해야 하는 컨테이너 수와 새 컨테이너가 실패하기 시작하면 어떻게 되는지 정의할 수 있습니다. 특정 임계값이 지나면 Swarm은 업데이트를 중지하거나(Docker 17.04 기준) 컨테이너를 이전 이미지 및 설정으로 롤백할 수 있습니다. 내일 아침에 당신의 상사에게 커피를 가져와야 한다고 걱정하지 마세요.

보안

마지막으로 Docker Swarm은 기본적으로 뛰어난 보안 기능을 제공합니다. 노드가 떼에 합류할 때 자신을 확인할 뿐만 아니라 자신이 생각하는 떼에 합류하고 있는지 확인하는 토큰을 사용합니다. 그 순간부터 노드 간의 모든 통신은 상호 TLS 암호화를 사용하여 발생합니다. 이 암호화는 모두 Swarm에서 자동으로 프로비저닝 및 관리되므로 인증서 갱신 및 기타 일반적인 보안 문제에 대해 걱정할 필요가 없습니다. 물론 키 회전을 강제로 수행하려는 경우 해당 명령이 있습니다.

최신 버전의 Docker Swarm에는 비밀 관리 기능도 내장되어 있습니다. 이를 통해 키 및 암호와 같은 비밀을 필요한 서비스와 이를 필요로 하는 서비스에만 안전하게 배포할 수 있습니다. 서비스에 비밀을 제공하면 해당 서비스의 컨테이너에는 비밀 값이 포함된 특수 파일이 파일 시스템에 마운트됩니다. 당연하지만 기존 접근 방식이었던 환경 변수를 사용하는 것보다 훨씬 안전합니다.

무리 속으로 다이빙

저와 같은 사람이라면 이 모든 기능을 사용해 보고 싶어질 것입니다! 그래서 더 이상 고민하지 않고 뛰어 들어 봅시다!

Docker Swarm 예제 앱

저는 Docker Swarm 사용의 강력함과 용이함을 보여주기 위해 매우 기초적인 Flask 앱을 ​​만들었습니다. 웹 앱은 요청을 처리한 컨테이너, 처리된 총 요청 수 및 "비밀" 데이터베이스 비밀번호가 무엇인지 알려주는 페이지만 표시합니다.

실제 Flask 앱, Nginx 역 프록시 및 Redis 키 저장소의 세 가지 서비스로 나뉩니다. 각 요청에서 앱은 Redis의 num_requests 키를 증가시키므로 적중하는 Flask 인스턴스에 관계없이 올바른 수의 요청이 반영된 것을 볼 수 있습니다.

진행 중인 작업을 "확인"하려는 경우 모든 소스 코드를 GitHub에서 사용할 수 있습니다.

도커와 함께 플레이하세요!

이 튜토리얼을 진행하면서 자신의 서버를 자유롭게 사용할 수 있지만, 그냥 뛰어들고 싶다면 play-with-docker.com을 사용하는 것이 좋습니다. 몇 명의 Docker 개발자가 운영하는 사이트로 네트워크로 연결된 여러 개를 스핀업할 수 있습니다. Docker가 사전 설치된 노드. 4시간 후에 종료되지만 이 예에서는 충분합니다!

스웜 생성

좋아, 간다! 계속해서 PWD(도커로 재생)에서 3개의 인스턴스를 생성하거나 선호하는 VPS(가상 사설 서버) 서비스에서 3개의 서버를 가동하고 모든 인스턴스에 Docker 엔진을 설치하십시오. 항상 이미지를 생성하고 나중에 노드를 추가할 때 이미지를 재사용할 수 있다는 점을 염두에 두십시오. 관리자 노드와 작업자 노드 간에 소프트웨어적인 차이가 없으므로 두 개의 다른 이미지를 유지할 필요가 없습니다.

아직 회전 중이신가요? 걱정마, 내가 기다릴게. 자, 이제 첫 번째 관리자 및 리더 노드를 생성하겠습니다. 첫 번째 인스턴스에서 무리를 초기화합니다.

 docker swarm init --advertise-addr <node ip here>

<node_ip_here> 를 노드의 IP 주소로 바꿉니다. PWD에서는 IP 주소가 상단에 표시되며 자체 VPS를 사용하는 경우 네트워크의 다른 노드에서 액세스할 수 있는 한 서버의 사설 IP 주소를 자유롭게 사용할 수 있습니다.

이제 무리가 생겼습니다! 하지만 노드가 하나만 있기 때문에 꽤 지루한 떼입니다. 다른 노드를 추가해 보겠습니다. init 를 실행했을 때 조인 토큰을 사용하는 방법을 설명하는 긴 메시지가 표시되었음을 알 수 있습니다. 다른 노드를 작업자로 만들고 관리자가 되기를 원하기 때문에 해당 노드를 사용하지 않을 것입니다. 첫 번째 노드에서 다음을 실행하여 관리자에 대한 조인 토큰을 가져옵니다.

 docker swarm join-token manager

결과 명령을 복사하고 두 번째 및 세 번째 노드에서 실행합니다. 보라, 3노드 무리! 모든 노드가 실제로 존재하는지 확인합시다. docker node ls 명령은 무리의 모든 노드를 나열합니다. 다음과 같이 표시되어야 합니다.

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

첫 번째 노드의 ID 옆에 별표가 있는 방법에 주목하세요. 그것은 단순히 그것이 우리가 현재 연결되어 있는 노드임을 알려주는 것입니다. 또한 이 노드가 현재 리더이고 다른 노드에 문제가 발생하면 연결할 수 있음을 알 수 있습니다.

그것이 얼마나 쉬운지 잠시 시간을 내어 감사하고 첫 번째 앱을 배포해 봅시다!

배송!

바로 이 때, 비즈니스 개발 팀은 고객에게 새 앱이 배포되고 1시간 이내에 준비될 것이라고 약속했습니다! 전형적인, 나도 알아. 그러나 두려워하지 마십시오. Docker를 사용하여 구축되었기 때문에 그렇게 많은 시간이 필요하지 않습니다! 개발자들은 친절하게 docker-compose 파일을 빌려주었습니다.

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

잠시 후에 분해해 보겠습니다. 하지만 아직 그럴 시간이 없습니다. 배포하자! 계속해서 첫 번째 노드에 docker-compose.yml 이라는 파일을 만들고 위의 구성으로 채웁니다. echo "<pasted contents here>" > docker-compose.yml 을 사용하여 쉽게 할 수 있습니다.

일반적으로 이것을 배포할 수 있지만 구성에는 db_password 라는 비밀을 사용한다고 언급되어 있으므로 해당 비밀을 빠르게 생성해 보겠습니다.

 echo "supersecretpassword" | docker secret create db_password -

엄청난! 이제 Docker에 구성을 사용하도록 지시하기만 하면 됩니다.

 docker stack deploy -c docker-compose.yml demo

이 명령을 실행하면 우리가 정의한 세 가지 서비스인 web , nginx 및 redis 를 생성하는 Docker를 볼 수 있습니다. 그러나 스택 데모 이름을 지정했기 때문에 실제로 서비스 이름은 demo_web , demo_nginx 및 demo_redis 입니다. 다음과 같이 표시되어야 하는 docker service ls 명령을 실행하여 실행 중인 서비스를 볼 수 있습니다.

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

짜잔! Docker는 이미지를 적절한 노드에 다운로드하고 서비스용 컨테이너를 생성했습니다. 복제본이 아직 전체 용량이 아닌 경우 잠시 기다렸다가 다시 확인하십시오. Docker가 여전히 이미지를 다운로드 중일 수 있습니다.

보는 것은 믿는 것이다

하지만 내 말(또는 Docker의 말)을 받아들이지 마십시오. 앱에 연결해 보겠습니다. 서비스 구성은 Docker에게 포트 8000에서 NGINX를 노출하도록 지시합니다. PWD를 사용 중인 경우 페이지 상단에 "8000"이라고 표시된 파란색 링크가 있어야 합니다. PWD는 실제로 해당 포트에서 서비스가 실행되고 있음을 자동으로 감지했습니다! 그것을 클릭하면 포트 8000에서 선택한 노드로 라우팅됩니다. 자체 서버를 롤링했다면 포트 8000에서 서버 IP 중 하나로 이동하기만 하면 됩니다.

몇 가지 기본 정보를 제공하는 아름다운 스타일의 화면이 표시됩니다.

요청을 처리한 컨테이너를 기록한 다음 페이지를 새로 고칩니다. 확 바뀌었습니다. 하지만 왜? 글쎄, 우리는 Docker에게 Flask 앱의 2개의 복제본을 생성하라고 지시했고, 이 두 인스턴스 모두에 요청을 배포하고 있습니다. 방금 두 번째로 다른 컨테이너를 쳤습니다. 또한 두 Flask 컨테이너가 우리가 지정한 단일 Redis 인스턴스와 통신하기 때문에 요청 수가 증가한 것을 알 수 있습니다.

아무 노드에서나 포트 8000을 눌러 보십시오. 여전히 앱으로 제대로 연결됩니다.

마법의 신비화

이 시점에서 모든 것이 작동하며, 이 과정이 고통 없이 진행되기를 바랍니다! docker-compose.yml 파일을 자세히 살펴보고 실제로 Docker에 말한 내용을 살펴보겠습니다. 높은 수준에서 web , nginx 및 redis 의 세 가지 서비스를 정의했습니다. 일반 작성 파일과 마찬가지로 Docker에 각 서비스에 사용할 이미지와 실행할 명령을 제공했습니다. nginx 의 경우 호스트의 포트 8000이 컨테이너의 포트 80에 매핑되도록 지정했습니다. 이 모든 것이 지금까지 표준 작성 구문입니다.

여기서 새로운 기능은 배포 및 비밀 키입니다. 이러한 키는 docker-compose 에서 무시되므로 개발 환경에 영향을 미치지 않지만 docker stack 에서는 사용됩니다. 웹 서비스를 살펴보자. 충분히 간단합니다. 우리는 Flask 앱 두 개의 복제본을 실행하고 싶다고 Docker에 알립니다. 또한 웹 서비스에 db_password 비밀이 필요하다는 것을 Docker에 알립니다. 이것은 컨테이너가 비밀 값을 포함하는 /run/secrets/db_password 라는 파일을 갖도록 하는 것입니다.

Nginx로 이동하면 배포 모드가 global 로 설정되어 있는 것을 볼 수 있습니다. 기본값(웹에서 암시적으로 사용됨)은 replicated 되며, 이는 원하는 복제본 수를 지정한다는 의미입니다. global 을 지정하면 Swarm의 모든 노드가 정확히 하나의 서비스 인스턴스를 실행해야 한다고 Docker에 알립니다. docker service ls 를 다시 실행하면 nginx 에 3개의 복제본이 있음을 알 수 있습니다.

마지막으로 도커에게 Redis의 단일 인스턴스를 무리의 어딘가에서 실행하도록 지시했습니다. Redis 호스트를 요청할 때 웹 컨테이너가 자동으로 라우팅되기 때문에 위치는 중요하지 않습니다.

Swarm 일상 사용하기

Docker Swarm에 첫 번째 앱을 배포한 것을 축하합니다! 잠시 시간을 내어 사용하게 될 몇 가지 일반적인 명령을 검토해 보겠습니다.

Swarm 검사

서비스를 확인해야 합니까? docker service ls 및 docker service ps <service name> 을(를) 시도하십시오. 전자는 각 서비스에 대한 높은 수준의 개요를 보여주고 후자는 지정된 서비스에 대해 실행 중인 각 컨테이너에 대한 정보를 제공합니다. 이는 서비스를 실행 중인 노드를 확인하려는 경우 특히 유용합니다.

롤링 업데이트

앱을 업데이트할 준비가 되면 어떻게 됩니까? docker stack deploy 의 멋진 점은 실제로 기존 스택에도 업데이트를 적용한다는 것입니다. 새 Docker 이미지를 저장소에 푸시했다고 가정해 보겠습니다. 실제로 처음 사용한 것과 동일한 배포 명령을 실행할 수 있으며 스웜은 새 이미지를 다운로드하여 배포합니다.

물론 스택의 모든 서비스를 항상 업데이트하고 싶지는 않을 수 있습니다. 서비스 수준에서도 업데이트를 수행할 수 있습니다. 최근에 웹 서비스에 대한 이미지를 업데이트했다고 가정해 보겠습니다. 이 명령을 실행하여 모든 웹 컨테이너를 업데이트할 수 있습니다.

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

이 명령의 추가 이점은 원래 구성에 있어야 한다고 지정한 경우 롤링 업데이트를 적용한다는 것입니다. 그리고 그렇게 하지 않은 경우에도 다음과 같이 롤링 업데이트를 수행하도록 지시하는 업데이트에 플래그를 전달할 수 있습니다.

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

업데이트 사이에 30초를 기다리면서 한 번에 하나의 컨테이너를 업데이트합니다.

서비스 확장 또는 축소

두 개의 웹 컨테이너를 갖는 것도 좋지만 무엇이 더 나은지 아십니까? 열 가지! Swarm에서 서비스를 확장 및 축소하는 것은 다음과 같이 쉽습니다.

 docker service scale demo_web=10

해당 명령을 실행하고 docker service ps demo_web 의 출력을 확인합니다. 이제 10개의 컨테이너가 있고 그 중 8개가 방금 시작되었음을 알 수 있습니다. 관심이 있는 경우 웹 응용 프로그램으로 돌아가서 페이지를 몇 번 새로고침하여 이제 원래 두 개의 컨테이너 ID보다 더 많은 정보를 얻고 있는지 확인할 수도 있습니다.

스택 및 서비스 제거

스택과 서비스가 배포되고 확장됩니다. 하지만 이제 오프라인으로 전환하려고 합니다. 이것은 각각의 rm 명령으로 수행할 수 있습니다. 데모 스택을 제거하려면 다음 명령을 실행하세요.

 docker stack rm demo

또는 단일 서비스를 제거하려면 다음을 사용하십시오.

 docker service rm demo_web

배수 노드

우리가 swarm의 노드를 확인하기 위해 이전에 docker node ls 를 실행했을 때를 기억하십니까? 가용성 을 포함하여 각 노드에 대한 많은 정보를 제공했습니다. 기본적으로 노드는 Active 이며, 이는 컨테이너를 실행하기에 공정한 게임임을 의미합니다. 그러나 유지 관리를 수행하기 위해 노드를 일시적으로 오프라인으로 전환해야 하는 경우가 있습니다. 물론, 그냥 종료하면 떼가 회복되지만 Moby(도커 고래)에게 약간의 알림을 주는 것이 좋습니다.

여기에서 드레이닝 노드가 등장합니다. 노드를 Drain 으로 표시하면 Docker Swarm은 노드에서 실행 중인 모든 컨테이너를 다른 노드에 위임하고 가용성을 다시 Active 로 변경할 때까지 노드에서 컨테이너를 시작하지 않습니다.

node1 을 배수하고 싶다고 가정해 봅시다. 다음을 실행할 수 있습니다.

 docker node update --availability drain node1

쉬운! 다시 작동할 준비가 되면:

 docker node update --availability active node1

마무리

지금까지 살펴본 것처럼 Docker와 Swarm 모드를 함께 사용하면 애플리케이션을 그 어느 때보다 효율적이고 안정적으로 배포할 수 있습니다. Docker Swarm이 유일한 컨테이너 오케스트레이션 엔진이 아니라는 점은 언급할 가치가 있습니다. 사실, 그것은 젊은 사람들 중 하나입니다. Kubernetes는 더 오래 사용되었으며 더 많은 프로덕션 애플리케이션에서 확실히 사용됩니다. 즉, Swarm은 Docker에서 공식적으로 개발한 것으로 매일 더 많은 기능을 추가하기 위해 노력하고 있습니다. 어떤 것을 사용하든 상관없이 용기를 계속 보관하십시오!