sockets - for - ¿Qué significa fd:// exactamente en dockerd-H fd://

dockerd exe

Question

La documentación del demonio Docker sugiere la siguiente opción de hosts para la mayoría de las configuraciones:

dockerd -H fd://

Supongo que fd significa descriptor de archivos. No entiendo cómo se usa fd para la comunicación de socket.

Entiendo las siguientes opciones:

-H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2

Estos son los sockets de dominio Unix y sockets tcp. Sé cómo llamar al demonio docker usando estos sockets:

docker -H tcp://0.0.0.0:2375 ps

Pero si inicié el demonio docker usando -H fd:// , la siguiente llamada genera un error:

$ docker -H fd:// ps
error during connect: Get http:///v1.26/containers/json: http: no Host in request URL

Entonces, ¿cuál es el significado de fd:// ? ¿Hay algún uso para ello?

Answer 1

Cuando inicie el demonio Docker, -H fd:// le dirá a Docker que Systemd está iniciando el servicio y usará la activación de socket. systemd creará el socket de destino y lo pasará al demonio de Docker para que lo use. Esto se describe en la introducción a Systemd y en la introducción a la activación de socket . Los blogs son bastante largos pero realmente vale la pena leerlos, aquí hay un breve resumen de los puntos clave para entender esta pregunta:

• Systemd es un nuevo sistema de init destinado a reemplazar el sistema de inicio tradicional SysV. Una de sus características clave es un proceso de inicio más rápido.
• Socket activation es una de las tecnologías utilizadas en Systemd para acelerar la inicialización del servicio
• Para recibir solicitudes, el servicio necesita un socket para escuchar. Tome Docker como ejemplo, necesita un unix domain socket como /var/run/docker.sock o un socket TCP. Por supuesto, estas tomas necesitan algo para crearlas y la mayoría de las veces es el servicio en sí en el momento de inicio.
• Con la activación de socket, SystemD creará estos sockets y los escuchará para los servicios, y los pasará al servicio con exec cuando se inicie el servicio. Una de las ventajas es que las solicitudes de los clientes pueden ponerse en cola en el búfer de socket una vez que el socket se haya creado correctamente, incluso antes de que se inicie el servicio relacionado.

• La información de socket para un determinado servicio utilizado por Systemd está en el archivo de unidad de socket , para Docker es [docker.socket][3] con contenido:

  [Unit]
  Description=Docker Socket for the API
  PartOf=docker.service
  [Socket]
  ListenStream=/var/run/docker.sock
  SocketMode=0660
  SocketUser=root
  SocketGroup=docker
  [Install]
  WantedBy=sockets.target

Veamos cómo funciona todo. Tengo los archivos docker.socket y docker.service en /etc/systemd/system . La línea docker.service para docker.service es:

ExecStart=/usr/bin/dockerd -H fd://

1. Servicio Stop Docker: systemctl stop docker

   $> ps aux | grep ''docker'' # the `grep` itself in the output is ignored
   $> lsof -Ua | grep ''docker''
   $>

   No se está ejecutando ningún proceso de docker, y no hay docker.sock

2. Ejecute systemctl start docker.socket :

   $> systemctl start docker.socket
   $> ps aux | grep ''docker''
   $> lsof -Ua | grep ''docker''
   systemd 1 root 27u unix 0xffff880036da6000 0t0 140748188 /var/run/docker.sock

   Después de iniciar docker.socket , podemos ver que todavía no se está ejecutando ningún proceso de docker, pero se ha creado el socket /var/run/docker.sock , y pertenece al proceso systemd .

   (Fuera de tema: en realidad, el socket está listo para recibir solicitudes ahora, aunque la docker aún no se está ejecutando. docker.service iniciará docker.service en el momento en que docker.service la primera solicitud, pasando los sockets ya creados a Docker. Esto se denomina auto-generación a petición)

3. Iniciar docker.service

   $> systemctl start docker.service
   $> ps aux | grep ''docker''
   root 26302 0.0 1.8 431036 38712 ? Ssl 14:57 0:00 /usr/bin/dockerd -H fd://
   <....>

   Como puedes ver, Docker ahora está corriendo. Retrocedamos un paso e intentemos ejecutar /usr/bin/dockerd -H fd:// manualmente desde la terminal:

   $> /usr/bin/dockerd -H fd://
   FATA[0000] no sockets found via socket activation: make sure the service was started by systemd

   Ahora ves la diferencia; cuando use -H fd:// , la ventana acoplable esperará que el socket pase el proceso primario en lugar de crearlo por sí mismo. Cuando lo inicia Systemd, Systemd hará el trabajo, pero cuando lo inicies manualmente en la terminal, no lo harás, por lo que el proceso del daemon docker falló y se abortó. Este es el código de cómo el docker procesa fd: // cuando se inicia el daemon docker , puede echar un vistazo si está interesado.

Por otro lado, para el cliente de la ventana acoplable, cli de la ventana acoplable analizará el protocolo / addr del host especificado en -H y realizará una solicitud http al demonio de la ventana acoplable. El host predeterminado es unix:///var/run/docker.sock . Los protocolos soportados incluyen tcp , unix , npipe y fd . Hasta donde exploro desde el código fuente, la configuración de transporte para fd es la misma que con tcp por lo tanto, si tiene escucha de socket TCP, solo puede jugar con:

$> docker -H fd://localhost:4322 ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

que es lo mismo que

docker -H tcp://localhost:4322 ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Answer 2

La sintaxis -H fd:// se usa cuando se ejecuta la ventana acoplable dentro de systemd. Systemd creará un socket en el archivo de la unidad docker.socket y lo escuchará, y este socket está conectado al demonio docker con la sintaxis fd:// en el archivo de la unidad docker.service.