为了执行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历程的下一个要挑战的优化目标。
相关报导