Ansible Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 76: Line 76:


A task combines an [[#Action|action]] (a [[#Module|module]] and its arguments) with a name and optionally some other keywords like looping directives. [[#Handler|Handlers]] are also tasks, but they do not run unless they are notified by name when a task reports an underlying change on a remote system. [[#Playbook|Playbooks]] exist to run tasks.
A task combines an [[#Action|action]] (a [[#Module|module]] and its arguments) with a name and optionally some other keywords like looping directives. [[#Handler|Handlers]] are also tasks, but they do not run unless they are notified by name when a task reports an underlying change on a remote system. [[#Playbook|Playbooks]] exist to run tasks.
Ansible tasks are idempotent, they can be safely run repeatedly. Idempotence is achieved by the fact that ansible first gathers the context, which consists of [[#Fact|facts]], before running the tasks.


=Action=
=Action=

Revision as of 04:19, 12 December 2019

External

Internal

Overview

Ansible is a configuration management and provisioning tool, similar to Chef, Puppet or Salt. What sets it aside is that it does not require agents on the hosts it configures - it only requires ssh access and sudo.

Workflow

The target hosts are specified in the inventory file, located on the "ansible host". Then ansible is executed on that host. During the execution, ansible connects via SSH to the target hosts , gets the context and executes tasks being cognizant of the context.

Inventory File

http://docs.ansible.com/ansible/intro_inventory.html#inventory

Ansible works against multiple systems at the same time. It does this by selecting portions of systems listed in Ansible’s inventory file. The default location of the inventory file is /etc/ansible/hosts.

A different location of the inventory file can be specified on the command line with:

-i <path>

Inventory File Structure

host1.example.com

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com
db2.example.com

Groups

The headings in brackets are group names, which are used in classifying systems and deciding what systems you are controlling at what times and for what purpose. A host can be part of more than one group.

Default Groups

There are two default groups: "all" and "ungrouped". "all" contains every host. "ungrouped" contains all hosts that don’t have another group aside from "all".

Recursive Groups

Recursive groups are declared with the [<group-name>:children].

[A]
host1
host2

[B]
host3
host4

[AandB:children]
A
B

[AandB:vars]
something=something-else

Playbook

Playbooks exist to run tasks.

Task

A task combines an action (a module and its arguments) with a name and optionally some other keywords like looping directives. Handlers are also tasks, but they do not run unless they are notified by name when a task reports an underlying change on a remote system. Playbooks exist to run tasks.

Ansible tasks are idempotent, they can be safely run repeatedly. Idempotence is achieved by the fact that ansible first gathers the context, which consists of facts, before running the tasks.

Action

An action is a module and its arguments.

Module

A module will be executed individually, on command line, in the same way as it would be executed as part of a playbook.

ansible -m <module-name> -a "arg1 arg2 ..."

Example:

ansible -m shell -a "echo {{ a_global_variable }} > /tmp/test.txt"

A module is declared as follows:

- name: This is a descriptive name of what the module execution will achieve
  <module-name>: ...
  ...

Example:

- name: This is a descriptive name of what the module execution will achieve
  shell: echo {{ openshift_dns_ip }} > /etc/origin/node/openshift-dns-ip
  args:
    executable: /bin/bash

shell

shell

command

command

Role

Roles are units of organization. Assigning a role to a group of hosts implies that they should implement a specific behavior. A role may include applying certain variable values, certain tasks, and certain handlers. Roles are redistributable units that allow you to share behavior among playbooks. Conventionally, the elements associated with a role are stored in a directory named after the role:

roles
  |
  +- role1
  |    |
  .    +-- files
  .    +-- handlers
  .    +-- meta
       +-- tasks
       +-- templates 

  |
  +- role2
  +- role3
  ...

Handler

Handlers are just like regular tasks in a playbook (see Tasks) but are only run if the task contains a notify directive and also indicates that it changed something.

For example, if a config file is changed, then the task referencing the config file templating operation may notify a service restart handler. This means services can be bounced only if they need to be restarted. Handlers can be used for things other than service restarts, but service restarts are the most common usage.

Variable

Group Variables

Group variables are declared with [<group-name>:vars] in the inventory file. If they are declared this way, the variables apply to an entire group at once.

[group-A]
host1
host2

[group-A:vars]
something=something-else

Host Variables

Variables that apply to a specific host are declared in the inventory file after the host name:

[group1]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909

Fact

http://docs.ansible.com/ansible/glossary.html#term-facts

Facts are pieces of information about remote nodes. Facts can used in playbooks and templates just like variables, but they are inferred, rather than set, during automatic discovery when running plays, by executing the internal setup module on the remote node.

Directives

notify

Template

A template is a file to be installed on the target system after the declared variables are substituted with actual values. Variable values may come from the inventory file, host variables, group variables, or facts. Templates use the Jinja2 template engine and can also include logical constructs like loops and if statements.