Day 27 - 从零开始导入Terraform，Infrastructure as Code Terraform Atlantis

本文同步刊登於个人技术部落格，有兴趣关注更多 Kubernetes、DevOps 相关资源的读者，请务必追踪从零开始的软件工程师之旅，喜欢的话帮我按赞分享、欢迎留言、或是许愿想要看的文章。

如果有技术问题也可透过粉丝专页 讨论，技术方面谘询免钱、需要动手做另计 XD。

需求与问题

随着 terraform 在团队内的规模持续成长，团队需要让工作流程更加顺畅，来面对大量的 tf 变更查核与变更请求。想像几十个工程师同时在修改几十个不同的 terraform projects / modules，这时可能会有几个问题

• 需要一个稳定乾净的环境执行 terraform
  • 工程师的开发本机不是个好选择
  • 需要 24/7 的 terraform 执行中心
    • 执行中心会有各个环境 (dev / stage / prod) 的存取权限，希望设置在内部
• 下列两个工作会切换工作平台，例如 Github
  • review，检视 difference，与讨论
  • PR
• review 完有时会忘记 merge，merge 完有时会忘记 apply
  • repository 越多，忘得越多...

团队已经导入 Git-flow，希望把工作流程做得更完整自动化更加便利

Atlantis 解决方案是与版本控制整合，提供 terraform 执行的 worker，并可以与 Git Host (e.g. Github) 整合做 PR + Review，来达成持续的 CI/CD 远端执行，自动 plan 与自动 apply merge。也就是 Atlantis 帮我们处理以下几件事

• Git-flow
• TODO 自动化 plan
• TODO Webhook 回传 plan 结果
• TODO 透过 bot 控制 apply
• TODO 自动 merge

需求与工作流程

以下的范例使用

• Github 作为版本控管工具
  • 是整个工作流程的控制中心
  • tf code，review，plan，apply 的结果都会在 Github
  • 进一步整合到 Slack 上也非常方便
• Atlantis 放在 Kubernetes 上
  • 使用 helm chart 部署

如果需要其他的版本控制工具或是安装方式，请见Atlantis 官方文件，Atlantis 支援非常多版本控制工具，例如 Github，Gitlab，Bitbucket，...等

整个工作流程

• Github commit push
  • Github event -> Atlantis webhook
  • Atlantis run terraform validate plan
• Github PR push
  • Github event -> Atlantis webhook
  • Atlantis run terraform validate plan
• Github Merge event / main branch push
  • Github event -> Atlantis webhook
  • Atlantis run terraform validate plan
  • Atlantis acquire access to site (dev / stage)
  • Atlantis apply to site
• Github release tag push (eg. 1.2.0-rc)
  • Github event -> Atlantis webhook
  • Atlantis run terraform validate plan
  • Atlantis acquire access to site (dev/stage)
  • Atlantis apply to site (release-candidate / prod)

依据上面的环境，安装需要准备以下几个东西

• Git
  • Git Host 上设定 Atlantis 存取 Git Repository 的权限
  • 为 Git Host 设定存取私钥，让 Atlantis 认证 webhook
• Terraform Backend State storage: Atlantis 需要存取外部的 state storage
• Terraform 使用的版本要注意一下。Atlantis 可以支援不同 repository / project 使用不同版本
• Environment credential (provider credential)
  • Atlantis 会需要存取不同的环境 (dev / stage / prod)
  • 为这些环境独立配置 credential 让 Atlantis 存取

实际 Atlantis 的环境会有

• Docker 作为孤城师本机开发测试使用
• Kubernetes Atlantis
  • 我们的团队会是一个环境一个独立的 Atlantis
    • 安全性：切分各个环境的权限与 Access
    • 各个 Atlantis webhook 只接收属於自己的 event

Docker

使用 Docker 作为本地开发与测试的容器 runtime：

docker pull runatlantis/atlantis:v0.15.0

docker run runatlantis/atlantis:v0.15.0 atlantis \
  --gh-user=GITHUB_USERNAME \
  --gh-token=GITHUB_TOKEN

Helm Chart

Helm 的安装十分简易

helm repo add runatlantis https://runatlantis.github.io/helm-charts
helm inspect values runatlantis/atlantis > values.yaml

更改 values.yaml

github:
  user: chechiachang
  token: ...
  secret: ...

orgWhitelist: github.com/chechiachang/*

安装到 Kubernetes 上

helm install atlantis runatlantis/atlantis -f values.yaml

结果

• 工程师透过 Github 就可以完成所有工作
• 安全稳定的 terraform 执行环境
• 独立的 in-cluster credential，集群的存取权限都控制在集群内，不会暴露到外部环境
• 自动 plan 与 apply，不会遗忘

结果

• 工程师透过 Github 就可以完成所有工作
  • 加上 Github Slack 整合，就完全不用离开 Slack，跟 bot 聊天就可以完成所有 terraform 工作
• 安全稳定的 terraform 执行环境
• 独立的 in-cluster credential，集群的存取权限都控制在集群内，不会暴露到外部环境
• 自动 plan 与 apply，不会遗忘

优劣

优点

• 可以 self-hosted，credential 不外泄，确保最高的安全性
• 已经整合 Kubernetes, helm chart
• webhook 整合许多版本控制库，例如 github, gitlab,...
• 实现安全的远端执行
  • 本地执行还是会有诸多问题
  • terraform cloud 提供的远端执行

缺点，其实没什麽缺点

• 就需要多养一组 Atlantis
  • 使用 stateless deployment，其实是应该不会有什麽负担

Terraform 系列至此应该是全部完结，感谢各位