Docker-Entwicklungsworkflow

Question

Wie sieht der richtige Entwicklungsworkflow für Code aus, der in einem Docker-Container ausgeführt wird?

Solomon Hykes said dass der "offizielle" Arbeitsablauf das Erstellen und Ausführen eines neuen Docker-Images für jedes Git-Commit beinhaltet. Das macht Sinn, aber was ist, wenn ich eine Änderung testen möchte, bevor ich sie an das Git Repo verpfände?

Ich denke an zwei Möglichkeiten, es zu tun:

1. auf einem lokalen Entwicklungsserver den Code ausführen (zum Beispiel des Django-Entwicklungsserver). Bearbeiten Sie eine Datei. Test auf dem Dev-Server; Mach ein Git commit; Erstellen Sie das Docker-Image mit dem neuen Code neu. Testen Sie erneut den lokalen Docker-Container.

2. Führen Sie keinen lokalen Dev-Server aus. Erstellen und erstellen Sie stattdessen jedes Mal ein neues Docker-Image, wenn Sie eine Datei bearbeiten, und testen Sie dann die Änderung am lokalen Docker-Container.

Beide Ansätze sind ziemlich ineffizient. Gibt es einen besseren Weg?

Answer 1

Ein effizienterer Weg besteht darin, einen neuen Container mit dem neuesten Image auszuführen (das dann den neuesten Code enthält).

Sie könnten diesen Container Starten einer Bash-Shell starten, so dass Sie in der Lage sein wird, Dateien zu bearbeiten aus dem Inneren des Behälters:

docker run -it <some image> bash -l 

Sie würde die Anwendung in diesem Container führen Sie dann den neuen Code zu testen.

Eine weitere Möglichkeit, Dateien in diesem Container zu ändern, besteht darin, sie mit einem Volume zu starten. Die Idee ist, Dateien in einem Verzeichnis auf dem Docker Host zu ändern, anstatt mit Dateien von der Kommandozeile aus dem Behälter aus Messing selbst:

docker run -it -v /home/joe/tmp:/data <some image> 

Jede Datei, die Sie in /home/joe/tmp auf Ihrem Docker Host gestellt werden wird unter zur Verfügung steht /data/ im Container. Ändern Sie /data auf den für Ihren Fall geeigneten Pfad und hacken Sie ihn weg.