Ansible is an opensource IT automation tool that automates provisioning, configuration management, application deployment and orchestration. It was created by RedHat and then handled to the community via opensource.
Why use Ansible?
Assume that you are a system Administrator for a company and and you in charge of maintaining the infrastructure consisting of few webserver database servers, you will be fine as, maintaining and updating few servers manually is an easy task.
But in a situation where your company has hundreds of servers, then everything changes . To maintain and update hundreds of servers manually one by will not only be a dompting and inefficient use of the company's time.
That is when a tool like Ansible comes into pay. Ansible will allow you configure and update your server exactly how you want it to be through some lines of YAML and that is referred as an Infrastructure as Code (IaC).
How Ansible Work?
Traditionally, in order to manage servers remotely, you needed to have an agent installed thus the concept of Master/salve .The only way the master can get information from the salves were through the agents installed on the target nodes.
That is called Pull Configuration and configuration management as done by tools like Chef and Puppet.
But Ansible is different, and that is what makes it so attractive to lot of Sysadmins.
Ansible is Agentless. Unlike the Pull Configuration, there is no need to install an Agent on the target nodes. Ansible use what is called Push Configuration. Unlike Pull Configuration, you can Push information to your target node and force them to be configured as you wish.
Setting up and Ansible
Set up your main machine and install Ansible on it. In the next blog I will quickly show how to install Ansible. No need to have Ansible installed on your target machines.
In order for your Ansible instance to push the desired configuring, the only the only requirement will be an ssh connection.
The configuration that will be send ( Module ) will have a set of instructions called "Playbook" and will on your Ansible which as mentioned earlier can be a local machine, a VM, and or cloud instance like an AWS EC2.In addition to that , your Ansible node will have the list of the target machines in what is called "Inventory".
Playbooks
This is where will be store the set of instruction used to configure the target nodes a and they are written in YAML
Below is a basic playbook to install apache on an target server. In next blogs I will dive deeper into the structure of of an Ansible playbook by explaining it line by line. Oh and it you are a little confuse about the syntax, there are tools out there like yamlchecker that can help check the validity of your playbook
Ansible is an open-source IT automation tool that simplifies provisioning, configuration management, application deployment, and orchestration.
There are several reasons why you should use Ansible. As a system administrator responsible for maintaining a company's infrastructure with a few web and database servers, updating and maintaining them manually may be manageable. However, if your company has hundreds of servers, this becomes an arduous and inefficient task that consumes valuable company time. This is where Ansible comes in handy.
Ansible allows you to configure and update your servers precisely the way you want them to be, using a few lines of YAML. This is known as Infrastructure as Code (IaC).
Traditionally, to manage servers remotely, you needed to have an agent installed. This is known as Pull Configuration and is used by tools like Chef and Puppet for configuration management. However, Ansible is different and more attractive to sysadmins because it is agentless.
With Ansible, you can push information to your target nodes and configure them as you desire. You only need to set up your main machine and install Ansible on it; no need to install Ansible on your target machines. The only requirement is an SSH connection for your Ansible instance to push the desired configuration.
To configure target nodes, Ansible uses modules, which are sets of instructions called "playbooks." Playbooks are written in YAML and stored in the main machine, which can be a local machine, a VM, or a cloud instance such as AWS EC2. Your Ansible node will have a list of the target machines in "Inventory."
To illustrate, here is a basic playbook that installs Apache on a target server. We will delve deeper into the structure of an Ansible playbook in future blogs. If you find the syntax confusing, there are tools such as "yamlchecker" to validate your playbook.
---
- name: is https installed?
hosts: all
task:
- name: Install apache
apt:
name: apache2
state: latest
become: yes
- name: index.html
copy:
content: "this is an ansible playbook"
dest: /var/www/html/index.html
become: yes
- name: restart apache2
service:
name: apache2
state: restarted
enabled: yes
become: yes
Inventory
This is where we maintain the structure of the network environment. Below is a random example of an inventory file for webserver . It has the IP Addresses of the targeted servers
"webservers: {
"hosts:[
" 192.168.0.1
"192.168.0.10
]
}
In the next blog, I will show you how to spin up an AWS EC2 servers, install Ansible on the main server and deploy a basic webserver.
Follow me if you like my content on twitter at @asouley
Top comments (0)