opuppet/puppet-deploy
4
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
No description
39 commits 2 branches 0 tags 29 KiB
Shell 52.5%
Puppet 47.5%
Find a file
jigen 40330012f4 Deleted class inclusion
2015-02-21 14:18:50 +01:00
manifests Deleted class inclusion 2015-02-21 14:18:50 +01:00
modules Removed submodules, now managed through mr 2015-01-26 12:23:35 +01: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 Fixed path lookup for hiera 2015-02-20 19:10:03 +01:00
puppet.conf first hiera test on puppet 2015-01-07 23:45:26 +01:00
README.md Removed submodules, now managed through mr 2015-01-26 12:23:35 +01:00

README.md

Puppet-deploy

Ovvero della centralizzazione, automazione delle configurazioni per indivia/ortiche.

Requisiti

Puppet

Git

Riseup shared puppet modules

Gogs

Presupposti

  • Semplificare l'installazione l'installazione di un nuovo server
  • Semplificare la reinstallazione di un server esistente
  • Mantenere tutte le configurazioni in un'unico repository, con history
  • Poter collaborare facilmente al mantenimento dei server e servizi
  • Evitare Single Point of Failure
  • Usare tool standard diffusi e minimamente conosciuti anche da noi
  • Collaborare con gli altri collettivi/server/reti

Architettura

Gogs
  • Organizzazione opuppet A questa fanno riferimento tutti i repository. I permessi sui repository di un'organizzazione non vengono definiti per utente, bensi' per team. In opuppet ne sono definiti tre:
  • Owners possono creare nuovi repository e chiaramente leggere e scrivere. Di questa fanno parte tutti gli sviluppatori
  • Developers ha permessi di lettura/scrittura sui repository esistenti.
  • Deploy ha i permessi di lettura sui repository. A questo team appartengono tutti i server.
Progetti Git

  • puppet-deploy

  • E' il progetto principale in cui viene mantenuta tutta la configurazione di puppet;

  • 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 tabelle utenti;

  • Il file manifests/site.pp contiene tutte le associazioni server/servizio e quindi le dichiarazioni delle classi (PER ORA: bisogna valutare se implemntare un semplice External Node Classifier )

  • Tutte le funzionalita', i moduli puppet, sono sottomoduli (git submodule) del progetto e obbligatoriamente ospitati su un nostro repository.

  • module-$name

  • Ogni modulo ha un suo repository con la convenzione http://git.lattuga.net/opuppet/module-$name;

  • Quando possibile il clone iniziale avviene da gli shared puppet module di riseup NON dai 'moduli personali' ne' di riseup, ne' dei collettivi. Esempio: https://labs.riseup.net/git/shared-apt.git e' il modulo shared mentre https://labs.riseup.net/git/module-apt.git e' il modulo privato di riseup, https://git.puppet.immerda.ch/module-apt/ e' il modulo di quelli di immerda;

  • Quando nel progetto principale viene eseguito un git submodule add questo DEVE puntare ad un url ospitata dal nostro repository.

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.
  • riseup clone workaround Invece di eseguire git clone https://labs.riseup.net/git/shared-$name.git e' necessario modificare l'url in modo che diventi git clone https://labs.riseup.net/code/shared-$name.git