Herramientas de verificación de salud Docker

Por Javier Ramírez

En este post trataremos de dar una breve pincelada a cada una de las herramientas que Docker provee out-of-box para realizar un seguimiento del estado del entorno.

Veremos desde herramientas de gestión de estado de los propios contenedores/tareas hasta herramientas que proporcionan información de la plataforma de ejecución.

Docker ps

Comenzaremos con el comando probablemente más usado por todos, docker ps, que nos proporciona información acerca de los contenedores presentes en el sistema, tanto en ejecución como parados.

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

707a5f3db491 nginx “nginx -g ‘daemon …” 6 minutes ago Up 5 minutes 80/tcp, 443/tcp test

Por defecto, docker ps sólo muestra los contenedores en ejecución. Para poder ver los parados presentes en el sistema, añadimos la opción –all.

Podemos filtrar la salida para únicamente mostrar los contenedores creados a partir de una imagen concreta, asociados a un servicio (revisando la etiqueta “com.docker.swarm.service.name“). Por ejemplo podemos ver los IDs asociados a servicios.

$ docker ps -a –filter “label=com.docker.swarm.service.name” –format “table {{.ID}}\t{{.Labels}}”

CONTAINER ID LABELS

a0b66ab80d44 com.docker.swarm.task.id=el8kwxcch3udsbd9ab1wbd7ma,com.docker.swarm.task.name=test.1.el8kwxcch3udsbd9ab1wbd7ma,

com.docker.swarm.node.id=2crc1mrbzqquvkiy70eic48wx,com.docker.swarm.service.id=o4pa38gwid6qb1z4zcj9kosze,

com.docker.swarm.service.name=test,com.docker.swarm.task=…

Tanto el filtrado como el formateo de la salida nos permiten jugar para poder obtener los resultados necesarios en cada momento de la forma más eficiente posible.

Desde la versión 1.12, con la llegada de swarm mode, tenemos además la existencia de servicios, de manera que cada servicio está compuesto por una serie de instancias o tareas (tasks) que definimos para proporcionar este servicio (recordemos que podemos crear servicios globales y replicados).

Docker service ps

Cuando trabajamos con servicios, el concepto de réplicas, instancias o tareas necesita de una asociación adicional a nivel de contenedor. Para ello usamos docker service ps para obtener información sobre los contenedores creados para cada servicio.

$ docker service ps test1

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS

3d3ctpfs6cre test1.1 nginx:latest sirius Running Running 9 seconds ago

2f52jjsqizsy test1.2 nginx:latest sirius Running Running 9 seconds ago

v2wovgq4avz8 test1.3 nginx:latest sirius Running Running 9 seconds ago

Podremos realizar el filtrado por ejemplo para obtener la tarea con un identificador de instancia o nombre concretos. Así, podríamos usar el siguiente ejemplo para obtener únicamente la tarea llamada “test1.1”

$ docker service ps –filter name=test1.1 test1 –no-trunc

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS

3d3ctpfs6cre8fty6d4uh2rey test1.1 nginx:latest@sha256:f2d384a6ca8ada733df555be3edc427f2e5f285ebf468aae940843de8cf74645 sirius Running Running 6 minutes ago

En general tanto docker ps como su homólogo para trabajar con las tareas asociadas a los servicios, docker service ps, proporcionan información sobre el estado de los contenedores y su distribución en los diferentes nodos del cluster.

Docker stats

Para verificar el consumo de recursos de los contenedores podemos usar docker stats. Esta herramienta nos permite observar el consumo en tiempo real de los contenedores o tareas asociados a un servicio que se ejecutan en el host. Podemos formatear su salida para obtener los campos de forma simplificada o sencillamente para obtener los nombres asociados.

$ docker stats

CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS

7a5c5bb61493 0.00% 7.723 MiB / 11.63 GiB 0.06% 28.2 kB / 648 B 7.22 MB / 0 B 2

92e89dd8d077 0.00% 7.719 MiB / 11.63 GiB 0.06% 28.2 kB / 648 B 6.98 MB / 0 B 2

57ce088ee69c 0.00% 7.852 MiB / 11.63 GiB 0.07% 28.2 kB / 648 B 7.99 MB / 0 B 2

df70f7b35ce3 0.00% 6.18 MiB / 11.63 GiB 0.05% 57 kB / 648 B 5.69 MB / 0 B 2

c5921a8d0be6 0.00% 7.727 MiB / 11.63 GiB 0.06% 56.8 kB / 648 B 6.94 MB / 0 B 2

^C

Docker stats se ejecuta como stream, actualizando los datos constantemente, pero podemos usar –no-stream para obtener su salida instantánea. Además, es posible especificar los contenedores de los que queremos obtener la información usando su nombre o identificador.

$ docker stats affectionate_sammet c5921a8d0be

CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS

affectionate_sammet 0.00% 56 KiB / 11.63 GiB 0.00% 5.67 kB / 648 B 0 B / 0 B 1

c5921a8d0be6 0.00% 7.727 MiB / 11.63 GiB 0.06% 60.9 kB / 648 B 6.94 MB / 0 B 2

^C

Si lo que queremos obtener es una captura del consumo en un momento concreto, podremos usar –no-stream, como en el siguiente ejemplo, en el que se combina además el uso de formato para obtener los datos de porcentaje de uso de CPU, uso de memoria y el porcentaje de la misma en el sistema.

$ docker stats –format “table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}} ({{.MemPerc}})” –no-stream

NAME CPU % MEM USAGE / LIMIT MEM %

affectionate_sammet 0.00% 56 KiB / 11.63 GiB (0.00%)

test1.1.3d3ctpfs6cre8fty6d4uh2rey 0.00% 7.723 MiB / 11.63 GiB (0.06%)

test1.3.v2wovgq4avz8knpbldtvvg1rc 0.00% 7.719 MiB / 11.63 GiB (0.06%)

test1.2.2f52jjsqizsyza96gdvvo6408 0.00% 7.852 MiB / 11.63 GiB (0.07%)

kk.ehglbr9qzl07gifot80mj34b9.8evbu73uv7q480d33sawj4u0t 0.00% 6.18 MiB / 11.63 GiB (0.05%)

mad_bassi.1.4o4k86q19p0l08ximhgo1oq05 0.00% 7.727 MiB / 11.63 GiB (0.06%)

Healthcheck

Docker 1.12 añadió la funcionalidad de healthcheck, que permite proporcionar un comando o script de verificación de estado del contenedor o tarea. De esta forma, podemos detectar problemas de servicio cuando el proceso maestro está en ejecución, por ejemplo cuando el rendimiento de nuestra aplicación se ve afectado.

Es posible configurar el intervalo entre verificaciones de estado, el tiempo de respuesta/finalización del script o comando y el número de ejecuciones que deben ser erróneas antes de indicar el contenedor/tarea como erróneo o caído.

Simplemente con un script o comando y su salida podremos gestionar el comportamiento. No se mostrará el estado hasta la primera ejecución y antes de ese momento aparecerá como “starting”.

Como ejemplo sencillo, creamos una imagen de nginx con alpine con curl y añadimos el healthcheck en tiempo de ejecución, aunque por supuesto podemos incluirlo en la imagen.

$ cat Dockerfile.healthtest

FROM nginx:alpine

RUN apk –update –no-cache add curl

$ docker build -t healthtest .

Sending build context to Docker daemon 2.048 kB

Step 1/2 : FROM nginx:alpine

—> 2f3c6710d8f2

Step 2/2 : RUN apk –update –no-cache add curl

—> Running in 595b007e95d6

fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz

fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz

fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz

fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz

(1/4) Installing ca-certificates (20161130-r0)

(2/4) Installing libssh2 (1.7.0-r0)

(3/4) Installing libcurl (7.52.1-r0)

(4/4) Installing curl (7.52.1-r0)

Executing busybox-1.24.2-r11.trigger

Executing ca-certificates-20161130-r0.trigger

OK: 55 MiB in 28 packages

—> 44723a5885ec

Removing intermediate container 595b007e95d6

Successfully built 44723a5885ec

$ docker run -d -P –name healthtest –health-cmd “curl -sSLq 0.0.0.0:80 -o /dev/null” –health-interval 30s healthtest

885939189bb5bf790e2345c1906dbf4558a803da487cd14909053341ebd3a607

La salud del contenedor no se indica hasta la primera ejecución del script o comando.

$ docker inspect –format='{{json .State.Health}}’ healthtest

{“Status”:”starting”,”FailingStreak”:0,”Log”:[]}

Tras 30s, observamos que el resultado del comando es correcto y se considera ‘healthy’.

$ docker inspect –format='{{json .State.Health}}’ healthtest

{“Status”:”healthy”,”FailingStreak”:0,”Log”:[{“Start”:”2017-02-12T00:05:04.375005338+01:00″,”End”:”2017-02-12T00:05:04.499081417+01:00″,”ExitCode”:0,”Output”:””}]}

Docker logs

La salida estándar y de error de cada contenedor pueden consultarse en el log del mismo. Redirigiremos pues cualquier log del aplicativo levantado en él a una de estas dos salidas para poder unificarlos y gestionarlos. Esta salida de log puede redirigirse a un gestor de logs usando los drivers de log (syslog, journald, gelf, fluentd, etc…, por defecto la salida se guardará en formato json). Cada driver requiere de su propia configuración y es posible elegir el método para cada contenedor/tarea de forma individual. De esta forma podremos tratar de forma unificada los logs fuera de la plataforma Docker.

Por otra parte, es posible que nuestro aplicativo requiera almacenar los datos por motivos de seguridad o auditoría de forma local o remota usando volúmenes

Usando el contenedor en ejecución del ejemplo de healthcheck, observamos la salida del log de acceso, redirigido desde access.log a la salida estándar (/dev/stdout, véase la construcción de la imagen nginx:alpine), en la que pueden verse todas las verificaciones de estado.

$ docker logs healthtest

127.0.0.1 – – [11/Feb/2017:23:05:04 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:05:34 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:06:04 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:06:34 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:07:04 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:07:34 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:08:04 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:08:34 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:09:04 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

127.0.0.1 – – [11/Feb/2017:23:09:34 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.52.1” “-“

Docker service logs

Docker service logs (disponible acutalmente con docker en modo experimental) viene a completar la gestión de servicios en modo swarm. Desde que Docker planteó el cambio en la forma de crear y gestionar el cluster, uno de los puntos que echamos en falta fue la gestión unificada de los logs de un servicio y todas sus tareas/contenedores asociados. En versiones anteriores, la gestión de aplicaciones multicontenedor o multiservicio (hay que entender que el concepto de servicio en 1.11 no es exactamente el mismo que en 1.12 y posteriores), se realizaba con docker-compose. Esta herramienta proporcionaba un lugar unificado de ejecución, gestión y obtención de datos de estado y logs.

De forma similar a docker-compose, cuando ejecutamos docker service logs sobre un servicio, obtenemos de forma unificada los logs de todas las tareas/contenedores que conforman este servicio. Nos permite observar la salida de forma continua de todos los logs de los contenedores/tareas que forman parte del servicio si aplicamos –follow, esto nos proporciona una herramienta muy eficaz de debug cuando buscamos posibles problemas de despliegue o ejecución.

Supongamos por ejemplo la ejecución de un servicio global:

$ docker service create –name cagent –mode global \

> –network collectd \

> –env GRAPHITE_SERVER=graphite \

> –env PLUGINS=”docker write_graphite” \

> –label service_name=”docker-statistics” \

> –mount type=volume,source=COLLECTD_AGENT,target=/DATA,volume-driver=local \

> –mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \

> –mount type=bind,src=/etc/timezone,dst=/etc/timezone,readonly \

> –mount type=bind,src=/etc/localtime,dst=/etc/localtime,readonly \

> frjaraur/collectd agent

65qfzcn44q5ya6eyqlw4fhnf6

De forma sencilla, observamos el log de la tarea arrancada en todos los nodos del cluster:

$ docker service logs cagent

cagent.0.up9b0y56ofan@swarmnode1 | plugin_load: plugin “python” successfully loaded.

cagent.0.up9b0y56ofan@swarmnode1 | Docker stats use stream

cagent.0.up9b0y56ofan@swarmnode1 | [2017-02-05 12:36:10] plugin_load: plugin “rrdcached” successfully loaded.

cagent.0.ip84bd6ptss4@swarmnode2 | plugin_load: plugin “python” successfully loaded.

cagent.0.ip84bd6ptss4@swarmnode2 | [2017-02-05 12:35:41] plugin_load: plugin “rrdcached” successfully loaded.

cagent.0.ip84bd6ptss4@swarmnode2 | [2017-02-05 12:35:41] plugin_load: plugin “rrdtool” successfully loaded.

cagent.0.ip84bd6ptss4@swarmnode2 | [2017-02-05 12:35:41] plugin_load: plugin “write_graphite” successfully loaded.

cagent.0.ip84bd6ptss4@swarmnode2 | Docker stats use stream

cagent.0.ip84bd6ptss4@swarmnode2 | [2017-02-05 12:35:41] Collecting stats about Docker containers from unix://var/run/docker.sock (API version 1.25; timeout: 3s).

cagent.0.ip84bd6ptss4@swarmnode2 | [2017-02-05 12:35:41] Initialization complete, entering read-loop.

cagent.0.4khq0iqipsve@swarmnode3 | plugin_load: plugin “python” successfully loaded.

cagent.0.4khq0iqipsve@swarmnode3 | [2017-02-05 12:35:41] plugin_load: plugin “rrdcached” successfully loaded.

cagent.0.4khq0iqipsve@swarmnode3 | [2017-02-05 12:35:41] plugin_load: plugin “rrdtool” successfully loaded.

cagent.0.4khq0iqipsve@swarmnode3 | [2017-02-05 12:35:41] plugin_load: plugin “write_graphite” successfully loaded.

cagent.0.4khq0iqipsve@swarmnode3 | Docker stats use stream

cagent.0.4khq0iqipsve@swarmnode3 | [2017-02-05 12:35:41] Collecting stats about Docker containers from unix://var/run/docker.sock (API version 1.25; timeout: 3s).

Docker system df

Docker system df proporciona información de espacio de uso de docker en nuestro sistema.

$ docker system df

TYPE TOTAL ACTIVE SIZE RECLAIMABLE

Images 109 27 24.35 GB 18.77 GB (77%)

Containers 165 0 3.687 GB 3.687 GB (100%)

Local Volumes 140 71 10.73 GB 10.62 GB (98%)

Nos fijamos en la columna que nos muestra el tamaño que podemos recuperar (RECLAIMABLE). En mi ejecución actual, dado que no tengo ningún contenedor en ejecución, el espacio recuperable es del 100% (se entiende que en este host no requiere tener ningún contenedor arrancado, OJO).

Para obtener una información mucho más detallada de dónde está distribuido este espacio, usaremos la opción verbose; de manera que obtendremos un listado detallado agrupado por imágenes, contenedores y volúmenes. Esto nos permite observar dónde está nuestro espacio desperdiciado.

$ docker system df –verbose

Images space usage:

REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS

frjaraur/docker-on-docker latest 98fdd0c619ae 8 days ago 191.6 MB 191.6 MB 0 B 0

<none> <none> da37a5146010 8 days ago 191.6 MB 191.6 MB 0 B 0

<none> <none> 24ed94786e08 8 days ago 191.6 MB 191.6 MB 0 B 0

rundeck latest 9c29715f132b 8 days ago 633 MB 633 MB 0 B 1

<none> <none> 24f04e681be2 8 days ago 633 MB 633 MB 0 B 3

<none> <none> 9e34a103b9f5 8 days ago 739.5 MB 129.5 MB 610 MB 1

registry.gitlab.com/codegazers/docker-rsyslogd latest 7d78bbcd48d8 2 weeks ago 11.78 MB 11.78 MB 0 B 0

frjaraur/rsyslogd latest 2077826348da 2 weeks ago 11.78 MB 11.78 MB 0 B 1

<none> <none> 95c1c4c2f19e 2 weeks ago 11.78 MB 11.78 MB 3.672 kB 0

hdp-deployer latest 1fc3448f9516 2 months ago 204.2 MB 204.1 MB 90.5 kB 0

hdp-deployer base d530c0997ca5 2 months ago 204.1 MB 204.1 MB 0 B 0

hdp-core latest ca63920b7637 2 months ago 3.36 GB 763.4 MB 2.596 GB 0

hdp-client latest b00de9443d43 2 months ago 2.538 GB 763.4 MB 1.774 GB 0

hdp-base latest ad1cc057e22a 2 months ago 763.4 MB 763.4 MB 0 B 0

frjaraur/nginx-repo latest 952f3301af4b 2 months ago 6.883 MB 6.882 MB 968 B 0

<none> <none> 3034b40630a2 3 months ago 389.8 MB 389.8 MB 0 B 0

frjaraur/translator latest 4b84af995ea7 3 months ago 103.1 MB 87.6 MB 15.49 MB 0

Containers space usage:

CONTAINER ID IMAGE COMMAND LOCAL VOLUMES SIZE CREATED STATUS NAMES

418f92b26399 nginx “nginx -g ‘daemon …” 0 0 B 19 hours ago Exited (0) 17 hours ago test

4135bc60eb06 rundeck “/entrypoint.sh” 2 14.9 MB 8 days ago Exited (255) 6 days ago rundeck

5a48ae61b2e1 frjaraur/rsyslogd “/entrypoint.sh help” 2 0 B 2 weeks ago Exited (0) 2 weeks ago backstabbing_hamilton5

9f8efa24c24d d927754ac667 “/entrypoint.sh help” 2 153 B 2 weeks ago Exited (0) 2 weeks ago stoic_golick

35373f48c9aa alpine “logger testing” 2 0 B 2 weeks ago Exited (0) 2 weeks ago fervent_curie

20abda9fe3a7 alpine “sh” 2 12 B 2 weeks ago Exited (0) 2 weeks ago 5d768b0334c8 docker-do “/entrypoint.sh 0….” 0 51.2 kB 4 weeks ago Exited (0) 4 weeks ago do

71c10e410ba4 microsoft/dotnet:latest “/bin/bash” 0 11 B 7 weeks ago Exited (0) 7 weeks ago f1530414d728 baa5d63471ea “/bin/sh -c ‘apk a…” 0 766 kB 8 weeks ago Exited (0) 8 weeks ago jolly_liskov

75717b1d4e64 alpine “sh” 0 44 B 2 months ago Exited (0) 2 months ago peaceful_allen

87281136d765 jwilder/nginx-proxy “/app/docker-entry…” 1 0 B 2 months ago Created gigantic_bose2

bd84cac1b67f 637eaa14bc63 “/bin/sh -c ‘apk a…” 0 766 kB 2 months ago Exited (0) 2 months ago adoring_bartik

5318e4192824 dc15734317bf “/bin/sh -c ‘apk a…” 0 0 B 2 months ago Exited (0) 2 months ago pensive_noyce

239c5a7fc8cf 95aacde4feb9 “/entrypoint.sh -a…” 0 0 B 2 months ago Exited (0) 2 months ago jovial_franklin

45dc123d6f74 95aacde4feb9 “/entrypoint.sh -a…” 0 0 B 2 months ago Exited (0) 2 months ago angry_bohr

ef171d144ccc 7d43a8293be0 “/entrypoint.sh -a…” 0 0 B 2 months ago Exited (0) 2 months ago reverent_kirch

1587149334c7 7d43a8293be0 “/entrypoint.sh -a…” 0 0 B 2 months ago Exited (0) 2 months ago pensive_kilby

distracted_lichterman

bec013625c8a ba6bed934df2 “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago tender_rosalind

9029d923149d nginx:alpine “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago rproxy

cfdef5654887 nginx:alpine “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago http4

c2a37e9dd7c9 nginx:alpine “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago http3

14b2ec306841 nginx:alpine “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago http2

bec1848d4f21 nginx:alpine “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago http1

b0f4d308cf84 yyyar/gobetween “/usr/bin/gobetwee…” 0 0 B 2 months ago Exited (0) 2 months ago dreamy_dubinsky

4863e60e9aa9 ba6bed934df2 “nginx -g ‘daemon …” 0 0 B 2 months ago Exited (0) 2 months ago suspicious_banach

a86940385860 yyyar/gobetween “/usr/bin/gobetwee…” 0 0 B 2 months ago Exited (0) 2 months ago adoring_galileo

e2423c565fb3 yyyar/gobetween “/usr/bin/gobetwee…” 0 0 B 2 months ago Exited (0) 2 months ago desperate_hugle

a25975cec66e yyyar/gobetween “/usr/bin/gobetwee…” 0 0 B 2 months ago Exited (0) 2 months ago naughty_wozniak

ff0ac8c18ebc yyyar/gobetween “/usr/bin/gobetwee…” 0 0 B 2 months ago Exited (0) 2 months ago prickly_murdock

2f29385ee8f0 1a1c35cf200e “bash” 0 0 B 4 months ago Exited (0) 4 months ago kickass_jones

a299c61b132f 1a1c35cf200e “nginx -g ‘daemon …” 0 0 B 4 months ago Exited (0) 4 months ago grave_wescoff

c76498887f65 1a1c35cf200e “bash” 0 0 B 4 months ago Exited (0) 4 months ago nauseous_joliot

efae67781cd7 9bcfddcfd579 “bash” 0 21 B 4 months ago Exited (0) 4 months ago tender_wright

Local Volumes space usage:

VOLUME NAME LINKS SIZE

744fb38f0d95ad4036778bc2fe56633dea4b87cea943df31f604bd4a585cc132 1 0 B

CONSUL_AGENT 0 0 B

RSYSLOG 4 40.24 kB

e1a0f112f966e05b9685b5636b34e75ac9d80021e6e31278f5cc795b59b75f5b 1 0 B

e655c4a55f88201e78d75e22d4f7c317067af12ba5486d4169e9d50677183962 0 226.5 MB

f98db9f70506ff354a8f7125b13dff424b22777bd82caf148bd4584b06dfa564 1 0 B

fd98e64f78977370894ee2fa4168012931b967111fdd2f566c363fe0d9f22876 0 226.6 MB

652f12feeaa5494d6a0982e6665e5b1a4e41ed92a81ab05b5cbe9e0849379b38 1 0 B

9b65fd7e070f8a25682a56e76cbf7047d64d13c572b28c70c67b5be86e0c70e2 1 0 B

b2288aadab74ae3926a9da28e2987569b9a7a8e50bfb2912efc8789336a73263 0 119.5 MB

6136d291ee137530dfc93810cda2eb3ff866b7a4df651d5e15d68f36b7a4276c 1 0 B

GITLABlogs 0 120.2 kB

a8fc77d40866026cea190bad3ca0272c735619fb2c3a691b8d7d5d86a788ba5c 1 0 B

b96cda8a84399f72f4c5271f6bbccb1da0cedc0ed19436228513e388782fd32f 0 199.7 MB

bf1967d8a9a22d49b65f7ab3728d8b5e755d075ad588854eb62235c56de5d30d 0 199.7 MB

1c17d488c743e72c4d4ece0dc266cb398f7180974c61ca62d5fd3e3e6711cd05 1 0 B

015202af06af813f6dae50062308d67a5ae77216596b500f75bf691772aa0e2d 0 226.6 MB

116f4d624e32aa5318770ffcc2c6f476a059de0f1f0d2b5c3f73a23f564d3b17 0 227.7 MB

6a981ceefd8cdb7b5f9e04ea756c6d6f495e67eeedbfdf2be43555fc40d8ed57 0 0 B

68f42ab10763ab416e1636865b74ac79fdf94a5f60c41f3c1196a85bd0c22606 0 220.9 MB

b3f730c9c58ef2120222c8af4c590308525c03766c9cd7127abe10b663f2b918 1 0 B

27f4a81385ec8b274522b40eb73899024f2ca1ff62afab3b782d543452dd163b 0 199.7 MB

ace6659d6243090f54f289950d1d0009951450a1ca631c550953b10d3fa4a46b 1 16.09 kB

2e2ab4b5a405841d8c3affc5fae5565d95869f85cc39a83240743dd574c0fc15 0 199.7 MB

3454a8cd432e3a2d6bc54c835908c52b1a877f382c2dba76cdf3c5c8b698fb60 0 223.4 MB

b3af124065021365566dc12f76eee10201e4f674d8893c6ba060725393c70d5d 1 0 B

bf41478098e95a53f7a3848423def14df6e531797b6e21215b08bd0742fcfb16 0 209.6 MB

fb845a5a472a27704718dad3d9bf4d3d2cdcbfc35e949e2be324e675a6ef7365 0 226.6 MB

GITLABdata 0 48.04 MB

cdc89b5e1de3ae5e536ff78cbe647d5ed44977d2f17f7569c8f5bb9f7bc62d51 0 0 B

24276be60044923cb7d7cbe63e005a61aeb941ea5823410b480f1944e41f0229 1 48 B

CONSUL_SERVER2 1 9.562 MB

c923669816c16d0fa4edd8ec5484a47d8d4ffdf2412ad20ac9bb6a6746ae4b11 0 226.6 MB

2bf46a5a4d82854a60eda9bcdd5350377dfcffb10b73cf25d23ded64ba767515 0 227.7 MB

216e05884746050596fa29a8bacea91d327446f87f839e3e8363db9156063415 1 0 B

52aec9df4887794091b6466ddd79e818450884171b0ab40e546fce6d724b0620 0 199.7 MB

9c29fefd78c8a66c05b37f6dcc5bbd56f176490b70b22d5bb868adfb6425f70c 0 226.6 MB

CONSUL_SERVER1 1 9.562 MB

be699c1d3d1a8b6ab2c4efa16258b511961cf3ce3befc157bb18a8492759c744 0 23.3 MB

d99fc884e2a21211013d17e227f8f84668667d97ed49d071524b54770ac2a702 1 0 B

45a3c03421a9a0497494654eefdec21c5f8784d57b51650954c762c8a6dc8810 1 48 B

GITLABconfig 0 58.63 kB

11fbd4eddf3fa86761c2f40b1d4cbc23604d0ec3c145ec3b379b531cec39866d 0 200.2 MB

RSYSLOGFWDEV 0 48 B

ebfd82532ad2d047277a66afe4b1341db47ff43ab1526167760e84a1497cd84c 0 227.8 MB

9e19d2fa9bf03b2035d6c20449483d7b38bd3ff398e230512c1d6630fef30b67 0 0 B

CONSUL_MASTER 1 37 MB

611295a09cb61c14707935a9eed0955d136d28897190ae79142aabadb9a95115 1 0 B

7615f128ac302572daad6a4d8534a112849b6bef1454655fe4c295c42073ed4e 1 0 B

214545173a87532fa799b660d326d77a2e596917a384a776403afc6c8ee5941a 1 0 B

40cdb76ab6583712c96a0c3b0fd5550694585e6e830216580d8eb20330c6407e 0 2.315 MB

aed184f612798b5cab90fb2ce5fdb00252bae3580f92936d97edf0fb689ec716 0 119.5 MB

Con esta información, podríamos comenzar a borrar datos que conocemos innecesarios. Es importante resaltar la importancia de que los volúmenes tengan una nomenclatura conocida de manera que sea sencillo y rápido asociarlos al servicio o aplicativo correspondiente. Podremos usar ahora de forma habitual los comandos habituales de borrado de volúmenes (docker volume rm), contenedores (docker rm) e imágenes (docker rmi). Es posible usar el nuevo comando docker system prune, que permite realizar este borrado de forma más sencilla. Esta nueva funcionalidad disponible en 1.13 permite visualizar de forma resumida el espacio que recuperaremos en el borrado, pero no permite realizar una selección tan rigurosa como la realizada de forma manual.

Docker images

Las imágenes en nuestro sistema pueden ocupar mucho espacio y cada actualización o creación de las mismas puede suponer la generación de gran cantidad de datos de forma temporal que luego es necesario borrar. Docker ha mejorado esto como hemos visto con docker system prune, pero también podemos usar docker images de forma sencilla para localizar las imágenes que más espacio ocupan y así borrarlas si no se utilizan:

$ docker images –format “{{.Size}}\t{{.ID}}\t{{.Repository}}:{{.Tag}}” | sort -k 1 -g -r

816 MB 108c722d7099 jenkinsci/workflow-demo:latest

763 MB ad1cc057e22a hdp-base:latest

739 MB 9e34a103b9f5 <none>:<none>

702 MB 39019f4975cb icinga/icinga2:latest

633 MB 9c29715f132b rundeck:latest

633 MB 24f04e681be2 <none>:<none>

581 MB 5448a3faaf72 microsoft/dotnet:latest

390 MB 9d9b9f36e8fb hdp-db-rh:latest

390 MB 7bd2b0b73739 hdp-db:latest

390 MB 66498efd6bd8 mariadb:latest

390 MB 66498efd6bd8 hdp-mariadb:latest

390 MB 3034b40630a2 mariadb:<none>

298 MB 72745ac1cd8f frjaraur/graphite:latest

248 MB 0f63f5446a32 jwilder/nginx-proxy:latest

208 MB 8ae254616ce5 yyyar/gobetween:latest

205 MB 038452c01c97 frjaraur/docker-on-docker:<none>

204 MB f2a51ec798d5 hdp-deployer-rh:latest

204 MB d530c0997ca5 hdp-deployer:base

204 MB 1fc3448f9516 hdp-deployer:latest

197 MB 980e0e4c79ec hdp-centos:latest

197 MB 980e0e4c79ec centos:latest

192 MB da37a5146010 <none>:<none>

192 MB 98fdd0c619ae frjaraur/docker-on-docker:latest

192 MB 65cac4efff73 <none>:<none>

192 MB 2afde8cf1fe0 <none>:<none>

192 MB 24ed94786e08 <none>:<none>

188 MB 1e0c3dd64ccd ubuntu:14.04

188 MB 1e0c3dd64ccd hdp-ubuntu:14.04

182 MB cc1b61406712 nginx:<none>

182 MB 01f818af747d nginx:latest

181 MB dc15734317bf <none>:<none>

181 MB ba6bed934df2 nginx:<none>

131 MB adbcba695f4c frjaraur/stress-ng:latest

130 MB 85d16452e2ac frjaraur/docker-stress:latest

129 MB f49eec89601e ubuntu:16.04

127 MB c73a085dc378 ubuntu:latest

127 MB c73a085dc378 localhost:5000/ubuntu:latest

122 MB 0cd79a37f049 frjaraur/collectd:latest

110 MB a803f4bcef8e docker-do:latest

104 MB 90f065ad819a httpd:alpine

104 MB 025decc4ae99 hdp-repo:latest

103 MB 9f7997b3977c translator:latest

103 MB 4b84af995ea7 frjaraur/translator:latest

87.6 MB e57c79136a08 python:3.5-alpine

82.7 MB d541718124c1 infra-base:latest

81 MB 719a3a082d31 wordpress:4.7.0-fpm-alpine

81 MB 49bc2c4c2caf wp:latest

81 MB 168c50143115 <none>:<none>

54.5 MB d8b8c23ff108 php:5.6-fpm-alpine

54.2 MB 637eaa14bc63 <none>:<none>

54.2 MB 2f3c6710d8f2 nginx:alpine

54.2 MB 2f3c6710d8f2 192.168.1.23:5000/nginx:alpine

51.5 MB c69bad023d14 docker/dtr:latest

38.6 MB f064fd8d3590 hopla/consul:0.7.0

38.6 MB f064fd8d3590 frjaraur/consul:latest

38.6 MB 7608b80d3b4a consul:latest

34.2 MB 5ed5bb9bc6d9 diag:latest

33.3 MB 541a6732eadb registry:2.5

25 MB 9055e1c88f3e registrator:latest

25 MB 6f9acd390039 test:latest

25 MB 503f9f304e3e frjaraur/registrator:latest

23.8 MB 3b59190c6c80 gliderlabs/registrator:latest

21.9 MB fa78efbfb74f ehazlett/interlock:master

21.9 MB cdce78980062 reverse-proxy:latest

21.9 MB 045e527a94b2 hdp-reverse:latest

20 MB 08cd64894407 docker/ucp:latest

11.8 MB fffbf9b94ab0 <none>:<none>

11.8 MB f3a272441ca3 <none>:<none>

11.8 MB da7e9d478cd7 <none>:<none>

11.8 MB d927754ac667 <none>:<none>

11.8 MB d63ecd7181fc <none>:<none>

11.8 MB d47be4061223 <none>:<none>

11.8 MB c98b93345b5b <none>:<none>

11.8 MB b43ce5abcd64 <none>:<none>

11.8 MB afd6aeb8142b <none>:<none>

11.8 MB ae81f0605218 <none>:<none>

11.8 MB a4e217e64c8f <none>:<none>

11.8 MB a414446ca10a <none>:<none>

11.8 MB 9664336ce4c4 <none>:<none>

11.8 MB 95c1c4c2f19e <none>:<none>

11.8 MB 8a67d57a4f9d <none>:<none>

11.8 MB 84151c0ad8c8 <none>:<none>

11.8 MB 7d78bbcd48d8 registry.gitlab.com/codegazers/docker-rsyslogd:latest

11.8 MB 65170333d366 <none>:<none>

11.8 MB 446e862084d1 <none>:<none>

11.8 MB 374338fbb308 <none>:<none>

11.8 MB 3461e07635a6 <none>:<none>

11.8 MB 336af2d19317 <none>:<none>

11.8 MB 2e62ae545bc5 <none>:<none>

11.8 MB 2518213bc2fb <none>:<none>

11.8 MB 24c38e307571 <none>:<none>

11.8 MB 210ccac75c7b <none>:<none>

11.8 MB 2077826348da frjaraur/rsyslogd:latest

11.8 MB 1a5a377b8af5 <none>:<none>

11.8 MB 15a50d2bec69 <none>:<none>

11.8 MB 139bf4eb6d60 <none>:<none>

11.8 MB 0ae7e8156e89 <none>:<none>

11.8 MB 04a6529e280a <none>:<none>

11.8 MB 03f0b8f1af56 <none>:<none>

11.2 MB e17d883eeb8a frjaraur/simple-ucp-tools:latest

9.47 MB be44fd55e327 ehazlett/docker-demo:latest

6.88 MB cb810693e578 frjaraur/nginx-repo:<none>

6.88 MB 952f3301af4b nginx-repo:latest

6.88 MB 952f3301af4b frjaraur/nginx-repo:latest

4.8 MB baa5d63471ea hdp-alpine:latest

4.8 MB baa5d63471ea alpine:latest

4.64 GB f1f9584df435 hdp-core-rh:latest

3.98 MB a1a3cae7a75e alpine:edge

3.36 GB ca63920b7637 hdp-core:latest

3.25 GB 6dd602733a11 hdp-coressh:latest

2.54 GB b00de9443d43 hdp-client:latest

2.12 GB 80230b6f1c5c hdp-ambari-rh:latest

1.64 GB 4174039ee6c3 hdp-ambarissh:latest

1.63 GB 65014622b79e hdp-ambari:latest

1.23 GB 428ae47c75b2 gitlab/gitlab-ce:latest

1.11 MB 7968321274dc busybox:latest

1.06 GB 04fea0f73a5c training/docker-present:1.12-v3.0

1.02 GB 1cce2a78cef5 hdp-base-rh:latest

Llegamos hasta aquí con este breve repaso de las herramientas que nos proporciona Docker para poder gestionar y monitorizar la salud de nuestras aplicaciones dockerizadas. En siguientes posts iremos entrando con más detenimiento en cada una de ellas y veremos también las herramientas específicas del cluster swarm para mantener la integridad del mismo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.