Zi 字媒體

Docker Swarm利用Docker來開發﹀﹀﹀Docker讓工作更輕鬆。如需要一個部署安裝MySQL資料庫，或者安裝Ghost, 又或者Redis資料庫，PostgreSQL，Ruby等。實際上這些都已經被Docker化和鏡像化。只需要一條命令即可運行：下載(鏡像)—使用完—丟掉，沒有其他程序搞亂本地開發環境。擴展現有的容器十分簡單，只要擁有足夠的Docker基礎知識，就能判定從網上下載的Docker鏡像是否是有用的鏡像。Docker是開發人員的利器，添加到開發環境中好處無需多言。若熟悉Docker, 會經常使用Docker-compose一條命令來啟動整個開發環境棧。version: '2' services: web: build: . command: npm run dev ports: - 8080:80docker-compose up 這是一種極為簡便的方法，整個開發環境棧用幾行代碼描述（development stack as a code），並且內置版本控制功能。下面來講下生產環境。Docker Swarm 生產環境要求﹀﹀﹀可用性： 必須所有的時間點上，服務都是可用的，儘可能減少宕機時間。性能： 伺服器需要處理大量的訪客請求，故而性能也很重要。易於部署和回滾。收集日誌和指標。負載均衡： 如果有某些服務或者伺服器失敗了，我們期望網站可以正常訪問。Docker作為一個準生產的解決方案，實際上被非常多的人低估了。約一年前，我選擇把PvP Center（https://beta.pvpc.eu/）過程中，因Docker文件系統問題，也經歷了一些失敗（目前，使用Overlay2文件系統，問題不復存在），現在回頭想一下，這是很好的決定。生產部署是使用原始Docker命令還是 Docker-compose若遇到這個問題，配置好Ansible自動下載新版本的應用，然後自動部署到容器即可（Ansible配置文件： ）。接下來查看列表——性能：Docker進程，是正常的內核進程，不會產生顯著的資源開銷。易於部署： 一鍵部署。因Ansible要檢查多個判斷條件, 不僅僅是判斷容器版本，所以需要花費一點時間。回滾: 所有的容器鏡像都使用不同的標籤后，保存在容器倉庫中。對資料庫遷移做了向後兼容，回滾會很容易。但以上的做法也會產生問題：1、不能滿足一些非常規要求（在要求部署應用的時候伺服器零宕機） 因為要維護後端動態的負載均衡節點，不能輕易的擴容到多台伺服器上。2、需要極聰明的手段和方法才能整合 持續集成/持續部署系統（CI/CD）。3、如果分別存放特定應用程序，滿足部署依賴在不同的架構倉庫內 。當配置文件發生變化時，回滾變得非常困難。堅持了這種做法一段時間，沒有任何問題，但是總感覺缺失了什麼東西，因為快速部署以及配置文件需要太多修改， Ansible部署也刺激到了我（太慢了）。但是，真正促使往Docker Swarm遷移的決定性原因是——擴容到一台伺服器以的特性。雖然可以使用相同的方式部署應用到雲端，使用外部負載均衡器，但動態添加或者減少負載均衡節點依舊是痛點。把特定應用的配置文件從Ansible中移除，轉而把這些配置文件發到應用倉庫中。Docker SwarmDocker Swarm﹀﹀﹀Docker Swarm設計的目的是方便地使用Docker命令來管理多台伺服器之間的容器調度，是相當前沿的新功能新特性（從Docker 1.12版本開始）。要點：要點：允許同時連接到多台運行Docker的伺服器上。比較簡單：對比Kubernetes，Docker Swarm上手更快。高可用 – 集群中有兩種不同類型的節點： Master節點和Worker節點。其中的一個Master節點是Leader, 如果當前Leader宕機不可用，其他健康的Master中的一台會自動成為Leader 。如果Worker節點宕機不可用，宕機節點上的容器實例會被重新調度到其他健康的Worker節點上。聲明式配置：只需明確發布希么應用以及多少份實例副本，調度系統會自動調度發布這些應用實例，並且遵循指定的限制條件等。滾動更新：Swarm保存了發布容器時候的配置。 若更新了配置文件，容器也會批量更新，所以服務會是一直是可用的。內置服務發現和負載均衡 ：與Docker-compose 實現的負載均衡類似。可以通過參考服務名，容器跑在哪裡哪台伺服器上已經完全不重要，這些負載均衡節點都會接收前端導過來的流量，默認是輪詢策略。Overlay網路：如果容器暴露了一個服務埠，這個服務埠在集群內都可以被訪問。這對使用外部負載均衡器幫助巨大。在什麼時候才應該考慮使用Docker Swarm在考慮使用Docker Swarm前，先過一遍下面5個問題——應用是否需要擴容到兩台以上的伺服器上？多台伺服器總是比單台伺服器複雜，或者只是想購買更高配置的單台伺服器（譯者注: 縱向擴展）？應用是否有高可用的要求？應用容器化后是否真的是無狀態化的？在Swarm下跑容器不應該使用存儲卷，雖然理論上是可以使用存儲卷，但是在測試使用的時候，它依舊不是穩定可靠的。可以考慮把多媒體文件移到亞馬遜S3上，而把資料庫運行在Docker Swarm之外。是否需要集中日誌系統，例如ELK (這個適用於所有分散式系統)。是否需要已經存在於其他更成熟解決方案（如Kubernetes）中的高級功能和特性? 謹記，熟悉Kubernetes比熟悉Docker Swarm要難得多。生產環境使用Docker Swarm經驗截止目前，應用跑在Swarm上面已經有六個月的時間，從Docker-compose遷移到Swarm花去一周的時間（包括學習如何遷移等）。需要調整配置文件，以便讓應用容器完全是無狀態的，使用外部集中式日誌和指標收集。高峰時，共運行了35個節點。對集群的管理十分方便。例如：docker service scale name_of_service=30 or docker service update --env-add SECRET_ENV=youdontneedtoknowit name_of_service截屏如下：部署流程如下圖：在Deploy區域內，使用最新Docker-compose v3版的語法和Docker stack deploy命令。把發布應用容器的配置文件存儲為VCS這項工作變得前所未有的簡單。無需要手工修改任何配置，輕鬆地部署應用容器到Swarm集群。配置文件例子：version: '3' services: web: image: registry.gitlab.com/example/example # you need to use external image command: npm run prod ports: - 80:80 deploy: replicas: 6 update_config: parallelism: 2 delay: 10s restart_policy:整個部署命令只有一行：docker stack deploy application . 當然，這裡使用了Gitlab.com 的流程，結果如下圖所示：可以在Web界面上進行回滾操作，甚至在手機上執行回滾操作。Docker Swarm結語﹀﹀﹀以上都是個人對Docker Swarm的觀點。之前考慮過使用其他選項，如果想讓應用容器化，進而伸縮擴容到多台伺服器上，目前這種方法是最好的選擇。 原文作者：Jakub Skałecki