Hoy prepararé la capacitación en contenedores, aprenderé los conocimientos relacionados con el motor acoplable y lo resumiré y registraré.
1. Motor acoplable
El motor Docker es el software central utilizado para ejecutar y administrar contenedores. Adopta el principio de diseño modular y realiza la creación y operación de contenedores bajo la cooperación de muchos componentes dedicados. La razón por la que presento esto es porque está estrechamente relacionado con el principio.
2. Arquitectura temprana del motor Docker
Cuando se lanzó Docker por primera vez, el motor de Docker constaba de dos componentes principales: LXC y el demonio de Docker.
Un demonio de Docker es un único archivo binario que incluye cosas como el cliente de Docker, la API de Docker, el tiempo de ejecución del contenedor, la creación de imágenes y más.
LXC brinda la capacidad de operar herramientas básicas como Namespace y CGroup, que son tecnologías de virtualización de contenedores basadas en el kernel de Linux.
La siguiente figura ilustra la interacción entre el demonio Docker, LXC y el sistema operativo en la versión anterior de Docker.
Las primeras arquitecturas tenían los siguientes problemas:
1. Dependencia de LXC. LXC está basado en Linux. Este es un problema para un proyecto que aspira a ser multiplataforma.
Tal componente central depende de herramientas externas, lo que traerá grandes riesgos para el proyecto e incluso afectará su desarrollo. Por lo tanto, la empresa Docker desarrolló una herramienta de desarrollo propio llamada Libcontainer para reemplazar a LXC. El objetivo de Libcontainer es ser una herramienta independiente de la plataforma que pueda proporcionar las funciones de interacción de contenedores necesarias para la capa superior de Docker en función de diferentes núcleos.
2. El demonio Docker está demasiado inflado. La naturaleza monolítica del demonio Docker creó más y más problemas con el tiempo. Difícil de cambiar, más y más lento de ejecutar. Consciente de estos problemas, la empresa Docker comenzó a trabajar arduamente para desmantelar este proceso daemon Docker grande y completo y modularizarlo.
3. La arquitectura actual del motor Docker
Ventajas significativas de este modelo:
Eliminar toda la lógica y el código para iniciar y administrar contenedores del daemon significa que el tiempo de ejecución del contenedor está desacoplado del daemon de Docker, a veces denominado "contenedor sin daemon", por lo que el mantenimiento y las actualizaciones del daemon de Docker no afectarán a los contenedores en ejecución. En el modelo anterior, toda la lógica de tiempo de ejecución del contenedor se implementa en el daemon, y al iniciar y detener el daemon, se eliminarán todos los contenedores en ejecución en el host. Este es un gran problema en un entorno de producción: ¡piense en la frecuencia con la que se lanzan nuevas versiones de Docker! Cada actualización de daemon matará todos los contenedores en el host, ¡lo cual es una lástima! Afortunadamente, esto ya no es un problema.
4. Descripción funcional de cada componente
| componentes | describir |
| /usr/bin/docker | El cliente docker está orientado directamente a los usuarios operativos; docker y dockerd se comunican a través de /var/run/docker.sock |
| /usr/bin/dockerd | dockerd es Docker Daemon, que es el proceso daemon de Docker; dockerd en sí mismo es en realidad la encapsulación de nivel superior de API para operaciones relacionadas con contenedores. Las funciones principales de daemon incluyen administración de imágenes, construcción de imágenes, API REST, autenticación, seguridad, núcleo red y orquestación; el archivo de socket entre dockerd y containerd es /run/containerd/containerd.sock |
| /usr/bin/contenedor | Lo que dockerd realmente llama es la interfaz API de containerd. containerd es un componente de comunicación intermedio entre dockerd y runc; el componente containerd garantiza que la imagen de Docker se pueda entregar a runc en el formato de paquete OCI correcto. |
| /usr/bin/containerd-shim | containerd-shim es un portador de correcciones de compatibilidad real de un contenedor en ejecución, y se iniciará un nuevo proceso docker-shim cada vez que se inicie un contenedor. Llama directamente a runc a través de los tres parámetros especificados: id del contenedor, directorio de límite (containerd corresponde al directorio generado por un determinado contenedor, generalmente ubicado en: /var/run/docker/libcontainerd/containerID), y ejecuta el binario (runc by por defecto).API para crear un contenedor (por ejemplo, para crear un contenedor: el comando de ensamblaje final es el siguiente: runc create); tiene las siguientes tres funciones: 1. Permitir que runc salga del archivo binario compilado por Go después de crear & ejecutando el contenedor El valor predeterminado es la vinculación estática , por lo tanto, si N contenedores están instalados en una máquina, entonces se ocupará M * N memoria, donde M es la memoria consumida por un runc. Sin embargo, por las razones descritas anteriormente, no quiero dejar que containerd sea directamente el proceso principal del contenedor, por lo tanto, necesito algo más pequeño que runc para que sea el proceso principal, es decir, shim. 2. El uso de shim como el proceso principal del contenedor en lugar de usar directamente containerd como el proceso principal del contenedor es para evitar esta situación: cuando containerd cuelga, shim todavía está allí, por lo que puede garantizar que el descriptor de archivo abierto por el contenedor no La función principal de shim que se apaga es desacoplar containerd del contenedor real (el proceso en él) 3. Confíe en shim para recopilar e informar el estado de salida del contenedor, de modo que containerd no sea necesario para esperar el proceso del niño |
| /usr/bin/containerd-shim-runc | RunC es el tiempo de ejecución para ejecutar contenedores. Crea y ejecuta contenedores de acuerdo con los estándares oci (Open Container Organization). Es responsable de ejecutar contenedores utilizando recursos como archivos que cumplen con los estándares, pero no incluye funciones de administración de imágenes como docker. Entonces, para ejecutar el contenedor con runC, primero debemos preparar el sistema de archivos del contenedor. El llamado paquete OCI se refiere al sistema de archivos del contenedor y un archivo config.json. Con el sistema de archivos del contenedor, podemos generar el archivo config.json a través del comando runc spec. Runc es esencialmente una herramienta interactiva de línea de comandos liviana empaquetada para Libcontainer |
| /usr/bin/docker-init | Todos sabemos que en el sistema UNIX, el proceso No. 1 es el proceso de inicio y el proceso principal de todos los procesos huérfanos. Al usar docker, si no se agrega el parámetro --init, el proceso n.º 1 en el contenedor es el PUNTO DE ENTRADA dado y, después de agregar --init, el proceso n.º 1 será tini. |
| /usr/bin/docker-proxy | Se utiliza para la asignación de puertos entre el contenedor y el host, y la capa inferior se realiza mediante iptables. Docker run -d -p 10010:10010 busybox sleep10000, el comando ps aux|grep docker puede ver las reglas. |
| estándar OCI | Tiempo de ejecución de contenedores, Tiempo de ejecución de contenedores se refiere a la herramienta para administrar y ejecutar contenedores. Hay muchas herramientas de contenedores actuales, como docker, rkt, etc., pero si cada herramienta de contenedor usa su propio tiempo de ejecución, no es propicio para el desarrollo del contenedor, por lo que algunos proveedores de contenedores han formulado conjuntamente el formato de imagen del contenedor y los estándares de tiempo de ejecución del contenedor, a saber, la Iniciativa OpenContainer (OCI). Docker participó en dos especificaciones relacionadas con contenedores que OCI se propuso definir: la especificación de imagen y la especificación de tiempo de ejecución del contenedor. |
| Paquete OCI | OCI Bundle hace referencia a una serie de archivos que cumplen con el estándar OCI. Estos archivos contienen todos los datos necesarios para ejecutar el contenedor. Se almacenan en un directorio común, que contiene los siguientes dos elementos: 1. config.json: contiene la configuración. del contenedor que ejecuta los datos; 2. Imagen del sistema de archivos del contenedor--Paquete OCI--runc--container |
5, referencia
https://jiajunhuang.com/articles/2018_12_24-docker_components_part2.md.html
http://c.biancheng.net/view/3137.html
http://eventos.jianshu.io/p/d08fb1f5de9d
https://www.jianshu.com/p/2e0e33dac632
https://zhuanlan.zhihu.com/p/59796137