Distinguish Between Ansible Engineering and Operations

Problem

Without a clear distinction between disciplines, Ansible engineering and Ansible operations often merge, leading to poorly structured code, reduced reusability, and maintenance challenges. This is especially problematic in organizations new to Ansible, where the advanced skills required for engineering may not be recognized, causing rushed or subpar development.

Context

Ansible supports multiple workflows: developing reusable Ansible content like Ansible roles and Ansible collections, versus using that content in inventory projects for configuration management. Ansible engineering focuses on creating powerful, flexible content that can be configured adaptively. In contrast, Ansible operations emphasizes applying this content to achieve desired state configuration in various environments. Blurring these lines can result in ad-hoc, non-idempotent automation that lacks modularity. This guideline is crucial for teams adopting Ansible without prior experience, as engineering demands deeper knowledge of best practices, testing, and Ansible’s ecosystem.

Solution

To maintain clarity and quality, separate Ansible engineering from Ansible operations as follows:

1. Define Roles Clearly

   Assign Ansible engineers to focus on developing, testing, and publishing Ansible collections and Ansible roles. They should prioritize reusability, flexibility, and adherence to best practices, using tools like Ansible Galaxy for sharing. This includes the creation, design, and engineering of the inventory projects, its structure, and mechanisms— for example, for managing environment differences.

2. Focus Operations on Application

   Have Ansible operators manage inventory projects, including playbooks, inventory file, group variables, and dependencies. They utilize existing content for tasks like orchestration, configuration, and automation workflows, possibly integrating with Ansible Automation Platform for scaling. Operators utilize and manage the inventory project—for example, to define environments, add hosts to Ansible groups, and manage environment groups. They use it to manage infrastructure effectively.

3. Encourage Overlap with Training

   Allow skill overlap but provide focused training—emphasize software development for engineers and infrastructure management for operators—to build expertise without blending responsibilities.

Benefits

• Improves code quality by allowing engineers to create modular, flexible content while operators focus on reliable application.
• Enhances scalability and maintainability, reducing errors in production environments.
• Supports organizational adoption of Ansible by allocating focus to skill development, especially in teams with limited experience.
• Promotes collaboration through clear boundaries, enabling efficient use of shared resources like collections.

Alternatives (Optional)

Some teams combine roles into a single “Ansible user” profile, but this often leads to inefficient code and burnout. While valid for small setups, it’s less effective at scale compared to distinct disciplines, which align better with DevOps principles like separation of concerns.

Examples and Implementation

In an organization adopting Ansible:

• Engineering Example: Using an Ansible development environment, an Ansible engineer develops an Ansible Windows collection  c2platform.wincore with a flexible and powerful Microsoft AD role  c2platform.wincore.ad that can be used to manage MS AD controller and join nodes to the AD domain. The engineer publishes this collection to Ansible Galaxy. See  c2platform.wincore. The engineer has also created an inventory project with a group-based environments approach, which allows the engineer to follow a true IaC approach. This manages differences between environments efficiently and codifies the policies for the systems, infrastructure, and applications for all environments.

  For example, the engineer will codify that each node will join the correct Microsoft AD controller for the environment by introducing two project variables gs_ad_controller and gs_add_controller_ip in the Ansible group all.

   group_vars/all/ad.yml
  

  11
  12gs_ad_controller: "{{ groups['ad'] | intersect(groups[gs_env]) | first }}"
  13gs_ad_controller_ip: "{{ hostvars[gs_ad_controller].ansible_host }}"
  

  These variables are then used to configure FME nodes to use the correct AD controller and join the correct AD domain, that matches the environment (development test):

   group_vars/fme/ad.yml
  

  ---
  ad_resources_types: ['ad_dns_client', 'ad_membership']
  ad_dns_client:
    - name: Use AD DNS sever
      adapter_names: '*'
      # log_path: C:\dns_log.txt
      dns_servers:
        - "{{ gs_ad_controller_ip }}"
  ad_membership:
    - name: Join domain
      hostname: "{{ inventory_hostname }}"
      dns_domain_name: "{{ gs_ad_domain_name }}"
      domain_admin_user: "{{ gs_ad_domain_name_admin }}@{{ gs_ad_domain_name }}"
      domain_admin_password: "{{ gs_ad_admin_password }}"
      state: domain
      reboot: true
  

• Operations Example: An Ansible operator uses the inventory project to set up the test environment by creating a new Ansible group test and putting 5 hosts in the group:

   hosts.ini
  

  32[test]
  33gst-rproxy1         ansible_host=1.1.5.209
  34gst-awx1            ansible_host=1.1.5.164
  35gst-db1             ansible_host=1.1.5.210
  36gst-fme-core        ansible_host=1.1.8.118
  37gst-ad              ansible_host=1.1.8.119
  

  The operator will then also place each host in the correct Ansible group, assigning it that way the correct role. For example, the host gst-ad will be added to the Microsoft AD controller group ad and the host gst-rproxy1 will be added to the Apache reverse proxy group reverse_proxy:

   hosts.ini
  

  72[ad]
  73gsd-ad
  74gst-ad
  75
  76[reverse_proxy]
  77gsd-rproxy1
  78gst-rproxy1
  

  Now the inventory project has been engineered by the Ansible engineer in such a way that the gst-fme-core node will use the correct AD controller gst-ad (and not the development node gsd-ad). The operator does not have to be aware of this.

This separation ensures engineering produces robust content, while operations applies it effectively.

Additional Information

For further reference, explore the following information:

• Ansible Inventory Project: A structured collection of files used for managing hosts and configurations. It typically includes inventory files, playbooks, host configurations, group variables, and Ansible vault files.