RH294 Red Hat Enterprise Linux Automation with Ansible
ONLY FOR SELF STUDY, NO COMMERCIAL USAGE!!!
Lab Env
In this course, the main computer system used for hands-on learning activities is workstation. Four other machines are also used by students for these activities: servera, serverb, serverc, and serverd. All these five systems are in the lab.example.com DNS domain.
User/passwd : student/ student. AND root/ redhat.
Table 1. Classroom Machines
| Machine name | IP addresses | Role |
|---|---|---|
bastion.lab.example.com |
172.25.250.254 |
Gateway system to connect student private network to classroom server (must always be running) |
utility.lab.example.com |
172.25.250.8 |
System with utility services required for the classroom |
workstation.lab.example.com |
172.25.250.9 |
Graphical workstation used for system administration |
servera.lab.example.com |
172.25.250.10 |
Host managed with Ansible |
serverb.lab.example.com |
172.25.250.11 |
Host managed with Ansible |
serverc.lab.example.com |
172.25.250.12 |
Host managed with Ansible |
serverd.lab.example.com |
172.25.250.13 |
Host managed with Ansible |
The primary function of bastion is that it acts as a router between the network that connects the student machines and the classroom network.
Several systems in the classroom provide supporting services. Two servers, content.example.com and materials.example.com, are sources for software and lab materials used in hands-on activities. These are provided by the classroom.example.com virtual machine. Both classroom and bastion should always be running for proper use of the lab environment.
Chapter 1. Introducing Ansible
Ansible Concepts and Architecture
The Ansible architecture consists of two types of machines: control nodes and managed hosts. Ansible is installed and run from a control node, and this machine also has copies of your Ansible project files.
Managed hosts are listed in an inventory, which also organizes those systems into groups for easier collective management. You can define the inventory statically in a text file, or dynamically using scripts that obtain group and host information from external sources.
Instead of writing complex scripts, Ansible users create high-level plays to ensure that a host or group of hosts is in a particular state. A play performs a series of tasks on the hosts, in the order specified by the play. These plays are expressed in YAML format in a text file. A file that contains one or more plays is called a playbook.
Each task runs a module, a small piece of code (written in Python, PowerShell, or some other language), with specific arguments. Each module is essentially a tool in your toolkit. Ansible ships with hundreds of useful modules that can perform a wide variety of automation tasks. They can act on system files, install software, or make API calls.
When used in a task, a module generally ensures that some particular aspect of the machine is in a particular state. For example, a task using one module might ensure that a file exists and has particular permissions and content. A task using a different module might ensure that a particular file system is mounted. If the system is not in that state, the task should put it in that state, or do nothing. If a task fails, the default Ansible behavior is to abort the rest of the playbook for the hosts that had a failure and continue with the remaining hosts.
Tasks, plays, and playbooks are designed to be idempotent. This means that you can safely run a playbook on the same hosts multiple times. When your systems are in the correct state, the playbook makes no changes when you run it. Numerous modules are available that you can use to run arbitrary commands. However, you must use those modules with care to ensure that they run in an idempotent way.
Ansible also uses plug-ins. Plug-ins are code that you can add to Ansible to extend it and adapt it to new uses and platforms.
The Ansible architecture is agentless. Typically, when an administrator runs an Ansible Playbook, the control node connects to the managed host by using SSH (by default) or WinRM. This means that you do not need to have an Ansible-specific agent installed on managed hosts, and do not need to permit any additional communication between the control node and managed hosts.
Ansible Source
- Community Ansible : Ansible Core / community Ansible(包含开源社区Ansible modules and roles)
- Ansible Core in Red Hat Enterprise Linux (RPM package,
ansible-core, included with Red Hat Enterprise Linux 9 in the AppStream repository.) - Red Hat Ansible Automation Platform (subscription, Ansible Core toolset plus additional certified and supported content, tools, components, and cloud services)
Red Hat Ansible Automation Platform 2
-
Ansible Core(Red Hat Ansible Automation Platform 2.2 provides Ansible Core 2.13 in the
ansible-coreRPM package and in itsee-minimal-rhel8andee-supported-rhel8automation execution environments.) -
Ansible Content Collections
-
Automation Content Navigator (
ansible-navigatorrunning your playbooks in a container ) -
Automation Execution Environments(a container image that contains Ansible Core, Ansible Content Collections, and any Python libraries, executables, or other dependencies needed to run your playbook.)
-
Automation Controller (Red Hat Ansible Tower, web UI and a REST API that can be used to configure, run, and evaluate your automation jobs)
-
Automation Hub (
console.redhat.comprovides access to Red Hat Certified Ansible Content Collections)
Prepare Control Node
-
If use your control node as the execution environment :
[user@controlnode ~]$ sudo dnf install ansible-core -
If container: install ansible-navigator on control node
-
Install automation content navigator on your control nodes.
[user@controlnode ~]$ sudo dnf install ansible-navigator
-
Verify that automation content navigator is installed on the system.
[user@controlnode ~]$ ansible-navigator --version
ansible-navigator 2.1.0 -
Log in to the container registry.
[user@controlnode ~]$ podman login registry.redhat.io
Username: your-registry-username
Password: your-registry-password
Login Succeeded! -
Download the container image for the execution environment that you plan to use with automation content navigator. (
ansible-navigator imagesmight also automatically download the default execution environment when you run the command.)[user@controlnode ~]$ podman pull \
registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest
-
Display the list of locally available container images to verify that the image was downloaded.
[user@controlnode ~]$ ansible-navigator images
Image Tag Execution environment Created Size
0│ee-supported-rhel8 latest True 5 weeks ago 1.32 GB
-
-
python>=3.8installed -
valid Red Hat Ansible Automation Platform subscription
Managed hosts
-
Linux/Unix hosts
- python installed(check Support Matrix for python version)
- If SELinux, the
python3-libselinuxpackage need to be installed firstly - Regular user need
sudoto get superuser access
-
Windows hosts
- Use
ansible.windowsAnsible Content Collection - managed hosts require PowerShell 3.0 or later
- managed hosts need to have Windows PowerShell remoting configured.
- requires .NET Framework 4.0 or later to be installed
- More information on the Ansible website at https://docs.ansible.com/ansible/latest/user_guide/windows.html, or in the Red Hat training course Microsoft Windows Automation with Red Hat Ansible Automation Platform (DO417).
- Use
-
Network Devices
- Ansible automation supported routers and switches as well, This includes support for Cisco IOS, IOS XR, and NX-OS; Juniper Junos; Arista EOS; and VyOS-based networking devices, among others.
- most network devices cannot run Python, Ansible runs network modules on the control node, not on the managed hosts. Special connection methods are also used to communicate with network devices, typically using either CLI over SSH, XML over SSH, or API over HTTP(S).
- more information see Ansible for Network Automationon the Ansible community website, or the Red Hat training course Network Automation with Red Hat Ansible Automation Platform (DO457).
TO BE CONTINUED...