opuppet/puppet-deploy
4
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
No description
25 commits 2 branches 0 tags 29 KiB
Shell 52.5%
Puppet 47.5%
Find a file
jigen 7bfa897b33 altri fix
2015-01-06 15:19:46 +01:00
manifests Merge branch 'hosts' 2015-01-06 13:14:04 +01:00
modules aggiunto il modulo lsb 2015-01-06 00:25:58 +01:00
.gitmodules aggiunto il modulo lsb 2015-01-06 00:25:58 +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
puppet.conf Initial commit 2014-10-27 23:54:51 +02:00
README.md altri fix 2015-01-06 15:19:46 +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
  • 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