run library imagenes hub dockers container compose docker dockerfile docker-image

library - ¿Hay alguna manera de combinar imágenes Docker en 1 contenedor?



download docker image (5)

Tengo algunos Dockerfiles ahora mismo.

Una es para Cassandra 3.5, y es FROM cassandra:3.5

También tengo un Dockerfile para Kafka, pero es un poco más complejo. Es FROM java:openjdk-8-fre y ejecuta un comando largo para instalar Kafka y Zookeeper.

Finalmente, tengo una aplicación escrita en Scala que usa SBT.

Para ese Dockerfile, es FROM broadinstitute/scala-baseimage , que me proporciona Java 8, Scala 2.11.7 y STB 0.13.9, que es lo que necesito.

Tal vez, no entiendo cómo funciona Docker, pero mi programa Scala tiene a Cassandra y Kafka como dependencias y para propósitos de desarrollo, quiero que otros puedan simplemente clonar mi repo con el Dockerfile y luego poder construirlo con Cassandra, Kafka, Scala, Java y SBT se incorporaron para que puedan compilar la fuente. Aunque estoy teniendo muchos problemas con esto.

¿Cómo combino estos Dockerfiles? ¿Cómo simplemente hago un ambiente con esas cosas horneadas?


Docker no hace una fusión de las imágenes, pero no hay nada que le impida combinar los archivos docker, si están disponibles, y convertirlos en una imagen gruesa que debería construir. Sin embargo, hay momentos en que esto tiene sentido, ya que para ejecutar múltiples procesos en un contenedor, la mayoría de los dogmas de Docker señalarán que esto es menos deseable, especialmente con la arquitectura de microservicio (sin embargo, ¿hay reglas que deben romperse?)


No se pudieron combinar las imágenes de la ventana acoplable en 1 contenedor. Vea las discusiones detalladas en el tema Moby, ¿Cómo combino varias imágenes en una a través de Dockerfile ?

Para su caso, es mejor no incluir todas las imágenes de Cassandra y Kafka. La aplicación solo necesitaría el controlador Cassandra Scala y el controlador Kafka Scala. El contenedor debe incluir solo los controladores.


No se pueden combinar los archivos docker ya que pueden producirse conflictos. Lo que desea hacer es crear un nuevo archivo docker o crear una imagen personalizada.

TL; DR; Si su contenedor de desarrollo actual contiene todas las herramientas que necesita y funciona, entonces guárdelo como una imagen y póngalo en un repositorio y cree un archivo docker para extraer de esa imagen ese repositorio.

Detalles: la creación de una imagen personalizada es mucho más fácil que crear un archivo docker usando una imagen pública, ya que puede almacenar cualquier hacks y mods en la imagen. Para hacerlo, inicie un contenedor en blanco con una imagen básica de Linux (o broadinstitute / scala-baseimage), instale las herramientas que necesite y configúrelas hasta que todo funcione correctamente, luego guárdela (el contenedor) como una imagen. Cree un nuevo contenedor a partir de esta imagen y haga una prueba para ver si puede construir su código sobre él a través de docker-compose (o como quiera hacerlo / compilarlo). Si funciona, entonces tienes una imagen base de trabajo que puedes subir a un repositorio para que otros puedan extraerla.

Para crear un archivo docker con una imagen pública, deberá colocar todos los hacks, mods y configuración en el archivo docker. Es decir, deberás colocar cada línea de comando que usaste en un archivo de texto y reducir cualquier hacks, mods y configuración en líneas de comando. Al final, su dockerfile creará una imagen automáticamente y no necesita almacenar esta imagen en un repositorio y todo lo que necesita hacer es darles a otros el dockerfile y ellos pueden girar la imagen en su propia docker.

Tenga en cuenta que una vez que tenga un archivo docker en funcionamiento, puede modificarlo fácilmente ya que creará una nueva imagen cada vez que use el archivo docker. Con una imagen personalizada, puede tener problemas en los que necesita reconstruir la imagen debido a conflictos. Por ejemplo, todas sus herramientas funcionan con openjdk hasta que instala una que no funciona. La solución puede involucrar la desinstalación de openjdk y el uso de Oracle, pero se rompió toda la configuración que hizo para todas las herramientas que instaló.


Puede, con la función de compilaciones de varias etapas introducida en Docker 1.17

Mira esto:

FROM golang:1.7.3 WORKDIR /go/src/github.com/alexellis/href-counter/ RUN go get -d -v golang.org/x/net/html COPY app.go . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=0 /go/src/github.com/alexellis/href-counter/app . CMD ["./app"]

Luego construye la imagen normalmente:

docker build -t alexellis2/href-counter:latest

Desde: https://docs.docker.com/develop/develop-images/multistage-build/

El resultado final es la misma pequeña imagen de producción que antes, con una reducción significativa en la complejidad. No necesita crear ninguna imagen intermedia y no necesita extraer ningún artefacto en su sistema local.

¿Como funciona? La segunda instrucción DESDE comienza una nueva etapa de construcción con el alpino: la última imagen como base. La línea COPY --from = 0 copia solo el artefacto construido de la etapa anterior en esta nueva etapa. El Go SDK y cualquier artefacto intermedio se quedan atrás y no se guardan en la imagen final.


Sí, puede combinar una gran cantidad de software en una sola imagen de Docker ( GitLab hace esto, con una imagen que incluye Postgres y todo lo demás), pero generalhenry tiene razón: esa no es la forma típica de usar Docker.

Como dices, Cassandra y Kafka son dependencias para tu aplicación Scala, no son parte de la aplicación, por lo que no todas pertenecen a la misma imagen.

Tener que organizar muchos contenedores con Docker Compose agrega una capa de administración adicional, pero le brinda mucha más flexibilidad:

  • sus contenedores pueden tener diferentes vidas útiles, por lo tanto, cuando tenga una nueva versión de su aplicación para implementar, solo necesita ejecutar un nuevo contenedor de aplicaciones, puede dejar las dependencias en ejecución;
  • puede usar la misma imagen de la aplicación en cualquier entorno, usando diferentes configuraciones para sus dependencias; por ejemplo, en dev puede ejecutar un contenedor Kafka básico y en prod, agrupado en muchos nodos, su contenedor de aplicaciones es el mismo;
  • Sus dependencias también pueden ser utilizadas por otras aplicaciones, por lo que varios consumidores pueden ejecutar en diferentes contenedores y todos trabajan con los mismos contenedores de Kafka y Cassandra;
  • más toda la escalabilidad, registro, etc. ya mencionado.