Installare e configurare Ansible su CentOS 9 Stream

Perché su CentOS 9 Stream conviene partire dai repository giusti

Su CentOS 9 Stream Ansible non va trattato come un pacchetto “qualsiasi” da installare al volo. La parte delicata non è tanto l’engine in sé, quanto il contesto: Python 3 presente e coerente, repository abilitati in modo corretto, accesso SSH senza ambiguità, e policy SELinux che non devono essere aggirate per comodità. Se il server sarà usato come nodo di controllo, la differenza la fanno i dettagli: un ambiente pulito evita errori strani nei moduli, nei path e nelle dipendenze.

La regola pratica è semplice: prima verifico la piattaforma, poi scelgo il canale di installazione, infine imposto una baseline di configurazione che mi consenta di eseguire i primi playbook senza toccare il sistema più del necessario. Su Stream questo approccio è ancora più sensato perché il ramo è rolling e può introdurre aggiornamenti più frequenti rispetto a una release “fissa”.

Verifiche iniziali sul sistema

Prima di installare qualsiasi cosa, controllo versione, Python e stato dei repository. Così evito di scoprire dopo che il sistema è in uno stato incoerente o che manca un componente base per l’esecuzione dei moduli.

Comandi utili:

cat /etc/centos-release
python3 --version
dnf repolist
uname -r

Mi aspetto una release di CentOS Stream 9, Python 3 disponibile e repository attivi. Se python3 non risponde o il sistema è minimale, la correzione va fatta prima di procedere con Ansible. In un’installazione standard, CentOS 9 Stream porta già la base necessaria, quindi l’eventuale anomalia è un segnale da non ignorare.

Installazione di Ansible con dnf

Su CentOS 9 Stream la strada più lineare è usare i pacchetti del repository disponibile nel sistema. In molti casi Ansible è fornito dal repository AppStream oppure da moduli e repository aggiuntivi abilitabili con dnf. Prima di forzare installazioni esterne, conviene vedere cosa offre il sistema.

Il primo passo è cercare i pacchetti:

sudo dnf search ansible
sudo dnf info ansible-core ansible

Se i pacchetti sono disponibili, installo il minimo utile. In genere per lavorare in modo pratico bastano ansible-core e gli eventuali collezionamenti aggiuntivi li valuto dopo. Se invece il pacchetto ansible completo è presente e allineato alle esigenze operative, posso usare quello, ma non è obbligatorio.

sudo dnf install -y ansible-core

Dopo l’installazione verifico subito la versione e il path effettivo del binario:

ansible --version
which ansible

Mi aspetto un output coerente con il pacchetto installato e un binario in un path standard, tipicamente /usr/bin/ansible. Se il comando non viene trovato, il problema non è Ansible ma il PATH o l’installazione non completata correttamente.

Repo aggiuntivi: quando servono e quando evitarli

Il punto non è “da dove installo Ansible”, ma quanto controllo voglio sul ciclo di aggiornamento. I repository ufficiali di distro sono più conservativi e riducono il rischio di rotture improvvise. Repository esterni o installazioni via pip hanno senso solo se serve una versione specifica o una collezione di moduli non disponibile nei canali standard.

Se il pacchetto non è disponibile nel repository base, controllo i repository abilitati e la presenza di eventuali moduli:

sudo dnf module list ansible
sudo dnf repolist --enabled

Qui non conviene improvvisare. Se manca il pacchetto, prima capisco se il problema è di repository o di naming. In ambienti gestiti, una repo esterna va documentata, versionata e monitorata come qualsiasi altra dipendenza critica.

Installazione con pip: utile, ma non come prima scelta

La via con pip è comoda quando serve una versione più recente o quando il sistema deve restare isolato dai pacchetti di distro. Però va usata con disciplina: meglio un virtual environment dedicato che una installazione globale che poi entra in conflitto con i pacchetti RPM.

Creo un ambiente virtuale e installo Ansible lì dentro:

sudo dnf install -y python3 python3-pip python3-virtualenv
python3 -m venv ~/venv-ansible
source ~/venv-ansible/bin/activate
pip install --upgrade pip
pip install ansible

Verifico poi la versione dentro il virtualenv:

ansible --version
python --version

Questo approccio isola il tooling e rende più facile il rollback: basta disattivare o cancellare il virtualenv. La contropartita è che devi ricordarti di attivarlo prima di ogni sessione di lavoro oppure automatizzare l’ingresso con un alias o uno script di bootstrap.

Configurazione minima per un nodo di controllo pulito

Una volta installato Ansible, la parte importante è evitare una configurazione fragile. Il file ansible.cfg locale ti permette di fissare comportamento, inventario e gestione delle chiavi senza dipendere dal profilo dell’utente o da variabili d’ambiente lasciate a metà.

Una baseline essenziale può essere questa:

[defaults]
inventory = ./inventory
host_key_checking = True
retry_files_enabled = False
stdout_callback = yaml
interpreter_python = auto_silent

Il file va salvato come ansible.cfg nella directory del progetto. Con host_key_checking = True evito di normalizzare un comportamento insicuro solo perché “fa prima”. interpreter_python = auto_silent aiuta su sistemi remoti con Python in path non banale, senza trasformare ogni esecuzione in una caccia all’interprete.

Per l’inventario, un esempio minimale è questo:

[linux]
server1.example.net
server2.example.net

Se preferisci l’INI classico, va bene. Se il parco host cresce, il passaggio a YAML o a inventory dinamico diventa naturale, ma non serve complicare subito. Il guadagno vero in questa fase è avere una base leggibile e replicabile.

Accesso SSH: il punto che rompe più spesso i primi test

Ansible non installa agenti sui nodi remoti: si appoggia a SSH. Questo significa che l’operatività dipende dalla qualità della tua configurazione SSH, non solo da Ansible. Se il login chiave non funziona, Ansible non “aggiusta” nulla da solo.

Prima di lanciare playbook, verifico la connessione in modo diretto:

ssh server1.example.net hostname

Se questo comando fallisce, non ha senso passare ad Ansible. La chiave deve essere già distribuita e autorizzata. Per un setup amministrativo ordinato, creo una coppia di chiavi dedicata al controllo e la separo dall’account personale.

Generazione della chiave:

ssh-keygen -t ed25519 -f ~/.ssh/ansible_ed25519

Distribuzione della chiave sul nodo remoto, se consentita e in linea con la policy operativa:

ssh-copy-id -i ~/.ssh/ansible_ed25519.pub user@server1.example.net

Se ssh-copy-id non è disponibile o non è ammesso, la chiave pubblica va aggiunta manualmente nel file ~/.ssh/authorized_keys dell’utente remoto, con permessi corretti. Su sistemi con SELinux attivo, la parte dei permessi non è un dettaglio: file troppo permissivi possono bloccare l’accesso anche se la chiave è formalmente corretta.

Primo test end-to-end: ping Ansible e raccolta facts

Il test più utile non è un playbook complesso, ma un ping Ansible sul target. Serve a verificare inventario, SSH, Python remoto e parsing della configurazione locale.

Eseguo:

ansible all -m ping -i inventory

Se tutto è a posto, l’output deve restituire pong per gli host raggiungibili. Se fallisce, la priorità non è cambiare Ansible ma leggere il motivo esatto: autenticazione SSH, host non raggiungibile, interpreter missing, o Python remoto non compatibile.

Per la raccolta dei facts, che è il secondo test davvero utile, uso:

ansible all -m setup -i inventory

Qui verifico che Ansible riesca a interrogare il sistema remoto e che i dati restituiti abbiano senso. Se i facts mancano o sono parziali, spesso il problema è legato al Python remoto o a restrizioni troppo aggressive sul lato target.

Gestione di SELinux e permessi senza scorciatoie

Su CentOS 9 Stream SELinux è parte del gioco. Non va disattivato per abitudine. Di solito Ansible non richiede eccezioni particolari sul nodo di controllo, ma i target possono esporre il classico problema dei file con contesto sbagliato o dei path non accessibili dall’utente remoto.

Se un playbook che modifica file fallisce, non assumo subito che il problema sia Ansible. Controllo i log e i contesti SELinux sul target:

Comandi utili:

getenforce
ls -Z /percorso/file
sudo ausearch -m avc -ts recent

Se compare un AVC, lì c’è l’evidenza da seguire. Il fix corretto è ripristinare contesto, permessi o policy, non abbassare il livello di sicurezza del sistema solo per far passare un task.

Esempio pratico: playbook minimo per validare il setup

Dopo installazione e configurazione iniziale, il modo migliore per verificare tutto è eseguire un playbook ridotto all’osso. L’obiettivo non è fare configurazioni reali, ma confermare che il flusso completo funzioni: inventario, connessione, esecuzione, output.

---
- name: Test Ansible su CentOS 9 Stream
  hosts: all
  gather_facts: true
  tasks:
    - name: Conferma raggiungibilità
      ansible.builtin.debug:
        msg: "Host raggiunto correttamente"

Lo salvo come test.yml e lo avvio con:

ansible-playbook -i inventory test.yml

Se il playbook completa senza errori, la base è buona. Se fallisce, il vantaggio di un test così piccolo è che il dominio del problema resta stretto: non stai debuggando un’intera automazione, ma il tuo stack minimo.

Quando ha senso aggiungere collezioni e ruoli

Installare Ansible è solo il primo passo. In un ambiente reale, quasi subito arrivano collezioni e ruoli per gestire firewall, utenti, web server, database, backup e hardening. Il punto critico è non mescolare tutto in un’unica directory senza disciplina.

Una struttura minima ordinata può essere questa:

inventory, group_vars/, host_vars/, playbooks/, roles/.

Quando aggiungi collezioni, documenta la versione usata e il motivo della scelta. È il modo più semplice per evitare che un aggiornamento futuro cambi comportamento senza che nessuno capisca perché un playbook ha iniziato a fallire.

Manutenzione, aggiornamenti e rollback

Ansible sul nodo di controllo è uno strumento operativo, quindi va mantenuto come tale. Se lo hai installato da repository di sistema, gli aggiornamenti seguono la normale policy di dnf update. Se lo hai installato in un virtualenv, il rollback è più semplice: puoi ricreare l’ambiente da zero con una versione diversa e tenere separato il rischio.

Per controllare cosa è installato:

rpm -q ansible-core oppure pip show ansible, a seconda del metodo usato.

Se devi fare una modifica delicata, come passare da un’installazione RPM a una via pip, il blast radius è il nodo di controllo e tutto ciò che dipende da quel binario. Il rollback deve essere chiaro: snapshot del sistema, backup della configurazione locale, oppure ricreazione del virtualenv con i pacchetti precedenti. Non serve complicare: serve sapere prima come tornare indietro.

Checklist operativa finale

Se vuoi una verifica rapida prima di mettere Ansible in uso reale, questa sequenza è sufficiente:

1. Controllo versione sistema e Python con cat /etc/centos-release e python3 --version.
2. Installazione da repository o virtualenv dedicato, senza mescolare i due metodi.
3. Configurazione locale in ansible.cfg con inventario esplicito e host key checking attivo.
4. Verifica SSH diretta verso il target prima di usare Ansible.
5. Test con ansible all -m ping e poi con un playbook minimale.
6. Controllo di SELinux e permessi se emergono errori di accesso o scrittura.

Con questa impostazione hai un’installazione ripetibile, leggibile e facile da mantenere. La differenza tra un setup che funziona e uno che ti fa perdere tempo nei dettagli sta quasi sempre nel modo in cui hai deciso di installarlo e nel livello di ordine iniziale che hai imposto alla configurazione.