Ansible Playbooks

Playbooks are YAML files that are used for #202204272021 configuration. Structurally, it contains plays, 202205042134#, 202204300820#, and 202204300825#. They could be run by the command line ansible-playbook or #202204300954. It is shown as below:

--- # start of a play
- name: install and start apache
  hosts: web  # individual host or group
  become: yes # This is a plugin that escalate privilege (root permission)

  vars: # define variables for a play, not recommended
    var1: Ansible
    var2: This is
    var3: "{{ var2 }} {{ var1 }}" # Result: This is Ansible

  tasks:  # From here, define tasks
    - name: httpd package is present
      yum: # This is a module
        name: httpd
        state: latest
      debug:  # Debugging messages
        msg: "some debugging messages"

    - name: latest index.html is present
      template: # This is a module
        src: files/index.html
        dest: /var/www/html/

    - name: httpd is started
      service: # This is a module
        name: httpd
        state: started

Note: The order of the tasks written in the playbook is their order of execution.

Note: In the play section, we could add role to import 202205042207#. If we just need that role for a task, we could include it using include_role under tasks.

Links to this page

Automation Controller

The basic unit for Automaton Controller is Automation Job. It consists of project (collection of 202204272036# with 202208131616# or within the Automation Controller instance), credential such as CyberArk and Vault and 202204272043# which composed of 202206151453#, username, and access method (202205251209, 202205191908, API). Automation Job could be defined in a Job Template.

Note: It is a common practice to avoid defining host or group in the 202204272036# within Automation Controller since the inventory already had it covered.
Ansible Variables

For conditionals, we could use the #202204300820 when. One can use comparison operators such as ==, !=, >, >=, < and <=, or in keyword to check whether the value is found in a list. It has some limitation for potential large amount of tasks. For this, it is advised to use handler or separate the tasks into a #202204272036 and then included later. The usage is shown as below:

Module notify is used to notify the handlers when there is a change of state of the task. Use the module handlers to define handler. Its format is quite similar to #the tasks module. For example:

Variables could be defined in #202204272036 and #202204272043. However, it is recommended to put variables, primarily credentials that are essential for connection such as username and password, into Inventory.
Ansible Templates

Templates use Jinja2 templating to generate files based on defined #202205042134. Use the #202204300820 template inside #202204272036. The following shows its usage:
Ansible Roles

By default, roles module defined in #202204272036 will look into local directory to find roles. If namespace is given to a role, it will in turn find it in content sharing platform.

Role is a disaggregated #202204272036 which is reusable and #distributable (could be seen as a collection). It has a directory structure which includes default variables, handlers and others#, metadata (dependencies which could be fetched by 202205051149#), tasks, 202205051607#, and tests, shown as below:
Ansible Plugins

Ansible Plugins allow a #202204272036 to execute extra functionalities or change behaviours without support from Ansible architecture.
Ansible Modules

The 202205042134# defined within a module is call a fact. Run ansible all -m {module} to check all the facts that has been defined in the module specified. Since facts are variables, we could use them in #202204272036 using the Jinja syntax {{ }}.
Ansible Inventory

Inventory is a list of nodes, where #202204272036 run against, managed by #202204272021. Ansible has a default inventory file /etc/ansible/hosts but it could be changed using the option -i. We could create multiple groups that can contain multiple hosts either in domain name or 202206151453# within an inventory.
Ansible Content Navigator

Executing the command run {playbook} will run the 202204272036# on the managed nodes. With --check option, Ansible navigator will dry run the specified playbook which means that the configuration will not impose on the managed nodes.

ansible-navigator is a #202204292323 command line interface (CLI) tool to view or monitor various #202204272021 information. It can run 202204272036# and 202204300942#. It is an enhanced version of ansible-playbook which unlike the latter, can run EE.
Ansible Collection

Collection is a data structure used to store several #202204272021 components such as 202204272036#, 202204300820#, 202205042207# (could be multiple of them), 202204300825#, documentations and tests. The components could be updated asynchronously and independently without affecting the Ansible runtime. It is usually used for #content delivery in tar ball.
Ansible

To use Ansible, we need to install it into a node, which will become the management node or control node where we will place our configuration files or 202204272036# in here. Ansible will then run on remote hosts called managed nodes using the playbooks without actually installed into them. By default, it uses 202205191908 as the mean of communication between management node and managed nodes. We could configure it in 202204302318# to use SFTP or SCP instead. The SSH public key needs to be transferred to the managed nodes.

#automation