為了執行Basecamp,37signals打造一款部署工具Capistrano,可以將一隻應用快速部署到大量的伺服器上,開源後很快就成為Rails社群最常用的部署工具。2022年啟動下雲工程後,37signals進一步將Capistrano結合容器化技術,打造出新的部署工具稱為Kamal(舊名是mrsk),同樣開源釋出。

多年前,當37signals開始上雲時,先將資料中心上的應用,搬遷到AWS ECS上,使用Docker來部署容器化的應用,後來,因為ECS靈活度不敷需求,改用Google Cloud的GKE,開始嘗試Kubernetes,又因網路控制的考量,改用AWS的EKS,在雲端Kubernetes環境中執行相關的應用。

因為大部分AP早已是容器化的應用,而且都是命令列執行的應用,所以,一開始規畫下雲時,37signals想直接在本地端機房部署一套Kubernetes環境,取代原本所用的AWS EKS,來保留多年發展的技術成果,只需要將原本的工具指向新的本地端環境。

但是,本地端商用K8s管理工具的軟體授權和相關支援費用,比37signals預期中的費用更高,例如有家開源軟體商一開始報價高達200萬美元,而且再加上AP維運管理相關的配套機制很多,也高度依賴許多後端服務。

一支Rails應用(37signals的AP都是Rails應用)不只是AP的執行,還包括了搭配的輔助工具和機制,相關身分驗證和儲存管理機制,相關的IaC(基礎架構程式碼化)的程式碼等。這些配套的管理機制也需要同樣搬遷到本地端,一一調整或重建,這不只是複製貼上那樣簡單的過程,而是一個高度複雜的任務。

所以,37signals後來決定,不只下雲(de-Cloud),還要去K8s(de-K8s),不在本地端部署K8s來管理相關的容器工作負載調度,改直接使用Docker技術為主,自己打造一套容器化應用的調度管理工具,更極致的簡化基礎設施架構的配置管理,也趁機升級到最新版的Chef,從新設計了整套AP的部署和維運流程。37signals先從架構最簡單,沒有付費用戶的Tadalist,來導入新的部署工具和維運流程。

以Docker為基礎,打造全新Web應用部署工具

他們落地到本地機房後的新技術架構,使用KVM來提供虛擬機器,來分割實體伺服器的運算資源,再透過Docker來執行容器化的Web應用。

為了簡化本地端的部署,37signals打造了全新的Web應用部署工具。

早在2005年,37signals為了執行Basecamp,就打造了一款部署工具Capistrano,可以將一隻應用快速部署到大量的伺服器上,開源後很快就成為Rails社群最常用的部署工具。

在這次下雲過程中,37signals進一步將Capistrano結合容器化技術,打造出新的部署工具稱為Kamal(舊名是mrsk),同樣開源釋出。這個字是古代阿拉伯導航工具的名稱,水手會利用Kamal對準北極星,藉此來修正船隻的航向。Kamal使用Docker來部署和管理Web應用,可以提供不停機部署、快速重新啟動回滾、遠端建置等,Kamal也可說是一套容器化技術版本的Capistrano,而且不只是Rails應用,後來的版本甚至可以用Kamal來部署任何類型的容器化Web應用。

只要在Kamal伺服器清單中,新增一個新的Ubuntu伺服器IP,就可以透過Docker自動配置後立刻執行,不需要事先準備伺服器,像是確認Ruby版本是否正確。使用Kamal來部署37signals的郵件服務Hey,部署一個新版本只需要20秒,也比過去的部署速度快了很多。

在37signals完成下雲時,Kamal也發布了1.0版,採用MIT開源授權釋出,2024年初已經到了1.3版。目前Kamal也發展出了一個自己的開源社群。

Kamal不只可以在裸機上部署Web應用,也可以用來部署雲端環境中的Web應用,這是一款可以通吃本地端和雲端的通用部署工具。

除了新部署工具,37signals也設計了一個新的流程來調度KVM的虛擬機器,用cloud-init簡化了啟動程序,將這些操作指令和配置,寫成了一套慣用劇本,以便重複運用。最後將VM啟動時間,從過去的20分鐘,縮短到1分鐘。

37signals將Capistrano結合容器化技術,打造出一款新的部署工具稱為Kamal,開源釋出。Kamal使用了Docker來部署和管理Web應用,可以提供不停機部署、快速重新啟動回滾、遠端建置等,Kamal也可說是一套容器化技術版本的Capistrano,而且不只是Rails應用,可以用Kamal來部署任何類型的容器化Web應用。

不只部署,還有不少相關下雲技術切換

37signals在下雲過程中,還做了不少技術切換工作,像是在Log日誌管理上,37signals原本就使用了一套完整的ELK技術架構來搜集各種服務的運作log資訊。原本所用的這個ELK架構,是一個可以串接本地端機房或雲端環境的架構,因此切換到本地端環境不難。再加上,Kamal的日誌也都是只有Docker的日誌資料,要將日誌流程切換到下雲的作法不難,只需要改蒐集位在/var/lib/docker/containers/上的Docker日誌檔就可以完成。

另外在CDN和DNS需求的切換上,37signals則是改用Cloudflare來串接本地機房中的F5負載平衡設備,取代了原本所用的CloudFront和Route53等公雲業者的服務。CI/CD工具原本用Buildekite,現在也改用GitHub的Actions。

在資料庫副本和備份機制上,因為在Basecamp產品上,已有十多年的MySQL使用經驗,所以,37signals全面將資料庫副本和備份機制改為MySQL,並升級到Percona MySQL 8。最後,不到6個禮拜,就完成了Tadalist的搬遷和切換。

轉移到本地端後所採用的新部署流程更加簡化,不只是啟動虛擬機器的時間,從過去的20分鐘,縮短到1分鐘,一支標準Rails應用的部署時間甚至從過去的數分鐘,縮短到1分鐘。

從最簡單的AP先下雲,累積經驗再遷移複雜應用

第二個搬遷的產品是基礎架構需求與Tadalist類似的Writeboard,這個產品是一個提供付費版的產品,也使用了更多的資料庫,複雜性比第一款免費工具更高,也得更小心考慮對付費顧客帶來的影響。不過,有了第一款AP的搬遷經驗,再加上資安團隊、基礎架構團隊、效能團隊和應用開發團隊聯手,不到2周就完成了第二款AP的下雲搬家。後續又開始搬遷,技術架構更複雜的AP,像是第三款搬遷的產品是Backpack。

37signals從功能和架構簡單的AP產品先著手,累積下雲經驗,同步建立新的本地端作業流程和配套機制,升級必要的元件,再一步步搬遷更複雜的應用,最後完成了所有的搬遷工作。

37signals歸納,下雲過程,不只降低成本,更帶來了不少技術面的好處。舉例來說。搬遷到本地端後,不只大幅減少了基礎架構的複雜度,也提高了各AP部署策略的一致性,更大幅縮短部署時間。他們還順便清理了不少無效或可棄用的程式碼。搬家工作讓37signals趁機做了不少升級工作,例如將資料庫系統從MySQL 5.7版升級到8,用新版Chef重寫了整個設定管理機制,也依據自身需求設計了快速啟動的VM配置。

雖然,一開始難以實現本地端K8s的計畫,37signals的下雲計畫,花了一番時間來打造全新的本地端維運和部署架構,因為過去累積了大量容器化的經驗,最後打造出全新的Web應用部署工具Kamal,在2023年2月,完成了這個下雲最關鍵的技術轉換準備。

下一步優化目標是搜尋和監控

下雲不只是降低成本,也大幅減少了技術架構的複雜度,更讓37signals的維運團隊打開了新的思考視野,不只可以重新思考應用程式的運作模式。他們開始思考後端搜尋、監控機制的新可能性,這是37signals在下雲、去K8s歷程的下一個要挑戰的優化目標。

 相關報導 

知名SaaS公司為何要下雲?37signals應用搬家歷程大公開

37signals一年320萬美元上雲費用結構大公開

熱門新聞

Advertisement