Ansible is an open source, IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. In this article, we’ll now discuss ansible architecture and the difference between push-based vs pull based as well.

Let's begin by looking at the ansible architecture shown in the diagram below and discussing one by one of its components.

Host Inventory:

                By default, ansible will maintain/create a host inventory file at its default location is '/etc/ansible/hosts' after successful installation of ansible. With the help of this host inventory file, we want to know ansible which servers to connect and manage. Ansible's inventory host file is used to manage lists of the nodes or server’s group that have their IP address.

If we try to see the host file contents that will be the same as below.

In the inventory host file, we may mention any of both hostnames or ip addresses.

Let's take a sample of the actual content of the host inventory file as below.

Also, we can even have the host inventory file at custom location. So to know the ansible, custom file location, we need to set the environment variables or we need to pass the location of the custom host inventory file while running the commands via command line arguments (i.e. ‘inventory-file=file_location’ or ‘-i’).

export ANSIBLE_HOSTS=custom_host_inventory_file_location

               

Playbooks:

            Playbooks are nothing but files consisting of your written code, and they are written in YAML format, which defines the tasks and executes them through the Ansible. Playbooks may include one or more plays. Plays defines a set of activities or tasks to be run on hosts of inventory file.

 

Modules:

                Ansible comes with hundreds of inbuilt modules and modules are those pieces of code that get executed when you run a playbook. Ansible connected the nodes and spread out the Ansible modules programs. Ansible executes the modules and removed after finished. These modules can reside on any machine; no database or servers are required here. You can work with the chose text editor or a terminal or version control system to keep track of the changes in the content.

 

Plugins:

                Plugins are special types of modules here. These plugins are executed on the nodes before a module gets executed. Plugins are a piece of code which expends Ansible 's core functionality. There are plugins that are useful, and you can also write your own. While modules run in separate processes on the target machine (usually that means on a remote node), plugins run on the control node.

 

Private / Public Cloud:

                This can be act as a repository for all the IT installation and configurations in the servers. These are the remote servers that are hosted on the internet and storing the data remotely rather than the local server. This cloud can be used to store, manage, and process the data.

 

Hosts:

Hosts are nothing but node machines that are managed by Ansible, which can be any machine like RedHat, Linux, Windows, etc… We have a 'n' number of host machines in the above architecture to which ansible server connects and pushes through SSH the playbooks to. So, it's a listing of all the hosts' IP addresses.

 

Pull Based vs Push Based (Configuration Management Tool):

            Push Based:

• Ansible, Saltstack are push-based configuration management tools.
• In this type of tools, main/central server push the configuration information to the nodes.
• You control the nodes when the changes are made on the server.
• So, it’s the main server that initiates communication, not the nodes. Which means that an agent/client may or may not be installed on each node.

 

Pull Based:

• Puppet, Chefs are pull based configuration management tools.
• In this type of tools, the nodes pull the configuration information from the server.
• A small software called agents/clients’ needs to be installed in every node.
• Agents/clients on the nodes checks for the configuration information from server at regular intervals.
• Nodes shall receive any new configurations, checking with server at all times.
• So, it’s always the agent/client that initiates communication, not the main/central server.

 

That’s all about ansible architecture and push based vs pull based configuration management tools. At the end, based on your needs and customizations you're willing to do, you have to select the tool.