Novità per gli strumenti Puppet and Chef. Sembra che il lavoro che stanno facendo possa essere fatto con gli script di shell. Forse è stato fatto con gli script della shell fino a quando non sono arrivati.
Concordo sul fatto che sono più leggibili. Ma ci sono altri vantaggi rispetto agli script della shell oltre a essere leggibili?
Risposte:
Un linguaggio specifico del dominio fa una grande differenza nella quantità di codice che scrivi. Ad esempio, potresti sostenere che non c'è molta differenza tra:
chmod 640 /my/file
e
file { "/my/file":
mode => 640,
}
ma c'è una grande differenza tra questi:
FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
# where the URL contains "Hello world"
e
file { "/my/file":
mode => 640,
owner => foo,
group => bar,
content => "Hello world",
}
Cosa succede se la wget fallisce? Come lo gestirà la tua sceneggiatura? E cosa succede se nel tuo script c'è qualcosa che richiede $ FILE per essere lì con i contenuti corretti?
Si potrebbe obiettare che si potrebbe semplicemente inserire echo "Hello world" > $FILElo script, tranne che nel primo esempio lo script deve essere eseguito sul client, mentre il pupazzo compila tutto questo sul server. Quindi, se cambi il contenuto, devi solo cambiarlo sul server e lo cambia per tutti i sistemi su cui vuoi metterlo. E il burattino gestisce le dipendenze e trasferisce automaticamente i problemi.
Non c'è paragone: strumenti di gestione della configurazione adeguati consentono di risparmiare tempo e complessità. Più si tenta di fare, più script di shell sembrano inadeguati e maggiore sarà lo sforzo che si risparmia facendolo con le marionette.
Questa sarà un'opinione impopolare, ma i sistemi di gestione della configurazione non sono necessariamente migliori. A volte semplice è davvero il migliore.
Esiste una curva di apprendimento definita e un sovraccarico amministrativo associato al sistema di configurazione scelto. Dopotutto stai introducendo una dipendenza. Come con qualsiasi automazione, è necessario anche prestare attenzione al mantenimento della sicurezza nelle configurazioni distribuite.
Ho avuto solo un paio di casi in cui abbiamo implementato la gestione della configurazione e si è bloccato. Fu sempre quando c'erano un gran numero di sistemi con configurazione ripetitiva e necessità di eseguire implementazioni configurabili di cookie cutter.
Hai risposto alla tua domanda ...
L'automazione sta diventando più scalabile e formalizzata . Oggi Puppet e Chef sono considerati standard (controlla gli annunci di lavoro ).
Script di shell di ciottoli-insieme hanno il loro posto, ma sono non scalabile nel contesto del movimento DevOps. La leggibilità è parte di questo.
Chef rende molto più semplice la gestione e la versione della configurazione di un'infrastruttura complessa, in particolare in qualsiasi tipo di ambiente cloud, anziché dover eseguire manualmente ftp o scp di un sacco di script di shell organizzati in modo non standardizzato. A seconda di quante dipendenze devi gestire, le dimensioni di questa vincita possono variare notevolmente, rendendo la decisione di passare a una soluzione CM non ovvia per molte persone.
Il vero vantaggio (spesso non celebrato) dello Chef è l' idempotenza . Essere in grado di essere certi dello stato di una risorsa indipendentemente dalla combinazione di ricette eseguite con interessi sovrapposti è un enorme vantaggio rispetto alla configurazione degli script della shell. Se disponi ora di script di shell per la configurazione, chiediti quanti di essi possono essere eseguiti più volte senza conseguenze indesiderate / indesiderate?
Una soluzione CM adeguata aiuta a garantire il successo su vasta scala semplificando l'automazione multipiattaforma e la collaborazione in team. Mentre è possibile realizzare tutto ciò con un gruppo ben organizzato, adeguatamente gestito, con versione di script di shell; devi chiederti "perché". Chef / Puppet e tecnologie simili sono nate perché un gruppo di talentuosi SysOps erano stanchi di dover risolvere questi stessi problemi più e più volte e hanno deciso di darci un'opzione migliore.
I moderni strumenti di gestione della configurazione come Puppet e Chef consentono di definire lo stato di un sistema invece di preoccuparsi delle attività necessarie per ottenere un server configurato.
Ad esempio, il comando chmod presuppone che il file esista, l'utente che possiede il file esiste, che le directory siano state create e così via. Pertanto, la tua sceneggiatura deve considerare tutti questi prerequisiti.
Gli strumenti di gestione della configurazione basati sullo stato sono più semplici: ti importa solo che il file abbia le autorizzazioni corrette. Come ciò è ottenuto è il problema dello strumento.
chmodnon presuppone che il file esista perché il file è stato creato o testato per l'esistenza dallo script.
Se i server sono usa e getta per te o se hai motivo di resistere più di un paio alla volta, un sistema CM completo soddisferà molto meglio le tue esigenze rispetto a una serie di script di shell.
Se le tue esigenze di costruzione sono modeste (o ti piace creare artigianalmente artigianalmente server per il commercio equo e solidale biologici), allora mantienilo semplice.
Personalmente, dopo aver ampiamente utilizzato Chef in un concerto passato, ho provato a "mantenerlo semplice" in questo concerto, ma mi mancavano davvero le primitive, le astrazioni e il potere che lo Chef forniva. Anche se arrivi a una situazione in cui potresti ottenere ciò di cui hai bisogno da un paio di comandi shell, puoi semplicemente eseguirli con un blocco 'command', inserendo i tuoi comandi shell esattamente come li scriveresti nella shell.
Detto questo, puoi eseguire Chef senza un server (chef-solo) e sono abbastanza sicuro che Puppet abbia un analogo, in cui puoi ancora sfruttare i libri di cucina e le ricette degli altri senza eseguire un server centrale.
Un altro vantaggio è la comunità: ci sono molte persone (molte delle quali saranno più intelligenti e / o più esperte di te). Personalmente lo adoro quando qualcun altro ha svolto il mio lavoro per me, spesso più ampiamente di quanto avrei fatto.
Ho creato un framework di automazione dei server basato su script shell: https://github.com/myplaceonline/posixcube
Sono sicuro di non essere il primo a realizzare questo tipo di progetto, ma non sono riuscito a trovare qualcosa del genere adatto alle mie esigenze, quindi ho pensato che altri lo avrebbero trovato utile. Ho avuto solo esperienza con Chef, ma quando ho iniziato a dare un'occhiata a Ansible e ad altri, volevo dare un'occhiata agli script di shell e mi piace il risultato finora.