New documentation on architecture

2015-06-29 18:11:19 +02:00 · 2015-06-29 18:11:19 +02:00 · ca541b6193
commit ca541b6193
parent 7a8cb2c5a9
1 changed files with 91 additions and 30 deletions
--- a/README.md
+++ b/README.md
@ -1,8 +1,7 @@
 Puppet-deploy
 =============

-
-Ovvero della centralizzazione, automazione delle configurazioni per indivia/ortiche. 
+Ovvero della centralizzazione, automazione e documentazione delle configurazioni di un server autogestito

 ### Requisiti

@ -14,48 +13,112 @@ Ovvero della centralizzazione, automazione delle configurazioni per indivia/orti

 #### Git
 - [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
- - [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
 - 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
+ - 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

-##### Gogs
- - **Organizzazione [opuppet](http://git.lattuga.net/org/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. 
+##### 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
+<pre>
+[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
+</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
- - **[puppet-deploy](http://git.lattuga.net/opuppet/puppet-deploy)**
-  - E' il progetto principale in cui viene mantenuta tutta la configurazione di puppet;
+##### Repository Git
+ - **[<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 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 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) )
-  - 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.  
+  - **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')`]
+
+ - **[<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
 - Aggiungere uno sviluppatore a opuppet su Gogs
@ -93,6 +156,4 @@ Ovvero della centralizzazione, automazione delle configurazioni per indivia/orti
 #### Appunti 
 - **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.*
- - **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`