Ansible Architecture

 

Inventory : It is a text file that describes servers and systems. Here we can find host level variables, groups and roles. We can also define our user accounts to access the certain systems. It could a text file or it could be an executable script to git to manage our systems. 

The default location for inventory is a file called /etc/ansible/hosts. You can specify a different inventory file at the command line using -i <path> option. You can also use multiple inventory files at the same time and pull the inventory from dynamic or could source or different formats ( YAML, ini, etc )

Modules: Modules are discrete units of code that ca be used from the command line or in a playbook task. Ansible executes each module, usually on the remote managed node, and collects return values.

ansible webservers -m service -a "name=httpd state=started"
ansible webservers -m ping
ansible webservers -m command -a "/sbin/reboot -t now"

Each module supports taking arguments. Nearly all modules take key=value arguments, space delimited. Some modules take no arguments, and the command modules simply take the string of the command. 

All the modules return JSON format data. This means modules can be written in any programming language. Modules should be idempotent, and should avoid making any changes if they detect that the current state matches the desired final state. When used in an Ansible playbook, modules can trigger change vents in the form of notifying handlers to run additional tasks. 

A module is a reusable, standalone script that Ansible runs on your behalf, either locally or remotely. Modules interact with your local machine, an API, or remote system to perform specific tasks. Some Ansible modules built into the core of the product called core modules. You can write your own custom modules using python or any other programming language. After you create a module, you can must add it locally to the appropriate directory so that Ansible can find and execute it. 

Ansible Galaxy refers to the Galaxy Website, a free site for finding, downloading, and sharing community developed roles. 

Playbooks: Playbook record and execute Ansible's configuration, deployment, and orchestration functions. They can describe a policy you want your remote systems to enforce, or set of steps in general IT process.

Ansible Playbook offers a repeatable, re-usable, simple configuration management and multi-machine deployment system. If you need to execute a task with Ansible more than once, write a playbook and put it under source control. Then you can use playbook to push out new configuration or confirm the configuration of remote systems. 

Playbooks can:

• declare configurations
• orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order. 
• Launch tasks synchronously or asynchronously.

Play: Inside Playbook there are individual plays. Each play is a group together in a playbook. This is how we can build an automation and orchestration by defining individual plays to be executed in a pre-defined order. 

Ansible Config: Ansible supports several sources for configurating its behavior, including an ini file named ansible.cfg, environment variables, command-line options, playbook keywords, and variables. 

The ansible-config utility allows users to see all the configuration settings available, their defaults, how to set them and where their current value comes from. 

Changes can be made and used in a configuration file which will be searched for in the following order:

• ANSIBLE_CONFIG (environment variable if set)
• ansible.cfg (in the current directory)
• ~/.ansible.cfg (in the home directory)
• /etc/ansible/ansible.cfg

Python: Ansible takes all of the components and pushes it through the python component to build a package to be delivered to the remote systems using the python frame work also help in building the variable.