English
Development and Managed Hosting
ANEXIA
NOV
17
2020
Hosting & IT

Automation at Anexia with Ansible

Written on November 17, 2020 by Stefan Jakobs

Automation of the IT environment has been a hot topic for many years now. It is the prerequisite to solve complex IT problems. Due to its global locations and diverse customers, Anexia has special requirements for the automation of its IT landscape. A single tool may never fulfill all these requirements, and therefore, it rather is an interaction of multiple systems.

One of the basic tools for Anexia is Ansible. Together with the Anexia Engine, our customer portal and central data interface, it covers most of the requirements. In this blog post we take you on a journey from the decision to use Ansible, our challenges and up to the integration into our existing infrastructure.

 

Why Ansible as automation framework?

Ansible is – besides Puppet, Chef or SaltStack – one of the best-known automation frameworks for existing IT systems. While Puppet and SaltStack are declarative systems, Ansible and Chef are imperative tools.

A declarative system describes the desired state explicitly, while imperative systems describe the nominal condition implicitly. This results from individual steps that must be taken to get from the actual state to the desired state.

Declarative vs. Imperative Systems

 
Imperative systems have advantages when it comes to the chronology of cross-system tasks. In such cases a new state on a system can only be taken if another system has reached a certain state. As intermediate states are described explicitly, they can be easily used for synchronization of different systems.

Apart from the advantage of imperative states, there have been other decisive factors for choosing Ansible at Anexia:

  • Agentless. No agent has to run on the target system to communicate with the controller.
  • Different target platforms such as Linux, Windows, Junos, FortiOS, VMware
  • Clarity. Playbooks and roles are structured by YAML and are therefore clear and easily to learn.

    •  

    Challenges by using Ansible

    The often-mentioned easy entry with Ansible and the clarity of the playbook also have a flip side: There’s more than one way to solve a problem. While Puppet offers a strict framework to develop a manifest with its DSL (Domain Specific Language), users of Ansible have many options to develop a playbook. Any developer who has looked for a role via Galaxy may agree with the following statement:

    “It does what it should do. But it does not fit perfectly.”

    To ensure constant quality and reusability of playbooks and roles, a lot of additional effort has to be done in advance. This includes:

  • Definition of style and naming guides
  • Development of templates for playbooks/roles and their documentation
  • Development of a CI testing process

    •  
    The automated testing process is particularly invaluable for continuous quality assurance. On the one hand they support the maintenance of roles and playbooks over the complete life cycle. On the other hand, they can be used as a problem management tool to reproduce incidents.

    Anexia uses molecule together with Docker and Vagrant to enable automated tests for the Gitlab CI pipelines. We will cover this topic in more detail in an upcoming blog post.

     

    Integration of Ansible and the Anexia Engine

    A major challenge with Ansible is the development of inventories – a list of hosts – that must be managed. Agent-based systems solve this problem by using, well, agents. But that’s not possible with Ansible.

    Anexia uses the Engine – to be specific, the CMDB module – to solve this problem. The CMDB (Configuration Management DataBase) module catalogs all resources and manages the relationships between them. By using the CMDB it is possible, for example, to know that a VM is running on hypervisor X, located at location Y.

    When a system, VM, hypervisor, or switch is activated at Anexia, the Engine records it. With an inventory script it is possible to retrieve this data before starting a run. An updated list of all systems is available at all time.

    Ansible and Anexia Engine

    As a first step, Anexia made its internal systems accessible by using the Engine with a separate inventory. There a basic configuration (users, packages etc.) is defined. A similar project is underway for the hypervisor infrastructure. The goal is to additionally reduce the deployment time to define the basic configuration.

     

    Plans with Ansible at Anexia

    In the future, the integration of Engine and Ansible will be further expanded. This will enable Anexia to integrate more services into the Engine and offer customers more self-service.

    In this blog we will keep you updated on the progress of automation at Anexia. In the meantime inform yourself about our Anexia Engine.