過去幾年，使用容器技術（Container）來部署 Ruby on Rails 專案已經變成我個人最喜歡的方式之一。除了生態系完整之外，也有著容易安裝、部署環境，並且可以很好的維持部署環境乾淨的優點存在。
基於這樣的理由，在 Rails 部署實踐這一系列，我們會由 Rails 的容器部署方案最為起點開始討論可以使用的部署方案。
Docker
Docker 作為讓容器技術變為主流的解決方案之一，我相信還是有很多人仍在使用這個技術。作為部署 Rails 專案的選項，到 2022 年為止都會是一個不錯的方案。
然而，每一次的部署都需要使用 docker run 跟 docker stop 來重新啟動更新的容器，實際上效率是非常差的，因此我們會採取另一個解決方案。
Docker Compose
Docker Compose 是一個由 Python 所撰寫的工具，會透過呼叫 Docker API 來幫助我們依照使用 YAML 撰寫的設定檔進行建立、取代容器等等操作，相比 Docker 來說更適合用於管理部署的方案。
適用情境：
- 單機部署
- 開發環境
Docker Swarm
Docker Swarm 跟 Docker Compose 相比起來，更像是「企業級」解決方案的實現，在某方面來說也能夠接受 Docker Compose 的設定檔格式來進行部署。跟 Docker Compose 不同的是 Docker Swarm 是以 Cluster（叢集）為前提設計的，因此當我們需要稍微大規模的部署時就很適合。
適用情境：
- 多機部署
- 相對單純的應用
就個人經驗來說，如果需要到比較大規模的部署，直接採用雲端服務或者 Kubernetes 都會更容易些，因此這系列的文章不會多做討論。
AWS ECS
雖然這邊以 AWS（Amazon Web Service）的 ECS（Elastic Container Service）為例子，這個前提基本上還是適合大部分有提供類似服務的雲端。
在 ECS 中我們可以使用 Task Definition（任務定義）跟 Service（服務）來讓 ECS 可以根據定義自動的建立、運行我們所製作的容器，同時還能夠整合各種 AWS 的服務到裡面，像是 KMS（Key Management Service，金鑰管理服務）能夠幫助我們管理加密的字串，進而避免在容器中打包任何敏感資訊等等。
然而要完整的設定好 ECS 仍需要許多對 AWS 知識的理解，同時在 Auto Scaling 和單機能夠運用的容器數量都會受到一定的限制，在使用之前必須瞭解清楚。
適用情境：
- 多機部署
- 預算充足
雲端服務跟傳統機房相比肯定是節省非常多成本的，然而雲端的成本效益需要建立在「正確使用」以及「有一定規模」的前提之下，因此需要根據現實狀況判斷來使用。
Heroku
使用 Heroku 這個 PaaS 平台大概是最熱門的 Ruby on Rails 部署入門選項，除了使用 Heroku 的 Buildpack 機制部署之外，在這幾年 Heroku 也有支援以容器的方式進行部署。
這種部署方式仍有一部分的限制存在，然而讓開發者在 Buildpack 的限制下多了更多選擇，如果對於部署的掌控度沒有非常高的要求，使用這種方式不失為一種「最容易」的選項。
適用情境：
- 多機部署
- 沒有特殊需求
Kubernetes
Kubernetes 基本上是這幾年整個網路產業「最熱門」的部署選項之一，同時也是最難以入門的部署方案，除非對於整個雲端、微服務（Microservice）等等有一定程度的理解，通常很難在短時間內上手。
然而，因為 Kuberntes 的彈性與高度抽象化的設計，可以得到非常彈性的變化。除此之外因為跟微服務的相性非常好，在多專案或者大型企業中可以很好的讓不同團隊獨立運作並且維持協作。
適用情境：
- 大型團隊
- 大型系統
除了上述幾種常見方案之外，還有非常多變化的應用方式。礙於篇幅的關係我們只會選擇在不同階段適合的方案來討論。
如果想在第一時間收到更新，歡迎訂閱弦而時習之在這系列文章更新時收到通知，如果有希望了解的知識，可以利用Rails 部署實踐回饋表單告訴我。