Ansible e Claude Code: aggiornare server Linux

Quando i server Linux sono due o tre, aggiornarli a mano via SSH è fattibile. Quando diventano dieci, venti o più, e sono di clienti diversi, serve un metodo ripetibile: Ansible. E se ad Ansible si affianca Claude Code, scrivere, controllare e leggere gli esiti dei playbook diventa molto più veloce. In questa guida trovi l’impostazione che uso: inventario, un playbook di aggiornamento con riavvio controllato, la prova a vuoto e il ruolo, preciso e limitato, dell’intelligenza artificiale.

Perché Ansible

Ansible è uno strumento open source di automazione che non richiede agent sui server: si collega via SSH da una macchina di controllo ed esegue le operazioni descritte in file YAML chiamati playbook. Le operazioni sono pensate per essere idempotenti: rilanciarle non crea danni, perché portano il server allo stato descritto. È la base giusta per aggiornamenti, configurazioni uniformi e verifiche su molti server.

Dove sta Claude Code in tutto questo

La regola che mi do è netta: Claude Code lavora sul repository Ansible, non sui server. Scrive e corregge playbook, li controlla con ansible-lint, esegue la prova a vuoto, legge l’esito e lo riassume. L’esecuzione vera, quella che modifica i server, la lancio io. Così l’AI accelera il lavoro di scrittura e di analisi, e la decisione resta umana.

Installazione e preparazione

Sulla macchina di controllo (Linux, anche una macchina virtuale dedicata):

sudo apt install ansible ansible-lint
ansible --version

Per i server gestiti servono: un utente di servizio (per esempio ansible) con chiave SSH dedicata e sudo limitato a ciò che serve, e Python installato (di solito lo è già). La chiave privata resta sulla macchina di controllo e non entra mai nel repository.

L’inventario

Un file inventory.ini elenca i server e li raggruppa. I gruppi servono a distribuire gli aggiornamenti per gradi:

[prova]
test-01 ansible_host=192.0.2.11

[web]
web-01 ansible_host=192.0.2.21
web-02 ansible_host=192.0.2.22

[db]
db-01 ansible_host=192.0.2.31

[linux:children]
prova
web
db

[linux:vars]
ansible_user=ansible

Gli indirizzi sono di esempio. Per verificare che tutto risponda:

ansible -i inventory.ini linux -m ping

Un playbook di aggiornamento

Questo è un esempio per server Debian e Ubuntu: aggiorna l’elenco dei pacchetti, applica gli aggiornamenti, rimuove i pacchetti non più necessari e riavvia solo se serve.

---
- name: Aggiornamento dei server Linux
  hosts: linux
  become: true
  serial: 1                 # un server alla volta
  max_fail_percentage: 0    # al primo errore ci si ferma
  tasks:
    - name: Aggiorna l'elenco dei pacchetti
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Applica gli aggiornamenti
      ansible.builtin.apt:
        upgrade: dist

    - name: Rimuove i pacchetti non più necessari
      ansible.builtin.apt:
        autoremove: true

    - name: Controlla se serve il riavvio
      ansible.builtin.stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Riavvia se necessario
      ansible.builtin.reboot:
        reboot_timeout: 600
      when: reboot_required.stat.exists

Per le distribuzioni della famiglia Red Hat (AlmaLinux, Rocky Linux) si usa il modulo ansible.builtin.dnf al posto di apt. I due punti da notare sono serial: 1, che aggiorna un server alla volta, e max_fail_percentage: 0, che interrompe tutto se uno solo fallisce: un aggiornamento difettoso non si propaga a tutta la flotta.

Prima la prova a vuoto

La modalità --check simula l’esecuzione senza modificare i server, e --diff mostra le differenze:

ansible-playbook -i inventory.ini aggiorna.yml --check --diff --limit prova

Ricorda che alcune operazioni (per esempio il riavvio) in modalità di prova non vengono eseguite davvero, quindi la prova a vuoto è un controllo di coerenza, non una garanzia. L’esecuzione reale parte dal gruppo di prova e solo dopo si estende agli altri:

ansible-playbook -i inventory.ini aggiorna.yml --limit prova
ansible-playbook -i inventory.ini aggiorna.yml --limit web
ansible-playbook -i inventory.ini aggiorna.yml --limit db

Prima di aggiornare server importanti: snapshot o backup recente, una finestra di manutenzione concordata e la certezza di poter tornare indietro.

Il CLAUDE.md del repository

Nella radice del repository Ansible scrivo le regole per Claude Code:

# Repository Ansible - aggiornamento server
- Claude Code lavora SOLO sui file del repository. Non si collega ai server.
- Puoi eseguire: ansible-lint, ansible-playbook con --check e --syntax-check,
  ansible-inventory --list.
- NON eseguire ansible-playbook senza --check: l'esecuzione reale la lancia Paolo.
- Non leggere né stampare file con segreti: vault.yml, *.pem, chiavi SSH.
- Ogni playbook deve avere: serial, max_fail_percentage e commenti in italiano.
- Segreti solo con ansible-vault, mai in chiaro.

E nei permessi (.claude/settings.json) lascio il comando libero solo in lettura e nego i file riservati:

{
  "permissions": {
    "allow": ["Bash(ansible-lint:*)", "Bash(ansible-inventory:*)"],
    "deny": ["Read(./vault.yml)", "Read(~/.ssh/**)", "Bash(ansible-vault:*)"]
  }
}

La sintassi delle regole va verificata nella documentazione della versione che usi. Il comando ansible-playbook resta fuori dall’elenco dei permessi automatici, così Claude Code chiede conferma ogni volta e io posso rifiutare tutto ciò che non sia una prova a vuoto.

Cosa chiedere a Claude Code

Scrivere il playbook a partire da una descrizione: «aggiorna i server, riavvia solo se serve, un server alla volta, fermati al primo errore».
Controllare un playbook esistente: ansible-lint segnala problemi e Claude Code propone la correzione e ne spiega il motivo.
Adattare il playbook a distribuzioni diverse, con condizioni su ansible_facts['os_family'].
Leggere l’esito di un’esecuzione lunga: passargli l’output e chiedere un riassunto per server (aggiornato, riavviato, fallito, motivo).

ansible-playbook -i inventory.ini aggiorna.yml --check --diff --limit web 2>&1 \
  | claude -p "Riassumi per server cosa verrebbe modificato e segnala qualunque anomalia"

Un’idea in più: il rapporto sullo stato dei server

Un playbook di sola lettura che raccoglie versione del sistema, pacchetti da aggiornare e necessità di riavvio su tutti i server produce un quadro d’insieme. Passato a Claude Code, diventa un rapporto ordinato: quali server sono indietro, quali hanno aggiornamenti di sicurezza in attesa, quali richiedono un riavvio. È un buon punto di partenza per pianificare le finestre di manutenzione.

Gli aggiornamenti automatici bastano?

Su Debian e Ubuntu esiste unattended-upgrades, che installa da solo gli aggiornamenti di sicurezza: è utile e lo consiglio come base. Ansible serve a ciò che viene dopo: aggiornamenti completi, riavvii ordinati, verifica che tutti i server siano allineati e un registro di cosa è stato fatto e quando. Le due soluzioni si completano.

Attenzioni

Mai segreti in chiaro: password e token vanno in ansible-vault e fuori dal repository pubblico.
Dati personali: l’output dei playbook può contenere nomi di host, indirizzi IP e nomi utente. Prima di passarlo a Claude Code, ripulisci o anonimizza ciò che riguarda i clienti.
Servizi delicati: database, cluster e server con applicazioni particolari richiedono procedure su misura (arresto ordinato, controllo della replica) e non vanno aggiornati a ciclo cieco.
Verifica sempre: il codice generato dall’AI va letto e provato su una macchina di prova prima di toccare la produzione.

In sintesi

Ansible rende gli aggiornamenti ripetibili, Claude Code li rende più rapidi da scrivere e da leggere, e le regole (repository separato, prova a vuoto, un server alla volta, esecuzione reale decisa da una persona) tengono il rischio sotto controllo. Per il controllo di sicurezza di un singolo server leggi anche Claude Code per il controllo di sicurezza di un server Linux. Se gestisci più sistemi e vuoi un aiuto per impostare questo metodo, qui trovi come lavoriamo con Claude Code e qui l’area di amministrazione dei sistemi.