Se utilizzi Docker da un po' probabilmente hai già un flusso di lavoro semplice ed efficace su misura per te, che include alcuni dei tuoi comandi docker preferiti (i sottocomandi per essere tecnicamente corretti).
Ad esempio, rimuovevo i contenitori che non sono in esecuzione usando un comando lungo che assomiglia a questo docker container rm $(docker container ps -qf status=exited) , ha funzionato, generando ovviamente un errore ogni volta che non c'erano contenitori penzolanti. Questo si è fermato un giorno quando ho scoperto che abbiamo anche una prune sottocomando per i contenitori! Quindi ora quel lungo comando si è ridotto a un semplice docker container prune .
Il punto è che anche se molti di noi usano Docker da un po', c'è la possibilità che alcune cose siano state trascurate, o forse addirittura dimenticate nel tempo.
In questo articolo, ti darò tre sottocomandi Docker, che potrebbero essere nuovi per te, o non li stai usando molto, ma penso che dovresti.
Questi sottocomandi potrebbero includere anche i propri sottocomandi.
1. Il sottocomando di sistema
Docker ha un system comando che ti dà alcuni informazioni a livello di sistema relative alla finestra mobile. In realtà stai usando uno dei suoi sottocomandi da un po 'di tempo. Ricorda docker info ? Questo comando è in realtà docker system info .
Per saperne di più su questo sottocomando e su cosa offre, esegui --help opzione su di esso.
➟ docker system --help
Usage: docker system COMMAND
Manage Docker
Commands:
df Show docker disk usage
events Get real time events from the server
info Display system-wide information
prune Remove unused data
Run 'docker system COMMAND --help' for more information on a command.
Esaminiamo ciascuno di questi sottocomandi poiché penso che siano tutti molto critici.
Docker sistema df
Ti sei mai trovato in una situazione in cui lo spazio su disco del tuo server sembrava essere quasi pieno? Per controllare se si tratta dei contenitori (in esecuzione/volumi) probabilmente hai utilizzato il du comando direttamente sulla radice dei dati.
Usando du sulla radice dei dati richiede sudo accesso.
✗ du -h --max-depth=1 /var/lib/docker
du: cannot read directory '/var/lib/docker': Permission denied
4.0K /var/lib/docker
Non solo, per sapere esplicitamente quanto stanno allocando i volumi o le immagini, dovresti eseguire il comando più volte.
➟ sudo du -h --max-depth=0 /var/lib/docker/volumes && \
sudo du -h --max-depth=0 /var/lib/docker/image && \
sudo du -h --max-depth=0 /var/lib/docker/
Un'alternativa molto migliore è chiamare il docker system df comando. Ciò rileverà automaticamente la radice dei dati e di conseguenza stamperà tutte le informazioni relative all'utilizzo del disco da parte di contenitori, immagini e volumi Docker.
Ecco cosa mostra il mio sistema attuale (è una nuova installazione)
➟ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 10 1 84.17MB 84.17MB (100%)
Containers 1 1 8.219MB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Eliminazione del sistema Docker
Se hai mai desiderato rimuovere (1) tutte le reti inutilizzate, (2) le immagini penzolanti, (3) i contenitori interrotti, (4) tutti i volumi inutilizzati, c'è una grande possibilità che tu abbia usato o sei abituato a usare quattro comandi separati per ottenere il lavoro.
docker network prune && \
docker image prune && \
docker volume prune && \
docker container prune
Se in precedenza non eri a conoscenza di container prune come me, il comando diventa ancora più grande. Fortunatamente per noi, tutto questo può essere fatto usando un semplice comando, vale a dire docker system prune --volumes .
Per impostazione predefinita docker system prune non rimuove i volumi, per questo è necessario utilizzare il --volumes opzione. Questo comando cancella anche la cache di build per te.
Puoi usare il -f opzione per evitare il (a volte) fastidioso prompt. Vedi l'esempio seguente:
➟ docker system prune --volumes -f
Deleted Containers:
672d39c1a78969887f411ce9139e74e5b21c31fccf2bcf8c1190a9e166089ede
Deleted Networks:
Example
SSHnet
Dummy
Deleted Volumes:
dummy
Total reclaimed space: 0B
Altre opzioni includono -a che rimuove tutte le immagini non utilizzate, non solo quelle penzolanti.
Eventi del sistema Docker
Questo comando potrebbe non essere sempre utile, ma è qualcosa di cui tutti dovrebbero essere a conoscenza.
docker system events o docker events in breve ti dà eventi in tempo reale direttamente per il demone docker (dockerd ). Questo può aiutare a monitorare determinati eventi, ad esempio quando un'immagine è stata rimossa.
Guarda lo screenshot qui sotto per capirlo meglio.
2. Il sottocomando di contesto
Questo è un altro bellissimo sottocomando di cui non molti sono a conoscenza, per quanto ne so. Un contesto per l'esecuzione di qualsiasi comando Docker è costituito da un paio di coppie chiave-valore, che includono, ma non sono limitate a, l'endpoint, l'host, forse qualche file di configurazione, ecc.
Una volta creato, un contesto può essere riutilizzato in seguito.
Uno dei più grandi casi d'uso pratici, in particolare per me, è stato la creazione di contesti separati per i singoli server su cui è in esecuzione la finestra mobile. Poiché la maggior parte del mio lavoro ruota attorno ad esso, invece di accedere al server ogni volta, utilizzo il mio client locale con il server Docker di rimozione su SSH.
Come configurare l'accesso remoto a Docker Daemon [Guida dettagliata]Non vuoi accedere a ssh nel server remoto e quindi eseguire comandi docker? Puoi configurare l'accesso remoto alla finestra mobile che offre anche altri vantaggi.
Linux HandbookDebdut Chakraborty 
Lascia che ti mostri come posso ottenere questo risultato con i contesti docker.
Per prima cosa ho un server distribuito su Linode, che ha la finestra mobile in esecuzione. Se dovessi accedere al demone Docker remoto, senza contesti, utilizzerei un comando come il seguente
➟ docker --host ssh://[email protected]:7770 ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bb4fa8390ab7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 2 hours ago Up 2 hours reverse-proxy_letsencrypt_1
ccdda507facb jwilder/nginx-proxy "/app/docker-entrypo…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp reverse-proxy_reverse_proxy_1
Quindi per accedere al demone remoto dovrei fare l'alias docker a docker --host ssh://[email protected]:7770 oppure utilizza una variabile di ambiente DOCKER_HOST . Ma questi rendono molto difficile il passaggio ad altri host. Un'alternativa più semplice è creare semplicemente un contesto.
Il comando seguente crea un contesto chiamato remote , per un endpoint Docker con un host diverso da quello locale.
docker context create remote --description "Remote docker server" --docker "host=ssh://[email protected]:7770"
L'output è simile a questo:
➟ docker context create remote --description "Remote docker server" --docker "host=ssh://[email protected]:7770"
remote
Successfully created context "remote"
Ora puoi usare il -c opzione con docker se vuoi controllare qualcosa velocemente o per operazioni ripetute, cambia il contesto in questo nuovo.
Con il -c opzione:
➟ docker -c remote ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bb4fa8390ab7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 2 hours ago Up 2 hours reverse-proxy_letsencrypt_1
ccdda507facb jwilder/nginx-proxy "/app/docker-entrypo…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp reverse-proxy_reverse_proxy_1
Con docker context use [CONTEXT_NAME] :
➟ docker context use remote
remote
Current context is now "remote"
~
➟ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bb4fa8390ab7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 2 hours ago Up 2 hours reverse-proxy_letsencrypt_1
ccdda507facb jwilder/nginx-proxy "/app/docker-entrypo…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp reverse-proxy_reverse_proxy_1
Per uscire dal contesto, usa use sottocomando con default per il nome del contesto:
➟ docker context use default
default
Current context is now "default"
~
➟ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3. Il sottocomando pausa e riattiva
Le grandi distribuzioni (applicazioni) sono ora suddivise in più componenti, meglio conosciuti come microservizi. Quando li distribuisci usando qualcosa come docker-compose, a volte succede che un componente si avvia prima di quello da cui dipende. Questo è un problema perché poiché la sua dipendenza (o le sue dipendenze) non è ancora stata avviata, questo componente non si avvierà.
Puoi mitigare questo problema usando i criteri di riavvio in Docker, ma non impediscono di inondare il registro con tentativi non riusciti. Quello che facevo all'inizio è semplicemente fermare il contenitore/servizio fino a quando la dipendenza non è stata completamente avviata.
Un modo migliore è mettere in pausa il container per un po' e, una volta che i servizi necessari sono stati attivati con successo, puoi riattivare il container e tutto andrà avanti da lì senza problemi.
Sebbene i container siano veloci da avviare, questo è un modo ancora più veloce per contrastare un problema del genere.
La sintassi per pause e unpause è abbastanza semplice.
docker pause [CONTAINER_NAME|ID]
docker unpause [CONTAINER_NAME|ID]
Questo conclude questo articolo per ora. Se trovo altri comandi di questo tipo, utili o interessanti, aggiornerò questo articolo di conseguenza.
Hai un comando Docker che pensi avrebbe dovuto essere in questo elenco? Fammi sapere nei commenti in basso.