assets/etherpad | ||
dev | ||
examples | ||
roles | ||
vars | ||
.gitignore | ||
ansible.cfg | ||
backup.yml | ||
frontend.yml | ||
infra.yml | ||
inventory.yml | ||
koha.yml | ||
README.md |
Silicone
Un angolo ragionato per facilitare la messa in opera di servizi autogestiti di prossimità.
Come si usa
ansible-galaxy collection install community.general
ansible-galaxy collection install community.postgresql
ansible-galaxy install nginxinc.nginx
ansible-galaxy install nginxinc.nginx_config
Silicone è una raccolta di ruoli ansible 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) il tuo playbook
(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:
# test_playbook.yml
---
- name: Generic servers operation
hosts: all
tasks:
- name: Install generic packages
apt:
pkg:
- sudo
- git
- 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.
Un ruolo ansible quindi non è nient'altro che una lista di operazioni.
Per poter eseguire solo alcuni ruoli di alto livello possiamo usare i tag:
ansible-playbook --tags radicale infra.yml
.
Nello sviluppo può essere molto comodo usare la flag --start-at-task
:
ansible-playbook -i inventory.yml -i hosts --tags fdroid --start-at-task \
"Link repo into public dir" infra.yml
C'è anche un tool abbastanza comodo per fare dei controlli su quello che stai scrivendo, si chiama ansible-lint
Password / Keys
Per le informazioni sensibili (password del database, dell'account di
admin, una chiave ssh) viene usato
passwordstore, il path usato è
specificato nell'inventory con la variabile passwordstore_path
.
Backup
Per i backup usiamo restic. 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
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)