7.8 KiB
Puppet-deploy
Ovvero della centralizzazione, automazione e documentazione delle configurazioni di un server autogestito
Requisiti
Puppet
- Puppet
- Puppet modules
- puppet masterless
- puppet masterless server automation on a very small scale
Git
gcrypt
- Github
- In Debian 7.x Wheezy si installa da backports
MyRepos
Riseup shared puppet modules
Presupposti
- Semplificare l'installazione l'installazione di un nuovo server
- Semplificare la reinstallazione di un server esistente
- Mantenere logica, dati e configurazioni separati
- Avere un versioning delle confgiurazioni
- Facilitare la collaborazione degli amministratori nel mantenimento dei server/servizi
- Facilitare la collaborazione nello sviluppo degli strumenti
- Collaborare con gli altri collettivi/server/reti
- Evitare Single Point of Failure
- Non creare tool nuovi, utilizzare l'esistente (soprattutto se conosciuto)
Architettura
MyRepos
- Tutto parte dalla configurazione di mr, che elenca quali repository scaricare e mantenere aggiornati.
- /root/.mrconfig elenca i repository ed e' parametrizzato in funzione di SITE, HOSTNAME e REPO_ROOT
[DEFAULT] lib = SITE="nome_site" && \ HOSTFQDN="$(hostname --fqdn)" && HOSTNAME="$(hostname)" && \ REPO_ROOT="git@gitlab.com:organization/" [/etc/puppet] checkout = git clone ${REPO_ROOT}/puppet-deploy.git puppet order = 1 [/etc/puppet/site-conf] checkout = git clone gcrypt::${REPO_ROOT}/siteconf-${SITE}.git site-conf order = 2 chain = true [/etc/puppet/site-conf/host-conf] checkout = git clone gcrypt::${REPO_ROOT}/hostconf-${HOSTNAME}.git host-conf order = 3 chain = true [/etc/puppet/modules/common] checkout = git clone ${REPO_ROOT}/module-common.git common order = 4 [/etc/puppet/modules/stdlib] checkout = git clone ${REPO_ROOT}/puppetlabs-stdlib.git stdlib cd stdlib && git checkout tags/4.5.1 order = 4 [/etc/puppet/modules/apt] checkout = git clone ${REPO_ROOT}/module-apt.git apt order = 4 [/etc/puppet/modules/concat] checkout = git clone ${REPO_ROOT}/module-concat.git concat order = 4 [/etc/puppet/modules/lsb] checkout = git clone ${REPO_ROOT}/module-lsb.git lsb order = 4 [/etc/puppet/modules/postfix] checkout = git clone ${REPO_ROOT}/module-postfix.git postfix order = 4
- /root/.mrtrust istruisce myrepos per fidarsi dei file .mrconfig inclusi nei repository di configurazione del sito e dell'host
/etc/puppet/site-conf/.mrconfig /etc/puppet/site-conf/host-conf/.mrconfig
Repository Git
-
[conf, world-wide, clear] puppet-deploy
-
E' il progetto principale in cui viene mantenuta tutta e sola la configurazione di puppet e hiera;
-
Ogni sviluppatore ha un account read-write sul repository centrale di questo progetto;
-
Una copia del repository e' distribuita su ogni server, con account read-only, nella directory
/etc/puppet
(su Debian); -
NON contiene dati sensibili (chiavi e password);
-
NON contiene dati o tabelle utenti;
-
Il file
manifests/site.pp
contiene la dichiarazione di default per i nodi, che include i ruoli definiti nella configurazione [hiera_include('host-roles')
] -
[logic, world-wide, clear] module-$(prog-name)
-
Quando disponibile il clone iniziale deriva da gli shared puppet module
-
Sono i moduli puppet responsabili di una singola funzionalita'/programma
-
Rappresentano il principale luogo di collaborazione nella comunita'. Committare sui moduli upstream significa sviluppare la logica su cui tutti i siti si basano.
-
Es: module-postfix, module-apt, etc.
-
[conf, site-wide, gcrypt] siteconf-$(site-name)
-
Contiene principalmente (solo?) due file:
-
site.yaml: file utilizzato da hiera per determinare le proprieta' e le configurazioni specifiche di un sito
-
.mrconfig: configurazione di myrepos per includere i moduli (repository git) specifici per un sito
-
[logic, site-wide, gcrypt] module-$(site-name)
-
Modulo (o moduli) specifici del sito (es. ortiche), che contiene funzionalita' utili solo per uno specifico gruppo di server;
-
Esistono due differenti filosofie da valurare
-
O questo modulo non dovrebbe esistere e tutte le funzionalita' utili dovrebbero essere portate upstream in un modulo condiviso oppure, se sono specifiche di un server, incluse in un modulo module-$(server-name).
-
Oppure posso utilizzarlo per distribuire le chiavi, file, configurazioni comuni ai server di uno stesso sito
-
Es: module-ortiche
-
[conf, host-wide, gcrypt] hostconf-$(server-name)
-
Contiene principalmente (solo?) due file:
-
host.yaml: file utilizzato da hiera per determinare le proprieta' e le configurazioni specifiche del server
-
.mrconfig: configurazione di myrepos per includere i moduli (repository git) specifici per il server
-
[logic, host-wide, gcrypt] module-$(server-name)
-
Modulo che contiene la logica specifica per un unico server
-
Includo qui i file sensibili per un unico server?
Installare e configurare un nuovo server
Creare la configurazione di un nuovo [site]
Configurazione di un server base, senza moduli specifici per site o host
-
Installare un nuovo server Debian Wheezy
-
Abilitare i backports (necessari per
git-remote-gcrypt
)echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list
-
Aggiungere i repository dei PuppetLabs (per le versioni aggiornate di puppet) `wget https://apt.puppetlabs.com/puppetlabs-release-wheezy.deb && dpkg -i puppetlabs-release-wheezy.deb
-
Creare il file
/etc/apt/preferences.d/00-puppet.pref
con le seguente configurazione: `Package: puppet puppet-common Pin: version 3.7* Pin-Priority: 999Package: facter Pin: version 2.3* Pin-Priority: 999`
-
Aggiornare la lista dei pacchetti disponibili
apt-get update
-
Da root
apt-get install puppet git git-remote-gcrypt myrepos
-
Eliminare i file esistenti per puppet
rm -rf /etc/puppet
-
Generare una nuova coppia di chiavi gpg
gpg --gen-key
-
Configurare sul repository git l'account e i permessi per il nuovo server. Questo passo potrebbe non essere indispensabile, dipende dal repository configurato.
-
Copiare i file
.mrconfig
e.mrtrust
forniti sopra in/root
e configurare le variabiliSITE
eREPO_ROOT
in.mrconfig
. -
Eseguire l'update di tutti i moduli
mr -d /etc/ update
-
Lanciare l'esecuzione di puppet
puppet apply -v /etc/puppet/manifests/site.pp
- Aggiungere la configurazione di un nuovo server in puppet-deploy
- Aggiungere un submodule a puppet-deploy
Appunti
- module naming convention
Dalla documentazione di puppet:
init.pp
is special and always contains a class with the same name as the module. You may not have a class named init.