我們在以容器部署 Rails 的方案介紹了以容器化的方式部署 Rails 專案的方案，然而在部署之前我們還有不少前置準備需要處理。
如果你已經有部署過網站，很可能已經有大部分需要的條件，那麼可以考慮跳過這篇文章。如果是第一次準備部署，那麼可以先來看看這些需要預先準備的東西有哪些。
必要條件
想要部署我們的專案，至少會需要有「伺服器」以及「網域名稱」兩個條件才足夠讓我們可以讓網站完成部署以及被其他人連上。當然，像是信用卡、網路這些條件暫時不在我們討論的範圍內，這裏單純討論的是技術上的條件。
伺服器
伺服器（Server）用簡單的方式來看，可以認為是一個「能夠連上網路持續提供服務」的電腦，以目前的主流來說，我們會採取雲端服務來作為伺服器的方案，畢竟以軟體、虛擬的方式我們能更快、更簡單的產生我們需要的伺服器。
在選用上，我個人主要使用 DigitalOcean的新加坡機房為主要的方案，搭配 Amazon Web Service 作為輔助，以下是我個人會使用的一些服務。
| 名稱 | 簡介 |
|---|---|
| DigitalOcean | 類似簡易版 AWS 硬體條件普通，最接近雲端服務 |
| Vultr | 如果需要日本機房會作為 Digital Ocean 的替代，功能稍弱 |
| Linode | 早期台灣部署網站主流的選用的虛擬主機商，目前作為備用選項 |
| AWS | 最為知名的雲端服務提供商，比較正式的網站會採用 |
市面上還有非常多選項，我自己主要會用的就是這幾家。個人除了無法選用日本機房之外都是很推薦 DitgitalOcean 的，在專案早期可以省下不少花費，雖然沒有 AWS 完善但是基本功能都具備可以使用。
除此之外我還有使用 Cloudflare Works 來做一些 Serverless 的方案，因為不屬於伺服器以及 Rails 部署的範疇，因此我們暫時不討論。
網域名稱
網域名稱（Domain Name）的概念很簡單，我們可以把它當作「地址」的概念，因為單純使用 IP 位址來紀錄要連上哪個網站是很難記憶的，使用網域就能改善這個問題。
除此之外，在同一個 IP 位址上我們還可以利用 Virtual Host（虛擬主機）的機制，利用定義多個 Hostname（主機名稱）來同時服務多個網站，要注意的是 Domain 剛好可以跟 Hostname 用「一樣」的名字，利用這樣的機制來達到虛擬主機的效果，兩者並不是相同的東西。
網域名稱除了用來簡化連上網站的方式之外，也跟 SEO（Search Engine Optimize，搜尋引擎優化）有關，因此建議幫自己或者產品、品牌準備一個適合的網域，以我自己為例個人網站會使用 aotoki.me 的 gTLD（通用頂級域名）如果是簡單的服務會用 aotoki.cloud 來表示，也方便區分自己在提供怎樣的服務。
在台灣有很多廠商都提供了購買網域名稱的服務，國外也有許多知名廠商。以經驗來看 Gandi.net是目前使用體驗最好的廠商之一，除了價格相對台灣廠商低之外，還能夠自己串連 API 管理，唯一的缺點是伺服器可能是在法國的關係，有時候會跑的稍微慢。
SSH 客戶端
因為我們的伺服器大多沒辦法使用物理的方式操作，因此有一個 SSH 客戶端會更方便我們遠端操作這些伺服器。
如果你使用的是 macOS 或者 Linux 的話，你的電腦基本上已經具備對應的功能。在開始部署之前最好先準備好 SSH Key 在後續部署的時候可以使用，如果有設定過 GitHub 帳號並且可以正確上傳程式碼，那麼你的 ~/.ssh/id_rsa.pub 檔案應該會存在，這表示你已經成功設定完畢。
選用條件
大多數時候我們在部署網站時只需要有網域名稱跟伺服器即可，然而還有一些東西可能會需要額外準備，或者在部署的時候一起設置會比較方便一些。
SSL 憑證
現代的網站基本上都預設配備 SSL 憑證用來保護使用者跟網站的連線，一般情況下使用 Let’s Encrypt 的免費服務即可。
然而，假設你希望有額外的保護，還是可以向大部分網域註冊商（大多會一起販售）購買有認證的憑證，這類憑證除了提供保護之外還有類似「保險」的作用，也就是當發生資安問題時，只要符合特定的條件可以獲的理賠。
一般來說我們可以直接使用 Let’s Encrypt 或者雲端服務（例如：AWS ACM）提供的憑證即可，因為有些情況可能會需要「自簽憑證（Self-Signed Certificate）」這類情境，因此在雲端服務廠商中大多會提供上傳自訂憑證的選項。
因為這屬於很細節的部署知識，我們先不在這邊討論這類型的憑證，只需要特別注意憑證的更新時間，使用這類憑證通常都需要人工更換。
域名伺服器
如果是一般使用，直接使用域名註冊商提供的 Name Server 基本上就沒有問題，然而如果有一些特殊需求的話，你可能就會需要有另外的伺服器。
以我個人來說，我會把域名另外放到 Cloudflare 上面，這樣可以獲得基本免費的 CDN（Content Delivery Network，內容傳遞網路）的功能外，也相對域名註冊商的介面還容易編輯 DNS 紀錄以及享受 Cloudflare 的各類功能。
如果網站是預定部署在 AWS 上，則會推薦使用 Route53 服務。在 AWS 的設計下，基本上都會有內部的 DNS 伺服器進行對應，因此可以非常簡單的讓 Route53 幫我們自動跟內部服務串連起來。除此之外如果想要使用 AWS ACM 來產生 SSL 憑證，也能夠自動偵測到 Route53 來進行驗證，而減少人工操作的處理。
也有一些人會將 Cloudflare 跟 Route53 混合使用，這也不在我們部署的討論範圍中，因此也不多做額外的討論。
軟體授權
我相信大部分的 Rails 專案都是使用開放原始碼的套件，或者社群版而非付費版本。然而，如果你有使用像是 Sidekiq Pro 或者 Passenger 這類付費的套件，那麼很有可能需要針對使用的「主機」購買對應數量的授權。
這些授權取決於不同套件的收費方式，如果你有這樣的需求也要記得先將授權準備好，可以的話先測試過一遍，避免在正式部署的時候因為授權問題而卡住。
如果想在第一時間收到更新，歡迎訂閱弦而時習之在這系列文章更新時收到通知，如果有希望了解的知識，可以利用Rails 部署實踐回饋表單告訴我。