No description
Find a file
2015-06-29 18:11:19 +02:00
manifests Eliminated some ortiche-specific name, added some site.pp explanation 2015-06-26 00:29:03 +02:00
modules Removed submodules, now managed through mr 2015-01-26 12:23:35 +01:00
.gitignore Hiera conf tree now subdirectory of puppet-deploy 2015-06-26 00:36:02 +02:00
.gitmodules Removed submodules, now managed through mr 2015-01-26 12:23:35 +01:00
etckeeper-commit-post Riaggiunti gli hook 2014-10-27 23:08:28 +01:00
etckeeper-commit-pre Riaggiunti gli hook 2014-10-27 23:08:28 +01:00
hiera.yaml Hiera conf tree now subdirectory of puppet-deploy 2015-06-26 00:36:02 +02:00
puppet.conf first hiera test on puppet 2015-01-07 23:45:26 +01:00
README.md New documentation on architecture 2015-06-29 18:11:19 +02:00

Puppet-deploy

Ovvero della centralizzazione, automazione e documentazione delle configurazioni di un server autogestito

Requisiti

Puppet

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="ortiche" && \
  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?

Workflow

  • Aggiungere uno sviluppatore a opuppet su Gogs
  1. Creare l'utente dalla pagina di registrazione. L'indirizzo email deve essere valido per procedere all'attivazione dell'utente;
  2. Aggiungere l'utente al team "Developer" dell'organizzazione opuppet.
  • Aggiungere un server a opuppet su Gogs
  1. Creare un indirizzo email da associare all'utente. Per esempio, su indivia, php vmail.php -na <hostname>@ortiche.net gestione@posta.indivia.net ;
  2. Se non esiste gia', generare sul server una nuova coppia di chiavi ssh per l'utente root (ssh-keygen -b 4096 -t rsa). Se i filename delle chiavi non vengono modificati allora e' sufficiente questo passo, altrimenti sara' necessario aggiungere le entry corrispondenti in /root/.ssh/config ;
  3. Creare l'utente dalla pagina di registrazione. L'indirizzo email deve essere valido per procedere all'attivazione dell'utente;
  4. Associare la chiave ssh generata, all'utente su gogs;
  5. Aggiungere l'utente al team "Deploy" dell'organizzazione opuppet.
  6. Testare eseguendo git clone --recursive gogs@lattuga.net:opuppet/puppet-deploy.git sul server
  • Installare un nuovo server Debian wheezy e configurare Git/puppet
  1. wget https://apt.puppetlabs.com/puppetlabs-release-wheezy.deb && dpkg -i puppetlabs-release-wheezy.deb && apt-get update

  2. Creare il file /etc/apt/preferences.d/00-puppet.pref con le seguente configurazione: `Package: puppet puppet-common Pin: version 3.7* Pin-Priority: 999

    Package: facter Pin: version 2.3* Pin-Priority: 999`

  3. Aggiungere la linea echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list && apt-get update

  4. Da root apt-get install puppet git

  5. Eliminare i file esistenti per puppet: rm -rf /etc/puppet

  6. Aggiungere l'utente specifico del server sulla piattaforma Gogs (vedi piu' in alto)

  7. Clonare il repository puppet-deploy al punto della configurazione di puppet: cd /etc && git clone --recursive gogs@lattuga.net:opuppet/puppet-deploy.git

  • 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.