Come installare Ansible su Rocky Linux 8 e AlmaLinux

Perché su Rocky Linux 8 e AlmaLinux conviene partire da EPEL

Su Rocky Linux 8 e AlmaLinux la strada più pulita per installare Ansible è usare i repository ufficiali della distribuzione insieme a EPEL. Non è la sola opzione, ma è quella che riduce attriti, mantiene il sistema allineato con il ciclo di aggiornamenti della piattaforma e evita di tirarsi dentro dipendenze strane o versioni non coerenti con il resto dell’ambiente.

Il punto pratico è semplice: Ansible non è un demone da avviare sul server target, ma un tool di automazione che gira sulla macchina di controllo. Quindi l’installazione corretta non riguarda solo il pacchetto in sé, ma anche la verifica di Python, dei moduli di rete e del fatto che il sistema possa raggiungere le macchine gestite via SSH senza inventarsi scorciatoie.

Su Rocky 8 e AlmaLinux 8 il requisito minimo è avere accesso amministrativo, una connessione Internet per abilitare i repository necessari e una shell con privilegi sudo. Se il nodo è in una rete chiusa, il discorso cambia: bisogna predisporre mirror interni o repository locali, altrimenti il pacchetto non si risolve e si finisce a inseguire errori di metadata invece del problema vero.

Verifica preliminare del sistema

Prima di installare, conviene capire esattamente su quale release stai lavorando e se i repository base sono sani. È un controllo banale, ma in pratica evita metà dei casi in cui l’installazione fallisce per problemi di mirror, DNS o repository disabilitati.

Esegui questi controlli:

cat /etc/redhat-release
uname -r
dnf repolist

Il primo comando conferma la distribuzione, il secondo ti dice quale kernel stai usando, il terzo elenca i repository attivi. Se `dnf repolist` mostra pochi repo o errori di metadata, non ha senso correre subito a installare Ansible: prima va sistemata la connettività verso i mirror o la configurazione dei repository.

Se il sistema è appena stato provisionato, verifica anche che l’orologio sia corretto. Errori TLS su repository HTTPS o su eventuali mirror interni spesso nascono da una data sballata, non da un problema del pacchetto.

timedatectl status

Installazione di EPEL e Ansible

Su Rocky Linux 8 e AlmaLinux 8, il pacchetto Ansible si trova normalmente in EPEL. La sequenza corretta è: aggiornare la cache, installare il repository EPEL, poi installare Ansible. Fare tutto in un colpo solo è possibile, ma separare i passaggi rende il troubleshooting più leggibile.

Comandi consigliati:

sudo dnf makecache
sudo dnf install -y epel-release
sudo dnf install -y ansible

Se il sistema è appena uscito da una reinstallazione o da una clonazione, può essere utile aggiornare prima i pacchetti base:

sudo dnf update -y

Non è obbligatorio per installare Ansible, ma riduce il rischio di conflitti con librerie vecchie o con un `python3` non allineato. In ambienti di produzione, però, un update globale va trattato come change controllato: meglio farlo in finestra e con rollback chiaro, non a caso.

Dopo l’installazione, verifica subito la versione:

ansible --version

Il comando deve restituire la versione di Ansible, il percorso del binario e l’interprete Python usato. Questo dettaglio conta: se il binario punta a un Python non previsto, potresti trovarti moduli che si comportano in modo diverso da un host all’altro.

Controllare che il modulo Python sia quello giusto

Ansible su RHEL-like recenti vive bene con Python 3, ma non bisogna dare per scontato che il sistema stia usando l’interprete atteso. Su Rocky e Alma 8, il pacchetto di sistema è allineato a Python 3, però in ambienti personalizzati o con repository terzi possono comparire conflitti.

Per vedere quale interprete viene usato:

python3 --version
which python3
rpm -q python3

Se `ansible --version` mostra un percorso Python incoerente con quello del sistema, non forzare subito modifiche invasive. Prima verifica se esiste un `alternatives` alterato o un virtual environment attivo. In molti casi il problema è semplicemente una shell con PATH sporco.

Per controllare il binario effettivo di Ansible:

which ansible
rpm -qf $(which ansible)

Prima prova operativa: inventario locale e localhost

Installare il pacchetto è solo metà del lavoro. Il test utile è far girare un playbook minimo contro `localhost`, perché ti dice se il tool funziona, se Python è accessibile e se i moduli base si caricano senza errori.

Crea un inventario minimale:

cat > inventory.ini <<'EOF'
localhost ansible_connection=local
EOF

Poi lancia un ping di verifica:

ansible -i inventory.ini all -m ping

Il risultato atteso è un `SUCCESS` con `pong`. Se ottieni un errore sul modulo Python o sulla connessione locale, il problema non è Ansible in sé ma l’ambiente del nodo. In quel caso controlla `python3`, permessi, PATH e presenza dei pacchetti base.

Se vuoi un test ancora più esplicito, usa il modulo `setup`, che raccoglie facts di sistema:

ansible -i inventory.ini localhost -m setup

È utile perché mostra se il discovery dell’ambiente funziona e se i facts vengono raccolti senza blocchi lato Python o SELinux.

Gestione di un inventario reale

In un ambiente vero, non ti basta `localhost`. Devi definire host, gruppi e variabili in modo leggibile. La scelta più semplice resta un file `ini` o `yaml`, ma il criterio non è estetico: conta la manutenibilità. Se l’inventario cresce, il formato YAML tende a essere più chiaro per chi lo eredita dopo di te.

Esempio minimale in formato INI:

[web]
web01 ansible_host=192.0.2.10
web02 ansible_host=192.0.2.11 [db]
db01 ansible_host=192.0.2.20

Se vuoi evitare di ripetere parametri comuni, puoi usare variabili di gruppo:

[web:vars]
ansible_user=deploy
ansible_port=22

Meglio ancora, quando il numero di host cresce, separa inventario e variabili in directory strutturate. Così riduci il rischio di fare modifiche manuali su un singolo file enorme e di introdurre errori difficili da scovare.

SSH: il vero prerequisito operativo

Ansible non sostituisce SSH, lo usa. Quindi se la connessione verso gli host remoti non è già pulita, il problema si presenta subito. Prima di giocare con playbook e ruoli, verifica che il login SSH funzioni senza password o con il metodo previsto dalla tua policy.

Test rapido:

ssh deploy@192.0.2.10

Se usi chiavi, controlla che la chiave privata sia protetta e che i permessi siano corretti. Un errore classico è avere chiavi con permessi troppo aperti, che OpenSSH rifiuta senza troppe spiegazioni utili.

ls -l ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Se la connessione richiede un utente diverso da quello corrente, specificarlo in inventario o in `ansible.cfg` è più pulito che passarlo ogni volta da riga di comando. La riga di comando va bene per i test, non come configurazione permanente.

Configurazione minima di ansible.cfg

Un file `ansible.cfg` locale nel progetto aiuta a evitare ambiguità. È meglio tenerlo vicino all’inventario o al repository dei playbook, in modo che chiunque lavori sul progetto usi gli stessi default.

Esempio essenziale:

[defaults]
inventory = ./inventory.ini
host_key_checking = True
interpreter_python = auto
retry_files_enabled = False

`interpreter_python = auto` è una scelta sensata su Rocky 8 e Alma 8 perché lascia ad Ansible la gestione dell’interprete remoto senza forzare path rigidi. `host_key_checking = True` è la scelta corretta in ambienti seri: disattivarlo può far comodo in fase di laboratorio, ma in produzione è una semplificazione che paghi dopo.

Se usi repository Git per i playbook, aggiungi `ansible.cfg`, inventari e ruoli nel versioning. Evita invece di committare chiavi private, token o password in chiaro. Le credenziali vanno gestite con vault, segreti di pipeline o un secret manager esterno.

Quando il pacchetto non si trova

Capita spesso di vedere errori del tipo “No match for argument: ansible”. In quel caso le cause probabili sono poche: EPEL non è abilitato, la cache DNF è vecchia, il sistema non raggiunge i mirror, oppure stai lavorando su un host con repository aziendali che filtrano i pacchetti.

La sequenza di diagnosi più rapida è questa:

1. Verifica che EPEL sia installato con rpm -q epel-release.
2. Controlla i repository attivi con dnf repolist.
3. Pulisci la cache metadati con sudo dnf clean all e rigenera con sudo dnf makecache.
4. Riprova l’installazione con sudo dnf install -y ansible.

Se la macchina è dietro proxy, il problema può essere il proxy stesso. In quel caso non serve cambiare Ansible: bisogna sistemare la configurazione DNF o il proxy di rete, altrimenti ogni installazione rimane bloccata allo stesso punto.

Aggiornare Ansible senza rompere l’ambiente

Quando Ansible è già installato, l’aggiornamento va trattato come un change normale. Prima controlli la versione attuale, poi verifichi se il repository disponibile offre la release attesa, infine aggiorni e testi di nuovo il comportamento base.

Controlli utili:

ansible --version
sudo dnf info ansible

Se devi fissare una versione specifica, è meglio farlo con cautela. Bloccare il pacchetto può avere senso in ambienti controllati, ma va accompagnato da una policy chiara di aggiornamento, altrimenti ti ritrovi con un tool fermo mentre il resto del sistema evolve.

Per verificare eventuali pacchetti bloccati:

sudo dnf versionlock list

Se il tuo ambiente usa version lock, documenta il motivo e il criterio di revisione. Non è un dettaglio amministrativo: in pratica è ciò che evita di ritardare correzioni di sicurezza o bugfix importanti.

Uso di pip: quando ha senso e quando no

Installare Ansible con `pip` invece che con DNF può avere senso in casi specifici: test di versioni nuove, ambienti isolati, necessità di un’uscita più recente di quella del repository. Ma su Rocky 8 e AlmaLinux 8, per l’uso ordinario, il pacchetto di sistema resta la scelta più lineare.

Il rischio del `pip install ansible` è creare un doppio binario, uno di sistema e uno in un virtual environment, con risultati non sempre prevedibili. Se scegli `pip`, fallo in modo esplicito, documentato e confinato. Non mescolare i due approcci nello stesso host senza una ragione concreta.

Per capire da dove arriva il comando che stai usando:

which ansible
python3 -m pip show ansible

Se il comando non corrisponde a quello che ti aspetti, correggi il PATH o il virtual environment prima di procedere. In caso contrario rischi di testare una versione diversa da quella che pensi di avere installato.

Check finale prima di usare Ansible in produzione

Prima di considerare conclusa l’installazione, fai una verifica minima su tre livelli: binario, connessione locale e connessione remota. Se questi tre passano, il setup di base è sano e puoi passare ai playbook veri.

1. Binario: ansible --version deve mostrare una versione coerente con i repository usati.
2. Locale: ansible -i inventory.ini all -m ping deve rispondere con pong su localhost.
3. Remoto: ansible -i inventory.ini web -m ping deve raggiungere gli host target senza errori di SSH o Python.

Se uno di questi passaggi fallisce, non saltare direttamente a modifiche complesse. Prima identifica il layer: repository, pacchetto, Python, SSH o inventario. Quasi sempre il problema è più vicino alla configurazione di base che al tool in sé.

In sintesi operativa: su Rocky Linux 8 e AlmaLinux installi Ansible da EPEL, verifichi subito la versione, confermi il comportamento locale e solo dopo passi agli host remoti. È un percorso semplice, ma è anche quello che ti evita di scoprire i problemi quando ormai hai già affidato ad Ansible il primo change importante.