自動化建置在軟體業界中已經被使用非常多年，然而許多工具並不一定容易入門，其中 ＧitLab CI 就屬於相對容易入門的類型，我們可以使用 YAML 格式去撰寫設定。雖然很好上手，但是在功能跟彈性上就比其他工具相對的缺少一些。

採用容器化技術能夠讓我們更加容易的部署到任何環境，相較於過去我們需要使用 Chef 這類工具在新節點加入時進行 Porvision（環境準備）或者預先進行鏡像的製作（像是 AWS 的 AMI 硬碟）等等，使用容易更加容易，那麼我們就沒有理由不進行持續的部署。

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

進入點是一個很容易被忽略的處理，在大部分的容器處理中我們只是將應用（Application）封裝成一個容器鏡像，並且使用命令（Command）來告知容器啟動時該呼叫怎樣的命令運行應用。

然而，這樣的機制存在一些問題，因此我們需要實現進入點（Entrypoint）來做一些處理。

目前大多數的 Rails 專案都還是前端、後端一起開發的，因此我們還需要讓製作出來的容器鏡像能夠將網站運行所需的圖檔、JavaScript 等等製作出來加入到容器鏡像中。

目前我們還沒有搭配持續交付（Continuous Delivery）相關的設計，因此我們先以直接在容器鏡像製作階段製作素材（Assets）的方式。

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

雖然我們已經轉換為 Alpine 來製作容器鏡像，然而在現代軟體設計中為了加速會有許多快取（Cache）的檔案產生，以利再次執行時能夠更快速的啟動。使用 Bundler 安裝 Ruby Gem 也不例外，這些檔案在容器部署中有非常多是不需要的，因此我們還需要針對 Bundler 進行最佳化。

在容器化 Rails 專案概述這篇文章，我們介紹了非常快速的 Rails 容器製作方式，然而這樣的方式除了容器鏡像會非常大之外，也包含了許多我們不需要在正式環境存在的套件，對安全性也會有索影響，因此接下來我們要透過 Alpine 來製作專為正式環境部署打造的容器鏡像。

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

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

在過去傳統的部署方式中，我們大多是單機的方式部署，因此網站如果發生障礙連不上，那麼就可以視為無法使用。

然而當我們有多個網站節點的時候，大多會使用負載平衡（Load Balancer）來將流量分散到不同的節點上，這個時候哪一個節點可以接受流量，就會仰賴健康檢查（Health Check）來回報狀態。