Ansible is currently very popular as an orchestration and configuration management tool. This stems from the fact that it is very easy to get started and also that Ansible supports a wide range of devices. Besides Linux with SSH, Windows and various network components are also supported.
Anexia, an Austrian cloud provider, has set itself the goal of managing its infrastructure with Ansible, among other things. This presentation will introduce the associated infrastructure and lessons learned in developing the system.
A typical Ansible project consists of a playbook, an inventory, and some roles. For all these documents traceability is of great importance, therefore these documents are stored in a version management system. For Anexia, this is Gitlab. Gitlab also provides the environment for automated testing (CI). molecule is usually used for the tests Using molecule, containers or virtual machines are created in the CI environment, which can then be used as target systems for the roles or playbooks under test. In addition, molecule provides mechanisms to verify the result of the execution.
Running Ansible playbooks against the production environment is handled by AWX. AWX provides a web-based user interface and API for managing and running Ansible projects. Ansible requires an inventory that contains the systems to be managed. In small projects, this is often maintained in a text file. This is not practical for frequently changing or larger environments. Anexia has therefore decided to source inventory from the Anexia Engine. Anexia Engine is the cloud management platform from Anexia. In addition to modules for compute, storage and IPAM, it also offers a CMDB module. An inventory can be created dynamically via the associated API. Additionally, it has the advantage that the inventory can be enriched with meta information, such as location or customer number.
When developing roles, Anexia uses a components/profiles/pattern structure. Generic components roles are developed (or used by Galaxy) for each application. A profile is then developed with the correct parameters or additional auxiliary roles. In other words, a role that fulfills a specific application purpose. In a pattern, it becomes a finished product. For example, a LAMP setup could be implemented as a pattern and consist of the profiles/roles Apache, MySQL and PHP.
The environment described here allows the management of several hundred systems and simultaneously enables their further development and maintenance in a software-like development model.