DocSpring 创始人回顾在 Convox 上运行八年的经历

所有文章 2026年11月14日 · 8 分钟阅读 · Nathan Broadbent Convox 是运行在你自己的 AWS 账户里的、类似 Heroku 的 PaaS。我们从 2018 年起就在 Convox 上运行 DocSpring。

2018 年，我把 DocSpring 从 Heroku 迁移到了 AWS。（那时它还叫 FormAPI。）我们拿到了一些免费的 AWS 额度，我想用掉它们，又不想自己动手搭一个部署平台。Convox 直接给了我一个能用的平台：描述应用、部署，然后回去继续做产品。

Convox 之于基础设施，就是约定优于配置。我从一个还没完全理解其实现细节就能使用的平台起步，后来从这个实现里学习，接手了更多 Terraform 配置，并按我们的需求做了调整，同时保留了原有的应用工作流。

这是我 2018 年 7 月在 Hacker News 上写的关于这次迁移的评论。当时我对滚动部署和能用上 AWS 额度这件事很兴奋。自那以后，我们的基础设施从 ECS 迁移到了 Kubernetes，我们建立起了自己的安全与合规控制，也加上了自己的访问层。

Convox 由 David Dollar、Noah Zoschke 和 Matt Manning 创立，三人都来自 Heroku。所以如果你用过 Heroku，会觉得 Convox 非常熟悉。Convox 把平台的一次安装称为一个 rack。开源版 rack 采用 Apache-2.0 许可证，运行在你自己的云账户里，并且有文档化的 CLI 安装路径。独立的 Convox Console 增加了 Web 界面和团队工作流，有免费和付费方案。rack 可以单独使用。

如今，我们的团队在美国运行一个生产 rack，在欧洲运行另一个，还有一个 staging rack。我们还帮助一些 Enterprise 客户维护他们的 Convox rack。

对于一个 Rails 应用，你通常需要一个 web 进程和一个后台 worker，以及一些定时命令。Convox 让你在 convox.yml 里描述这些。

下面这份简化配置假设已有一个 Rails 应用，带有 Dockerfile、Sidekiq、位于 /up 的健康检查端点，以及一个 reports:daily 的 rake 任务。它的数据库和 Redis 是单独提供的：

environment:

• RAILS_ENV=production
• SECRET_KEY_BASE
• DATABASE_URL
• REDIS_URL services: web: build: . command: bundle exec rails server -b 0.0.0.0 -p 3000 port: 3000 health: /up scale: count: 2 worker: build: . command: bundle exec sidekiq timers: daily-report: schedule: "0 3 * * *" service: worker command: bundle exec rake reports:daily

这份配置声明了两个 web 进程和一个 worker。定时器会在 UTC 03:00 使用 worker 服务的配置启动一个独立进程。没有默认值的环境变量条目必须通过应用的配置提供，它们的值不会出现在这个文件里。

CLI 会记住你选中的 rack，并从你当前所在的目录中选取应用：

convox deploy convox logs convox run web bundle exec rails console

第一条命令构建容器，创建一个把本次构建与应用环境变量配对的 release，并通过滚动部署将其上线。新进程启动并通过健康检查，同时旧进程被替换。启动失败或健康检查失败可能导致这次发布回滚到上一个 release。其余命令让你跟踪应用日志、启动 Rails 控制台。

convox.yml 清单还负责自定义域名、资源限制和自动扩缩容，Convox 会管理 Let's Encrypt 证书。它的 resources 可以创建数据库和缓存：postgres 运行在容器里，而 rds-postgres 创建由 AWS 托管的数据库。你也可以连接自己单独管理的数据库。

我刚开始时对 AWS 和 DevOps 并没有多少经验。通过研究 Convox、弄清楚如何修改和扩展它，我学到了很多。

Convox v2 使用 CloudFormation 和 Amazon ECS。2020 年 2 月，Convox 发布了基于 Kubernetes 的多云平台，通过 Terraform 安装。在 AWS 上，v3 使用 EKS，即 Amazon 的托管 Kubernetes 服务。它还支持 Google Cloud、Azure 和 DigitalOcean。

当我想要添加 CloudWatch 配置、自定义证书 DNS 验证时，我开始直接管理我们 rack 的 Terraform。我还希望我们的数据库和存储基础设施在同一个地方管理。从 Convox 起步意味着，我可以在一个已经能正常工作的应用平台周围做这些改动。

Convox 的 AWS 系统模块把集群、rack API 和日志整合在一起。它的 cluster 模块管理网络和 EKS。节点默认运行在 NAT 网关后面的私有子网中；管理端点有单独的访问设置。

你可以在自己的基础设施仓库中使用这些模块。下面这段摘录把模块和 rack release 固定在一起，并为新 rack 选择 Contour ingress controller：

module "rack" { source = "git::https://github.com/convox/convox.git//terraform/system/aws?ref=3.26.0" name = "example-staging" region = "us-east-1" release = "3.26.0" private = true router_type = "contour"

这些示例使用 Convox 3.26.0。我们目前的部署使用基于 3.25.14 定制的基础版本。一套完整的 Terraform 配置还需要凭证、状态存储和访问配置。

最终我自己写了相当多的自定义 Terraform。到那时，我对所改动的东西理解得多了很多，而且我们的工作流底层仍然是 Convox 的构建、release 和应用 API。（我也用 Terraform 管理 Cloudflare、Tailscale、CircleCI、我们所有的监控工具以及许多其他东西。）

我们的 SOC 2 工作带来了对个人权限、敏感操作审批以及操作留痕的要求。我们选择构建 Rack Gateway，一个独立的 Convox API 代理，并通过我们私有的 Tailscale 网络访问它。这些是我们自己工作流的附加组件；新的 Convox rack 并不需要它们。官方的 Convox Console 根据方案不同，提供自己的团队访问和审计功能。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）