¿Cómo puedo inspeccionar el sistema de archivos de una 'construcción de docker' fallida?

Estoy tratando de construir una nueva imagen de Docker para nuestro proceso de desarrollo, utilizando cpanmpara instalar un montón de módulos Perl como imagen base para varios proyectos.

Mientras desarrolla el Dockerfile, cpanmdevuelve un código de falla porque algunos de los módulos no se instalaron limpiamente.

Estoy bastante seguro de que necesito aptinstalar algunas cosas más.

Mi pregunta es, ¿dónde puedo encontrar el /.cpanm/workdirectorio citado en la salida para inspeccionar los registros? En el caso general, ¿cómo puedo inspeccionar el sistema de archivos de un docker buildcomando fallido ?

Editar mañana Después de morder la bala y ejecutar un finddescubrí

/var/lib/docker/aufs/diff/3afa404e[...]/.cpanm

¿Es esto confiable, o es mejor construir un contenedor "desnudo" y ejecutar cosas manualmente hasta que tenga todo lo que necesito?

Cada vez que Docker ejecuta con éxito un RUNcomando desde un Dockerfile, se confirma una nueva capa en el sistema de archivos de imagen . Convenientemente, puede usar esos identificadores de capas como imágenes para iniciar un nuevo contenedor.

Tome el siguiente Dockerfile:

FROM busybox
RUN echo 'foo' > /tmp/foo.txt
RUN echo 'bar' >> /tmp/foo.txt

y construirlo:

$ docker build -t so-2622957 .
Sending build context to Docker daemon 47.62 kB
Step 1/3 : FROM busybox
 ---> 00f017a8c2a6
Step 2/3 : RUN echo 'foo' > /tmp/foo.txt
 ---> Running in 4dbd01ebf27f
 ---> 044e1532c690
Removing intermediate container 4dbd01ebf27f
Step 3/3 : RUN echo 'bar' >> /tmp/foo.txt
 ---> Running in 74d81cb9d2b1
 ---> 5bd8172529c1
Removing intermediate container 74d81cb9d2b1
Successfully built 5bd8172529c1

Ahora puede comenzar un nuevo contenedor de 00f017a8c2a6, 044e1532c690y 5bd8172529c1:

$ docker run --rm 00f017a8c2a6 cat /tmp/foo.txt
cat: /tmp/foo.txt: No such file or directory

$ docker run --rm 044e1532c690 cat /tmp/foo.txt
foo

$ docker run --rm 5bd8172529c1 cat /tmp/foo.txt
foo
bar

por supuesto, es posible que desee iniciar un shell para explorar el sistema de archivos y probar comandos:

$ docker run --rm -it 044e1532c690 sh      
/ # ls -l /tmp
total 4
-rw-r--r--    1 root     root             4 Mar  9 19:09 foo.txt
/ # cat /tmp/foo.txt 
foo

Cuando falla uno de los comandos de Dockerfile, lo que debe hacer es buscar la identificación de la capa anterior y ejecutar un shell en un contenedor creado a partir de esa identificación:

docker run --rm -it <id_last_working_layer> bash -il

Una vez en el contenedor:

• pruebe el comando que falló y reproduzca el problema
• luego arregla el comando y pruébalo
• finalmente actualice su Dockerfile con el comando fijo

Si realmente necesita experimentar en la capa real que falló en lugar de trabajar desde la última capa de trabajo, vea la respuesta de Drew .

La respuesta principal funciona en el caso de que desee examinar el estado inmediatamente anterior al comando fallido.

Sin embargo, la pregunta pregunta cómo examinar el estado del contenedor fallido. En mi situación, el comando fallido es una compilación que lleva varias horas, por lo que rebobinar antes del comando fallido y ejecutarlo nuevamente lleva mucho tiempo y no es muy útil.

La solución aquí es encontrar el contenedor que falló:

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                          PORTS               NAMES
6934ada98de6        42e0228751b3        "/bin/sh -c './utils/"   24 minutes ago      Exited (1) About a minute ago                       sleepy_bell

Compromételo con una imagen:

$ docker commit 6934ada98de6
sha256:7015687976a478e0e94b60fa496d319cdf4ec847bcd612aecf869a72336e6b83

Y luego ejecute la imagen [si es necesario, ejecutando bash]:

$ docker run -it 7015687976a4 [bash -il]

Ahora realmente está mirando el estado de la compilación en el momento en que falló, en lugar de en el momento antes de ejecutar el comando que causó la falla.

Docker almacena en caché todo el estado del sistema de archivos después de cada RUNlínea exitosa .

Sabiendo que:

• para examinar el último estado antes de su RUNcomando fallido , coméntelo en el Dockerfile (así como en cualquiera y todos los RUNcomandos posteriores ), luego ejecútelo una docker buildy docker runotra vez.
• para examinar el estado después del RUNcomando fallido , simplemente agréguelo || truepara forzarlo a tener éxito; luego proceda como anteriormente (mantenga RUNcomentados todos y cada uno de los comandos posteriores , ejecute docker buildy docker run)

Tada, no es necesario meterse con elementos internos de Docker o ID de capa, y como beneficio adicional, Docker minimiza automáticamente la cantidad de trabajo que se debe volver a hacer.

La depuración de fallas de paso de compilación es realmente muy molesta.

La mejor solución que he encontrado es asegurarme de que cada paso que hace un trabajo real tenga éxito y agregar un cheque después de aquellos que fallan. De esa forma, obtiene una capa comprometida que contiene los resultados del paso fallido que puede inspeccionar.

Un Dockerfile, con un ejemplo después de la # Run DB2 silent installerlínea:

#
# DB2 10.5 Client Dockerfile (Part 1)
#
# Requires
#   - DB2 10.5 Client for 64bit Linux ibm_data_server_runtime_client_linuxx64_v10.5.tar.gz
#   - Response file for DB2 10.5 Client for 64bit Linux db2rtcl_nr.rsp 
#
#
# Using Ubuntu 14.04 base image as the starting point.
FROM ubuntu:14.04

MAINTAINER David Carew <carew@us.ibm.com>

# DB2 prereqs (also installing sharutils package as we use the utility uuencode to generate password - all others are required for the DB2 Client) 
RUN dpkg --add-architecture i386 && apt-get update && apt-get install -y sharutils binutils libstdc++6:i386 libpam0g:i386 && ln -s /lib/i386-linux-gnu/libpam.so.0 /lib/libpam.so.0
RUN apt-get install -y libxml2


# Create user db2clnt
# Generate strong random password and allow sudo to root w/o password
#
RUN  \
   adduser --quiet --disabled-password -shell /bin/bash -home /home/db2clnt --gecos "DB2 Client" db2clnt && \
   echo db2clnt:`dd if=/dev/urandom bs=16 count=1 2>/dev/null | uuencode -| head -n 2 | grep -v begin | cut -b 2-10` | chgpasswd && \
   adduser db2clnt sudo && \
   echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

# Install DB2
RUN mkdir /install
# Copy DB2 tarball - ADD command will expand it automatically
ADD v10.5fp9_linuxx64_rtcl.tar.gz /install/
# Copy response file
COPY  db2rtcl_nr.rsp /install/
# Run  DB2 silent installer
RUN mkdir /logs
RUN (/install/rtcl/db2setup -t /logs/trace -l /logs/log -u /install/db2rtcl_nr.rsp && touch /install/done) || /bin/true
RUN test -f /install/done || (echo ERROR-------; echo install failed, see files in container /logs directory of the last container layer; echo run docker run '<last image id>' /bin/cat /logs/trace; echo ----------)
RUN test -f /install/done

# Clean up unwanted files
RUN rm -fr /install/rtcl

# Login as db2clnt user
CMD su - db2clnt

Lo que haría es comentar el Dockerfile a continuación e incluir la línea ofensiva. Luego puede ejecutar el contenedor y ejecutar los comandos de la ventana acoplable a mano, y mirar los registros de la manera habitual. Por ejemplo, si el Dockerfile es

RUN foo
RUN bar
RUN baz

y se está muriendo en el bar que haría

RUN foo
# RUN bar
# RUN baz

Luego

$ docker build -t foo .
$ docker run -it foo bash
container# bar
...grep logs...