The Spacelift team is pleased to announce the newest IaC provider within the Spacelift platform, Ansible from Red Hat. The engineering team has been hard at work integrating the best-in-class IT Automation platform into the most sophisticated Infrastructure Delivery platform.
To help ensure a smooth integration into the platform, we are introducing Ansible as a “Closed Beta.” We have already begun testing with existing customers, and the feedback is going well. If you are not a Spacelift customer, you can sign up for a Free trial.
Now you can bring Terraform, Pulumi, AWS CloudFormation, Kubernetes, and Ansible all in Spacelift!
Although managing individual servers is largely considered crazy in new greenfield deployments, countless companies still rely on good old-fashioned stateful servers. These servers require TLC to provision, update, and manage. Ansible is considered one of the best options for these tasks due to its simplicity and large ecosystem. Now, servers aren’t the only thing Ansible can manage, as it has documentation for databases, messaging platforms, network devices, monitoring services, and more! Any of these can be critical dependencies in your infrastructure as code ecosystem.
Spacelift has historically been capable of managing the rest of the ecosystem with Terraform, Pulumi, AWS CloudFormation, and more, and now it is gaining another large piece of the infrastructure puzzle with Ansible support! Let’s take a look.
It is common for infrastructure teams to bootstrap an existing server in Google Cloud Platform (or any public cloud) with the open source observability solution Grafana.
Organizations have struggled with combining provisioning and automation use cases for some time. Using a pre-configured image is common in situations like this, but it is not the most trivial solution to maintain. Bringing Infrastructure as Code (IaC) and Ansible for IT automation becomes even more powerful. And with the power of Spacelift, you can bridge the old (IT Automation) with the new!
Start by creating a stack to deploy your server to GCP using Terraform. Complete the use case by setting up a job to automatically run your Ansible playbooks using trigger policies or manually trigger it when the time is right.
Inventory
Ansible provides two options for configuring the inventory file by either hardcoded entries or via the dynamic inventory feature. We recommend using the dynamic inventory to build an inventory of resources in your cloud account versus having to hardcode them. The benefits of dynamic inventory quickly appear in organizations with a high amount of change in infrastructure provisioning and workload deployments.
Below is an example of a dynamic inventory file:
plugin: gcp_compute
projects:
- ${project-id}
keyed_groups:
- key: ${group-key}
prefix: ${group-prefix}
auth_kind: serviceaccount
The above inventory file has been modified with Terraform’s interpolation syntax to generate the details while deploying your Ansible stack. This highlights the benefit of Spacelift to help manage automation with Ansible, and everything is now deployed dynamically in conjunction with Terraform.
Dependencies and Environment
Once you create your inventory file, there are other requirements that you may need to satisfy to connect to your instances. These requirements could be:
- SSH Key
- Custom ansible.cfg configuration
- Extra environment variables
- Cloud credentials for your inventory file
All of these can be managed securely using Spacelift! You can manage all of these items securely within a Spacelift Context. This context can also be created manually by uploading the required files or in an automated fashion using the Terraform Spacelift Provider. An example of these variables being created within context using Terraform is here:
locals {
context_vars = {
"GCP_SERVICE_ACCOUNT_FILE" = { "value" = "/mnt/workspace/gcp_creds", "write_only" = "false" },
"ANSIBLE_HOST_KEY_CHECKING" = { "value" = "FALSE", "write_only" = "false" },
"ANSIBLE_PRIVATE_KEY_FILE" = { "value" = "/mnt/workspace/terraform-ansible-key", "write_only" = "false" },
"ANSIBLE_INVENTORY" = { "value" = "/mnt/workspace/inventory.compute.gcp.yml", "write_only" = "false" }
"ANSIBLE_CONFIG" = { "value" = "/mnt/workspace/ansible.cfg", "write_only" = "false" }
}
}
resource "spacelift_environment_variable" "vars" {
for_each = local.context_vars
context_id = spacelift_context.ansible-context.id
name = each.key
value = each.value.value
write_only = each.value.write_only
}
There are many ways to optimize this based on your needs.
Deploy
Once the Ansible stack is created and ready to go, you can either trigger it manually using the intuitive Spacelift UI or configure policies to automatically trigger it after your infrastructure has been deployed. This, of course, depends on your organization’s needs. Once the stack is triggered, Spacelift handles the rest by using the dynamic inventory file to populate the hosts, utilizes any keys and credentials defined, and runs the playbook!
Your playbook runs, and your instance is bootstrapped with the software and settings you require!
Although this example is relatively simple, when you have the power of Ansible at your fingertips along with the rest of your Infrastructure as Code, you will find that the possibilities are endless, and Spacelift makes it easy! We have kept this blog a bit vague due to pending changes, support, and modifications, but we want you to join in the fun with us.
The most flexible management platform for Infrastructure as Code
Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.
