Introduction
Ansible is an IT automation tool intended to facilitate the management of remote servers. Ansible requires Python (version 2.7 or 3.5 and higher) to run. Ansible is run from a centralized control node and can manage any server accessible over SSH. Remote servers that are managed by Ansible are called managed nodes.
By default, Ansible communicates with managed nodes using OpenSSH. SSH is not the only communication mechanism Ansible supports. You can run tasks on the control server locally, in a docker container or even a Windows server. The control node will require Linux to run.
What is IT Automation?
Today, System Administrators and DevOps Engineers must manage complex IT infrastructure in the cloud and across multiple sites. Modern web applications typically consist of an API service, a front-end service, and a database service. Manually managing such complex systems would require a lot of time and would be prone to mistakes.
IT automation uses software to provision IT infrastructure, deploy applications and, to manage services configuration changes. The software you use to fill this role needs to provide a reliable and repeatable way to manage your IT tasks. Ansible’s approach to IT automation centers around the ‘playbook’. You can think of an Ansible playbook as a recipe that describes the steps needed to set up your IT infrastructure, deploy your applications and then configure those services.
Advantages of Ansible
Ansible is very easy to learn and allows you to get up and running with automation more quickly than other tools. Ansible is agentless, so you don’t have to install and maintain an Ansible client on your managed nodes. This dramatically simplifies the management of Ansible updates.
Drawbacks of Ansible
Ansible, of course, is not a perfect tool. If an SSH connection is interrupted partway through a playbook run, that node could end up in a partially configured state. Ansible also has a reputation for being slow and may require additional performance tuning to meet your requirements
Install Ansible
L
Step 1: Install the EPEL Repository
yum install epel-release
Step 2: Install Ansible
Next, we install the Ansible package from the EPEL repository
yum install ansible
Step 3: Create a User for Ansible
As security best practice denotes, it is a good idea to avoid logging into your Linux servers as root. We will create a non-root user on our control node and our managed nodes that will run our Ansible playbooks. This user defines the admin Ansible will utilize to log into our managed nodes. Here we have used “admin”’ for the user, but any username can be substituted. To follow along with our examples, you will want to use the same username on both the Control node and our managed Nodes. Log onto the control node to add a user and set a password
useradd admin
passwd admin
Step 3b: Configure the Control Node User for Passwordless Super User Access
On the managed node, we need to ensure our Ansible user can utilize the sudo command without a password. Run the following command to open the sudoers file for editing
visudo
Step 5: Configure our Admin User for SSH Access
ssh-keygen
Now we can copy the public key to our managed node with the following command.
ssh-copy-id node.kb.liquidweb.com
Step 6: Create an Ansible Inventory
Ansible requires an inventory list so it can identify your managed nodes. To add our managed node to the inventory, we need to login to our Control node as the admin user. Next, we will add a new inventory file. Make sure you are logged onto the Control node as the admin user.
vim /home/admin/inventory
Type ‘i’ to enter insert mode and add the managed node hostname to the inventory file.
node.kb.liquidweb.com
Next, type ‘[ESC]+:wq’ to save the file.
Step 7: Create an Ansible Playbook
To test our configuration, we will create a simple playbook to install Nginx on our managed node. First, we will create and open a new file. File names are not particularly important as far as Ansible is concerned. You should, of course, use descriptive file names. Make sure you are logged onto the control node as the admin user.
vim /home/admin/install-nginx.yml
Ansible’s playbooks are written in a language called YAML. YAML is intended to be human-readable. Looking at the text below, you should be able to tell what the expected results are. I’ll break the syntax down in just a moment, but for the time being, type ‘i’ to enter insert mode and add the following text to your playbook. Then type ‘[ESC]+:wq’ to save and exit.
Ansible’s playbooks execute ‘plays’. A play is a list of tasks that will be performed on the nodes. In the example above, we used the ‘hosts’ keyword to specify a list of just a single node. You can, however, specify a list of hosts, using comma-separated values. To install software with Ansible, we require root access to utilize yum. We use the keyword “become” in the play to instruct Ansible that the root user is required to execute the task.
The ‘tasks’ keyword initiates the list of tasks to be completed. Each task is given a unique name using the ‘name’ keyword. We then use the yum module provided by Ansible to install the first epel repository, and then we use the second entry to install nginx.
Step 8: Run the Playbook
Running a playbook is rather easy. We use the “ansible-playbook” command and then specify the inventory file with the “-i” option followed by the path to the playbook. Make sure you are logged onto the control node as the admin user.
ansible-playbook -i /home/admin/inventory /home/admin/install-nginx.yml
Conclusion
We’ve only scratched the surface with Ansible so far. You can group the servers in your inventory together by using group names. This grouping allows you to execute playbooks on only your webservers or, only on your database servers. You can also run ad-hoc commands. Ad-hoc commands are tasks that you need to run only once. For instance, if you needed to reboot all of your web servers. All in all, Ansible is an excellent tool you can use to save time, money and effort to automate tasks across a single or multiple remote servers.