cisti/infra
3
0
Fork 1
Code Issues Pull requests Releases Activity

add galaxy deps and cattable readme

Browse source 
Signed-off-by: bic <bicno@autistici.org>
This commit is contained in:
bic 2021-03-28 19:15:36 +02:00
parent 63cce40f7e
commit 160328e7b4
No known key found for this signature in database
GPG key ID: 958E390154AB4DFA
1 changed files with 48 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

58
README.md
View file

@ -2,13 +2,34 @@
Un angolo ragionato per facilitare la messa in opera di servizi autogestiti di prossimità.
#### Come si usa
Silicone è una raccolta di ruoli [ansible](https://docs.ansible.com/ansible/latest/index.html) fatti a modino e basati su debian stable, un tentativo di fissare alcune scelte tecniche ragionate e poterle ridiscutere in un posto comodo.
È molto utile anche per chi vuole tirare su un pad o gancio o altro senza dover necessariamente mettere le mani troppo nella marmellata dei file di configurazione di nginx, ricordarsi di aggiungere il cron per certbot, capire quale versione di nodejs bisogna usare per installare etherpad o trovare un sistema per fare i backup di tutto questo. Qui dentro abbiamo fatto delle scelte.
Per usarlo velocemente e conoscendo un minimo ansible, imposta il tuo inventory ([inventory.yml](./inventory.yml)) il tuo playbook ([infra.yml](./infra.yml)) e lancia `ansible-playbook`.
```bash
ansible-galaxy collection install community.general
ansible-galaxy collection install community.postgresql
```
Silicone è una raccolta di ruoli
[ansible](https://docs.ansible.com/ansible/latest/index.html) fatti a
modino e basati su debian stable, un tentativo di fissare alcune scelte
tecniche ragionate e poterle ridiscutere in un posto comodo. È molto utile
anche per chi vuole tirare su un pad o gancio o altro senza dover
necessariamente mettere le mani troppo nella marmellata dei file di
configurazione di nginx, ricordarsi di aggiungere il cron per certbot,
capire quale versione di nodejs bisogna usare per installare etherpad o
trovare un sistema per fare i backup di tutto questo. Qui dentro abbiamo
fatto delle scelte.
Per usarlo velocemente e conoscendo un minimo ansible, imposta il tuo
inventory ([inventory.yml](./inventory.yml)) il tuo playbook
([infra.yml](./infra.yml)) e lancia `ansible-playbook`.
#### Ansible in breve
Ansible è uno strumento a cui si fornisce una lista di macchine da gestire (specificate dentro un file inventory) e si descrive quali ruoli assegnare ad ogni macchina. Ad esempio, diciamo che su ogni server/vm che gestiamo vogliamo installare 3 pacchetti (git, sudo e python3), ecco bisognerà scrivere nel playbook qualcosa come:
Ansible è uno strumento a cui si fornisce una lista di macchine da gestire
(specificate dentro un file inventory) e si descrive quali ruoli assegnare
ad ogni macchina. Ad esempio, diciamo che su ogni server/vm che gestiamo
vogliamo installare 3 pacchetti (git, sudo e python3), ecco bisognerà
scrivere nel playbook qualcosa come:
```yaml
# test_playbook.yml
@ -24,7 +45,9 @@ Ansible è uno strumento a cui si fornisce una lista di macchine da gestire (spe
- python3
```
A questo punto lanciando `./ansible-playbook test_playbook.yml` tutti i server specificati nel file di inventory verranno contattati da ansible via ssh che provvederà ad eseguire le operazioni descritte nel task.
A questo punto lanciando `./ansible-playbook test_playbook.yml` tutti i
server specificati nel file di inventory verranno contattati da ansible via
ssh che provvederà ad eseguire le operazioni descritte nel task.
Un ruolo ansible quindi non è nient'altro che una lista di operazioni.
@ -32,20 +55,35 @@ Per poter eseguire solo alcuni ruoli di alto livello possiamo usare i tag:
`ansible-playbook --tags radicale infra.yml`.
#### Password / Keys
Per le informazioni sensibili (password del database, dell'account di admin, una chiave ssh) viene usato [passwordstore](https://www.passwordstore.org/), il path usato è specificato nell'inventory con la variabile `passwordstore_path`.
Per le informazioni sensibili (password del database, dell'account di
admin, una chiave ssh) viene usato
[passwordstore](https://www.passwordstore.org/), il path usato è
specificato nell'inventory con la variabile `passwordstore_path`.
#### Backup
Per i backup usiamo [restic](https://restic.net/).
ogni servizio che vuole supportare i backup deve controllare la variabile `with_backup` e specificare di quali database e directory fare i backup (`restic_databases` e `restic_folders`). Le configurazioni sono dentro l'inventory (che le cerca dentro il passwordstore).
Per i backup usiamo [restic](https://restic.net/). ogni servizio che vuole
supportare i backup deve controllare la variabile `with_backup` e
specificare di quali database e directory fare i backup (`restic_databases`
e `restic_folders`). Le configurazioni sono dentro l'inventory (che le
cerca dentro il passwordstore).
#### Monitoring
#### Creare nuovi ruoli e testarne di vecchi:
Ci sono varie possibilità, si può usare docker o vagrant, sono dentro `dev/`, per Docker c'e' un [README](./dev/README.md)
Ci sono varie possibilità, si può usare docker o vagrant, sono dentro
`dev/`, per Docker c'e' un [README](./dev/README.md)
### Servizi
I servizi di alto livello dipendono dai ruoli base, ad esempio etherpad dipende tra gli altri da nodejs, postgresql e opzionalmente anche da nginx e restic. Le dipendenze di un ruolo sono specificate dentro `meta/main.yml` alla voce `dependencies` (vedi le dipendenze del ruolo etherpad come esempio [qui](./roles/stable/etherpad/meta/main.yml))
I servizi di alto livello dipendono dai ruoli base, ad esempio etherpad
dipende tra gli altri da nodejs, postgresql e opzionalmente anche da nginx
e restic. Le dipendenze di un ruolo sono specificate dentro `meta/main.yml`
alla voce `dependencies` (vedi le dipendenze del ruolo etherpad come
esempio [qui](./roles/stable/etherpad/meta/main.yml))
<!--
#### [Etherpad](https://etherpad.org/)