Category: Ansible

Ansible – Inventory

admin

Ansible Inventory is a collection of Nodes/hosts/servers/systems. Ansible inventories are used when we have to execute ansible commands/playbooks on multiple hosts or nodes.

We can either have individual hosts added to the inventory file or we can group these hosts like DB servers and web servers.

Grouping the Host/Nodes in inventory files allows us to run commands/playbooks on a specific set of servers.

Types of Inventory

  • Static Inventory
  • Dynamic Inventory

Static Inventory consists of a list of static hosts defined in inventory files, these are hardcoded and cannot be changed during run time.

Dynamic Inventory is used when we have a dynamic environment of Hosts/Node and we are not aware of the host IP address etc. An example of a Dynamic Environment is a cloud environment.

Dynamic Inventory is created using scripts in Python, and Shell Scripts.

Ansible has pre-built scripts for dynamic environments on certain cloud environments,

  • AWS EC2
  • GCP Compute Service
  • OpenStack
  • Jail, Spacewalk, etc.

Syntax

ansible -i <inventory_file> <group_name1> <group_name2> -m setup

The default ansible inventory file is defined in ansible.cfg file.

Syntax, Dynamic inventory file

ansible -i ec2.py <group_name> -m ping

Raw Module

Ansible allows running the Adhoc commands on the host/node which do not have python installed. We will need to use the raw module to execute such commands.

Syntax

ansible localhost -m raw -a ping
ansible localhost -m raw -a uptime

Ansible – Facts

admin

Ansible Facts are used to fetch information about the managed nodes. The fact can provide a wide range of information about nodes/servers/systems etc.,

  • Processor details
  • Memory
  • Python version
  • OS release, distribution, etc.

Ansible’s setup module is used to gather these facts/information.

Facts are gathered in both Ansible Ad-Hoc commands and in the Ansible playbooks. In Ad-hoc commands, we need to explicitly run the setup module command, whereas in playbooks facts are by default gathered.

Syntax

ansible localhost -m setup

The setup module default will display all information about your node/system.

The facts information will be displayed in JSON/python dictionary format.

We may not be interested in such large Node/system information. We may be interested only in specific information about the node. Ansible does provide us the option to fetch only the information which is required from the facts.

We can retrieve specific required data from facts by passing the argument filter in your setup module ad-hoc command.

Syntax

ansible localhost -m setup -a "filter=ansible_python_version"
ansible localhost -m setup -a "filter=ansible_distribution"

Types of Ansible Facts

  • Default Facts, the default system information fetched using the setup module are called default facts. These facts do not provide details of any third-party application installed on the node, like MySQL, Splunk, etc.
  • Custom Facts are created to gather information about the third-party applications/services installed on your node/system, like Splunk, Mysql server, etc.

Custom Facts are required when we need information about third-party applications installed on the host or nodes. This information is like version details of third-party applications Splunk, Apache, MySQL server, etc.

Steps to create Custom facts

  1. Create your custom facts file at /etc/ansible/facts.d directory
  2. Create custom facts file with exention .fact under your /etc/ansible/fact.d directory.
  3. Custom facts files can be created using python, and shell script, but the files should be saved with .fact as a file extension.
  4. Set executable permission to the fact files.

Syntax to execute custom facts

ansible localhost -m setup -a "filter=ansible_local"

Ansible – Command vs Shell Module

admin

The Shell Module as well as command modules are used to execute Binary Commands.

The command module is the default module to execute the binary commands, if we do not specify the module name in our ad-hoc command, ansible will by default use the command module.

The command module will execute the commands without proceeding to through the shell.

The command module will not recognize certain variables like $HOME

Stream operators like <,>, &, and | will not work with command modules.

The command module is more secured, compared to the shell module

For example, both shell and command module will have the same outputs,

ansible localhost -m shell -a "uptime"
ansible localhost -m command -a "uptime"

The stream operator, when passed through the shell and command module, will show different results, as the command module doesn’t recognize the stream operators and will throw errors, whereas the same will work fine with the shell module.

Command Module, will throw an error as it will not recognize > stream operator

ansible localhost -m command -a "uptime > uptime.txt"

Shell Module

ansible localhost -m shell -a "uptime > uptime.txt"

Ansible – Default Command module

admin

The Ansible command module is the default module that ansible. It is used to execute Binary Commands.

The command module will execute if we do not specific module name in Ansible Ad-Hoc commands.

ansible localhost -m command -a "uptime"

In the above example, we are passing the module as a command, if we skip the module name, ansible will still execute the command and will pick the command as the default module, the output will be the same for both ad-hoc commands.

ansible localhost -a "uptime"

Ansible – Install Packages

admin

Ansible can be used to install application packages like Git, apache, Mysql, etc. These packages can be installed using Ansible Ad-Hoc commands or through ansible Playbooks.

Syntax – To install the git package on the Ubuntu system.

ansible localhost -m apt -a "name=git state=present" -b

  • localhost – inventory, the host to be targeted.
  • -m module name, here we are using apt for Ubuntu/Debian systems. For the Linux systems using yum.
  • -a arguments passed for installation of the package.
    • name – package name to be installed.
    • state – Ansible provides multiple state options
      • present/installed – to install package
      • latest – to update the existing package
      • absent/removed – to uninstall package
  • -b argument to change the owner, like to grant sudo privileges

Output –

Ansible – Modules

admin

Ansible Modules are pre-defined, reusable scripts, Ansible ships the default modules with the install package, and also allows the creation of custom modules.

AnsibleModules can be used with Ansible Ad-hoc commands or with Ansible-playbook.

To list all modules available with your Ansible installation run the below command,

> ansible-doc -l

Ansible – Ad-hoc Command Structure

admin

Ansible provides us the option to either run playbooks or ad-hoc commands on the local and remote nodes through ansible engines.

Let us look at an Ansible ad-hoc command example

> ansible localhost -m shell -a "uptime"

The above command can be divided into the following parts,

  • localhost – You can specify the target host/groups here where you want the command to be executed.
  • -m shell – You define the Ansible module, in our example shell.
  • -a “uptime” – Pass the command arguments in double quotes string.

To run the commands on custom inventory host files,

> ansible localhost -m shell -a "uptime" -i custom_inventory_file

On a similar line, we can create our own ad-hoc commands.

ansible.cfg – file priority

admin

We can have the ansible.cfg file at various locations, the default location shipped with ansible installation is at,

/etc/ansible/ansible.cfg

The default ansible.cfg has the least priority when you have multiple ansible.cfg defined in your system/server.

The priority is set to ansible.cfg file is based on how it is defined or stored,

  • ANSIBLE_CONF – Environment variable, defined in your server/system.
  • ./ansible.cfg – Ansible config file defined in your current working directory.
  • ~/.ansible.cfg – Ansible config file defined in your home directory.
  • /etc/ansible/ansible.cfg – Ansible config file defined in default location.