為了執行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應用。
為了盡可能地簡化部署工作，37signals後來決定不用Kubernetes或Docker Swarm部署自家的應用，雖然Docker Swarm的架構比K8s簡單得多了，但是Docker Swarm仍舊是以透過狀態協調來實現的宣告式部署模式，這樣仍有一定的複雜度。37signals自行開發的Kamal則是設計成命令式的指令，只需要呼叫最基礎的Docker指令，就能進行。一個口令一個動作，清清楚楚，也可以更有效率。
而是直接使用Dco因為相關資訊都儲存在Docker映像檔中，只要維運人員在Kamal伺服器清單中，新增了一個新的Ubuntu伺服器IP，再提供SSH金鑰，就可以透過Docker自動配置後立刻執行，不需要事先準備好伺服器，像是確認Ruby版本是否正確或是其他相依性問題的檢查。以DHH自己的經驗來說，他們使用Kamal來部署37signals的郵件服務Hey，部署一個新版本只需要20秒，也比過去的部署速度快了很多。
DHH指出，各種商用SaaS服務的蓬勃發展，讓Web應用程式的部署比過去更容易了，Kamal的願景是致力於讓你可以到任何地方部署Web應用。Kamal也會只用開源技術來實現，而不會綁定到任何的商用產品上。
在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歷程的下一個要挑戰的優化目標。
相關報導
熱門新聞
2024-12-24
2024-12-22
2024-08-14
2024-12-20
2024-11-29
