Leggere changed e ok nell'output

Dopo ogni attività, Ansible stampa uno stato per ogni host. I due più comuni sono ok e changed, e raccontano storie diverse.

Uno stato ok significa che l'host corrispondeva già allo stato desiderato. L'attività ha eseguito il controllo, ma non ha apportato alcuna modifica.

Uno stato changed significa che l'host non corrispondeva allo stato desiderato, quindi il modulo ha modificato qualcosa per portarlo allo stato dichiarato.

Per impostazione predefinita, Ansible visualizza l'output changed in giallo e l'output ok in verde. Una schermata tutta verde alla seconda esecuzione è esattamente ciò che si desidera.

Alla fine, PLAY RECAP riepiloga i conteggi per ogni host: ok, changed, unreachable e failed. È il controllo dello stato in una sola riga.

Si esegue due volte un playbook idempotente e il secondo riepilogo dovrebbe mostrare changed=0. Qualsiasi modifica durante una riesecuzione merita di essere analizzata.

Uno stato changed indica un successo, non un problema. Registra semplicemente che l'host richiedeva un intervento e che l'attività lo ha eseguito correttamente.

Si può visualizzare anche skipping, che significa che una condizione when era falsa, quindi l'attività non è stata eseguita su quell'host.

Uno stato failed significa che si è verificato un errore nell'attività; unreachable significa che Ansible non ha potuto neppure connettersi tramite SSH. Entrambi interrompono il play per quell'host.

Il conteggio di changed è il proprio indicatore di idempotenza. Se un'esecuzione ripetuta continua a segnalare modifiche, significa che un'attività non è veramente idempotente.

Si aggiunga -v (oppure -vv) a ansible-playbook per ottenere un output dettagliato che mostri esattamente cosa ha modificato ogni attività e perché.

Si legga ok come «già corretto» e changed come «appena corretto». PLAY RECAP e una seconda esecuzione con changed=0 dimostrano che il play è idempotente. ✅