2023-02-06, 16:45–17:35, B.1.017
Ansible has thousands of modules, plugins, roles and collections that can be leveraged to automate (almost) anything anywhere.
Could we use Ansible to build Ansible ? Why not ?
What could go wrong ? ¯\(ツ)/¯
The ansible community package includes a curated set of Ansible collections in addition to ansible-core.
At a high level, building this python package means:
- Installing dependencies from distribution packages and PyPI
- Cloning different git repositories
- Downloading the latest release for each included Ansible collection
- Updating versions, changelogs & documentation in different files
- Building a specified version of the actual package
- Testing that the package works and contains what we expect it to
And then, probably other things like:
- Pushing updated files to git repositories and opening pull requests
- Publishing the package to PyPI (once it's been tested)
- Sending an email to a couple of mailing lists
- Sending messages to Matrix and IRC channels to let people know about it
We'll look at how an Ansible playbook with a role lets us reproducibly automate, test and document every step of the build process.
Then, we'll find out how another recursive acronym makes it easier to understand and troubleshoot when something inevitably fails.
In this presentation with live demos, you can expect to learn about:
- Different use cases for automation with Ansible
- What's inside the
ansiblecommunity package, how it works and how it is built - How ARA Records Ansible playbooks to provide granular metrics and reporting
- Opportunities to participate and contribute in the Ansible open source community
David is an open source enthusiast and contributor to projects like OpenStack, Ansible, Fedora and CentOS.
iWeb, Ubisoft and RedHat alumni doing bare metal and clouds, Dev/Ops, SRE, CI/CD and everything in between.
He likes simplicity and makes things work.