Ansible for IBM Cloud IaaS
Ansible is a configuration management and provisioning tool, similar to Chef and Puppet, and is designed for multi-tier application deployment. Compared to some of the other configuration tools it is simple to use, is quick to learn and can be literally used straight after installation.
In my experience its ease of use with IBM Cloud is down to the fact that it is completely agentless and connects to devices (servers) using SSH. As no agent is installed on the target system, it works out of the box with the default IBM Cloud OS images, avoiding the need to create custom images with embedded agents, or to maintain a separate repository of boot time provisioning scripts. If an SSH key is specified when a VSI is ordered, you are ready to go.
For an introduction to Ansible and installation see:
Tasks can be run off of any machine Ansible is installed on as long as there is connectivity to the target servers. I use the MotionPro Plus VPN client on my MacBook to VPN into the IBM Cloud data center hosting the virtual servers I’m working with.
I installed Ansible on my MacBook, first installing Python 3.5 with Homebrew. In a production environment Ansible would more typically be installed on a server hosted in IBM Cloud. This ensure the whole ops team has access to the same Ansible playbooks. Follow the Ansible install instructions for your choice of control machine.
For the test of these instructions I will assume that OSX is used as the control workstation, though the instructions are the same for Linux and only slightly different for Windows. Once installed executing ansible tasks is the same on any workstation, OSX, Linux or Windows.
See the following instructions for installing Python 3:
On a Mac install Ansible as below:
sudo pip install ansible
Order VSI on private network
To demonstrate how simple Ansible is to use in action, we will order a VSI and run some actions against it.
As securing public network access to the VSI to prevent unwanted attacks is not considered in this recipe, the VSI will be provisioned with a private network interface only. All Ansible operations will be performed over the private network interface.
- Upload your public SSH key to the IaaS portal that will be used by Ansible to configure VSIs. See Getting started with SSH keys.
- Order a public VSI https://console.bluemix.net/catalog/infrastructure/virtual-server-group
- The location will be the same as defined by your choice of VPN login data center
- Select *CentOS* and *7.x Minimal (64bit)- HVM* as the image.
- Under the network interface section, select Private Network Uplink
- Click Provision.
When the VSI has been deployed record its <Private IP address>
The first step is to create an Ansible configuration file in your user directory for execution parameters specific to the tasks we are running. In this case we need to set the flag to disable SSH host_key_checking, as VSIs created by IBM Cloud reuse the same IP addresses if a VSI is deleted and then recreated. This avoids the known host error on SSH login.
Create ansible user directory
Create ansible.cfg file in directory
And copy in the following content
host_key_checking = False
Create the Ansible inventory file:
Copy in the following contents, replacing the <VSI private IP address> with the IP address of the VSI created in the previous step. ansible_user is set as root otherwise ansible would log into the VSI using your login ID from your control workstation.
ws01 ansible_host=<VSI private IP address> ansible_user=root ansible_become=yes
We are now ready to run the first Ansible command to list the inventory of devices as understood by Ansible. The -i ./hosts parameter is used to tell Ansible which inventory file to use.
ansible-inventory -i ./hosts --list
The output should look like the following, with the host parameters we specified under the *hostvars* tag.
We are now ready to un our first commands on the VSI.
The simplest Ansible operation against a target device is to run a command. In this case the Ansible ping command.
ansible -i ./hosts all -m ping
If you receive the following message, either you need to start your VPN to IBM Cloud, or the VSI has been provisioned on a network you cannot access from your workstation.
Successful execution of the Ansible ping command will result in the following:
That completes this step and we have executed our first command against a server on IBM Cloud.
Installing application code
Create the Ansible playbook file apache.yml using nano.
Copy in the following content and save.
- hosts: all
- name: ensure nginx is at the latest version
apt: name=nginx state=latest
- name: start nginx
Run the playbook on the target VSI by running the ansible-playbook command specifying the inventory file to use and the playbook apache.yml.
ansible-playbook -i ./hosts apache.yml
The output should look like the folliowing.
The tasks show a status of *changed* as the state on the target machine has changed.
To prove that Apache is now installed on the Centos VSI and running, run curl against the VSI.
curl <VSI private IP address>
The first few lines of the output should look like the following, demonstrating that Apache is now installed and running.
Congratulations you have now installed Ansible and successfully installed application code on a VSI without needing to login.
Delete the VSI
From the IBM Cloud IaaS portal cancel the VSI to avoid incuring additional charges.
Select Action and Cancel Device
That completes this receipe. Other receipes in this series will look at more complex Ansible playbooks and roles to deploy full multi-tier applications on the IBM Cloud IaaS platform. Also how to use Ansible with Terraform to automate the creation of infrastructure as well as application deployment.