opuppet/puppet-deploy
4
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

New documentation on architecture

Browse source
This commit is contained in:
jigen 2015-06-29 18:11:19 +02:00
parent 7a8cb2c5a9
commit ca541b6193
1 changed files with 91 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

121
README.md
View file

@ -1,8 +1,7 @@
Puppet-deploy Puppet-deploy
============= =============
Ovvero della centralizzazione, automazione e documentazione delle configurazioni di un server autogestito
Ovvero della centralizzazione, automazione delle configurazioni per indivia/ortiche.
### Requisiti ### Requisiti
@ -14,48 +13,112 @@ Ovvero della centralizzazione, automazione delle configurazioni per indivia/orti
#### Git #### Git
- [Git](http://www.git-scm.com/) - [Git](http://www.git-scm.com/)
- **git submodules**
- [Pro Git book](http://git-scm.com/book/en/v2/Git-Tools-Submodules) #### gcrypt
- [Github](https://github.com/joeyh/git-remote-gcrypt)
- In Debian 7.x Wheezy si installa da backports
#### MyRepos
- https://myrepos.branchable.com/
#### Riseup shared puppet modules #### Riseup shared puppet modules
- [Shared puppet modules](https://labs.riseup.net/code/projects/sharedpuppetmodules) - [Shared puppet modules](https://gitlab.com/groups/shared-puppet-modules-group)
#### Gogs
- [Gogs](http://gogs.io/)
- **http://gogs.lattuga.net**
#### Presupposti #### Presupposti
- Semplificare l'installazione l'installazione di un nuovo server - Semplificare l'installazione l'installazione di un nuovo server
- Semplificare la reinstallazione di un server esistente - Semplificare la reinstallazione di un server esistente
- Mantenere tutte le configurazioni in un'unico repository, con history - Mantenere logica, dati e configurazioni separati
- Poter collaborare facilmente al mantenimento dei server e servizi - Avere un versioning delle confgiurazioni
- Evitare Single Point of Failure - Facilitare la collaborazione degli amministratori nel mantenimento dei server/servizi
- Usare tool standard diffusi e minimamente conosciuti anche da noi - Facilitare la collaborazione nello sviluppo degli strumenti
- Collaborare con gli altri collettivi/server/reti - Collaborare con gli altri collettivi/server/reti
- Evitare Single Point of Failure
- Non creare tool nuovi, utilizzare l'esistente (soprattutto se conosciuto)
#### Architettura #### Architettura
##### Gogs ##### MyRepos
- **Organizzazione [opuppet](http://git.lattuga.net/org/opuppet)** - Tutto parte dalla configurazione di mr, che elenca quali repository scaricare e mantenere aggiornati.
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: - **/root/.mrconfig** elenca i repository ed e' parametrizzato in funzione di SITE, HOSTNAME e REPO_ROOT
- *Owners* possono creare nuovi repository e chiaramente leggere e scrivere. Di questa fanno parte tutti gli sviluppatori <pre>
- *Developers* ha permessi di lettura/scrittura sui repository esistenti. [DEFAULT]
- *Deploy* ha i permessi di lettura sui repository. A questo team appartengono tutti i server. 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
</pre>
- **/root/.mrtrust** istruisce myrepos per fidarsi dei file .mrconfig inclusi nei repository di configurazione del sito e dell'host
<pre>
/etc/puppet/site-conf/.mrconfig
/etc/puppet/site-conf/host-conf/.mrconfig
</pre>
##### Progetti Git ##### Repository Git
- **[puppet-deploy](http://git.lattuga.net/opuppet/puppet-deploy)** - **[<font color="yellow">conf</font>, <font color="red">world-wide</font>, <font color="red">clear</font>]** **[puppet-deploy](http://git.lattuga.net/opuppet/puppet-deploy)**
- E' il progetto principale in cui viene mantenuta tutta la configurazione di puppet; - 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; - 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); - 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 sensibili (chiavi e password);
- **NON** contiene tabelle utenti; - **NON** contiene dati o 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](https://docs.puppetlabs.com/guides/external_nodes.html) ) - Il file `manifests/site.pp` contiene la dichiarazione di default per i nodi, che include i ruoli definiti nella configurazione [`hiera_include('host-roles')`]
- Tutte le funzionalita', i [moduli puppet](https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html), sono sottomoduli (`git submodule`) del progetto e **obbligatoriamente** ospitati su un nostro repository.
- **[<font color="cyan">logic</font>, <font color="red">world-wide</font>, <font color="red">clear</font>]** **module-$(prog-name)**
- Quando disponibile il clone iniziale deriva da gli [shared puppet module](https://gitlab.com/groups/shared-puppet-modules-group)
- 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.
- **[<font color="yellow">conf</font>, <font color="orange">site-wide</font>, <font color="green">gcrypt</font>]** **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
- **[<font color="cyan">logic</font>, <font color="orange">site-wide</font>, <font color="green">gcrypt</font>]** **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
- **[<font color="yellow">conf</font>, <font color="green">host-wide</font>, <font color="green">gcrypt</font>]** **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
- **[<font color="cyan">logic</font>, <font color="green">host-wide</font>, <font color="green">gcrypt</font>]** **module-$(server-name)**
- Modulo che contiene la logica specifica per un unico server
- Includo qui i file sensibili per un unico server?
- **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 #### Workflow
- Aggiungere uno sviluppatore a opuppet su Gogs - Aggiungere uno sviluppatore a opuppet su Gogs
@ -93,6 +156,4 @@ Ovvero della centralizzazione, automazione delle configurazioni per indivia/orti
#### Appunti #### Appunti
- **module naming convention** - **module naming convention**
Dalla [documentazione di puppet](https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html#manifests): *`init.pp` is special and always contains a class with the same name as the module. You may not have a class named init.* Dalla [documentazione di puppet](https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html#manifests): *`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`