Esta es la arquitectura Docker: No puedo entender por qué uno necesita el demonio docker. El cliente es lo suficientemente bueno. El cliente simplemente accede al daemon usando un socket Unix. Puede usar TCP, pero lo que noto es que, por lo general, el cliente y el demonio están en la misma máquina. Entonces, ¿por qué dos entidades separadas?
Como se mencionó anteriormente, el cliente puede usar TCP para comunicarse con el demonio. Entonces, ¿cuál es la forma preferida de trabajar en equipo? ¿Un demonio para todo el equipo en un servidor separado con cada desarrollador ejecutando un cliente? O cada desarrollador tiene su propio proceso daemon.
El cliente Docker solo proporciona cli, es solo un envoltorio http api, como aws cli.
Docker daemon es el cerebro detrás de toda la operación, como aws mismo. Cuando usa el comando docker run
para iniciar un contenedor, su cliente docker traducirá ese comando en una llamada de API http, lo enviará al demonio docker, el demonio Docker luego evalúa la solicitud, habla con el sistema operativo subyacente y aprovisiona su contenedor.
Tenga en cuenta que docker cli puede conectarse a un demonio docker remoto, y puede configurar su demonio docker para usar tcp IP.
P en mi mente era, ¿cuál es la forma preferida de trabajar en equipo? ¿Un demonio para todo el equipo en un servidor separado con cada desarrollador ejecutando un cliente? O cada desarrollador tiene su propio demonio.
Esto depende de usted, pero la mayoría de las veces los desarrolladores tienen un demonio y un cliente docker locales, que crean imágenes usando archivos dockerfiles. Si necesitan compartir imágenes de la ventana acoplable, puede proporcionar un registro de la ventana acoplable local o usar los públicos. De esta manera, aprovechando la ventana acoplable, puede tener exactamente el mismo entorno de desarrollo a disposición de los desarrolladores. Este entorno de desarrollo será similar al entorno de producción.
P en mi mente era, ¿cuál es la forma preferida de trabajar en equipo? ¿Un demonio para todo el equipo en un servidor separado con cada desarrollador ejecutando un cliente? O cada desarrollador tiene su propio demonio
Cada desarrollador trabaja con su propio demonio y contenedor Docker: la idea con Docker es poder especificar (Dockerfile) un contenedor que cada desarrollador pueda reconstruir y usar localmente, con la seguridad de que la compilación docker producirá exactamente la misma imagen.
O pueden insertar una imagen en la ventana acoplable y reutilizarla en su propia instancia local del demonio de la ventana acoplable.
Pero en cualquier caso, el demonio docker es por servidor, lo que significa que lo compartiría a través de un equipo solo si dicho equipo accedió a un servidor común. Si no, pueden instalar docker en su estación de trabajo, en cuyo caso, cada uno tiene su propio demonio docker.
El demonio Docker se instala en una máquina host y actúa esencialmente como el cerebro de Docker; crea y administra sus imágenes de Docker en su nombre. Todo su propósito es ejecutar los comandos que emite el cliente.
Por ejemplo, si emite el comando de detención de Docker para un contenedor en particular, el demonio seguirá adelante, encontrará el contenedor y lo detendrá.
Además, cada vez que su contenedor necesite acceso a los puertos de red, volúmenes de almacenamiento o cualquier otro componente a nivel del sistema operativo, el demonio Docker se lo proporcionará.