Esta es la publicación tres en Docker que sigue a Docker: aplicaciones de administración y contenedores (2). Si está buscando una administración más generalizada de[alert-announce]$ docker daemon[/alert-announce] y ejemplos básicos de uso de la CLI de Docker Engine, es posible que desee leer esa publicación.
1 – Administración del demonio Docker
El demonio de Docker es el servicio en segundo plano que maneja los contenedores en ejecución y todos sus estados.
1 – Administración de Docker Daemon2 – Automatización de contenedores de Process Manager3 – Redes de Docker4 – Creación de redes de Docker5 – Conexión de contenedores a redes6 – Comandos de red misceláneos
El inicio y la detención del demonio Docker a menudo se configura a través de un administrador de procesos como systemd o Upstart. En un entorno de producción, esto es muy útil ya que tiene mucho control personalizable sobre el comportamiento del daemon. Se puede ejecutar directamente desde la línea de comandos, aunque en lugar de esto: Escucha en el socket de Unix: unix:///var/run/docker.sock cuando está activo y en ejecución. Si está ejecutando el demonio docker directamente de esta manera, puede agregar opciones de configuración al comando. Un ejemplo de ejecución del daemon de docker con opciones de configuración es el siguiente:
-D –debug=false : activa o desactiva el modo de depuración. –tls=false: activa o desactiva TLS. –tlscert= – ubicación del certificado. tlskey= - ubicación clave. -H –host=[] – Conector(es) de daemon a los que conectarse.
Se ofrecen más opciones para el demonio Docker en el enlace antes del último bloque de código.
Advenedizo
El trabajo predeterminado de Docker Daemon Upstart se encuentra en /etc/init/docker.conf . Para comprobar el estado del daemon: Para iniciar el demonio Docker: Detenga el demonio Docker: O reinicie el demonio: Los registros de los trabajos de Upstart se encuentran en /var/log/upstart y se comprimen cuando el daemon no se está ejecutando. Así que ejecute el daemon/container para leer el archivo de registro activo: docker.log a través de:
sistemad
Los archivos de unidades predeterminados se almacenan en los subdirectorios /usr/lib/systemd y /lib/systemd/system . Los archivos de unidad personalizados creados por el usuario se guardan en /etc/systemd/system . Para comprobar el estado del daemon: Para iniciar el demonio Docker: Detenga el demonio Docker: O reinicie el demonio: Para asegurarse de que el demonio Docker se inicie en el arranque: Los registros de Docker se ven en systemd con: Una mirada más profunda a systemd y Docker se mantiene aquí en los documentos de Docker: Consulte la documentación de Docker – systemd
2 – Automatización de contenedores del administrador de procesos
Las políticas de reinicio son un mecanismo de Docker incorporado para reiniciar los contenedores automáticamente cuando salen. Estos deben establecerse manualmente con el indicador – –restart=“yes” y también se activan cuando se inicia el demonio Docker (como después de reiniciar el sistema). Las políticas de reinicio también inician los contenedores vinculados en el orden correcto. Si tiene procesos que no son de Docker que dependen de los contenedores de Docker, puede usar un administrador de procesos como upstart, systemd o supervisor en lugar de estas políticas de reinicio para reemplazar esta funcionalidad. Esto es lo que cubriremos en este paso. Para estos ejemplos, suponga que los contenedores para cada uno ya se han creado y ejecutan Ghost con el nombre –name=ghost-container .
Advenedizo
Docker adjunta automáticamente el administrador de procesos al contenedor en ejecución o lo inicia si es necesario con esta configuración. Todas las señales de Docker también se reenvían para que el administrador de procesos pueda detectar cuándo se detiene un contenedor y reiniciarlo correctamente. Si necesita pasar opciones a los contenedores (como –env), deberá usar docker run en lugar de docker start en la configuración del trabajo. Esto difiere ya que crea un nuevo contenedor utilizando la imagen fantasma cada vez que se inicia el servicio y tiene en cuenta las opciones adicionales.
sistemad
Docker adjunta automáticamente el administrador de procesos al contenedor en ejecución o lo inicia si es necesario con esta configuración. Todas las señales de Docker también se reenvían para que el administrador de procesos pueda detectar cuándo se detiene un contenedor y reiniciarlo correctamente. Si necesita pasar opciones a los contenedores (como –env), deberá usar docker run en lugar de docker start en la configuración del trabajo. Esto difiere ya que crea un nuevo contenedor con las opciones adicionales cada vez que se inicia el servicio, que se detiene y se elimina cuando finaliza el servicio de Docker.
3 – Redes acoplables
Los controladores de red permiten que los contenedores se vinculen entre sí y se conecten en red. Docker viene con dos controladores de red predeterminados como parte de la instalación normal:
El conductor del puente. El controlador superpuesto.
Estos dos controladores se pueden reemplazar con otros controladores de terceros que funcionan de manera más óptima en diferentes situaciones. Pero para los usos básicos de Docker de gama baja, estos valores predeterminados dados están bien. Docker también incluye automáticamente tres redes predeterminadas con la instalación base: La red denominada puente está clasificada como una red especial. Docker lanza todos y cada uno de los contenedores en esta red (a menos que se indique lo contrario). Por lo tanto, si actualmente tiene contenedores en ejecución, estos se habrán colocado en el grupo de red puente. Las redes se pueden inspeccionar con el siguiente comando, donde puente es el nombre de la red que se inspeccionará: El resultado muestra todas y cada una de las directivas configuradas para la red: Esta inspección cambia la salida a medida que se modifica y configura una red; cómo hacerlo se explica en pasos posteriores.
4 – Creación de redes Docker
Las redes son formas naturales de aislar contenedores de otros contenedores u otras redes. Sin embargo, no se debe confiar únicamente en las redes predeterminadas originales. Es mejor crear sus propios grupos de red. Recuerde que hay dos controladores predeterminados y, por lo tanto, dos tipos de redes nativas; puente y superposición. Las redes puente solo pueden hacer uso de un único host para ejecutar el software Docker Engine. Una red superpuesta difiere en que puede incorporar múltiples hosts para ejecutar el software Docker. Para hacer la red de tipo “puente” más simple, usamos la opción crear : Con este último comando la opción -d (controlador) y puente especifica el tipo de red que queremos crear. Con un nuevo nombre para la red al final del comando. Para ver la nueva red después de la creación: Se muestra en la última línea: Las redes superpuestas son un tema mucho más amplio debido a la inclusión de múltiples hosts, por lo que no se tratan en esta publicación, pero los principios básicos y dónde comenzar se mencionan en el siguiente enlace: Consulte la documentación de Docker: cómo trabajar con comandos de red.
5 – Conectando Contenedores a Redes
La creación y el uso de estas redes permite que las aplicaciones de contenedores funcionen al unísono y con la mayor seguridad posible. Los contenedores dentro de las redes solo pueden interactuar con sus contrapartes y están aislados del exterior de la red. Similar a la segregación de VLAN dentro de una red basada en IP. Por lo general, los contenedores se agregan a una red cuando inicia y ejecuta el contenedor por primera vez. Seguiremos el ejemplo de la Documentación de Docker que usa un contenedor de base de datos de PostgreSQL y la aplicación web de Python para demostrar una configuración de red simple. Primero, inicie un contenedor que ejecute la imagen de entrenamiento de la base de datos PostgreSQL y, en el proceso, agréguelo a su red puente personalizada del paso anterior. Para hacer esto, debemos pasar el indicador –net= al nuevo contenedor y proporcionarle el nombre de nuestra red puente personalizada. Que en mi ejemplo anterior fue test-bridge-network : Puede inspeccionar este contenedor db acertadamente llamado para ver dónde está exactamente conectado: Esto nos muestra los detalles de la red para la conexión test-bridge-network del contenedor de la base de datos: A continuación, ejecute la aplicación web de entrenamiento de Python en modo daemonizado sin opciones adicionales: Inspeccione la conexión de red del contenedor python-webapp de la misma manera que antes: Como era de esperar, este nuevo contenedor se ejecuta en la red de puente predeterminada, que se muestra en el resultado del último comando: Docker nos permite conectar un contenedor a tantas redes como queramos. Más importante para nosotros, también podemos conectar un contenedor que ya se está ejecutando a una red. Adjunte el contenedor python-webapp en ejecución a la “red de puente de prueba” como necesitamos: Para probar las conexiones del contenedor a nuestra red personalizada, podemos hacer ping de uno a otro. Obtenga la dirección IP del contenedor db : En mi caso esto fue: Ahora tenemos la dirección IP abierta en un shell interactivo en el contenedor python-webapp : Intente hacer ping al contenedor db con la dirección IP anterior, sustituyendo 172.18.0.2 por su dirección equivalente: Siempre que haya conectado con éxito ambos contenedores anteriormente, el comando ping tendrá éxito: Convenientemente, los nombres de los contenedores también funcionan en lugar de una dirección IP en este escenario: Presione CTRL + D para salir del mensaje del contenedor, o escriba salir en su lugar. Y con eso tenemos dos contenedores en la misma red creada por el usuario que pueden comunicarse entre sí y compartir datos. Que es lo que estaríamos buscando en el caso de la base de datos PostgreSQL y la aplicación web Python. Hay más formas de compartir datos entre contenedores una vez que están conectados a través de una red, pero estas se tratan en la próxima publicación de la serie.
6 – Comandos de red misceláneos
Aquí hay algunos comandos complementarios en relación con lo que ya se ha cubierto en esta publicación. En algún momento, es probable que necesite eliminar un contenedor de su red. Esto se hace usando el comando de desconexión: Aquí test-bridge-network es el nombre de la red, seguido del contenedor que desea eliminar de ella. Cuando todos los contenedores de una red están detenidos o desconectados, puede eliminar las redes por completo con: Lo que significa que test-bridge-network ahora se elimina y no aparece en la lista de redes existentes: El resultado aquí se obtiene del comando docker network ls . La creación de redes en Docker comienza aquí con estos ejemplos, pero va mucho más allá de lo que hemos cubierto. Los volúmenes de datos, los contenedores de datos y los volúmenes de host de montaje se describen en la próxima publicación de Docker cuando se publique.
