Ansible architecture

ANSIBLE Architecture

Components in ANSIBLE

Playbook(s):
A playbook consists of one or more plays, which map groups of hosts to well-defined tasks. Here is what you need to know about YAML to get started with your first playbook:

1. The first line of a playbook should begin with "--- " (three hyphens) which indicates the beginning of the YAML document.
2. Lists in YAML are represented with a hyphen followed by a white space. A playbook contains a list of plays; they are represented with "- ". Each play is an associative array, a dictionary, or a map in terms of key-value pairs.
3. Indentations are important. All members of a list should be at the same indentation level. 
4. Each play can contain key-value pairs separated by ":" to denote hosts, variables, roles, tasks, and so on.

Variable(s):

While automation exists to make it easier to make things repeatable, all of your systems are likely not exactly alike. On some systems you may want to set some behavior or configuration that is slightly different from others. Also, some of the observed behavior or state of remote systems might need to influence how you configure those systems. (Such as you might need to find out the IP address of a system and even use it as a configuration value on another system). You might have some templates for configuration files that are mostly the same, but slightly different based on those variables. Variables in Ansible are how we deal with differences between systems.

http://docs.ansible.com/ansible/playbooks_variables.html

Role(s):

To have complete wear and tear, we need some abstraction which allows us to define what we need to configure in each of these groups, and call them by name. That's exactly what roles do. Ansible roles allow us to configure groups of nodes at the same time, without repeating ourselves. Roles also provide a way to create modular code, which then can then be shared and reused. Roles are nothing but directories laid out in a specific manner. Roles follow predefined directory layout conventions and expect each component to be in the path meant for it.

Module(s):

Modules are also known as batteries in Ansible. In short modules are the encapsulated procedures that are responsible for managing specific system components on specific platforms. Modules abstract the actual implementation from users. They expose a declarative syntax that accepts a list of the parameters and states of the system components being managed. All this can be declared using the human-readable YAML syntax, using key-value pairs.

Core Modules:

Ansible ships with a number of modules called Core Modules, that can be executed directly on remote hosts or through Playbooks.

Please see module index from http://docs.ansible.com/ansible/modules_by_category.html to know more about modules and further usage examples.

Custom Modules:

We can also write our own modules. These modules can control system resources, like services, packages, or files (anything really), or handle executing system commands.

To develop your own module refer http://docs.ansible.com/ansible/dev_guide/developing_modules.html

Plugin(s):

By using plugins for Ansible, you can do the following:

·         Add new methods for controlling other machines with connection plugins

·         Use data from external sources outside Ansible in loops or lookups with lookup plugins

·         Add new filters for use with variables or in templates with filter plugins

·         Include callbacks that run when certain actions happen inside Ansible with callback plugins

Connection plugins:

Connection plugins are responsible for relaying files to and from the remote machine, and executing modules. You will no doubt have already used the SSH, local and possibly the winrm plugins with the playbooks used earlier in the book.

Lookup plugins:

Lookup plugins are used in two ways: to include data from outside as a lookup(), or in the with_ style to loop over items. You can even combine the two to loop over external data as is done in the with_fileglob lookup plugin.

Filter plugins:

Filter plugins are extensions to the Jinja2 template engine that Ansible uses to process variables and generate files from templates. These extensions can be used in playbooks to perform data processing on variables, or they can be used inside templates to process data before it is included in the file. They simplify the processing of data by moving the complexity to a Python file and away from the templates or Ansible configuration.

Callback plugins

Callback plugins are used to provide information about actions that are happening in Ansible to external systems. They are automatically activated if they are found in the directories specified under the callback_plugins directory into Ansible configuration. They are often useful when playbooks are being run as automated tasks as they can give feedback via other channels than the standard output.

Callback plugins have a wide variety of uses, as follows:

·         Sending an e-mail at the end of a playbook with the statistics of what changed

·         Recording a running log of changes being made to syslog

·         Notifying a chat channel when a playbook task fails

·         Updating a CMDB as changes are made to ensure an accurate view of the configuration of every system

·         Alerting an admin when a play has exited early because all hosts have failed

If you would like to continue learning about plugins, you can see the plugin development guide at http://docs.ansible.com/ansible/dev_guide/developing_plugins.html   

Ansible Vault:

Ansible provides a utility named Ansible-vault, which as the name suggests, lets you manage data securely. The Ansible-vault utility can either let you create an encrypted file by launching an editor interface, or encrypt an existing file. In either case, it will ask for a vault password, which is then used to encrypt the data with the AES cipher. The encrypted contents can be stored in a version control system without being compromised. Since the AES is based on shared secret, the same password needs to be provided for decryption too. To provide the password, there are two options, while launching Ansible, run the --ask-vault-pass option to prompt for the password, and the --vault-password-file option to provide the path to the file that contains the password.

Please see http://docs.ansible.com/ansible/playbooks_vault.html to know more about Ansible Vault and further usage examples.

Ansible Galaxy:

Ansible Galaxy is a free site where you can download Ansible roles developed by the community and kick-start your automation within minutes. You can share or review community roles so that others can easily find the most trusted roles on Ansible Galaxy. You can start using Ansible Galaxy by simply signing up with social media applications such as Twitter, Google, and GitHub, or by creating a new account on the Ansible Galaxy website ( https://galaxy.ansible.com/ ) and downloading the needed roles using the ansible-galaxy command, which ships with Ansible Version 1.4.2 and later.

Ansible CLI:

Ansible provides CLI to communicate with Ansible Engine.