In today’s fast paced environment, system administrators don’t have time to manually make configuration changes across servers in their environment. Instead, they need tools that can help automate configuration management. Ansible is a powerful automation tool, and in Satellite 6.4 Red Hat introduced the ability to use Ansible for basic host configuration management.
There are two main ways that Ansible can be used within Satellite. The first is using the Red Hat Enterprise Linux (RHEL) System Roles within Satellite, which help automate configuration of several common RHEL subsystems. Using RHEL System Roles in Satellite does not require an Ansible subscription.
The second way to use Ansible within Satellite is by using custom and 3rd party Ansible roles from within Satellite, which is what this post will be covering. This requires that you have a valid Ansible subscription. For more information on Ansible support in Satellite, please see the Scope of Support for Ansible Components included with Red Hat Satellite 6.
In this post, we will go through an example of setting up Satellite to run a custom Ansible role to manage the message of the day file (/etc/motd
) on several Satellite hosts.
Setting Up Remote Execution
The first thing to check when getting started with Ansible is what version of Satellite you have in your environment. Ansible functionality for configuration management was introduced in Satellite version 6.4. If you are on a prior version of Satellite, first upgrade to at least Satellite 6.4, or Satellite 6.5 if possible (which is currently the latest release, and is the recommended version).
Satellite uses the existing remote execution functionality to run Ansible roles on remote hosts, therefore, you must have remote execution working in the environment.
To test if remote execution is working, login to the Satellite web interface, go to the Hosts menu, and select All Hosts. Next, select all of the hosts you would like to use Ansible with, go to the Select Action drop down menu, and select Schedule Remote Job. We can leave the Job category set to Ansible Commands and the Job template set to Run Command - Ansible Default. For the command, we will specify hostname as a simple test command to run, as shown:
![Setting up remote execution Setting up remote execution](/rhdc/managed-files/styles/wysiwyg_full_width/private/image1_15_0.png.webp?itok=2PFGUaHe)
If the results for the remote job are successful on all of your hosts, then remote execution is working in your environment. If some or all of your hosts failed, you need to setup remote execution. There could be a number of issues causing a failure, but the most frequent is the SSH keys not being distributed to your hosts. See the documentation for information on how to distribute the SSH keys. Other issues that can cause remote execution failures are hostname resolution issues, remote servers inaccessible or down, firewalls blocking SSH traffic, etc.
Creating the Message of the Day (MOTD) Ansible Role
Once we have remote execution working, the next step is to create a new Ansible role that will configure the /etc/motd file.
A directory structure needs to be created on the Satellite server for the new role (and also on any Capsule servers with clients that will use the role), which we can create with the following commands:
# mkdir -p /etc/ansible/roles/motd/tasks # mkdir -p /etc/ansible/roles/motd/templates
Next, we will create the /etc/ansible/roles/motd/tasks/main.yaml
with the following contents:
![/etc/ansible/roles/motd/tasks/main.yaml /etc/ansible/roles/motd/tasks/main.yaml](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig2.png.webp?itok=VQuctdwQ)
This specifies that the /etc/motd
file should be created from the motd.j2
Jinja2 template, and should be set up with the specified mode, owner, and group.
Finally, we will create the Jinja2 template at /etc/ansible/roles/motd/templates/motd.j2
which defines what the /etc/motd
file will look like with the following contents:
![Jinja2 Template Jinja2 Template](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig3.png.webp?itok=25HlhubI)
In the Jinja2 template, we referred to a variable named test_var
, which we will later define in Satellite.
Importing the MOTD Ansible Role
Now that we have created our Ansible MOTD role, we need to import it into Satellite. To do this, first login to the Satellite web interface, then go to the Configure menu, and under the Ansible header, select Roles. From here, click on the blue From Satellite FQDN button, then check the box for the motd role, and click the Update button:
![Importing the MOTD Ansible Role Importing the MOTD Ansible Role](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig4.png.webp?itok=Awm7foh5)
In this demo environment, there are no Capsule servers. If you are using Capsule servers in your Satellite environment, refer to the documentation regarding importing and managing Ansible roles on Capsule servers.
Configuring Hosts for the Ansible Role
We now have the motd Ansible role created and imported into Satellite. At this point, we could edit an individual host and assign it to the Ansible role, or we can use a Satellite Host Group and assign the Ansible role and the Satellite hosts to this Host Group.
In this example, we will use a Host Group, since it is usually more efficient than managing Ansible roles at the individual host level.
We will create a new Host Group by going to the Configure menu and selecting Host Groups. Then, we will click the blue Create Host Group button in the upper right side of the page. In this example, we will give the Host Group a name of Test, as shown in this screenshot:
![Creating host group in Ansible Creating host group in Ansible](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig5.png.webp?itok=TRyNGH1c)
Then, we will click on the Ansible Roles tab, and add the motd role by selecting it under Available roles, which moves it to Selected Items:
![Ansible Roles tab Ansible Roles tab](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig6.png.webp?itok=kpPlg3SF)
In our motd.j2
Jinja2 template, we referred to a test_var
variable, which is going to be passed from Satellite. From Satellite, this variable can be defined at the global level, the Host Group level, or at the individual host level. In this example, we will define it at the Host Group level by clicking on the Parameters tab and clicking the + Add Parameter button. For the variable name, we will specify test_var
, and for the value, “Hello from Satellite!”, as shown in the next screenshot:
![Host group parameters Host group parameters](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig7.png.webp?itok=XnZADaIo)
Then, we’ll click the blue Submit button at the bottom of the screen to create the Host Group.
Next, we will add some hosts to the Host Group by going to the Hosts menu, and selecting All Hosts. We’ll click the checkbox for the hosts that we would like to run the motd Ansible role on, click Select Action, and select Change Group, as shown:
![Add hosts to host group Add hosts to host group](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig8.png.webp?itok=4vBOhy_x)
On the next screen, we will specify the Test Host Group, and click the blue Submit button:
![Test host group Test host group](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig9.png.webp?itok=HIwN2qHm)
Running the Ansible Role
At this point, we have created a new Ansible role, imported it into Satellite, defined a Host Group with the Ansible role, and added our hosts to the Host Group. The next step is to actually run the Ansible role on the hosts.
To run the Ansible role on all the hosts in the Host Group, we can go back to the Configure menu, and select Host Groups. We can then press the down arrow under Actions for the Test Host Group, and select Play Roles:
![Running the Ansible Role Running the Ansible Role](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig10.png.webp?itok=AaUtPHpf)
The Ansible roles in the Host Group will be run on each of the hosts within the Host Group. In this example, we only have the motd role. The results of the operation are shown and if you would like more details, you can click on one of the host names, as shown:
![Results of running Ansible Playbooks Results of running Ansible Playbooks](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig11.png.webp?itok=0G5p6j9x)
If you click on a host name, you will see additional details about the playbook run:
![Additional details about the playbook run Additional details about the playbook run](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig12.png.webp?itok=tlCy-XqI)
And if we check on one of the servers, we can validate that the /etc/motd file was updated:
![Validating /etc/motd was updated Validating /etc/motd was updated](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig13.png.webp?itok=tlXf290o)
Scheduling Automatic Runs of Ansible Roles
We can optionally configure Satellite to periodically run Ansible roles in an automated manner. This helps ensure our desired configuration stays applied to the hosts. For example, let’s consider the motd Ansible role we created and the /etc/motd
file that it is managing. If someone went on the hosts and changed the /etc/motd file, if we did not re-run our Ansible role, the/etc/motd
file would not match what the motd Ansible role specified. However, if we configure Satellite to periodically run the motd Ansible role, when run, it would detect if the /etc/motd
file did not match what was specified in the motd Ansible role, and update the file to what the motd role specified.
By default, Satellite expects that hosts have Ansible roles run every 30 minutes, or the host status (under All Hosts) will report that Configuration is Out of sync, as shown:
![Display of configuration out of sync Display of configuration out of sync](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig14.png.webp?itok=qUXDy2Ah)
This behavior is configurable under the Administer menu by selecting Settings, then going to the Ansible tab. From there, the Ansible out of sync disabled, and Ansible report timeout settings can be adjusted to change this behavior:
![Configuring Ansible report timeout settings Configuring Ansible report timeout settings](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig15.png.webp?itok=-GCcWfGR)
In our example, we will configure the Ansible roles to be run on our hosts in the Test Host Group every 20 minutes. To do this, we will go to the Monitor menu, and select Jobs. Then, we’ll click the blue Run Job button in the upper right. For the new job, we will specify the following:
Job Category: Ansible Playbook
Job Template: Ansible Roles - Ansible Default
Search Query: hostgroup_fullname = "Test"
Schedule: Set up recurring execution.
Repeats: cronline
Cron line: */20 * * * *
Ends: Never
We've included a screenshot of this:
![Defining a new job for Ansible Defining a new job for Ansible](/rhdc/managed-files/styles/wysiwyg_full_width/private/2019-07-17-ansible-fig16.png.webp?itok=gXcCpA0k)
We will then press Submit to create the recurring job. At this point, our motd Ansible role will run every 20 minutes on our hosts within the Test Host Group.
Ansible Tower
Satellite provides basic Ansible functionality, however, a number of customers have a need for more advanced Ansible functionality, such as orchestration, role based access control, etc.
In this situation, Ansible Tower is the recommended tool to use, and it is possible to integrate Satellite and Ansible Tower together. For example, Ansible Tower can use Satellite as a dynamic inventory source. In addition, it is possible to use an Ansible Tower provisioning callback to configure hosts provisioned by Satellite. For more information, see the documentation.
Summary and Closing
In this post, we covered an overview of how to get started with Ansible in Satellite by going through the process of creating a new Ansible motd role, and setting up Satellite so the role is run every 20 minutes on the specified hosts.
Sull'autore
Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management. He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit