docker - images - kubectl run

diferencia entre Docker Attach y Docker Exec

Question

Ambos podrán ejecutar comandos en el contenedor. Ambos podrían separar el contenedor.

Entonces, ¿cuál es la verdadera diferencia entre Docker Exec y Docker Attach?

Answer 1

Como dijo Michael Sun en su respuesta

docker exec ejecuta un nuevo comando / crea un nuevo proceso en el entorno del contenedor, mientras que docker attach conecta la entrada / salida / error estándar del proceso principal (con PID 1) dentro del contenedor a la entrada / salida / error estándar correspondiente de la corriente terminal (la terminal que está utilizando para ejecutar el comando).

Mi respuesta se centrará más en permitirle validar la declaración anterior y comprenderla más claramente.

Abra una ventana de terminal y ejecute el comando docker run -itd --name busybox busybox /bin/sh . El comando extraerá la imagen busybox si aún no está presente. Luego creará un contenedor con el nombre busybox usando esta imagen.

Puede verificar el estado de su contenedor ejecutando el comando docker ps -a | grep busybox docker ps -a | grep busybox .

Si va a ejecutar docker top busybox , debería ver una salida similar a esta.

UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                7469                7451                0                   11:40               pts/0               00:00:00            /bin/sh

Por supuesto, el PID , PPID y otros valores serán diferentes en su caso. Puede usar otras herramientas y utilidades, como pstree , top , htop para ver la lista de PID y PPID .

El PID y PPID significa la identificación del proceso y la identificación del proceso padre. El proceso comenzó cuando creamos e iniciamos nuestro contenedor con el comando /bin/sh . Ahora, ejecute el comando docker attach busybox . Esto adjuntará el flujo de entrada / salida / error estándar del contenedor a su terminal.

Después de adjuntar el contenedor, cree una sesión de shell ejecutando el comando sh . Presione CTRL-p CTRL-q secuencia. Esto separará la terminal del contenedor y mantendrá el contenedor en funcionamiento. Si ahora ejecuta docker top busybox , debería ver dos procesos en la lista.

UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                7469                7451                0                   11:40               pts/0               00:00:00            /bin/sh
root                7737                7469                0                   11:43               pts/0               00:00:00            sh

Pero el PPID de los dos procesos será diferente. De hecho, el PPID del segundo proceso será el mismo que el PID del primero. El primer proceso actúa como el proceso padre para la sesión de shell que acabamos de crear.

Ahora, ejecute docker exec -it busybox sh . Una vez dentro del contenedor, verifique la lista de procesos en ejecución para el busybox del contenedor en otra ventana de terminal ejecutando el comando docker top busybox . Debería ver algo como esto

UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                7469                7451                0                   11:40               pts/0               00:00:00            /bin/sh
root                7737                7469                0                   11:43               pts/0               00:00:00            sh
root                7880                7451                0                   11:45               pts/1               00:00:00            sh

El PPID del primer y tercer proceso será el mismo, lo que confirma que docker exec crea un nuevo proceso en el entorno del contenedor, mientras que PPID conecta la entrada / salida / error estándar del proceso principal dentro del contenedor a la entrada estándar correspondiente. salida / error del terminal actual.

Answer 2

Cuando un contenedor se inicia usando / bin / bash, se convierte en el PID 1 de los contenedores y la conexión acoplable se usa para ingresar al PID 1 de un contenedor. Entonces, docker attach <container-id> lo llevará dentro del terminal bash, ya que es PID 1 como mencionamos al iniciar el contenedor. Salir del contenedor lo detendrá.

Mientras que en el comando docker exec puede especificar en qué shell desea ingresar. No lo llevará al PID 1 del contenedor. Creará un nuevo proceso para bash. docker exec -it <contenedor-id> bash . Salir del contenedor no lo detendrá.

También puede usar nsenter para ingresar dentro de los contenedores. nsenter -m -u -n -p -i -t <pid of container> Puede encontrar el PID del contenedor utilizando: docker inspeccionar <container-id> | grep PID

Nota: Si ha iniciado su contenedor con el indicador -d, al salir del contenedor no se detendrá, ya sea que use attach o exec para entrar.

Answer 3

Docker Exec ejecuta un nuevo comando / crea un nuevo proceso en el entorno del contenedor, mientras que Docker Attach conecta la entrada / salida / error estándar del proceso principal (con PID 1) dentro del contenedor a la entrada / salida / error estándar correspondiente de la corriente terminal (la terminal que está utilizando para ejecutar el comando).

Un contenedor es un entorno aislado, con algunos procesos ejecutándose en el entorno. Específicamente, un contenedor tiene su propio espacio de sistema de archivos y espacio PID que están aislados del host y otros contenedores. Cuando el contenedor se inicia utilizando "docker run –it ...", el proceso principal tendrá un pseudo-tty y STDIN abierto. Cuando se conecta en el modo tty, puede desconectarse del contenedor (y dejarlo en funcionamiento) utilizando una secuencia de teclas configurable. La secuencia predeterminada es CTRL-p CTRL-q. Usted configura la secuencia de teclas usando la opción --detach-keys o un archivo de configuración. Puede volver a conectarlo a un contenedor separado con conexión acoplable.

Docker exec simplemente inicia un nuevo proceso, dentro del entorno del contenedor, es decir, pertenece al espacio PID del contenedor.

Por ejemplo, si inicia su contenedor utilizando "docker run –dit XXX / bin / bash", puede adjuntarlo al contenedor (proceso principal) utilizando dos terminales diferentes. Mientras ingresa en un terminal, puede ver que aparece en el otro terminal, ya que ambos terminales están conectados al mismo tty. Tenga cuidado de que ahora se encuentra en el proceso principal del contenedor, si escribe "salir", saldrá del contenedor ( así que tenga cuidado, utilizando las teclas de desconexión para desconectar ), y verá que ambos terminales se han salido. Pero si ejecuta "docker exec –it XXX / bin / bash" en dos terminales, ha iniciado dos nuevos procesos dentro del contenedor, y no están relacionados entre sí y con el proceso principal, y puede salir de ellos de forma segura. .

Answer 4

Hubo un compromiso de relaciones públicas que se agregó al documento:

Nota: Este comando ( attach ) no es para ejecutar un nuevo proceso en un contenedor. Ver: docker exec .

La respuesta a " Docker. ¿Cómo obtener bash / ssh dentro del contenedor run -d ( run -d )? " Ilustra la diferencia:

(docker> = 1.3) Si usamos docker attach , solo podemos usar una instancia de shell .
Entonces, si queremos abrir una nueva terminal con una nueva instancia del shell del contenedor, solo necesitamos ejecutar docker exec

si el contenedor docker se inició con el comando /bin/bash , puede acceder a él mediante adjuntar, de lo contrario, debe ejecutar el comando para crear una instancia de bash dentro del contenedor con exec .

Como se menciona en este número :

• Adjuntar no es para ejecutar una cosa adicional en un contenedor, es para adjuntar al proceso de ejecución.
• " docker exec " es específicamente para ejecutar cosas nuevas en un contenedor ya iniciado, ya sea un shell o algún otro proceso.

El mismo problema agrega:

Si bien attach no está bien nombrado, particularmente debido al comando LXC lxc-attach (que es más parecido a docker exec <container> /bin/sh , pero específico de LXC), tiene un propósito específico de literalmente adjuntarlo al proceso Docker empezado.
Dependiendo de cuál sea el proceso, el comportamiento puede ser diferente , por ejemplo, adjuntar a /bin/bash le dará un shell, pero adjuntar a redis-server será como si acabara de iniciar redis directamente sin demonizar.