Wie kann ich das Dateisystem eines fehlgeschlagenen `docker build` überprüfen?

Question

Ich versuche, ein neues Docker-Image für unseren Entwicklungsprozess zu erstellen, wobei cpanm verwendet wird, um eine Reihe von Perl-Modulen als Basisimage für verschiedene Projekte zu installieren.

Beim Entwickeln des Dockerfiles gibt cpanm einen Fehlercode zurück, weil einige der Module nicht sauber installiert wurden.

Ich bin ziemlich sicher, dass ich apt dazu bringen muss, noch einige Dinge zu installieren.

Wo finde ich das Verzeichnis /.cpanm/work, das in der Ausgabe zitiert wird, um die Protokolle zu überprüfen? Im Allgemeinen, wie kann ich das Dateisystem eines fehlgeschlagenen docker build-Befehls überprüfen?

Nachdem ich ein find ausgeführt habe, habe ich entdeckt

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

Ist das zuverlässig, oder sollte ich besser einen "nackten" Container erstellen und Dinge manuell ausführen, bis ich alles habe, was ich brauche?

Answer 1

In meinem Fall muss ich haben:

DOCKER_BUILDKIT=1 docker build ...

und wie von Jannis Schönleber in seiner Antwort erwähnt, gibt es derzeit kein Debugging verfügbar (d.h. es werden keine Zwischenbilder/-container erstellt).

Was ich herausgefunden habe, dass ich tun könnte, ist die Verwendung der folgenden Option:

... --progress=plain ...

und dann verschiedene RUN ... hinzufügen oder zusätzliche Zeilen zu vorhandenem RUN ... zur Überprüfung spezifischer Befehle. Dies gibt Ihnen, was für mich wie vollen Zugriff scheint (zumindest wenn Ihr Build relativ schnell ist).

Zum Beispiel könnten Sie eine Variable so überprüfen:

RUN echo "Variable NAME = [$NAME]"

Wenn Sie sich fragen, ob eine Datei ordnungsgemäß installiert ist, tun Sie dies:

RUN find /

etc.

In meiner Situation musste ich das Docker-Build eines Go-Anwendungs mit einem privaten Repository debuggen und es war ziemlich schwierig, das Debugging durchzuführen. Weitere Details dazu finden Sie hier.

Answer 2

Das Debuggen von Build-Schrittausfällen ist wirklich sehr ärgerlich.

Die beste Lösung, die ich gefunden habe, besteht darin, sicherzustellen, dass jeder Schritt, der tatsächliche Arbeit leistet, erfolgreich ist, und nach den fehlerhaften Schritten eine Prüfung hinzuzufügen. Auf diese Weise erhalten Sie eine festgelegte Ebene, die die Ausgaben des fehlerhaften Schritts enthält, die Sie überprüfen können.

Ein Dockerfile, mit einem Beispiel nach der Zeile # Run DB2 silent installer:

#
# DB2 10.5 Client Dockerfile (Teil 1)
#
# Erfordert
#   - DB2 10.5 Client für 64bit Linux ibm_data_server_runtime_client_linuxx64_v10.5.tar.gz
#   - Antwortdatei für DB2 10.5 Client für 64bit Linux db2rtcl_nr.rsp 
#
#
# Verwendung des Ubuntu 14.04 Basisimages als Ausgangspunkt.
VON Ubuntu:14.04

MAINTAINER David Carew 

# DB2-Voraussetzungen (Auch das Installation des Sharutils-Pakets, da wir das Dienstprogramm uuencode zur Generierung des Kennworts verwenden - alles andere wird für den DB2-Client benötigt) 
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

# Benutzer db2clnt erstellen
# Starkes zufälliges Kennwort generieren und Sudo zu root ohne Kennwort ermöglichen
#
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 ALLES=(ALLE) NOPASSWD:ALLES' >> /etc/sudoers

# DB2 installieren
RUN mkdir /install
# DB2-Tarball kopieren - Das ADD-Kommando wird es automatisch entpacken
ADD v10.5fp9_linuxx64_rtcl.tar.gz /install/
# Antwortdatei kopieren
COPY  db2rtcl_nr.rsp /install/
# DB2 silent installer ausführen
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 FEHLER-------; echo Installation fehlgeschlagen, siehe Dateien im Container /logs-Verzeichnis der letzten Container-Ebene; echo Führen Sie docker run '' /bin/cat /logs/trace aus; echo ----------)
RUN test -f /install/done

# Unnötige Dateien aufräumen
RUN rm -fr /install/rtcl

# Als Benutzer db2clnt anmelden
CMD su - db2clnt

Answer 3

Wenn Sie docker-compose zum Erstellen von Docker-Images verwenden, versuchen Sie, DOCKER_BUILDKIT=0 vor dem Befehl hinzuzufügen, um die letzte erfolgreiche Layer-ID zu sehen

DOCKER_BUILDKIT=0 docker-compose ... 

Dies deaktiviert vorübergehend DOCKER_BUILDKIT nur für den Befehl.

Wenn Sie die letzte Layer-ID haben, können Sie eine Verbindung dazu herstellen, indem Sie den Befehl aus der obersten Antwort verwenden

docker run --rm -it LAST_LAYER_ID sh

Answer 4

Was ich tun würde, ist das Dockerfile unten zu kommentieren, einschließlich der problematischen Zeile. Anschließend können Sie den Container starten und die Docker-Befehle manuell ausführen und die Protokolle auf die übliche Weise anzeigen. Wenn das Dockerfile zum Beispiel wie folgt aussieht:

RUN foo
RUN bar
RUN baz

und es bei bar abstürzt, würde ich folgendes tun:

RUN foo
# RUN bar
# RUN baz

Dann

$ docker build -t foo .
$ docker run -it foo bash
container# bar
...Protokolle durchsuchen...

Answer 5

Meine Lösung wäre, zu sehen, welcher Schritt im Docker-Datei fehlgeschlagen ist, RUN bundle install in meinem Fall,

und ändere es zu

RUN bundle install || cat 

Dies hat den doppelten Effekt, den Grund für das Versagen auszudrucken, UND dieser Zwischenschritt wird nicht als fehlerhaft von docker build erkannt. daher wird es nicht gelöscht und kann überprüft werden durch:

docker run --rm -it  bash -il

dort können Sie sogar Ihren fehlgeschlagenen Befehl erneut ausführen und ihn live testen.