Seeding Ansible Automation Platform Content At Installation Time

In a previous blog, I announced the tech preview of containerized Red Hat Ansible Automation Platform. With that we introduced a new feature to enable you to pre-seed configuration and content at installation time. This blog will take you through how that works.

At Red Hat, we are very lucky to have some super talented people. Some of these great folks have worked tirelessly on producing Ansible Content Collections for managing configuration within the platform. Using this as the foundation, we have wrapped enablement around that to provide a fully automated way of doing this, in a seamless fashion.

The Benefits

Many people today already use a configuration-as-code (CaC) approach to managing the platform and laying down standards for their users. If that’s your case, then this simply extends and simplifies this capability.

If this is a new concept to you, then these examples may be of interest:

• Standardize your user’s out of the box (OOTB) experience, in one go, at installation time.
  • Are there platform artifacts that you always need to apply to each and every installation? Define those as code and simply point the installation at that code and it will pre-configure the platform

• The ability to automate your Ansible Automation Platform configuration and manage as code.

• Ansible content developers provide automation solutions. Why not also extend that so you can automate the necessary wraparounds needed to enable your users to run automation jobs in a controlled and audited manner. 
• A content developer provides the playbooks, collections, roles etc for specific automation tasks. Using our post-install feature, you can apply the appropriate projects, inventory, credentials, execution environments and any other platform artifacts needed for automation execution.

• Provide tailored, pre-configured Ansible Automation Platform environments for specific users/teams/use cases on a case-by-case need.

• Does a particular segment of your business require a tailored environment specific to their needs? Perhaps they use a particular public cloud or look after a Windows Server estate, requiring specialized automation services for those sectors..
• Provide the correct Ansible Automation Platform configuration and content for those teams at installation time so they are up and running with all the applicable content for them OOTB.

Using Postinstall

postinstall gives us this seeding capability. It’s a task which is part of a role and in the installer collection.

Right now, you set installer inventory variables to enable this functionality:

# To use the postinstall feature you need to set these variables
controller_postinstall=true
controller_license_file=
controller_postinstall_repo_url=
controller_postinstall_dir=

By default, postinstall is disabled so we have to set controller_postinstall=true

The content seeding is done via a collection which uses the API to access automation controller. To use that, we need a valid subscription applied, hence the use of the controller_license_file. This is a manifest file generated on the RHN portal as documented here available as a .zip file and requires local filesystem access. This means you won’t need to accept or input a subscription on first logging into the platform.

controller_postinstall_repo_url sets the source for the configuration-as-code files. This is essentially a Git-based repository which contains the necessary .yml files we’ll load in.

controller_postinstall_dir is the local filesystem location where we’ll Git clone the repository content into. 

For the configuration-as-code files, there are plenty of examples out in the wild, such as this Job Template one from the Red Hat Ansible Community of Practice. For this blog, we’ll walk through a few example config files to set up a few items  in automation controller.

Looking at a simple repo of content I put together, within the controller directory, you’ll find some .yml files:

You’ll no doubt recognise these filenames as automation controller artifacts. Each configuration file will load the configuration for that artifact in order to provide something a little more fleshed out.

Let’s look at one of them now, projects.yml:

Each configuration file uses the same syntax and format. As per official guidelines, a line starting with ‘---’ declares it’s a YAML file. Likewise ‘...’ defines the end of the YAML file.

As we add Projects, we use the controller_projects role. Then supply the right variables for the desired state we require. In this case, we’re loading the Git repo with our desired settings..

We can do more than just load new configurations, we can also modify existing ones. Let’s look at the job_templates.yml:

In this example, we have two job templates: Demo Job Template and Demo Job Template2. The first you’ll recognise as the Demo Job Template that comes preloaded with an Ansible Automation Platform default installation. In this case, we are reconfiguring the instance groups it is using.

The second Job Template is new but uses the default hello_world.yml playbook in the Demo Project but with different configuration items for the instance group and inventory to be used.

At the heart of the infra.controller_configuration collection being used for this is a central ‘dispatch’ role. This takes care of loading all the content in the right order. This means all you need to do is land the configuration content into the repo which takes care of the sequencing and its order. This is important because some content relies on other content being loaded first. For instance, before a Job Template can be loaded, it’ll need the project, credentials, inventory, and execution environment to be set.

Now you’re ready to run the normal installer. Your configuration content will be loaded as part of the install and will be available for your automation needs upon logging into the platform.

Summary

This blog provides a quick overview and demonstration of our new tech preview released containerized Ansible Automation Platform’s post-install seeding capability. 

Currently, this is just for installation time but we’re working on ways to make this more flexible and provide a standardized way to run this at any time you choose.

You can get started by downloading containerized Ansible Automation Platform from the normal Red Hat Portal Downloads section, and you'll find the current documentation here.