Come utilizzare gli ambienti Puppet in Linux per aggiornare in modo sicuro un agente

Obiettivo

Crea e utilizza ambienti puppet per testare la nuova configurazione prima di aggiornare un sistema di produzione live.

Versioni del sistema operativo e del software

Sistema operativo: Tutte le principali distribuzioni Linux, ad esempio Ubuntu, Debian, CentOS
Software: burattinaio e burattinaio

Fabbisogno

Accesso privilegiato al server master puppet e al nodo client puppet.

Convenzioni

# – richiede che determinati comandi Linux vengano eseguiti con privilegi di root direttamente come utente root o utilizzando il comando sudo
$ – dati i comandi Linux da eseguire come un normale utente non privilegiato

Introduzione

La maggior parte delle installazioni di Puppet inizia la sua vita come server master che esegue un singolo ramo. Il master contiene tutti i manifesti e altre configurazioni per tutti gli agenti Puppet sincronizzati con esso. Questo è un buon punto di partenza, ma arriverà rapidamente un momento in cui sarà necessario inviare un aggiornamento che ha il potenziale per interrompere un server di produzione. Sperare per il meglio non è il modo migliore di procedere.

Puppet fornisce gli strumenti per separare interi rami della configurazione. Questi sono chiamati ambienti. Un ambiente Puppet è un modo per fornire a un gruppo isolato di nodi agente la propria configurazione dedicata. Ogni ambiente contiene un intero albero di configurazione Puppet e può essere considerato come un server master Puppet separato.

Come vengono utilizzati gli ambienti Puppet?

Lo scenario tipico per gli ambienti, ed è quello che stiamo esplorando in questa guida, consiste nel creare un ambiente di test, accanto all'ambiente di produzione, in cui viene creata una nuova configurazione Puppet.

Un modo per testare la nuova configurazione nell'ambiente di test consiste nell'aggiornare una copia di un server di produzione, ad esempio uno snapshot di una macchina virtuale. Eventuali problemi verranno osservati sulla macchina di test e la configurazione del pupazzo verrà modificata per correggerlo. Tuttavia, non è sempre possibile disporre di un server di test per verificare le modifiche nell'ambiente di test.

Un altro metodo, quello che esploreremo qui, consiste nell'eseguire manualmente l'agente Puppet sul server di produzione, ma utilizzare diverse opzioni che causeranno la sincronizzazione dell'agente Puppet con l'ambiente di test, ma mostreranno solo cosa sarebbe successo senza apportare modifiche effettive. In questo modo verranno evidenziati tutti gli errori che si sarebbero verificati in un aggiornamento completo senza causare effettivamente tempi di inattività.

Creazione di ambienti Puppet

In questa guida, creeremo un'istanza Puppet molto semplice con un Puppet Master e un nodo agente Puppet. Il server Puppet master sarà configurato per avere due ambienti; test e sviluppo.

Questa guida presuppone che si disponga di un server master Puppet e di un nodo agente Puppet in grado di connettersi al master Puppet.

Creeremo due ambienti sul Puppet master e all'interno di questi ambienti creeremo un manifesto Puppet molto semplice che crea un file di testo sul nodo dell'agente.

La posizione predefinita per la configurazione di Puppet cambia a seconda della distribuzione in uso. Su Ubuntu 18.04LTS, la versione che verrà utilizzata in questa guida, la posizione è in /etc/puppet. Altre distribuzioni (e la documentazione ufficiale) potrebbero metterlo in /etc/puppetlabs/. Tuttavia, una volta che ci si trova nella directory di configurazione principale di Puppet, tutte le sottodirectory sono le stesse per tutte le distribuzioni.

Disposizioni

Creare le directory dell'ambiente

Gli ambienti e la loro configurazione esistono tutti nella directory /etc/puppet/code/. Su Ubuntu 18.04 questa directory è vuota durante l'installazione, quindi dovremo prima creare le due directory dell'ambiente di primo livello con i seguenti due comandi:

mkdir -p /etc/puppet/code/environments/testing
mkdir -p /etc/puppet/code/environments/development

Qualsiasi nuovo nodo dell'agente si connetterà automaticamente all'ambiente di sviluppo, a meno che la variabile di ambiente non sia impostata su un'alternativa nella sezione [agent] del file puppet.conf sul nodo dell'agente.

Creazione di due semplici manifesti site.pp

Il file site.pp è il manifesto principale da cui l'agente Puppet inizia a creare un catalogo dello stato del computer desiderato. Creeremo due file site.pp molto semplici nei due ambienti che creano lo stesso file sul nodo agente. L'unica differenza è che inseriscono testo diverso nel file.

Il primo file site.pp sarà l'ambiente di produzione all'indirizzo:
/etc/puppet/codice/ambienti/sviluppo/manifesti/sito.pp
Questo file dovrebbe avere i seguenti contenuti:

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Development Environment \n",
}

Usa il tuo editor di testo preferito per creare e popolare questo file.

Questo manifesto garantisce che un file sia presente in /tmp/example.txt e contenga il testo "From The Development Environment" (il "" aggiunge una nuova riga alla fine del file, il che è una buona pratica e impedisce a Puppet di mostrare un messaggio di avviso quando non è presente).

Il secondo manifesto sarà nell'ambiente di test all'indirizzo:
/etc/puppet/codice/environments/testing/manifests/site.pp
Questo file contiene quanto segue:

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Testing Environment \n",
}

Questo è quasi identico al file nell'ambiente di sviluppo con l'unica differenza che il testo nel file indica che proviene dall'ambiente di test.

Valutazione della nuova configurazione del pupazzo dall'ambiente di test

Per impostazione predefinita, il nodo dell'agente verrà sincronizzato solo con l'ambiente di sviluppo. Per prima cosa indicheremo manualmente all'agente Puppet di sincronizzarsi con il server Puppet master e di creare e applicare il site.pp creato nell'ambiente di sviluppo.

Questa operazione viene eseguita con il seguente comando:

puppet agent --environment=production --test

L'opzione --test fa sì che l'agente Puppet esegua un'esecuzione del catalogo in primo piano con una registrazione dettagliata. Eventuali aggiornamenti o modifiche verranno applicati al nodo.

L'opzione --environment=production serve a rendere chiaro che stiamo sincronizzando dall'ambiente di produzione. In genere, questa opzione viene configurata nella configurazione principale dell'agente Puppet e non è necessario includerla nel comando.

Quando viene eseguito il comando precedente, otteniamo il seguente output:

  Info: Using configured environment 'production'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Caching catalog for digital-2.net
  Info: Applying configuration version '1527680694'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/ensure: defined content as '{md5}59f9ce1d4aad5fd155db7ccc2478a93b'
  Notice: Applied catalog in 0.02 seconds

Questo output indica che il file /tmp/example.txt non era presente, quindi l'agente Puppet lo ha creato come indicato nel manifesto site.pp. Le esecuzioni successive non avranno le righe Notice: poiché il file /tmp/example.txt esiste con il contenuto corretto.

Ora che lo stato del nodo agente concorda con il manifesto dell'ambiente di sviluppo, è possibile testare cosa accadrebbe se applicassimo il manifesto alternativo dall'ambiente di test.

Per testare e non eseguire il commit della nuova configurazione, è necessario eseguire il seguente comando:

puppet agent --environment=testing --test --noop

Come puoi vedere, l'opzione --environment è stata modificata in testing e abbiamo incluso l'opzione aggiuntiva --noop. Questa opzione fa sì che l'agente esegua una prova di prova. Ciò significa che l'agente Puppet non apporterà alcuna modifica effettiva al nodo dell'agente, ma produrrà tutto l'output come se lo avesse fatto.

Questo ci permette di valutare cosa sarebbe successo se la nuova configurazione fosse stata applicata al server. In questo caso l'output del comando precedente è simile al seguente:

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Applying configuration version '1527683748'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content:
  --- /tmp/example.txt    2018-05-30 12:19:16.205774048 +0000
  +++ /tmp/puppet-file20180530-21610-8ipzur      2018-05-30 12:35:48.740982652 +0000
  @@ -1 +1 @@
  -From The Development Environment
  +From The Testing Environment

  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content: current_value '{md5}59f9ce1d4aad5fd155db7ccc2478a93b', should be '{md5}abbb8f68df144a5673d
  62ae6c4a036ed' (noop)
  Notice: Class[Main]: Would have triggered 'refresh' from 1 event
  Notice: Stage[main]: Would have triggered 'refresh' from 1 event
  Notice: Applied catalog in 0.04 seconds

Le linee più interessanti qui sono le seguenti:

  -From The Development Environment
  +From The Testing Environment

Questi indicano con il simbolo meno ( - ) da cosa si sta cambiando e con il simbolo più ( + ) in cosa si sta cambiando. In questo esempio è il testo nel file.

Tutto questo output indica che la nuova configurazione sarebbe stata applicata correttamente e che il contenuto di /tmp/example.txt sarebbe stato modificato. Se questo è lo stato desiderato del server di produzione, le modifiche al file site.pp possono essere apportate in modo sicuro nell'ambiente di produzione.

Identificazione di un errore

La nuova configurazione del pupazzo non viene sempre applicata senza errori e questo è il motivo per cui dovrebbe essere sempre testata prima di essere applicata a un sistema di produzione. Forzeremo un errore in questa situazione commettendo un errore intenzionale nel file site.pp di test. Cercheremo di impostare le autorizzazioni del file su 0944 che non è un'autorizzazione valida e causerà un errore.

Ora, quando eseguiamo:

  # puppet agent --environment=testing --test --noop

Vedremo il seguente output:

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Error: Failed to apply catalog: Parameter mode failed on File[/tmp/example.txt]: The file mode specification is invalid: "0944" (file: /etc/puppetcode/environments/testing/manifests/site.pp, line: 1)

La schermata seguente mostra questo output come verrebbe presentato nella riga di comando:

Il pupazzo indicherà eventuali errori stampandoli in rosso.

I colori ci fanno subito capire che si sarebbe verificato un errore nel tentativo di utilizzare la nuova configurazione del pupazzo dall'ambiente di test. Tuttavia, poiché abbiamo utilizzato l'opzione --noop non sono stati commessi errori nel server di produzione.

Conclusione

Quando si eseguono sistemi di produzione gestiti da Puppet, è sempre importante testare qualsiasi nuova configurazione prima che venga applicata. L'utilizzo degli strumenti forniti da Puppet per creare ambienti alternativi in cui è possibile creare e valutare in modo sicuro una nuova configurazione rispetto ai sistemi di produzione significherà meno errori e meno tempi di inattività.