Technical Articles
[Part VII] Setting Up Components for Ansible Automation Platform
This is Part 7 of a blog series on Deploying SAP S/4HANA Systems Using The Red Hat Portfolio. Read Part VI: Setting Up an Inventory in Ansible Automation Platform here.
Read the other chapters here:
[Part I – Overview] Deploying SAP S/4HANA Systems Using The Red Hat Portfolio
[Part II] Curating Content with Red Hat Satellite
[Part III] Setting up Provisioning via Red Hat Satellite
[Part IV] Leveraging Ansible Collections and Upstream Roles
[Part V] Building an Execution Environment for Ansible Automation Platform
[Part VI] Setting Up an Inventory in Ansible Automation Platform
[Part VIII] Provisioning a new SID with Ansible Automation Platform
—
Now that we have our inventory ready to go, there’s only a few other pieces to put together within Ansible Controller. First, we’ll tell Controller about our execution environment that we built earlier:
I’ve stored my execution environment on my private instance of Automation Hub, however any image registry that your instance of Ansible Controller can access will work here as well. I’ve also provided a set of credentials to use to log in to the image registry, however if your registry doesn’t require logging in then the credential field can be left blank.
Next, let’s set up a connection to our code by configuring a project:
This is a typical setup for a project in Ansible Controller. Something to note here: since we set up an execution environment, there’s no roles/requirements.yml or collections/requirements.yml file in the repository. While this may seem like a minor change, it significantly speeds up the project sync process, and we don’t need to maintain credentials within Controller to log in to private or public instances of Automation Hub.
After setting up our project, we can set up our credentials. First, let’s set up a custom credential type to store our peripheral credentials, such as our password for Red Hat Satellite. In the Input Configuration field, we’ll enter what we’d like this credential type to take as input:
--- fields: - id: satellite_password type: string label: satellite_password secret: true
And in the Injector configuration, we’ll enter how the credentials should be fed into the running job:
--- env: FOREMAN_PASSWORD: '{{ satellite_password }}'
For a more in-depth example of setting up a content credential type for interfacing with the Satellite API or using the redhat.satellite collection, take a look at this blog post.
Now we can create our system and peripheral credentials:
A quick note: I’ve defined more in my peripheral credentials than specified above, however not all of these pieces are required, I simply use them for when I demonstrate this workflow to customers.
Lastly, we can set up our job templates:
Here we can see our various job templates that comprise the typical SID installation workflow: provisioning systems, running the preconfigure roles,and installing our SAP components. Zooming in to one of the job templates:
Here we can see we’ve tied our project and execution environment to this job template, as well as enabled concurrent jobs so we could provision multiple SIDs at once if needed. What we haven’t specified here is an inventory or a limit: instead we’ve set those to be prompted for at runtime, making these job templates more dynamic. For example, we could run this job template against all of our SAP systems to ensure none have drifted, or we could enter in a specific group to target with our automation: a specific SID, all netweaver servers, non-production, and so on. This allows the consumers of our automation to make that decision at runtime, and we don’t need to maintain multiple copies of this job template.
As a final note, the various playbooks used in these job templates live in this repository on GitHub, if you’re interested in more of the details or the actual code. Everything displayed in this blog series exists as code within that repository: the Satellite configuration, the Controller configuration, the various playbooks, and so on.
Stay tuned for Part 8: Provisioning a new SID with Ansible Automation Platform.
Josh Swanson is currently a Solution Architect for Red Hat.
Ted Jones is currently a SAP Architect for the Red Hat SAP Tech Alliance team.
Vivien Wang is currently an Ecosystem Partner Manager for the Red Hat Partner Engineering Ecosystem.