Docker-Entwicklungs-Workflow für kompilierte Komponenten in einem Docker-Compose-Setup

Question

Ich arbeite an einem Dienst in einem 'System' orchestriert mit Docker-Compose. Der Dienst ist in einer kompilierten Sprache geschrieben und muss neu erstellt werden, wenn ich etwas ändere. Ich versuche den besten Weg zu finden, Änderungen schnell zu iterieren.

Ich habe versucht 2 'Workflows', beide verlassen sich darauf, mit dem Quellverzeichnis über eine volume: verknüpft, um die neueste Quelle zu erhalten.

A.

• Rufen Sie alle Stützbehälter mit docker-compose up -d
• Stoppen Sie den Behälter für den Dienst in der Entwicklung
• einen neuen Container das Bild mit Lauf docker-compose run --name SERVICE --rm SERVICE /bin/bash
• Innerhalb dieses Containers laufen kompiliert und ausgeführt die Anwendung am exponierten Port.
• Starten Sie neu, indem Sie den laufenden Prozess anhalten und dann neu erstellen.

B.

• (erfordert Dockerfile CMD zu bauen und dann den Dienst ausführen)
• Stoppen Sie den Service: docker-compose kill SERVICE
• Starten Sie den Dienst docker-compose up -d --no-deps SERVICE

Das Problem ist sowohl zu lange dauern, um neu zu starten vs den Dienst lokal neu zu starten (läuft auf meinem Laptop unabhängig o f docker). Diese Konfiguration scheint bei interpretierten Sprachen, die geänderte Dateien neu laden können, in Ordnung zu sein, aber ich muss noch ein angemessen schnelles System für kompilierte Sprachdienste finden.

Answer 1

Ich würde dies tun:

Run docker-compose up aber:

• verwenden, um einen Host-Datenträger für das Verzeichnis der kompilierten binären anstelle der Quelle
• ein entrypoint verwenden, die etwas tut, wie

entrypoint.sh:

trap "pkill -f the_binary_name" SIGHUP 
trap "exit" SIGTERM 

while [[ 1 ]]; do 
    ./the_binary_name; 
done 

Schreiben Sie ein Skript das binäre neu zu erstellen, und kopieren Sie sie in das Volumen durch den Dienst in docker-compose.yml verwendet:

# Run a container to compile and build the binary 
docker run -ti -v $SOURCE:/path -v $DEST:/target some_image build_the_binary 

# copy it to the host volume directory 
copy $DEST/... /volume/shared/with/running/container 

# signal the container 
docker kill -s SIGHUP container_name 

So das binäre Sie dieses Skript verwenden zu kompilieren, die die Quelle besteigt und eine Zielverzeichnis als Datenträger. Sie können den Kopierschritt überspringen, wenn $DEST mit dem Volume-Verzeichnis übereinstimmt, das mit dem Container "run" gemeinsam genutzt wird. Schließlich signalisiert das Skript dem laufenden Container, dass es den alten Prozess (der die alte Binärdatei ausgeführt hat) beendet und die neue startet.

Wenn das gemeinsam genutzte Volume die Kompilierung in einem Container zu langsam macht, können Sie auch die Kompilierung auf dem Host ausführen und lediglich die Kopie und die Signalisierung ausführen, damit es in einem Container ausgeführt wird.

Diese Lösung hat den zusätzlichen Vorteil, dass Ihr "Runtime" -Bild nicht alle Dev-Abhängigkeiten benötigt. Es könnte ein sehr mageres Bild mit nur einer bloßen OS-Basis sein.