tentativo di mantenere le cose ordinate :D ansible Vagrant e altri amenuncoli

six f0d65afd45 comment on debian-frotend/tasks/nginx.yml 3 年之前
assets 23c6bb4bd3 daje 3 年之前
dev ee97b7acc1 update README and dev documentation 3 年之前
examples 3a1cb57d4b Testing backup 3 年之前
roles f0d65afd45 comment on debian-frotend/tasks/nginx.yml 3 年之前
vars c42d7b4a5f minor 3 年之前
.gitignore 16ed2a40ef ignore inventory 3 年之前
README.md ee7216929a staging/radicale 3 年之前
ansible.cfg 23c6bb4bd3 daje 3 年之前
backup.yml ebeaf6f533 update nginx role 3 年之前
infra.yml ee7216929a staging/radicale 3 年之前
inventory.yml ebeaf6f533 update nginx role 3 年之前

README.md

Silicone

Un angolo ragionato per facilitare la messa in opera di servizi autogestiti di prossimità.

Come si usa

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.

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)