Come posso ispezionare il file system di una `docker build` fallita?

Sto cercando di creare una nuova immagine Docker per il nostro processo di sviluppo, usando cpanml'installazione di un gruppo di moduli Perl come immagine di base per vari progetti.

Durante lo sviluppo del Dockerfile, cpanmrestituisce un codice di errore poiché alcuni dei moduli non sono stati installati correttamente.

Sono abbastanza sicuro di dover aptinstallare altre cose.

La mia domanda è: dove posso trovare la /.cpanm/workdirectory citata nell'output, al fine di ispezionare i log? Nel caso generale, come posso controllare il file system di un docker buildcomando non riuscito ?

Modifica del mattino Dopo aver morso il proiettile ed eseguito un findho scoperto

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

È affidabile o sto meglio costruendo un contenitore "nudo" e facendo funzionare le cose manualmente finché non avrò tutto ciò di cui ho bisogno?

Ogni volta che la finestra mobile esegue correttamente un RUNcomando da un file Docker, viene eseguito il commit di un nuovo livello nel file system immagine . Convenientemente puoi usare questi ID di layer come immagini per avviare un nuovo contenitore.

Prendi il seguente Dockerfile:

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

e costruiscilo:

$ 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

È ora possibile avviare un nuovo contenitore da 00f017a8c2a6, 044e1532c690e 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

ovviamente potresti voler avviare una shell per esplorare il filesystem e provare i comandi:

$ 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

Quando uno dei comandi Dockerfile fallisce, quello che devi fare è cercare l' id del livello precedente ed eseguire una shell in un contenitore creato da quell'id:

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

Una volta nel contenitore:

• provare il comando non riuscito e riprodurre il problema
• quindi correggere il comando e testarlo
• infine aggiorna il tuo Dockerfile con il comando fisso

Se hai davvero bisogno di sperimentare il livello effettivo che ha fallito invece di lavorare dall'ultimo livello di lavoro, vedi la risposta di Drew .

La risposta migliore funziona nel caso in cui si desideri esaminare lo stato immediatamente prima del comando non riuscito.

Tuttavia, la domanda chiede come esaminare lo stato del contenitore stesso non riuscito. Nella mia situazione, il comando non riuscito è una build che richiede diverse ore, quindi il riavvolgimento prima del comando non riuscito e l'esecuzione successiva richiede molto tempo e non è molto utile.

La soluzione qui è trovare il contenitore che non è riuscito:

$ 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

Commettilo a un'immagine:

$ docker commit 6934ada98de6
sha256:7015687976a478e0e94b60fa496d319cdf4ec847bcd612aecf869a72336e6b83

E quindi esegui l'immagine [se necessario, eseguendo bash]:

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

Ora stai effettivamente osservando lo stato della build nel momento in cui ha fallito, anziché nel momento prima di eseguire il comando che ha causato l'errore.

Docker memorizza nella cache l'intero stato del filesystem dopo ogni RUNriga corretta .

Sapendo ciò:

• per esaminare l'ultimo stato prima del tuo RUNcomando non riuscito , commentalo nel Dockerfile (così come tutti i RUNcomandi successivi ), quindi esegui docker builde di docker runnuovo.
• per esaminare lo stato dopo il RUNcomando non riuscito , è sufficiente aggiungerlo || trueper forzarlo ad avere successo; quindi procedere come sopra (mantenere RUNcommentati tutti i comandi successivi , eseguirli docker builde docker run)

Tada, non c'è bisogno di scherzare con gli interni Docker o gli ID layer e come bonus Docker minimizza automaticamente la quantità di lavoro che deve essere rifatto.

Il debugging degli errori di step di build è davvero molto fastidioso.

La migliore soluzione che ho trovato è quella di assicurarsi che ogni passaggio che fa il vero lavoro abbia successo, e l'aggiunta di un controllo dopo quelli che falliscono. In questo modo si ottiene un livello di commit che contiene gli output del passaggio non riuscito che è possibile controllare.

Un file Docker, con un esempio dopo la # Run DB2 silent installerriga:

#
# 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

Quello che vorrei fare è commentare il Dockerfile qui sotto e includere la linea offensiva. Quindi è possibile eseguire il contenitore ed eseguire manualmente i comandi della finestra mobile e guardare i registri nel solito modo. Ad esempio, se il file Docker è

RUN foo
RUN bar
RUN baz

ed è morire al bar che vorrei fare

RUN foo
# RUN bar
# RUN baz

Poi

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