Onderscheid tussen Ansible engineering en operations

Probleem

Zonder een duidelijk onderscheid tussen disciplines versmelten Ansible engineering en Ansible operations vaak, wat leidt tot slecht gestructureerde code, verminderde herbruikbaarheid en onderhoudsproblemen. Dit is vooral problematisch in organisaties die nieuw zijn met Ansible, waar de geavanceerde vaardigheden die nodig zijn voor engineering mogelijk niet worden herkend, wat leidt tot gehaaste of ondermaatse ontwikkeling.

Context

Ansible ondersteunt meerdere workflows: ontwikkelen van herbruikbare Ansible-content zoals Ansible-rol en Ansible-collecties, versus het gebruiken van die content in Ansible-inventarisproject voor configuratiebeheer. Ansible engineering richt zich op het creëren van krachtige, flexibele content die adaptief kan worden geconfigureerd. Daarentegen benadrukt Ansible operations het toepassen van deze content om desired state configuration te bereiken in verschillende omgevingen. Het vervagen van deze grenzen kan resulteren in ad-hoc, niet-idempotente automatisering die modulariteit mist. Deze richtlijn is cruciaal voor teams die Ansible adopteren zonder eerdere ervaring, omdat engineering diepere kennis vereist van beste praktijken, testen en het Ansible-ecosysteem.

Oplossing

Om duidelijkheid en kwaliteit te behouden, scheid Ansible engineering van Ansible operations als volgt:

1. Definieer Rollen Duidelijk

   Wijs Ansible engineers toe om zich te richten op het ontwikkelen, testen en publiceren van Ansible-collecties en Ansible-rol. Ze moeten prioriteit geven aan herbruikbaarheid, flexibiliteit en naleving van beste praktijken, met behulp van tools zoals Ansible Galaxy voor delen. Dit omvat het creëren, ontwerpen en engineeren van de Ansible-inventarisproject, de structuur en mechanismen— bijvoorbeeld voor het beheren van omgevingsverschillen.

2. Richt Operations op Toepassing

   Laat Ansible operators Ansible-inventarisproject beheren, inclusief playbook, inventarisbestand, groepsvariabelen en afhankelijkheden. Ze gebruiken bestaande content voor taken zoals orkestratie, configuratie en automatiseringsworkflows, mogelijk integrerend met Ansible Automation Platform voor schaling. Operators gebruiken en beheren het Ansible-inventarisproject—bijvoorbeeld om omgevingen te definiëren, hosts toe te voegen aan Ansible-groep en omgevingsgroepen te beheren. Ze gebruiken het om infrastructuur effectief te beheren.

3. Moedig Overlap Aan met Training

   Sta vaardigheidsoverlap toe, maar bied gerichte training—benadruk softwareontwikkeling voor engineers en infrastructuurbeheer voor operators—om expertise op te bouwen zonder verantwoordelijkheden te vermengen.

Voordelen

• Verbetert codekwaliteit door engineers in staat te stellen modulaire, flexibele content te creëren terwijl operators zich richten op betrouwbare toepassing.
• Verbetert schaalbaarheid en onderhoudbaarheid, vermindert fouten in productieomgevingen.
• Ondersteunt organisatorische adoptie van Ansible door focus toe te wijzen aan vaardigheidsontwikkeling, vooral in teams met beperkte ervaring.
• Bevordert samenwerking door duidelijke grenzen, wat efficiënt gebruik van gedeelde resources zoals collecties mogelijk maakt.

Alternatieven

Sommige teams combineren rollen in een enkel “Ansible-gebruiker”-profiel, maar dit leidt vaak tot inefficiënte code en burnout. Hoewel geldig voor kleine opstellingen, is het minder effectief op schaal vergeleken met afzonderlijke disciplines, die beter aansluiten bij DevOps-principes zoals scheiding van concerns.

Voorbeelden en Implementatie

Engineering-voorbeeld

Met behulp van een Ansible-ontwikkelomgeving ontwikkelt een Ansible engineer een Ansible Windows-collectie  c2platform.wincore met een flexibele en krachtige Microsoft AD-rol  c2platform.wincore.ad die kan worden gebruikt om MS AD-controller te beheren en nodes toe te voegen aan het AD-domein. De engineer publiceert deze collectie naar Ansible Galaxy. Zie  c2platform.wincore. De engineer heeft ook een Ansible-inventarisproject  c2platform/rws/ansible-gis gecreëerd met een aanpak op basis van groepgebaseerde omgevingen, die de engineer in staat stelt een echte IaC-aanpak te volgen. Dit beheert verschillen tussen omgevingen efficiënt en codeert de beleidsregels voor de systemen, infrastructuur en applicaties voor alle omgevingen.

De engineer zal bijvoorbeeld coderen dat elk node zich aansluit bij de juiste Microsoft AD-controller voor de omgeving door twee projectvariabele gs_ad_controller en gs_add_controller_ip in te voeren in de Ansible-groep 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 }}"

Deze variabelen worden vervolgens gebruikt om FME-nodes te configureren om de juiste AD-controller te gebruiken en zich aan te sluiten bij het juiste AD-domein, dat past bij de omgeving (ontwikkeltest):

 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-voorbeeld

Een Ansible operator gebruikt het Ansible-inventarisproject om de testomgeving in te stellen door een nieuwe Ansible-groep test te creëren en 5 hosts in de groep te plaatsen:

 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

De operator zal vervolgens elke host in de juiste Ansible-groep plaatsen, en op die manier de juiste rol toewijzen. Bijvoorbeeld, de host gst-ad wordt toegevoegd aan de Microsoft AD-controller groep ad en de host gst-rproxy1 wordt toegevoegd aan de Apache reverse proxy groep reverse_proxy:

 hosts.ini

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

Nu het Ansible-inventarisproject op een dergelijke manier is ontworpen door de Ansible engineer dat de gst-fme-core node de juiste AD-controller gst-ad zal gebruiken (en niet de ontwikkelnode gsd-ad). De operator hoeft zich hier niet van bewust te zijn.

Deze scheiding zorgt ervoor dat engineering robuuste content produceert, terwijl operations het effectief toepast.

Aanvullende Informatie

Voor verdere referentie, verken de volgende informatie:

• Ansible-inventarisproject: Een gestructureerde verzameling bestanden die worden gebruikt voor het beheren van hosts en configuraties. Het omvat doorgaans inventarisbestanden, playbooks, hostconfiguraties, groepsvariabelen en Ansible Vault-bestanden.