Da strumento di configurazione a piattaforma di automazione
Ansible nasce come strumento di automazione agentless per la configurazione dei server: playbook in YAML, connessione via SSH, nessun agent da installare sui nodi gestiti. Questo modello semplice ha portato Ansible dalla gestione di pochi server alla posizione di piattaforma di automazione IT tra le più adottate al mondo. Ma l’evoluzione del panorama infrastrutturale — multi-cloud, container, reti software-defined — ha richiesto un’evoluzione altrettanto significativa nella struttura del progetto.
La ristrutturazione attorno alle Collection
Il cambiamento architetturale di maggiore portata degli ultimi anni è la ristrutturazione attorno alle Collection. In precedenza, centinaia di moduli — per AWS, Azure, Google Cloud, VMware, database, servizi di rete — erano distribuiti insieme al pacchetto Ansible principale. Ogni rilascio richiedeva il coordinamento di migliaia di moduli con cicli di sviluppo diversi.
Le Collection separano i moduli e i plugin dal core. Ogni Collection è un pacchetto indipendente con il proprio ciclo di rilascio, la propria documentazione e i propri maintainer. La Collection amazon.aws può rilasciare una nuova versione senza attendere il rilascio di Ansible; la Collection community.general evolve con i propri tempi.
ansible-core e Galaxy
Il risultato della ristrutturazione è una netta separazione: ansible-core contiene il motore di esecuzione, il linguaggio dei playbook, le API dei plugin e un set minimale di moduli builtin. Tutto il resto — centinaia di moduli per piattaforme cloud, database, servizi di rete, container — viene installato come Collection da Ansible Galaxy, il marketplace delle Collection.
Galaxy funziona come un registro centralizzato: i team possono pubblicare Collection proprie, condividere ruoli e plugin con la comunità, e gestire le dipendenze tramite un file requirements.yml analogo a quello dei gestori di pacchetti.
Execution Environment
Gli Execution Environment risolvono un problema pratico: le dipendenze Python necessarie per eseguire moduli diversi possono entrare in conflitto. Un modulo per AWS richiede boto3, uno per Azure richiede il SDK Azure, uno per rete richiede netmiko — e le versioni devono essere compatibili tra loro e con il Python del sistema.
Gli Execution Environment sono immagini container che includono ansible-core, le Collection necessarie e tutte le dipendenze Python in un ambiente isolato e riproducibile. Lo strumento ansible-builder genera queste immagini a partire da un file di configurazione, e ansible-navigator le utilizza come ambiente di esecuzione predefinito. Il risultato è un’automazione che non dipende dallo stato della macchina di controllo.
Automazione oltre i server
Nel 2022 l’ambito di Ansible si estende ben oltre la configurazione dei server. Le Collection coprono il provisioning cloud — creazione di VPC, load balancer, cluster Kubernetes — la gestione di apparati di rete Cisco, Juniper e Arista, l’automazione di database, container e pipeline CI/CD. Per le organizzazioni che gestiscono infrastrutture ibride, Ansible offre un linguaggio dichiarativo unico per orchestrare risorse eterogenee.
Link: ansible.com