Differenze tra le versioni di "Sistemi informatici"
Riga 17: | Riga 17: | ||
}} | }} | ||
− | = Indice | + | = Indice tematico = |
<!-- per favore cercare di mantenere l'ordine alfabetico! --> | <!-- per favore cercare di mantenere l'ordine alfabetico! --> | ||
* [[IPv6 @ GOLEM]] | * [[IPv6 @ GOLEM]] | ||
Riga 23: | Riga 23: | ||
* [[VPN del GOLEM]] | * [[VPN del GOLEM]] | ||
+ | = Caratteristiche di un servizio = | ||
Ogni servizio del GOLEM: | Ogni servizio del GOLEM: | ||
* è basato su microservizi, ogni servizio è suddiviso in uno o più microservizi che girano all'interno di container docker; | * è 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); | * 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 <code>docker-compose.yml</code> in cui sono presenti tutte le informazioni necessarie per replicare i container che lo compongono; | * è descritto da un file <code>docker-compose.yml</code> in cui sono presenti tutte le informazioni necessarie per replicare i container che lo compongono; | ||
+ | * potenzialmente, è in ascolto su delle porte TCP/UDP. | ||
+ | |||
+ | {{Note | ||
+ | |type=attention | ||
+ | |text=Evitare collisioni di nomi di servizi e di porte dello stack di rete, consultando e mantenendo aggiornata la pagina [[Servizi]]. | ||
+ | }} | ||
= VPS - atena = | = VPS - atena = |
Versione delle 20:55, 17 nov 2022
Stai leggendo la guida "Sistemi informatici"
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.
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.
VPS - atena
atena ospita buona parte dei servizi del GOLEM accessibili al pubblico (sito web, repository git, ...).
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;
Server locale - cassiopea
Sul server locale di officina è installato il gestore di macchine virtuali e container Proxmox, su cui sono installate le seguenti macchine (VM e container).
vpntest
LXC. Ambiente di test per la VPN
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.
vupiuesse
VM. Replica le condizioni di lavoro del VPS, e costituisce principalmente il suo ambiente di test. Dovrà essere operata una migrazione da VM a LXC per ridurre i consumi di risorse, in particolare la RAM.
Su vupiuesse
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.
pezzalcloud
LXC. Storage aggiuntivo per l'archivio del cloud.
servirtualozzo
LXC. Backup di serverozzo
.
Contiene un backup del disco del precedente server d'officina, da cui fare cherry pick delle configurazioni quando necessario.
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/
.