Some of the most common questions we hear from new users involve automating Terraform and Kubernetes orchestration.
The major challenges often emerge for teams that need to orchestrate multiple Terraform scripts, Helm Charts, and native Kubernetes manifests to work together in a single environment.
The manual work required to provision these environments can bring a DevOps team grinding to a halt.
Here we’ll lay out how Quali users automate orchestration of Terraform and Kubernetes environments in minutes, with the added benefit of making those environments repeatable.
Step 1: Discover and import Terraform scripts and Kubernetes assets from your Git repository
Quali’s Torque was designed to support the use of Terraform and Kubernetes so our users could build multi-asset environments faster.
This starts by connecting a Github, GitLab, or Bitbucket repository to Quali’s Torque platform.
Once you’ve done this, you can import the Terraform scripts, Helm Charts, and Kubernetes assets you need for your environment. Most users import all assets in case they need them later, but for this article we’ll just focus on the ones you need.
Step 2. Select the Terraform scripts and Kubernetes assets you need for your environment
Once you’ve selected the assets you need, Quali’s Torque will generate a YAML file defining the environment based on those assets.
Once created, you can use this YAML as often as needed, and you can set your CI/CD, CLI, or IDE to deploy it automatically in line with the pipeline stage it is designed to support.
Step 3. Set a maximum duration and tags for your Terraform and Kubernetes environment
The maximum duration automates the termination of the environment after a time that you determine, reducing the risk that your team forgets to shut it down. You can also set the environment to run indefinitely if needed.
Tags are customizable and allow you to group usage and cost reporting based on your own parameters. If, for example, this environment supports a testing group, a tag labeled “testing” will attribute this environment and any others with that tag to the testing group—with automated reporting over time.
Step 4. Set role-based access controls so end users can view and deploy the environment without edit access
Self-service access is the final step to mitigate the provisioning bottleneck for multi-asset environments.
End users can browse a catalog of pre-configured environments, view the infrastructure components within these environments, and launch them on demand. Integrations with CI/CD tools and CLIs allow them to automate the deployment and teardown of these environments in line with each stage that they support.
Meanwhile, role-based access controls prevent end users from modifying the environments, including the infrastructure, configurations, maximum duration, and tags.
Infrastructure as Code and Kubernetes are invaluable for automating the delivery of infrastructure. Orchestration takes this approach one steps further to automate the delivery of complex environments that leverage that infrastructure.
Learn more about Quali’s Torque here.
