Automating Red Hat Satellite with Ansible

June 26, 2020 by Evgeni Golov

Red Hat Satellite is a great tool to automate deployment, provisioning, patching and configuration of your infrastructure, but how can you automate Satellite itself?

Using the Red Hat Ansible Automation Platform and the Satellite Ansible Content Collection, of course!

Since you’re already tuning in, you probably don’t need convincing that automation is great; it helps enable easier collaboration, better accountability and easier reproducibility. But have you already heard about Collections?

We’ll show you how you can use the Satellite Ansible Content Collection to manage your Satellite installations via Ansible

What is the Satellite Ansible Content Collection?

The Satellite Ansible Content Collection is, as you might have guessed already, a set of Ansible modules and plugins to interact with Red Hat Satellite.

These modules are an evolution from the foreman and katello modules previously available in Ansible itself, as those are deprecated since Ansible 2.8 and are scheduled for removal in 2.12. Due to the use of a Satellite-specific library, the old modules would not work properly in plain Foreman setups and often lacked features that were not present in Red Hat Satellite. At the same time, using the modules together with Satellite wasn’t easy either, as the used library only supported a specific Satellite release and you had to find the right version of Satellite for yourself.

Over the past year, the community sat together, cleaned up the modules, created tests and documentation, and finally ported the modules to a Satellite independent library.

Today, we cover many core Satellite workflows and examples. We would also love your feedback to extend to other workflows like OpenSCAP and Remote Execution.

Where can the Collection be downloaded?

You can download the redhat.satellite Collection from Automation Hub (requires Ansible Automation Platform subscription) immediately (along with the updated Satellite 6.7.z erratum), or wait for the forthcoming ansible-collection-redhat-satellite RPM from the Satellite 6.8 repositories later this year. When installing from Automation Hub, you’ll also have to make sure you have the latest apypie Python library now available from the Satellite repository.

The community can download and contribute to the corresponding unsupported upstream theforeman.foreman Collection from Ansible Galaxy as well.

Information on how to configure downloading via the ansible.cfg or requirements.yml files, please refer to the blog entitled, “Hands On With Ansible Collections.

How can the modules be used?

Usually you’ll find one module per Satellite entity (Organization, Location, Host Group, etc.) or action (Repository Sync, Content Upload, etc.). Each module takes a set of common parameters:

  • server_url: the URL of your Satellite instance (e.g. https://satellite.example.com)
  • username: the login of the user that will be used for API authentication (e.g. admin)
  • password: the password of said user (e.g. changeme)
  • validate_certs: whether or not to validate the TLS certificates the server presents

For example, if you’re about to create a new domain, the task in your Ansible playbook will look like this:

- name: create example.org domain
  redhat.satellite.domain:
    name: example.org
    state: present
    server_url: https://satellite.example.com
    username: admin
    password: changeme

That’s it! All modules follow the same basic calling convention and you’re set up using them in your environment. Now is a good time to look through the list of available modules and start writing playbooks for the most common workflows.

Examples

The previous example was quite short. Here are a few real world examples of how we use the modules today. For the sake of readability, the server_url, username and password parameters were omitted.

Enable and sync a repository from the CDN and add it to a Content View

One very common workflow is to sync content from the Red Hat CDN and then publish it to the clients. For that, the following steps need to happen:

  1. The repository set needs to be enabled, which will create all the necessary products in Satellite. This is a step that needs to happen once.
  2. The repository needs to be synced. This will usually happen regularly either by executing the workflow from Tower on a schedule or by creating a Sync Plan in Satellite. We show the scheduled variant here.
  3. A content view needs to exist and contain the repository in question, so that clients can consume it.
  4. The content view needs to be published to get the newly synced content.
- hosts: localhost
  vars:
    content_view: RHEL
    product: "Red Hat Enterprise Linux Server"
    repo: "Red Hat Enterprise Linux 7 Server (RPMs)"
    repo_variants:
      - releasever: "7Server"
        basearch: "x86_64"
    organization: ACME
  tasks:
    - name: "Enable {{ repo }} repository"
      redhat.satellite.repository_set:
        name: "{{ repo }}"
        product: "{{ product }}"
        repositories: "{{ repo_variants }}"
        organization: "{{ oragnization }}"
        state: enabled
    
    - name: "Sync {{ repo }} repository"
      redhat.satellite.sync:
        repository: "{{ repo }}"
        product: "{{ product }}"
        organization: "{{ organization }}"
    
    - name: "Create RHEL ContentView"
      redhat.satellite.content_view:
        name: "{{ content_view }}"
        repositories:
          - name: "{{ repo }}"
            product: "{{ product }}"
        organization: "{{ organization }}"
        state: present
    
    - name: "Publish RHEL content view"
      redhat.satellite.content_view_version:
        content_view: "{{ content_view }}"
        organization: "{{ organization }}"

Create Lifecycle Environment and Activation Key

Another common workflow is to organize system updates in Lifecycle Environments. This allows clients to vary on patching cadence and enables the use of a set of machines as a testing environment. To achieve that, we first create a Lifecycle Environment and then an Activation Key that “points” to that Lifecycle Environment. Now when a system is set up, utilizing this Activation Key in the registration step will allow the admin to assign the system directly into the correct environment.

- hosts: localhost
  vars:
    activation_key: rhel
    lifecycle_env: Test
    content_view: RHEL
    subscriptions:
      - name: "Red Hat Enterprise Linux"
    organization: ACME
  tasks:
    - name: "Create {{ lifecycle_env }} LCE"
      redhat.satellitelifecycle_environment:
        name: "{{ lifecycle_env }}"
        prior: "Library"
        organization: "{{ organization }}"
        state: present
    
    - name: "Create {{ activation_key }}-{{ lifecycle_env }} Activation Key"
      redhat.satellite.activation_key:
        name: "{{ activation_key }}-{{ lifecycle_env }}"
        lifecycle_environment: "{{ lifecycle_env }}"
        content_view: "{{ content_view }}"
        subscriptions: "{{ subscriptions }}"
        organization: "{{ organization }}"
        state: present

Takeaways/Going Forward

Now is the best time to try out the Collection - we’d love to hear about the workflows that you implement with it and especially the ones that you’re still missing so we can make the Collection even better!

If you want to learn more, check out the following resources:

Share:

Topics:
Ansible Automation Platform


 

Evgeni Golov

Evgeni Golov studied computer science at the Heinrich-Heine-Universität Düsseldorf and finished his master's in 2012. He went into consulting for various open source things for a while and is now working as a developer for The Foreman and Satellite. In his spare time he is working on open-source projects and enjoys photography and home-automation. https://www.die-welt.net https://chaos.social/@zhenech


rss-icon  RSS Feed

RH-ansible-automation-platform_trial-banner