puppet-deploy/README.md

Puppet-deploy

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

Requisiti

Puppet

• Puppet
• Puppet modules
• puppet masterless
• puppet masterless server automation on a very small scale

Git

• Git
• git submodules
• Pro Git book

Riseup shared puppet modules

• Shared puppet modules

Gogs

• Gogs
• 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
• Collaborare con gli altri collettivi/server/reti

Architettura

Gogs

• Organizzazione opuppet Aquesta 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
• Aggiungere un server a opuppet su Gogs
• Installare un nuovo server e configurare Git/puppet
• 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