Infrastructură de generație următoare: Platforme Self-Service cu arhitectură bazată pe evenimente

Denis Rendler
Information Security Officer @ Accesa

Documentarea corectă a infrastructurii este esențială pentru menținerea unui mediu robust de dezvoltare. Există, însă, o provocare comună: documentația tinde să devieze de la realitate, în special în cazul infrastructurilor dinamice unde modificările sunt frecvente. În cadrul acestui articol, propun un workflow (flux de lucru) pentru a crea un sistem cu configurații automate de infrastructură, folosind Ansible și Netbox, în cadrul căruia documentația devine o parte activă a procesului de automatizare. Vom construi un proces care configurează automat noi medii virtuale pe baza documentației din Netbox, asigurându-ne că documentația și infrastructura în sine rămân sincronizate. Observațiile curente se bazează pe premisele enunțate de mine anterior, legate de automatizarea documentației cu Terraform și Netbox unde puteți consulta pașii pe care să îi includeți direct din documentație în pipeline-urile Terraform.

Legând documentația direct la procesul de automatizare, încerc să ofer un răspuns câtorva provocări operaționale cheie: reducerea muncii de configurare manuală, îmbunătățirea timpilor de deployment și menținerea conformității prin procese ce pot fi verificate și reproduse.

Event-Driven Ansible (Ansible bazat pe evenimente)

Event-Driven Ansible (EDA) transformă automatizarea tradițională Ansible prin introducerea de răspunsuri bazate pe evenimente. În loc să se bazeze pe rulări programate sau declanșări manuale, EDA monitorizează activ mediul vostru de lucru și răspunde la evenimente aproape în timp real.

Utilitatea EDA derivă din implementarea simplă și capabilitățile de integrare. Folosește sintaxa familiară YAML pe care utilizatorii Ansible o știu deja, ceea ce face ușoară definirea surselor de evenimente, condițiile, dar și răspunsurile lor automate.

Platforma este destul de flexibilă când ne raportăm la sursele de evenimente. O puteți conecta la mesaje Kafka, webhooks, alerte de monitorizare sau scripturi customizate - adică la ceea ce se potrivește mediului vostru de dezvoltare. Când are loc un eveniment, EDA îl detectează și generează automat componentele potrivite pentru playbook.

Această automatizare gestionează totul de la mentenanța de bază a sistemului la fluxuri de lucru complexe care gestionează răspunsul la incidente. De exemplu, când se creează o nouă mașină virtuală sau când apare o alertă, EDA poate executa imediat componentele playbook necesare, fără intervenție manuală.

Impactul asupra echipei de operațiuni este semnificativ - echipa petrecând timp mai puțin pe sarcini de rutină și răspunzând mai rapid incidentelor.

Precondiții

Pentru acest exemplu, voi folosi o instanță Netbox pentru a stoca datele din mediul virtual prin intermediul unui câmp customizat, configurat pentru utilizatorul logat și având numele login_user. Documentația noii mașini virtuale este împinsă către instanța Netbox folosind Netbox API direct din workflowul Terraform menționat anterior.

Deployment EDA

În centrul unui Event-Driven Ansible se află ansible-rulebook care orchestrează workflowurile EDA. Pentru această implementare, am creat o mașină virtuală mică unde rulează componentele EDA și care este configurată specific pentru a gestiona evenimentele webhook.

Puteți consulta pașii de instalare manuală aici: https://ansible.readthedocs.io/projects/rulebook/en/stable/installation.html. Mai mult, am creat o colecție Ansible care instalează și configurează toate componentele necesare pe care le puteți găsi aici: https://github.com/rendler-denis/ansible-rendler-collection/tree/main/rendler/eda

În deploymentul vostru EDA, rulați comenzile următoare pentru a crea o structură de proiect care vă va ajuta să gestionați lucrurile mai ușor și mai fiabil:

mkdir -p /opt/eda
cd /opt/eda
mkdir rulebooks inventory devops

Configurarea integrării Netbox

Pentru sursa de date de tip inventar al EDA, folosesc instanța Netbox unde am documentat deja toate mediile mele virtuale.

Primul pas necesită configurarea unui webhook în Netbox care să se declanșeze oricând se adaugă o nouă mașină virtuală la un inventar. Acest webhook va notifica sistemul nostru EDA care inițiază un workflow automatizat.

Accesați instanța voastră Netbox și creați un nou webhook sub Operations > Webhooks. Completați câmpurile din formular precum în captura de ecran de mai jos, ajustând valorile, astfel încât să se potrivească mediului vostru de lucru:

Apoi, configurați Netbox sub Operations > Event Rules, pentru a folosi acest webhook când se adaugă o nouă mașină virtuală. Configurați câmpurile precum în captura de ecran următoare, dar inserând setările voastre proprii pentru cîmpurile name și webhook.

După configurarea acestor setări, Netbox va trimite un eveniment din toate mașinile virtuale către EDA web endpoint de fiecare dată când o nouă "mașină virtuală" a fost adăugată la colecția sa.

Momentul la care se desfășoară operațiunile este și el esențial, un aspect care mi-a dat ceva de furcă. Deși EDA primește configurarea mașinii virtuale atunci când aceasta este creată inițial în Netbox, EDA nu va primi și adresa IP a mașinii virtuale. Acest lucru se întâmplă, deoarece Netbox trimite evenimentul webhook imediat după crearea mașinii virtuale, dar asignarea unui IP primar se întâmplă ca pas separat în workflowul Netbox'.

Utilizarea Netbox ca sursă unică de adevăr

În loc să ne bazăm pe datele de tip eveniment pe care le primește workflowul EDA, o soluție mai bună este să folosim Netbox ca sursă pentru inventar și să aducem datele direct printr-un plugin Ansible de tip inventar. Folosind această abordare, workflowul EDA va avea mereu informația cea mai recentă din mediul virtual. Un avantaj adițional este faptul că același inventar poate fi folosit pentru a rula alte workflowuri Ansible fără a fi nevoie sincronizarea datelor între sisteme diferite.

Pentru a reuși această sarcină de lucru, pe mașina EDA, rulați următoarele comenzi:

cd /opt/eda/

cat > inventory/hosts.yml <<EOF
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.example.com    
token: 32029....                            
validate_certs: true
config_context: true
ansible_host_dns_name: true
group_by:
  - sites
group_names_raw: true
interfaces: true
site_data: true
query_filters:
  - role: "virtual-machine"                 
flatten_config_context: true
device_query_filters:
  - has_primary_ip: 'true'
compose:
  ansible_host: "network_interfaces[0].ip_addresses[0].address"
  ansible_user: "custom_fields.login_user"
EOF

După ce ați rulat comenzile de mai sus, deschideți editorul vostru favorit și editați cele trei linii potrivit mediului în care lucrați. Componenta api_endpoint ar trebui să referențieze instanța voastră Netbox, iar token-ul ar trebui înlocuit cu token-ul vostru API Netbox, pe care îl puteți crea sub Admin > API Tokens. Tot aici, înlocuiți rolul cu componenta tag pe care ați folosit-o pentru a identifica mașinile virtuale create de voi.

Acest fișier de configurare hosts.yml va instrui toate componentele EDA să folosească instanța Netbox ca inventar, să grupeze datele pe site-uri și să filtreze doar acele mașini virtuale care au un IP primar și rolul "virtual-machine" (în cazul meu).

Următorul pas este crearea unui rulebook folosit pentru a răspunde evenimentului Netbox. În acest scop, folosiți următoarele comenzi:

cd /opt/eda/

cat > rulebooks/netbox_vm.yml <<EOF
- name: Netbox VM creation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5500
        endpoint: /netbox-vm

  rules:
    - name: Configure VM
      condition: event.payload.event == "created" and event.payload.model == "virtualmachine"
      action:
        run_playbook:
          delay: 10
          retries: 3              
          delay: 10               
          name: devops/playbooks/new_vm.yml    
          extra_vars:
            target: "{{ event.payload.data.name }}"   
EOF

Acest rulebook configurează un web endpoint pe port-ul 5500 unde ansible-rulebook va aștepta evenimentele. Când primește un eveniment, se uită la regulile sale, iar, când condiția este evaluată ca fiind adevărată, va executa acțiunea care, în acest caz este aceea de a executa componenta playbook new_vm.yml.

În spate, ansible-rulebook folosește ansible-runner pentru a rula o comandă ansible-playbook cu componenta playbook pe care am configurat-o. Acest lucru oferă workflowului toate beneficiile utilizării 'ansible-playbook' împreună cu o automatizare cu dichis.

Apoi, adăugați un proiect Ansible pe mașina EDA în folderul /opt/eda/devops. Dacă nu aveți un proiect Ansible sau dacă doriți să testați lucrurile pur și simplu, puteți folosi următorul repository cu scop de demo: https://github.com/ops-cafe/eda-note-ansible-demo-project

Ultimul pas este să inițializați workflowul EDA, folosind comanda:

cd /opt/eda

ansible-rulebook -r rulebooks/netbox_vm.yml 
-i inventory/hosts.yml

Dacă totul se configurează corect, nu veți vedea niciun rezultat până când este generat un eveniment, printr-un request POST către endpoint.

Pentru un test rapid, folosiți comanda:

curl -X POST -d '{"event": "created", 
"model": "virtualmachine", 
"data": {"name": "test"}}' https://ops.cafe:5500

Pe mașina EDA, ar trebui să vedeți un mesaj similar cu următorul în fișierul /var/log/messages:

Configurarea EDA ca system service (opțional)

Realizarea unei infrastructuri self-service cu Netbox și Ansible

Una din caracteristicile puternice ale Netbox este funcționalitatea Config context care permite adăugarea de metadate customizate pe care le putem folosi ulterior în cadrul Ansible playbooks.

Pentru acest exemplu, am adăugat un obiect JSON în câmpul contextual Config al obiectului VM, în Netbox, cu următorul conținut:

{
  "ansible_roles": ["baseline"]
}

Când rulează pluginul de tip inventar Ansible, acesta aduce automat datele și le face disponibile în playbook prin intermediul variabilei hostvars[inventory_hostname].ansible_roles.

Componenta playbook rulată de acest workflow EDA demo folosește apoi această informație pentru a rula rolurile Ansible specificate în câmpul ansible_roles, după cum urmează:

---
- name: Configure new VM
  hosts: '{{ target }}'
  tasks:
    - name: Basline the new VM
      ansible.builtint.include_role:
        name: '{{ item }}'
      loop: '{{ hostvars[inventory_hostname]
            .ansible_roles }}'

Putem extinde acest workflow pentru a include configurații complexe, precum folosirea rolurilor și a colecțiilor Ansible pentru a seta aplicații de monitorizare, logare sau deployment - creându-se, în esență un catalog software bazat exclusiv pe datele Netbox.

Această abordare aduce avantaje semnificative: minimizează intervenția umană, accelerează timpii de deployment și menține gradul de conformitate printr-un proces ce poate fi auditat și reprodus. Centralizând datele de configurare ale mediului virtual în Netbox, este posibilă crearea unei singure surse de adevăr pentru workflowurile Ansible.

Recapitulare

În acest articol, am arătat cum putem integra automatizarea Ansible cu Netbox pentru gestionarea configurării infrastructurii. Această abordare leagă automatizarea configurării direct de documentația infrastructurii, oferind mai mult beneficii practice:

• Set-up pentru medii virtuale automatizate, bazate pe documentația Netbox;

• Sincronizarea în timp real între documentație și starea actuală a infrastructurii;

• Configurare manuală redusă;

• Procese de deployment ce pot fi reproduse și verificate la nivel de conformitate.

Folosind Event-Driven Ansible pentru a oferi suport pentru actualizările Netbox, putem genera actualizări automate de configurație când documentația se schimbă. De exemplu, când un nou mediu virtual este documentat în Netbox, Ansible provizionează automat infrastructura corespondentă, cu parametri specifici.