November 21, 2018 By Steve Strutt 3 min read

End-to-end application provisioning

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.

Seeing is believing

Get started and find out for yourself. Start with Using Ansible to automate app deployment on Terraform-provided infrastructure and try out the tutorial Using Terraform and Ansible to deploy WordPress on IBM Cloud infrastructure.

The end-to-end provisioning time is in the order of 20 minutes.

More from Cloud

Hybrid cloud examples, applications and use cases

7 min read - To keep pace with the dynamic environment of digitally-driven business, organizations continue to embrace hybrid cloud, which combines and unifies public cloud, private cloud and on-premises infrastructure, while providing orchestration, management and application portability across all three. According to the IBM Transformation Index: State of Cloud, a 2022 survey commissioned by IBM and conducted by an independent research firm, more than 77% of business and IT professionals say they have adopted a hybrid cloud approach. By creating an agile, flexible and…

Tokens and login sessions in IBM Cloud

9 min read - IBM Cloud authentication and authorization relies on the industry-standard protocol OAuth 2.0. You can read more about OAuth 2.0 in RFC 6749—The OAuth 2.0 Authorization Framework. Like most adopters of OAuth 2.0, IBM has also extended some of OAuth 2.0 functionality to meet the requirements of IBM Cloud and its customers. Access and refresh tokens As specified in RFC 6749, applications are getting an access token to represent the identity that has been authenticated and its permissions. Additionally, in IBM…

How to move from IBM Cloud Functions to IBM Code Engine

5 min read - When migrating off IBM Cloud Functions, IBM Cloud Code Engine is one of the possible deployment targets. Code Engine offers apps, jobs and (recently function) that you can (or need) to pick from. In this post, we provide some discussion points and share tips and tricks on how to work with Code Engine functions. IBM Cloud Code Engine is a fully managed, serverless platform to (not only) run your containerized workloads. It has evolved a lot since March 2021, when…

Sensors, signals and synergy: Enhancing Downer’s data exploration with IBM

3 min read - In the realm of urban transportation, precision is pivotal. Downer, a leading provider of integrated services in Australia and New Zealand, considers itself a guardian of the elaborate transportation matrix, and it continually seeks to enhance its operational efficiency. With over 200 trains and a multitude of sensors, Downer has accumulated a vast amount of data. While Downer regularly uncovers actionable insights from their data, their partnership with IBM® Client Engineering aimed to explore the additional potential of this vast dataset,…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters