5. Execució#

El playbook havia estat funcionant perfectament durant mesos: deu commutadors d’accés al laboratori, dos minuts de principi a fi, resultats nets cada vegada. Quan l’equip va decidir desplegar-lo a l’inventari complet de 800 commutadors, ningú esperava problemes. Els primers 600 dispositius es van actualitzar sense incidents. Llavors la feina es va alentir. Després es va aturar. El servidor RADIUS, que de sobte rebia 150 sol·licituds d’autenticació SSH simultànies, va començar a rebutjar connexions. Ansible es va quedar penjat en 150 dispositius a mig executar. Un enginyer va matar la feina.

El que va venir a continuació era el problema més difícil: ningú sabia quins 600 dispositius s’havien actualitzat i quins 150 no. No s’havia registrat cap estat d’execució. Van tornar a executar el playbook i van esperar que la idempotència els salvés; ho va fer, aquella vegada. Però l’incident va revelar quelcom important: la capa d’execució havia estat dissenyada per al laboratori, no per a la xarxa. La velocitat, el paral·lelisme, els límits d’error i el seguiment d’estat no s’havien considerat. L’automatització funcionava; l’arquitectura d’execució no.

La majoria de persones pensen en l’automatització de xarxes com: “agafar les mateixes dades i, sense connectar-se com a humà al CLI, fer quelcom a la xarxa.” Apostaré que la majoria de les persones que comencen amb l’automatització de xarxes comencen per aquí. I sí, això és el que fa el bloc d’Execució. Però com heu vist al llarg d’aquest llibre, l’automatització de xarxes és més gran que aquest primer pas, i l’Execució és només un component dins d’una arquitectura.

El bloc d’Execució interactua directament amb la xarxa per a les operacions més perilloses (p. ex., canvis de configuració o reinicis). Així que no us salteu aquest capítol; és crucial fer-ho bé.

En aquest capítol, cobrirem els objectius i els pilars que proporciona aquest bloc, i les capacitats internes que necessita per assolir-los.

5.1. Fonaments#

5.1.1. Context#

L’Execució defineix com executar les accions. El què prové del bloc d’Intenció, i el quan prové de l’Orquestració.

En els primers projectes d’automatització de xarxes, un script que fa rebotar una interfície per a un dispositiu i un nom d’interfície donats pot ser la primera victòria. Aquest camí pot créixer fins a un sistema molt més sofisticat.

5.1.2. Objectius#

Què ha de fer realment un sistema d’execució? Cinc coses importen:

1. Posar les dades correctes al lloc adequat. Abans d’executar qualsevol cosa, necessiteu saber què executar (la intenció), on executar-ho (quins dispositius) i com accedir-hi (credencials, detalls de connexió). Això significa extreure l’inventari i obtenir l’estat desitjat de la Font de Veritat (més informació al Capítol 4), i de vegades consultar les dades d’observabilitat per entendre les condicions actuals. Sense aquesta integració, el vostre motor d’execució simplement executa ordres a cegues. Per al vostre benestar mental, eviteu-ho.

2. Iniciar quan calgui, ja sigui ara o més tard. De vegades necessiteu una execució immediata: un enginyer fa clic a “desplegar” i espera que passi de seguida. Altres vegades, l’execució hauria d’esperar, desplegar durant la finestra de manteniment, esperar que un dispositiu es connecti o reaccionar a un esdeveniment de l’observabilitat. El sistema ha de donar suport als activadors síncrons i asíncrons.

3. Rastrejar l’estat al llarg del temps. Les operacions a tota la xarxa no són instantànies. Podeu desplegar en centenars de dispositius durant hores. Quins dispositius han tingut èxit? Quins han fallat? Quins estan pendents? La gestió d’estat també permet la idempotència (executar la mateixa tasca dues vegades, obtenir el mateix resultat), el rollback (desfer el que acabeu de fer) i la represa (continuar on ho vau deixar després d’un error). Sense el seguiment d’estat, cada execució és una aposta d’un sol tret.

4. Executar de manera fiable a escala. Un script que funciona per a 5 dispositius sovint falla (o es degrada) a 500. Necessiteu execució en paral·lel, gestió d’errors, reintentos, limitació de velocitat i capacitats de dry-run. El sistema hauria de gestionar les fallades parcials de manera gradual, proporcionar retroalimentació clara sobre el que ha anat malament i mai deixar la xarxa en un estat indefinit. Les operacions diferents necessiten estratègies diferents. Algunes són ràpides i en paral·lel, d’altres lentes i en sèrie.

5. Funcionar amb qualsevol dispositiu o plataforma de xarxa. La vostra xarxa probablement té Cisco, Arista, Juniper, Application Programming Interface (API)s cloud, màquines Linux, tallafocs i balancejadors de càrrega. Cadascun parla protocols diferents i té patrons operatius diferents. La vostra capa d’execució necessita adaptadors per a tots ells, amb una interfície comú perquè la resta de la vostra automatització no se n’hagi de preocupar.

Amb aquests objectius en ment, quines capacitats arquitectòniques necessiteu realment?

5.1.3. Pilars#

Cada objectiu es tradueix en capacitats específiques:

1. Capa d’integració de dades. El vostre motor d’execució no existeix de manera aïllada. Necessita accés programàtic a la vostra Font de Veritat (inventari, credencials, intenció), als vostres sistemes d’observabilitat (estat actual, mètriques de salut) i potencialment a altres sistemes (ticketing, gestió de canvis, fluxos d’aprovació). Això significa implementar clients d’Application Programming Interface (API), gestionar l’autenticació de manera segura, emmagatzemar en memòria cau les dades de manera adequada i validar que teniu tot el necessari abans de començar l’execució.

2. Mecanismes d’activació flexibles. Múltiples maneres d’iniciar l’execució importen. Els activadors síncrons inclouen Application Programming Interface (API)s Representational State Transfer (REST) (invocació directa), webhooks (integració amb sistemes externs) i crides de procediment remot. Els activadors asíncrons inclouen escoltadors d’esdeveniments (reacció a alertes d’observabilitat, canvis d’estat del dispositiu o esdeveniments externs), programadors (execució periòdica tipus cron o tasques programades d’una sola vegada) i consumidors de cues de missatgeria. L’encadenament bàsic també ajuda: una execució es completa i activa una altra.

3. Infraestructura de gestió d’estat. Això va més enllà de “el dispositiu té aquesta configuració”. Necessiteu estat d’execució (quines tasques s’estan executant, pendents, completades, fallades), estat desitjat (el que s’hauria de configurar) i estat real (el que està configurat). Això requereix emmagatzematge persistent, suport transaccional per a operacions atòmiques, mecanismes de bloqueig per evitar conflictes concurrents i un model d’estat clar. La infraestructura ha de gestionar els escenaris distribuïts on l’estat es comparteix entre múltiples treballadors d’execució.

4. Motor d’execució robust. Aquest és el cor del sistema. Admet fluxos de treball imperatius (executar l’ordre 1, després l’ordre 2, després l’ordre 3) i enfocaments declaratius (fer que el dispositiu tingui aquest aspecte, descobrir els passos per si sol). El motor gestiona la concurrència (executant en múltiples dispositius en paral·lel o en lots), implementa la lògica de reintents amb backoff exponencial, proporciona capacitats de dry-run (predir el que passaria sense fer-ho), captura registres d’execució detallats i gestiona les fallades parcials de manera gradual. La gestió d’errors és crítica: quan quelcom falla, hauríeu d’abortar-ho tot, continuar amb altres dispositius o reintentar?

5. Capa d’abstracció de protocols. Els dispositius de xarxa són un conjunt heterogeni. Alguns parlen Secure Shell (SSH) i esperen ordres de Command Line Interface (CLI). Altres utilitzen NETCONF o RESTCONF. Els dispositius moderns admeten gRPC Network Management Interface (gNMI) per a la telemetria en streaming i la configuració. Les plataformes cloud exposen APIs Representational State Transfer (REST). El vostre sistema d’execució necessita adaptadors per a tots ells, presentant una interfície unificada a la lògica de nivell superior. Aquesta capa gestiona el pool de connexions, la gestió de sessions, l’autenticació, el format d’ordres i l’anàlisi de respostes. Una bona abstracció significa que podeu afegir suport per a un nou tipus de dispositiu sense reescriure tota la vostra automatització.

5.1.4. Abast#

El bloc d’execució se situa entre la planificació i l’acció. Rep instruccions de la Intenció (el que s’hauria de configurar) i de l’Orquestració (quan i com fer-ho), i després interactua directament amb els dispositius de xarxa per fer que els canvis succeïn.

Dins de l’abast:

• Connexió als dispositius de xarxa via qualsevol protocol suportat
• Execució de canvis de configuració, ordres operatives, transferències de fitxers i reinicis
• Gestió de l’estat d’execució i seguiment del progrés
• Gestió d’errors, reintentos i rollbacks
• Proporcionar retroalimentació a l’Orquestració

Fora de l’abast:

• Decidir què configurar (això és la Intenció)
• Orquestrar fluxos de treball complexos de múltiples passos i decidir quan activar-los (això és l’Orquestració)
• Emmagatzematge a llarg termini i anàlisi dels resultats d’execució (això és l’Observabilitat)

Penseu en l’execució com el motor d’un cotxe: proporciona potència i moviment, però no decideix on anar ni quan girar. Aquestes decisions provenen del conductor (Orquestració) seguint un mapa (Intenció).

5.2. Funcionalitats#

Cinc àrees funcionals clau treballen juntes per modificar l’estat de la xarxa de manera segura i fiable:

1. Integració de Dades: Recuperar inventari, credencials, intenció i dades d’observabilitat dels sistemes aigüest amunt
2. Activació: Iniciar l’execució mitjançant mecanismes síncrons o asíncrons
3. Gestió d’Estat: Rastrejar el progrés de l’execució, habilitar la idempotència i el rollback
4. Motor: La lògica principal que executa les tasques amb la concurrència i la gestió d’errors apropiades
5. Adaptador de Xarxa: Interfícies específiques de protocol per comunicar-se amb dispositius de xarxa diversos

Aquests components formen un pipeline: la integració de dades proporciona les entrades, l’activació inicia el procés, el motor executa les tasques fent servir adaptadors de xarxa, i la gestió d’estat rastreja tot al llarg del procés.

graph LR
    subgraph Objectius
        G1[Posar les dades correctes al lloc adequat]
        G2[Iniciar quan calgui]
        G3[Rastrejar l'estat al llarg del temps]
        G4[Executar de manera fiable a escala]
        G5[Funcionar amb qualsevol dispositiu o plataforma de xarxa]
    end

    subgraph Pilars
        P1[Capa d'integració de dades]
        P2[Mecanismes d'activació flexibles]
        P3[Infraestructura de gestió d'estat]
        P4[Motor d'execució robust]
        P5[Capa d'abstracció de protocols]
    end

    subgraph Funcionalitats
        F1[Integració de Dades]
        F2[Activació]
        F3[Gestió d'Estat]
        F4[Motor]
        F5[Adaptador de Xarxa]
    end

    G1 --> P1 --> F1
    G2 --> P2 --> F2
    G3 --> P3 --> F3
    G4 --> P4 --> F4
    G5 --> P5 --> F5

L’arquitectura interna és la següent:

graph TD
    A[Integració de Dades] --> C[Motor]
    B[Activació] --> C[Motor]
    C --> E[Gestió d'Estat]
    E --> C
    C --> D[Adaptador de Xarxa]
    classDef component fill:#e1f5ff,stroke:#4a90e2,stroke-width:2px;
    class A,B,C,D,E component;

5.2.1. Integració de Dades#

Abans d’executar qualsevol cosa, necessiteu dades. El motor d’execució extreu informació de múltiples fonts per entendre què fer i on fer-ho.

5.2.1.1. Inventari#

Les dades d’inventari defineixen els dispositius objectiu. Ho vam cobrir al Capítol 4, però com a mínim:

• Destinació: Adreça IP o FQDN per arribar al dispositiu
• Plataforma/SO: Tipus de dispositiu, proveïdor, versió del SO (determina quin protocol i quines ordres fer servir)
• Credencials: Nom d’usuari/contrasenya, claus Secure Shell (SSH), tokens d’Application Programming Interface (API), rutes de certificats
• Paràmetres de connexió: Port Secure Shell (SSH), valors de temps d’espera, endpoints d’Application Programming Interface (API)
• Metadades: Ubicació del lloc, rol (spine/leaf/edge), entorn (prod/staging)

Les dades d’inventari haurien de provenir de la Font de Veritat. L’ús de fitxers només funciona bé en entorns molt petits. El vostre motor d’execució consulta l’Application Programming Interface (API) de la Font de Veritat en temps d’execució (o rep les dades via Orquestració en activar-se). Alguns sistemes emmagatzemen l’inventari en memòria cau per al rendiment amb intervals d’actualització configurables, o aprofiten l’inventari orientat a esdeveniments que combina l’activador amb la informació associada.

Mai emmagatzemeu les credencials en fitxers d’inventari o registres. Feu servir un sistema de gestió de secrets (HashiCorp Vault, AWS Secrets Manager, CyberArk) i injecteu les credencials en temps d’execució. La Font de Veritat hauria de proporcionar apuntadors a aquestes dades sensibles i recuperar-les en temps d’execució. El vostre motor d’execució hauria de suportar múltiples fonts de credencials i substitucions de credencials per dispositiu.

5.2.1.2. Dades Desitjades#

Les dades desitjades són el que voleu configurar o canviar. Provenen del bloc d’Intenció/Font de Veritat i poden incloure:

• Artefactes de configuració: Artefactes preparats per desplegar que poden ser dades estructurades usades directament amb APIs, o un conjunt d’ordres CLI que construeixen la configuració.
• Ordres: Ordres Command Line Interface (CLI) específiques o crides d’Application Programming Interface (API) a executar per a les operacions del dispositiu.
• Fitxers: Imatges de programari per a actualitzacions, fitxers de configuració per importar.

Hauria el motor d’execució d’obtenir les dades d’intenció per si sol, o hauria l’Orquestració de passar-les? Tots dos funcionen. Obtenir la intenció directament acobla l’execució a la vostra Font de Veritat però assegura que les dades sempre estiguin actualitzades. Rebre la intenció com a paràmetres fa que l’execució sigui més genèrica però requereix que l’Orquestració gestioni la recuperació de dades.

La meva recomanació és consumir artefactes de configuració directament. El bloc d’Intenció hauria de ser responsable de generar l’artefacte de configuració amb la seva pròpia lògica, renderitzant plantilles de configuració amb dades estructurades que representen l’estat (configuracions de VLAN, polítiques d’encaminament, ACLs).

Els artefactes de configuració poden quedar obsolets entre el moment en què es generen i el moment en què els consumeix l’Executor. Si les dades de la Font de Veritat canvien després que s’hagi emmagatzemat en memòria cau un artefacte pre-generat, l’Executor pot aplicar una configuració desfasada. La finestra d’obsolescència és el temps entre l’últim commit a la Font de Veritat i l’activador d’execució. Per a l’automatització que obté artefactes en el moment de l’activació (en lloc d’una memòria cau), aquesta finestra és mínima. Per als pipelines que pre-renderitzen artefactes en un programa i els emmagatzemen per a un ús posterior, la finestra pot créixer fins a hores. Quan la frescor de les dades importa, l’Orquestrador o l’activador d’Execució sempre hauria d’obtenir un artefacte fresc de la Font de Veritat en lloc d’un fitxer en memòria cau.

5.2.1.3. Dades Observades#

La validació d’observabilitat sol pertànyer a l’Orquestració, que pot decidir si continuar. En casos simples on l’Orquestració encara no existeix, l’Execució pot incorporar aquest rol.

Aquí hi ha alguns casos d’ús on les dades d’observabilitat s’utilitzen a prop del flux d’execució:

• Validació pre-execució: El dispositiu és accessible? Hi ha prou espai en disc per a una actualització? Hi ha sessions actives que es veurien interrompudes?
• Degradació gradual: Abans de reiniciar un commutador, consulteu l’observabilitat per veure si hi ha connectivitat redundant. Si no n’hi ha, ajorneu o avorteu.
• Lògica condicional: Només apliqueu una configuració si es compleixen certes condicions (CPU per sota del llindar, cap alarma activa, hora del dia dins de la finestra)
• Drenatge de capacitat: Abans d’executar una operació de drenatge, assegureu-vos que la capacitat disponible sigui suficient per absorbir el canvi sense trencar els SLOs.

Això requereix integració amb els vostres sistemes d’observabilitat. El motor d’execució podria consultar Application Programming Interface (API)s per a les mètriques actuals, comprovar l’estat del dispositiu o esperar senyals de preparació. L’Orquestració també pot fer aquesta integració i condicionar l’execució basant-se en la frescor i el risc.

Un patró comú: eines com els mòduls “network health checks” d’Ansible o les tasques de recollida de dades de Nornir executen consultes d’observabilitat abans i després de l’execució, comparant els resultats per detectar canvis inesperats. L’enfocament de “snapshot abans/després” detecta regressions que d’altra manera passarien desapercebudes.

5.2.2. Activació#

L’execució no s’inicia per si sola. Quelcom ha d’activar-la. Els sistemes d’execució moderns admeten múltiples mecanismes d’activació:

Síncron (immediat, bloquejant):

• Crides a Application Programming Interface (API)s Representational State Transfer (REST): Un sistema extern o un usuari invoca un endpoint d’Application Programming Interface (API), l’execució s’executa i la resposta inclou els resultats. Simple i directe.
• Webhooks: Els sistemes externs (Term "git" not found, ticketing, CI/CD) envien sol·licituds HTTP quan es produeixen esdeveniments. Patró comú: un push a Term "git" not found activa el desplegament de la configuració.
• Ordres de Command Line Interface (CLI): Els enginyers executen ordres que invoquen directament l’execució (ansible-playbook, terraform apply, scripts personalitzats). Aquestes ordres CLI formen part de la capa de presentació lleugera que ofereixen aquestes eines (més al Capítol 8).

Asíncron (retardat o orientat a esdeveniments):

• Escoltadors d’esdeveniments: Reaccioneu als esdeveniments de l’observabilitat (dispositiu caigut, llindar superat), les cues de missatgeria o els sistemes externs. Ansible Event-Driven Automation (EDA) va construir aquest patró explícitament: escoltar events, fer coincidir regles, activar playbooks automàticament.
• Cues de missatgeria: Tasques enviades a una cua (RabbitMQ, Kafka, AWS SQS), els treballadors les extreuen i les executen. Permet la memòria intermèdia, la cua de prioritats i la limitació de velocitat.

L’enfocament adequat depèn del vostre cas d’ús. Els canvis immediats (arreglar un problema de producció) necessiten activadors síncrons. L’automatització reactiva (respondre a alertes) utilitza escoltadors d’esdeveniments. Les consideracions d’escala també importen, com cobrirem al Capítol 11.

L’activació sol provenir de l’Orquestració, tot i que si aquesta no existeix, altres blocs poden activar l’execució directament. Per exemple, activant directament des de la capa de Presentació com una tasca exposada als humans, o des del bloc de la Font de Veritat.

Una consideració important: què compta com a execució? Per a mi, una execució és més que una simple tasca. Pot incloure múltiples tasques encadenades que no requereixen un flux de treball complex (aquesta és la feina de l’Orquestració). El límit es torna borrós (de nou). Per exemple, aquesta seqüència pot ser encara un sol flux d’execució: actualitzar el firmware, esperar que el dispositiu es reiniciï, verificar l’operació, actualitzar l’inventari. Però si requereix validació humana o ramificació condicional basada en una validació més àmplia, pertany al bloc d’Orquestració.

5.2.3. Gestió d’Estat#

La gestió d’estat consisteix a rastrejar on sou en una execució i com és el món perquè pugueu prendre decisions intel·ligents. Hi ha dues categories principals:

• Estat d’execució (rastrejar la pròpia automatització):

  • Quins dispositius s’han processat?
  • Quines tasques han tingut èxit, han fallat o estan pendents?
  • Si una tasca ha fallat amb un error transitori, podem reintentar-la?
  • Si l’execució es va interrompre, podem reprendre on ho vam deixar?

• Estat real de la infraestructura (rastrejar l’estat de configuració objectiu):

  • Què està configurat actualment?

Existeixen dos enfocaments:

• Sense estat/sense agent (p. ex., Ansible). Cada execució s’executa de manera independent. Cap estat persistent entre execucions. Cada execució comença de nou: recollir l’estat actual, calcular el diff, aplicar els canvis. Més senzill d’operar (sense base de dades d’estat), però menys eficient (redescobriu tot cada vegada) i sense rollback integrat.

• Amb estat (p. ex., Terraform). El sistema manté un fitxer d’estat persistent que registra el que es va desplegar per darrera vegada. En cada execució, compareu l’estat desitjat (la vostra configuració) amb l’estat registrat (el que vau desplegar l’últim cop) i l’estat real (el que hi ha al dispositiu). Això permet una planificació de canvis precisa, una execució eficient (només canviar el que és diferent) i el rollback (revertir a l’estat anterior). Però ara teniu un fitxer d’estat per protegir, bloquejar i sincronitzar entre múltiples operadors.

L’execució transaccional és el pas següent quan voleu garanties de seguretat més sòlides que el “millor esforç”. Una transacció agrupa múltiples canvis de dispositiu en una sola unitat: o bé tot s’aplica i es valida, o bé el sistema reverteix a l’estat anterior. Això requereix tres coses:

• Un límit clar (quines operacions estan dins de la transacció)
• Un registre durador de l’estat pre-canvi (per al rollback)
• Un mecanisme de bloqueig o arrendament per evitar que els canvis concurrents trenquin l’atomicitat

A la pràctica, la majoria de l’automatització de xarxes utilitza un comportament “transaccional” en lloc de semàntiques ACID estrictes, perquè no tots els dispositius admeten el commit/rollback natiu. Tot i així, podeu aproximar les transaccions fent snapshots, fent servir configuracions candidates (quan es suporta), aplicant bloquejos exclusius i fent de la ruta de rollback una part de primera classe del flux d’execució.

El repte? La sincronització i el compartiment d’estat. Si múltiples persones o sistemes modifiquen els dispositius de xarxa, l’estat queda obsolet. Terraform ho aborda amb l’emmagatzematge d’estat remot i el bloqueig. Ansible evita el problema sent sense estat però sacrifica l’eficiència. El terreny intermedi: emmagatzemar en memòria cau l’estat actual temporalment, validar abans de cada operació i construir patrons de “consistència eventual” on les diferències breus siguin acceptables.

5.2.3.1. Idempotència#

La idempotència significa que executar la mateixa automatització múltiples vegades produeix el mateix resultat. Apliqueu una configuració de VLAN una vegada: la VLAN es crea. Apliqueu-la de nou: res no canvia (la VLAN ja existeix). Això és crític per a la fiabilitat: si l’execució falla a mig camí, podeu tornar-la a executar de manera segura sense crear duplicats ni trencar coses.

Com les eines aconsegueixen la idempotència:

• Mòduls integrats (p. ex., Ansible): La majoria dels mòduls d’Ansible són idempotents per disseny. El mòdul ios_vlan comprova si la VLAN existeix abans de crear-la. Si ja hi és amb la configuració correcta, Ansible informa “ok” (cap canvi). Això requereix que l’autor del mòdul implementi la lògica de comprovació.

• Comparació d’estat (p. ex., Terraform): Terraform compara l’estat desitjat amb l’estat actual, calcula un diff i només aplica les diferències. Si executeu terraform apply dues vegades sense canvis a la vostra configuració, la segona execució no fa res.

• APIs declaratives (p. ex., NETCONF/YANG): Alguns protocols gestionen la idempotència de manera nativa. El <edit-config> de NETCONF amb l’operació merge és inherentment idempotent: fusiona la vostra configuració amb la configuració existent, creant o actualitzant segons calgui.

• Comprovació manual (p. ex., scripts bruts): Si esteu escrivint scripts Python o Go, implementeu la idempotència vosaltres mateixos: consulteu l’estat actual, compareu amb l’estat desitjat, feu canvis només si hi ha un diff.

La idempotència és més difícil del que sembla. Què passa si la VLAN existeix però té configuració incorrecta? Hauríeu d’actualitzar-la (potencialment interrompent el tràfic) o informar d’un conflicte? Què passa amb les fallades transitòries (dispositiu temporalment inaccessible)? La lògica de reintentos ha de distingir entre “operació ja feta” (èxit idempotent) i “operació fallada” (error real).

La idempotència perfecta afegeix sobrecàrrega. Cada operació requereix consultar l’estat actual primer. Per als desplegaments a gran escala, això alenteix les coses. Alguns equips accepten “majoritàriament idempotent” (funciona el 99% del temps) en lloc de “perfectament idempotent” (funciona sempre, però s’executa lentament).

La idempotència és un requisit per a l’enfocament declaratiu. Algú ha de portar la càrrega de proporcionar la idempotència i amagar la complexitat per a tots els altres.

5.2.4. Motor#

El motor d’execució és la lògica principal que agafa una tasca (“configurar aquesta VLAN en aquests 50 commutadors”) i l’executa de manera segura i eficient. Això no és l’Orquestració. El bloc d’Orquestració coordina múltiples tasques d’execució al llarg del temps i les dependències. El motor simplement executa bé una tasca (o una cadena simple de tasques).

Què fa:

• Accepta una definició de tasca (què fer, quins dispositius)
• La divideix en operacions atòmiques (accions per dispositiu)
• Executa les operacions amb la concurrència apropiada (en sèrie, en paral·lel, per lots)
• Gestiona els errors, els reintentos i els rollbacks
• Informa del progrés i dels resultats

Un motor d’execució podria configurar 100 encaminadors en paral·lel, però no decideix quan configurar-los, quines configuracions aplicar basant-se en la lògica de negoci, ni què fer a continuació basant-se en els resultats. Aquestes són preocupacions de l’Orquestració. L’Execució és el cavall de treball; l’Orquestració és el capatàs.

Dit això, els motors d’execució sovint admeten encadenament simple: “feu la tasca A, després la tasca B en els mateixos dispositius.” Això és seqüenciació bàsica, no Orquestració completa. Quan necessiteu fluxos de treball complexos (espereu l’aprovació externa, ramifiqueu basant-vos en els resultats, coordineu a través de múltiples sistemes) necessiteu una capa d’Orquestració real (més al Capítol 7).

5.2.4.1. Llenguatges#

Com definiu la lògica d’execució? Els diferents estils de llenguatge tenen compromisos diferents:

Molts equips utilitzen DSLs (Ansible) per als patrons comuns i passen a codi personalitzat (mòduls Python, plugins) per als casos extrems complexos. Això equilibra l’accessibilitat amb la potència. El factor humà sol decidir quin enfocament guanya; més sobre això al Capítol 13.

5.2.4.2. Imperatiu versus Declaratiu#

Imperatiu: Especifiqueu com fer quelcom, pas a pas.

Declaratiu: Especifiqueu quin ha de ser l’estat final, i l’eina s’esbrinja com arribar-hi.

En resum, preferiu el declaratiu quan s’adapti.

Una bona manera de veure la diferència és mirar Ansible, que admet tots dos:

• Ansible imperatiu:

  - name: Create VLAN 100
    cisco.ios.ios_command:
      commands:
        - vlan 100
        - name Engineering

  Literalment li esteu dient a Ansible quines ordres executar. Si la VLAN existeix, això s’executa igualment (tot i que pot ser idempotent depenent del mòdul).

• Ansible declaratiu:

  - name: Ensure VLAN 100 exists
    cisco.ios.ios_vlans:
      config:
        - vlan_id: 100
          name: Engineering
      state: merged

  Descriviu l’estat desitjat. Ansible esbrinja quines ordres executar. Si la VLAN 100 ja existeix amb el nom correcte, Ansible no fa res.

La majoria dels equips utilitzen el declaratiu quan és possible, l’imperatiu quan és necessari. Recordeu: declaratiu significa que algú altre porta la càrrega, fins i tot si sembla simple des de fora.

5.2.4.3. En Sèrie versus en Paral·lel#

Existeixen dues opcions per executar les tasques:

• Execució en sèrie: Processeu els dispositius d’un en un. Configureu el dispositiu 1, espereu que es completi, configureu el dispositiu 2, etc. Segur (veieu les fallades immediatament i podeu aturar-vos), però lent (100 dispositius = 100 vegades el temps d’un dispositiu).

• Execució en paral·lel: Processeu múltiples dispositius simultàniament. Configureu els dispositius 1-10 alhora, 11-20 a continuació, etc.

flowchart TD
    subgraph Serial["En Sèrie"]
        S1[Dispositiu 1] --> S2[Dispositiu 2] --> S3[Dispositiu 3]
    end
    subgraph Parallel["En Paral·lel"]
        P0[Inici] --> P1[Dispositiu 1]
        P0 --> P2[Dispositiu 2]
        P0 --> P3[Dispositiu 3]
    end

Per què existeix Nornir: Ansible era originalment en sèrie. Per a l’automatització de xarxes a escala, això era dolorosament lent. Ansible va afegir strategy: free i després forks per habilitar el paral·lelisme, però continua estant fonamentalment dissenyat per a l’execució seqüencial. Nornir es va construir des de zero amb el paral·lelisme en ment: utilitza threading per defecte per executar en múltiples dispositius concurrentment. Això el fa 10-100 vegades més ràpid per a grans comptadors de dispositius.

Consideracions per a l’execució en paral·lel:

• Impacte en el pla de control: Accedir a 1000 dispositius simultàniament pot sobrecarregar les xarxes de gestió, les fonts de dades i els sistemes d’autenticació, o els plans de control dels dispositius.
• Gestió de dependències: Si els dispositius depenen els uns dels altres (spine abans que leaf), necessiteu ordenació. El paral·lelisme pur no funciona.
• Radi d’explosió d’errors: Si la vostra automatització té un error, l’execució en paral·lel el desplega en molts dispositius abans que us n’adoneu. L’execució en sèrie falla en el dispositiu 1; us atureu abans de danyar els dispositius 2-100.

La meva recomanació: feu servir l’execució en paral·lel amb lots. Processeu els dispositius en grups de 10-50 (jo solia anomenar-los “ones”), verifiqueu l’èxit de cada lot abans de continuar. Això equilibra la velocitat amb la seguretat. Més sobre les estratègies de desplegament al Capítol 10.

5.2.4.4. Dry-run (Mode Pla)#

El dry-run és la fase de “pla” del motor d’execució: simular els canvis sense tocar els dispositius, i després mostrar un diff concret i els riscos. Un bon dry-run extreu l’estat actual, calcula les operacions exactes a nivell de dispositiu que s’executarien i valida els prerequisits (accessibilitat, esquema, ordenació de dependències). Ha de ser ràpid, determinista i reproduïble perquè els revisors hi puguin confiar.

Exemple (pla de Terraform per a un AWS VPC amb canvis revisables):

Terraform will perform the following actions:

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + cidr_block           = "10.10.0.0/16"
      + enable_dns_support   = true
      + enable_dns_hostnames = true
      + tags = {
          + "Name" = "core-vpc"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Això és el que els revisors aproven: els recursos i atributs exactes que canviarien, sense tocar el cloud.

A la pràctica, el dry-run és el que fa que les aprovacions siguin significatives i que els rollbacks siguin menys probables. Dóna als humans una visió clara del que passarà, i dóna al motor una oportunitat de rebutjar els canvis insegurs o inconsistents d’hora. Si la plataforma admet configuracions candidates o commit-check, el motor hauria de fer-les servir. En cas contrari, el dry-run és un diff calculat més pre-comprovacions, no una garantia.

En la meva experiència, oferir capacitats de dry-run és molt convenient en els primers dies d’un projecte d’automatització per aconseguir el suport dels enginyers de xarxa. Més tard, la rellevància disminueix.

5.2.4.5. Resiliència#

L’execució de xarxa és inherentment poc fiable (com la majoria dels sistemes distribuïts): els dispositius es reinicien, la connectivitat fa errors i els plans de control es col·lapsen. Altres dependències, com el bloc d’Intenció, també poden tenir problemes temporals. L’execució resilient ho gestiona de manera gradual:

Lògica de reintentos:

• Les fallades transitòries (temps d’espera de connexió, pic de CPU temporal) haurien d’activar reintentos amb backoff exponencial
• Distingiu els errors reintentables (temps d’espera) dels errors permanents (fallada d’autenticació, error de sintaxi)
• Limiteu els intents de reintents per evitar bucles infinits

Estratègies de temps d’espera:

• Temps d’espera de connexió: quant de temps esperar la resposta del dispositiu abans de rendir-se
• Temps d’espera de tasca: quant de temps pot durar una operació completa (evita quedar-se penjat en dispositius bloquejats)
• Temps d’espera global: temps màxim d’execució per a tota la feina

Gestió d’errors:

• Fallada ràpida: un dispositiu falla, avorteu-ho tot (segur però ineficient)
• Continueu: registreu la fallada, continueu amb altres dispositius (eficient però podria estendre el dany)
• Basat en llindar: si >10% dels dispositius falla, atureu-vos (equilibrat)

Capacitats de rollback:

• Feu snapshots de configuració abans dels canvis
• Si l’execució falla, restaureu automàticament els snapshots
• Admeteu el mode dry-run: mostreu el que canviaria sense canviar-ho realment

Tallacircuits:

• Si un dispositiu falla consistentment, marqueu-lo com a no saludable i ometeu-lo temporalment
• Evita perdre el temps intentant connectar-se repetidament a dispositius morts

Punts de control:

• Deseu el progrés periòdicament
• Si l’execució falla, repreneu des de l’últim punt de control en lloc de começar de nou

Construir tot això és difícil. La majoria dels equips comencen amb la lògica de reintents bàsica i afegeixen complexitat a mesura que es troben fallades en producció.

Un patró útil: tractar els “modes de seguretat” com a estats d’execució de primera classe. Renderitzeu la configuració desitjada, analitzeu la configuració actual, recopileu fets i després apliqueu (merged/replaced/overridden) només després que les portes de validació passin. Això us dóna punts de control deterministes abans de tocar la producció.

5.2.5. Adaptador de Xarxa#

Els dispositius de xarxa parlen protocols diferents. La capa d’adaptador de xarxa abstrau aquestes diferències perquè les capes superiors no es preocupin de si estan parlant amb un commutador Cisco via Secure Shell (SSH) o un commutador Arista via Application Programming Interface (API) Representational State Transfer (REST).

5.2.5.1. Interfícies#

Els dispositius diferents admeten interfícies de gestió diferents:

Algunes biblioteques proporcionen una capa d’abstracció amb una interfície comú entre plataformes, com ara:

• NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support): Biblioteca Python que proporciona una API unificada entre proveïdors.
  • Admet Cisco, Arista, Juniper i d’altres
  • Per sota, utilitza el protocol apropiat (Secure Shell (SSH), Application Programming Interface (API), NETCONF)
  • Cas d’ús: Entorns multi-proveïdor on voleu codi d’automatització consistent
• Pybatfish: No és una biblioteca de transport de dispositius, sinó un company sòlid per a la seguretat de l’execució. Un patró pràctic és “planificar/aplicar amb NAPALM o Ansible, validar el comportament de la xarxa amb pybatfish abans i després dels canvis.”

Per què fer servir una capa d’abstracció? En lloc d’escriure codi diferent per a Cisco vs. Juniper, NAPALM us dóna una API. Crideu a get_facts() i NAPALM esbrinja com obtenir les dades del dispositiu tant si és un dispositiu Cisco IOS (via Secure Shell (SSH)), Arista EOS (via eAPI) o Juniper Junos (via NETCONF). El compromís: l’abstracció oculta les característiques específiques del proveïdor. Per a les operacions comunes (obtenir configuració, enviar configuració, obtenir dades), és fantàstic. Per a les operacions més avançades o les característiques exòtiques del proveïdor, tornareu a les interfícies natives perquè probablement no s’haurà implementat.

5.2.5.2. Operacions#

L’execució de xarxa no és només gestió de configuració:

Cada tipus d’operació té els seus propis modes d’error i necessita un tractament específic. Les actualitzacions de programari necessiten pre-comprovacions (prou espai en disc?), post-comprovacions (el dispositiu ha arrencat correctament?) i plans de rollback (si l’actualització falla, recarregueu la imatge antiga). Els resultats haurien d’estar exposats a l’Orquestració per a les decisions, mentre que l’Execució pot gestionar les barreres de seguretat locals i els reintentos.

On pertanyen la validació i el renderitzat: La Font de Veritat posseeix la intenció i (opcionalment) les configuracions pre-renderitzades. L’Execució posseeix les comprovacions de seguretat a nivell de dispositiu i la validació operativa (accessibilitat, pre/post comprovacions). L’Orquestració decideix quan validar i què fer amb els resultats (aprovar, pausar, fer rollback o escalar). Si voleu una regla simple: la validació que canvia el flux de treball pertany a l’Orquestració; la validació que canvia les accions del dispositiu pertany a l’Execució.

5.2.6. Solucions#

Existeixen moltes eines per a l’execució de xarxes, i comparar-les ajuda a entendre els compromisos:

Molts equips utilitzen múltiples eines depenent del cas d’ús i la infraestructura de xarxa.

5.2.7. Aprovisionament sense Intervenció Humana (ZTP)#

El Zero Touch Provisioning (ZTP) és un patró d’execució diferent on un dispositiu arrenca per primera vegada i recupera i aplica automàticament la seva configuració completa sense cap intervenció humana al dispositiu. El flux de dades és estructuralment diferent de les operacions del dia 2 i val la pena tractar-lo com un patró arquitectònic amb nom.

El flux ZTP

flowchart LR
    A[Dispositiu arrenca\nsense config] --> B[DHCP assigna\nIP de gestió\ni URL de bootstrap]
    B --> C[Dispositiu obté\nconfig de bootstrap\ndel servidor]
    C --> D[Dispositiu s'autentica\nal SoT i xarxa\nde gestió]
    D --> E[Orquestrador detecta\nnou dispositiu, activa\nfeina d'aprovisionament complet]
    E --> F[Executor aplica\nintenció completa del SoT]

La idea clau és que el pas d’arrencada és deliberadament mínim: just prou configuració per connectar el dispositiu a la xarxa de gestió i poder autenticar-se. L’aprovisionament complet s’executa després com una feina estàndard de l’Executor, extraient la intenció completa de la Font de Veritat. Això significa que ZTP reutilitza el mateix pipeline d’execució que les operacions del dia 2 en lloc de requerir un sistema d’aprovisionament separat.

Patrons ZTP comuns

ZTP introdueix una dependència de seqüenciació: el dispositiu ha d’estar inscrit a la Font de Veritat abans d’arrencar físicament, en cas contrari el servidor bootstrap no té dades per generar una configuració. En l’escenari del campus, això es gestiona mitjançant la sincronització de ServiceNow a Nautobot: quan s’afegeix un commutador com a actiu a ServiceNow (abans que arribi al lloc), Nautobot crea automàticament el registre del dispositiu amb ubicació, rol i proveïdor. Quan el commutador arrenca, la Font de Veritat ja està llesta.

5.2.8. Execució Híbrida i en el Cloud#

L’Executor necessita cada vegada més operar simultàniament en dos entorns fonamentalment diferents: dispositius de xarxa tradicionals i plataformes cloud-native. Aquests entorns tenen paradigmes d’API, models d’autenticació i modes de fallada diferents. Tractar-los de manera idèntica condueix a una automatització fràgil; tractar-los com a sistemes completament separats duplica l’esforç i crea operacions inconsistents.

El problema de la divergència

L’arquitectura recomanada

Mantingueu la Intenció (Font de Veritat) i l’Orquestració unificades. La mateixa sol·licitud de negoci que crea una VLAN en els commutadors del campus pot necessitar també crear un grup de seguretat a AWS. La Font de Veritat conté tots dos. L’Orquestrador coordina tots dos. Només a la capa de l’Adaptador de Xarxa (5.2.5) divergeix la ruta d’execució: un adaptador gestiona NETCONF/Ansible contra els commutadors del campus; un altre gestiona Terraform o les APIs del proveïdor cloud contra l’entorn cloud.

Això significa que el radi d’explosió d’un canvi de l’API cloud i un canvi de dispositiu de xarxa es regeix pel mateix rastre d’aprovació i auditoria, que és el resultat arquitectònic correcte fins i tot quan els protocols són completament diferents.

L’estratègia del gestor de secrets ha d’acomodar tant les credencials de llarga durada dels dispositius de xarxa com els tokens de curta durada del cloud. Per a les plataformes cloud, les credencials s’haurien de generar a l’inici de la feina i mai emmagatzemar-se. La majoria dels proveïdors cloud ofereixen mecanismes per a això (perfils d’instàncies AWS, identitats gestionades Azure, identitat de càrrega de treball GCP). Les credencials dels dispositius de xarxa es mantenen a Vault i s’injecten en temps d’execució. L’Executor mai hauria de tenir credencials entre execucions de feines independentment del tipus de destinació.

5.2.9. Consideracions de Seguretat#

L’Executor és el component de la vostra arquitectura que té accés d’escriptura a la xarxa. Pot enviar configuracions, reiniciar serveis, actualitzar firmware i alterar les polítiques d’encaminament en centenars de dispositius simultàniament. Això fa que la seva postura de seguretat sigui més conseqüent que gairebé qualsevol altre component, i tot i així és freqüentment el més negligit des d’un punt de vista arquitectònic. Un Executor compromès o mal configurat no és un risc de bretxa de dades; és un risc d’interrupció de la xarxa.

Gestió de credencials

Les credencials per als dispositius de xarxa mai haurien d’aparèixer en playbooks, plantilles, definicions de feines o control de versions. El patró és senzill: emmagatzemeu els secrets en un gestor de secrets dedicat (HashiCorp Vault, AWS Secrets Manager, CyberArk) i injecteu-los en temps d’execució a l’entorn de l’Executor. L’Executor obté les credencials a l’inici de la feina; no les manté permanentment.

Això també significa que la rotació de credencials es torna operativament segura. Quan es roten les contrasenyes dels dispositius, com s’hauria de fer regularment, l’Executor recull les noves credencials en la seva pròxima execució sense cap desplegament ni reconfiguració.

Privilegi mínim per operació

No totes les execucions necessiten el mateix nivell d’accés. Les operacions de lectura (recopilació de dades, comprovacions de dry-run, validació pre-desplegament) haurien d’utilitzar credencials de només lectura. Les operacions d’escriptura haurien d’utilitzar credencials amb abast al tipus de canvi: una feina que desplega canvis de VLAN no hauria de tenir credencials que permetin canvis de configuració BGP. On la plataforma de xarxa admet l’accés basat en rols (rols Arista, nivells de privilegi Cisco, control d’accés NETCONF), feu-los servir per limitar el radi d’explosió de qualsevol sessió compromesa.

A l’exemple del campus, això significa que una feina de desplegament de VLAN en un commutador Arista utilitza un rol que permet la configuració de VLAN i interfície però no pot tocar la configuració del protocol d’encaminament ni la configuració del pla de gestió.

Separació de responsabilitats

Qui pot activar l’execució i qui pot modificar la lògica d’automatització haurien de ser rols diferents amb controls d’accés diferents. Un operador que aprova i llança una feina de desplegament de VLAN no necessita, i no hauria de tenir, accés per modificar els rols d’Ansible o les plantilles de playbook que ho implementen. A AWX i AAP, això s’aplica mitjançant assignacions de rols: “Llançador de feines” pot iniciar plantilles de feines pre-aprovades; “Editor de projectes” pot canviar la lògica d’automatització subjacent.

Aquesta separació importa més quan l’automatització s’utilitza per a operacions d’alt impacte. La persona que inicia una actualització de firmware a 800 commutadors no hauria de ser també la persona que va escriure el playbook d’actualització, o com a mínim un segon revisor hauria d’haver aprovat el playbook abans que estigui disponible per a l’ús en producció.

Requisits del rastre d’auditoria

Cada esdeveniment d’execució s’ha de registrar amb prou detall per reconstruir el que va passar: qui va activar la feina, quina plantilla de feina es va fer servir, quins dispositius eren objectiu, quins paràmetres es van passar, quin va ser el resultat per a cada dispositiu i en quin moment. Els registres s’han de conservar durant el període de compliment aplicable a l’organització, normalment de 12 a 24 mesos per a la gestió de canvis en indústries regulades.

Això no és opcional en la majoria dels entorns empresarials. Els processos de gestió de canvis requereixen un registre traçable que vinculi un tiquet de canvi a un esdeveniment d’execució específic a un conjunt específic de canvis de dispositiu. Dissenyeu aquest rastre d’auditoria a l’Executor des del principi en lloc de retrofitar-lo després.

Segmentació de la xarxa de la infraestructura d’automatització

L’Executor i el seu pla de control (AWX, nodes de control d’Ansible) haurien d’estar en un segment de xarxa de gestió. El tràfic d’execució als dispositius hauria de fluir a través de la xarxa de gestió fora de banda on estigui disponible, no a través del mateix pla de dades que l’Executor podria estar modificant. L’accés entrant per activar les feines hauria de requerir autenticació i no hauria de ser accessible des de xarxes no fiables.

Un mode de fallada pràctic a evitar: un Executor accessible des de la VLAN d’usuari de producció significa que qualsevol host compromès en aquesta VLAN podria potencialment activar canvis de xarxa. L’accés al pla de gestió pertany a una xarxa del pla de gestió.

5.3. Exemple d’Implementació#

5.3.1. Cas d’Ús: Desplegament Automatitzat de VLAN en un Campus Heterogeni#

Continuem amb la xarxa del campus del Capítol 4. La definició del servei VLAN (el seu ID, subxarxa, plantilles de configuració per proveïdor i grups de commutadors objectiu) ara es troba emmagatzemada a la Font de Veritat. Aquest capítol se centra en com el bloc d’Execució agafa aquesta intenció i la desplega de manera fiable a tots els 800 commutadors.

Escenari: Un equip de negoci sol·licita una nova VLAN per a una nova aplicació. La sol·licitud arriba a través d’un sistema de ticketing amb detalls: ID de VLAN, nom, llocs del campus i aprovació. Les operacions de xarxa despleguen aquesta VLAN a través dels commutadors d’accés/distribució Arista, HPE i Cisco, verifiquen la connectivitat i informen de l’èxit.

Requisits:

• Desplegar la configuració de VLAN en múltiples commutadors en paral·lel
• Verificar les pre-condicions (la VLAN no existeix ja, els commutadors són accessibles)
• Realitzar un dry-run per mostrar el que canviaria
• Executar el desplegament real amb capacitat de rollback si es produeixen fallades
• Verificar post-desplegament (la VLAN és activa, cap error)

5.3.2. Arquitectura de la Solució#

Ampliant la visió de tota l’arquitectura abans d’entrar en els detalls d’execució:

1. Font de Veritat: NetBox (emmagatzema l’inventari, les definicions de VLAN)
2. Orquestració/Activació: Coordinació de la Plantilla de Flux de Treball AWX (llançament via API, webhook, programat)
3. Observabilitat: Proporciona dades en temps real per a la presa de decisions
4. Execució:
   • Motor d’Execució: Plantilles/tasques de feina d’Ansible (precomprovació, dry-run, desplegament, verificació, rollback)
   • Integració de Dades: Plugin d’inventari NetBox a Ansible/AWX
   • Adaptadors de Xarxa: Mòduls Ansible per a Cisco IOS XE, Arista EOS i HPE/Aruba
   • Gestió d’Estat: Estat de feina i flux de treball AWX per fase + resultats per host, amb tasca de rollback en les rutes de fallada

Aquesta solució és a efectes il·lustratius; no és una recomanació universal.

5.3.3. Flux d’Implementació#

Això s’executa com un flux de treball AWX amb múltiples nodes de tasques:

1. Un canvi d’intenció de VLAN a NetBox activa AWX via webhook
2. El flux de treball AWX s’inicia i executa la sincronització d’inventari (NetBox)
3. La feina de precomprovació valida l’accessibilitat, l’estat de VLAN existent i les barreres de seguretat del lloc
4. La feina de dry-run renderitza les tasques específiques del proveïdor sense aplicar els canvis
5. El node d’aprovació (opcional) condiciona l’execució en producció
6. La feina de desplegament aplica la intenció de VLAN en lots en paral·lel entre proveïdors
7. La feina de verificació confirma l’estat operatiu i desitjat
8. En cas de fallades, la feina de rollback s’executa només per a l’abast afectat
9. L’observabilitat recull les dades pre/post per donar suport a la validació final
10. La validació final s’executa i es publica el resum d’execució

flowchart TD
    A[Canvi d'Intenció de VLAN a NetBox] --> B[Webhook a AWX]
    B --> C[Inici del Flux de Treball AWX]
    C --> E[Sincronització d'Inventari des de NetBox]
    E --> F[Tasca de Precomprovació]
    F --> G[Tasca de Dry-run]
    G --> H[Node d'Aprovació]
    H --> I[Tasca de Desplegament]
    I --> J[Tasca de Verificació]
    J --> N[Recollida de Dades de Xarxa]
    N --> L[Validació Final]
    L --> M[Actualitzar Tiquet i Informe]

    F -->|fallada| X[Aturar i retornar errors de validació]
    I -->|hosts fallats| Y[Tasca de Rollback per als dispositius afectats]
    Y --> J
    F --> N

    %% --- Styles ---
    classDef sot fill:#cfe8ff,stroke:#0b5fb3,stroke-width:2px;
    classDef orch fill:#ffe0cc,stroke:#c24b00,stroke-width:2px;
    classDef exec fill:#d7f4e1,stroke:#0f7a3b,stroke-width:2px;
    classDef obs fill:#ffd6d6,stroke:#b22222,stroke-width:2px;

    class A sot;
    class B,C,E,H,L,M orch;
    class F,G,I,J,Y,X exec;
    class N obs;

5.3.4. Resum de la Solució#

Aquesta implementació demostra totes les capacitats d’execució clau:

• Integració de Dades: Extreu l’inventari i la intenció de NetBox mitjançant l’inventari dinàmic
• Activació: El flux de treball AWX admet API/webhook/programació, a més de l’execució condicionada per aprovació
• Gestió d’Estat: L’estat del flux de treball/feina AWX rastreja el progrés i els dominis de fallada; la ruta de rollback és explícita
• Motor: Ansible gestiona l’execució en paral·lel (configurat via forks/lots), la gestió d’errors i el dry-run
• Adaptador de Xarxa: Els mòduls de recursos específics del proveïdor mapegen una intenció a plataformes diferents (cisco.ios.ios_vlans, arista.eos.eos_vlans i mòduls de col·lecció HPE/Aruba)
• Observabilitat: La recollida de dades pre/post dóna suport a la validació final i els informes

Característiques de resiliència:

• Les pre-comprovacions eviten el desplegament en dispositius inaccessibles o la creació de VLANs duplicades
• El dry-run mostra els canvis abans d’aplicar-los
• Els punts de control de seguretat utilitzen estats de mòduls de recursos (rendered, parsed, gathered) abans dels estats d’aplicació (merged, replaced, overridden)
• Els mòduls idempotents fan que tornar a executar sigui segur
• La post-verificació detecta les fallades silencioses
• Rollback: el node de rollback dedicat d’AWX limita el rollback a l’abast del dispositiu afectat

Consideracions d’escalabilitat:

• L’execució en paral·lel via forks: 50 processa 50 commutadors simultàniament
• Per a desplegaments més grans (500+ commutadors), dividiu en grups i feu servir Ansible Tower/AWX per a la gestió del flux de treball
• Afegiu limitació de velocitat si el pla de control o els sistemes d’autenticació no poden gestionar la càrrega

5.4. Resum#

El bloc d’Execució és on l’automatització de xarxes es fa tangible: les configuracions s’envien, els dispositius es reinicien, els canvis succeeixen. Però l’execució fiable és més que enviar ordres via Secure Shell (SSH).

Comença amb la integració de dades i l’activació, i depèn de la gestió d’estat (idempotència, rollback i seguretat transaccional), un motor capaç (eleccions en sèrie/paral·lel, dry-run/pla, resiliència) i una capa d’adaptador de xarxa que oculta les diferències de protocol entre proveïdors. L’observabilitat alimenta la validació i les barreres de seguretat, mentre que l’Orquestració decideix quan continuar o aturar-se. Les eines importen menys que els patrons d’execució: integreu dades, activeu intencionalment, executeu de manera determinista, valideu els resultats i manteniu una ruta de rollback neta.

Comenceu petit i escaleu deliberadament: un flux de treball, una classe de dispositius i pre/post comprovacions clares. Afegiu lots, límits de velocitat i validació més sòlida a mesura que creixi el radi d’explosió. L’execució és poderosa i arriscada; proveu exhaustivament, desplegueu gradualment, monitoritzeu constantment i planifiqueu sempre el rollback.

Referències i Lectures Addicionals#

• Network Programmability and Automation: Skills for the Next-Generation Network Engineer, 2a edició. O’Reilly Media, 2023. Matt Oswalt, Christian Adell, Scott S. Lowe i Jason Edelman. Capítol 10 (Automation Tools) i Capítol 12 (Automation Architecture).
• Network Automation Cookbook, 2a edició. Packt Publishing, 2024. Christian Adell i Jeff Kala.
• Documentació d’automatització de xarxes Ansible: https://docs.ansible.com/ansible/latest/network/
• Mastering Python Networking, 4a edició. Packt Publishing, 2023. Eric Chou
• Documentació NAPALM: https://napalm.readthedocs.io/
• Documentació Nornir: https://nornir.readthedocs.io/
• Terraform Network Infrastructure Automation: https://www.terraform.io/use-cases/network-infrastructure-automation

💬 Found something to improve? Send feedback for this chapter