casa › Consiglio › Master of Puppet: Installazione e configurazione del sistema di gestione della configurazione remota Puppet. Master of Puppets: Installazione e configurazione del sistema di gestione della configurazione remota Puppet Installazione di Puppet

Master of Puppet: Installazione e configurazione del sistema di gestione della configurazione remota Puppet. Master of Puppets: Installazione e configurazione del sistema di gestione della configurazione remota Puppet Installazione di Puppet

Per utilizzare Puppet in modo più efficace, è necessario comprendere come vengono creati moduli e manifest. Questo tutorial ti guiderà attraverso il funzionamento di questi componenti Puppet configurando uno stack LAMP su un server Ubuntu 14.04.

Requisiti

Installazione di Puppet (master e agente). Maggiori informazioni su questo -.
La possibilità di creare almeno un server virtuale Ubuntu 14.04 per servire il nodo dell'agente Puppet.

Nozioni di base sul codice pupazzo

Risorse

Il codice pupazzo è costituito principalmente da risorse. Una risorsa è un pezzo di codice che descrive lo stato del sistema e determina le modifiche di cui ha bisogno. Per esempio:

utente("mitchell":
garantire => presente,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
casa => "/casa/mitchell"
}

La dichiarazione della risorsa ha il seguente formato:

tipo_risorsa("nome_risorsa"
attributo => valore
...
}

Per visualizzare tutti i tipi di risorse Puppet, esegui il comando:

risorsa pupazzo --types

Imparerai di più sui tipi di risorse in questa guida.

Manifesti

Un manifest è uno script di orchestrazione. I programmi fantoccio con estensione .pp sono chiamati manifest. Il manifest Puppet predefinito è /etc/puppet/manifests/site.pp.

Classi

Come in ogni normale linguaggio di programmazione, le classi sono responsabili dell'organizzazione e del riutilizzo di parti dell'orchestrazione.

All'interno di una definizione di classe c'è un blocco di codice che descrive come funziona la classe. Una volta definita una classe, puoi usarla nei manifest.

La definizione della classe ha il seguente formato:

classe esempio_class(
...
codice
...
}

Questo codice definisce la classe example_class. Il codice Puppet sarà tra parentesi graffe.

Una dichiarazione di classe è il punto nel codice in cui viene chiamata una particolare classe. Con una dichiarazione di classe, Puppet elabora il suo codice.

La dichiarazione della classe può essere ordinaria e per tipo di risorsa.

Una normale dichiarazione di classe viene aggiunta al codice utilizzando la parola chiave include.

includere classe_esempio

Quando dichiarata come tipo di risorsa, la classe viene dichiarata nel formato risorsa:

classe("classe_esempio":)

Questa dichiarazione ti consente di aggiungere parametri di classe al tuo codice che sovrascrivono i valori predefiniti degli attributi di classe. Per esempio:

nodo "host2" (
class ("apache": ) # usa il modulo apache
apache::vhost ( "example.com": # definisce la risorsa vhost
porta => "80",
docroot => "/var/www/html"
}
}

Moduli

Un modulo è un gruppo di manifesti e altri file organizzati in modo predefinito che semplifica la condivisione e il riutilizzo di singole parti dell'orchestrazione. I moduli aiutano a organizzare il codice Puppet perché possono essere utilizzati per separare il codice in più manifest.

I moduli Puppet sono memorizzati nella directory /etc/puppet/modules.

Scrivere un manifesto

Puoi esercitarti a scrivere manifest, moduli e classi Puppet usando l'esempio dell'installazione di uno stack LAMP su un server Ubuntu (il risultato sarà ).

Quindi, per orchestrare un server Ubuntu 14.04 e installarvi uno stack LAMP, sono necessarie risorse per le seguenti azioni:

installando il pacchetto apache2.
avviare il servizio apache2.
installazione del pacchetto Server MySQL, server mysql.
avviando il servizio mysql.
installazione del pacchetto php5
creando uno script di test PHP, info.php.
aggiornando l'indice apt prima di installare ciascun pacchetto.

Di seguito troverai tre esempi di codice Puppet che può essere utilizzato per ottenere una tale configurazione dello stack LAMP.

Il primo esempio ti insegnerà come scrivere manifest di base in un unico file. Il secondo esempio ti aiuterà ad assemblare e utilizzare una classe e un modulo basati su manifest scritti in precedenza. Il terzo esempio ti mostrerà come utilizzare moduli pubblici predefiniti per installare uno stack LAMP.

Nota: Per i test è meglio utilizzare un nuovo server virtuale.

Esempio 1: installazione di LAMP con un manifest

Il manifest Puppet può essere scritto sul nodo agente e quindi eseguito utilizzando il comando pupazzo apply (non è necessario disporre di una configurazione master e agente per eseguire questa operazione).

In questa sezione imparerai a scrivere manifest che utilizzeranno questi tipi di dichiarazioni di risorse:

exec: esegue i comandi.
pacchetto: installa i pacchetti.
servizio: gestione del servizio.
file: gestione dei file.

Creazione di un manifesto

Crea un nuovo manifesto:

sudo vi /etc/puppet/manifests/lamp.pp

Aggiungi il seguente codice per dichiarare le risorse richieste.

# esegue il comando "apt-get update".
exec("apt-update": # risorsa exec "apt-update"
command => "/usr/bin/apt-get update" # comando che verrà eseguito da questa risorsa
}
# installa il pacchetto apache2
pacchetto("apache2":
require => Exec["apt-update"], # request "apt-update" prima di installare il pacchetto
garantire => installato,
}
# avvia il servizio apache2
servizio("apache2":
garantire => in esecuzione,
}
# installa mysql-server
pacchetto("server-mysql":
require => Exec["apt-update"], # richiedi "apt-update" reinstallando
garantire => installato,
}
# avvia il servizio mysql
servizio("mysql":
garantire => in esecuzione,
}
# installa il pacchetto php5
pacchetto("php5":
require => Exec["apt-update"], # richiedi "apt-update" prima dell'installazione
garantire => installato,
}
# avvia il servizio info.php
file("/var/www/html/info.php":
garantire => file,
contenuto => "", # codice phpinfo
require => Pacchetto["apache2"], # richiesta per il pacchetto "apache2"
}

Applicazione di un manifesto

Per utilizzare il nuovo manifest, inserisci il comando:

sudo pupazzo applica --test

Verrà visualizzato un risultato voluminoso che mostra tutti i cambiamenti nello stato dell'ambiente. Se non ci sono errori nell'output, dovresti essere in grado di aprire il tuo indirizzo IP esterno o nome di dominio nel tuo browser. Sullo schermo verrà visualizzato un test di prova. Pagina PHP con informazioni sullo stack. Ciò significa che Apache e PHP funzionano.

Ora lo stack LAMP è installato sul server utilizzando Puppet.

Questo è un manifest abbastanza semplice poiché può essere eseguito su un agente. Se non disponi di un Puppet master, gli altri nodi agente non saranno in grado di utilizzare questo manifest.

Il server master Puppet verifica le modifiche allo stato del server ogni 30 minuti.

Esempio 2: installazione di uno stack LAMP utilizzando un modulo

Ora prova a creare un modulo semplice basato sul manifest LAMP che hai scritto nella sezione precedente.

Per creare un modulo, creare una nuova directory nella directory dei moduli (il suo nome deve corrispondere al nome del modulo). Questa directory dovrebbe contenere una directory dei manifesti e un file init.pp. Il file init.pp specifica la classe Puppet (il suo nome deve corrispondere anche al nome del modulo).

Creazione di un modulo

Vai al server master Puppet e crea una struttura di directory per il modulo:

cd /etc/puppet/modules
sudo mkdir -p lampada/manifest

Crea e apri il file init.pp nell'editor:

sudo vi lamp/manifests/init.pp

Inserisci la classe della lampada nel file:

lampada di classe (
}

Copia il contenuto del manifest dalla sezione 1 e incollalo nel blocco della classe lamp. Ora hai una definizione di classe lampada. Altri manifesti potranno utilizzare questa classe come modulo.

Salva e chiudi il file.

Utilizzando un modulo nel manifest principale

Ora puoi configurare il manifest principale e utilizzare il modulo lampada per installare lo stack LAMP sul server.

Sul server master Puppet, modifica il seguente file:

sudo vi /etc/puppet/manifests/site.pp

Molto probabilmente su questo momento il file è vuoto. Aggiungi le seguenti righe:

nodo predefinito ( )
nodo "lampada-1" (
}

Nota: sostituisci lamp-1 con il nome host del tuo agente Puppet su cui installare lo stack.

Il blocco nodo ti consente di specificare il codice Puppet che verrà applicato solo ad alcuni nodi.

Il blocco predefinito si applica a tutti i nodi agente che non dispongono di un blocco individuale (lasciarlo vuoto). Il blocco lampada-1 verrà applicato al nodo agente lampada-1.

Aggiungi la seguente riga a questo blocco, che utilizza il modulo lampada:

Salva e chiudi il file.

Ora il nodo dell'agente Puppet sarà in grado di scaricare le impostazioni dal server master e installare lo stack LAMP. Se desideri apportare modifiche adesso, esegui il comando sull'agente:

sudo pupazzo agente --test

I moduli rappresentano il modo più conveniente per riutilizzare il codice Puppet. Inoltre, i moduli ti aiutano a organizzare logicamente il tuo codice.

Esempio 3: installazione di LAMP utilizzando moduli pubblici

Il modulo MySQL viene utilizzato in modo simile. Aggiungi le seguenti righe al blocco nodo:

classe("mysql::server":
root_password => "password",
}

Puoi anche passare i parametri del modulo MySQL.

Aggiungi una risorsa che copierà info.php nella posizione desiderata. Utilizza il parametro sorgente. Aggiungi le seguenti righe al blocco nodo:

file("info.php": # nome del file di risorsa
percorso => "/var/www/html/info.php", # percorso di destinazione
garantire => file,
require => Class["apache"], # classe Apache da utilizzare
source => "puppet:///modules/apache/info.php", # posizione in cui copiare il file
}

Questa dichiarazione di classe utilizza il parametro source anziché il contenuto. Questa opzione non solo utilizza il contenuto del file, ma lo copia anche.

Puppet copierà il file pupazzo:///modules/apache/info.php in /etc/puppet/modules/apache/files/info.php.

Salva e chiudi il file.

Crea un file info.php.

sudo sh -c "eco""> /etc/puppet/modules/apache/files/info.php"

Ora il nodo dell'agente Puppet sarà in grado di scaricare le impostazioni dal server master e installare lo stack LAMP. Se desideri apportare modifiche all'ambiente dell'agente adesso, esegui il comando su questo nodo:

sudo pupazzo agente --test

Questo comando scaricherà tutti gli aggiornamenti per il nodo corrente e installerà lo stack su di esso. Per assicurarti che Apache e PHP funzionino, apri l'indirizzo IP o il dominio del nodo in un browser:

http://lamp_1_public_IP/info.php

Conclusione

Ora hai una conoscenza di base su come lavorare con i moduli e i manifest Puppet. Prova a creare un semplice manifest e moduli tu stesso.

Puppet è ottimo per gestire i file di configurazione dell'applicazione.

Tag: ,
Un po' di poesia. Sembrerebbe che questo articolo dovrebbe essere il punto di partenza per l'intera serie, ma il pubblico target sono ancora gli utenti più esperti dei prodotti Open Source Puppet Labs che non sono soddisfatti dei singoli moduli scarsamente integrati con Puppet Forge. Come in ogni caso “biblioteca vs framework”, il prezzo da pagare è seguire la visione del mondo dell’autore della soluzione integrata.

Un po' di come funziona Puppet

Puppet è principalmente un linguaggio specifico per specificare in modo dichiarativo lo stato finale del sistema. Per fare un confronto, il Makefile GNU è estremamente adatto, dove, oltre alla descrizione diretta delle dipendenze, è possibile diventare completamente strani.

L'astrazione di Puppet è qualcosa del genere ( rompere gli schemi: dimentica tutto quello che sapevi sui termini di programmazione!).

Nodoè un insieme di configurazioni per un sistema di destinazione specifico. In realtà, questo è un caso speciale di una classe.
Classeè un insieme di logica dichiarativa incluso nella configurazione del nodo o in altre classi. La classe non ha né istanze né metodi, ma ha parametri e variabili definiti all'interno della logica. In realtà si tratta piuttosto di una procedura che può ereditare un'altra procedura semplicemente aggiungendo codice e disponendo di un ambito di variabili non così banale.
Tipo- ma questa assomiglia più a una classe classica - presuppone istanze con un nome e sicuramente parametri dati, ma niente di più. Un'implementazione specifica di un tipo può essere scritta come uno script Puppet tramite define , che crea istanze di altri tipi, o come estensione Ruby con un volo di fantasia.
Risorsa- queste sono in realtà istanze denominate di Types. Ogni nome di risorsa è univoco all'interno di un tipo specifico all'interno della configurazione del nodo (directory).
Variabili- beh, in breve, queste sono costanti... Prima di Puppet 4, le cose erano ancora peggiori per quanto riguarda la loro portata. Ora è adeguato: per l'uso dall'esterno della posizione della definizione, deve essere specificato un identificatore completo, tranne nel caso dell'ereditarietà della classe.

Puppet può essere utilizzato per la distribuzione locale senza rete o infrastruttura associata. Questo può essere utilizzato per creare immagini del contenitore. Esiste addirittura un intero movimento che sostiene l'abbandono di un server centralizzato.

In modo ideologicamente corretto, l'infrastruttura Puppet è costituita da un agente - un servizio privilegiato sul sistema di destinazione - e da un server che distribuisce preziose istruzioni sotto forma di directory di risorse dichiarative su richiesta degli agenti. La sicurezza viene implementata a livello dell'infrastruttura a chiave pubblica privata (X.509). In poche parole, gli stessi meccanismi di HTTPS, ma con una propria CA e verifica obbligatoria certificato cliente.

In una forma semplificata, la procedura di distribuzione è simile alla seguente:

Elaborazione tramite TLS e X.509 (creazione della connessione, aggiornamento CRL, controllo delle restrizioni dei certificati, ecc.)
L'agente riceve generatori di fatti dal server con memorizzazione nella cache e tutto il resto (più precisamente, tutto viene estratto dalle cartelle lib/ nei moduli). Non è difficile aggiungere il proprio script Ruby per raccogliere le informazioni di interesse.
L'agente raccoglie informazioni sul sistema di destinazione e le invia al server. Tutti i fatti possono essere facilmente visualizzati manualmente tramite la chiamata ai fatti dei burattini. Questi fatti sono disponibili come variabili globali.
Il server compila un catalogo di risorse e lo invia all'agente. Sotto questo si trova un intero strato di concetti diversi.
L'agente estrae tutto il necessario dal server e porta il sistema nel modulo specificato. L'agente stesso non sa cosa fare con le risorse; si affida all'implementazione di fornitori (la traduzione semantica sarà "implementer", non fornitore) di specifici tipi di risorse. Alcuni fornitori sono standard e sono inclusi nei pacchetti Puppet, mentre il resto viene estratto dai moduli.

Per goderti tutte le delizie, ci sono panini aggiuntivi sotto forma di:

Modulo- una raccolta di script dichiarativi Puppet, estensioni Ruby per Puppet, file, modelli di file, dati Hiera e molto altro. Il termine più corretto sarebbe “pacchetto”.
Ambiente- un insieme di script, moduli e dati Hiera. Man mano che l’infrastruttura diventava più complessa si è reso inevitabilmente necessario suddividere la configurazione oltre la divisione standard per nodi. Fondamentalmente, ciò è necessario per innovazioni pilota e banali controlli di accesso (quando non tutti gli amministratori hanno accesso a tutti i nodi dell'infrastruttura IT).
Hiera- database gerarchico. Questa formulazione può essere molto intimidatoria. Questo è probabilmente il motivo per cui è stato modificato nella documentazione delle versioni successive. In effetti, questo è un meccanismo estremamente semplice e conveniente per estrarre la configurazione da file YAML o JSON. La gerarchia è la capacità di specificare l'ordine di lettura di più file di configurazione, ad es. gerarchia/priorità di questi file.
- Oltre a recuperare i dati tramite chiamata di funzione, Puppet estrae i parametri di classe predefiniti, che è il punto forte.
- Naturalmente Hiera supporta l'interpolazione dei fatti e persino il richiamo di funzioni speciali.
- In Puppet 4.3 abbiamo implementato nuovamente la stessa funzionalità per supportare non solo un database globale, ma anche locale per l'ambiente e il modulo, sebbene l'autore abbia già riscontrato diversi problemi nella loro implementazione (PUP-5983, PUP-5952 e PUP -5899), che sono stati immediatamente risolti da Puppet Labs.
- Sono supportate diverse strategie per estrarre valori da tutti i file nella gerarchia:
  - first: viene restituito il primo valore trovato in base alla priorità
  - unico: raccoglie tutti i valori in un array unidimensionale e rimuove i duplicati
  - hash: combina tutti gli hash YAML trovati. Le chiavi duplicate vengono selezionate in base alla priorità.
  - deep è essenzialmente una versione ricorsiva di hash
- Il bello è che la strategia di campionamento può essere specificata sia quando si chiama la funzione lookup(), perché e in qualsiasi file della gerarchia tramite la chiave speciale lookup_options, che viene utilizzata attivamente nel modulo cfnetwork.
PuppetDB- essenzialmente uno strato di logica di business attorno ad un database relazionale (PostgreSQL), che consente di salvare report su fatti e distribuzioni effettuate ed esportare risorse per la successiva importazione in directory su altri nodi o selezioni tramite funzioni speciali. C'è anche un'interfaccia web sotto forma di Puppet Dashboard.
PKI X.509- la già citata infrastruttura dei certificati, estremamente comoda da utilizzare per altri servizi senza la necessità di gestire un'infrastruttura separata.
MCollective- sembra essere una cosa utile per l'avvio di attività basato su eventi in una server farm, ma l'autore ha una certa sfiducia nella sicurezza di una particolare soluzione.
Forgia delle marionette- una piattaforma aperta per la pubblicazione e il download dei moduli.
alcune altre funzionalità sotto forma di controlli dispositivi esterni tipo di apparecchiatura Cisco e implementazione su bare metal, ma questa è una storia diversa

Note sulla sicurezza e l'accessibilità

Devi capire che Puppet Server diventa un punto vulnerabile dell'intera infrastruttura IT, perché... determina la configurazione finale di tutti i sistemi. In casi particolari ha senso effettuare una separazione: un server separato per gli elementi critici dell'infrastruttura con estremamente accesso limitato e aggiornamento manuale e il secondo per tutto il resto.

La disponibilità di Puppet Server determina la capacità di gestire l'intera infrastruttura. Ha senso ospitare Puppet Server su una macchina virtuale in un cloud di terze parti più affidabile e rapidamente ripristinabile rispetto alle proprie capacità. Oppure dovresti installare diversi server.

In ogni caso, non dovresti installare altri servizi sul sistema in cui verrà distribuito Puppet Server con tanti fronzoli. La virtualizzazione e la containerizzazione possono aiutarti.

Multi-master (diversi Puppet Server separati)

In questo caso, solo un server funge da CA (Certificate Authority): la sua indisponibilità significa che è impossibile aggiungere nuovi nodi.
- Puppet ti consente di utilizzare un'infrastruttura X.509 di terze parti se quella integrata non è soddisfacente.
L'intera configurazione (ambiente) deve essere archiviata in un sistema di controllo della versione e distribuita su ciascun server contemporaneamente.
L'unica cosa in comune è il database PostgreSQL, la cui organizzazione dell'alta disponibilità va oltre lo scopo di questo articolo.
Il modulo cfpuppetserver supporta installazioni come server primario (con CA) e come server secondario.

Ciò che è cambiato in modo significativo rispetto alle versioni precedenti

Il produttore ha una descrizione completa.

Tutti i servizi sono stati spostati su JVM, JRuby e Jetty. Nonostante gli ovvi vantaggi dell'integrazione, ci sono anche degli svantaggi in termini di consumo di memoria.
Sono state aggiunte funzioni Lambda per l'elaborazione delle raccolte: ora non è più necessario tagliare le stampelle in Ruby o pervertire tramite create_resources()
È apparso uno strumento per l'elaborazione dei modelli EPP: essenzialmente lo stesso ERB, ma con Puppet DSL invece di Ruby,
La struttura della directory predefinita dei file di configurazione è cambiata in modo significativo
Aggiunto supporto per fornitori di dati per ambienti e moduli (gli hack non sono più necessari).
Minimizzare il ruolo della Hiera globale. Il comando nuovo e correlato è la ricerca dei pupazzi.

Installazione

Questo processo è piuttosto primitivo, ma richiede il rispetto di una determinata sequenza di passaggi. Poiché farlo manualmente è un compito ingrato, l'autore ti insegnerà qualcosa di brutto, ovvero scaricare script incomprensibili da Internet ed eseguirli come root sul tuo sistema.

I tre componenti server principali sono Puppet Server stesso, PuppetDB e PostgreSQL. Possono essere tutti stipati in un nodo o divisi in due o tre sistemi. Puppet Server e Puppet DB possono essere eseguiti più volte, ma PostgeSQL è un singolo punto di errore. Esistono vari approcci alla replica e al clustering di PostgeSQL. Un approccio conveniente nel caso dei server principale e secondario sarebbe Master + Slave di sola lettura, che è supportato nello stesso PuppetDB come nodo del database principale e di sola lettura, ma automatizzando tale una configurazione richiede tempo e quindi non è ancora disponibile inclusa nel modulo cfpuppetserver.

La configurazione stessa può essere semplicemente memorizzata almeno su file system insieme a Puppet Server, ma è come scrivere script su un server web di produzione. La soluzione più adatta è un repository git. L'utilità r10k può estrarre tutti i rami del repository e distribuirli su Puppet Server come ambienti separati. r10k è piuttosto pessimo nel generare dipendenze, quindi viene utilizzato librarian-puppet in cima. Vale subito la pena notare che il principale ambiente canonico dei burattini è la "produzione". Pertanto, il repository di configurazione dovrebbe utilizzare un ramo chiamato "produzione" anziché "master".

Requisiti di sistema

L'hardware è descritto dal produttore stesso. Il modulo cfpuppetserver attualmente supporta solo Debian Jessie+ e Ubuntu Trusty+.

Configurazione in Git

Per r10k stesso, la posizione del repository non ha molta importanza: la cosa principale è la sua disponibilità. Ad esempio, a scopo di test, il repository potrebbe essere ospitato sullo stesso sistema e accessibile tramite file:// . Un buon punto di partenza è l'esempio di configurazione codingfuture/puppet-exampleenv.

Clonazione del repository: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Installare Impostazioni generali accesso amministratore utilizzando i suggerimenti nei commenti:
- $EDITOR dati/common.yaml
Creiamo una configurazione del nodo:
- $MY_DOMAIN - nome del dominio root (ad esempio, example.org)
- $HOST_NAME: nome host del client senza dominio
- dati mkdir/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - configurazione di un nodo con Puppet Server in base ai suggerimenti nei commenti
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - impostazione di un nodo arbitrario in base ai suggerimenti nei commenti
Effettuiamo l'invio al nostro server Git o lo rendiamo disponibile localmente su un nodo con Puppet Server tramite rsync o scp. Un repository locale è utile come passaggio intermedio finché il server Git non viene distribuito dallo stesso Puppet. In un certo senso, questo ricorda l'assemblaggio di un compilatore in più fasi.

Installazione da zero su un sistema pulito

Il modulo cfpuppetserver ti permette di installare tutto utilizzando Puppet stesso, ma per l'installazione iniziale le operazioni di base sono duplicate da uno script Bash.

Sul sistema di destinazione:

Scarica lo script di installazione: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Esaminiamo lo script e aggrottiamo le sopracciglia: less setup_puppetserver.sh
Esegui: bash setup_puppetserver.sh
pupazzo.$(MY_DOMAIN) .
- Esempio con un repository remoto: bash setup_puppetserver.sh ssh:// [e-mail protetta]/puppet-conf
- Esempio con locale: bash setup_puppetserver.sh file:///root/puppetconf/
Vediamo come il sistema si gonfia e non installa tutto molto velocemente.
Se il repository è remoto:
- Crea una chiave SSH per root: ssh-keygen -t rsa -b 2048
- Registriamo la chiave pubblica /root/.ssh/id_rsa.pub sul server Git remoto...
- ... e lì impostiamo un hook Git chiamando il seguente comando: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Iniziamo a distribuire la configurazione manualmente: /etc/puppetlabs/deploy.sh
Proviamo come funziona sul server stesso: /opt/puppetlabs/bin/puppet agent --test
Controlla le impostazioni di rete, protettore di sovratensione e accesso SSH

Aggiunta di nodi gestiti

Il nome completo del Puppet Server deve essere disponibile tramite DNS sull'host gestito o codificato in /etc/hosts.
- Esempio: echo "128.1.1.1 pupazzo.esempio.com" >> /etc/hosts
Sul nodo con Puppet Server, eseguire il seguente script /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Copia l'intero risultato e incollalo in riga di comando sul sistema di destinazione.
Aspettiamo la fine dell'esecuzione ed eseguiamo /opt/puppetlabs/bin/puppet agent --test . Al primo avvio verrà generata una richiesta di firma del certificato.
Andiamo al nodo Puppet Server per firmare il certificato.
- Elenco dei certificati dei burattini: controlliamo la firma del certificato per ulteriore paranoia.
- segno del certificato pupazzo $(HOST_NAME).$(MY_DOMAIN) - in realtà, firmiamo il certificato.
Ritorniamo al nodo gestito ed eseguiamo di nuovo: /opt/puppetlabs/bin/puppet agent --test`. Ciò forzerà l'avvio della procedura di distribuzione.
Stiamo aspettando il completamento della distribuzione tramite Puppet Agent.
Questo è tutto, hai già pronta un'infrastruttura Puppet minima!

Esempio di output da /root/genclientinit.sh

bash</etc/cflocation fi se prova! -z""; quindi echo -n >/etc/cflocationpool fi if test! -z "\$http_proxy"; quindi esporta http_proxy esporta https_proxy="\$http_proxy" esporta HTTP_PROXY="\$http_proxy" esporta HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! quale versione lsb | Leggere; quindi apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; quindi echo "Impossibile rilevare il nome in codice corretto" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(nome in codice).deb dpkg -i pupazzolabs-release-pc1-\$(nome in codice) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<segno certificato pupazzo host.example.com" echo "Usa CTRL+C per interrompere il ciclo, se fallisce per motivi diversi" sleep 5 done EOT

Descrizione del modulo

Elenco completo dei parametri Bash per lo script di installazione iniziale

~# ./setup_puppetserver.sh Utilizzo: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - URI del repository Git
certname: nome di dominio completo dell'host
cflocation - inizializzazione del fatto cf_location
cflocationpool - inizializzazione del fatto cf_location_pool
http_proxy: server proxy per richieste HTTP e HTTPS

Elenco completo dei parametri Bash per lo script di inizializzazione del client Puppet

~# /root/genclientinit.sh Utilizzo: ./genclientinit.sh [ [ []]]
Il significato dei parametri è lo stesso dello script precedente.

classe cfpuppetserver

deployuser = "deploypuppet" - nome utente per la distribuzione automatica degli aggiornamenti di configurazione
deployuser_auth_keys = undef - elenco di chiavi per $deployuser
repo_url = undef - URI del repository (esempio: ssh://utente@host/repo o file:///nome/percorso)
pupazzoserver = true - se installare il componente Puppet Server su questo nodo
pupazzodb = true - se installare il componente PuppetDB su questo nodo
pupazzodb_port = 8081 - porta per PuppetDB
setup_postgresql = true - se installare il componente PostgreSQL su questo nodo (solo se l'installazione PuppetDB è abilitata)
service_face = "any" - nome della risorsa cfnetwork::iface per accettare le connessioni in entrata
pupazzoserver_mem = auto - RAM per Puppet Server in megabyte (minimo 192 MB)
pupazzodb_mem = auto - RAM per PuppetDB in megabyte (minimo 192 MB)
postgresql_mem = auto - RAM per PostgreSQL in megabyte (minimo 128 MB)

classe cfpuppetserver::puppetdb

postgresql_host = "localhost" - indirizzo del database
postgresql_listen = $postgresql_host - il valore va direttamente alla direttiva PostgreSQL listen_addresses
postgresql_port = 5432 - porta del database
postgresql_user = "puppetdb" - Utente PuppetDB nel database
postgresql_pass = "puppetdb" - password dell'utente PuppetDB nel database
postgresql_ssl = false - abilita la crittografia della connessione basata sui certificati PKI Puppet

classe cfpuppetserver::puppetserver

autosign = false - NON DEVE essere utilizzato in un ambiente di combattimento, tranne forse nella DMZ. Esiste esclusivamente per l'automazione dei test.
global_hiera_config = "cfpuppetserver/hiera.yaml" - il percorso del file di configurazione Hiera predefinito secondo i canoni Puppet (il primo componente è il nome del modulo, il resto è il percorso sotto la cartella files/ nel modulo)

Puoi aiutare e trasferire alcuni fondi per lo sviluppo del sito

Gestire un gran numero di sistemi Unix non può essere definito conveniente. Per modificare un parametro, l'amministratore deve contattare ciascuna macchina; gli script possono aiutare solo parzialmente e non in tutte le situazioni.

Va riconosciuto che gli amministratori di rete Windows si trovano ancora in una posizione più vantaggiosa. È sufficiente modificare le impostazioni dei criteri di gruppo e dopo un po' tutti i computer della rete, compresi quelli con un sistema operativo installato di recente, “impararanno” l'innovazione, se ovviamente li riguarda. Guardando indietro al lungo periodo di sviluppo di Unix, noterai che nulla di simile ha mai preso piede. Esistono soluzioni come kickstart che aiutano con l'installazione iniziale sistema operativo, ma un ulteriore perfezionamento richiederà uno sforzo significativo. Soluzioni commerciali come BladeLogic e OpsWare risolvono solo parzialmente il problema dell'automazione delle impostazioni; il loro vantaggio principale è la disponibilità GUI e possono essere acquistati solo da grandi organizzazioni. Naturalmente esistono progetti che offrono soluzioni gratuite, ma nel corso della loro esistenza non sono mai riusciti a creare una grande comunità. Ad esempio, Cfengine non è molto popolare tra gli amministratori, sebbene oltre a Linux possa essere utilizzato in *BSD, Windows e Mac OS X. Ciò potrebbe essere dovuto alla relativa complessità della creazione delle configurazioni. Quando si descrivono le attività, è necessario tenere conto delle caratteristiche di ciascun sistema specifico e controllare manualmente la sequenza delle azioni durante l'esecuzione dei comandi. Cioè, l'amministratore deve ricordare che per alcuni sistemi è necessario scrivere adduser, per altri useradd, tenere conto della posizione dei file su sistemi diversi e così via. Ciò complica il processo di scrittura dei comandi di un ordine di grandezza; è molto difficile creare al volo la configurazione corretta ed è quasi impossibile leggere le configurazioni create dopo un po'. Nonostante la licenza GPL, Cfengine è in realtà un progetto individuale che controlla tutti i cambiamenti e non è molto interessato a costruire una società aperta. Di conseguenza, le capacità di cfengine sono abbastanza soddisfacenti per lo sviluppatore, ma per gli altri amministratori rappresentano un ulteriore grattacapo. Per migliorare cfengine, sono stati creati diversi componenti aggiuntivi da sviluppatori di terze parti, che spesso hanno solo peggiorato la situazione. L'autore di numerosi moduli simili per cfengine, Luke Kanies, alla fine ha deciso di sviluppare uno strumento simile, ma senza molti dei difetti di cfengine.

Caratteristiche delle marionette

Puppet, come cfengine, è un sistema client-server che utilizza un linguaggio dichiarativo, ovvero obbligatorio per descrivere attività e librerie per la loro implementazione. I client periodicamente (30 minuti per impostazione predefinita) si connettono al server centrale e ricevono la configurazione più recente. Se le impostazioni ricevute non corrispondono allo stato del sistema, verranno eseguite e, se necessario, verrà inviato al server un report sulle operazioni eseguite. Il server può salvare i messaggi in syslog o in un file, creare un grafico RRD e inviarli a un'e-mail specifica. Ulteriori livelli di astrazione transazionale e di risorse forniscono la massima compatibilità con le impostazioni e le applicazioni esistenti, consentendoti di concentrarti sugli oggetti di sistema senza preoccuparti delle differenze nell'implementazione e nella descrizione di comandi dettagliati e formati di file. L'amministratore opera solo con il tipo di oggetto, Puppet si occupa del resto. Pertanto, il tipo di pacchetto conosce circa 17 sistemi di pacchetti; quello richiesto verrà riconosciuto automaticamente in base alle informazioni sulla versione della distribuzione o del sistema, anche se, se necessario, è possibile forzare il gestore dei pacchetti.

A differenza degli script, che spesso non è possibile utilizzare su altri sistemi, le configurazioni Puppet scritte da amministratori di terze parti funzioneranno, nella maggior parte dei casi, senza problemi su qualsiasi altra rete. Nel ricettario delle marionette [ http://www.reducinglabs.com/trac/puppet/tags/puppet%2Crecipe] esistono già tre dozzine di ricette già pronte. Puppet attualmente supporta ufficialmente i seguenti sistemi operativi e servizi: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo e MySQL, LDAP.

Linguaggio delle marionette

Per andare avanti, devi prima comprendere gli elementi e le capacità di base della lingua. La lingua è una delle punti di forza Fantoccio. Con il suo aiuto vengono descritte le risorse che l'amministratore intende gestire e le azioni. A differenza della maggior parte delle soluzioni simili, Puppet consente al linguaggio di semplificare l'accesso a tutte le risorse simili su qualsiasi sistema in un ambiente eterogeneo. Una descrizione di una risorsa in genere è composta da un nome, un tipo e attributi. Ad esempio, puntiamo al file /etc/passwd e impostiamo i suoi attributi:

file("/etc/passwd":

proprietario => root,

gruppo => radice,

Ora i client, dopo essersi connessi al server, copieranno il file /etc/passwd e installeranno gli attributi specificati. Puoi definire più risorse in un'unica regola, separandole utilizzando un punto e virgola. Cosa fare se il file di configurazione utilizzato sul server differisce da quelli del client o non viene utilizzato affatto? Ad esempio, questa situazione può verificarsi quando Impostazioni VPN connessioni. In questo caso, è possibile puntare al file utilizzando la direttiva source. Qui ci sono due opzioni, come al solito, per specificare il percorso di un altro file; sono supportati anche due protocolli URI: file e pupazzo. Nel primo caso, un collegamento a un file external server NFS, nella seconda opzione, sul server Puppet viene avviato un servizio simile a NFS, che esporta risorse. In quest'ultimo caso, il percorso predefinito è relativo alla directory root del pupazzo - /etc/puppet. Cioè, il collegamento pupazzo://server.domain.com/config/sshd_config corrisponderà al file /etc/puppet/config/sshd_config. È possibile sovrascrivere questa directory utilizzando la direttiva filebucket, sebbene sia più corretto utilizzare la sezione con lo stesso nome nel file /etc/puppet/fileserver.conf. In questo caso puoi limitare l'accesso al servizio solo da determinati indirizzi. Ad esempio, descriviamo la sezione di configurazione.

percorso /var/puppet/config

consentire *.dominio.com

consenti 192.168.0.*

consentire 192.168.1.0/24

negare *.wireless.dominio.com

E poi ci rivolgiamo a questa sezione quando descriviamo la risorsa.

sorgente => "puppet://server.domain.com/config/sshd_config"

Prima dei due punti c'è il nome della risorsa. Nei casi più semplici, puoi semplicemente specificare un alias o variabili come nome. L'alias viene impostato utilizzando la direttiva alias. percorso completo del file. In configurazioni più complesse

file("/etc/passwd":

alias => password

Un'altra opzione per creare un alias è utile quando hai a che fare con diversi sistemi operativi. Ad esempio, creiamo una risorsa che descrive il file sshd_config:

file(sshdconfig:

nome => $sistema operativo ? (

solaris => "/usr/local/etc/ssh/sshd_config",

predefinito => "/etc/ssh/sshd_config"

In questo esempio siamo di fronte ad una scelta. Il file per Solaris viene specificato separatamente, per tutti gli altri verrà selezionato il file /etc/ssh/sshd_config. Ora è possibile accedere a questa risorsa come sshdconfig, a seconda del sistema operativo verrà selezionato il percorso desiderato. Ad esempio, indichiamo che se il demone sshd è in esecuzione e ricevuto nuovo file, dovresti riavviare il servizio.

garantire => vero,

iscriviti => File

Le variabili vengono spesso utilizzate quando si lavora con i dati utente. Ad esempio, descriviamo la posizione delle directory home dell'utente:

$radicecasa = "/casa"

Ora è possibile accedere ai file di un utente specifico come

$(homeroot)/$nome

Il parametro $name verrà riempito con il nome dell'account dell'utente. In alcuni casi è conveniente definire un valore predefinito per alcuni tipi. Ad esempio, per il tipo exec, spesso indicano le directory in cui cercare il file eseguibile:

Exec (percorso => "/usr/bin:/bin:/usr/sbin:/sbin")

Se è necessario puntare a più file e directory nidificati, è possibile utilizzare il parametro recurse.

file("/etc/apache2/conf.d":

source => “puppet:// pupazzo://server.domain.com/config/apache/conf.d”,

ricorsivo => "vero"

Più risorse possono essere combinate in classi o definizioni. Le classi rappresentano una descrizione completa di un sistema o servizio e vengono utilizzate separatamente.

"/etc/passwd": proprietario => root, gruppo => root, modalità => 644;

"/etc/shadow": proprietario => root, gruppo => root, modalità => 440

Come nei linguaggi orientati agli oggetti, le classi possono essere sovrascritte. Ad esempio, su FreeBSD il proprietario del gruppo di questi file è wheel. Pertanto, per non riscrivere completamente la risorsa, creiamo una nuova classe freebsd, che erediterà la classe linux:

la classe freebsd eredita linux (

File[“/etc/passwd”] (gruppo => ruota);

File[“/etc/shadow”] (gruppo => ruota)

Per comodità, tutte le classi possono essere inserite in un file separato, che può essere collegato utilizzando la direttiva include. Le definizioni possono accettare più parametri come argomenti, ma non supportano l'ereditarietà e vengono utilizzate quando è necessario descrivere oggetti riutilizzabili. Ad esempio, definiamo la directory home degli utenti e i comandi necessari per creare un nuovo account.

definire user_homedir ($gruppo, $nome completo, $ingroup) (

utente("$nome":

garantire => presente,

commento => "$nome completo",

gid => "$gruppo",

gruppi => $ingruppi,

abbonamento => minimo,

shell => "/bin/bash",

casa => "/casa/$nome",

richiedono => Gruppo[$gruppo],

exec("$nomedircasa":

comando => “/bin/cp -R /etc/skel /home/$nome; /bin/chown -R $nome:$gruppo /home/$nome",

crea => "/home/$nome",

richiedono => Utente[$nome],

Ora per crearne uno nuovo account basta contattare user_homedir.

user_homedir("sergej":

gruppo => "sergej",

nome completo => “Sergej Jaremchuk”,

ingroup => ["media", "admin]

Esistono descrizioni separate dei nodi che supportano l'ereditarietà come le classi. Quando un client si connette al server Puppet, verrà cercata la sezione del nodo corrispondente e verranno fornite le impostazioni specifiche solo per questo computer. Per descrivere tutti gli altri sistemi, è possibile utilizzare node default. Una descrizione di tutti i tipi è fornita nel documento “Type Reference”, che deve essere letto in ogni caso, almeno per comprendere tutte le funzionalità del linguaggio Puppet. Vari tipi consentire di eseguire comandi specifici, anche quando vengono soddisfatte determinate condizioni (ad esempio, modifica di un file di configurazione), lavorare con cron, credenziali e gruppi utente, computer, montare risorse, avviare e arrestare servizi, installare, aggiornare e rimuovere pacchetti, lavorare con Chiavi SSH, zone Solaris e così via. Ecco quanto è semplice forzare l'aggiornamento dell'elenco dei pacchetti nelle distribuzioni utilizzando apt ogni giorno tra le 2 e le 4 ore.

programma (giornaliero:

periodo => giornaliero,

intervallo =>

exec("/usr/bin/apt-get aggiornamento":

programma => giornaliero

L'aggiornamento per tale periodo verrà eseguito da ciascun sistema una sola volta, dopodiché l'attività verrà considerata completata e verrà eliminata dal computer client. Il linguaggio Puppet supporta altre strutture familiari: condizioni, funzioni, array, commenti e simili.

Installazione di Puppet

Puppet richiede Ruby (>= 1.8.1) con supporto OpenSSL e librerie XMLRPC, oltre alla libreria Faster [ http://reductionlabs.com/projects/facter]. Il repository Ubuntu 7.04 utilizzato per l'installazione di prova includeva già il pacchetto cucciolo.

$ sudo apt-cache marionetta di ricerca

pupazzo: gestione centralizzata della configurazione per le reti

burattinaio: demone di controllo della gestione della configurazione centralizzata

Durante l'installazione verranno installati tutti i pacchetti di dipendenze necessari: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install burattinaio burattinaio

Puoi verificare la disponibilità delle librerie Ruby con il comando.

$ ruby -ropenssl -e "mette: sì"

~$ ruby -rxmlrpc/client -e "mette: sì"

Se non vengono ricevuti errori, tutto ciò di cui hai bisogno è già incluso. I file che descrivono la configurazione desiderata dei sistemi sono chiamati manifest nella terminologia Puppet. Quando viene avviato, il demone tenta di leggere il file /etc/puppet/manifests/site.pp; se manca, visualizza un messaggio di avviso. Durante il test, puoi dire al demone di funzionare in modalità offline, nel qual caso il manifest non è richiesto

$ sudo /usr/bin/puppetmasterd --nonodes

Se necessario, puoi collegare altri file a site.pp, ad esempio con le descrizioni delle classi. Per un'esecuzione di prova, è possibile inserire le istruzioni più semplici in questo file.

file("/etc/sudoers":

proprietario => root,

gruppo => radice,

Tutti i file di configurazione sia per il server che per i client si trovano in /etc/puppet. Il file fileserver.conf di cui abbiamo parlato sopra è facoltativo e viene utilizzato solo se Puppet funzionerà anche come file server. Su Ubuntu, questo file esporta la sottodirectory /etc/puppet/files. La sottodirectory SSL contiene certificati e chiavi che verranno utilizzati per la crittografia durante la connessione dei client. Le chiavi vengono create automaticamente la prima volta che avvii burattinaio; puoi crearle manualmente con il comando.

$ sudo /usr/bin/ burattinaio --mkusers.

I file Puppetd.conf e Puppetmasterd.conf sono simili. Indicano alcuni parametri per il funzionamento dei demoni sul sistema client e sul server. Il file client differisce solo per la presenza del parametro server, che punta al computer su cui è in esecuzione Puppetmasterd.

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/esegui

# invia un rapporto al server

Per evitare di digitare tutto manualmente, puoi creare un modello utilizzando lo stesso pupazzo.

$ pupazzo --genconfig > /etc/puppet/puppetd.conf

Allo stesso modo, puoi creare site.pp sul server.

$ pupazzo --genmanifest > /etc/puppet/manifests/site.pp

Un altro file, tagmail.conf, consente di specificare gli indirizzi email a cui verranno inviati i report. Nel caso più semplice, puoi utilizzare una riga.

Tutto: [e-mail protetta]

I file di configurazione non sono sufficienti per consentire al client di connettersi al server. Per fare ciò è necessario firmare anche i certificati. Innanzitutto, per far conoscere al server il nuovo computer sul sistema client, inserisci il comando:

$ sudo pupazzo --server grinder.com --waitforcert 60 --test

info: Richiesta certificato

avviso: il certificato peer non verrà verificato in questa sessione SSL

avviso: non ho ricevuto il certificato

Se viene restituita una riga diversa, è necessario verificare il funzionamento del server.

$ps aux | burattino grep

burattino 5779 0.0 1.4 27764 15404 ? Ssl 21:49 0:00 ruby /usr/sbin/puppetmasterd

Il firewall deve consentire le connessioni sulla porta 8140.

Sul server riceviamo un elenco di certificati che devono essere firmati.

$ sudo pupazzo --list

nomad.grinder.com

E firmiamo il certificato client.

$ sudo pupazzo –sign nomad.grinder.com

Ora il client può connettersi liberamente al server e ricevere le impostazioni.

Sfortunatamente, semplicemente non è possibile mostrare tutte le funzionalità di Puppet all'interno dell'articolo. Ma come puoi vedere, si tratta di uno strumento funzionale e flessibile che consente di risolvere la maggior parte dei problemi di amministrazione simultanea di un gran numero di sistemi. Se il tuo lavoro richiede la configurazione di diversi sistemi. E, cosa più importante, il progetto è riuscito a riunire una comunità piccola ma in costante crescita. Speriamo quindi che una buona idea non venga lasciata morire o andare da parte.

Fantoccioè una struttura multipiattaforma che consente amministratori di sistema Esegui attività comuni utilizzando il codice. Il codice consente di eseguire varie attività, dall'installazione di nuovi programmi al controllo dei permessi dei file o all'aggiornamento degli account utente. Fantoccio superiore non solo durante l’installazione iniziale del sistema, ma durante l’intero ciclo di vita del sistema. Nella maggior parte dei casi fantoccio utilizzato nella configurazione client/server.

Questa sezione mostra l'installazione e la configurazione Fantoccio in una configurazione client/server. Questo semplice esempio dimostra come installare Apache utilizzando Fantoccio.

Installazione

Per l'installazione Fantoccio inserire nel terminale:

Sudo apt-get install burattinaio

Sui computer client, immettere:

Sudo apt-get install pupazzo

Impostazioni

Prima di configurare il pupazzo potresti voler aggiungere una voce DNS CNAME Per pupazzo.esempio.com, Dove esempio.com- questo è il tuo dominio. Clienti predefiniti Fantoccio controlla il DNS per pupazzo.esempio.com come nome del server pupazzo ( Burattinaio). Consulta Domain Name Service per ulteriori dettagli sull'utilizzo del DNS.

Se non intendi utilizzare DNS, puoi aggiungere voci al file /etc/hosts sul server e sul client. Ad esempio, nel file /etc/hosts Fantoccio il server aggiunge:

127.0.0.1 localhost.localdomain localhost pupazzo 192.168.1.17 meercat02.example.com meercat02

Su ogni Fantoccio Nel client, aggiungi una voce per il server:

192.168.1.16 meercat.example.com suricato pupazzo

Sostituisci gli indirizzi IP e nomi di dominio dall'esempio agli indirizzi e ai nomi attuali del server e dei client.

Ora impostiamo alcune risorse per apache2. Crea un file /etc/puppet/manifests/site.pp contenente quanto segue:

Pacchetto ( "apache2": Guarantee => installato) servizio ( "Apache2": Guarantee => true, abilita => true, require => Pacchetto["Apache2"])

Nodo "meercat02.example.com" (include apache2)

Sostituire meercat02.esempio.com al tuo nome attuale Fantoccio cliente.

Il passaggio finale per questo semplice Fantoccio server è riavviare il servizio:

Sudo /etc/init.d/puppetmaster riavviare

Ora avanti Fantoccio tutto è configurato sul server ed è ora di configurare il client.

Innanzitutto, configuriamo il servizio Fantoccio agente da avviare. Modifica /etc/default/puppet, sostituendo il valore INIZIO SU SÌ:

Sudo /etc/init.d/puppet start

Torniamo a Fantoccio server per firmare il certificato client utilizzando il comando:

Sudo pupazzo --sign meercat02.example.com

Controllo /var/log/syslog per eventuali errori di configurazione. Se tutto è andato bene, il pacco apache2 e le sue dipendenze verranno installate Fantoccio cliente.

Questo esempio è molto semplice e non mostra molte delle funzionalità e dei vantaggi. Fantoccio. Per Informazioni aggiuntive Aspetto

Sergey Yaremchuk

Configurazione centralizzata di sistemi UNIX tramite Puppet

Gestire un gran numero di sistemi UNIX non può essere definito conveniente. Per modificare un parametro, l'amministratore deve contattare ciascuna macchina; gli script possono aiutare solo parzialmente e non in tutte le situazioni.

Va riconosciuto che gli amministratori di rete Windows si trovano ancora in una posizione più vantaggiosa. È sufficiente modificare le impostazioni dei criteri di gruppo e dopo un po 'tutti i computer della rete, compresi quelli con un sistema operativo installato di recente, "impararanno" l'innovazione, se li riguarda, ovviamente. Guardando indietro al lungo periodo di sviluppo di UNIX, puoi vedere che nulla di simile ha mai preso piede. Esistono soluzioni come kickstart che aiutano con l'installazione iniziale del sistema operativo, ma un ulteriore sviluppo richiederà uno sforzo significativo. Le soluzioni commerciali, come BladeLogic e OpsWare, risolvono solo parzialmente il problema dell'automazione delle impostazioni; il loro vantaggio principale è la presenza di un'interfaccia grafica e solo le grandi organizzazioni possono permettersi di acquistarle. Naturalmente ci sono progetti che offrono soluzioni gratuite, ma nel corso della loro esistenza non sono riusciti a creare una grande comunità. Ad esempio, Cfengine non è molto popolare tra gli amministratori, sebbene, oltre a Linux, possa essere utilizzato in *BSD, Windows e Mac OS X. Ciò potrebbe essere dovuto alla relativa complessità della creazione delle configurazioni. Quando si descrivono le attività, è necessario tenere conto delle caratteristiche di ciascun sistema specifico e controllare manualmente la sequenza delle azioni durante l'esecuzione dei comandi. Cioè, l'amministratore deve ricordare che per alcuni sistemi dovresti scrivere adduser, per altri - useradd, tenere conto della posizione dei file su sistemi diversi e così via. Ciò complica il processo di scrittura dei comandi di un ordine di grandezza; è molto difficile creare al volo la configurazione corretta ed è quasi impossibile leggere le configurazioni create dopo un po'. Nonostante la licenza GPL, Cfengine è essenzialmente un progetto individuale che controlla tutti i cambiamenti e non è molto interessato a costruire una società aperta. Di conseguenza, le capacità di Cfengine sono abbastanza soddisfacenti per lo sviluppatore, ma per gli altri amministratori questo è piuttosto un ulteriore grattacapo. Per migliorare Cfengine, sono stati creati diversi componenti aggiuntivi da sviluppatori di terze parti, che spesso hanno solo peggiorato la situazione. L'autore di numerosi moduli di questo tipo per Cfengine, Luke Kanies, alla fine ha deciso di sviluppare uno strumento simile, ma senza molti dei difetti di Cfengine.

Caratteristiche delle marionette

Puppet, come Cfengine, è un sistema client-server che utilizza un linguaggio dichiarativo per descrivere attività e librerie per implementarle. I client periodicamente (ogni 30 minuti per impostazione predefinita) si connettono al server centrale e ricevono la configurazione più recente. Se le impostazioni ricevute non corrispondono allo stato del sistema, verranno eseguite e, se necessario, verrà inviato al server un report sulle operazioni eseguite. Il server dei messaggi può salvarlo in syslog o in un file, creare un grafico RRD e inviarlo all'e-mail specificata. Ulteriori livelli di astrazione transazionale e di risorse forniscono la massima compatibilità con le impostazioni e le applicazioni esistenti, consentendoti di concentrarti sugli oggetti di sistema senza preoccuparti delle differenze nell'implementazione e nella descrizione di comandi dettagliati e formati di file. L'amministratore opera solo con il tipo di oggetto, Puppet si occupa del resto. Pertanto, il tipo di pacchetto conosce circa 17 sistemi di pacchetti; quello richiesto verrà riconosciuto automaticamente in base alle informazioni sulla versione della distribuzione o del sistema, sebbene, se necessario, il gestore dei pacchetti possa essere impostato forzatamente.

A differenza degli script, che spesso sono impossibili da utilizzare su altri sistemi, le configurazioni Puppet scritte da amministratori di terze parti funzioneranno per lo più senza problemi su qualsiasi altra rete. Puppet CookBook ha già tre dozzine di ricette già pronte. Puppet attualmente supporta ufficialmente i seguenti sistemi operativi e servizi: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo e MySQL, LDAP.

Linguaggio delle marionette

Per andare avanti, devi prima comprendere gli elementi e le capacità di base della lingua. Il linguaggio è uno dei punti di forza di Puppet. Descrive le risorse che l'amministratore intende gestire e le azioni da intraprendere. A differenza della maggior parte delle soluzioni simili, Puppet consente al linguaggio di semplificare l'accesso a tutte le risorse simili su qualsiasi sistema in un ambiente eterogeneo. Una descrizione di una risorsa in genere è composta da un nome, un tipo e attributi. Ad esempio, puntiamo al file /etc/passwd e impostiamo i suoi attributi:

file("/etc/passwd":

Proprietario => root,

Gruppo => radice,

Modalità => 644,

Ora i client che si connettono al server copieranno il file /etc/passwd e imposteranno gli attributi specificati. Puoi definire più risorse in un'unica regola, separandole utilizzando un punto e virgola. Ma cosa succede se il file di configurazione utilizzato sul server differisce da quelli del client o non viene utilizzato affatto? Questa situazione può verificarsi, ad esempio, durante la configurazione delle connessioni VPN. In questo caso, dovresti puntare al file utilizzando la direttiva source. Ci sono due opzioni qui; puoi, come al solito, specificare il percorso di un altro file e anche utilizzare i due protocolli URI supportati: file e pupazzo. Nel primo caso viene utilizzato un collegamento a un server NFS esterno; nella seconda opzione viene lanciato un servizio simile a NFS sul server Puppet che esporta risorse. In quest'ultimo caso, il percorso predefinito è relativo alla directory root del pupazzo – /etc/puppet. Cioè, il collegamento pupazzo://server.domain.com/config/sshd_config corrisponderà al file /etc/puppet/config/sshd_config. È possibile sovrascrivere questa directory utilizzando la direttiva filebucket, sebbene sia più corretto utilizzare la sezione con lo stesso nome nel file /etc/puppet/fileserver.conf. In questo caso, puoi limitare l'accesso al servizio solo a determinati indirizzi. Ad esempio, descriviamo la sezione di configurazione:

Percorso /var/puppet/config

Consenti *.dominio.com

Consenti 127.0.0.1

Consenti 192.168.0.*

Consenti 192.168.1.0/24

Nega *.wireless.dominio.com

E poi facciamo riferimento a questa sezione quando descriviamo la risorsa:

sorgente => "puppet://server.domain.com/config/sshd_config"

Prima dei due punti c'è il nome della risorsa. Nei casi più semplici, puoi semplicemente specificare il percorso completo del file come nome. Nelle configurazioni più complesse è meglio utilizzare un alias o variabili. L'alias viene impostato utilizzando la direttiva alias:

file("/etc/passwd":

Alias => passwd

Un'altra opzione per creare un alias è utile quando hai a che fare con diversi sistemi operativi. Ad esempio, creiamo una risorsa che descrive il file sshd_config:

file(sshdconfig:

Nome => $sistemaoperativo? (

Solaris => "/usr/local/etc/ssh/sshd_config",

Predefinito => "/etc/ssh/sshd_config"

In questo esempio siamo di fronte ad una scelta. Il file per Solaris viene specificato separatamente, per tutti gli altri verrà selezionato il file /etc/ssh/sshd_config. Ora è possibile accedere a questa risorsa come sshdconfig, a seconda del sistema operativo verrà selezionato il percorso desiderato. Ad esempio, indichiamo che se il demone sshd è in esecuzione e viene ricevuto un nuovo file, il servizio deve essere riavviato:

servizio(sshd:

Assicurati => vero,

Iscriviti => File

Le variabili vengono spesso utilizzate quando si lavora con i dati utente. Ad esempio, descriviamo la posizione delle directory home dell'utente:

$radicecasa = "/casa"

Ora è possibile accedere ai file di un utente specifico come:

$(homeroot)/$nome

Il parametro $name verrà riempito con il nome dell'account dell'utente. In alcuni casi è conveniente definire un valore predefinito per alcuni tipi. Ad esempio, per il tipo exec è molto comune specificare le directory in cui deve cercare il file eseguibile:

Exec ( percorso => "/usr/bin:/bin:/usr/sbin:/sbin" )

Se è necessario puntare a più file e directory nidificati, è possibile utilizzare il parametro ricorsivo:

file("/etc/apache2/conf.d":

Fonte => "puppet:// pupazzo://server.domain.com/config/apache/conf.d",

Ricorsione => "vero"

Più risorse possono essere combinate in classi o definizioni. Le classi sono una descrizione completa di un sistema o servizio e vengono utilizzate separatamente:

classe Linux (

File (

"/etc/passwd": proprietario => root, gruppo => root, modalità => 644;

"/etc/shadow": proprietario => root, gruppo => root, modalità => 440

la classe freebsd eredita linux (

File["/etc/passwd"] (gruppo => ruota);

File["/etc/shadow"] (gruppo => ruota)

Per comodità, tutte le classi possono essere inserite in un file separato, che deve essere incluso utilizzando la direttiva include. Le definizioni possono accettare più parametri come argomenti, ma non supportano l'ereditarietà e vengono utilizzate quando è necessario descrivere oggetti riutilizzabili. Ad esempio, definiamo la directory home dell'utente e i comandi necessari per creare un nuovo account:

definire user_homedir ($gruppo, $nome completo, $ingroup) (

Utente("$nome":

Garantire => presente,

Commento => "$nome completo",

Gid => "$gruppo",

Gruppi => $ingroup,

Iscrizione => minimo,

Shell => "/bin/bash",

Casa => "/casa/$nome",

Richiedi => Gruppo[$gruppo],

Exec("$nomedircasa":

Comando => "/bin/cp -R /etc/skel /home/$nome; /bin/chown -R $nome:$gruppo /home/$nome",

Crea => "/home/$nome",

Richiedi => Utente[$nome],

Ora, per creare un nuovo account, basta accedere a user_homedir:

user_homedir("sergej":

Gruppo => "sergej",

Nome completo => "Sergej Jaremchuk",

Ingroup => ["media", " amministratore]

Esistono descrizioni separate dei nodi che supportano l'ereditarietà, nonché delle classi. Quando un client si connette al server Puppet, verrà cercata la sezione del nodo corrispondente e verranno fornite le impostazioni specifiche solo per questo computer. Per descrivere tutti gli altri sistemi, è possibile utilizzare node default. Una descrizione di tutti i tipi è fornita nel documento “Type Reference”, che deve essere letto in ogni caso, almeno per comprendere tutte le funzionalità del linguaggio Puppet. Vari tipi consentono di eseguire comandi specifici, anche quando vengono soddisfatte determinate condizioni (ad esempio, la modifica di un file di configurazione), lavorare con cron, credenziali e gruppi utente, computer, montaggio di risorse, avvio e arresto di servizi, installazione, aggiornamento e rimozione di pacchetti , lavorando con chiavi SSH, zone Solaris e così via. In questo modo puoi forzare facilmente l'aggiornamento quotidiano dell'elenco dei pacchetti nelle distribuzioni utilizzando apt tra 2 e 4 ore:

programma (giornaliero:

Periodo => giornaliero,

Gamma =>

exec("/usr/bin/apt-get aggiornamento":

Programma => giornaliero

Installazione di Puppet

Puppet richiede Ruby (versione 1.8.1 e successive) con supporto OpenSSL e librerie XMLRPC, oltre alla libreria Faster. Il repository Ubuntu 7.04 utilizzato per l'installazione di prova include già il pacchetto cucciolo:

$ sudo apt-cache marionetta di ricerca

~$ ruby -rxmlrpc/client -e "mette: sì"

Sì

Se non vengono ricevuti errori, tutto ciò di cui hai bisogno è già incluso. I file che descrivono la configurazione desiderata dei sistemi sono chiamati manifest nella terminologia Puppet. Quando viene avviato, il demone tenta di leggere il file /etc/puppet/manifests/site.pp; se manca, visualizza un messaggio di avviso. Durante il test, puoi dire al demone di essere eseguito in modalità autonoma, che non richiede un manifest:

$ sudo /usr/bin/puppetmasterd --nonodes

Se necessario è possibile collegare altri file a site.pp, ad esempio con le descrizioni delle classi. Per un'esecuzione di prova, è possibile inserire le istruzioni più semplici in questo file.

classe sudo (

File("/etc/sudoers":

Proprietario => root,

Gruppo => radice,

Modalità => 440,

nodo predefinito (

Includi sudo

Tutti i file di configurazione, sia server che client, si trovano in /etc/puppet. Il file fileserver.conf, di cui abbiamo già parlato, è facoltativo e viene utilizzato solo se Puppet funzionerà anche come file server. Su Ubuntu, questo file esporta la sottodirectory /etc/puppet/files. La sottodirectory SSL contiene certificati e chiavi che verranno utilizzati per la crittografia durante la connessione dei client. Le chiavi vengono create automaticamente la prima volta che avvii burattinaio; puoi crearle manualmente con il comando:

$ sudo /usr/bin/puppetmasterd --mkusers

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/esegui

# invia un rapporto al server

rapporto = vero

Per evitare di digitare tutto manualmente, puoi creare un modello utilizzando il pupazzo stesso:

$ pupazzo --genconfig > /etc/puppet/puppetd.conf

Allo stesso modo, puoi creare site.pp sul server:

$ pupazzo --genmanifest > /etc/puppet/manifests/site.pp

Un altro file, tagmail.conf, consente di specificare gli indirizzi email a cui verranno inviati i report. Nel caso più semplice, puoi utilizzare una riga:

Tutto: [e-mail protetta]

I file di configurazione non sono sufficienti per consentire al client di connettersi al server. Per fare ciò è necessario firmare anche i certificati.

Per prima cosa, per far sapere al server del nuovo computer, inserisci il comando sul sistema client:

$ sudo pupazzo --server grinder.com --waitforcert 60 –test

Il firewall deve consentire le connessioni sulla porta 8140.

Sul server otteniamo un elenco di certificati che devono essere firmati:

$ sudo pupazzo –list

nomad.grinder.com

E firma il certificato client:

$ sudo pupazzo –sign nomad.grinder.com

Ora il client può connettersi liberamente al server e ricevere le impostazioni.

Sfortunatamente, è impossibile mostrare tutte le funzionalità di Puppet all'interno dell'articolo. Ma, come puoi vedere, si tratta di uno strumento funzionale e flessibile che consente di risolvere la maggior parte dei problemi di amministrazione simultanea di un gran numero di sistemi. E, cosa più importante, il progetto è riuscito a riunire una comunità piccola ma in costante crescita. Speriamo quindi che una buona idea non venga lasciata morire o andare da parte.

Buona fortuna!

Sito web del progetto BladeLogic – http://www.bladelogic.com.
Il sito web del progetto OpsWare è http://www.opsware.com.
Il sito web del progetto Cfengine è http://www.cfengine.org.
Il sito web del progetto Puppet è http://reductionlabs.com/projects/puppet.
Libro di ricette delle marionette - http://www.reducinglabs.com/trac/puppet/tagspuppet%2Crecipe.
Libreria più veloce –