關於Docker Swarm，你可能須要瞭解更多實踐經驗

數人云今天帶來的本篇文章將分享Docker在應用程序生命週期每一個階段中所扮演的角色，以及遷移到Swarm集羣時須要考慮的問題。

利用Docker來開發

Docker讓工做更輕鬆。如須要一個部署安裝MySQL數據庫，或者安裝Ghost,又或者Redis數據庫，PostgreSQL，Ruby等。實際上這些都已經被Docker化容器化和鏡像化。

只須要一條命令便可運行：

docker run name_of_programe_you_need

下載(鏡像)—使用完—丟掉，沒有其餘程序搞亂本地開發環境。

擴展示有的容器十分簡單，只要擁有足夠的Docker基礎知識，就能斷定從網上下載的Docker鏡像是不是有用的鏡像。

Docker是開發人員的利器，添加到開發環境中好處無需多言。

若熟悉Docker,  會常用Docker-compose一條命令來啓動整個開發環境棧。

例如，很常見的Docker-compose文件是這樣：

version: '2'  
services:  
  web:
    build: .
    command: npm run dev
    ports: 
      - 8080:80

  redis:
    image: redis

  database:
    image: postgres

而後運行：

docker-compose up # --build if you want to rebuild

PostgreSQL訪問地址：postgresql://database

Redis訪問地址： http://redis

這是一種極爲簡便的方法，整個開發環境棧用幾行代碼描述（development stack as a code），而且內置版本控制功能。下面來說下生產環境。

生產環境要求

生產環境非同通常。這裏例舉中等負載量的服務器要求——

• 可用性： 必須全部的時間點上，服務都是可用的，儘量減小宕機時間。

• 性能： 服務器須要處理大量的訪客請求，故而性能也很重要。

• 易於部署和回滾。

• 收集日誌和指標。

• 負載均衡： 若是有某些服務或者服務器失敗了，咱們指望網站能夠正常訪問。

Docker做爲一個準生產的解決方案，實際上被很是多的人低估了。約一年前，PvP Center（https://beta.pvpc.eu/）過程當中，因Docker文件系統問題，也經歷了一些失敗（目前，我使用Overlay2文件系統，問題不復存在），如今回頭想一下，這是很好的決定。

生產部署是使用原始Docker命令仍是 Docker-compose

若遇到這個問題，配置好Ansible自動下載新版本的應用，而後自動部署到容器便可（Ansible配置文件：https://rock-it.pl/managing-m... ）。
接下來查看列表——

• 性能：Docker進程，是正常的內核進程，不會產生顯著的資源開銷。

• 易於部署： 一鍵部署。因Ansible要檢查多個判斷條件, 不只僅是是判斷容器的版本，因此須要花費一點時間。

• 回滾: 全部的容器鏡像都使用不一樣的標籤後，保存在容器倉庫中。對數據庫遷移作了向後兼容，回滾會很容易。

但以上的作法也會產生問題：

一、不能知足一些很是規要求（在要求部署應用的時候服務器零宕機） 由於要維護後端動態的負載均衡節點，不能輕易的擴容到多臺服務器上。

二、須要極聰明的手段和方法才能整合 持續集成/持續部署系統（CI/CD）。

三、若是分別存放特定應用程序，知足部署依賴在不一樣的架構倉庫內 。當配置文件發生變化時，回滾變得很是困難。

堅持了這種作法一段時間，沒有任何問題，可是總感受缺失了什麼東西，由於快速部署以及配置文件須要太多修改， Ansible部署也刺激到了我（太慢了）。可是，真正促使往Docker Swarm遷移的決定性緣由是——擴容到一臺服務器以的特性。雖然可使用相同的方式部署應用到雲端，使用外部負載均衡器，但動態添加或者減小負載均衡節點依舊是痛點。把特定應用的配置文件從Ansible中移除，轉而把這些配置文件發到應用倉庫中。

Docker 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:
        condition: on-failure

整個部署命令只有一行：docker stack deploy application . 固然，這裏使用了Gitlab.com 的流程，結果以下圖所示：

能夠在Web界面上進行回滾操做，甚至在手機上執行回滾操做。

結語

以上都是我的對Docker Swarm的觀點。以前考慮過使用其餘選項，但若是想讓應用容器化，進而伸縮擴容到多臺服務器上，目前這種方法是最好的選擇。

原文做者：Jakub Skałecki
原文連接： https://rock-it.pl/my-experie...

歡迎關注數人云微信公衆號，若有後續文章，咱們會在第一時間進行跟進