Automatizzare il deploy dei nuovi server

[Radeox]

Il deploy dei nuovi server nel software di monitoring dovrebbe partire ogni volta che si effettua un commit sul master. Questo è possibile tramite le actions ma non abbiamo molta esperienza in merito e vogliamo evitare di rompere tutto 😄

[tapionx]

@Radeox Bene, per non rompere tutto invece si possono fare dei test

[sgs00]

Ciao, quali sono esattamente le azioni che oggi vengono svolte manualmente?

[tapionx]

https://github.com/iorestoacasa-work/iorestoacasa_monitoring/blob/master/README.md
quì è formalizzata la procedura per aggiungere server.
Secondo me si potrebbero introdurre le seguenti migliorie:

• invece di gestire le richieste in chat, con il rischio che vengano perse, preparare un template per le issue di GITHUB con le domande da rispondere. Chi vuole aggiungere un server crea una issue partendo dal template
  (bisogna modificare tutte le procedure nel sito web e nei repository inserendo un link all'apertura di una nuova issue con template, se non sbaglio si può fare)
• realizzare un test da lanciare che verifica in automatico che il nuovo server aggiunto appaia nel file hosts.json
• realizzare una procedura di Continuous Deploy per cui quando si fa push sul master il nuovo server viene automaticamente pubblicato sul server
  (attualmente si fa a mano: ssh; git pull; docker-compose restart)

[sgs00]

Riprendo gli step del readme (https://github.com/iorestoacasa-work/iorestoacasa_monitoring/blob/master/README.md) espandendo un po' lo scope, si tratta di idee, bisognerà valutare effort e fattibilità.

Un possibile flusso potrebbe essere:

1. installazione del server (ansible?, eventuale issue a parte)

2. il volontario invia una PR direttamente sul file jitsi_targets.yml oppure aggiungerà un file jitsi_targets.SERVERNAME.yml in una cartella specifica (preferito in quanto è più facile testare automaticamente il singolo contributo).
   Una pipeline farà immediatamente dei test (quanto meno sulle URL, status code HTTP 200 e check su chiave/valori attesi dalle metriche).
   Un feedback quasi immediato consente al volontario di capire se qualcosa non va ed un KO del test farà si che l'owner eviti la merge.

3. un owner fa eventuali altre verifiche manuali e poi accetta la merge.

4. la pipeline che si occupa della build colleziona e unisce tutti i file jitsi_targets.*.yml in un unico jitsi_targets.yml e aggiorna hosts.json
   Idealmente la build è costituita da un unico artefatto sotto forma di immagine docker taggata, e pushata su dockerhub, che contiene al suo interno tutto il necessario - no file esterni da montare come volumi (questo semplifica il deploy e consente di associare in ogni momento un tag specifo allo stato delle configurazioni nel loro complesso)

5. docker-compose.yaml (unico file necessario al deploy) viene copiato automaticamente sul server e poi lanciato docker-compose stop/pull/start (questa action sembra fare quello che ci serve https://github.com/fifsky/ssh-action)

Restano fuori (azioni manuali):

• inserire una nuova riga nel foglio di calcolo condiviso
• creare un utente grafana
• chiedere di fare il deploy sul server del repository iorestoacasa.work (questo se ho capito bene serve a pubblicare hosts.json - in alternativa si può spedire automaticamente il file su un bucket che alimenta un dominio a parte, tipo hosts.iorestoacasa.work - mi sembra che il file abbia il solo scopo di popolare la tabella dei server ma non non ne sono sicuro - comunque un modo per gestirlo si trova)

Siccome non è poca roba, si potrebbe partire con lo script di deploy, a seguire build e integrazione con le actions di github.

Come vi sembra?

[tapionx]

grazie per il contributo @sgs00
oggi abbiamo fatto un piccolo passo avanti e creato un template per le issue in questo repository per aggiungere nuovi server.
Chi vuole aggiungere un nuovo server crea una issue partendo dal template

1. installazione del server (ansible?, eventuale issue a parte)

Abbiamo già dei playbook ansible che usiamo internamente per configurare un sistema base con docker. Potremmo metterli a disposizione per ottenere un sistema pronto, ma non li indicherei come metodo principale per installare un nuovo server, temo che molti tecnici non sappiano usare Ansible.
Magari conoscono solo SaltStack o Puppet oppure sono "vecchio stile" e installano la macchina manualmente.
Per questo motivo ho scritto semplicemente di installare git, docker e docker-compose, in effetti è tutto quello che serve.

2. il volontario invia una PR direttamente sul file jitsi_targets.yml oppure aggiungerà un file jitsi_targets.SERVERNAME.yml in una cartella specifica (preferito in quanto è più facile testare automaticamente il singolo contributo).
   Una pipeline farà immediatamente dei test (quanto meno sulle URL, status code HTTP 200 e check su chiave/valori attesi dalle metriche).
   Un feedback quasi immediato consente al volontario di capire se qualcosa non va ed un KO del test farà si che l'owner eviti la merge.

3. un owner fa eventuali altre verifiche manuali e poi accetta la merge.

Questo mi piace. Tuttavia molte persone sono spiazzate quando gli chiedo di aprire una PR, non sanno cos'è. Credo che sia più efficace un metodo alla portata di tutti (aprire una issue tramite link), e poi un nostro volontario si occupa di fare commit.

4. la pipeline che si occupa della build colleziona e unisce tutti i file jitsi_targets.*.yml in un unico jitsi_targets.yml e aggiorna hosts.json

Il file hosts.json viene generato da questo script (che ha un gran bisogno di refactoring). Gira sul docker-compose del sito di monitoraggio, ogni 5 secondi interroga prometheus e genera il JSON che poi viene esposto sul sito web con un alias di nginx.

   Idealmente la build è costituita da un unico artefatto sotto forma di immagine docker taggata, e pushata su dockerhub, che contiene al suo interno tutto il necessario - no file esterni da montare come volumi (questo semplifica il deploy e consente di associare in ogni momento un tag specifo allo stato delle configurazioni nel loro complesso)

I volumi dove tenere i database di prometheus e grafana comunque sono necessari.

5. docker-compose.yaml (unico file necessario al deploy) viene copiato automaticamente sul server e poi lanciato docker-compose stop/pull/start (questa action sembra fare quello che ci serve https://github.com/fifsky/ssh-action)

Non ho mai usato le GitHub actions, chi si collega in SSH sul server? GitHub? quindi dovrei fornire a github una chiave SSH per accedere?

Restano fuori (azioni manuali):

* inserire una nuova riga nel foglio di calcolo condiviso

* creare un utente grafana

* chiedere di fare il deploy sul server del repository iorestoacasa.work (questo se ho capito bene serve a pubblicare hosts.json - in alternativa si può spedire automaticamente il file su un bucket che alimenta un dominio a parte, tipo hosts.iorestoacasa.work - mi sembra che il file abbia il solo scopo di popolare la tabella dei server ma non non ne sono sicuro - comunque un modo per gestirlo si trova)

Siccome non è poca roba, si potrebbe partire con lo script di deploy, a seguire build e integrazione con le actions di github.

Come vi sembra?

👍

[sgs00]

Ecco un esempio di workflow che comprende build push e deploy [1].

Nel file .github/workflows/main.yaml troverai dei riferimenti a variabili tipo ${{ secrets.DOCKER_PASSWORD }} - vanno configurate come secrets su github [2].

Hai bisogno di creare una chiave ssh che userai solo per i deploy, se sei paranoico (e non è un'offesa) puoi configurare il file authorized_keys affinchè chi si collega con quella chiave possa eseguire solo lo script di deploy [3]

Se vuoi / ti interessa possiamo approfondire.

Per quanto riguarda il template per le issue è un ottimo passo avanti, ma finché non arrivi a dover fare un solo clic per la merge (in quanto tutto già predisposto e testato) c'è sempre margine di miglioramento :-D

Concordo con te sul fatto che ci possano essere persone che non hanno voglia di aprire una PR, un'alternativa potrebbe essere somministrare il questionario tramite il bot telegram.

[1] https://github.com/sgs00/github-actions-playground

[2] https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets

[3] https://serverfault.com/questions/749474/ssh-authorized-keys-command-option-multiple-commands/803873#803873