imagenes - download docker image

¿Debo usar Dockerfiles o confirmaciones de imagen?

Question

Estoy un poco confundido acerca de estas dos opciones. Parecen estar relacionados. Sin embargo, no son realmente compatibles.

Por ejemplo, parece que usar Dockerfiles significa que realmente no deberías comprometerte con las imágenes, porque realmente solo debes rastrear el Dockerfile en git y hacer cambios en eso. Entonces no hay ambigüedad sobre lo que es autoritario.

Sin embargo, las confirmaciones de imagen parecen realmente agradables. Es tan bueno que podría modificar un contenedor directamente y etiquetar los cambios para crear otra imagen. Entiendo que incluso puede obtener algo como un sistema de archivos diferente de un historial de confirmación de imagen. Increíble. Pero entonces no deberías usar Dockerfiles. De lo contrario, si realizó una confirmación de imagen, tendría que volver a su Dockerfile y hacer algún cambio que represente lo que hizo.

Entonces estoy desgarrado. Me encanta la idea de las confirmaciones de imagen: que no tiene que representar el estado de su imagen en un Dockerfile, simplemente puede rastrearlo directamente. Pero me incomoda renunciar a la idea de algún tipo de archivo de manifiesto que le brinde una visión general rápida de lo que hay en una imagen. También es desconcertante ver dos características en el mismo paquete de software que parecen ser incompatibles.

¿Alguien tiene alguna idea sobre esto? ¿Se considera una mala práctica usar commits de imágenes? ¿O debería dejar ir mi archivo adjunto a los archivos de manifiesto de mis días de Puppet? ¿Qué tengo que hacer?

Actualización :

Para todos aquellos que piensan que esta es una pregunta basada en la opinión, no estoy tan seguro. Hay algunas cualidades subjetivas, pero creo que es principalmente una pregunta objetiva. Además, creo que una buena discusión sobre este tema será informativa.

Al final, espero que cualquiera que lea esta publicación obtenga una mejor comprensión de cómo los Dockerfiles y las confirmaciones de imagen se relacionan entre sí.

Actualización - 2017/7/18 :

Recientemente descubrí un uso legítimo para las confirmaciones de imágenes. Acabamos de configurar una tubería de CI en nuestra empresa y, durante una etapa de la tubería, nuestras pruebas de aplicaciones se ejecutan dentro de un contenedor. Necesitamos recuperar los resultados de la cobertura del contenedor salido después de que el proceso del corredor de prueba los haya generado (en el sistema de archivos del contenedor) y el contenedor haya dejado de ejecutarse. Usamos las confirmaciones de imagen para hacer esto al confirmar el contenedor detenido para crear una nueva imagen y luego ejecutar comandos que muestran y vuelcan el archivo de cobertura en stdout. Entonces es útil tener esto. Además de este caso muy específico, utilizamos Dockerfiles para definir nuestros entornos.

Answer 1

Conocer las ventajas y los inconvenientes de ambas soluciones es un buen comienzo. Porque una combinación de los dos es probablemente una forma válida de hacerlo.

Con: evitar el callejón sin salida de la imagen dorada :

Usar solo commits es malo si pierde la noción de cómo reconstruir su imagen. No desea estar en el estado en que no puede reconstruir la imagen . Este estado final se llama aquí imagen dorada, ya que la imagen será su única referencia, punto de partida y punto final en cada etapa. Si lo pierde, tendrá muchos problemas ya que no puede reconstruirlo. El punto muerto fatal es que un día necesitarás reconstruir uno nuevo (porque todas las bibliotecas del sistema están obsoletas, por ejemplo), y no tendrás idea de qué instalar ... terminando en una gran pérdida de tiempo.

Como nota al margen , es probable que usar commits sobre commits sería mejor si el registro del historial fuera fácilmente utilizable (consulte diffs y repítalos en otras imágenes) ya que está en git: notará que git no tiene este dilema

Pro: mejoras ingeniosas para distribuir

Por otro lado, los commits de capas tienen una ventaja considerable en términos de actualizaciones distribuidas y, por lo tanto, en ancho de banda y tiempo de implementación. Si comienza a manejar imágenes de la ventana acoplable cuando un panadero está manejando panqueques (que es exactamente lo que permite la ventana acoplable), o desea implementar la versión de prueba al instante, será más feliz enviar solo una pequeña actualización en forma de una pequeña confirmación en lugar de un Imagen completamente nueva. Especialmente cuando tiene una integración continua para sus clientes donde las correcciones de errores deben implementarse pronto y con frecuencia.

Intenta obtener lo mejor de dos mundos:

En este tipo de escenario, es probable que desee etiquetar la versión principal de sus imágenes y deben provenir de Dockerfiles . Y puede proporcionar versiones de integración continua gracias a las confirmaciones basadas en la versión etiquetada. Esto mitiga las ventajas y los inconvenientes de Dockerfiles y el escenario de confirmación de capas. Aquí, el punto clave es que nunca deja de hacer un seguimiento de sus imágenes limitando la cantidad de confirmaciones que permitirá realizar en ellas.

Así que supongo que depende de su escenario, y probablemente no debería intentar encontrar una sola regla. Sin embargo, puede haber algunos callejones sin salida que realmente debería evitar (como terminar con un escenario de "imagen dorada") sea cual sea la solución.

Answer 2

Los Dockerfiles son una herramienta que se usa para crear imágenes.

El resultado de ejecutar docker build . es una imagen con una confirmación, por lo que no es posible usar un Dockerfile sin crear una confirmación . La pregunta es, ¿debería actualizar la imagen a mano cada vez que algo cambia y así condenarse a la maldición de la imagen dorada ?

La maldición de la imagen dorada es una terrible maldición sobre las personas que deben seguir viviendo con una imagen base llena de agujeros de seguridad para ejecutar su software porque la persona que la creó fue devorada por los antiguos hace mucho tiempo (o pasó a un nuevo trabajo) y nadie sabe de dónde sacaron la versión de imagemagic que entró en esa imagen. y es lo único que se vinculará con el módulo c ++ que fue provisto por ese consultor que el hijo del jefe contrató hace tres años, y de todos modos no importa porque, incluso si descubriste de dónde proviene imagemagic, la versión de libstdc ++ utilizada por el JNI llama a la herramienta de soporte que internó con el pelo largo creado solo existe en una versión no compatible de ubuntu de todos modos.