關於 #容器 的內容

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

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

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

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

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

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

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

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

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

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

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

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

Ruby on Rails 至今為止一直都是快速開發網站的首選框架之一，雖然我們可以利用 Rails 快速的製作網站，然而在部署上依舊還是要 DevOps 透過手動的方式部署伺服器、更新才能夠進行測試或者發布。

那麼，我們是否有更好的方式來解決這樣的問題呢？

今年 COSCUP 的時候前同事 Cindy 分享了 Rails 容器化最佳實踐 這場演講，裡面提到我們在五倍紅寶石在將 Ruby on Rails 專案轉換為容器的一些技巧。

這系列文章會分享一下這個容器化的過程是怎麼判斷、處理以及在過程中需要注意哪些事情。