‫El comando Docker Health Check. Fue una nueva característica agregada en 1. 12, que salió a mediados de 2016, al
‫mismo tiempo que Swarm Kit y Swarm Mode estaban disponibles en Docker. Se agregó realmente como parte de ese conjunto
‫de herramientas, pero todavía funciona en todos los archivos diferentes como Dockerfile, Compose, Docker Run, y
‫Stack lo admite, la actualización del servicio y Service Create lo soportan.
‫.
‫Está en todas partes.
‫Recomiendo encarecidamente que cuando vaya a la producción, participe en las opciones de prueba para este comando de
‫comprobación de estado.
‫Va a funcionar nada más sacarlo de la caja con un ejecutivo.
‫Va a ejecutar ese comando dentro del contenedor como si estuviera ejecutando su propio comando
‫de ejecución.
‫Por lo tanto, no lo ejecuta desde fuera del contenedor; solo lo está ejecutando dentro, lo
‫que significa que incluso los trabajadores simples que no tienen puertos expuestos, puede ejecutar un comando simple en ellos para
‫validar si están devolviendo datos correctos o lo que sea.
‫Es una ejecución simple de un comando, lo que significa que obtiene un retorno simple. Espera un 0 o un 1.
‫En Linux y Windows, tiene códigos de salida de comandos y un 0 es algo bueno.
‫Significa que todo estuvo bien.
‫Cualquier cosa que no sea un 0 va a ser un error en la mayoría de las aplicaciones.
‫Pero en Docker, necesitamos esa aplicación para salir de un 1 específicamente. Mostraremos en un minuto cómo
‫lo haces.
‫Solo hay tres estados para un chequeo de salud en Docker. Comienza con comenzar. El inicio es en los primeros 30
‫segundos, por defecto, donde todavía no se ha ejecutado un comando de revisión de estado.
‫Entonces se ejecutará uno.
‫Si eso devuelve un 0, comenzará con el saludable. Cambiará a la opción saludable.
‫Tomará ese comando y lo ejecutará cada 30 segundos por defecto nuevamente. Si alguna vez recibe un retorno no saludable,
‫como una salida 1, entonces lo marca como un contenedor insalubre.
‫Tenemos opciones para controlar todo esto, incluidos los reintentos.
‫Veremos eso en un minuto.
‫Esta es una opción mucho mejor que la que hemos tenido en el pasado porque Docker, hasta ahora, solo se aseguraba
‫de que la aplicación todavía se estuviera ejecutando.
‫No tenía ninguna idea de si esa aplicación estaba haciendo lo que se suponía que debía hacer.
‫Ahora podemos hacer eso dentro del contenedor Docker.
‫Pero esto no es un reemplazo para su solución de monitoreo de terceros.
‫Esto no le proporcionará gráficos, o estado a lo largo del tiempo, ni ningún tipo de herramienta de terceros que pueda
‫esperar de una solución de monitoreo.
‫Esto se trata de que Docker comprenda si el contenedor en sí tiene un nivel básico de salud.
‫Por lo tanto, en un Nginx, podría devolver un host local del archivo de índice raíz. Un retorno de 200 o 300 está bien y le da un
‫código de salida de 0, y lo considera saludable.
‫Esa no es una herramienta de monitoreo súper avanzada uh, ya sabes.
‫devolviera un error 404 o 500, entonces lo consideraría insalubre y podemos hacer algo al respecto.
‫Pero si
‫¿Dónde vamos a ver este Doche Healthcheck en la GUI?
‫El primer lugar está en el contenedor ls.
‫Simplemente lo verá como esta nueva opción.
‫Está en el medio. Veremos en un segundo dónde nos mostrará uno de los tres estados si el chequeo
‫de salud se está ejecutando, y así es como realmente sabemos que hay un chequeo de salud.
‫Esa es la forma más fácil, al menos, de saber. Veremos el historial, los últimos cinco de ese
‫chequeo de salud, aparecer en la inspección de ese contenedor. Y podemos ver una tendencia básica en el tiempo allí.
‫Pero el comando docker run no toma medidas en un contenedor insalubre.
‫Una vez que el chequeo de salud considera que un contenedor no es saludable, la ejecución del acoplador solo lo indicará en el
‫comando ls, y en la inspección, pero no va a tomar medidas.
‫Ahí es donde esperamos que Swarm Services tome medidas.
‫Entonces, las pilas y los servicios realmente reemplazarán ese contenedor con una nueva tarea, posiblemente en un nuevo
‫host, dependiendo del planificador.
‫comando de actualización, vemos un pequeño bono adicional al utilizar los cheques de salud porque las actualizaciones considerarán el
‫chequeo de salud como parte de la preparación para ese contenedor antes de que se ejecute y cambia el siguiente.
‫Incluso en el
‫Si aparece un contenedor, pero no pasa su verificación de estado, la actualización del
‫servicio no pasará al siguiente. O tomará medidas en función de los cambios que le dé.
‫Veamos algunos ejemplos antes de ir a la línea de comando.
‫Esta es una que estamos usando en la ejecución del acoplador.
‫Esto nos permite usar una imagen existente que no tiene un control de estado y estamos agregando la verificación
‫de estado en el tiempo de ejecución.
‫En este caso, estamos usando la imagen de Elasticsearch. del contenedor, no el puerto publicado, sino dentro del contenedor.
‫Puede ver que el comando es un cURL localhost 9200, que es el puerto en el que se
‫está ejecutando Elasticsearch dentro Para Elasticsearch, hay
‫una URL de salud real.
‫Entonces, podemos usar eso aquí.
‫Notarás las dos tuberías con el falso al final de ese comando.
‫Y eso va a ser
‫bastante común si se usa algo como cURL u otra herramienta que envíe un código de error que no sea 1.
‫¿Recuerdas cuando mencioné eso hace un tiempo? Necesitamos que salga con 1 si hay un problema. que Docker hará algo al respecto.
‫Porque ese es el único código de error con el
‫Necesitamos asegurarnos de que en este caso, un intérprete de comandos siempre devolverá el código de salida falso 1 si
‫hay algo que salga de ese comando que no sea 0.
‫Es una buena forma de evitar ese problema.
‫Simplemente sucede con cURL, cURL dará otros códigos de error potenciales y no queremos que
‫haga eso.
‫En los archivos Docker reales, podemos agregar el mismo comando. El formato es un poco diferente. Pero ves que
‫tenemos estas opciones aquí. Tenemos el intervalo, el tiempo de espera, el período de inicio (que es nuevo) y los reintentos.
‫El intervalo es lo que crees que es. Es, por defecto, cada 30 segundos.
‫Con qué frecuencia ejecutará este control de salud. El tiempo de espera es cuánto tiempo esperará antes de que se
‫extravíe y devuelva un código incorrecto, si es que la aplicación es lenta. El período de inicio es una nueva característica el intervalo de tiempo antes de que comenzara
‫que nos permite ahora en 17. 09 y más reciente, para dar un período de espera más largo que los primeros 30 segundos de la duración. Antes, siempre esperaría por Pero tal vez tengas una aplicación Java, o una base de datos, o algo que demore mucho más en comenzar.
‫mucho tiempo. el chequeo de salud. Tal vez tome cinco minutos.
‫Podría agregar ese período de inicio allí. Todavía hará chequeos de salud. Pero lo que hará es no alarmarse en un cheque no saludable hasta
‫que ese tiempo haya transcurrido.
‫vez que haya pasado esa marca de dos minutos.
‫Entonces, si establece dos minutos allí, a pesar de que se trata de revisar la salud cada 30 segundos, solo lo considerará no saludable una El último, reintentos, significa que intentaremos este chequeo de
‫salud x número de veces antes de considerarlo no saludable.
‫Eso le da a una aplicación potencialmente inestable la posibilidad de
‫volver con una persona sana y recuperarse por sí misma antes de que consideremos que se trata de un contenedor realmente insalubre.
‫El comando básico healthcheck que usaría en un archivo Docker se
‫llama HEALTHCHECK, todas las letras mayúsculas allí. El mismo formato existe donde si solo estamos haciendo un simple CURRICULUM del
‫localhost porque tal vez es una aplicación PHP o algo así. Podemos hacerlo.
‫un archivo Docker para ver cómo agrego el intervalo de tiempo de espera y los reintentos antes del comando mismo.
‫Esta es la forma en que agregaría todas esas opciones a
‫El primero allí para el comando básico, note que no tengo que
‫poner un CMD si solo le estoy dando el comando para ejecutar. Pero si quiero mostrar las opciones, si quiero darle opciones personalizadas de fábrica
‫con el tiempo de espera y así sucesivamente, entonces debo especificar cuál es el comando.
‫Ahora estas no son dos líneas diferentes.
‫Observe la barra invertida al final de la primera línea allí.
‫Entonces no te confundas
‫cómo sería si tuviera una aplicación estática ejecutándose dentro de un servidor Nginx.
‫Aquí tenemos un ejemplo simple de
‫Podrías configurar el intervalo y el tiempo de espera de tu archivo Docker, y simplemente harías que simplemente hiciera un comando
‫CURL en el servidor local.
‫Si devuelve 200 o 300, considera que está bien. Si devuelve un 4, o 5, o algo más,
‫considera que es un error.
‫Usted nota aquí que tengo una salida 1, que es lo mismo que una falsa.
‫Lo hice solo para mostrarte que ciertos ejemplos en Internet tendrán un mensaje falso. Ciertos
‫ejemplos tendrán una salida 1.
‫Ambos hacen la misma cosa.
‫Aquí hay un ejemplo un poco más avanzado.
‫En este caso, estamos usando una aplicación PHP que se combina con Nginx.
‫Lo que he hecho es que, en los recursos, encontrarás un enlace a este ejemplo de PHP. He agregado un archivo de configuración de
‫Nginx personalizado que usa las URL de estado de Nginx y PHP-FPM.
‫Ambas aplicaciones tienen su propia página de estado y una especie de URL de comprobación de salud.
‫Puede usarlos en sus aplicaciones si usa PHP o Nginx. Hay dos URL diferentes, pero puede
‫usarlas en el mismo chequeo de salud.
‫En este caso, estamos usando solo uno de
‫ellos, y estamos lanzando el localhost / ping, que
‫en realidad es un comando de estado de PHP-FPM, pero debe habilitarlo dentro de su PHP-FPM. Una vez más, en los recursos de esta conferencia, hay un enlace a un
‫PHP Docker Good Defaults.
‫Puedes ver eso en un GitHub donde he mostrado en este ejemplo con un poco más de detalle.
‫A continuación tenemos un ejemplo de Postgres, así que en Dockerfile puedo usar una URL diferente.
‫Aquí tenemos una aplicación Postgres donde en el comando healthcheck, estoy usando un comando de pg listo.
‫Ahora, con diferentes aplicaciones, hay diferentes herramientas. simple de una conexión a un servidor de Postgres.
‫Con Postgres, viene con una herramienta integrada, que es una prueba muy
‫No valida que tenga buenos datos o que su base de datos esté montada correctamente. Simplemente va a decir: '¿Este
‫servidor de base de datos permite conexiones? ¿Si o no? 'Esa es una buena idea que puedes
‫hacer de la caja.
‫Así es como se vería en un archivo de compositor / pila.
‫Muy similar.
‫Notarás que el período de inicio requiere una versión diferente.
‫Dado que el comando healthcheck salió en 1. 12, en realidad fue compatible con 2. Compose.
‫1 de este archivo
‫Pero, si va a utilizar el período de inicio, eso significa que debe actualizar su archivo
‫Compose a la versión 3. 4 para apoyar eso. Porque el
‫período de inicio salió más de un año después de que lo hiciera el comando de comprobación de salud.
‫Comencemos con algunos comandos de ejecución simples.
‫Lo que vamos a hacer aquí es que vamos a iniciar un servidor de base de
‫datos Postgres sin el chequeo de salud porque, de manera predeterminada, no viene con uno.
‫de revisión manual de salud que se agregará en la línea de comando, y veremos la diferencia.
‫Luego, lo ejecutaremos nuevamente con un comando
‫Aquí, vamos a llamar al primero p1. Lo ejecutaremos separado de
‫la imagen oficial de Postgres.
‫Si hago un contenedor docker ls, verás que no hay nada que indique un chequeo de salud aquí.
‫Si hacemos ese mismo comando nuevamente, y lo llamamos p2 esta vez, vamos a agregar un comando de estado.
‫Esta vez, vamos a usar la pg isready, de la
‫que hablamos antes, para probar que las conexiones están disponibles en este servidor de Postgres. Vamos a decirle que el usuario que necesitamos es
‫el usuario de Postgres. En realidad no necesitamos darle una contraseña. a intentar iniciar sesión.
‫No va Solo va a tratar de validar. Usaremos la imagen de Postgres.
‫Ahora, si hacemos un contenedor docker ls, y lo alejo
‫un poco, verán que dice: "Comienza la salud de 4 segundos. 'Ahora obtenemos
‫esta característica adicional en nuestro estado de nuestro comando ls. Permanecerá en el estado inicial durante los 30 segundos predeterminados hasta que ejecute
‫el
‫comando healthcheck por primera vez.
‫Ahora que hemos esperado más de 30 segundos, verá que ha cambiado al estado de saludable.
‫tenemos esta nueva opción de estado de salud.
‫Si hacemos un contenedor docker inspeccionando esa p2, veremos en la parte superior de eso que En este caso, solo he podido ejecutarlo dos veces.
‫Puede ver el resultado allí, que muestra que está aceptando conexiones.
‫Todo bien. Hagamos algunos servicios para crear comandos a esa misma base de datos, en esa misma prueba de chequeo de salud.
‫Lo que veremos aquí cuando hagamos esto es que hay tres estados diferentes por
‫los que pasa un servicio al iniciarse.
‫Se está preparando, lo que generalmente significa que está descargando la imagen. Está comenzando, lo que significa que está ejecutando el contenedor y lo
‫está sacando. Entonces se está ejecutando.
‫Sin el comando healthcheck, el inicio y la ejecución son muy rápidos. Son casi instantáneos.
‫Veremos que aquí con un servicio de acoplador creamos el nombre p1 postgres.
‫Una vez que haya terminado la preparación al
‫descargar la imagen, verá que va inmediatamente desde el inicio hasta la ejecución, porque no hay una revisión de salud. No tiene nada más que hacer que no
‫sea iniciar el contenedor y decir, 'Sí. El binario se está ejecutando. 'Pero si hacemos ese mismo comando, crearemos servicio docker, lo llamaremos p2 como
‫antes y le daremos el mismo comando
‫de mantenimiento.
‫Comenzamos este servicio con el comando healthcheck integrado.
‫el primer chequeo de salud.
‫Lo que veremos es que pasará de la preparación al inicio y se situará en el estado inicial durante los 30 segundos predeterminados hasta que se ejecute
‫Este es ahora el servicio Docker que espera un estado saludable antes de
‫considerar que este servicio se está ejecutando por completo. Después de que hayan transcurrido los 30 segundos, pasará al estado de funcionamiento. Luego obtenemos la última pequeña verificación allí,
‫solo para asegurarnos de que se considera estable, y luego terminamos.
‫Ya puede ver, de fábrica, que con los servicios, así como las
‫actualizaciones de los servicios, obtendremos esta bonificación extra del concepto de salud si usamos estos comandos siempre que podamos.
‫