从 Docker Compose 到 Terraform：Web3 基础设施的真实演进之路

大多数 Web3 项目最初并未使用复杂的底层设施。真的没有。

在早期，通常只是 Docker Compose 在承担重任 —— 启动后端、数据库，如果你更有野心的话，可能还有 Redis。它在你的机器上运行，也许是在一台服务器上，这足以让项目运转起来。

老实说，这正是它本该有的样子。

在那个阶段，速度比结构更重要。你正在测试想法，而不是为了规模化而构建。

但情况会发生变化。

一旦真正的用户出现 —— 或者更糟糕的是，真正的流量 —— 你的设置就开始出现裂痕。部署感觉不一致。Scaling 变成了一个手动的、略微令人压力倍增的过程。安全？它确实存在……但并不是以你完全信任的方式。

这时你意识到：问题不再是你的代码了。

而是它周围的系统。

而这正是转变开始的地方。

Docker 帮助你运行程序。

Terraform 帮助你构建这些程序运行的地方。

Docker 对比 Terraform（不复杂化）

很多人会把这两者混淆。这是很容易犯的错误。

Docker 是关于打包你的应用，使其在任何地方的表现都一致。没有意外。

Terraform 是关于创建应用生存的环境 —— 服务器、网络、权限，等等。

如果你只需要记住一件事：

Docker = 你的应用

Terraform = 你的应用周围的一切

为什么 Docker Compose 运作得如此出色（起初）

几乎每个人都从这里开始是有原因的。

只需一条命令，你就拥有了：

• 后端正在运行
• 数据库已启动
• 缓存已就绪

没有冗长的设置文档。没有奇怪的环境不匹配。新开发人员可以毫无压力地加入。

这在早期是一个巨大的胜利。

哪里开始出现故障

问题不会立即显现。它们是悄悄潜入的。

也许你正在通过 SSH 进入服务器来修复某些问题。

也许 Staging 环境的表现与 Production 环境略有不同（而且没人知道原因）。

也许 Scaling 仅仅意味着“让我们再启动一个实例并希望它能奏效”。

在出大问题之前，这些看起来都不是什么大事。

常见的痛点如下：

• 基础设施存在于版本控制之外
• 没人记录的手动修复
• 安全规则散布在各处
• “在我的机器上能运行”以新的形式回归

在某些时候，它变得无法管理。

思维转变：从服务到系统

这是人们低估的部分。

你不再仅仅是在运行容器。你正在管理一个由相互依赖的移动部件组成的系统。

现在你关心如下事情：

• 服务之间如何通信
• 你的数据究竟存储在哪里
• 谁拥有什么的访问权限
• 当某些东西失败时会发生什么

而手动完成这一切？那是无法扩展的。

这正是 Terraform 开始发挥作用的地方。

Terraform（不再令人生畏）

乍一看，Terraform 看起来……有点抽象。

但它在原理上其实很简单：你描述你想要什么，Terraform 会弄清楚如何将其变为现实。

就像这样：

provider "aws" {
  region = "ap-south-1"
}

resource "aws_instance" "app" {
  instance_type = "t3.micro"
}

就是这样。你正在用代码定义基础设施。

而且这些好处会悄然而至：

• 你可以跟踪每一次更改
• 你可以轻松地重建环境
• 你不再依赖记忆或猜测

Docker + Terraform：并非非此即彼

这不是一个替代的故事。

你不是“从 Docker 转向 Terraform”。你是开始将它们结合使用。

Docker 处理应用层。

Terraform 处理底层的一切。

一个典型的流程最终看起来像：

• 将你的应用构建成 Docker Image
• 将其推送到某个地方（如 Registry）
• 使用 Terraform 调配基础设施
• 将该 Image 部署到其上

突然之间，事情变得……一致了。

生产环境中的 Web3 系统究竟是什么样的

当你进入生产阶段时，你的系统不再简单 —— 这很正常。

记住我以实现更快登录

你正在处理：

• 区块链 RPC 提供商
• 处理逻辑的后端服务
• 存储状态的数据库
• 加速运行的缓存
• 使区块链数据可用的 Indexer
• 通过 CDN 交付的前端

每个部分都有自己的工作。而且重要的是，它们不应该全部紧密耦合。

一个干净的划分通常看起来像：

• Terraform → 基础设施
• Docker → 应用服务

这让事情保持理智。

安全（人们拖延太久的事情）

很多团队都会推迟这件事。这是一个错误。

一旦进入生产阶段，安全就不再是可选的了。

一些非常有用的基础知识：

• 不要硬编码密钥（认真地）
• 锁定你的 Terraform 状态
• 使用更小、更安全的容器镜像
• 限制哪些服务可以相互通信
• 保持环境隔离

这些都不令人兴奋 —— 但它们都很重要。

CI/CD：一切汇聚之处

如果你在这个阶段仍在手动部署，那将会很痛苦。

自动化不仅是锦上添花 —— 它是防止事情出错的关键。

一个典型的设置：

• 推送代码
• 构建 Docker Image
• 存储它
• Terraform 计划变更
• 自动执行部署

最大的好处？更少的“糟糕”时刻。

反复出现的错误

你会看到不同团队中出现相同的模式：

• 将 Docker Compose 视为生产工具
• 在云控制台点击操作而不是使用代码
• 忽视安全直到出现问题
• 将基础设施逻辑与应用逻辑混合
• 不跟踪基础设施的变化

这些都不会立即导致失败 —— 这就是为什么它们存在的时间比应有的更长。

什么时候该进行转变

你不需要在第一天就使用 Terraform。

但当你遇到以下情况时，你可能需要它：

• 你的应用有多个移动部件
• 停机时间开始变得重要
• 更多的人加入你的团队
• 你在认真考虑 Scaling
• 安全成为一个真正的担忧

这通常就是转折点。

结语

Docker Compose 让你起步。而且它在那个岗位上做得非常好。

但在某些时候，你会超越它。

Terraform 不会取代你已经构建的东西 —— 它赋予其结构。它将一个可以运行的设置转变为可靠的东西。

一旦规模扩大，这种差异就会变得非常明显。

关于 Ancilar

让 MVP 运行是一回事。在实际使用下保持其稳定完全是另一回事。

这就是良好的基础设施决策开始变得重要的地方。

Ancilar 与那些正在度过早期阶段并需要以下支持的团队合作：

• 可扩展的基础设施
• 干净的部署流水线
• 不会在增长压力下崩溃的系统

如果那是你的目标：

https://www.ancilar.com/hire-developer

Email: hello@ancilar.com

Website: https://www.ancilar.com

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～