1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
Control node
============
The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others).
You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible.
Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features.
Managed nodes
=============
Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible.
Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup.
Inventory
=========
A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address.
It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment.
To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section. Sometimes an inventory source file is also referred to as a 'hostfile'.
Playbooks
=========
They contain Plays (which are the basic unit of Ansible execution). This is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates.
Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`.
Plays
-----
The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks.
The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly.
It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them.
Roles
.....
A limited distribution of reusable Ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play.
To use any Role resource, the Role itself must be imported into the Play.
Tasks
.....
The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file).
You can execute a single task once with an ad hoc command using ``ansible`` or ``ansible-console`` (both create a virtual Play).
Handlers
........
A special form of a Task, that only executes when notified by a previous task which resulted in a 'changed' status.
Modules
=======
The code or binaries that Ansible copies to and executes on each managed node (when needed) to accomplish the action defined in each Task.
Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device.
You can invoke a single module with a task, or invoke several different modules in a playbook.
Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`.
Plugins
=======
Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins),
manipulate data (filter plugins) and even control what is displayed in the console (callback plugins).
See :ref:`working_with_plugins` for details.
Collections
===========
A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other.
AAP
===
Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on.
|
