In questa pagina è riassunta la documentazione relativa ai sistemi informatici del GOLEM. Se fai parte del gruppo IT, questo è l'indice di pagine che stavi cercando, e probabilmente ti interessano anche le altre pagine nella categoria SysOp.

Questa pagina dovrebbe consentire di avere una visione d'insieme della struttura, ma anche da punto di partenza per le bozze di documentazione, perché al momento (autunno 2022) l'infrastruttura è poco documentata.

Questa pagina è in fase di scrittura, potenzialmente in maniera permanente.

Indice tematico

Caratteristiche di un servizio

Ogni servizio del GOLEM:

è basato su microservizi, ogni servizio è suddiviso in uno o più microservizi che girano all'interno di container docker;
ha un nome, convenzionalmente composto solo da lettere minuscole (esempio: wiki). Il nome dovrebbe rappresentare il servizio e non la tecnologia che utilizza. (esempio: al momento esiste un servizio chiamato wordpress, ma la dicitura corretta sarebbe blog, in quanto wordpress è la tecnologia che utilizza, non il servizio che offre. Questo è importante perché la tecnologia wordpress potrebbe essere impiegata anche per altri servizi);
è descritto da un file docker-compose.yml in cui sono presenti tutte le informazioni necessarie per replicare i container che lo compongono;
potenzialmente, è in ascolto su delle porte TCP/UDP.

Evitare collisioni di nomi di servizi e di porte dello stack di rete, consultando e mantenendo aggiornata la pagina Servizi.

Se stai usando Docker per realizzare un servizio al GOLEM, allora dovresti considerare di scambiare quattro chiacchiere col sistemista e di entrare a far parte del gruppo del sistema automatico argilla su git.

Tassonomia

L'associazione ha alcuni server, che possono essere sia fisici che virtuali. I server offrono dei servizi, che, in genere, sono composti da più microservizi, che vengono installati per mezzo di container basati su immagini (nel caso specifico, immagini Docker)

Flusso di lavoro per un nuovo servizio

Ho un programma e voglio farne un container docker per usarlo nell'infrastruttura GOLEM. Che fare?

Sono il programmatore:
1. Scrivere il Dockerfile per il proprio programma
2. Creare l'immagine per il proprio programma

Sono il sistemista:
1. Scrivere il docker-compose.yml per il servizio
2. Avviare il servizio

Spesso ci si troverà a che fare con programmi che hanno già un'immagine Docker pronta e mantenuta su Docker Hub, perciò non è necessario scriversi un Dockerfile dedicate, ed è sufficiente utilizzare l'immagine originale, a meno che, ovviamente, non ci sia bisogno di personalizzazioni specifiche. (Ad esempio, per un certo periodo l'immagine ufficiale di MediaWiki veniva distribuita senza alcuni plugin che ci erano utili, e che aggiungevamo manualmente in un'immagine personalizzata)

Segue un esempio di flusso di lavoro per thttpd, un server HTTP minimale.

Creazione dell'immagine

Poiché manca l'immagine Docker per thttpd, bisogna scrivere un Dockerfile che descriva come creare questa immagine; poiché non è un programma mantenuto dal GOLEM, e si tratta di qualcosa di sufficientemente piccolo, non ha senso che esista in un suo repository dedicato, perciò lo si deve mettere in argilla/images

descrivere l'immagine:

FROM alpine:latest
RUN apk add thttpd
ENTRYPOINT ["thttpd", "-D", "-d", "/html"]

creare l'immagine e taggarla

docker build --tag git.golem.linux.it/argilla/thttpd:1 .

Note:

git.golem.linux.it identifica il dominio del registry che contiene le nostre immagini personalizzate; il registry è quello integrato in Gitea, un'interfaccia web per git;
argilla identifica l'organizzazione relative a strumenti di sistema;
thttpd identifica il nome dell'immagine specifica
1 identifica il tag dell'immagine

Utilizzare sempre un tag puntuale e mai generico, e specificare sempre il tag puntuale dell'immagine, per evitare spiacevoli sorprese nel caso in cui il tag dovesse essere sovrascritto. Per esempio: 1 o 1.2 vanno bene, mentre latest no.

Creazione di un servizio

Scegliere un nome significativo per il servizio, che identifichi bene di cosa si tratta.
- Per esempio, archivio e blog vanno bene, mentre webserver e wordpress no (tutti sanno che thttpd è un webserver, e che wordpress serve per fare i blog: al massimo, questi ultimi potrebbero essere nomi adatti alle immagini, non ai servizi).
I file docker-compose.yaml per i servizi, vanno messi nel repository argilla/docker, rispettando l'albero delle directory.
Scegliere una porta d'ascolto libera e univoca, e annotarla in Servizi: questo consente di evitare conflitti in caso di spostamenti di container da un server ad un altro.
Montare i volumi sotto /srv/$nome_servizio, per coerenza.

version: "3.3"
services:
  archivio:
    image: git.golem.linux.it/atena/thttpd:1
    restart: unless-stopped
    ports:
      - "8000:80"
    volumes:
      - /srv/webserver:/html

dove:

archivio è il nome del servizio, usato da docker-compose per nominare i container automaticamente
image immagine docker, con tanto di dominio del repository
ports sono espresse nella forma host:container
volumes: usare sempre una cartella nella forma /srv/$nome_servizio, per coerenza

Un servizio spesso è composto da più microservizi, anche se non è il caso di questo esempio.

Ricordarsi sempre di utilizzare un nome significativo per il servizio, di annotare la porta in ascolto e di montare i volumi sotto /srv

Avvio di un servizio

docker-compose up

Una volta sicuri che funzioni, utilizzare -d per eseguirlo in background.

Pushare immagine

Sul repository privato:

docker push git.golem.linux.it/argilla/thttpd:1

Se non è mai stato fatto, la prima volta il registry richiede di effettuare l'autenticazione:

docker login git.golem.linux.it

Server

atena - VPS Francia

atena ospita buona parte dei servizi del GOLEM accessibili al pubblico (sito web, repository git, ...). Si tratta di un VPS (virtual private server) hostato in Francia presso un datacenter di OVH.

I seguenti servizi risiedono su atena ma non sono microservizi dentro container, bensì bare metal:

server DNS (attenzione: in seguito ad un incidente, il server DNS è stato spostato temporaneamente, e deve ancora essere ripristinato su atena)
server VPN;
tunnel IPv6;
proxy http;

cassiopea - server fisico officina

Sul server locale di officina è installato il gestore di macchine virtuali e container Proxmox, su cui sono installate le seguenti macchine (VM e container).

backupper

LXC. Fa i backup.

Un crontab esegue periodicamente lo script argilla (vedere git se sei autorizzato), il quale:

si collega in ssh agli host specificati
spegne temporaneamente i container dei servizi associati
esegue un backup dei volumi via rete, scaricandoli in una directory dedicata
riavvia i container

Note importanti:

Durante il backup, il servizio interessato dal backup non è raggiungibile.
Per limitare disservizi, i backup vengono eseguiti durante le ore notturne.
Lo spazio disco sul VPS è una risorsa limitata. Per evitare di sprecarla con i `tar.gz` temporanei dei backup, il backup viene eseguito direttamente "al volo" su backupper tramite un tunnel ssh, anche se questa procedura aumenta il tempo di downtime.
I backup vengono eseguiti con frequenza settimanale.
I backup risiedono fisicamente in officina.

Il backup di tutti i volumi relativi ai container di un servizio:

hanno per nome $SERVIZIO-$DATETIME.tar.gz
hanno la struttura directory /srv/$SERVIZIO

Per ripristinare un backup, è sufficiente prendere il suo tar.gz, e scompattarlo nella root.

cd /
tar xf /backups/path/$SERVIZIO-$DATETIME.tar.gz

Possibili miglioramenti: usare un playbook ansible.

cassone

LXC. Ambiente di test per il VPS. Vi risiedono anche altri servizi con requisiti speciali.

gestionaledb: libro soci, vedere anche [1]. Requisito speciale: i dati personali dei soci non devono risiedere in cloud.
pubblici: archivio storico con fotografie e filmati. Requisito speciale: occupa molto spazio disco (decine di GiB), ma può tollerare eventuali downtime dell'officina.

vupiuesse

VM. Replicava le condizioni di lavoro del VPS, lavoro adesso svolto da cassone. Attualmente ospita solamente WebSDR, l'ultimo servizio rimasto in officina che richiede una VM per beneficiare del passthrough delle porte USB.

servirtualozzo

LXC. Backup di serverozzo.

Contiene un backup del disco del precedente server d'officina, da cui fare cherry pick delle configurazioni quando necessario. Attualmente è spento.

Docker su LXC Proxmox

Creazione e configurazione del container

Aprire il tool di creazione di un LXC;
Lasciare selezionati i flag "unprivileged container" e "nesting";
Selezionare l'immagine LXC preferita (es. turnkey-core);
Mountpoints:
- Lasciare il rootfs di default;
- Aggiungere un nuovo mountpoint /var/lib/docker/ da esculdere dai backup di Proxmox. Servirà per i file di sistema di docker (immagini, log, etc). Questi vengono ricreati automaticamente, quindi non ha senso che sia backuppato. Dimensione ~ decine di GB;
- Aggiungere un nuovo mountpoint /srv/docker da includere nei backup. Dimensione ~ decine di GB. Memorizzerà i file "utente" utilizzati nei container.
Al termine della creazione del container, entrare sulle opzioni e abilitare keyctl nelle features.

Installazione di docker

Informazioni riprese dalla guida ufficiale

Aggiornare il sistema

# apt update && apt upgrade

Installare le dipendenze

# apt install ca-certificates curl gnupg lsb-release

Aggiungere il repository docker

# mkdir -p /etc/apt/keyrings
# curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
# echo   "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null

Installare docker

# apt update
# apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Buone prassi

Come sul VPS, è sempre bene esplicitare la posizione dei volumi su cui deve essere fatto il backup. Posizionare i volumi in /srv/docker/nome-container/.

🚧 giomba (discussioni) 12:34, 15 apr 2023 (UTC) Questo percorso è sbagliato?

Sistemi informatici

Indice