9

Managing Infrastructure From Kubernetes with the HashiCorp Terraform Operator

 4 years ago
source link: https://www.infoq.com/news/2020/04/terraform-operator-kubernetes/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

HashiCorp has released the alpha version of Terraform operator for Kubernetes to manage infrastructure as code calling Terraform Cloud from Kubernetes. After installing the operator, users can synchronize Terraform workspaces using Kubernetes manifests. Then, applications running in Kubernetes can reference Terraform outputs using ConfigMaps. For now, this operator only works for Terraform Cloud.

The Terraform operator was created for use cases where developers want to provision infrastructure like a queue in AWS SQS using the Kubernetes interface. To get started, users need to create a token in their Terraform Cloud organization, both free and paid version works, and stored it as a secret in Kubernetes. Then, install the operator using Helm . Once the operator is running, users can start creating Terraform workspaces using Kubernetes manifests. The operator can create, update, and retrieve values from Terraform workspaces, execute a run in Terraform Cloud, and update Terraform workspace status in Kubernetes.

1terraform-operator-kubernetes-1586880800875.jpg

To provision infrastructure, it’s necessary to define a Terraform module first so that Kubernetes only sends the input parameters for the module. Developers don’t define nor interact with a Terraform template within a Kubernetes manifest. The reason for this is for design simplicity and reduces the number of custom resource definitions (CRDs) in the cluster. Developers create a Terraform workspace manifest and define the values for each of the Terraform module inputs they want to use. When an infrastructure resource is ready, developers can access the module outputs via ConfigMaps, like the AWS SQS endpoint. Then, reference these values from the application running in Kubernetes.

For every change in the Terraform workspace object, the operator picks it up, except for any sensitive information like the AWS secret keys, and apply it automatically with the auto-approve parameter. Also, to delete resources, users can delete the Terraform workspace using the Kubernetes API by running a command like kubectl delete workspace sqs-queue .

Internally, the Terraform workspace controller reconciles the Kubernetes workspace CRD with a Terraform Cloud workspace. To perform a change, the operator runs the terraform apply -auto-approve to perform changes automatically, but users can use Sentinel to validate changes before applying them. The operator is namespace-scoped for security reasons. Users need an access token via secrets to interact with Terraform Cloud, and giving access to only namespaces reduces risks.

1terraform-operator-kubernetes-loop-1586880800461.jpg

In this alpha release, the operator works only for Terraform Cloud . And Rosemary Wang , developer advocate at HashiCorp, in a recent virtual office hour said: we scoped it to Terraform Cloud usage because we wanted to make sure we understand the behavior of it and didn’t want to add too much logic into the operator. If the community needs support for other backends like AWS S3, Wang encouraged users of the Terraform open-source version to open an issue in the GitHub repository and explain its use case.

Additionally, the Terraform operator allows developers to provision infrastructure for on-premise environments and not just only in the cloud or SaaS providers like the service broken API does.

To learn more about the Terraform operator, visit the GitHub page .


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK