摘要：應該如何解決本文將給出若干提示，如何在生產環境中使用。路由匹配服務發現負載均衡跨容器通訊非常可靠。在單個端口上運行一個服務，節點的任意主機都可以訪問，負載均衡完全在后臺實現。

上周數人云給大家分享了——《你可能需要的關于Docker Swarm的經驗分享》今天給大家帶來這位作者大大的后續文章——《Docker Swarm在生產環境中的進階指南》

當在本地開發環境中使用Docker，或者已經在單臺生產服務器上部署Docker，卻發現它不足以支撐更多的流量。應該如何解決？本文將給出若干提示，如何在生產環境中使用Docker Swarm。

附：如果對Swarm不熟悉，請查看之前的文章《你可能需要知道的關于Docker Swarm的經驗分享》

這里不重復官方Swarm的入門教程和文檔。入門教程很簡短，它會讓你明白Swarm是如何工作的。這里也不講解設置和部署Swarm環境，網上有很多初級的教程，可供參考如——

Digitalocean上的教程 :（https://www.digitalocean.com/...）

或者google搜索相關教程。

附：一個牛X的： Ansible role (
https://galaxy.ansible.com/at...

就觀察而言，用于Swarm內部信息共享和調度的Cpu開銷確實很低。得益于此，管理節點同時也可以是工作節點。如果要跑一個1000+個節點的大集群，管理節點開銷需要非常多的資源，但當集群是小規模到中等規模時，這種資源消耗和開銷是可以忽略不計的。參考這里——
（https://sematext.com/blog/201...）Swarm3k, 一個運行4700個節點的集群實驗。

路由匹配（服務發現、負載均衡、跨容器通訊）非常可靠。在單個端口上運行一個服務，Swarm節點的任意主機都可以訪問，負載均衡完全在后臺實現。之前遇到過一些難題，但使用Docker1.13版本后，問題得到解決。

在配置初始化完成后，只需要幾行命令作為日常運維。下面是日常使用的命令：

# let"s create new service  創建一個新的服務
docker service create   
  --image nginx 
  --replicas 2 
  nginx 

# ... update service ...   更新服務
docker service update   
  --image nginx:alpine 
  nginx 

# ... and remove   刪除服務
docker service rm nginx

# but usually it"s better to scale down 但是更好的辦法是縮容，而不是直接刪除服務
docker service scale nginx=0

# you can also scale up   擴容
docker service scale nginx=5

# show all services 列出所有的服務
docker service ls

# show containers of service with status   列出一個服務的所有實例(包括服務的健康狀況)
docker service ps nginx

# detailed info  服務的詳細信息
docker service inspect nginx

服務零宕機，是完美的持續部署方案。

# lets build new version and push to the registry 創建新版本的鏡像，并且推送到registry
docker build -t hub.docker.com/image .  
docker push hub.docker.com/image

# and now just update (on a master node) 現在更新服務（在master節點上）
docker service update --image hub.docker.com/image service

易于啟動：分布式系統本身就很復雜。相比于其他解決方案（Mesos, Kubernetes）, Swarm簡單易學，即便無任何Swarm的知識，從單臺服務器Docker-compose方式的部署，擴展到20臺服務器，分布式可伸縮的解決方案，也只需要大約一周。

無需修改。容器實例同時跑在多臺服務器上。修改任何東西，需要打包一個新的鏡像，適當的測試和部署是成功的關鍵。

并不是所有的應用都適合跑在Docker swarm上，比如，數據庫和一些有狀態的服務。

從理論上而言，可以使用標簽的方式固定某個容器跑在某個特定的資源上，但是，更難的是從Swarm集群外部來訪問這個容器提供的服務。（在Docker1.12版本里面沒有簡單的方式來實現，在Docker1.13+版本可以使用附加的Overlay 網絡模式）。

比如，想開放一個數據庫服務給外部訪問，讓外部所有節點都可以訪問數據庫，但是這不是真正想要實現的結果（只想讓特定節點訪問數據庫）
。
又如，Swarm里面的跨主機存儲卷掛載幾個月之前還不可靠，用戶上傳文件這樣簡單的操作也會引發問題。

適用于容器化的是那些由環境變量驅動無狀態的應用容器。是時候準備自己使用過的開源軟件Docker鏡像了，例如配置完善的Nginx鏡像。

跑在swarm上的服務

web服務器（Django channels - Daphne and workers）

反向代理（Nginx）

Periodic workers (Celery)

指標收集器 (Sensu)

不跑在swarm上的容器

數據庫（Postgres）

Redis

由于獲取真實IP的問題（https://github.com/moby/moby/...），也會把Sginx多帶帶移出來不跑在Swarm模式下，至少應該使用Nost網絡模式，但在Docker 1.12版本下，這是唯一的選擇。

Docker倉庫或是自己的服務器，也許是Dockerhub、 Gitlab.com(作者選擇這個)此類。在服務器上創建鏡像已經不適用了，因為有太多服務器且在創建服務時（ Docker service create）要指明鏡像。如果倉庫是私有倉庫，記得增加--with-registry-auth 這個參數，否則其他節點無法拉取鏡像。同時應該使用Tag來標明發布的版本號，這樣發現問題時可以快速回滾。

“部分有狀態”是指有一些共享而不重要的文件。可以嘗試使用共享存儲卷掛載，更好的方法是遷移到亞馬遜S3或者其他云存儲。記住，擴張的時候，云是最佳選擇。

如例子中，不得不創建自己有合適參數的Nginx鏡像。通過共享存儲卷掛載在以前非常不可靠、不方便。

集中式的日志和指標是使用分布式文件系統的必須項，如ELK，Graphana，Graylog 等等。

這里有許多可選項，有開源項目，也有SaaS類服務。這些打造和整合成可靠的服務是復雜且艱難的。建議先使用云端服務（如Loggly, Logentries）, 當成本上漲的時候，再開始架設自己的日志收集服務。
例：ELK 棧日志處理配置:

docker service update   
  --log-driver gelf 
  --log-opt gelf-address=udp://monitoring.example.com:12201 
  --log-opt tag=example-tag 
  example-service

記得使用它，否則無法在Docker Swarm下一條命令跑起一個容器。這是Docker1.13+新功能。如果使用舊版本的Docker, 最好升級下。

代碼：

docker network create --driver=overlay --attachable core

如果創建Docker鏡像的時候，遵循了最佳實踐原則（https://rock-it.pl/how-to-wri...），允許在運行的時候通過環境變量設置一切配置項，那么把應用遷到Swarm的過程完全沒有問題。

例，有用的命令：

docker service create   
  --env VAR=VALUE 
  --env-file FILENAME 
  ...

docker service update   
  --env-add VAR=NEW_VALUE 
  --env-rm VAR 
  ..

下一個級別就是使用非公開的API掛載文件像掛載秘鑰那樣（Authorized keys, SSL certs 等）。作者暫時還未使用此功能，不能詳述，但這個功能特性絕對值得思考和使用。

保持適當數量的實例，以應對高流量和實例或者節點不可用的情況。同時太多的實例數也會占用CPU和內存，并且導致爭搶CUP資源。

update-parallelism的默認值是1，默認只有一個實例在運行。但這個更新速度太慢了，建議是 replicas / 2。

相關命令：

docker service update   
  --update-parallelism 10 
  webapp

# You can scale multiple services at once
docker service scale redis=1 nginx=4 webapp=20

# Check scaling status
docker service ls

# Check details of a service (without stopped containers)
docker service ps webapp | grep -v "Shutdown"

最好使用Docker Compose v3版本的語法（https://docs.docker.com/compo...）。

他允許使用代碼指定幾乎所有的服務選項。作者在開發的時候使用 Docker-compose.yml，在生產環境（swarm）配置使用 Docker-compose.prod.yml . 部署Docker-compose文件中所描述的服務，需要Docker stack deploy 命令（屬于新版本 Stack命令集合中的一部分[https://docs.docker.com/engin...）

Docker compose v3例子：

# docker-compose.prod.yml
version: "3"  
services:  
  webapp:
    image: registry.example.com/webapp
    networks:
      - ingress
    deploy:
      replicas: ${WEBAPP_REPLICAS}
      mode: replicated
      restart_policy:
        condition: on-failure

  proxy:
    image: registry.example.com/webapp-nginx-proxy
    networks:
      - ingress
    ports:
      - 80:80
      - 443:443
    deploy:
      replicas: ${NGINX_REPLICAS}
      mode: replicated
      restart_policy:
        condition: on-failure

networks:  
  ingress:
    external: true

部署的例子（創建或者更新服務）：

export NGINX_REPLICAS=2 WEBAPP_REPLICAS=5

docker login registry.example.com  
docker stack deploy   
  -c docker-compose.prod.yml
  --with-registry-auth 
  frontend

提示：Docker-compose文件支持環境變量 (${VARIABLE}), 所以，可以動態調整配置作為測試等。

就經驗而言，可以為所有服務設置CPU使用限制。當某一個容器應用占用掉所有主機資源時，此限制可以避免這種情況發生。

當想把所有容器均勻地發布在所有主機上或是想確保有足夠的資源來響應操作時，需使用Reserve-cpu這個參數。

例如：

docker service update  
  --limit-cpu 0.25
  --reserve-cpu 0.1
  webapp

曾經在Swarm網絡上遇到過一些問題。很多次所有的流量都被路由到同一個容器實例上，而同時有9個容器實例正常且健康的。這種情況下——即流量持續導到一個實例上，做擴容或者縮容操作的時候，加上這個參數--endpoint-mode 。

在沒有適當的集中式日志時，要發現這個問題還真不容易。

原文作者：Jakub Ska?ecki

原文鏈接： https://rock-it.pl/my-experie...

歡迎關注數人云微信公眾號，如有后續文章，我們會在第一時間進行跟進。