關於 #Docker 的內容

最近在社群網站寫到「容器數量越來越多，該從 Docker Swarm 轉換到 Nomad 上」的訊息，然後就被問到這幾年來只要是這類問題，畢竟會被問的「為什麼不用 Kubernetes？」的問題。

將 Rails 專案進行容器化，或者搭配容器化技術應用的情境很多，這邊介紹幾個比較有趣跟方便使用的案例，大家可以比較一下差異跟使用上的體驗。

經過兩週的努力，我們已經可以製作出能夠運行 Ruby on Rails 的環境，然而這個狀態的環境依舊同時混合了「編譯」跟「運行」兩種狀態的套件，在過去我們需要透過 RUN 合併命令來清理，然而在新版的 Docker 提供了「多階段建置（Multi-Stage Build）」的選項，因此我們可以直接切割開來處理。

完成網站部署後，我們還需要持續的更新網站。然而如果只有一個節點的話，網站是會有一瞬間服務暫停的狀況，為了避免這樣的問題可以採取滾動更新（Rolling Upgrade）的方式處理。

過去我們需要仰賴人工切換，然而到了虛擬機、容器的階段就能夠透過預先安裝好環境來做到半自動、自動的處理。

現在我們已經有建置好的專案鏡像並且可以被任意伺服器存取，同時也有了能夠運行容器的環境（以 Docker 為基礎）接下來只需要將我們的專案運行起來即可。

要將網站使用容器技術部署，就需要有可以運行容器的伺服器。要滿足可以提供其他人連上使用、隨時提供服務以及能夠運行容器，選擇雲端服務上的 Linux 伺服器會是最適合的選項。

在 Rails 部署實踐 - 容器化 Rails 專案概述中，我們快速的介紹了將專案容器化的入門技巧，雖然我們可以製作出能夠運行的鏡像，卻沒辦法將它傳送到我們想要部署的環境中。

這篇文章會向大家介紹如何讓我們的伺服器可以獲取要部署的鏡像，並且加以部署。

要將 Ruby on Rails 透過容器的方式部署，我們就需要讓我們的專案可以被容器化。這篇文章我們會採用最簡單的方式進行容器化，扣除掉有使用特殊的 Ruby Gem 的情況下，大多能夠透過這種方式完成容器化。

過去幾年，使用容器技術（Container）來部署 Ruby on Rails 專案已經變成我個人最喜歡的方式之一。除了生態系完整之外，也有著容易安裝、部署環境，並且可以很好的維持部署環境乾淨的優點存在。

基於這樣的理由，在 Rails 部署實踐這一系列，我們會由 Rails 的容器部署方案最為起點開始討論可以使用的部署方案。

在Ruby on Rails 容器化最佳指南（一）我們已經大致說明了製作容器的目的、用途，這篇文章會跟大家介紹如何去撰寫 Production-ready（正式環境）可用的容器鏡像。

如果不想花太多時間在了解細節的技巧上，可以參考如何在幾分鐘內容器化 Rails 專案這篇文章，裡面有有針對容器化所製作的 Ruby Gem 可以快速解決這方面的問題。