Perché i file di configurazione non devono essere modificati linea per riga con Chef/Puppet?

Question

Perché il cambio di linea nel file di configurazione è considerato un anti-pattern in Chef o Marionetta? È una cattiva abitudine, come ho capito. Presumo che questo editing di file avvenga in modo idempotente e con strumenti avanzati (ad esempio, ad esempio).

Perché la distribuzione dell'intero file, con i modelli ERB, è considerata un metodo preferito?

È possibile trovare molti esempi in cui gli sviluppatori stanno suggerendo l'uso di modelli anziché di modifica dei file. Per esempio here, here, here, ecc

Answer 1

In termini di impostazione del sistema a uno stato noto, distribuzione di file intere è meglio di editing, perché si è certi che il file è esattamente come previsto quando si è fatto.

Se stai cercando soluzioni potenziali a un problema e modifica manualmente alcuni file di configurazione, non devi preoccuparti della modifica manuale che hai fatto rimanendo come parte incontrollata del tuo ambiente. La prossima volta che esegui chef-client, sai che lo stato sarà esattamente come specificato nella ricetta dello Chef e non includerà la tua modifica.

Inoltre, è in generale più difficile e più complicato modificare in modo affidabile un file piuttosto che generarne uno. Potresti scrivere qualcosa che è idempotente nel caso base, ma se il file contiene un errore di sintassi o qualcosa di non valido, il tuo editing non funziona più.

Come sempre, a volte non si ha una scelta e il montaggio è l'unico modo per andare.

Answer 2

In realtà c'è una gran parte della comunità DevOps che vede accettare i valori predefiniti di sistema/pacchetto per i file di configurazione e solo modificando ciò di cui si ha bisogno attraverso il metodo augeas, i deviatori di Github sarebbero uno di loro (se vi capita di catturare loro a Puppet Conf 2012).

Penso che avere un modello predefinito di utilizzare sempre i modelli crei un carico di manutenzione troppo elevato e quasi sempre richieda il blocco di versioni specifiche per tutto lo stack o si rischi di avere un modello incompatibile rispetto a una versione più recente di tale risorsa.

Ci sono casi d'uso per entrambe le opzioni, ma in generale io preferisco la pratica del "tutto il meno possibile" rispetto al "tutto proprio anche se non devi" esercitarti.