Ansible Deploy — Automatizzare Configurazione Server e Deployment • Meteora Web Agency

Sei stanco di connetterti via SSH per aggiornare nginx, ricaricare PHP-FPM o copiare i file aggiornati sul server? Ogni volta è un copia-incolla di comandi, un errore umano in agguato, un'ora di lavoro che non fatturi. Il problema non è la singola operazione: è che la ripeti. E ripetere manualmente significa spendere tempo, sbagliare su un server e non accorgertene, riscoprire il 3 del mattino che la configurazione è andata in produzione senza un backup. Esiste un modo diverso: scrivere la configurazione una volta sola, come codice, e farla applicare ovunque, nello stesso identico modo.

Noi, di Meteora Web, lavoriamo con questa filosofia dal 2017. Quando un cliente ha tre server o dieci, non ci fidiamo della memoria. Scriviamo un playbook Ansible, lo versioniamo su git e diciamo al sistema: applica questa configurazione, verificando che tutto sia come ci aspettiamo. Nel 2026, farlo a mano non è solo inefficiente: è un rischio.

Cos'è Ansible e perché si chiama configurazione come codice?

Ansible è un motore di automazione IT che descrive lo stato desiderato dei tuoi server in file di testo. Tu non gli dici "esegui questo comando e speriamo che funzioni". Gli dici "questo server deve avere nginx installato, la porta 80 aperta, PHP 8.3 attivo". Ansible capisce cosa fare, connessione dopo connessione.

La differenza fondamentale rispetto agli script bash è che Ansible è dichiarativo e idempotente. Dichiarativo: descrivi il risultato, non i passaggi. Idempotente: eseguire lo stesso playbook cento volte produce lo stesso risultato. Se la configurazione è già corretta, Ansible non tocca nulla. Se è sbagliata, la corregge. Uno script bash, al contrario, esegue tutto ogni volta: se un pacchetto è già installato, lo reinstalla; se un file esiste, lo sovrascrive a caso. Con Ansible, il server converge verso lo stato dichiarato. Niente più derive di configurazione.

Perché Ansible è lo strumento giusto per le PMI italiane?

Perché non richiede un agente installato sui server. Usa SSH, che già conosci. Non serve una infrastruttura dedicata: basta un computer con Python e SSH per controllare tutti i server. E la curva di apprendimento è più dolce rispetto ad alternative come Puppet o Chef. In pratica, Ansible è il modo più rapido per passare dal caos "configuro tutto a mano" a una gestione professionale.

Noi, di Meteora Web, lo usiamo per configurercentinaia di server in tutta Italia, dal negozio di abbigliamento al professionista con un portale a catalogo. Il risultato è sempre lo stesso: meno errori, più tempo per il lavoro che aggiunge valore.

Azione immediata: installa Ansible sul tuo computer. Su Linux o macOS, apri il terminale e digita sudo apt install ansible (Debian/Ubuntu) o brew install ansible (macOS). Su Windows, usa WSL2 con una distro Ubuntu. Dopo l'installazione, verifica con ansible --version.

Come funziona Ansible senza agente?

Ansible funziona in modalità push. La macchina dove lo esegui (il controllo) spinge i comandi verso i server target (i nodi) attraverso SSH. Non installi nulla sul server remoto. Questo è un vantaggio enorme rispetto ad altre soluzioni: niente porte aggiuntive da aprire, niente servizi extra da proteggere, niente agenti da aggiornare.

Sul tuo computer, Ansible gira in Python e usa moduli predefiniti per fare quasi tutto: installare pacchetti (apt, yum, dnf), copiare file (copy, template), gestire servizi (service, systemd), eseguire comandi (command, shell). Quando lanci un playbook, Ansible controlla lo stato corrente del server per ogni task e decide se deve agire o se è già tutto a posto.

Questa scelta è anche una questione di sicurezza. Avendo meno superficie esposta, un server gestito con Ansible è più facile da mantenere e da monitorare. E per chi, come noi, si occupa di sicurezza informatica, sapere che non ci sono agenti sparsi sulle macchine dei clienti è un sospiro di sollievo.

Il file di inventario: dove dici ad Ansible chi gestire

L'inventario è un semplice file INI o YAML che elenca i server e le loro variabili. Ecco un esempio minimo di inventario hosts.ini:

[web]
web1.example.com ansible_host=192.168.1.10
web2.example.com ansible_host=192.168.1.11

[db]
db1.example.com ansible_host=192.168.1.20

[web] e [db] sono gruppi. Puoi lanciare un playbook solo su un gruppo, mettendo ordine nel caos. In produzione, gestiamo inventari che cambiano dinamicamente, ma per iniziare va benissimo un file statico. Ricorda di impostare le variabili positive di connessione, ad esempio ansible_user=deploy e ansible_ssh_private_key_file=/path/to/key.

Differenza con uno script shell: uno script shell è una sequenza imperativa di comandi che non sa cosa è già stato fatto. Ansible descrive lo stato finale e lo applica. Non è una sottigliezza: è il motivo per cui non rompi la produzione eseguendo un playbook due volte.

Azione immediata: crea un file hosts.ini con i tuoi server. Poi testa la connessione con ansible all -i hosts.ini -m ping --user tuo-utente. Il comando ping non è il classico ping ICMP: usa un modulo Python per verificare che SSH funzioni e che il server risponda.

Come scrivere un playbook Ansible per il deploy?

Il playbook è il cuore di Ansible. È un file YAML che contiene una lista di play. Ogni play definisce su quali server agire e quali task eseguire. Ecco un playbook minimo per configurare nginx e un'applicazione PHP su un server:

---
- name: Configura web server per la mia app
  hosts: web
  become: yes
  vars:
    domain: esempio.it
    php_version: "8.3"

  tasks:
    - name: Aggiorna cache apt
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Installa nginx e PHP-FPM
      apt:
        name:
          - nginx
          - php{{ php_version }}-fpm
        state: present

    - name: Avvia e abilita nginx
      service:
        name: nginx
        state: started
        enabled: yes

    - name: Copia la configurazione del virtual host
      template:
        src: templates/vhost.conf.j2
        dest: /etc/nginx/sites-available/{{ domain }}
      notify: reload nginx

    - name: Abilita il virtual host
      file:
        src: /etc/nginx/sites-available/{{ domain }}
        dest: /etc/nginx/sites-enabled/{{ domain }}
        state: link
      notify: reload nginx

    - name: Copia i file dell'applicazione
      synchronize:
        src: ./app/
        dest: /var/www/{{ domain }}
        delete: yes

  handlers:
    - name: reload nginx
      service:
        name: nginx
        state: reloaded

Cosa succede qui? Ogni task è dichiarato in modo esplicito. Se il virtual host non è ancora configurato, viene creato e nginx viene ricaricato. Se la configurazione è identica, il playbook non fa nulla e termina con ok=5 invece di changed=5. Questo è il concetto di idempotenza: il risultato è sempre lo stato desiderato, con il minimo intervento.

La riga notify: reload nginx è un gestore (handler). Ansible lo esegue solo se il task precedente ha effettivamente cambiato qualcosa. Non si ricarica nginx ogni volta, ma solo quando serve. Un altro dettaglio che evita di far andare giù il server per un cambio di file innocuo.

Template Jinja2 per configurazioni dinamiche

Ansible integra Jinja2 per generare file di configurazione dinamici. Il virtual host di nginx del playbook precedente può essere un template vhost.conf.j2:

server {
    listen 80;
    server_name {{ domain }};
    root /var/www/{{ domain }};
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php{{ php_version }}-fpm.sock;
    }
}

Le variabili tra doppie graffe vengono sostituite con i valori definiti nel playbook. Così lo stesso template funziona per più siti sullo stesso server, senza duplicare file. Se devi aggiungere un dominio, basta cambiare una riga nel playbook.

Azione immediata: prendi un server di test, crea un playbook con almeno due task: installare nginx e creare una pagina index.html personalizzata. Eseguilo con ansible-playbook -i hosts.ini playbook.yml e verifica con un browser. Poi, eseguilo di nuovo e guarda l'output: i task risulteranno ok e non changed.

Ansible deploy funziona davvero per applicazioni web reali?

Il deploy manuale di un'applicazione web è la fonte di errori più frequente che vediamo nei progetti che ci arrivano. File caricati via FTP in un orario che non sai, codice in produzione che non combacia con quello in test, dipendenze installate a caso. Ansible risolve anche questo, non solo la configurazione di sistema.

Ecco come impostiamo noi, di Meteora Web, il deploy di una qualsiasi applicazione Laravel, il framework che usiamo per le piattaforme proprietarie dei clienti:


- name: Deploy applicazione Laravel
  hosts: web
  become: yes
  vars:
    deploy_dir: /var/www/mio-sito
    repo_url: git@github.com:cliente/repo.git

  tasks:
    - name: Naviga nella directory di deploy
      git:
        repo: "{{ repo_url }}"
        dest: "{{ deploy_dir }}"
        version: main
        update: yes
        force: yes

    - name: Installa dipendenze PHP con Composer
      composer:
        command: install
        working_dir: "{{ deploy_dir }}"
        no_dev: yes
        arguments: "--optimize-autoloader"

    - name: Esegui le migration del database
      command: php artisan migrate --force
      args:
        chdir: "{{ deploy_dir }}"

    - name: Ottimizza la cache di Laravel
      command:
        cmd: php artisan optimize
        chdir: "{{ deploy_dir }}"

    - name: Imposta i permessi corretti
      file:
        path: "{{ deploy_dir }}/storage"
        owner: www-data
        group: www-data
        recurse: yes

Il modulo git di Ansible gestisce il clone e il fetch del repository. Il modulo composer è un wrapper per Composer. I comandi di Laravel vengono eseguiti solo se necessario, perché Ansible controlla l'uscita del comando e agisce di conseguenza.

Una buona pratica è usare due directory e un symlink per il deploy zero-downtime. La struttura è questa:

/var/www/app/current -> release_20260101_1100
/var/www/app/releases/release_20260101_1100
/var/www/app/releases/release_20251228_0900

Ansible crea una nuova release, aggiorna il symlink current e attiva il nuovo codice. Se qualcosa va storto, il symlink viene ripristinato alla vecchia release. Il deploy torna indietro in pochi secondi, senza ripristinare backup da mezze notti.

Azione immediata: se usi Laravel, trasformalo nel tuo playbook personale. Inizia clonando il repository in una directory temporanea, poi sposta i file in produzione e infine esegui il comando php artisan migrate manualmente. Una volta che sei sicuro del risultato, automatizza ogni passaggio in Ansible.

Quanto tempo risparmia un playbook Ansible rispetto a un deploy manuale?

Prendiamo un esempio concreto. Un cliente di Meteora Web gestisce un server con nginx, PHP-FPM, la sua applicazione Laravel e un lavoro cron per le code. Ogni settimana, lo sviluppatore (o il titolare) si connette al server e lancia circa 15 comandi in ordine preciso: git pull, composer install, php artisan migrate, php artisan cache:clear, il reload di PHP-FPM, ecc. Un errore di battitura su un comando può mandare in errore il sito per ore. Con Ansible, lo stesso processo è ridotto a una riga da terminale:

ansible-playbook -i hosts.ini deploy.yml

Tempo per eseguire il deploy manuale: da 20 a 45 minuti, più la verifica del risultato. Tempo con Ansible: meno di 2 minuti, con verifica automatica dello stato di ogni task. Se moltiplichi per 4 deploy al mese, sono circa 3 ore risparmiate. Se per un progetto servono due server, Ansible li aggiorna in parallelo, non in sequenza.

E il tempo non è l'unico vantaggio. Gli errori umani spariscono. La configurazione è documentata nel playbook, non nella testa di chi l'ha fatta. Quando il collega che ha scritto il playbook è in ferie, un altro membro del team può capire il sistema leggendo il codice. Questo vale più di mille pagine di documentazione.

Anche il lavoro di configurazione del server paga. A mano, ci vogliono ore per installare tutti i pacchetti, gestire i permessi, configurare i firewall. Con Ansible, lo stesso server è pronto in 10 minuti. E se devi riprodurre un ambiente identico in staging, non parti da zero: lanci lo stesso playbook su una nuova macchina.

Azione immediata: cronometra quanto tempo impieghi a fare un deploy manuale. Scrivilo su un post-it. La prossima volta che automatizzi, confronta il tempo del playbook. La differenza è il tuo guadagno in ore fatturabili.

Ansible Tower, AWX e le alternative: cosa serve davvero?

Quando i playbook crescono e i server diventano decine, serve un'interfaccia centralizzata. Ansible Tower (la versione commerciale) e AWX (la versione open source) sono pannelli web che aggiungono funzioni di programmazione, ruoli utente e log storico. Consentono di lanciare i playbook da una console, senza dover tenere il computer con il terminale aperto.

Noi, di Meteora Web, consigliamo di iniziare senza. Prima impara a usare la riga di comando: risolvere un errore in un playbook richiede la comprensione di cosa c'è sotto. Un'interfaccia web nasconde i dettagli dello stack e, se non capisci il log, non risolvi il problema. Aggiungi AWX quando hai 3 server o più e hai bisogno di una visione unica dei job. Una soluzione intermedia è usare GitHub Actions o GitLab CI per lanciare Ansible da una pipeline, ma è un argomento che tocca la CI/CD nel suo complesso, non solo Ansible.

Per le PMI italiane, una buona regola è: prima metti ordine con i playbook, poi pensa agli strumenti aggiuntivi. Il valore non sta nel pannello di controllo, ma nella qualità dei playbook. Un playbook scritto bene si gestisce anche da terminale.

Azione immediata: se non hai ancora una pipeline CI/CD, non complicarti la vita. Lancia Ansible dal tuo computer con un alias nel .bashrc o .zshrc. Memorizza il comando e inizierai a essere automatico con il processare.

Cosa fare adesso

Hai letto abbastanza. Il prossimo deploy che fai a mano è un'occasione persa. Ecco le azioni da mettere in pratica per il tuo prossimo progetto:

Installa Ansible sul tuo computer e crea un inventario con almeno un server di test. Non serve un server in produzione per imparare.
Scrivi un primo playbook che installi nginx e crei una pagina index.html. Eseguilo due volte: la seconda esecuzione deve concludersi con ok e nessun changed.
Riproduci il tuo ultimo deploy manuale in un playbook. Non importa se all'inizio il playbook non è perfetto. Il solo fatto di scrivere i passaggi in un file YAML ti costringe a capire davvero cosa fai.
Rispetta i principi che rendono Ansible potente: idempotenza, gestione dei gestori e template. Se un task forza sempre un aggiornamento, stai facendo male Ansible.
Leggi la documentazione ufficiale quando hai un dubbio: Ansible Documentation (IT) e Ansible Documentation (EN). È la fonte autorevole, non i tutorial in prima pagina.

Questo è anche l'approccio che portiamo avanti in Meteora Web. Abbiamo visto aziende usare Ansible con 50 server gestiti in modo impeccabile e aziende con un solo server configurato a mano maldestramente. La differenza non è la dimensione, ma la professionalità del processo. Se vuoi approfondire come Ansible si inserisce nell'infrastruttura completa, leggi la nostra guida su DevOps e CI/CD. E per chi deve difendersi dagli errori, la nostra guida sulla network forensics con Wireshark mostra come monitorare il traffico quando le cose non vanno come dovrebbero.