Si usa Docker por un tiempo, probablemente ya tenga un flujo de trabajo simple y efectivo hecho a su medida, que incluye algunos de sus comandos favoritos de Docker (los subcomandos son técnicamente correctos).
Por ejemplo, solía eliminar los contenedores que no se estaban ejecutando usando un comando largo que se parece a este docker container rm $(docker container ps -qf status=exited) , funcionó, obviamente arrojando un error cada vez que no había contenedores colgando. Esto se detuvo un día cuando descubrí que también tenemos una prune subcomando para contenedores! Así que ahora ese comando largo se ha reducido a una simple docker container prune .
El punto es que a pesar de que muchos de nosotros hemos estado usando Docker por un tiempo, existe la posibilidad de que algunas cosas se hayan pasado por alto, o tal vez incluso se hayan olvidado con el tiempo.
En este artículo, le daré tres subcomandos de la ventana acoplable, que pueden ser nuevos para usted, o no los está usando mucho, pero creo que debería hacerlo.
Estos subcomandos también pueden incluir sus propios subcomandos.
1. El subcomando del sistema
Docker tiene un system comando que te da algo información a nivel del sistema relacionada con docker. De hecho, ha estado usando uno de sus subcomandos por un tiempo. Recuerda docker info ? Este comando es en realidad docker system info .
Para saber más sobre este subcomando y lo que ofrece, ejecute --help opción en él.
➟ 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.
Repasemos cada uno de estos subcomandos, ya que creo que todos son muy críticos.
Sistema Docker df
¿Alguna vez ha estado en una situación en la que el espacio en disco de su servidor parecía estar casi lleno? Para inspeccionar si son los contenedores (en ejecución/volúmenes), probablemente haya estado usando el du comando directamente en la raíz de datos.
Usando du en la raíz de datos requiere sudo acceso.
✗ du -h --max-depth=1 /var/lib/docker
du: cannot read directory '/var/lib/docker': Permission denied
4.0K /var/lib/docker
No solo eso, para saber explícitamente cuánto se están asignando los volúmenes o las imágenes, tendría que ejecutar el comando varias veces.
➟ 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/
Una alternativa mucho mejor es llamar al docker system df dominio. Esto detectará automáticamente la raíz de datos y, en consecuencia, imprimirá toda la información relacionada con el uso del disco por parte de los contenedores, imágenes y volúmenes de Docker.
Esto es lo que muestra mi sistema actual (es una nueva instalación)
➟ 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
Recorte del sistema Docker
Si alguna vez quiso eliminar (1) todas las redes no utilizadas, (2) imágenes colgantes, (3) contenedores detenidos, (4) todos los volúmenes no utilizados, existe una gran posibilidad de que haya usado o esté acostumbrado a usar cuatro comandos separados para lograr el trabajo.
docker network prune && \
docker image prune && \
docker volume prune && \
docker container prune
Si no sabías sobre container prune como yo, entonces el comando se vuelve aún más grande. Por suerte para nosotros, todo esto se puede hacer con solo un comando simple, a saber, docker system prune --volumes .
Por defecto docker system prune no elimina los volúmenes, para eso necesita usar --volumes opción. Este comando también borra el caché de compilación por usted.
Puedes usar el -f opción para evitar el aviso (a veces) molesto. Vea el siguiente ejemplo:
➟ docker system prune --volumes -f
Deleted Containers:
672d39c1a78969887f411ce9139e74e5b21c31fccf2bcf8c1190a9e166089ede
Deleted Networks:
Example
SSHnet
Dummy
Deleted Volumes:
dummy
Total reclaimed space: 0B
Otras opciones incluyen -a que elimina todas las imágenes no utilizadas, no solo las que cuelgan.
Eventos del sistema Docker
Es posible que este comando no sea útil todo el tiempo, pero es algo que creo que todos deberían conocer.
docker system events o docker events para abreviar, le brinda eventos en tiempo real directamente para el demonio docker (dockerd ). Esto puede ayudar a monitorear ciertos eventos, como cuando se eliminó una imagen, por ejemplo.
Vea la captura de pantalla a continuación para entender esto mejor.
2. El subcomando de contexto
Este es otro hermoso subcomando que no muchos conocen hasta donde yo sé. Un contexto para la ejecución de cualquier comando docker es un par de pares clave-valor, que incluyen, entre otros, el punto final, el host, tal vez algún archivo de configuración, etc.
Una vez que haya creado un contexto, puede reutilizarlo más adelante.
Uno de los casos de uso práctico más grandes, especialmente para mí, ha sido crear contextos separados para los servidores individuales que tengo en ejecución. Dado que la mayor parte de mi trabajo gira en torno a él, en lugar de iniciar sesión en el servidor cada vez, uso mi cliente local con el servidor docker de eliminación a través de SSH.
Cómo configurar el acceso remoto a Docker Daemon [Guía detallada] ¿No desea acceder al servidor remoto y luego ejecutar los comandos de Docker? Puede configurar el acceso remoto a la ventana acoplable que también tiene otros beneficios.
Manual de LinuxDebdut Chakraborty 
Déjame mostrarte cómo logro esto con los contextos de la ventana acoplable.
Primero, tengo un servidor implementado en Linode, que tiene la ventana acoplable en ejecución. Si tuviera que acceder al demonio docker remoto, sin contextos, estaría usando un comando como el siguiente
➟ 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
Entonces, para acceder al demonio remoto, tendría que usar un alias docker a docker --host ssh://[email protected]:7770 , o use una variable de entorno DOCKER_HOST . Pero esto hace que cambiar a otros hosts sea muy difícil. Una alternativa más fácil es simplemente crear un contexto.
El siguiente comando crea un contexto llamado remote , para un punto final de docker con un host diferente al local.
docker context create remote --description "Remote docker server" --docker "host=ssh://[email protected]:7770"
La salida se ve así:
➟ docker context create remote --description "Remote docker server" --docker "host=ssh://[email protected]:7770"
remote
Successfully created context "remote"
Ahora puedes usar -c opción con docker si desea verificar algo rápidamente o para operaciones repetidas, cambie el contexto a este nuevo.
Con el -c opción:
➟ 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
Para salir del contexto, use el use subcomando con default para el nombre de contexto:
➟ docker context use default
default
Current context is now "default"
~
➟ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3. El subcomando pausar y reanudar
Las grandes implementaciones (aplicaciones) ahora se dividen en varios componentes, más conocidos como microservicios. Cuando los implementa usando algo como docker-compose, a veces lo que sucede es que un componente se inicia antes que el que depende. Esto es un problema porque dado que su dependencia (o dependencias) aún no se ha iniciado, este componente no se iniciará.
Puede mitigar este problema mediante el uso de políticas de reinicio en Docker, pero no evitan que se inunde el registro con intentos fallidos. Lo que solía hacer al principio era simplemente detener el contenedor/servicio hasta que la dependencia se haya iniciado por completo.
Una mejor manera es simplemente pausar el contenedor por un tiempo, y una vez que los servicios necesarios hayan aparecido con éxito, puede reanudar el contenedor y todo avanzará desde allí sin problemas.
Aunque los contenedores giran rápidamente, esta es una forma aún más rápida de contrarrestar este problema.
La sintaxis de pause y unpause es bastante simple.
docker pause [CONTAINER_NAME|ID]
docker unpause [CONTAINER_NAME|ID]
Eso concluye este artículo por ahora. Si encuentro más comandos de este tipo, útiles o interesantes, actualizaré este artículo en consecuencia.
¿Tiene un comando de Docker que cree que debería haber estado en esta lista? Házmelo saber en los comentarios a continuación.