Estoy explorando el uso de la ventana acoplable para que implementemos nuevas imágenes de la ventana acoplable en lugar de cambios de archivos específicos, por lo que todas las necesidades de la aplicación vienen con cada implementación, etc.
Pregunta 1:
Si agrego un nuevo archivo de aplicación, digamos 10 MB, a una imagen de Docker cuando implemento la nueva imagen, usando las herramientas en la caja de herramientas de Docker, ¿esto requerirá la implementación de una imagen completamente nueva en mis contenedores o hacer implementaciones de Docker? la diferencia entre los 2, similar al control de versiones de git?
Otra forma de decirlo, busqué en una lista de imágenes base de Docker y vi una versión de ubuntu que tiene 188 MB. Si confirmo una nueva aplicación en una imagen acoplable, usando esta imagen base, ¿mis contenedores acoplables necesitarán extraer los 188 MB completos, que ya se están ejecutando, más la aplicación o hay una forma diferencial de simplemente obtener lo que ha cambiado?
Pregunta complementaria
¿Estoy en lo correcto al suponer que cuando uso la ventana acoplable, la implementación de imágenes es el enfoque previsto? ¿Significa que cualquier cambio nuevo debería requerir una nueva implementación de imagen para que las imágenes se traten como inmutables? Cuando estaba usando AWS, seguimos este enfoque con AMI (Amazon Machine Images), pero el almacenamiento de AMI tenía una sobrecarga baja, para docker aún no lo sé.
¿O es una mejor práctica implementar archivos acoplables y hacer que la nueva imagen se construya en el propio contenedor?
Docker utiliza un sistema de archivos de unión en capas, solo una copia de una capa será extraída por un motor acoplable y almacenada en su sistema de archivos. Cuando construye una imagen, la ventana acoplable verificará su caché de capa para ver si la misma capa principal y el mismo comando se han usado para construir una capa existente y, de ser así, el caché se reutiliza en lugar de construir una nueva capa. Una vez que cualquier paso en la compilación crea una nueva capa, todos los pasos siguientes crearán nuevas capas, por lo que el orden de su Dockerfile es importante. Debe agregar pasos que cambian con frecuencia al final del Dockerfile para que los pasos anteriores se puedan almacenar en caché.
Por lo tanto, si usa una imagen base de 200 MB, tiene 50 MB de adiciones, pero solo 10 MB son adiciones nuevas al final de su Dockerfile, enviaría 250 MB la primera vez a un motor acoplable, pero solo 10 MB a un motor que ya tenía una copia anterior de esa imagen, o 50 MB a un motor que solo tenía la imagen base de 200 MB.
La mejor práctica con las imágenes es crearlas una vez, enviarlas a un registro (ya sea alojado por sí mismo usando la imagen del registro, alojado en la nube por alguien como AWS o en Docker Hub) y luego extraer esa imagen a cada motor que necesita ejecutarse. eso.
Para obtener más detalles sobre el sistema de archivos en capas, consulte https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
También puede trabajar un poco para crear imágenes más pequeñas. Puede usar Alpine o Busybox en lugar de usar Ubuntu, Debian o Bitnami (Debian light).
Una imagen más pequeña es más segura ya que hay menos herramientas disponibles.
algo de lectura
http://blog.xebia.com/cómo-crear-el-contenedor-docker-más-pequeño-posible-de-cualquier-imagen/
https://www.dajobe.org/blog/2015/04/18/making-debian-docker-images-smaller/
Tienes 2 excelentes herramientas para hacer imágenes acoplables más pequeñas
https://github.com/docker-slim/docker-slim
y
https://github.com/mvanholsteijn/strip-docker-imagen
Algunos ejemplos con docker-slim
https://hub.docker.com/r/k3ck3c/grafana-xxl.slim/
espectáculos
size before -> 357.3 MB
y using docker-slim -> 18.73 MB
o sobre simh
https://hub.docker.com/r/k3ck3c/simh_bitnami.slim/
size 5.388 MB
cuando el original
k3ck3c/simh_bitnami 88.86 MB
una imagen popular de netcat
chilcano/netcat tiene 135.2 MB
cuando un netcat basado en Alpine tiene 7.812 MB
y en base a busybox necesitará 2 o 3 MB