Comment puis-je inspecter le système de fichiers d'une «construction de docker» qui a échoué?

J'essaie de construire une nouvelle image Docker pour notre processus de développement, en utilisant cpanmpour installer un tas de modules Perl comme image de base pour divers projets.

Lors du développement du Dockerfile, cpanmrenvoie un code d'échec car certains modules ne se sont pas installés correctement.

Je suis assez sûr que je dois aptinstaller d'autres choses.

Ma question est, où puis-je trouver le /.cpanm/workrépertoire cité dans la sortie, afin d'inspecter les journaux? Dans le cas général, comment puis-je inspecter le système de fichiers d'une docker buildcommande ayant échoué ?

Montage du matin Après avoir mordu la balle et exécuté un findje découvre

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

Est-ce fiable, ou est-ce que je ferais mieux de construire un conteneur "nu" et d'exécuter des choses manuellement jusqu'à ce que j'aie tout ce dont j'ai besoin?

Chaque fois que docker exécute avec succès une RUNcommande à partir d'un Dockerfile, une nouvelle couche dans le système de fichiers image est validée . Idéalement, vous pouvez utiliser ces identifiants de calques comme images pour démarrer un nouveau conteneur.

Prenez le Dockerfile suivant:

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

et le construire:

$ 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

Vous pouvez maintenant lancer un nouveau conteneur à partir 00f017a8c2a6, 044e1532c690et 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

bien sûr, vous voudrez peut-être démarrer un shell pour explorer le système de fichiers et essayer les commandes:

$ 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

Lorsque l'une des commandes Dockerfile échoue, ce que vous devez faire est de rechercher l' id de la couche précédente et d'exécuter un shell dans un conteneur créé à partir de cet id:

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

Une fois dans le conteneur:

• essayez la commande qui a échoué et reproduisez le problème
• puis corrigez la commande et testez-la
• enfin mettre à jour votre Dockerfile avec la commande fixed

Si vous avez vraiment besoin d'expérimenter le calque réel qui a échoué au lieu de travailler à partir du dernier calque de travail, voir la réponse de Drew .

La première réponse fonctionne dans le cas où vous souhaitez examiner l'état immédiatement avant l'échec de la commande.

Cependant, la question demande comment examiner l'état du conteneur défaillant lui-même. Dans ma situation, la commande ayant échoué est une génération qui prend plusieurs heures, donc le rembobinage avant la commande qui a échoué et la relancer prend beaucoup de temps et n'est pas très utile.

La solution ici est de trouver le conteneur qui a échoué:

$ 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

Validez-le sur une image:

$ docker commit 6934ada98de6
sha256:7015687976a478e0e94b60fa496d319cdf4ec847bcd612aecf869a72336e6b83

Et puis exécutez l'image [si nécessaire, exécutez bash]:

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

Vous regardez maintenant l'état de la génération au moment où elle a échoué, plutôt qu'au moment avant d'exécuter la commande à l'origine de l'échec.

Docker met en cache l'intégralité de l'état du système de fichiers après chaque RUNligne réussie .

Sachant que:

• pour examiner le dernier état avant votre RUNcommande en échec , commentez-le dans le Dockerfile (ainsi que toutes les RUNcommandes suivantes ), puis exécutez docker buildet docker runrecommencez.
• pour examiner l'état après la RUNcommande défaillante , ajoutez-y simplement || truepour le forcer à réussir; puis procédez comme ci-dessus (laissez toutes les RUNcommandes suivantes commentées, exécutez docker buildet docker run)

Tada, pas besoin de jouer avec les internes de Docker ou les identifiants de couche, et en bonus Docker minimise automatiquement la quantité de travail à refaire.

Le débogage des échecs des étapes de génération est en effet très ennuyeux.

La meilleure solution que j'ai trouvée est de s'assurer que chaque étape qui fait un vrai travail réussit, et en ajoutant une vérification après celles qui échouent. De cette façon, vous obtenez une couche validée qui contient les sorties de l'étape ayant échoué que vous pouvez inspecter.

Un Dockerfile, avec un exemple après la # Run DB2 silent installerligne:

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

Ce que je ferais, c'est commenter le Dockerfile ci-dessous et y compris la ligne incriminée. Ensuite, vous pouvez exécuter le conteneur et exécuter les commandes du docker à la main, et consulter les journaux de la manière habituelle. Par exemple, si le Dockerfile est

RUN foo
RUN bar
RUN baz

et il se meurt au bar je ferais

RUN foo
# RUN bar
# RUN baz

ensuite

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