Rails 部署實踐 - Docker Swarm 與 Docker Compose

雖然我們可以用 Watchtowner 來實現自動的部署，然而這樣的方式還有許多問題存在。首先是我們基本上無法控制版本，只能抓取 latest 的版本，除此之外也無法控制部署的時機以及退回的機制。

這個時候我們就可以導入 Docker Swarm 來作為替代方案，作為轉換到像是 AWS ECS 或者 Kubernetes 的過度方案。

進階版 Docker Compose

Docker Swarm 簡單來說可以視為進階版本的 Docker Compose 應用，在 Docker Compose 的文件就可以看到像是 deploy 這類針對部署選項可以使用。

因為 Docker Compose 還是設計成「單機部署」的狀況，當我們需要進行調度的時候，就會需要叢集（Cluster）的模式來幫我們協調資源的管理，目前除了雲端的方案之外，還有像是 HashiCorp 的 Nomad 以及主流的 Kubernetes 和其他各種解決方案。

而 Docker Swarm 就提供了這樣的機制，可以簡單地將不同具備 Docker 的伺服器串連起來，讓我們可以分配容器到這些節點上，並且不用擔心網路以及服務查詢的問題。

容易安裝

我會推薦使用 Docker Swarm 的原因是相比 Nomad 和 Kubernetes 來說是最容易安裝的，基本上只要有安裝 Docker 並且使用 docker swarm init 命令，就算是完成安裝跟配置，同時消耗的系統資源也相對的少。

以 Nomad 為例子，我們想要搭建對應的環境，會需要連同 Consul 也一起搭建起來，並且還需要自己處理入口（Ingress）與 Consul 的整合，才能夠解決部署的服務能被外部存取的問題。

若是想要使用 Kubernetes 除了許多網路解決方案（CNI，Container Network Interface）要選擇之外，還需要針對許多基礎建設（Infrastructure）類型的問題處理，除非使用像是 AWS EKS 或者 Google 的 GKE 這類雲端服務，不然非常難以設定。

不過以上這幾種解決方案，都在儲存（Storage）有相同的限制，需要依靠 NAS（Network Attached Storage）或者 CSI（Container Storage Interface）來輔助解決跨節點的資料轉移。

無痛學習

除了安裝上非常容易外，在學習的成本幾乎也是接近零。這是因為大多數人在入門容器技術的時候，都會一起學習 Docker Compose 的撰寫，而 Docker Swarm 的設定可以向下相容 Docker Compose 的設定（扣除少部分選項）

另一方面，Docker Swarm 其實也有提供針對 Kubernetes 的轉換，在未來要轉移到 Kubernetes 的時候也可以減少初期轉換的成本，而不需要馬上將完整的 Kubernetes 學會。

雖然 Docker Swarm 的學習曲線對大部分熟悉 Docker 的開發者來說相對的低，然而要做好設定還是需要花費一定的力氣，才能夠將 Docker Swarm 跟 CI / CD 完善的整合在一起，並且建立一個完整的開發、部署流程。

如果想在第一時間收到更新，歡迎訂閱弦而時習之在這系列文章更新時收到通知，如果有希望了解的知識，可以利用Rails 部署實踐回饋表單告訴我。