Differenze tra le versioni di "Docker"

Da GolemWiki.
Jump to navigation Jump to search
(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.

Golem-template-note-attention.png 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:
    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

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

Golem-template-note-info.png 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.

Golem-template-note-info.png 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

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.