Many of the DevOps and platform teams we work with use Terraform to define the cloud infrastructure configurations powering their application environments.
However, many of these teams face a common challenge—delivering and operating the infrastructure in their Terraform files in a way that’s scalable and easy to use for their developers, testers, and other end users.
Here we’ll break down how our users automate actions on VMs defined in their Terraform configurations, including how to power on VMs automatically when needed and power off VMs when no longer needed.
This accomplishes a few important benefits for operations and development teams:
- Eliminates a common bottleneck by removing manual tasks to power on VMs that are needed for day-to-day development tasks
- Improves the developer experience by providing direct access to actions on VMs so they don’t need to launch a VM config tool or connect to the VMs via VPN/SSH manually
- Controls cloud costs by ensuring that those VMs are powered off during the hours when developers won’t need them
Step 1. Import the Terraform configurations from your Git repository into a reusable blueprint defining the complete environment your users need
Let’s say you have a specific environment with Azure VMs that need to run during normal business hours from Monday to Friday, and all the infrastructure is already defined in a Terraform file (or in multiple files).
First, you’d connect your Git repository to Quali’s Torque platform to orchestrate the complete environment. If your environment requires multiple Terraform files, this has the added benefit of removing the manual work of configuring those resources to work together.
Learn more: Automating Terraform and Kubernetes orchestration
The platform will automatically generate a blueprint that models the Terraform configurations into standard definitions in a YAML file to define all the assets, dependencies, and artifacts needed for the complete application environment.
Your end users can now deploy the blueprint and get the environment as frequently as needed.
Step 2. Set your operational schedule for the Azure VMs defined in your Terraform files
Next, you’d create a workflow to power these on when the workday starts.
In the Administration space of your Torque account, create a new workflow that defines when all VMs should power on.
This workflow will automatically power on Azure VMs at 8 am every Monday through Friday.
You can choose to apply this rule to all infrastructure in your Torque account or to a specific workspace that manages only certain infrastructure.
As you can see in this example, we chose to apply this to our Development space. You can create additional workspaces to support your various use cases.
From there, just create a separate workflow to schedule when these VMs should power off.
Step 3. Allow developers access to request extensions as needed
Since the end users who rely on these VMs may need to start early, work late, or run a workload past 5 pm, you’ll need to give them some flexibility.
Role-based permissions that allow end users to view and launch any of the environments in their Space, but without the ability to modify any of the infrastructure or configurations powering this environment.
This allows end users to request an extension for the specific environment they need, which will trigger a notification to an administrator who can approve or deny the request.
For further flexibility, you can remove the approval workflow for certain environments and allow end users to power specific VMs on and off with a single click.
With this approach, you can now automate operations and distribute access to the infrastructure defined in your Terraform files, without sacrificing oversight from the DevOps or platform teams.