Varios FROM: lo que significa

Quiero crear una imagen de la ventana acoplable para el proyecto Linkurious en github, que requiere tanto la base de datos Neo4j como Node.js para ejecutarse.

mi primer enfoque fue declarar una imagen base para mi imagen, que contiene Neo4j. Los documentos de referencia no definen "imagen base" de ninguna manera útil:

Imagen base: una imagen que no tiene padre es una imagen base

del cual leí que solo puedo tener una imagen base si esa imagen no tiene una imagen base en sí.

pero ¿qué es una imagen base? ¿Significa que si declaro neo4j / neo4j en una directiva FROM, cuando se ejecute mi imagen, la base de datos neo se ejecutará automáticamente y estará disponible dentro del contenedor en el puerto 7474?

leyendo la referencia de Docker (ver: https://docs.docker.com/reference/builder/#from ) veo:

FROM puede aparecer varias veces dentro de un solo Dockerfile para crear varias imágenes. Simplemente tome nota de la última ID de imagen generada por la confirmación antes de cada nuevo comando FROM.

¿Quiero crear varias imágenes? parece que lo que quiero es tener una sola imagen que contenga el contenido de otras imágenes, por ejemplo, neo4j y node.js

No encontré ninguna directiva para declarar dependencias en el manual de referencia. ¿No hay dependencias como en RPM donde para ejecutar mi imagen, el contexto de llamada debe instalar primero las imágenes que necesita?

Estoy confundido...

¿Qué es una imagen base?

Un conjunto de archivos, más EXPOSE'd ports ENTRYPOINTy CMD.
Puede agregar archivos y crear una nueva imagen basada en esa imagen base, con un nuevo Dockerfilecomienzo con una FROMdirectiva: la imagen que se menciona después FROMes "la imagen base" para su nueva imagen.

¿Significa que si declaro neo4j/neo4jen una FROMdirectiva, que cuando se ejecute mi imagen, la base de datos neo se ejecutará automáticamente y estará disponible dentro del contenedor en el puerto 7474?

Solo si no sobrescribe CMDy ENTRYPOINT.
Pero la imagen en sí misma es suficiente: usaría un FROM neo4j/neo4jsi tuviera que agregar archivos relacionados neo4jpara su uso particular de neo4j.

FROM puede aparecer varias veces dentro de un solo Dockerfile

No: hay una propuesta para eliminar esa "función" de todos modos ( problema 13026 )

El número 14412 menciona:

El uso de múltiples FROMno es realmente una característica sino un error (bueno, el límite es estrecho y hay pocos casos de uso para múltiples FROMen un Dockerfile).

Actualización de mayo de 2017 (18 meses después), con Docker (moby) 17.05-ce .

Se pueden usar varios FROM en un solo Dockerfile.
Consulte " Patrón de constructor frente a compilaciones de varias etapas en Docker " (por Alex Ellis ) y PR 31257 por Tõnis Tiigi .

Antes de:

El patrón del constructor implica el uso de dos imágenes de Docker: una para realizar una compilación y otra para enviar los resultados de la primera compilación sin la penalización de la cadena de compilación y las herramientas en la primera imagen.

Después:

La sintaxis general implica agregar FROMtiempos adicionales dentro de su Dockerfile; la última FROMdeclaración es la imagen base final. Para copiar artefactos y resultados de imágenes intermedias, use COPY --from=<base_image_number>.

Primera parte del Dockerfile:

FROM golang:1.7.3 as builder
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 .

Segunda parte del mismo (!) Dockerfile:

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app    .
CMD ["./app"]  

El resultado serían dos imágenes, una para la construcción, otra con solo la aplicación resultante (mucho, mucho más pequeña)

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

multi               latest              bcbbf69a9b59        6 minutes ago       10.3MB  
golang              1.7.3               ef15416724f6        4 months ago        672MB  

La primera respuesta es demasiado compleja, histórica y poco informativa para mi gusto.

En realidad, es bastante simple. Docker proporciona una funcionalidad llamada compilaciones de múltiples etapas, la idea básica aquí es,

• Libérate de tener que eliminar manualmente lo que no quieres, obligándote a incluir en la lista blanca lo que sí quieres.
• Recursos gratuitos que de otro modo se utilizarían debido a la implementación de Docker.

Empecemos por el primero. Muy a menudo con algo como Debian verá.

RUN apt-get update \ 
  && apt-get dist-upgrade \
  && apt-get install <whatever> \
  && apt-get clean

Podemos explicar todo esto en términos de lo anterior. El comando anterior está encadenado, por lo que representa un único cambio sin imágenes intermedias requeridas. Si estuviera escrito así,

RUN apt-get update ;
RUN apt-get dist-upgrade;
RUN apt-get install <whatever>;
RUN apt-get clean;

El resultado sería 3 imágenes intermedias temporales más. Habiéndolo reducido a una imagen, queda un problema restante: apt-get cleanno limpia los artefactos utilizados en la instalación. Si un mantenedor de Debian incluye en su instalación un script que modifica el sistema, esa modificación también estará presente en la solución final (vea algo así como pepperflashplugin-nonfreeun ejemplo de eso).

Al usar una compilación de múltiples etapas, obtiene todos los beneficios de una sola acción modificada, pero requerirá que ingrese manualmente en la lista blanca y copie los archivos que se introdujeron en la imagen temporal utilizando la COPY --fromsintaxis documentada aquí. Además, es una gran solución donde no hay alternativa (como una apt-get clean), y de lo contrario tendría muchos archivos innecesarios en su imagen final.

Ver también

• Construcciones de varias etapas
• Sintaxis COPY