Cómo monitorear la ejecución de PostgreSQL dentro de un contenedor Docker:primera parte

El monitoreo es la acción de observar y verificar durante un período de tiempo para ver cómo se desarrolla y funciona lo que se está monitoreando. Lo hace para que pueda realizar los cambios necesarios para asegurarse de que las cosas funcionen correctamente. Es esencial que los procesos sean monitoreados para producir buenos conocimientos sobre las actividades que se están realizando para planificar, organizar y ejecutar una solución eficiente.

Docker es un programa creado para operar como un constructor listo para responder a la pregunta "¿Se ejecutará el software en mi máquina?" Básicamente ensambla diferentes partes creando un modelo fácil de almacenar y transportar. El modelo, también conocido como contenedor, se puede enviar a cualquier computadora que tenga Docker instalado.

En este artículo, presentaremos Docker, describiendo algunas formas de configuración y comparándolas. Además, PostgreSQL entra en juego, y lo implementaremos dentro de un contenedor Docker de una manera inteligente y, finalmente, veremos los beneficios que puede proporcionar ClusterControl, para monitorear métricas clave sobre PostgreSQL y el sistema operativo fuera de él.

Descripción general de Docker

Cuando se inicia Docker, crea una nueva conexión de red para permitir la transmisión de datos entre dos puntos finales, llamada puente, y aquí es donde se guardan los nuevos contenedores de forma predeterminada.

A continuación, veremos detalles sobre este puente y discutiremos por qué no es una buena idea usarlo en producción.

$ docker network inspect bridge

Tenga en cuenta las opciones incrustadas, porque si ejecuta un contenedor sin especificar la red deseada, estará de acuerdo con él.

En esta conexión de red predeterminada, perdemos algunas buenas ventajas de las redes, como DNS. Imagina que quieres acceder a Google, ¿cuál dirección prefieres, www.google.com o 172.217.165.4?

No sé tú, pero yo prefiero la opción anterior y, para ser honesto, no escribo 'www.'.

Red puente definida por el usuario

Así que queremos DNS en nuestra conexión de red y el beneficio del aislamiento, porque imagine el escenario en el que implementa diferentes contenedores dentro de la misma red.

Cuando creamos un contenedor de Docker, podemos darle un nombre, o Docker lo crea para nosotros aleatorizando dos palabras conectadas por subrayado, o '_'.

Si no usamos una red de puente definida por el usuario, en el futuro podría haber un problema en el medio de las direcciones IP, porque claramente no somos máquinas, y recuerde que estos valores pueden ser difíciles y propensos a errores.

Crear un puente personalizado o una red de puente definida por el usuario es muy fácil.

Antes de crear el primero, para comprender mejor el proceso, abramos una nueva terminal, escribamos un comando de Linux del paquete iproute2 y olvidémonos de él por ahora.

$ ip monitor all

Este terminal ahora escuchará la actividad de la red y se mostrará allí.

Es posible que haya visto comandos como "ifconfig" o "netstat" antes, y le digo que están en desuso desde 2001. El paquete net-tools todavía se usa mucho, pero ya no se actualiza.

Ahora es el momento de crear nuestra primera red personalizada, así que abre otra terminal e ingresa:

$ docker network create --driver bridge br-db

Esta mezcla muy larga de letras y números se llama UUID, o Universally Unique IDentifier. Básicamente está diciendo que la red se ha creado con éxito.

El nombre dado para nuestra primera red creada manualmente ha sido “br-db”, y debe estar al final del comando, pero antes de eso, tenemos el argumento '“-driver”, y luego el valor “bridge” , ¿por qué?

En Community Edition, Docker proporciona tres controladores diferentes disponibles:puente, host y ninguno. En el momento de la creación, así, el valor predeterminado es el puente y no es necesario especificarlo, pero estamos aprendiendo al respecto.

Si has hecho todo conmigo, mira el otro terminal porque te explico lo que está pasando.

Docker ha creado la red, llamada "br-db", pero solo él la llama así.

Al otro lado de este puente personalizado creado, hay otra capa, el sistema operativo. El nombre dado para la misma red de puente ha cambiado y se convierte en una representación de la nomenclatura para puente, "br", seguido de los primeros 12 caracteres del valor UUID anterior, en rojo.

Con nuestra nueva conexión de red, tenemos una subred, una puerta de enlace y una transmisión.

La puerta de enlace, como sugiere el nombre, es donde ocurre todo el tráfico de paquetes entre los puntos finales del puente, y se llama "inet" para el sistema operativo, como puede ver.

Broadcast se encuentra en la última dirección IP y es responsable de enviar el mismo tráfico de datos para todas las direcciones IP en la subred cuando sea necesario.

Siempre están presentes en las conexiones de red, y es por eso que tenemos al principio de la salida, el valor “[ADDR]”. Este valor representa cambios en la dirección IP y es como un evento que se dispara para monitorear la actividad de la red, ¡porque hemos creado una nueva conexión de red!

Contenedor Docker

Visite Docker Hub y vea que lo que hay allí se conoce como Docker Image, y es básicamente el esqueleto del contenedor (modelo).

Las imágenes de Docker son generadas por Dockerfiles y contienen toda la información necesaria para crear un contenedor, a fin de que sea fácil de mantener y personalizar.

Si observa con atención el Docker Hub, es fácil ver que la imagen de PostgreSQL, llamada postgres, tiene diferentes etiquetas y versiones, y si no especifica una de ellas, se usará la predeterminada, la última, pero tal vez en en el futuro, si necesita diferentes contenedores de PostgreSQL trabajando juntos, es posible que desee que estén en la misma versión.

Vamos a crear nuestro primer contenedor correcto ahora, recuerde la necesidad del argumento '--network', o se implementará en el puente predeterminado.

$ docker container run --name postgres-1 --network br-db -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6551:5432 -d postgres

Nuevamente el UUID, éxito, y en la otra terminal, ¿qué está pasando?

Los cambios en la interfaz de red son el evento que está ocurriendo en este momento, o simplemente “[ENLACE]”. Puede olvidar cualquier cosa después de "veth", créame, el valor siempre cambia cuando se reinicia el contenedor o sucede algo similar.

La otra opción “-e POSTGRES_PASSWORD=?” significa Entorno, y solo está disponible cuando se ejecutan contenedores PostgreSQL, está configurando la contraseña para la cuenta de superusuario en la base de datos, llamada postgres.

Publish es el nombre largo del parámetro "-p 6551:5432", y básicamente hace que el puerto 6551 del sistema operativo se enlace bidireccionalmente al puerto 5432 del contenedor.

Por último, pero no menos importante, está la opción Separar, “-d”, y lo que hace es que el contenedor se ejecute independientemente de esta terminal.

El nombre de la Imagen Docker debe estar al final, siguiendo el mismo patrón de creación de la red, teniendo todos los argumentos y opciones a la izquierda, y al final lo más importante, en este caso, el nombre de la imagen.

Recuerde que los contenedores se mantienen en la subred de la red, parados sobre las direcciones IP permitidas para cada uno de ellos, y nunca estarán en la primera ni en la última dirección, porque el Gateway y el Broadcast estarán siempre ahí.

Hemos mostrado los detalles del puente creado, y ahora serán mostrados por cada uno de los endpoints estos detalles guardados por ellos.

$ docker network inspect br-db

$ brctl show

Como puede ver, los nombres de la red y del contenedor difieren, siendo el segundo reconocido como una interfaz por el sistema operativo, llamado "veth768ff71", y el nombre original dado por nosotros "postgres-1" para Docker.

En el comando Docker es posible anotar la dirección IP del contenedor creado anteriormente, la subred que coincide con lo que apareció en el otro terminal abierto hace unos momentos y, por último, las opciones vacías para esta red personalizada.

El comando de Linux “brctl show” es parte del paquete bridge-utils y, como sugiere el nombre, su propósito es proporcionar un conjunto de herramientas para configurar y administrar puentes Ethernet de Linux.

Otra red puente personalizada

Hablaremos sobre el DNS pronto, pero ha sido muy bueno para simplificarnos las cosas en el futuro. Las grandes configuraciones tienden a facilitar la vida del DBA en el futuro.

Con las redes es lo mismo, por lo que podemos cambiar la forma en que el sistema operativo reconoce la subred, la dirección y el nombre de la red agregando más argumentos en el momento de la creación.

$ docker network create --driver bridge --subnet 172.23.0.0/16 -o “com.docker.network.bridge.name”=”bridge-host” bridge-docker

$ ip route show

Con este comando de Linux, podemos ver casi lo mismo que el otro comando anterior, pero ahora en lugar de enumerar las interfaces "veth" para cada red, simplemente tenemos este "linkdown" que muestra las que están vacías.

La dirección de subred deseada se ha especificado como argumento y, de forma similar a la opción Entorno para la creación del contenedor, para la red tenemos la “-o” seguida del par de clave y valor. En este caso, le estamos diciendo a Docker que le diga al sistema operativo que debe llamar a la red como "host-puente".

La existencia de esas tres redes también se puede verificar en Docker, solo ingrese:

$ docker network ls

Ahora, hemos discutido anteriormente que los valores de estos "veth" para los contenedores no importan, y se los mostraré en la práctica.

El ejercicio consiste en verificar el valor actual, luego reiniciar el contenedor, luego verificar nuevamente. Para hacerlo, necesitaremos una combinación de los comandos de Linux utilizados anteriormente y los de Docker, que son nuevos aquí pero muy simples:

$ brctl show
$ docker container stop postgres-1
$ docker container start postgres-1
$ brctl show

Cuando se detiene el contenedor, la dirección IP debe liberarse para recibir una nueva si es necesario, y eso es un recordatorio de lo importante que puede ser el DNS.

El sistema operativo asigna estos nombres a las interfaces cada vez que un contenedor se encuentra en una dirección IP y se generan utilizando el paquete iptables, que pronto será reemplazado por el nuevo marco denominado nftables.

No se recomienda cambiar estas reglas, pero existen herramientas disponibles para ayudar con su visualización, si es necesario, como dockerveth.

Política de reinicio de contenedores

Cuando reiniciamos el programa Docker, o incluso la computadora, las redes creadas por él se mantienen en el sistema operativo, pero vacías.

Los contenedores tienen lo que se denomina Política de reinicio del contenedor, y este es otro argumento muy importante que se especifica en el momento de la creación. PostgreSQL, como base de datos de producción, su disponibilidad es crucial, y así es como Docker puede ayudar.

$ docker container run --name postgres-2 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6552:5432 -d postgres

A menos que lo detenga manualmente, este contenedor "postgres-2" estará siempre disponible.

Para entenderlo mejor, se mostrarán los contenedores en ejecución y se reiniciará el programa Docker, luego el primer paso nuevamente:

$ docker container ls
$ systemctl restart docker
$ docker container ls

Solo se está ejecutando el contenedor "postgres-2", el otro contenedor "postgres-1" no se inicia solo. Se puede ver más información al respecto en la Documentación de Docker.

Sistema de nombres de dominio (DNS)

Un beneficio de User-Defined Bridge Network es la organización, sin duda, porque podemos crear tantos como queramos para ejecutar contenedores nuevos e incluso conectar los antiguos, pero otro beneficio que no tenemos usando el puente predeterminado de Docker es DNS.

Cuando los contenedores necesitan comunicarse entre sí, puede ser doloroso para el DBA memorizar las direcciones IP, y lo hemos discutido anteriormente mostrando el ejemplo de www.google.com y 172.217.165.4. El DNS resuelve este problema a la perfección, haciendo posible interactuar con los contenedores utilizando los nombres que les proporcionamos en el momento de la creación, como "postgres-2", en lugar de la dirección IP "172.23.0.2".

Vamos a ver cómo funciona. Crearemos otro contenedor solo para fines de demostración en la misma red llamado “postgres-3”, luego instalaremos el paquete iputils-ping para transmitir paquetes de datos al contenedor “postgres-2”, usando su nombre por supuesto .

$ docker container run --name postgres-3 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6553:5432 -d postgres
$ docker container exec -it postgres-3 bash

Para una mejor comprensión, separémoslo en partes, en las siguientes salidas, la flecha azul indicará cuándo se ejecuta el comando dentro de un contenedor y en rojo, en el sistema operativo.

$ apt-get update && apt-get install -y iputils-ping

$ ping postgres-2

Resumen

PostgreSQL se ejecuta dentro de Docker y su disponibilidad ya está garantizada. Cuando se usan dentro de una red de puente definida por el usuario, los contenedores se pueden administrar más fácilmente con muchos beneficios, como DNS, direcciones de subred personalizadas y nombres de SO para las redes.

Hemos visto detalles sobre Docker y la importancia de conocer los paquetes y marcos actualizados en el sistema operativo.