Differenze tra le versioni di "Docker"
(Aggiornamento del flusso di lavoro) |
|||
Riga 50: | Riga 50: | ||
=== Creazione di un servizio === | === Creazione di un servizio === | ||
− | Scegliere un nome significativo per il servizio, che identifichi bene di cosa si tratta. | + | * 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''). | + | ** 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 <code>docker-compose.yaml</code> per i servizi, vanno messi nel repository ''argilla/docker'', rispettando l'albero delle directory. | + | * I file <code>docker-compose.yaml</code> 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 <code>/srv/$nome_servizio</code>, per coerenza. | ||
<syntaxhighlight lang="yaml"> | <syntaxhighlight lang="yaml"> | ||
Riga 76: | Riga 78: | ||
{{Note | {{Note | ||
|type=info | |type=info | ||
− | |text=Ricordarsi sempre di utilizzare un nome significativo per il servizio, e di montare i volumi sotto /srv | + | |text=Ricordarsi sempre di utilizzare un nome significativo per il servizio, di annotare la porta in ascolto e di montare i volumi sotto /srv |
}} | }} | ||
Versione delle 08:55, 15 apr 2023
Questa pagina descrive l'organizzazione dei microservizi basati su container Docker che usiamo al GOLEM.
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
Ho un programma e voglio farne un container docker per usarlo nell'infrastruttura GOLEM. Che fare?
- Sono il programmatore:
- Scrivere il Dockerfile per il proprio programma
- Creare l'immagine per il proprio programma
- Sono il sistemista:
- Scrivere il docker-compose.yml per il servizio
- Avviare il servizio
Segue un esempio di flusso di lavoro per thttpd.
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.
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
Utilità
Dove mette i volumi Docker?
Se non si impostano i volumi del conatiner Docker li crea automaticamente in un "suo" percorso. Per sapere dove il container mette i nostri dati si possono utilizzare questi comandi:
Mostrare l'elenco dei container in esecuzione. Da questo elenco si prende l'ID del container che ci interessa.
docker ps
Mostrare l'elenco dei volumi del container. Il risultato sarà in formato JSON. Il parametro ID è quello che abbiamo preso dal docker ps
docker inspect -f 'Template:.Mounts' <ID>
E' possibile usare il comando
docker inspect <ID>
per ottenere l'elenco completo (sempre in formato JSON) delle informazioni di configurazione del container. Tra queste, la lista dei volumi e dei relativi mount point identificate da "Mounts":
Al posto del parametro ID e' sepre possibile utilizzare il nome assegnato al container, nome che è anch'esso reperibile dall'elenco ottenuto con docker ps
.