關於 #Rails 的內容

當我們從 Docker Compose 轉換到 Docker Swarm 之後，仍然還是面臨需要人工進行部署操作的狀況，因此我們還需要更近一步的利用 GitLab CI 來幫助我們解決部署的人工操作。

部署的環境已經準備好後，我們就可以來將之前所撰寫的 Docker Compose 設定檔轉換為 Docker Swarm 支援的格式，以及調整我們的架構來讓專案可以被部署到 Docker Swarm 上面。

要使用 Docker Swarm 還是需要進行一些設定，相比過去的 Docker Swarm 這幾年使用上容易許多，基本上只需要兩個命令就可以完成安裝。

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

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

為了要能夠實現持續部署，我們除了將專案準備好之外，還需要能夠將 Rails 自動的部署到我們想要部署的伺服器上。

採用容器技術的話就不需要煩惱環境的問題，只需要有能夠運行容器的環境即可，在測試環境或者簡單的小專案就可以使用 Watchtowner 來幫助進行部署，是一種非常簡單又快速的方式。

GitHub Actions 跟 GitLab CI 有著不少差異，雖然在這類工具中不外乎就是生產線（Pipeline）和任務（Task）的搭配使用，然而每套系統都還是有著不同的設計可以使用。

因為我比較常使用 GitLab CI 因此有著完整的樣板專案可以使用，目前還在建置 GitHub Actions 的樣板，這篇文章主要是我在 GitHub 上面的專案所彙整出來的使用技巧。

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

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

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

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

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