關於 #Ruby on Rails 的內容

最近剛好被人問到使用 Ruby on Rails 應該如何開發遊戲，因為是個很有趣的題目所以就利用週末的時間來簡單討論一下這個問題。雖然是以 Ruby on Rails 作為案例，不過這些經驗大致上是適用於所有程式語言的。

當我們的 Rails 專案邊複雜的時候，Form Object 算是一個常見的方法。不過網路上的教學似乎大多都沒有能夠相容 Rails 的 Form Helper 的版本。

所以我就開始思考，有沒有辦法法在比較少的修改下去支援 Form Helper 呢？

大概一年前左右，我開始製作一個 Ansible 的 Playbook 來幫五倍紅寶石的客戶安裝環境。

不過當我們的客戶增加之後，其實開始有點變的很難透過 Fork 的機制來管理不同客戶的 Playbook。

這表示我必須先更新主要的 Playbook 然後再同步到每一個客戶的版本上，也因此我決定去把這些通用的部分拆成單獨的 Role 專案。

去年雙十一活動的時候有一個算是比較急的專案是要做活動網站，當時評估了一下之後決定來嘗試透過 CI 自動生成 GCE 的自訂映像檔然後搭配 Auto Scale 來做部署。

會選擇這樣的方式主要是因為 Rails 或者大多數開發框架的部署工具預設大多是不適合 Auto Scale 的，像是 Capistrano 大多數是手動填入伺服器位置（之前也有實作過透過 GCP API 自動填入）比較適合雲端服務的作法其實就是是製作成一個映像檔來處理，也因此像是 Docker Image 這類型容器化技術在這方面是相對容易做的。

不過考量到容器化本身也還有一些調整問題才適合使用，再加上雲端服務的選擇是使用 GCP 來提供服務，並不像 AWS ECS 有專門針對容器的服務（可能是我不知道）而是提供 K8S 的方案，對一個短期活動來說在整個專案成員都沒有經驗的前提下學習成本還是偏高的。

因此相對適合的做法是用之前我準備好的 Ansible 腳本，搭配 Packer 這套工具直接在 GCP 上面生成一個自訂的映像檔然後直接更新 Instance Group 的設定讓他以新版本 Scale 起來，就能做到基本上網站不斷掉的更新（Health Check 和 Scale 規則需要調整好）

我們大概花了約一天多的時間快速搭起來，這次的開發時間約兩週中間是透過放額外的人力去支援搭建這個部署流程。

今年把在六月到八月做的一個小專案拿去投稿 Ruby World Conference 意外的獲得了 15 分鐘的時間，於是又展開了一次日本出差之旅，剛好彌補一下今年因為客戶專案需要趕上線而無法參加 RubyKaigi 的遺憾。

跟 RubyKaigi 不太一樣的地方是 Ruby World Conference 雖然叫做「World Conference」但是除了台上的講者之外，幾乎都是日本人（而且是稍微有年紀的大叔）去參加的。

六月底的時候發現巴哈姆特似乎想為他們推出的 Messaging APP （哈哈姆特）舉辦一個聊天機器人的比賽，看到之後想說還算蠻有趣的，所以我就跟朋友很隨意的組成一個團隊來開發。

跟大多數我們熟悉串接 Chatbot 的機制是類似的，我們可以用 Webhook 的方式接收一個來自使用者發送的訊息，然後再透過程式處理後回傳訊息給使用者。

前面幾篇文章已經把所有關於 Ruby 和資料庫都設定完成，最後一個階段就是要把 Nginx 設定好，並且讓 Let’s Encrypt 可以正確的被設定，讓網站支援 SSL 功能。

現在伺服器還沒辦法下載到 Ruby on Rails 專案的原始碼用來部署，這一篇會介紹該如何把原始碼下載回來，並且在伺服器上將相關的 Ruby Gem 都安裝好。

經過前面五篇的教學，我們距離將 Ruby on Rails 部署到伺服器上越來越接近了。上一階段我們在本機段將部署的設定做完之後，這一篇文章會回到伺服器將部署所需的設定補齊，讓 Capistrano 可以正確的將程式碼部署到伺服器。

到第四篇為止，我們已經有了可以運行 Ruby on Rails 的環境，不過到底該怎麼在伺服器上跑起來呢？

絕對不是把程式碼複製到伺服器這種簡單的做法，或者說這樣的做法在更新上是很沒有效率的！