弦而時習之

TGONext: 追蹤和技術債

在 TGONext 期間我們基本上有 4 ~ 5 次的聚會,而這次算是表定上的最後一次聚會。在可能是最後一次的聚會,我們先討論了幾個原本沒有要討論的主題。

這次聚會中,我們會討論關於日誌追蹤跟如何處理技術債。

做一個 Rails Form Helper 相容的 Form Object

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

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

TGONext: 資料庫變遷跟架構改變

這次在開始討論關於架構的主題之前,我們的倒是讓我們提出一些問題。

剛好在兩次聚會的期間,我的客戶因為一些錯誤的計畫讓 Migration 失敗了,所以我提出了關於在不停機的狀況下做 Migration 的規劃問題。

TGONext: 從缺點選擇架構

這次聚會我們先簡單的回顧一下上一次的討論,然後就切換到了下一個主題。基於前一次聚會高併發的討論,我們模擬一個簡單的架構然後開始演進。

重複利用的 Ansible Role 難題

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

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

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

TGONext: 規劃高併發服務

昨天是 TGONext 的第一次聚會,在這個活動中我們會向台灣的一些高階主管學習。在開場結束後我們的導師 Ant 讓我們投票選出幾個想在這半年的時間內討論的題目。基本上我們預定討論四個主題,而「高併發」是我們的第一個主題。

撰寫一個合適的 RSpec 測試

包括我自己在內,寫測試有時候是一個非常不想面對的工作。也有很多剛入門的工程師覺得很難去分辨該怎麼去寫測試,在今天跟同事說明完一些技巧後就決定來寫一下這篇分享一下我自己的經驗。

淺談在 Google Cloud Platform 讓 Ruby on Rails 實現簡單的 Immutable Infrastructure 部署

去年雙十一活動的時候有一個算是比較急的專案是要做活動網站,當時評估了一下之後決定來嘗試透過 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 規則需要調整好)

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