Terraform控制器:云资源自助服务使用方法

236 阅读6分钟

Terraform控制器。云资源自助服务

了解Kubernetes如何帮助应用程序的依赖性和消耗不再造成进展的主要瓶颈。

Kubernetes在为开发者提供生态系统方面表现出色,提高了发货速度,将组件置于一个共同的框架和DSL之下,同时还具有扩展和延伸服务的灵活性。因此,令人难以置信的是,与客户交谈时,应用程序的依赖性和消费仍然是进展的一个主要瓶颈,团队被封锁在数据库、队列、对象存储等方面。

问题是...

  • 大多数应用程序甚至没有进入生产阶段--软件交付周期的很大一部分是原型设计和实验。它被驱动着快速展示价值:尝试它,展示它,看看它是否失败。
  • 这种说法经常与平台工程发生冲突,自然也是如此。他们的目标是产品化的设置,对可靠性、成本和安全性的所有权是一个非常不同的世界观。
  • 虽然Kubernetes在消除应用交付的障碍方面非常成功,使开发团队和DevOps能够体验到平台即服务,但在很大一部分组织中,应用依赖性仍然是一个票据系统;点击,打开支持票,等待响应,等等。

虽然 Terraform-controller 并不试图解决所有这些问题,但它是朝着正确方向迈出的一步。

  • 重复使用你已经拥有的Terraform模块和代码;没有支点或技术选择。
  • 允许团队消费,同时保持对资产(Terraform模块)和安全配置文件(Checkov)的控制。
  • 让团队意识到他们自己的成本,允许他们改善他们。

为什么和什么的问题

对于开发者

  • 工作流在开发者的命名空间之外运行,所以凭证可以集中管理和共享,而不会被暴露。
  • 更改可以事先被批准,按照计划和应用工作流程。
  • 开发人员可以从他们的命名空间查看和调试Terraform工作流程。
  • 将输出作为环境变量提供,准备直接从Kubernetes的秘密中消费,而不需要进一步操作数值。

对于平台工程师

  • 这不是一个免费的;平台工程师可以围绕哪些模块可以被应用团队消费来实施政策。
  • 配置可以是特定环境的,使工程师能够将特定环境的数据注入模块配置中。可以注入环境标签、过滤器、项目标签、成本代码等用例。
  • 使开发人员能够看到他们在Kubernetes内配置的相关成本
  • 支持吊舱身份(AWS上的IRSA),并将凭证管理移交给云供应商。
  • Infracost集成,并提供查看预期成本和潜在的执行政策(预算控制)的能力。
  • 重用你可能已经写好的Terraform和你几乎肯定已经有的经验。
  • 在你的团队可以使用的模块周围设置护栏,而不是参考或从互联网上拉取任何Terraform模块。
  • 孤儿资源的能力,即删除自定义资源而不删除支持它的云资源。

先决条件

最快的方法是通过Helm图表来启动和运行。

a.部署控制器

外壳

$ git clone git@github.com:appvia/terraform-controller.git
$ cd terraform-controller
# kind create cluster
$ helm install -n terraform-system terraform-controller charts/ --create-namespace
$ kubectl -n terraform-system get po

b.为开发者配置凭证

# The following assumes you are using static credentials. For managed pod identity see the docs: https://github.com/appvia/terraform-controller/blob/master/docs/providers.md

$ kubectl -n terraform-system create secret generic aws \
  --from-literal=AWS_ACCESS_KEY_ID=<ID> \
  --from-literal=AWS_SECRET_ACCESS_KEY=<SECRET> \
  --from-literal=AWS_REGION=<REGION>
$ kubectl -n terraform-system apply -f examples/provider.yaml

c. 创建你的第一个配置

壳牌

$ kubectl create namespace apps
# NOTE: Make sure to change the bucket name in examples/configuration.yaml (spec.variables.bucket)
$ vim examples/configuration.yaml
$ kubectl -n apps apply -f examples/configuration.yaml
# Check the module output
$ kubectl -n apps get secret test -o yaml

路线图上有什么?

预算限制

随着Infracosts的集成,一个想法是引入对预算的控制。虽然它不会直接执行成本,而且一些资源是基于使用的(例如,一个S3桶是免费的,但在里面倾倒10TB,它的成本很高)。这可能是一种捕捉成本的轻量级手段,允许开发人员发挥/调整他们的依赖性,并促进对成本的更好理解。

脚本语言(YAML

constraints:
  budgets:
    # Allow monthly spend of up to 100 dollars within each namespace for cloud resources
    - namespaces:
        matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: Exists
      budget: 100
    # Allow monthly spend of up to 500 dollars for namespaces with project cost center code PK-101
    - namespaces:
        matchExpression:
          - key: company.com/costcode:
            operator: In 
            values: [PK-101]
        budget: 500

政策执行

Checkov集成到管道中,让平台工程师有能力从上面驱动政策。

YAML

constraints:
  checkov:
    source: https://github.com/<ORG>/<POLICY-REPO>.git?ref=v1.2.0
    secretRef:
       name: policy-sshkey

注意: 虽然作为一个障碍,但如果这是对生产工作负载的应用,并且没有真正遵循左移的方法,那么它就会非常晚。绝对值得阅读我们的Policy As (Versioned) Code(PaC)博客,以了解耦合的方法(即在发布版本之前,在Terraform模块CI工作流程中使用相同的PaC存储库,以及在部署时在集群中强制执行)。

更新: 这已经完成,从0.1.1版本开始可以使用:https://github.com/appvia/terraform-controller/releases/tag/v0.1.1

那么,有哪些替代方案?

这并不意味着是一个唯一的列表或比较,在谷歌上搜索一下就有很多博客,但值得强调的是,在那里有几个值得注意的项目。

Crossplane

Crossplane现在是CNCF上的一个孵化项目,它是一个有趣的项目,并且很好地发挥了我们DevOps所喜爱的砖石方法。简而言之,它由管理资源(想想Terraform资源)组成,这些资源被打包成 "组合"(想想Terraform模块的意见集合)并作为可消耗的CRD呈现给应用开发者。最初,它试图复制Terraforms云支持的广度,最近它加入了Terrajet项目的俱乐部,它对Terraform供应商的控制器进行编码。

  • 它有很多优点,但确实伴随着技术上的转折和平台团队的学习曲线。
  • 不能重复使用以前的投资或经验。有可能你有一批经过测试的Terraform模块即将被废止。
  • 没有试运行或计划支持。对资源所做的任何改变都会试图立即应用,这就有了风险,对特定资源属性的修改可能会引起破坏性的改变。

Terraform运营商

当输入terraform控制器时,可能是谷歌的第一个点击。该项目以类似的方式工作--通过Kubernetes作业协调一系列工作流程,并将其映射到 "terraform init "和 "terraform apply"。

  • 自定义资源的定义非常灵活,允许调整;图像、版本、运行后和运行前脚本,以及许多其他设置(尽管可以说你可能必须以某种方式阻止这些功能,因为它增加了滥用的表面积)。
  • 目前,操作者没有分享证书的手段。这可以被看作是一个优点,然而,它确实使开发人员的部署和消费更加复杂,因为你现在需要为团队管理证书,或者可能与Vault等产品集成。
  • 它有一个spec.resourceDownloads的功能,相当有用,也许可以用来提供特定环境的配置。
  • 不支持批准或审查更改 - 一切都是 "自动批准"。
  • 政策必须在事后通过另一个组件(如GateKeeper或Kynervo准入控制器)进行叠加。
  • Terraform的输出被写成Kubernetes Secret中的JSON对象,因此你的应用程序可能需要改变来解析和消费这些值。