sockets - for - ¿Qué significa fd:// exactamente en dockerd-H fd://
dockerd exe (2)
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?
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://
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
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 procesosystemd
.(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 quedocker.service
la primera solicitud, pasando los sockets ya creados a Docker. Esto se denomina auto-generación a petición)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
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.