Capitolo 3 – Configurazione Iniziale dell’Ambiente di Lavoro

Dopo aver compreso architettura e componenti, il passo successivo è impostare correttamente l’ambiente operativo.
In ambito sysadmin è fondamentale non lavorare in modo disordinato.
Una struttura chiara permette scalabilità, manutenzione e integrazione con Git.
3.1 Non lavorare in /etc/ansible
Ansible può utilizzare:
/etc/ansible/ansible.cfg
/etc/ansible/hosts
Tuttavia, in ambienti professionali è sconsigliato lavorare direttamente lì.
Motivi:
Difficoltà di versionamento
Configurazione globale poco flessibile
Problemi in ambienti multi-progetto
Best practice: creare una directory progetto dedicata.
3.2 Creazione Struttura Base Progetto
Esempio struttura iniziale:
mkdir -p ~/ansible/{inventory,playbooks,roles,group_vars,host_vars}
cd ~/ansible
Struttura consigliata:
ansible/
├── ansible.cfg
├── inventory/
│   ├── production
│   ├── staging
│   └── dev
├── playbooks/
├── roles/
├── group_vars/
└── host_vars/
Descrizione:
ansible.cfg → configurazione locale del progetto
inventory/ → separazione ambienti
playbooks/ → file operativi
roles/ → componenti modulari
group_vars/ → variabili per gruppi
host_vars/ → variabili per host specifici
Questa struttura è scalabile e adatta a infrastrutture reali.
3.3 Creazione del File ansible.cfg Locale
Creare un file 
ansible.cfg nella root del progetto:
[defaults]
inventory = ./inventory/production
remote_user = ansible
host_key_checking = False
retry_files_enabled = False
roles_path = ./roles
forks = 10
timeout = 30
[privilege_escalation]
become = True
become_method = sudo
become_ask_pass = False
Spiegazione Parametri Principali
inventory
Percorso dell’inventory di default.
remote_user
Utente SSH utilizzato per la connessione.
host_key_checking
Se disabilitato evita prompt interattivi (valutare in produzione).
retry_files_enabled
Disabilita la creazione di file .retry.
roles_path
Percorso locale dei ruoli.
forks
Numero di host gestiti in parallelo.
become
Abilita automaticamente l’escalation privilegi.
3.4 Ordine di Precedenza del File di Configurazione
Ansible legge il file di configurazione in questo ordine:
Variabile ambiente ANSIBLE_CONFIG
ansible.cfg nella directory corrente
~/.ansible.cfg
/etc/ansible/ansible.cfg
Questo significa che il file locale nel progetto ha priorità rispetto a quello globale.
Verifica configurazione attiva:
ansible-config view
3.5 Configurazione SSH Corretta
Prerequisito fondamentale: accesso SSH senza password.
Generazione chiave (se non esiste):
ssh-keygen -t ed25519
Copia chiave sui nodi remoti:
ssh-copy-id ansible@server
Test connessione:
ssh ansible@server
Best practice:
Non usare root diretto
Creare utente dedicato (es. ansible)
Consentire sudo controllato
3.6 Verifica Connessione con Ansible
Prima di scrivere playbook, verificare la connettività.
Esempio:
ansible all -m ping
Output atteso:
SUCCESS
Nessun errore SSH
Nessun errore Python
Se compare errore Python, verificare presenza di python3 sul nodo remoto.
3.7 Preparazione per Ambienti Multipli
Separare ambienti evita errori critici.
Esempio:
inventory/
├── production
├── staging
└── dev
Esecuzione su staging:
ansible-playbook -i inventory/staging playbooks/site.yml
Non mescolare mai produzione e ambienti di test nello stesso inventory.
Conclusione
Una corretta configurazione iniziale è fondamentale per:
Scalabilità
Sicurezza
Manutenibilità
Integrazione con controllo versione
Nel prossimo capitolo entreremo nel dettaglio dell’Inventory: sintassi, gruppi, variabili e struttura professionale.