Rails 實踐部署 - 使用 Alpine 製作容器鏡像
在容器化 Rails 專案概述這篇文章,我們介紹了非常快速的 Rails 容器製作方式,然而這樣的方式除了容器鏡像會非常大之外,也包含了許多我們不需要在正式環境存在的套件,對安全性也會有索影響,因此接下來我們要透過 Alpine 來製作專為正式環境部署打造的容器鏡像。
Pager 2
在容器化 Rails 專案概述這篇文章,我們介紹了非常快速的 Rails 容器製作方式,然而這樣的方式除了容器鏡像會非常大之外,也包含了許多我們不需要在正式環境存在的套件,對安全性也會有索影響,因此接下來我們要透過 Alpine 來製作專為正式環境部署打造的容器鏡像。
雖然我們已經轉換為 Alpine 來製作容器鏡像,然而在現代軟體設計中為了加速會有許多快取(Cache)的檔案產生,以利再次執行時能夠更快速的啟動。使用 Bundler 安裝 Ruby Gem 也不例外,這些檔案在容器部署中有非常多是不需要的,因此我們還需要針對 Bundler 進行最佳化。
經過兩週的努力,我們已經可以製作出能夠運行 Ruby on Rails 的環境,然而這個狀態的環境依舊同時混合了「編譯」跟「運行」兩種狀態的套件,在過去我們需要透過 RUN
合併命令來清理,然而在新版的 Docker 提供了「多階段建置(Multi-Stage Build)」的選項,因此我們可以直接切割開來處理。
目前大多數的 Rails 專案都還是前端、後端一起開發的,因此我們還需要讓製作出來的容器鏡像能夠將網站運行所需的圖檔、JavaScript 等等製作出來加入到容器鏡像中。
目前我們還沒有搭配持續交付(Continuous Delivery)相關的設計,因此我們先以直接在容器鏡像製作階段製作素材(Assets)的方式。
進入點是一個很容易被忽略的處理,在大部分的容器處理中我們只是將應用(Application)封裝成一個容器鏡像,並且使用命令(Command)來告知容器啟動時該呼叫怎樣的命令運行應用。
然而,這樣的機制存在一些問題,因此我們需要實現進入點(Entrypoint)來做一些處理。
將 Rails 專案進行容器化,或者搭配容器化技術應用的情境很多,這邊介紹幾個比較有趣跟方便使用的案例,大家可以比較一下差異跟使用上的體驗。
採用容器化技術能夠讓我們更加容易的部署到任何環境,相較於過去我們需要使用 Chef 這類工具在新節點加入時進行 Porvision(環境準備)或者預先進行鏡像的製作(像是 AWS 的 AMI 硬碟)等等,使用容易更加容易,那麼我們就沒有理由不進行持續的部署。
自動化建置在軟體業界中已經被使用非常多年,然而許多工具並不一定容易入門,其中 GitLab CI 就屬於相對容易入門的類型,我們可以使用 YAML 格式去撰寫設定。雖然很好上手,但是在功能跟彈性上就比其他工具相對的缺少一些。
GitHub Actions 跟 GitLab CI 有著不少差異,雖然在這類工具中不外乎就是生產線(Pipeline)和任務(Task)的搭配使用,然而每套系統都還是有著不同的設計可以使用。
因為我比較常使用 GitLab CI 因此有著完整的樣板專案可以使用,目前還在建置 GitHub Actions 的樣板,這篇文章主要是我在 GitHub 上面的專案所彙整出來的使用技巧。
為了要能夠實現持續部署,我們除了將專案準備好之外,還需要能夠將 Rails 自動的部署到我們想要部署的伺服器上。
採用容器技術的話就不需要煩惱環境的問題,只需要有能夠運行容器的環境即可,在測試環境或者簡單的小專案就可以使用 Watchtowner 來幫助進行部署,是一種非常簡單又快速的方式。