El contenedor de solo datos de mi acoplador está vacío

El escenario que más temía ha sucedido: mi contenedor acoplador solo de datos está repentinamente vacío.

Esto no es serio: es una máquina de desarrollo y tengo respaldo. Pero me temo más porque sé que todavía tengo agujeros en mi comprensión de Docker.

He leído en esta respuesta lo siguiente:

Los contenedores Docker persistirán en el disco hasta que se eliminen explícitamente con docker rm .

Aquí están los contenedores que me interesan (de un command docker ps ):

 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 478e59ecd218 dockerlocal_mongo_instance "/entrypoint.sh mongo" About an hour ago Exited (137) 12 minutes ago dockerlocal_mongo_instance_1 0ca49f6629cb tianon/true "/true" 3 hours ago Exited (0) About an hour ago dockerlocal_mongo_data_1 

Tengo un 1) un contenedor de mongo que hace reference al contenedor de solo datos, y 2) el contenedor de solo datos en sí. Recientemente ejecuté docker rm un par de veces en el contenedor mongo dockerlocal_mongo_instance_1 que hace reference al contenedor de solo datos.

Puedo ver desde la salida del command docker ps (ver arriba) que dice que el contenedor de solo datos fue creado 'hace 3 horas'. Pero lo creé hace 2 semanas. De alguna manera mi original se ha ido. Mi pregunta es ¿cómo podría suceder esto? ¿Qué otras posibilidades hay?

Revisé el historial de commands de bash y el command docker rm se ejecutó solo en el contenedor de mongo, no en el contenedor de solo datos, que por razones obvias he tenido mucho cuidado de no tocar.

¿Alguien puede aclarar esto? Debo haber entendido mal algo fundamental aquí.

Agradecería cualquier otro escenario posible que pudiera causar que el contenedor de datos se destruya y se vuelva a crear de esta manera.

Docker compone el file .yml (bits relevantes):

 mongo_data: image: tianon/true volumes: - /data/db mongo_instance: build: mongodb volumes_from: - mongo_data ports: - "27017:27017" environment: - MONGODB_USER=$S_USER_NAME - MONGODB_PASS=$S_USER_PASSWORD # command: --auth 

Hay un par de cosas que debes entender.

  • Un contenedor de datos no tiene que estar, y no debería estar, ejecutándose. En realidad, es solo un espacio de nombres para un set de volúmenes al que se puede hacer reference desde otros contenedores. En su caso, cada vez que inicie su aplicación, el contenedor de datos se iniciará, se ejecutará true y luego se apagará. Sería mejor si acaba de crear el contenedor una vez y nunca lo volvió a ejecutar.
  • Docker Compose define los services en ejecución que componen su aplicación. Tiene mucha lógica relacionada con decidir cuándo recrear los contenedores o reutilizar los existentes, lo que en algún momento ha decidido recrear su contenedor de datos (no estoy seguro de por qué en este caso). Solo debes poner cosas en Compose que no necesiten persistir. También tenga en count que Compose intentará copyr volúmenes de contenedores viejos a nuevos, lo que puede causar confusión si no lo espera.

En su caso, la solución es definir el contenedor de datos fuera de Compose, por ejemplo:

 docker run --name mongo_data mongodb echo "Data Container" 

Esto ejecutará el command echo inmediatamente saldrá. A continuación, puede eliminar la input mongo_data de Compose yaml. Tenga en count que he usado intencionalmente la image de mongodb lugar de tianon/true ; como un contenedor de datos no se deja en ejecución, no ocupará ningún espacio adicional y el uso de la image mongodb garantiza que los permissions de files, etc. son correctos.

Si alguna vez ejecutó docker-compose rm (o, peor, docker-compose rm -f ), eso hubiera eliminado todos los contenedores existentes definidos en su docker-compose.yml . Tenga en count que, incluso si solo pretendía iniciar el contenedor mongo_instance con docker-compose up mongo_instance , mongo_data se habría creado el contenedor mongo_data , ya que mongo_instance depende de mongo_data , y docker-compose rm mientras mongo_instance estaba alnetworkingedor eliminaría ambos contenedores.

La respuesta para mí al final es olvidar el uso de un contenedor de datos de docker y simplemente establecer un volumen normal en el contenedor mongo.

 mongo_instance: build: mongodb volume: - /data/db:/data/db ports: - "27017:27017" environment: - MONGODB_USER=$S_USER_NAME - MONGODB_PASS=$S_USER_PASSWORD 

¿Por qué?

  1. La razón principal para usar Docker Compose en mi opinión es su portabilidad. Puede ejecutar fácilmente todos sus commands de docker en un solo lugar, lo que significa una installation simple. Entonces, si usar un contenedor de datos del acoplador significa mover la creación del contenedor de datos fuera del file .yml, lo estoy complicando todo: primero tengo que crear el contenedor de datos y luego ejecutar el docker componer: preferiría simplemente cargar mi .yml archivar y ejecutarlo.
  2. De todos modos, encontré problemas con la creación del contenedor de datos antes de llamar a docker-compose. Se recomienda volver a utilizar sus propias imágenes al crear contenedores de datos en lugar de utilizar imágenes pequeñas de terceros como tianon / true. Pero mis imágenes, que podría usar, solo se crean cuando ejecuto Docker-Componer y todavía no lo he ejecutado, una situación de huevo y pollo.
  3. Intenté crear un contenedor de datos usando tianon / true (y otros) y siempre encontré problemas de permissions.

Así que eliminé el contenedor de datos y usé un parámetro de volumen en mongo_instance. Espero que esto también resuelva mi problema original …