Diferencia entre ejecutar e iniciar un contenedor Docker

En la práctica para iniciar un contenedor, hago:

docker run a8asd8f9asdf0

Si ese es el caso, qué hace:

docker start

¿hacer?

En el manual dice

Iniciar uno o más contenedores detenidos

Esta es una pregunta muy importante y la respuesta es muy simple, pero fundamental:

1. Ejecutar: crea un nuevo contenedor de una imagen y ejecuta el contenedor. Puede crear N clones de la misma imagen. El comando es: docker run IMAGE_ID y no docker run CONTAINER_ID

2. Inicio: inicia un contenedor que se detuvo anteriormente. Por ejemplo, si hubiera detenido una base de datos con el comando docker stop CONTAINER_ID, puede reiniciar el mismo contenedor con el comando docker start CONTAINER_IDy los datos y la configuración serán los mismos.

• runejecuta una imagen
• startinicia un recipiente .

El docker rundocumento menciona:

El docker runcomando primero crea una capa de contenedor grabable sobre la imagen especificada y luego la inicia usando el comando especificado.

Es decir, la ejecución de Docker es equivalente a la API /containers/createentonces /containers/(id)/start.

No ejecuta un contenedor existente, lo ejecuta docker (desde docker 1.3) .
Puede reiniciar un contenedor salido .

Explicación con un ejemplo:

Considere que tiene una imagen de juego (iso) en su computadora.

Cuando usted run(monta su imagen como una unidad virtual), se crea una unidad virtual con todos los contenidos del juego en la unidad virtual y el archivo de instalación del juego se inicia automáticamente. [Ejecutando su imagen acoplable - creando un contenedor y luego iniciándolo]

Pero cuando stop(similar a Docker lo detiene), la unidad virtual todavía existe pero detiene todos los procesos. [Como el contenedor existe hasta que no se elimina]

Y cuando lo hace start(similar al inicio de Docker), desde la unidad virtual, los archivos de los juegos comienzan su ejecución. [comenzando el contenedor existente]

En este ejemplo: la imagen del juego es su imagen Docker y la unidad virtual es su contenedor.

La respuesta de daniele3004 ya es bastante buena.

Solo una fórmula rápida y sucia para personas como yo que se mezclan runy startde vez en cuando:

docker run [...]= docker pull [...]+docker start [...]

runEl comando crea un contenedor a partir de la imagen y luego inicia el proceso raíz en este contenedor. Ejecutarlo con la run --rmbandera le ahorrará la molestia de eliminar el contenedor muerto inútil después y le permitirá ignorar la existencia de docker starty por docker removecompleto.

run El comando hace algunas cosas diferentes:

docker run --name dname image_name bash -c "whoami"

1. Crea un contenedor a partir de la imagen. En este punto, el contenedor tendría una identificación, podría tener un nombre si se le da uno, aparecerá endocker ps
2. Inicia / ejecuta el proceso raíz del contenedor. En el código anterior que se ejecutaría bash -c "whoami". Si se ejecuta docker run --name dname image_namesin un comando para ejecutar el contenedor entraría en estado detenido inmediatamente.
3. Una vez que finaliza el proceso raíz, el contenedor se detiene. En este punto, es prácticamente inútil. Ya no se puede ejecutar nada ni resucitar el contenedor. Básicamente, hay 2 formas de salir del estado detenido: eliminar el contenedor o crear un punto de control (es decir, una imagen) fuera del contenedor detenido para ejecutar otra cosa. Hay que ejecutar docker removeantes de iniciar el contenedor con el mismo nombre.

¿Cómo quitar el contenedor una vez que se detiene automáticamente? Agregue una--rmbandera alruncomando:

docker run --rm --name dname image_name bash -c "whoami"

¿Cómo ejecutar múltiples comandos en un solo contenedor? Al evitar que ese proceso raíz muera. Esto se puede hacer ejecutando algún comando inútil al comienzo con el--detachedindicador y luego usando "ejecutar" para ejecutar comandos reales:

docker run --rm -d --name dname image_name tail -f /dev/null
docker exec dname bash -c "whoami"
docker exec dname bash -c "echo 'Nnice'"

¿Por qué necesitamos docker stopentonces? Para detener este contenedor persistente que lanzamos en el fragmento anterior con el comando sin fintail -f /dev/null.