¿Debo usar Dockerfiles o confirmaciones de imágenes?

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ía comprometerse con las imágenes, porque realmente debería rastrear el Dockerfile en git y hacer cambios en eso. Entonces no hay ambigüedad sobre lo que es autorizado.

Sin embargo, las confirmaciones de imágenes 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 realizar algún cambio que represente lo que hizo.

Así que estoy desgarrado. Me encanta la idea de las confirmaciones de imágenes: que no tienes que representar el estado de tu imagen en un Dockerfile, simplemente puedes rastrearlo directamente. Pero me preocupa renunciar a la idea de algún tipo de archivo de manifiesto que le brinde una descripción general rápida de lo que hay en una imagen. También es desconcertante ver dos funciones en el mismo paquete de software que parecen ser incompatibles.

¿Alguien tiene alguna idea sobre esto? ¿Se considera una mala práctica utilizar confirmaciones de imágenes? ¿O debería simplemente soltar mi archivo adjunto para manifestar archivos de mis días de Puppet? ¿Qué tengo que hacer?

Actualización :

Para todos aquellos que piensan que esta es una pregunta basada en opiniones, no estoy tan seguro. Tiene 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 comprenderá mejor cómo los archivos Dockerfiles y las confirmaciones de imágenes 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 canalización de CI en nuestra empresa y, durante una etapa de la canalización, nuestras pruebas de aplicaciones se ejecutan dentro de un contenedor. Necesitamos recuperar los resultados de cobertura del contenedor salido después de que el proceso de ejecución de prueba los haya generado (en el sistema de archivos del contenedor) y el contenedor haya dejado de ejecutarse. Usamos confirmaciones de imagen para hacer esto confirmando el contenedor detenido para crear una nueva imagen y luego ejecutando comandos que muestran y vuelcan el archivo de cobertura a stdout. Así que es útil tener esto. Aparte de este caso muy específico, utilizamos Dockerfiles para definir nuestros entornos.

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

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

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

Conocer las ventajas e inconvenientes de las 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 confirmaciones 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 denomina aquí imagen dorada, ya que la imagen será su única referencia, punto de inicio y punto final en cada etapa. Si lo pierde, tendrá muchos problemas, ya que no podrá reconstruirlo. El callejón sin salida fatal es que un día necesitará reconstruir uno nuevo (porque todas las bibliotecas del sistema son obsoletas, por ejemplo), y no tendrá idea de qué instalar ... terminando en una gran pérdida de tiempo.

Como nota al margen , es probable que usar confirmaciones sobre confirmaciones sería mejor si el registro del historial fuera fácil de usar (consulte las diferencias y repítalas en otras imágenes) como está en git: notará que git no tiene este dilema.

Pro: mejoras ingeniosas para distribuir

Por otro lado, las confirmaciones 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 precisamente lo que permite la ventana acoplable), o si desea implementar la versión de prueba al instante, estará más feliz de enviar solo una pequeña actualización en forma de una pequeña confirmación en lugar de una 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 sacar lo mejor de dos mundos:

En este tipo de escenario, probablemente desee etiquetar la versión principal de sus imágenes y deberían 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 e inconvenientes de los Dockerfiles y el escenario de confirmaciones de capas. Aquí, el punto clave es que nunca dejas de hacer un seguimiento de tus imágenes al limitar la cantidad de confirmaciones que permitirás hacer en ellas.

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