Puppet o Chef è adatto per la gestione di configurazioni server di base in un ambiente multi-tenant?


9

Ciò riguarda ambienti multi-tenant come una piccola società di hosting.

Puppet (o simile) è una tecnologia adatta per prendersi cura dei cambiamenti di massa fondamentali ma critici? Per esempio:

  • Aggiornamento dei resolver DNS (resolv.conf)
  • Impostazione dei tasti SSH
  • Aggiornamento della configurazione NTP
  • Configurazione di snmpd
  • Distribuire script di monitoraggio come estensioni Perl SNMP o script Nagios

Le mie preoccupazioni riguardano la sicurezza e l'invasività:

  1. Non voglio che nessun server sia in grado di vedere alcuna configurazione che non dovrebbe
  2. Sono preoccupato che un burattinaio sia vulnerabile agli attacchi di un server compromesso
  3. Non voglio che Puppet apporti modifiche che non dovrebbero, né ripristini eventuali modifiche manuali apportate sul server.

Dovrei avvertirlo dicendo che non ho mai usato Puppet in produzione, ho solo avuto un gioco veloce in un laboratorio di prova, quindi è possibile che stia pensando a questo nel modo sbagliato!

Risposte:


6

Prova Ansible (ansible.cc). Forse è per te. Non esiste alcun agente in esecuzione sui client. Sta crescendo molto velocemente.

Un'altra ottima alternativa è Salt Stack.

Ansible e Salt sono facili da capire, puoi usarli come strumento da riga di comando se vuoi, come shell distribuita.


1
So di averlo chiesto molto tempo fa. Sarai felice di sapere che questa era LA risposta. Ora usiamo Ansible per distribuire automaticamente 10s di server al giorno e stiamo gestendo 1000s in uno stile fire-and-dimenticare. È fantastico da oltre un anno.
SimonJ Green

9

Sì, questo è certamente possibile. Decidere se dovresti farlo o meno dipende comunque da te.

Per quanto riguarda le tue domande:

1) abbastanza giusto. Il traffico è basato su SSL, quindi la gestione dei certificati è importante. Inoltre, non fidarti dei "fatti" che il cliente fornisce in relazione alla sua identità, in quanto questi possono essere modificati dal cliente. Si desidera fare affidamento sul certificato SSL del client per fornire l'autenticazione di chi sia il server. Ad essere onesti se stai usando cose come hiera in modo corretto ed evitando enormi blocchi basati su hostname nel tuo codice (cosa che dovresti davvero) andrà bene.

2) Non dovrebbe essere, supponendo che tu lo mantenga patchato. Configurato correttamente, c'è solo un piccolo vettore per il burattinaio che deve essere attaccato dai clienti. Detto questo, gli effetti se venissero compromessi sono grandi, quindi fai attenzione a bloccarlo.

3) Questo è davvero un problema di test e distribuzione. Se hai un codice fantoccio solido, non rovinerà i tuoi file. Ci vuole un po 'di tempo per risolverlo, ma per le basi (come è necessario) non molto tempo.


4

Puppet (o simile) è una tecnologia adatta per prendersi cura dei cambiamenti di massa fondamentali ma critici?

Sì, può essere utilizzato in questo modo. Lo uso per supportare sistemi client esterni.

Non voglio che nessun server sia in grado di vedere alcuna configurazione che non dovrebbe

Se stai usando un pupazzo, non devi abilitare la firma automatica. La firma automatica consente agli host di richiedere automaticamente un certificato. La configurazione e le autorizzazioni saranno quasi sicuramente legate direttamente alla CN nel certificato. Non vuoi che un computer casuale vada online e sia in grado di affermare che in realtà sono il sistema con tutte le cose segrete ad alta sicurezza.

Se sei veramente paranoico, puoi regolare le impostazioni del file server dei pupazzi per creare condivisioni a cui solo alcuni sistemi possono accedere. L'accesso al fileserver si basa sui certificati.

Non voglio che Puppet apporti modifiche che non dovrebbero, né ripristini eventuali modifiche manuali apportate sul server.

Esistono un paio di approcci diversi per consentire i cambiamenti locali.

Di seguito è riportato un metodo che utilizzo frequentemente. Fondamentalmente se passi un elenco a source, quindi il pupazzo prova ogni elemento nell'elenco. Quindi aggiungo il primo elemento nell'elenco per puntare a un file locale.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Un'altra opzione sarebbe quella di utilizzare i collegamenti simbolici. Se qualcuno desidera utilizzare la versione fantoccio, si collega alla versione fantoccio di un file. Se vogliono mantenere la propria configurazione localmente, non creano un collegamento simbolico.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

L'altra possibilità è utilizzare augeas per apportare modifiche a livello di linea anziché modificare interi file. Sii molto conservatore su ciò che cambi.


1

3> Non c'è annullamento automatico in Puppet o in tali strumenti. Devi scrivere un codice esplicito per annullare. Inoltre, è possibile ricercare la funzione Ambienti di Puppet, disporre di un laboratorio di test in cui viene testato il nuovo codice (potrebbe essere VM) e utilizzare la revisione del codice.


Non del tutto vero. Chef esegue un backup di qualsiasi file in cui viene modificato /var/lib/chefper impostazione predefinita (a meno che la risorsa non sia configurata per non lasciare backup, ad es. Per dati sensibili), e con il docformatter si vede un diff sull'output del terminale.
Maciej Pasternacki,

Bene, sì, Puppet può anche eseguire più backup. Ma come faresti a sapere quale backup ripristinare? Dovresti scrivere un codice Chef / Puppet o uno script esterno per eseguire effettivamente quell'azione? Che dire delle risorse non file come ripristinare un pacchetto precedente con una versione specifica? E i servizi? Se avevi il codice che diceva "assicurati che funzioni" e volevi cambiarlo, dovresti cambiare il codice per "assicurarti di essere fermato".
Non ora,

L'idea è che l'esecuzione della gestione della configurazione sia a senso unico. Non esiste una procedura di rollback supportata o "funzionamento a secco" pienamente funzionante (esiste una modalità whyrun in Chef che è solo un suggerimento / controllo di integrità piuttosto che una simulazione completa (vedi blog.afistfulofservers.net/post/2012/12/21/ ... per una spiegazione più lunga.) Non è possibile annullare la modifica della password dell'utente, ecc. Per questo motivo ho scritto "non del tutto vero" - non esiste un rollback supportato, ma esiste una rete di sicurezza / debug che consente di visualizzare il backup se qualcosa va storto e devi dare un'occhiata. Nient'altro, ma comunque utile
Maciej Pasternacki,

E ho scoperto che ho letto male il tuo commento: è vero che non c'è annullamento automatico e devi scrivere codice esplicito (e molto probabilmente difettoso) se hai provato ad automatizzarlo. Non riesco a modificare il mio commento originale poiché è stato risposto: stavo pensando al ripristino di emergenza piuttosto che al rollback automatico. Se vuoi vedere il rollback automatico, dai un'occhiata a nixos.org , BTW.
Maciej Pasternacki,

1

Non voglio che Puppet apporti modifiche che non dovrebbero, né ripristini eventuali modifiche manuali apportate sul server.

Per i file di configurazione creati utilizzando il tipo di file Puppets questo può essere ottenuto impostando:

replace => false,

Lo uso per generare alcuni file di configurazione la prima volta che un'applicazione viene distribuita su un server, ma tutte le modifiche a quel file di configurazione non verranno sovrascritte da Puppet.

Tuttavia, ciò è contrario alla filosofia di Puppet di essere uno script deploy idempotente.

Potrebbe essere meglio, se possibile, avere file modificabili dall'amministratore separati che non sono gestiti da Puppet e che sono inclusi dai file gestiti da Puppet.


0

Puppet funziona meglio per molti server con configurazione identica. Ad esempio, scrivi tutta la configurazione di un server Web condiviso fornita dalla tua azienda, quindi crei N istanze di quel server. Successivamente apportare modifiche su tutte le istanze contemporaneamente (ad esempio, si scopre che è necessario modificare AllowOverride per tutti gli host virtuali di Apache) sarà davvero facile. Sarai anche in grado di memorizzare tutte le informazioni di configurazione in un unico posto e averle sotto il controllo della versione. Nel caso perfetto, sarai in grado di gestire un errore hardware eliminando l'host danneggiato, sostituendolo con uno nuovo, impostando lo stesso nome host e firmando il certificato necessario. Tutto il resto potrebbe essere fatto da Puppet.

Ma se si finisce con quasi nessuna condivisione della configurazione tra due host, l'utilizzo di Puppet potrebbe essere meno produttivo rispetto alla configurazione manuale. Anche gestire metà della configurazione del server con le marionette e l'altra metà manualmente potrebbe non avere molto senso.

Riepilogo : se riesci a creare una configurazione uniforme e strutturata per gli host che gestirai, Puppet è il tuo migliore amico, ma se devi gestire ogni servizio (host, host virtuale, database) specialmente Puppet non aggiungerà molto valore.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.