RH Ce Student

RHCE
8 – EX294
Click to edit Master title style
Introduction
About this course
• This course doesn't replace my "Ansible Fundamentals" course,
neither my "Automating with Ansible" (Ansible Advanced) course
• Ansible Fundamentals is a brief introduction to key items in Ansible
and is a good course to take before taking this course
• Automating with Ansible focusses on managing datacenter
environments with Ansible, and is about more than just managing
RHEL
• This course prepares for the RHCE 8 Certification, and is the most
complete Ansible course I'm offering
Warning
• Today (Sept. 3 2019) is the first time I'm teaching this course
• At least some things will go wrong
• As this is the first time I'm teaching this course, I'm very eager to
getting your feedback. Please take the course survey!
• Or send feedback directly to mail@sandervanvugt.nl
Poll questions 1
Are you currently RHCSA certified?
• yes
• no
Poll Questions 2
How would you rate your own Ansible experience?
• 0
• 1
• 2
• 3
• 4
• 5
Poll Questions 3
Which part of the world are you from?
• Africa
• India
• Asia (not India)
• Europe
• North/Middle America
• South America
• Australia/Pacific
• Netherlands
Agenda – day 1
Day 1
• Introduction
• Setting up an Ansible Managed Environment
• Using Ad-hoc Commands
• Getting started with Playbooks
• Working with Variables and Facts part 1
• Day 1 Homework Assignment
Agenda – day 2
Day 2
• Day 1 Homework Lab Discussion
• Working with Variables and Facts part 2
• Using Task Control
• Deploying Files with Templates
• Day 2 Homework Lab Explanation
Agenda – day 3
Day 3
• Using Ansible Roles
• Using RHEL System Roles
• Using Ansible in Large Environments
• Day 3 Homework Lab Explanation
Agenda – day 4
Day 4
• Troubleshooting Ansible
• Advanced Ansible Usage Examples
• Exam Tips and Q&A
Lab Setup Requirements
• Install 3 VM's, using RHEL8 or CentOS 8, and the "Minimal Setup"
installation pattern
• control.example.com, 192.168.4.200
• ansible1.example.com, 192.168.4.201
• ansible2.example.com, 192.168.4.202
• The machines require Internet access
• Create a user with the name ansible
RHCE 8 – EX294
1. Introduction
RHCE7 vs. RHCE8
• Until RHCE 7, RHCE was about advanced Linux topics
• In RHCE 8, Ansible is the main topic
• More information is here:
https://www.redhat.com/en/blog/announcing-evolution-red-hat-
certified-engineer-program
EX407 and EX294
• EX407 was the old Ansible exam
• EX294 has taken over the contents of this exam, so EX407 is no
longer relevant
• EX447 (Advanced Automation) has been added to the certification
options
RHCE 8 – EX294
2. Setting up an Ansible
Managed Environment
Understanding Ansible
• Ansible is a Configuration Management solution
• It can be used for configuring a wide range of networked
devices
• With Ansible, you'll use playbooks that define the desired
state of managed machines
• These playbooks ensure that no matter the current state of
the managed machine, the desired state will be implemented
• Playbooks are written in YAML, and in playbooks you'll use
Ansible modules to define the tasks that have to be
accomplished
• One requirement is Python: Ansible uses Python to generate
scripts that are executed on the managed nodes
• Another requirement is access to the managed node,
typically this is done using SSH
Host Requirements
• The control node is where you install Ansible
• For RHCE 8, you'll install on top of RHEL 8
• Make sure a fixed IP address is set up, as well as a hostname
• The managed nodes are managed by Ansible
• Managed nodes can be anything: servers running RHEL, but also
other Linux distributions, Windows, Network Devices and much
more
• For RHCE 8, you'll need 2 managed nodes pre-installed with RHEL 8
• Ensure host name lookup is configured, /etc/hosts is good enough
• For installation from the repositories, enable the EPEL repository
Course Lab Setup
• In this course, a 3-node lab setup is used
• control.example.com is the control node. It is not
managed by Ansible, but it manages the other nodes
• ansible1.example.com and ansible2.example.com are
the managed nodes
• To get started, these nodes need a fixed IP address, and
a root user, everything else will be set up later
RHCE 8 – EX294
2.1 Installing Ansible

Installing Ansible
• Ansible can be installed from the repositories, or using the Python pip
installer
• In this procedure you'll see how to use Python pip
Using Python pip to Install Ansible
1. On all nodes: useradd ansible
2. echo password | passwd --stdin ansible
3. echo "ansible ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/ansible
4. On control.example.com: su - ansible; ssh-keygen
5. ssh-copy-id ansible1.example.com; ssh-copy-id ansible2.example.com
6. su -
7. yum install python3
8. yum -y install python3-pip
9. alternatives --set python /usr/bin/python3
10. su - ansible; pip3 install ansible --user
11. ansible --version
RHCE 8 – EX294
2.2 Seting up sudo and SSH

Preparing Managed Nodes - 1
• Ansible needs a dedicated non-root user account with sudo privileges that
can SSH into the managed nodes without entering a password
• In this course we'll use an account with the name ansible to do so
• To set up this account, you need to do the following
• useradd ansible
• echo "password" | passwd --stdin ansible
• echo "ansible ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/ansible
Preparing Managed Nodes - 2
• On the control host, generate an SSH key and copy over to the
managed nodes
• ssh-keygen
• ssh-copy-id ansible1.example.com
• Install Python3
• yum install python3
• alternatives --set python /usr/bin/python3
Verifying Ansible Installation
• As user ansible, type ansible --version
• Further verification is not possible yet, as additional
settings need to be done
Poll Question
Which of the following is not a requirement while setting up Ansible
• Create a user that has the same name on all managed machines
• Install Python on all managed machines
• Enable SSH if you're managing Linux
• Create an inventory file
RHCE 8 – EX294
2.3 Setting up Inventory

Managing Static Inventory
• In a minimal form, a static inventory is a list of host names and IP
addresses that can be managed by Ansible
• Hosts can be grouped in inventory to make it easy to address
multiple hosts at once
• A host can be a member of multiple groups
• Nested groups are also available
• It is common to work with project-based inventory files
• Variables can be set from the inventory file - but this is
deprecated practice
• Ranges can be used:
• server[1:20] matches server1 up to server20
• 192.168.[4:5].[0:255] matches two full class C subnets
Inventory File Locations
• /etc/ansible/hosts is the default inventory
• Alternative inventory location can be specified through the
ansible.cfg configuration file
• Or use the -i inventory option to specify the location of the
inventory file to use
• It is common practice to put the inventory file in the current
project directory
Static Inventory Example
[webservers]
web1.example.com
web2.example.com
[fileservers]
file1.example.com
file2.example.com
[servers:children]
webservers
fileservers
Host Groups Usage
• Functional host groups
• web
• lamp
• Regional host groups
• europe
• africa
• Staging host groups
• test
• development
• production
Testing Inventory
• ansible --list-hosts
• ansible file --list-hosts
Little Lab 1
• Create an inventory file with 4 servers in 2 groups, make sure that
at least one server is NOT included in any groups
• Use ansible -i inventory all --list-hosts
• ansible -i inventory ungrouped --list-hosts
• ansible -i inventory file --list-hosts
• Mention that -i is required as we have not yet specified a default
inventory location, but if we would have used /etc/ansible/hosts it
is not required to use -i
Understanding Dynamic Inventory
• Dynamic inventory can be used to discover inventory in
dynamic environments such as cloud
• Many community-provided dynamic inventory scripts are
available
• These scripts are referred to in the same way as static
inventory, but must have the execute permission set
• Alternatively, it's relatively easy to write your own
dynamic inventory
RHCE 8 – EX294
2.4 Managing Ansible

Configuration Files
Understanding ansible.cfg
• Settings in ansible.cfg are organized in two sections
• [defaults] sets default settings
• [privilege_escalation] specifies how Ansible runs commands on
managed hosts
• The following settings are used:
• inventory specifies the path to the inventory file
• remote_user is the name of the user that logs in on the remote
hosts
• ask_pass specifies whether or not to prompt for a password
• become indicates if you want to automatically switch to the
become_user
• become_method sets how to become the other user
• become_user specifies the target remote user
• become_ask_pass sets if a password should be asked for when
escalating
Connecting to the Remote Hosts
• The default protocol to connect to the remote host is SSH
• Key based authentication is the common approach, but password based
authentication is possible as well
• Use ssh-keygen to generate a public/private SSH key pair, and next use
ssh-copy-id to copy the public key over to the managed hosts
• Other connection methods are available, to manage Windows for
instance, use ansible_connection: winrm and set ansible_port: 5986
Escalating Privileges
• sudo is the default mechanism, su can also be used but is uncommon
• A password can be asked for, but it's common to do password-less
escalation
• To setup password-less sudo, create a snapin file in /etc/sudoers.d/ with
the following contents:
• ansible ALL=(ALL) NOPASSWD: ALL
Understanding Localhost Connections
• Ansible has an implicit localhost entry to run Ansible commands
on the localhost
• When connecting to localhost, the default become settings are
not used, but the account that ran the Ansible command is used
• Ensure this account has been configured with the appropriate
sudo privileges
Managing ansible.cfg
• The ansible.cfg file is considered in order of precedence:
• /etc/ansible/ansible.cfg is the default
• ˜/.ansible.cfg if exists will overwrite the default
• ./ansible.cfg is the configuration file in the current Ansible
project directory and it will always have precedence if it exists
• Alternatively, if a variable ANSIBLE_CONFIG exists to refer to a
specific config file, this will always have precedence
• Use ansible --version to find which configuration file currently
is used
RHCE 8 – EX294
3. Using Ad-hoc Commands

RHCE 8 – EX294
3.1 Using Ad-hoc Commands

Understanding Ad Hoc Commands
• To run tasks on Ansible, you'll typically want to use Playbooks
• A Playbook is a YAML file in which tasks can be defined
• For some tasks, writing a playbook is just too much work
• In such cases, you can use Ad hoc commands
• Ad hoc commands are also useful for testing if your playbook
was successful
Ad Hoc Commands Ingredients
• The basic structure is ansible hosts -m module [-a 'module
arguments'] [-i inventory]
• The hosts part specifies on which host the command should be
performed
• The module part indicates which Ansible module to use; following
the module you'll specify module arguments
• If inventory is not specified, you'll need to specify the inventory as an
argument
• An example of an ad hoc command is ansible all -m user -a
"name=lisa"
• And to verify the command works, use ansible all -m command -a "id
lisa"
RHCE 8 – EX294
3.2 Working with Modules

Understanding Ansible Modules
• Ansible comes with lots of modules that allow you to perform specific
tasks on managed hosts
• When using Ansible, you'll always use modules to tell Ansible what you
want it to do, in ad-hoc commands as well as in playbooks
• Many modules are provided with Ansible, if required you can develop
your own modules
• Use ansible-doc -l for a list of modules currently available
• All modules work with arguments, ansible-doc will show which
arguments are available and which are required
• Ansible modules are idempotent: which means that when running
them again they'll give the same result and if a task has already been
configured, they won't do it again
Essential Ansible Modules
• ping: verifies the ability to log in and that Python has been installed
• ansible all -m ping
• service: checks if a service is currently running
• ansible all -m service -a "name=httpd state=started"
• command: runs any command, but not through a shell
• ansible all -m command -a "/sbin/reboot -t now"
• shell: runs arbitrary commands through a shell
• ansible all -m shell -a set
• raw: runs a command on a remote host without a need for Python
• copy: copies a file to the managed host
• ansible all -m copy -a 'content="hello world" dest=/etc/motd'
RHCE 8 – EX294
3.3 Using ansible-doc

Using ansible-doc
• The ansible-doc command provides authoritative
documentation about modules
• Use ansible-doc -l for a list of all modules
• Use ansible-doc modulename to get the documentation for a
specific module
Understanding Module Status
Modules are very actively developed by the community, and the status field in
the module documentation indicates the current status
• stableinterface: the module is stable and safe to use
• preview: the module is in tech preview and its keywords may change
• deprecated: the module should not be used anymore, and will be removed
in a future release
• removed: the module has been removed, and the documentation only still
exists to help users migrating to its replacement
Understanding Module Support Status
The supported_by field in ansible-doc indicates who is responsible for
supporting a module
• core: the module is supported by the core Ansible developers
• curated: the primary support responsibility is with partners and
companies in the community. Proposed changes are reviewed by
the core developers
• community: support is completely within the community
Poll Question
Which of the following modules should you use to install Python on a new
managed machine?
• command
• shell
• yum
• raw
RHCE 8 – EX294
4. Getting Started with

Playbooks
Why Playbooks?
• Ad-hoc commands can be used to run one or a few tasks
• Ad-hoc commands are convenient to test, or when a
complete managed infrastructure hasn't been set up yet
• Ansible Playbooks are used to run multiple tasks against
managed hosts in a scripted way
• In Playbooks, one or multiple plays are started
• Each play runs one or more tasks
• In these tasks, different modules are used to perform the
actual work
• Playbooks are written in YAML, and have the .yml or
.yaml extension
Understanding YAML
• YAML is Yet Another Markup Language according to some
• According to others it stands for YAML Ain't Markup Language
• Anyway, it's an easy-to-read format to structure tasks/items
that need to be created
• In YAML files, items are using indentation with white spaces to
indicate the structure of data
• Data elements at the same level should have the same
indentation
• Child items are indented more than the parent items
• There is no strict requirement about the amount of spaces
that should be used, but 2 is common
Optimizing vim for YAML
• In ~/.vimrc, include the following setting:
• autocmd FileType yaml setlocal ai ts=2 sw=2 et
Writing Your First Playbook
---
- name: deploy vsftpd
hosts: ansible2.example.com
tasks:
- name: install vsftpd
yum: name=vsftpd
- name: enable vsftpd
service: name=vsftpd enabled=true
- name: create readme file
copy:
content: "free downloads for everybody"
dest: /var/ftp/pub/README
force: no
mode: 0444
...
Running Your First Playbook
• Use ansible-playbook vsftpd.yml to run the playbook
• Notice that a successful run requires the inventory and become
parameters to be set correctly, and also requires access to an
inventory file
• The output of the ansible-playbook command will show what
exactly has happened
• Playbooks in general are idempotent, which means that running
the same playbook again should lead to the same result
• Notice there is no easy way to undo changes made by a
playbook
Verifying Playbook Syntax
• ansible-playbook --syntax-check vsftpd.yml will perform a
syntax check
• Use -v[vvv] to increase output verbosity
• -v will show task results
• -vv will show task results and task configuration
• -vvv also shows information about connections to managed
hosts
• -vvvv adds information about plug-ins, users used to run scripts
and names of scripts that are executed
• Use the -C option to perform a dry run
Understanding Plays
• A play is a series of tasks that are executed against selected hosts from the
inventory, using specific credentials
• Using multiple plays allows running tasks on different hosts, using different
credentials from the same playbook
• Within a play definition, escalation parameters can be defined:
• remote_user: the name of the remote user
• become: to enable or disable privilege escalation
• become_method: to allow using an alternative escalation solution
• become_user: the target user used for privilege escalation
RHCE 8 – EX294
5. Working with Variables and

Facts part 1
RHCE 8 – EX294
5.1 Understanding and Using

Variables
Understanding Variables
• A variable is a label that is assigned to a specific value to
make it easy to refer to that value throughout the playbook
• Variables can be defined by administrators at different
levels
• A fact is a special type of variable, that refers to a current
state of an Ansible managed system
• Variables are particularly useful when dealing with managed
hosts where specifics are different
• Set a variable web_service on Ubuntu and Red Hat
• Refer to the variable web_service instead of the specific
service name
Using Variables
• Variables can be set at different levels
• In a playbook
• In inventory (deprecated)
• In inclusion files
• Variable names have some requirements
• The name must start with a letter
• Variable names can only contain letters, numbers,
and underscores
Defining Variables
• Variables can be defined in a vars block in the beginning of a playbook
- hosts: all
vars:
web_package: httpd
• Alternatively, variables can be defined in a variable file, which will be

included from the playbook
- hosts: all
vars_files:
- vars/users.yml
Using Variables
• After defining the variables, it can be used later in the playbook
• Notice that order does matter!
• Refer to a variable as {{ web_package }}
• If the variable is the first element, using quotes is mandatory!
• "{{ web_package }}"
RHCE 8 – EX294
5.2 Managing Variable

Precedence
Understanding Variable Scope
• Variables can be set with different types of scope
• Global scope: this is when a variable is set from inventory or the
command line
• Play scope: this is applied when it is set from a play
• Host scope: this is applied when set in inventory or using a host
variable inclusion file
• When the same variable is set at different levels, the most
specific level gets precedence
• When a variable is set from the command line, it will
overwrite anything else
• ansible-playbook site.yml -e "web_package=apache"
Understanding Built-in Variables
Some variables are built in and cannot be used for anything else
• hostvars
• inventory_hostname
• inventory_hostname_short
• groups
• group_names
• ansible_check_mode
• ansible_play_batch
• ansible_play_hosts
• ansible_version
Poll Question
Which of the following variable names is invalid?
• myvar
• groups
• my-var
• 123_var
RHCE 8 – EX294
5.3 Managing Host Variables

Using Host Variables
• Variables can be assigned to hosts and to groups of hosts
• The old way of doing so is through inventory, but this is now
deprecated because it mixes two types of information in
one file
• Instead, you should use directories to populate host and
group variables
Defining Host Variables Through Inventory
• A variable can be assigned directly to a host
[servers]
web1.example.com web_package=httpd
• Alternatively, variables can be set for host groups
[servers:vars]
web_package=httpd
Using Include Files
• To define host and host group variables, directories should be
created in the current project directory
• Use ~/myproject/host_vars/web1.example.com to include host
specific variables
• Use ~/myproject/group_vars/webservers to include host group
specific variables
• Notice that you don't have to define variables in these
directories in the playbook, they are picked up automatically
RHCE 8 – EX294
Day 1 Homework Lab

How to work with homework assignments
• Try to make the homework assignment before tomorrow's session
start
• Remember: you can only learn Ansible by doing it a lot!
• After completing your homework assignment, mail it to
mail@sandervanvugt.nl. I'll have a look at all, and we'll discuss one
solution in class tomorrow!
Day 1 Homework Lab
• Use the appropriate ad hoc command to install Python on a host
you want to manage
• Write a playbook that installs the httpd package on
ansible2.example.com
• Ensure that it is started and that the firewall is opened to allow
access to it
• Also create a file /var/www/html/index.html with some welcome
text
• Lastly, write a playbook that will undo all modifications
RHCE 8 – EX294
6. Day 1 Homework Lab

Discussion
RHCE 8 – EX294
7. Working with Variables and

Facts part 2
RHCE 8 – EX294
7.1 Using Vault

Dealing with Sensitive Data
• Some modules require sensitive data to be processed
• This may include webkeys, passwords, and more
• To process sensitive data in a secure way, Ansible Vault can be used
• Ansible Vault is used to encrypt and decrypt files
• To manage this process, the ansible-vault command is used
Creating an Encrypted File
• To create an encrypted file, use ansible-vault create playbook.yml
• This command will prompt for a new vault password, and opens
the file in vi for further editing
• As an alternative for entering passwords on the prompt, a vault
password file may be used, but you'll have to make sure this file is
protected in another way: ansible-vault create --vault-password-
file=vault-pass playbook.yml
• To view a vault encrypted file, use ansible-vault view
playbook.yml
• To edit, use ansible-vault edit playbook.yml
• Use ansible-vault encrypt playbook.yml to encrypt an existing file,
and use ansible-vault decrypt playbook.yml to decrypt it
• To change a password on an existing file, use ansible-vault rekey
Using Playbooks with Vault
• To run a playbook that accesses Vault encrypted files, you need to use the -
-vault-id @prompt option to be prompted for a password
• Alternatively, you can store the password as a single-line string in a
password file, and access that using the --vault-password-file=vault-file
option
Managing Vault Files
• When setting up projects with Vault encrypted files, it makes sense to use
separate files to store encrypted and non-encrypted variables
• To store host or host-group related variable files, you can use the following
structure:
|-group_vars
| |--dbservers
| |- vars
| |- vault
• This replaces the solution that was discussed earlier, where all variables are
stored in a file with the name of the host or host group
Poll Question
When using Ansible Vault, a password must be provided. Which of the
following is NOT a valid way to do so?
• Just run ansible-vault, it will prompt for a password
• Use the --vault-password-file option when running the ansible-vault create
command
• Write the password to the ansible_vault variable
• Store the password in the playbook
RHCE 8 – EX294
7.2 Using Facts

Understanding Ansible Facts
• Ansible Facts are variables that are automatically set
and discovered by Ansible on managed hosts
• Facts contain information about hosts that can be used
in conditionals
• For instance, before installing specific software you can
check that a managed host runs a specific kernel version
Managing Fact Gathering
• By default, all playbooks perform fact gathering before running
the actual plays
• You can run fact gathering in an ad hoc command using the
setup module
• To show facts, use the debug module to print the value of the
ansible_facts variable
• Notice that in facts, a hierarchical relation is shown where you
can use the dotted format to refer to a specific fact
Displaying Fact Names
• In Ansible 2.4 and before, Ansible facts were stored as individual
variables, such as ansible_hostname and ansible_interfaces.
• In Ansible 2.5 and later, all facts are stored in one variable with
the name ansible_facts, and referring to specific facts happens in
a different way: ansible_facts['hostname'] and
ansible_facts['interfaces']
• The old approach is referred to as "injecting facts as variables",
and this behavior can be managed through the
inject_facts_as_vars parameter
• Use inject_facts_as_vars=true in the [default] section of
ansible.cfg to specifically enable the old method
Turning off Fact Gathering
• Disabling fact gathering may seriously speed up playbooks
• Use gather_facts: no in the play header to disable
• Even if fact gathering is disabled, it can be enabled again by running the
setup module in a task
Using Custom Facts
• Custom facts allow administrators to dynamically generate variables which
are stored as facts
• Custom facts are stored in an ini or json file in the /etc/ansible/facts.d
directory on the managed host
• The name of these files must end in .fact
• Custom facts are stored in the ansible_facts.ansible_local variable
• Use ansible hostname –m setup –a "filter=ansible_local" to display local
facts
• Notice how fact filename and label are used in the fact
Custom Facts Example File
[localfacts]
package = vsftpd
service = vsftpd
state = started
RHCE 8 – EX294
8. Using Task Control

RHCE 8 – EX294
8.1 Using Loops and Items

Understanding Loops
• The loop keyword allows you to iterate through a simple list of items
• Before Ansible 2.5, the items keyword was used instead
- name: start some services
service:
name: "{{ item }}"
state: started
loop:
- vsftpd
- httpd
Using Variables to Define a Loop
• The list that loop is using can be defined by a variable:
vars:
my_services:
- httpd
- vsftpf
tasks:
- name: start some services
service:
name: "{{ item }}"
state: started
loop: "{{ my_services }}"
Using Hashes/Dictionaries in Loops
• Each item in a loop can be a hash/dictionary with multiple keys in each
hash/dictionary
- name: create users using a loop
hosts: all
tasks:
- name: create users
user:
name: "{{ item.name }}"
state: present
groups: "{{ item.groups }}"
loop:
- name: anna
groups: wheel
- name: linda
groups: users
Understand loops vs. items
• The loop keyword is the current keyword
• In previous versions of Ansible, the with_* keyword was used for the same
purpose
• This syntax will probably be deprecated in future versions of Ansible
• with_items: equivalent to the loop keyword
• with_file: the item contains a file, which contents is used to loop through
• with_sequence: generates a list of values based on a numeric sequence
Understanding register
• A register is used to store the output of a command and address it as a
variable
• You can next use the result of the command in a conditional or in a loop
RHCE 8 – EX294
8.2 Using Conditionals

Using Conditions
• when statements are used to run a task conditionally
• A condition can be used to run a task only if specific conditions
are true
• Playbook variables, registered variables, and facts can be used in
conditions and make sure that tasks only run if specific conditions
are true
• For instance, check if a task has run successfully, a certain amount
of memory is available, a file exist, etc.
Defining Simple Conditions
• The simplest example of a condition, is to check whether a
Boolean variable is true or false
• You can also check and see if a non-Boolean variable has a
value and use that value in the conditional
• Or use a conditional in which you compare the value of a fact
to the specific value of a variable
Poll Question
Which option should you use to loop through a list of items?
• with_items
• with_file
• with_sequence
• loop
Examples
• ansible_machine == "x86_64"
• ansible_distribution_major_version == "8"
• ansible_memfree_mb == 1024
• ansible_memfree_mb < 256
• ansible_memfree_mb > 256
• ansible_memfree_mb <= 256
• ansible_memfree_mb !=512
• my_variable is defined
• my_variable is not defined
• my_variable
• ansible_distribution in supported_distros
Testing Multiple Conditions
• when can be used to test multiple conditions as well
• Use and or or and group the conditions with parentheses
• when: ansible_distribution == "CentOS" or
ansible_distribution == "RedHat"
• when: ansible machine == "x86_64" and ansible_distribution
== "CentOS"
• The when keyword also supports a list and when using a list,
all of the conditions must be true
• And complex conditional statements can group conditions
using parentheses
Combining Loops and Conditionals
• Loops and conditionals can be combined
• For instance, you can iterate through a list of dictionaries and
apply the conditional statement only if a dictionary is found
that matches the condition
RHCE 8 – EX294
8.3 Using Handlers and Blocks

Understanding Handlers
• Handlers allow you to configure playbooks in a way that one
task will only run if another task has been running successfully
• In order to run the handler, a notify statement is used from the
main task to trigger the handler
• Handlers typically are used to restart services or reboot hosts
• Handlers are executed after running all tasks in a play
• Handlers will only run if a task has changed something, so if an
ok result instead of a changed result is reported, the handler
will not run
• If one of the tasks fails, the handler will not run, but this may be
overwritten using force_handlers: True
• One task may trigger more than one handler
Understanding Ansible Blocks
• A block is a logical group of tasks
• It can be used to control how tasks are executed
• One block can for instance be enabled using a single when
• Blocks can also be used in error condition handling
• Use block to define the main tasks to run
• Use rescue to define tasks that run if tasks defined in the block fail
• Use always to define tasks that will run, regardless the success or
failure of the block and rescue tasks
RHCE 8 – EX294
8.4 Dealing with Failure

Understanding Failure Handling
• Ansible looks at the exit status of a task to determine whether it has
failed
• When any task fails, Ansible aborts the rest of the play on that host
and continues with the next host
• Different solutions can be used to change that behavior
• Use ignore_errors in a task to ignore failures
• Use force_handlers to force a handler that has been triggered to
run, even if (another) task fails
Defining Failure States
• As Ansible only looks at the exit status of a failed task, it may think a task
was successful where that is not the case
• To be more specific, use failed_when to specify what to look for in
command output to recognize a failure
Handling Changed Status
• Managing the Changed status may be important, as handlers trigger
on the changed status
• The result of a command can be registered, and the registered
variable can be scanned for specific text to determine that a change
has occurred
• This allows Ansible to report a changed status, where it normally
would not, thus allowing handlers to be triggered
RHCE 8 – EX294
9. Deploying Files with

Templates
RHCE 8 – EX294
9.1 Using Modules to

Manipulate Files
Common File Modules
Different Modules are available for managing files
• lineinfile: ensures that a line is in a file, useful for changing a single
line in a file
• blockinfile: manipulates multi-line blocks of text in files
• copy: copies a file from a local or remote machine to a location on a
managed host
• fetch: used to fetch a file from a remote machine and store it on the
management node
• file: sets attributes to files, and can also create and remove files,
symbolic links and more
Managing SELinux Context
• file: sets attributes to files, including SELinux context, and can also
create and remove files, symbolic links and more
• sefcontext: manages SELinux file context in the SELinux Policy (but
not on files)
• Notice that file sets SELinux context directly on the file (like the
chcon command), and not in the policy
Poll Question
You want to change a few lines in a text file, using an Ansible module.
Which module is most appropriate?
• file
• lineinfile
• blockinfile
• copy
RHCE 8 – EX294
9.2 Using Jinja2 Templates

Understanding Jinja2 Templates
• lineinfile and blockinfile can be used to apply simple
modifications to files
• For more advanced modifications, use Jinja2 templates
• While using templates, the target files are automatically
customized using variables and facts
Understanding Jinja2 Templates
• In a Jinja2 template, you will find multiple elements
• data
• variables
• expressions
• control structures
• The variables in the template are replaced with their values
when the Jinja2 template is rendered to the target file on the
managed host
• If using variables, they can be specified using the vars section of
the playbook
• Alternatively, Ansible facts can be used as variables
Avoiding Confusion When Using Templates
• To prevent administrators from overwriting files that are managed by
Ansible, set the ansible_managed string
• First, in ansible.cfg set ansible_managed = Ansible managed
• On top of the Jinja2 template, set the {{ ansible_managed }} variable
RHCE 8 – EX294
9.3 Using Control Structures in

Jinja2
Using Control Structures in Templates
• In Jinja2 templates, control structures can be used to organize the template
in an optimal way
• The for statement can be used to iterate through a variable and use all
values in the variable
• The if statement can be used to have the template work with a variable if
another variable is defined
RHCE 8 – EX294
Day 2 Homework Lab

Lesson 7 Lab: Deploying Files with Templates
• To configure Anonymous FTP upload, you'll need to make sure that the
following is accomplished
• vsftpd.conf is modified to allow anonymous FTP access and uploads
• The directory /var/ftp/pub is configured with the appropriate permissions
• The directory /var/ftp/pub is configured with the appropriate SELinux context
label
• The SELinux boolean ftpd_anon_write is set to on
• Create a playbook that ensures that the vsftpd service is installed, enabled,
the firewall is opened, and the above requirements are met. Define
variables in the playbook to set vsftpd.conf parameters, and use these in a
template
• At the end of the playbook, verify connectivity, uploading the /etc/hosts
file from localhost
RHCE 8 – EX294

Explanation
RHCE 8 – EX294
11. Using Ansible Roles

RHCE 8 – EX294
11.1 Understanding Directory

Structure Best Practices
Organizing Ansible Contents
• When working with Ansible, it's recommended to use project
directories so that contents can be organized in a consistent way
• Each project directory may have its own ansible.cfg, inventory as
well as playbooks
• If the directory grows bigger, variable files and other include files
may be used
• And finally, roles can be use to standardize and easily re-use specific
parts of Ansible
• For now, consider a role a complete project dedicated to a specific
task that is going to be included in the main playbook
Directory Layout Best Practices
• Ansible Documentation describes best practices
(https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_
practices.html)
• Some highlights:
• On top in the directory, use site.yml as the master playbook
• From site.yml, call specific playbooks for specific types of host
(webservers.yml, dbservers.yml, etc.)
• Consider using different inventory files to differentiate between
production and staging phases
• Use groups_vars/ and host_vars/ to set host related variables
• Use roles to standardize common tasks
RHCE 8 – EX294
11.2 Using Ansible Roles

Understanding Roles Default Structure
• defaults contains default values of role variables. If variables are
set at the play level as well, these default values are overwritten
• files may contain static files that are needed from the role tasks
• handlers has a main.yml that defines handlers used in the role
• meta has a main.yml that may be used to include role
metadata, such as information about author, license,
dependencies and more
• tasks contains a main.yml that defines the role task definitions
• templates is used to store Jinja2 templates
• tests may contain an optional inventory file, as well as a
test.yml playbook that can be used to test the role
• vars may contain a main.yml with standard variables for the role
(which are not meant to be overwritten by playbook variables)
Understanding Role Variables
• Variables can be defined at different levels in a role
• vars/main.yml has the role default variables, which are used in
default role functioning. They are not intended to be overwritten
• defaults/main.yml can contain default variables. These have a low
precedence, and can be overwritten by variables with the same
name that are set in the playbook and which have higher precedence
• Playbook variables will always overwrite the variables as set in the
role. Site-specific variables such as secrets and vault encrypted data
should always be managed from the playbook, as role variables are
intended to be generic
• Role variables are defined in the playbook when calling the role and
they have the highest precedence and overwrite playbook variables
as well as inventory variables
Understanding Role Location
• Roles can be obtained in many ways
• You can write your own roles
• For Red Hat Enterprise Linux, the rhel-system-roles package is
available
• The community provides roles through the Ansible Galaxy website
• Roles can be stored at a default location, and from there can easily
be used from playbooks
• ./roles has highest precedence
• ˜/.ansible/roles is checked after that
• /etc/ansible/roles is checked next
• /usr/share/ansible/roles is checked last
Using Roles in a Playbook
• Roles are referred to from playbooks:
• When roles are used, they will run before any task that is defined
in the playbook
---
- name: role demo
hosts: all
roles:
- role1
- role2
Defining Role Variables
• When calling a role, role variables can be defined
---
- name: role variable demo
hosts: all
roles:
- role: role1
- role: role2
var1: cow
var2: goat
RHCE 8 – EX294
11.3 Using Galaxy

Using Ansible Galaxy
• Administrators can define their own roles, or standard roles can be
used from Ansible Galaxy
• Ansible Galaxy is a public website where community provided roles
are offered
• Before writing your own roles, check Galaxy, you may get the roles
from there
• An easy-to-use search interface is available at galaxy.ansible.com
Using the Galaxy CLI Utility
• ansible-galaxy search will search for roles
• If an argument is provided, ansible-galaxy will search for this
argument in the role description
• Use options --author, --platforms and --galaxy-tags to narrow down
the search results
• ansible-galaxy search 'install mariadb' --platforms el
• ansible-galaxy info provides information about roles
• ansible-galaxy info f500.mariadb55
• ansible-galaxy install downloads a role and installs it in
~/.ansible/roles
• After download, these roles can be used in playbooks, like any
other role
Managing Roles
• ansible-galaxy list shows installed roles
• ansible-galaxy remove can be used to clean up and remove roles
• ansible-galaxy init creates a directory structure that can be used to start
developing your own role
• It interacts with the Ansible Galaxy website API
• Use --offline to work offline
• Specify username and role name as arguments
• ansible-galaxy init --offline user.myrole
Using a Requirements File
• ansible-galaxy can be used to install a list of roles based on
definitions in a requirements file
• A requirements file is a yml file that defines a list of required
roles that are specified using the src keyword
• The src keyword can contain the name of a role from Ansible
Galaxy, or a URL to a custom location pointing to your own roles
• Create roles/requirements.txt in the projects directory to use it
• Always specify the optional version attribute, to avoid getting
surprises when a newer version of a role has become available.
- src: file:///opt/local/roles/myrole.tar
name: myrole
version: 1.0
• To install roles using a requirements file, use ansible-galaxy
install -r roles/requirements.yml
RHCE 8 – EX294
11.4 Creating Custom Roles

Creating Roles
• To create your own roles, use ansible-galaxy init myrole to
create the role directory structure
• Mind the location of the directory structure, you can put it in
the local project directory, or in a directory that is accessible
for all projects
• Populate the required role files as discussed before
Creating Roles - Best Practices
• Each role should have its own version control repository
• Don't put sensitive information in the role, but in the local
playbooks or Ansible Vault instead
• Use ansible-galaxy init to create the role structure
• Don't forget to edit the README.md and the meta/main.yml
to contain documentation about your role
• Roles should be dedicated to one task/function. Use multiple
roles to manage multiple tasks/functions
• Have a look at existing (Galaxy) roles before starting to write
your own
Defining Role Dependencies
• The meta/main.yml can be used to define role dependencies
• Dependencies listed here will be installed automatically when this
role is used
Using Conditional Roles
• Conditional roles call a role dynamically, using the include_role module
• This makes it so conditional roles are treated more as tasks
• Conditional Roles can be combined with conditional statements
• This makes it so a role will only run if the conditional statement is true
• Use include_role in a task statement to do so
---
- hosts: lamp
tasks:
- include_role:
name: lamp
when: "ansible_facts['os_family'] == 'RedHat'"
Poll Question
Ansible Roles van be stored in multiple locations. What is the default
location when installing roles from Ansible Galaxy?
• ./roles
• ˜/.ansible/roles
• /etc/ansible/roles
• /usr/share/ansible/roles
RHCE 8 – EX294
11.5 Managing Order of

Execution
Understanding Role Order of Execution
• Role tasks are always executed before playbook tasks
• Next, playbook tasks are executed
• And after playbook tasks, handlers are executed
• Use pre_tasks to define playbook tasks that are to be executed
before the tasks in a role
• If these tasks notify a handler, this handler is executed before as well
• The post_tasks keyword can be used to define playbook tasks that
are executed after playbook tasks and roles
RHCE 8 – EX294
12.1 Using RHEL System Roles

Understanding RHEL System Roles
• RHEL system roles are provided to configure standard RHEL operations
• RHEL system roles have been provided since RHEL 7.4, and can be used
to configure RHEL 6.10 and later
• Install the rhel-system-roles package to use them
• RHEL system roles are derived from the Ansible Linux System Roles
project, which is available through Ansible Galaxy
Current RHEL System Roles
• Currently, the following RHEL system roles are provided
• rhel-system-roles.kdump configures the kdump crash recovery service
• rhel-system-roles.network configures network interfaces
• rhel-system-roles.selinux manages all aspects of SELinux
• rhel-system-roles.timesync is used to set up Network Time Protocol or
Precision Time Protocol
• rhel-system-roles.postfix is used to configure a host as a Postfix MTA
• rhel-system-roles.firewall configures a firewall
• rhel-system-roles.tuned configures the tuned service
• Additional RHEL system roles are likely to be introduced
Installing RHEL System Roles
• Use yum install rhel-system-roles to install them
• The roles are installed to the /usr/share/ansible/roles directory, notice that
the upstream linux-system-roles name is provided as a symbolic link to
provide maximum compatibility
• Documentation of Ansible system roles is available in /usr/share/doc/rhel-
system-roles-<version>
• Look for example YAML files in the role directories
RHCE 8 – EX294
12.2 Using the SELinux System

Role
Using rhel-system-roles.selinux
The RHEL system role for SELinux can do several things:
• Set enforcing or permissive mode
• Set SELinux file contexts
• Run restorecon
• Set Booleans
• Set SELinux User Mappings
Rebooting After Making Changes
• In some cases, to apply SELinux changes (such as a switch between
enabled and disabled mode), a reboot is required
• The SELinux role doesn't reboot hosts itself because it should be up
to the administrator to do that
• The role will set the selinux_reboot_required variable to true, and
fail if a reboot is required
• This is used in a block / rescue structure, where the play is failing if
the variable is not set to true
• If the variable is set to true, the host is rebooted and the role is
started again
• See sample code in example-selinux-playbook in the roles
documentation
Setting SELinux Related Variables
• To Configure SELinux from the role, set at least the following variables:
• selinux_state
• selinux_booleans
• selinuc_fcontexts
• selinux_restore_dirs
• selinux_ports
• See the example playbook for examples
RHCE 8 – EX294
12.3 Using the Timesync

System Role
Why Does it Make Sense?
• rhel-system-roles.timesync can be used to manage time synchronization
• As the timesync service is different between RHEL 6 and RHEL 7/8, it makes
sense managing this functionality using a rhel-system-role
Using rhel-system-roles.timesync
• The role itself is configured to work with different variables, of which
timesync_ntp_servers is the most important one
• Items in this variable are made up of different attributes, of which
two are common
• hostname shows the hostname of the time server
• iburst specifies that fast iburst synchronization should be used
• The timezone variable is also important, and sets the current
timezone to be used
• A default playbook is available in /usr/share/doc/rhel-system-
roles/timesync
Poll Question
To set SELinux using the RHEL system role, different variables may be
used. Which of the following is NOT a common variable in the SELinux
role?
• selinux_state
• selinux_restorecon
• selinux_fcontexts
• selinux_ports
RHCE 8 – EX294
13. Using Ansible in Large

Environments
RHCE 8 – EX294
13.1 Using Multiple Inventory

Files
Understanding Inventory Options
• A static inventory file can be used as a list of managed hosts
• Dynamic inventory can automatically discover hosts, by talking to an
external host management system, such as FreeIPA, Active Directory, Red
Hat Satellite and more
• Also, multiple inventories can be used, for instance by putting multiple
inventory files in a directory and use that as the source of inventory
Managing Dynamic Inventory
• Dynamic inventory scripts are available for different environments
• Check https://github.com/ansible/ansible/tree/devel/contrib/inventory
• They are used like static inventory files, through ansible.cfg, or using the -i
option to the ansible[-playbook] command
• Instead of using community dynamic inventory scripts, you can also write
your own
Writing Dynamic Inventory Scripts
• The only requirement is that the script returns the inventory
information in JSON format
• To see the correct output format, use ansible-inventory --list on
any inventory
• Scripts can be written in any language, but Python is common
Using Multiple Inventory Files
• If the inventory specified is a directory, all inventory files in that
directory are considered
• This includes static as well as dynamic inventory
• Inventory files cannot be created with dependencies to other
inventory files
Poll Question
When addressing host names, some names are implicit and don't have to be
defined separately. Which of the following is NOT one of them?
• managed
• all
• localhost
• ungrouped
RHCE 8 – EX294
13.2 Using Includes

Understanding Inclusion
• If playbooks grow larger, it is common to use modularity by using
includes and imports
• Includes and imports can happen for playbooks as well as tasks
• An include is a dynamic process; Ansible processes the contents of
the included files at the moment that this import is reached
• An import is a static process; Ansible preprocesses the imported
file contents before the actual play is started
• Playbook imports must be defined at the beginning of the playbook,
using import_playbook
Including Tasks Files
• A task file is a flat list of tasks
• Use import_tasks to statically import a task file in the playbook, it will be
included at the location where it is imported
• Use include_tasks to dynamically include a task file
• Dynamically including tasks means that some features are not available
• ansible-playbook --list-tasks will not show the tasks
• ansible-playbook --start-at-task doesn't work
• You cannot trigger a handler in an imported task file from the main task file
• Best practice: store task files in a dedicated directory to make
management easier
When to Include Task Files
• When modularity is required, for instance to differentiate between groups
of tasks that need to be executed against specific host types
• When different groups of IT staff are responsible for different setup tasks
• If a task needs to be executed only in specific cases
Using Variables for External Plays and Tasks
• In the design, it is recommended to keep include files as generic as possible
• Define variables independently from the playbook
• in separate include files
• Using group_vars and host_vars
• Or using local facts
• This allows you to process different values on different groups of hosts, while still
using the same playbook
RHCE 8 – EX294
13.2 Configuring Parallelism

Understanding Processing Order
• Plays are executed in order on all hosts referred to, and normally
Ansible will start the next task if this task successfully completed on
all managed hosts
• Ansible can run on multiple managed hosts simultaneously, but by
default the maximum number of simultaneous hosts is limited to five
• Set forks = n in ansible.cfg to change the maximum number of
simultaneous hosts
• Alternatively, use -f nn to specify the max number of forks as
argument to the ansible[-playbook] command
• The default of 5 is very limited, so you can set this parameter much
higher, in particular if most of the work is done on the managed hosts
and not on the control node
Managing Rolling Updates
• The default behavior of running one task on all hosts, and next proceed to
the next task means that in cluster environments you may have all hosts
temporarily being unavailable
• Use the serial keyword in the playbook to run hosts through the entire play
in batches
RHCE 8 – EX294
Day 3 Homework Lab

Day 3 Lab: Using Ansible in Large Environments
• Analyze the project in the lesson13/lab directory. Optimize it for use in a
large environment
RHCE 8 – EX294

Discussion
RHCE 8 – EX294
15. Troubleshooting Ansible

RHCE 8 – EX294
15.1 Analyzing Errors

Understanding Ansible Logging
• By default Ansible is not configured to log its output anywhere
• Set log_path in ansible.cfg to write logs to a specific destination
• Create this file in the project directory, /var/log is not writable by the Ansible
user and will only work when running the playbook with sudo
• When using this, you should also use log rotation
Poll Question
Which of the following is the most efficient way to verify that the
become parameter is working as expected?
• Set the become parameter in a playbook
• Use an arbitrary ad-hoc command and add the --become option
• Use the ansible all -m ping --become command
• Use ansible all -m ping
RHCE 8 – EX294
15.2 Using Modules for

Troubleshooting and Testing
Using the debug Module
• Variables play an important role in playbooks
• The debug module is used to show values of variables in playbook
Using Check Mode
• Use ansible-playbook --check on a playbook to perform check mode; this
will show what would happen when running the playbook without actually
changing anything
• Modules in the playbook must support check mode
• Check mode doesn't always work well in conditionals
• Set check_mode: yes within a task to always run that specific task in check
mode
• This is useful for checking individual tasks
• When setting check_mode: no for a task, this task will never run in check mode
• Notice that check_mode: no is new since Ansible 2.6, and replaces the
always_run: yes option from earlier versions
Using Check Mode on Templates
• Add --diff to an Ansible playbook run to see differences that would be
made by template files on a managed hosts
• ansible-playbook --check --diff myplaybook.yml
RHCE 8 – EX294
16. Advanced Ansible Usage

Examples
RHCE 8 – EX294
16.1 Managing Software

Understanding Software Management Tasks
• To manage software on RHEL systems, different tasks need
to be managed
• Systems need to be subscribed
• Repositories and software channels need to be configured
• Software needs to be installed and removed
Understanding Software Management Modules - 1
• package: Distribution agnostic module to manage packages
• win_package: Manages packages on Windows
• apt: Manages packages on Ubuntu
• yum: Manages packages on RHEL
• yum_repository: Manages Yum repositories
Understanding Software Management Modules - 2
• package_facts: Returns information about packages as facts
• rpm_key: Adds or removes GPG keys from an RPM package database
• redhat_subscription: Uses the subscription_manager command to
manage subscriptions
• rhn_register: Managed Red Hat Network registration using rhnreg_ks
• rhn_channel: Manages RHN Channel subscription
• Other modules are available, see
https://docs.ansible.com/ansible/latest/modules/list_of_packaging_
modules.html for more information
RHCE 8 – EX294
16.2 Managing Users

Modules Related to User Management
• user: Manages Users and their common properties
• group: Manages Groups and their common properties
• pamd: Configures PAM
• authorized_key: Copies SSH public keys from Ansible
Control to the target user .ssh/authorized_keys
• lineinfile: Modifies configuration files based on regex
Understanding authorized_key
• The authorized_key module can be used to copy a user public key
to the ~/.ssh/authorized_keys file
• This is useful to enable SSH access from remote machines, such as
the Ansible control node
• Note that this will only copy the public key, and does NOT generate
any SSH keys
• To generate SSH keys for new users, use the user module and its
option generate_ssh_key
Managing Users
• Some tasks have well defined modules, some tasks don't
• When no specific module exists, it comes down to your own creativity
• When creating users, you'll at least want to use the users and groups
modules, whereas authorized_key is useful as well
Managing sudo
• There is no Ansible module for managing sudo
• Using templates and variables, it's not too difficult to set it up manually
though
• In the next demo, you'll see how to use a playbook, together with a Jinja2
template and variables to set up a sudo configuration
Poll Question
Which module should you use to copy an SSH public key to a managed
host?
• ssh
• copy
• put
• authorized_key
RHCE 8 – EX294
16.3 Managing Storage

Understanding Modules for Managing Storage
• parted: runs the parted utility
• lvg: create LVM volume group
• lvol: creates LVM logical volumes
• filesystem: managed filesystems
• mount: manages mounts
• vdo: manages VDO storage
RHCE 8 – EX294
16.4 Managing Networking

Using the Network System Role
• RHEL 8 includes a RHEL system role to manage networking
• Use ansible-galaxy list for an overview of all RHEL8 system roles
• See contents of the roles in /usr/share/ansible/roles
Setting Variables in the RHEL 8 System Roles
• Two variables are used to configure the network role:
• network_provider: typically set to nm
• network_connections: specifies details about the network connection
• Defaults for these variables are set in /usr/share/ansible/roles/rhel-system-
roles.network
Understanding Modules
• Different modules are available for managing network settings
• nmcli is used to manage many parameters for network devices or
connections
• hostname can be used to set the name of a managed host
• firewalld can be used to manage Firewalld rules

RH Ce Student

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RH Ce Student

Transféré par

Droits d'auteur :

Formats disponibles

RHCE

2.1 Installing Ansible

2.2 Seting up sudo and SSH

2.3 Setting up Inventory

2.4 Managing Ansible

3. Using Ad-hoc Commands

3.1 Using Ad-hoc Commands

3.2 Working with Modules

3.3 Using ansible-doc

4. Getting Started with

5. Working with Variables and

5.1 Understanding and Using

• Alternatively, variables can be defined in a variable file, which will be

5.2 Managing Variable

5.3 Managing Host Variables

• Alternatively, variables can be set for host groups

Day 1 Homework Lab

6. Day 1 Homework Lab

7. Working with Variables and

7.1 Using Vault

7.2 Using Facts

8. Using Task Control

8.1 Using Loops and Items

8.2 Using Conditionals

8.3 Using Handlers and Blocks

8.4 Dealing with Failure

9. Deploying Files with

9.1 Using Modules to

9.2 Using Jinja2 Templates

9.3 Using Control Structures in

Day 2 Homework Lab

10. Day 2 Homework Lab

11. Using Ansible Roles

11.1 Understanding Directory

11.2 Using Ansible Roles

11.3 Using Galaxy

11.4 Creating Custom Roles

11.5 Managing Order of

12.1 Using RHEL System Roles

12.2 Using the SELinux System

12.3 Using the Timesync

13. Using Ansible in Large

13.1 Using Multiple Inventory

13.2 Using Includes

13.2 Configuring Parallelism

Day 3 Homework Lab

14. Day 3 Homework Lab

15. Troubleshooting Ansible

15.1 Analyzing Errors

15.2 Using Modules for

16. Advanced Ansible Usage

16.1 Managing Software

16.2 Managing Users

16.3 Managing Storage

16.4 Managing Networking

Vous aimerez peut-être aussi