These summary reports document progress milestones and highlight accomplished features.
This week we added
ansible-lint to the Ansible SSA execution environment. This makes it easier to use the EE in Visual Studio Code to get syntax highlighting and tab completion with the collections inside our EE.
Also we finally managed to upgrade to Red Hat Ansible Automation Platform 2.2 - which automatically retires our support for 2.1.
It’s been a long time since this section has been updated. It doesn’t mean we were not working - on the contrary, a lot has happened.
fully switched to Red Hat Ansible Automation Platform 2
reorganized the CI pipeline completely, including building Execution Environments
bring back releases for each component for stable, reliable and predictable deployments
new roles e.g. to register a system on RHSM or Red Hat Insights
so much more…
We are planning to updated this document more regularly in the future. Promise.
We constantly try to make it easier to consume the content provided in this project. We started to experiment with Red Hat CodeReady Workspaces and can now provide instructions to automatically setup your workstation.
To be ready for the upcoming “Ansible Execution Environments” and Best Practices, we created an ansible_ssa.common collection which combines all relevant roles in this project in one collection. It was also a good exercise to get familiar with
git submodule and to build a CI/CD pipeline which builds a new collection automatically.
We were able to continue our work around private Automation Hub. Since last week, the playbooks can be used to (optionally) deploy a second cloud instance as an private Automation Hub. Since some variables were renamed, we bumped the version to 2.0.0 to indicate that we break backwards compatibility.
We’ve not updated this page for a while - but that doesn’t mean we were lazy! Welcome to 2021 and check out all the news!
Last week we set up a new server which acts as our DynDNS Server and wrote some Playbooks to set it up and manage it. Now we can offer a subdomain like <username>.ansible-labs.de which is fully controlled by the respective owner.
e.g. if you install automation you will have tower.<mysuffix>.ansible-labs.de automatically managed and deleted by the Ansible “instance” role.
Details and instructions on how to request access can be found in the chapter on extra variables
After this was done, we continued work of a unified “tower-install.yml” which calls tower-instance, tower-setup and tower-content in the proper order, reducing provisioning time and lowering the entry barrier. Note this will only work if you have the DynDNS magic enabled.
Last but not least we started working on upgrading to Tower 3.8 and adding (optionally) an private Automation Hub next to your tower - so stay tuned for next week, when it’s hopefully working.
A lot of effort was put into creating a CI/CD pipeline to run automated tests when merging code into the “master” branch. The pipeline will create a test VM, install and configure Ansible Tower, setup the content and finally delete it again. Although the initial work has been done, there is a lot more to do and we’re still far away from having full test coverage.
The IDM use case has also seen some additional development. It should now also work on Azure where it failed before.
The use cases to add Red Hat Identity Manager has seen some additional improvements, but is still missing documentation. The Playbooks to deploy and manage Tomcat have also seen some minor fixes, which haven’t been documented either. Clearly, we’re bit behind on documentation…
We introduced a new “Newbie” label to make it easier to get started and contribute to this projects. Issues which have a low risk of breaking stuff and which are considered to be easy to implement, are labeled with it.
The new tomcat use case saw some additional improvements on working with different users, roles and organizations. After some more polishing and QE, we still need to better document how to use the new preconfigured content in a demo scenario.
We also added Red Hat Identity Manager to the Tower Job Templates. This will deploy and configure an RH IDM Server for you. We will later build a use case around this to demonstrate RH IDM as our single sign on platform for all demo systems, including Ansible Tower itself and Red Hat Satellite.
To be able to demonstrate RBAC we created three organizations:
Each organization has two users developer and operator, which have also been created in the default organization. What’s missing is documentation about the complete list of users, groups, roles and permissions.
We also added optional support for Red Hat Ansible Automation Hub to automatically download and install certified content. The first role utilizing this content is role-tomcat-ops. It’s using the ansible.posix collection to make sure SElinux is in enforcing mode. Although this is a tiny example, more will follow soon, for example we are planning to switch to the Red Hat supported Collection to manage Red Hat Satellite.
This was a quiet week which saw some improvements on Deploying and Retiring Windows Server instances on GCP. To better track the different activities, a Add Windows Support milestone has been created.
Notable fixes and improvements:
packages from EPEL break the Satellite installer, however EPEL is enabled by default on some cloud providers (satellite-setup #6)
more boolean fixes (use boolean filter instead of true/false)
the Satellite Use Case is done for Google Cloud and Azure
If you find a bug you want to propose an idea for a new feature, please use the GitLab Issue Tracker