Just installing Linux in a DevOps lab isn't enough; the Linux VMs must be configured for the application that users will access, to more accurately mimic IT tasks in a real production environment. Configuration management tools take the manual work out of setting up new systems and updating existing ones -- on a handful of lab VMs or thousands of production instances.
Ansible is an open source tool owned by Red Hat.
Install and run Ansible
To learn Ansible, install the prerequisites: Ansible on the master VM and Python on the worker nodes. For these Ansible tips, I combined the configuration management tool with Vagrant, making the installation part of the Vagrant provisioning process:
Vagrant copies the file from the same folder as the Vagrantfile and runs it inside the node1 VM during provisioning. The file contains some package installation commands:
Both node1 and node2 use this same script to install Python, which provides the execution environment for Ansible. For the VM master, use a different script called ansible.sh to install Ansible as well as Python. You already created the VMs, so use vagrant provision to have Vagrant run these scripts. Use vagrant destroy followed by vagrant up to get a clean deployment.
Once Ansible completes the configurations successfully, commit to Git by adding the two new shell script (.sh) files then committing the changes:
The DevOps lab requires RSA key-based authentication so that the user on the master VM can SSH into the nodes without a password. This is essentially how Ansible configuration management operates without agents: It connects over SSH and runs commands. Use vagrant ssh to connect to the master, then run the command ssh-keygen to create RSA keys for the Vagrant user:
The command ssh-copy-id copies a key to node1. It prompts you to accept the SSH key and then supply the Vagrant user's password, which is also vagrant. Run the copy command again to copy the key to node2:
The lab is now set up, but you're just getting started with Ansible tips. Look at the inventory file that lists the computers that Ansible will manage. The default inventory list is kept in /etc/ansible/hosts, where you will list the master and nodes in two groups:
The DevOps lab does not have a name-resolution system, so refer to the nodes by their IP addresses. Verify that you can talk to the two nodes using the Ansible ping module with the command ansible nodes -m ping:
The two nodes should respond with a pong, which verifies that the SSH connection works and the inventory contains the right IP addresses. At this point, you can continue to run individual commands, but to truly learn Ansible's capabilities for DevOps processes, string commands together into a playbook that runs from a single prompt. Ansible playbooks are written in YAML. The playbook to ping the nodes is simple:
To run the playbook, use the ansible-playbook command and pass it the name of the YAML file:
There were two tasks completed for each node in this example: The setup task is a test that the user can talk to the node and then the ping task runs. The ping task is redundant, as the setup task verified Ansible was working. Ansible playbooks can contain hundreds of lines of tasks. Learn Ansible capabilities and create playbooks to utilize them.
It's time to commit these changes to Git. There's a copy of both the Ansible hosts file and the ping.yml file in my project folder. Add the files and commit the changes.
Continue building this DevOps lab ⇉
With Vagrant provisioning, Git source control and Ansible configuration management on the virtual machines, it's time to experiment with Docker container technology.
Pit Ansible against Puppet -- see how they compare
Automation capabilities let Ansible reach outside DevOps space
Ansible's simplicity earns spot in 2016 Modern Infrastructure Impact Awards