No Description

jigen e8198b84bd Using future parser 8 years ago
manifests e4937f68de Eliminated notify 8 years ago
modules 4e220d3bf5 Removed submodules, now managed through mr 9 years ago
.gitignore 7a8cb2c5a9 Hiera conf tree now subdirectory of puppet-deploy 8 years ago
.gitmodules 4e220d3bf5 Removed submodules, now managed through mr 9 years ago
README.md 2b37a7a88e Appunto su deep-merge 8 years ago
etckeeper-commit-post e86762cfff Riaggiunti gli hook 9 years ago
etckeeper-commit-pre e86762cfff Riaggiunti gli hook 9 years ago
hiera.yaml 0f1ec5fa6e Changed merge behaviour 8 years ago
puppet.conf e8198b84bd Using future parser 8 years ago

README.md

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="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

Software necessario

gem install deep_merge

Creare un nuovo $(site-name)

Configurazione siteconf-$(sitename)
  1. Creare il repository git per la configurazione del site git init siteconf-$(sitename)
  2. (Opzionale) Creare il repositori bare remoto
  3. Configurare il nuovo repository per usare un remote crittato con gcrypt:
    cd siteconf-$(sitename)/
    git remote add $(gcrypt_remote) gcrypt::/siteconf-$(site-name).git
    git config remote.$(gcrypt_remote).gcrypt-participants "$(sysadm1-key-fingerprint) $(sysadm2-key-fingerprint) $(server1-key-fingerprint) $(server2-key-fingerprint)"
    git config remote.$(gcrypt_remote).gcrypt-publish-participants true
    touch README
    git add .
    git commit -m "Initial gcrypt commit"
    git push --set-upstream $(gcrypt_remote) master

E' importante importare le chiavi pubbliche di TUTTI i sysadmin e TUTTI i servers elencati in gcrypt-participants prima di continuare oltre

Configurazione module-$(sitename)
  1. Creare un file .mrconfig nel repository siteconf-$(sitename) contenente i dettagli del repository di module-$(sitename)
    [DEFAULT]
    lib = SITE="$(sitename)" && \
    HOSTFQDN="$(hostname --fqdn)" && HOSTNAME="$(hostname)" && \
        REPO_ROOT="git@gitlab.com:organization/"

[/etc/puppet/modules/$(modulename)] checkout = git clone gcrypt::${REPO_ROOT}/module-${SITE}.git $(modulename)] order=3

  1. Committare/pushare/aggiornare siteconf-$(modulename)
  2. Creare il repository git per la configurazione del site git init module-$(sitename)
  3. (Opzionale) Creare il repositori bare remoto
  4. Configurare il nuovo repository per usare un remote crittato con gcrypt:
    cd module-$(sitename)/
    git remote add $(gcrypt_remote) gcrypt::/module-$(site-name).git
    git config remote.$(gcrypt_remote).gcrypt-participants "$(sysadm1-key-fingerprint) $(sysadm2-key-fingerprint) $(server1-key-fingerprint) $(server2-key-fingerprint)"
    git config remote.$(gcrypt_remote).gcrypt-publish-participants true
    touch README
    git add .
    git commit -m "Initial gcrypt commit"
    git push --set-upstream $(gcrypt_remote) master

E' importante importare le chiavi pubbliche di TUTTI i sysadmin e TUTTI i servers elencati in gcrypt-participants prima di continuare oltre

Configurazione di un server base, senza moduli specifici per site o host

  1. Installare un nuovo server Debian Wheezy
  2. Abilitare i backports (necessari per git-remote-gcrypt) echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list
  3. 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
  4. 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`

  5. Aggiornare la lista dei pacchetti disponibili apt-get update

  6. Da root apt-get install puppet git git-remote-gcrypt myrepos

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

  8. Generare una nuova coppia di chiavi gpg gpg --gen-key

  9. Configurare sul repository git l'account e i permessi per il nuovo server. Questo passo potrebbe non essere indispensabile, dipende dal repository configurato.

  10. (Opzionale) Configurare l'agent gpg

  11. Copiare i file .mrconfig e .mrtrust forniti sopra in /root e configurare le variabili SITE e REPO_ROOT in .mrconfig.

  12. Eseguire l'update di tutti i moduli mr -d /etc/ update

  13. Lanciare l'esecuzione di puppet puppet apply -v /etc/puppet/manifests/site.pp

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.