改良、辛味和处方箋的后来者🌶
这篇文章是关于的
这是 RetailAI X Advent Calendar 2022 的第三天文章。
讲述了使用 Terraform + Config Controller 运营基础设施即代码（IaC）的经历。
如您已所知，Terraform 在环境构建的可再现性方面非常有用。然而，维护和管理 tfstate 非常繁琐。出于希望简化运维工作的愿望，下面将描述我们所达到的当前状态。
为什么使用 Terraform 很困难呢？?
如果有人在 GUI 上进行更改，那么最大的困难就是需要收集（同步 tfstate）。如果不能正确收集，就可能导致冲突，最糟糕的情况是可能会删除资源。
因此，并不是每个人都可以编辑或应用 .tf 文件，因此必须允许使用 GUI 进行更改。
过去的运营流程
对于关键任务的系统来说，不能轻易地执行terraform apply。
同时，恢复操作则是迫在眉睫的。
这个任务的难度极高。
所以，我对Config Connector进行了重新考虑。
实际上，在Config Connector 宣布推出的时候，
我曾经想过，“为了 IaC，是否真的需要一个 Cluster 呢，或许 Terraform 已经足够了吧 ?”。
为什么选择 Config Connector？?
tfstate文件被释放出来，不再保持。同时，从计划/应用循环中解放出来。
-
- Config Connector は、状態を宣言します。Status ファイルは、存在しません。
-
- k8s の知識を活用できます。
-
- Config Connector では、k8s の namespace を Project や Folder として扱います。
-
- Multi Project を管理する場合は、Project が namespace として並びます。
- Project と GKE の位置関係が逆転しているような。個人的に面白いと思う構成です。
Config Connector的过程
-
- 启用Config Connector并创建集群。
-
- kubectl在config-control命名空间下获取ConfigConnectorContext。
创建Manifest。
vi tokyo-bucket.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
annotations:
cnrm.cloud.google.com/force-destroy: “false”
name: sanbox-danny
namespace: config-control
spec:
location: asia-northeast1
应用。
kubectl应用tokyo-bucket.yaml。
非常简单。
而且，您不需要关注整个项目的状态。
您可以将重点放在添加资源上。
此外，它还能够解决我们过去一直闭着眼睛的以下问题：Terraform Cloud 的管理。
-
- Terraform Cloud（ Free ）の課題
User 数の制限
セキュリティ（認証）
Concurrency の制限
通过使用 Config Connector，可以不再需要 Terraform Cloud。
Terraform Cloud 在 2019 年开始使用，当时考虑了谷歌云和 Azure 的多云环境。起初只是一个概念验证，并一直沿用至今。
有关 Config Connector 的案例有吗？
在Mercari网站上已公开了相关案例。这可能不是Managed模式。
最后
现在，对于Terraform的关注度非常高。
根据GitHub发布的年度报告《Octoverse 2022》，我们可以看到GitHub在过去一年的使用趋势等。
据说，编程语言中急剧增长的是用于Terraform等的HCL。
但与此同时，我想很多人都可以感受到我的困惑。
如果您能共鸣，或者有其他解决方法，我会非常高兴能够听到您的评论。
明天第四天的文章是由@wu_manning先生撰写的“next.js初学者入门文章”。请期待！
