Dockerfile-Strategien für Git

Sie haben im Allgemeinen zwei Ansätze:

• Verweisen auf einen Tresor, wo Sie Ihre geheimen Daten erhalten, die notwendig sind, um auf das zuzugreifen, was Sie in Ihr Image einfügen müssen (hier Ihre ssh-Schlüssel, um auf Ihr privates Repo zuzugreifen)

Update 2018: Siehe " So bewahren Sie Ihre Container-Geheimnisse auf ", einschließlich:

  

• Verwenden Sie Datenträgerbereitstellungen, um zur Laufzeit Geheimnisse an einen Container zu übergeben
  
• Habe einen Plan für rotierende Geheimnisse
  
• Stellen Sie sicher, dass Ihre Geheimnisse verschlüsselt sind
  

• oder eine Squash-Technik (nicht empfohlen, siehe Kommentar)

Für den zweiten Ansatz siehe " Ziehen Greifen Sie in ein Docker-Image, ohne SSH-Schlüssel zu hinterlassen "

  

• Fügen Sie den privaten Schlüssel der Dockerdatei
hinzu   
• Fügen Sie es dem ssh-agent
hinzu   
• Führen Sie die Befehle aus, die eine SSH-Authentifizierung erfordern
  
• Entfernen Sie den privaten Schlüssel
  

Dockerfile:

  

Lass uns jetzt das Bild erstellen:

• Komprimiere die Ebenen:

  %Vor%

Ich werde teilen, was ich bisher gefunden habe.

Es gibt verschiedene Strategien, um Ihren Git-Quellcode in einen Docker-Build zu bringen. Viele davon haben unterschiedliche Möglichkeiten, mit den Caching-Mechanismen von Docker zu interagieren und sind mehr oder weniger passend für Ihr Projekt geeignet und wie Sie Docker verwenden möchten.

RUN git Klon

Wenn Sie wie ich sind, ist dies der Ansatz, der Ihnen zuerst in den Sinn kommt, wenn Sie die Befehle sehen, die Ihnen in einer Dockerfile zur Verfügung stehen. Das Problem dabei ist, dass es auf verschiedene nicht intuitive Weise mit den Caching-Mechanismen von Docker interagieren kann. Wenn Sie beispielsweise ein Update für Ihr Git-Repository durchführen und anschließend das Docker-Build mit dem Befehl RUN git clone erneut ausführen, erhalten Sie möglicherweise die neuen Commits, je nachdem, ob die vorhergehenden Dockerfile-Befehle ungültig geworden sind der Cache.

Eine Möglichkeit, dies zu umgehen, ist die Verwendung von docker build --no-cache , aber wenn vor dem Klon zeitintensive Befehle vorhanden sind, müssen sie auch erneut ausgeführt werden.

Ein weiteres Problem besteht darin, dass Sie (oder jemand, dem Sie Ihre Docker-Datei verteilt haben) unerwartet zu einem fehlerhaften Build zurückkehren, wenn das Upstream-Git-Repository aktualisiert wird.

Ein Zwei-Vögel-Ein-Stein-Ansatz dafür, während der RUN-Git-Klon weiterhin verwendet wird, besteht darin, ihn in eine Zeile1 mit einem bestimmten Revisionskonto zu stellen, z.B.:

Wenn Sie dann die Revision aktualisieren, um sie in der Dockerdatei auszuchecken, wird der Cache in dieser Zeile ungültig und der Clone / Checkout wird ausgeführt.

Ein möglicher Nachteil dieses Ansatzes ist, dass git in Ihrem Container installiert sein muss.

RUN curl oder ADD ein Tag / commit tarball URL

Dies verhindert, dass git in Ihrer Container-Umgebung installiert sein muss, und kann davon profitieren, wenn der Cache bricht (d. h. wenn das Tag / die Revision Teil der URL ist, wird diese URL den Cache zerstören). Beachten Sie Folgendes: Wenn Sie den Dockerfile ADD-Befehl zum Kopieren von einer Remote-URL verwenden, wird die Datei jedes Mal heruntergeladen, wenn Sie den Build ausführen, und der Header HTTP Last-Modified wird auch zum Ungültigmachen des Caches verwendet.

Sie können diesen Ansatz in der golang Dockerfile sehen.

Git Submodule im Dockerfile Repository

Wenn Sie Ihre Dockerfile und Docker in einem separaten Repository aus Ihrem Quellcode erstellen oder wenn Ihr Docker-Build mehrere Quellrepositorys benötigt, kann die Verwendung von git-Submodulen (oder Git-Subtrees) in diesem Repository eine gute Möglichkeit sein, Ihre Quell-Repos zu erhalten in Ihren Build-Kontext. Dies verhindert einige Probleme beim Docker-Caching und Upstream-Update, da Sie die Upstream-Revision in Ihrer Submodul- / Teilbaumspezifikation sperren. Wenn Sie sie aktualisieren, wird der Docker-Cache beim Ändern des Erstellungskontexts beschädigt.

Beachten Sie, dass damit nur die Dateien in Ihren Docker-Build-Kontext gelangen. Sie müssen ADD-Befehle in Ihrer Docker-Datei verwenden, um diese Pfade dorthin zu kopieren, wo Sie sie im Container erwarten.

Sie können diesen Ansatz in hier

Dockerfile im git-Repository

Hier haben Sie Ihre Dockerfile im selben git-Repository neben dem Code, den Sie erstellen / testen / bereitstellen möchten, sodass sie automatisch als Teil des Build-Kontexts gesendet wird, sodass Sie z. HINZUFÜGEN . / Projekt, um den Kontext in den Container zu kopieren. Der Vorteil besteht darin, dass Sie Änderungen testen können, ohne sie zu committen / pushen, um sie in einen Test Docker Build zu bringen; Der Nachteil ist, dass jedes Mal, wenn Sie Dateien in Ihrem Arbeitsverzeichnis ändern, der Cache beim Befehl ADD ungültig wird. Das Senden des Buildkontexts für ein großes Quell- / Datenverzeichnis kann ebenfalls zeitaufwendig sein. Wenn Sie diesen Ansatz verwenden, sollten Sie auch die .dockerignore-Datei Dinge wie Ignorieren alles in Ihrem .gitignore und möglicherweise das .git-Verzeichnis selbst.

Volume-Zuordnung

Wenn Sie Docker verwenden, um eine Entwicklungs- / Testumgebung einzurichten, die Sie für eine Vielzahl von Quell-Repos auf Ihrem Host-Computer freigeben möchten, das Anhängen eines Host-Verzeichnisses als Datenvolumen kann eine praktikable Strategie sein. Auf diese Weise können Sie angeben, welche Verzeichnisse bei der Docker-Laufzeit berücksichtigt werden sollen, und Bedenken hinsichtlich des Zwischenspeicherns von Docker-Caches vermeiden. Dies wird jedoch nicht von anderen Benutzern Ihrer Docker-Datei oder Ihres Container-Image übernommen.

-

Referenzen:

• " Git Strategien für Docker " Ryan Baumann - / etc (blog), 29 Jul 2015