How do you stand up new environments and apps in minutes? The answer lies in Infrastructure as Code (IaC) and the tools and practices behind it. In this blog post, I look at using Ansible and Terraform to perform end-to-end environment and app provisioning on IBM Cloud. It shows how with the adoption of IaC, the building of environments can be reduced from hours (if not days) down to minutes.
The benefits of automating end-to-end environment creation in the development cycle are clear and proven:
The same config is used for dev, test, and production. This ensures consistency and a known working config.
Apps and environments are provisioned on demand. This reduces costs for test and dev environments which can be spun up as needed.
It reduces the potential for human error while deploying apps and infrastructure
IBM Cloud uses Terraform as its orchestrator of choice for infrastructure provisioning. The choice of configuration management tool for app provisioning is left to you as the user depending on your preferences and needs. My blogs on Infrastructure as Code Accelerates Application Deployment and Chef, Ansible, Puppet, or Terraform? look at the different roles these tools play and their distinguishing features.
So what is Ansible?
Ansible is a config management and provisioning tool, similar to Chef and Puppet. It is designed to automate multi-tier app deployments and provisioning in the cloud. Written in Python, Ansible uses YAML syntax to describe automation tasks. This makes Ansible easy to learn and use.
How does Ansible work?
Ansible does not use agents, but rather connects to hosts using SSH keys:
Ansible manages hosts by modeling all software packages, configs, and services as configurable resources. Playbooks specify the desired end state of a hosts’ resources and contain the tasks required to bring the resources to the target state. Via SSH, Ansible runs tasks on each host to bring the modeled resources to the desired state. Tasks are grouped into plays in playbooks. Alongside playbooks, Ansible inventory defines the hosts it will work with and groups hosts by the role they play as webservers, database hosts, etc. The inventory, therefore, determines the plays and playbooks to be executed for each host.
Terraform and Ansible
Terraform and Ansible are very complimentary tools. Together, they go from a blank sheet of paper to a fully functional app on IBM Cloud. The challenge is in integration, transferring data from one tool to the other, and the tightness of coupling.
Integration is usually through Terraform providers, initiating the chosen config management tool. Providers exist for Puppet and Chef, though today there is no Ansible provider. The only way to initiate playbooks from Terraform is to use a local-exec provisioner. Due to the limitations of local-exec in Terraform 0.11, this seems like a poor solution because the provisioner starts without waiting for an instance to launch. In most cases, it will fail because at the time that it will try to connect, there is no one ready to listen.
The integration approach adopted with IBM Cloud is loose coupling using Ansible Dynamic Inventory. The benefit of this approach is that it allows Ansible to be used regardless of how your instances were created. The inventory could be read from Terraform’s state file, any set of static files, or a config management tool.
First, you create your infrastructure with terraform apply and then invoke ansible-playbook -i inventory site.yml. The -i inventory flag tells Ansible to look in the specified folder for inventory. This contains the dynamic inventory scripts that read the Terraform state file recording the state of the provisioned infrastructure.
As determined by the inventory, Ansible performs final config of the servers and apps via SSH over a VPN connection. In this approach, Terraform and Ansible are loosely integrated through the sharing of inventory information. After completion of infrastructure provisioning, the Ansible configuration of software and services on the Terraform provisioned hosts is manually initiated by the user.