Let’s look back at the network and system computing age when server deployment and management were daunting tasks for companies. Then, only the system administrator was responsible for software installation, settings management, and all other administration services manually on various servers. It was almost impossible to manage workloads manually and always needed to put the extra effort to complete the tasks.
To overcome these repetitive, complex, and tedious operations, Ansible, an IT automation engine, was created. It uses a simple YAML configuration language that is easy to learn and understand.
Michael DeHaan, the creator of Ansible Work, already had a lot of experience with other configuration management tools when he decided to develop a new one. He said that he wanted “A tool that you could not use for six months, come back to, and still remember.”
How Ansible Works
Ansible can support one or more nodes, which are computers that attach to the “master node” that must be installed with the Ansible package. The way Ansible works is by connecting to your slave nodes, a computer that is connected with the Ansible control center, and pushing out small programs, called “ansible modules” to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules, over Secure Shell (SSH) by default, and removes them when finished the only thing we need ensure that the Master node must be able to access the slaves over an SSH port and must be having required access to complete the tasks.
What to Understand: Pre-Requisites
Before you work through this tutorial, you’ll need:
- Ansible 2.10 (or higher) installed
- One or more network devices that are compatible with Ansible
- Basic Linux command line knowledge
- Basic knowledge of network switch and router configuration
Next, install Ansible using your preferred method.
Once the installation is complete, confirm the version of the Ansible using the below command in your terminal:
- ansible –version
Now let’s create our first inventory file where we store the information of slave/managed nodes with the following commands:
- mkdir -pv /root/ansible_sample_project
- cd /root/ansible_sample_project
- vim inventory.txt
- Now, add the below line in the file:
- slave ansible_host=<private_ip_of_slave_server> ansible_ssh_pass=root
Each notation means the following:
- Slave: host variable name
- Ansible host: host variable definition
- Ansible_ssh_pass: ansible authentication method
We can use other formats also while creating the inventory files.
Below is how you’ll create a playbook (playbook is a blueprint of automation tasks—which are complex IT actions executed with limited or no human involvement) to run the automation:
- vim playbook_script.yaml
name: Run an Script
hosts: all remote_user: root tasks: – name: Transfer the script copy: src=status.sh dest=/root mode=0777 – name: Execute the script command: sh /root/status.sh – name: Remove file (delete file) file: path: /root/status.sh state: absent |
Create the “vim status.sh,” a bash script, to touch the file on the slave/node servers:
- vim status.sh
- Enter the below lines and save the file:
#!/bin/bash
touch /root/text.txt
The Playbook
When we run the above ansible-playbook with the inventory file from earlier, it will check the host entries and try logging it with the defined user with the password we mentioned in the inventory file. Once the SSH connection is established, it will transfer the script to the node servers and execute it using the command provided in the playbook. Once it’s done, it will delete the script from the node/slave servers.
Before we proceed with running the playbook, we must modify the setting so that we can establish the connection without any errors as we are using user-based login.
Go to the Ansible configuration file, “/etc/ansible/ansible.cfg.” Edit the below parameter so that it reads, “false,” like below:
host_key_checking = False
Once the changes are complete, you’ll want to save the file. Now test the connection using the below command:
ansible slave -m ping -i inventory.txt
Successful pong status means it has connected properly from the node/slave server.
Let’s run the playbook using the below command:
ansible-playbook playbook_script.yaml -i inventory.txt
Master Ansible in No Time
I hope my short introduction and tutorial to Ansible illustrates how this automation tool is designed to be reliable, agentless, and helps you thrive in the automation market. If you really want to master Ansible, make sure to find a project or a course as practice makes perfect.