HashiCorp发布了用于 Kubernetes 的 Terraform 操作符(Alpha 版本),用于将基础设施作为代码予以管理。安装该操作符之后,用户可以使用 Kubernetes 清单同步 Terraform 工作空间。然后,运行于 Kubernetes 中的应用程序就可以使用 ConfigMaps 引用 Terraform 输出了。目前,该操作符只适用于 Terraform Cloud。
因为开发人员希望使用 Kubernetes 接口在 AWS SQS 中像队列一样提供基础设施,该 Terraform 操作符正是出于实现这一需求。首先,用户需要在他们的 Terraform Cloud 组织中创建一个令牌(免费和付费版均可),并将其作为密钥保存在 Kubernetes 中。然后,用 Helm 安装这个操作符。一旦它运行起来,用户就可以开始使用 Kubernetes 清单创建 Terraform 工作空间了。该操作符可以创建、更新和检索源自于 Terraform 工作空间的值,在 Terraform 云中执行 run,并在 Kubernetes 中更新 Terraform 工作空间状态。
为了提供基础设施,需要首先定义一个 Terraform 模块,以便 Kubernetes 只为该模块发送输入参数。开发人员既不定义 Kubernetes 清单中的 Terraform 模板,也不与之交互。这样做旨在简化设计,并减少集群中自定义资源定义(crd)的数量。开发人员创建 Terraform 工作空间清单,并为想要使用的每个 Terraform 模块输入定义值。如果基础设施资源准备就绪,开发人员可以通过 ConfigMaps(如 AWS SQS 端点)访问模块输出,之后可以引用运行在 Kubernetes 中的应用程序中的定义的值。
对于 Terraform 工作空间对象中的每一处变更,除了 AWS 密钥之类的敏感信息之外,该操作符都会提取出来,并使用 auto-approve 参数自动应用。另外,若要删除资源,用户可以通过运行 kubectl delete workspace sqs-queue 命令,使用 Kubernetes API 删除 Terraform 工作空间。
在内部,Terraform 工作空间控制器将协调 Kubernetes 工作空间 CRD 与 Terraform 云工作空间。若要执行变更,可运行 terraform apply -auto-approve 自动执行,但是用户可以在应用它们之前使用 Sentinel 进行验证。出于安全考虑,该操作符的作用域限定于命名空间。用户需要通过访问令牌才能与 Terraform Cloud 交互,只允许访问命名空间可以降低风险。
在这个 Alpha 版中,该操作符只对 Terraform Cloud 有效。HashiCorp 的开发大使 Rosemary Wang 在最近的一次虚拟办公会中说:我们将它的应用范围限定于 Terraform Cloud,因为我们想彻底了解它的表现,不想给这个操作符添加太多的逻辑。如果社区需要对其他后端(如 AWS S3)的支持,Wang 希望 Terraform 开源版本的用户在 GitHub 库中提出问题,解释其应用场景。
此外,该 Terraform 操作符可以为本地环境提供基础设施,而不只是在云或 SaaS 提供商中提供。
要了解关于 Terraform 操作符的更多信息,请访问该GitHub页面。
原文链接:
Managing Infrastructure From Kubernetes with the HashiCorp Terraform Operator
评论