别再手搓环境了：聊聊我们是怎么用 Terraform + Helm 做内部服务模板化的

做过几年运维或者 DevOps 的朋友，大概率都有过这种经历：

新项目上线，流程是这样的：

1. 建 Kubernetes Namespace
2. 写 Deployment YAML
3. 配 Service
4. 配 Ingress
5. 配 ConfigMap
6. 配数据库
7. 配 Redis
8. 配监控
9. 配日志

忙完一圈，突然发现：

80% 的工作都是重复的。

更要命的是，不同项目的人写的 YAML 还不一样。

有人这样写：

resources:
  limits:
    cpu: "500m"

有人这样写：

resources:
  limits:
    cpu: "0.5"

还有人根本不写资源限制。

于是时间一长，公司 Kubernetes 集群就变成了：

YAML 垃圾场。

后来我们痛定思痛做了一件事：

内部服务模板化（Service Template）。

核心思路其实很简单：

Terraform 管基础设施，Helm 管应用模板。

今天就聊聊这个实践。

一、为什么一定要做服务模板化

先说句很实在的话：

DevOps 最大的敌人其实不是技术，而是重复劳动。

很多公司所谓的“自动化”，其实只是：

人工 + 文档

比如：

步骤1：创建Namespace
步骤2：复制deployment.yaml
步骤3：修改镜像

这不叫自动化。

这叫：

手工流水线。

真正的自动化应该是：

terraform apply

然后环境 + 应用直接起来。

这就是模板化的价值。

二、整体架构设计

我们当时的架构大概是这样：

开发者
   │
   │ git push
   ▼
CI/CD
   │
   ▼
Terraform
(基础设施)
   │
   ▼
Helm
(应用模板)
   │
   ▼
Kubernetes

职责划分非常清晰：

一句话总结：

Terraform 管“地”，Helm 管“房子”。

三、Terraform：统一基础设施模板

先说 Terraform。

我们先把所有服务需要的基础设施模板化。

比如一个服务通常需要：

Namespace
ServiceAccount
数据库
Redis
S3 Bucket

Terraform 模块可以这样写：

module "service_base" {

  source = "./modules/service_base"

  service_name = var.service_name
  env          = var.env

}

模块内部大概这样：

resource "kubernetes_namespace" "service" {
  metadata {
    name = var.service_name
  }
}

Redis 示例：

resource "aws_elasticache_cluster" "redis" {

  cluster_id = "${var.service_name}-redis"

  engine = "redis"

  node_type = "cache.t3.micro"

}

这样一个服务上线只需要：

service_name = "order-service"
env = "prod"

Terraform 就会自动创建：

namespace
redis
数据库
存储

基础设施一键完成。

四、Helm：真正的应用模板

Terraform 解决了基础设施问题。

接下来就是应用部署。

这部分 Helm 非常适合。

我们设计了一个 标准 Helm Chart 模板。

目录结构大概是这样：

service-template
  ├── Chart.yaml
  ├── values.yaml
  └── templates
        ├── deployment.yaml
        ├── service.yaml
        ├── ingress.yaml

Deployment 模板示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.service.name }}

spec:

  replicas: {{ .Values.replicaCount }}

  template:
    spec:

      containers:

      - name: app

        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

        resources:

          limits:
            cpu: {{ .Values.resources.limits.cpu }}
            memory: {{ .Values.resources.limits.memory }}

values.yaml：

service:
  name: order-service

replicaCount: 2

image:
  repository: company/order-service
  tag: latest

resources:
  limits:
    cpu: "500m"
    memory: "512Mi"

这样一个服务部署只需要：

helm install order-service ./service-template

五、模板化真正的关键：约束，而不是自由

很多团队做模板化最后都会失败。

原因只有一个：

模板不强制执行。

开发可以随便写 YAML。

结果时间一长：

模板 A
模板 B
模板 C

整个系统又乱了。

所以我们当时做了一件比较“狠”的事情：

禁止直接提交 Kubernetes YAML。

所有服务必须走：

Helm Template

CI 会检查：

if raw_yaml_detected
then
   build_fail
fi

这样所有服务部署都必须使用模板。

慢慢整个公司就统一了。

六、模板化带来的三个巨大好处

这套体系跑了一段时间之后，好处非常明显。

1 新服务上线速度

以前：

1-2天

现在：

30分钟

开发只需要写：

values.yaml

剩下全部自动完成。

2 运维成本下降

以前：

每个服务配置不一样。

现在：

所有服务结构一致。

排查问题的时候：

deployment
service
ingress

都一模一样。

3 平台能力可以统一升级

比如要加：

sidecar
日志采集
service mesh

只需要改：

Helm 模板

所有服务自动升级。

这才是平台化的真正价值。

七、模板化的终极形态：Internal Developer Platform

很多公司做到最后都会走到一个方向：

IDP（Internal Developer Platform）

开发者不再接触：

Terraform
Helm
Kubernetes

而是只写：

service: order-service
language: go
database: mysql
cache: redis

平台自动生成：

Terraform
Helm
CI
监控
日志

一键部署。

这其实就是很多大厂在做的：

平台工程（Platform Engineering）。

最后说点我的真实感受

这些年做运维，我最大的感触其实是：

运维的终极目标是“消灭运维”。

不是裁员那种消灭。

而是：

让系统自己运行。

真正好的平台应该是这样的：

开发只管写代码：

git push

服务就自动上线。

不用申请服务器
不用写 YAML
不用找运维