Ich plane, Docker-Compose für mehrere Knoten zu Docker-Swarm zu verschieben.
Ich habe docker-compose
es wie folgt verwendet:
version: '3'
services:
python:
container_name: python
build: ./python
command: uwsgi --socket :8001 --module myapp.wsgi --py-autoreload 1 --logto /tmp/mylog.log
volumes:
- ./src:/code
- ./src/static:/static
ports:
- "8082:8082"
expose:
- "8001"
nginx:
image: nginx:1.13
container_name: nginx
ports:
- "8000:8000"
volumes:
- ./nginx/conf:/etc/nginx/conf.d
- ./nginx/uwsgi_params:/etc/nginx/uwsgi_params
- ./static:/static
depends_on:
- python
es funktioniert gut für Django-Host.
dann versuche ich jetzt, zu verwenden docker-swarm
.
docker-compose
und docker-swarm
sehen ähnlich aus, aber es gibt eine Frage.
Ich habe die lokalen Laufwerke folgendermaßen gemountet
- ./src:/code
- ./src/static:/static
or here
- ./nginx/conf:/etc/nginx/conf.d
- ./nginx/uwsgi_params:/etc/nginx/uwsgi_params
- ./static:/static
In funktioniert dies jedoch nicht und der Dienst wird nie gestartet docker-swarm
.volumes
(Ich verstehe ... das ist verständlich, da es viele Knoten geben könnte ...)
Ich denke, ich sollte einige Änderungen vornehmen.
Ich habe ein bisschen gegoogelt und herausgefunden, dass es einige Einstellungen wie diese gibt.
services:
python:
volumes:
- src:/code
volumes:
src:
driver: local
Ich verstehe jedoch nicht, wie ich das verwenden soll ...
Wo soll ich meinen Quellcode oder eine Konfigurationsdatei ablegen?
Was ist die beste Vorgehensweise für häufig verwendete Docker-Swarm-Dateien?
Antwort1
Wenn Sie ein Image im Swarm-Modus auf mehreren Knoten bereitstellen, sollte sich der Quellcode in Ihrem Image befinden und dieses Image sollte in ein Register übertragen werden. Das Mounten des Quellcodes als Volume ist eine Methode, um den Entwicklungsprozess zu beschleunigen, aber das zu testende Image sollte mit diesem Quellcode erstellt werden, der mit einem COPY
Befehl in Ihrem Dockerfile enthalten ist, damit es ohne die Volume-Mounts verwendet werden kann.
Daher besteht die Änderung an Ihrer Compose-Datei darin, Image-Namen hinzuzufügen, die auf Ihr eigenes Repository verweisen, vorzugsweise mit versionierten Tags. Und dann verfügt jedes Image über eine Docker-Datei und wird erstellt und in die Registrierung übertragen, bevor der Stack bereitgestellt wird.
Beachten Sie, dass container_name, depends_on und build im Swarm-Modus nicht gültig sind. Sie müssen alle Abhängigkeiten von einem fest codierten Containernamen entfernen (verwenden Sie den Dienstnamen für die DNS-basierte Erkennung). Abhängigkeiten sollten idealerweise von der Anwendung mit einem Konnektivitätstest mit einer Art exponentiellem Backoff bis zu einem Höchstwert behandelt werden oder indem etwas wie das wait-for-it.sh
Skript zum Einstiegspunkt hinzugefügt wird, um zu überprüfen, ob Abhängigkeiten verfügbar sind, bevor die Anwendung gestartet wird. Builds werden normalerweise aus der Compose-Datei in ein CI/CD-System verschoben. Die Compose-Datei erhält dann den aktuellen Tag-Namen als Variable von diesem CI/CD-Tool.
Für persistente Daten würden Sie ein Volume verwenden, das sich jedoch auf einem Netzwerkdateisystem wie NFS und nicht auf dem lokalen Standarddateisystem befinden sollte, wenn die Daten persistent sein sollen, wenn Container zwischen Knoten migrieren. Ein Beispiel hierfür finden Sie inmeine Antwort hier.
Um Daten zwischen Containern in einem Swarm-Cluster zu teilen, wird dies idealerweise mit Netzwerk-APIs durchgeführt (z. B. alle REST-basierten Microservices). Sie können dies auch in eine Datenbank auslagern, die entweder außerhalb von Swarm ausgeführt wird oder für eine Containerumgebung entwickelt wurde (CNCF hat einige davon in seiner Landschaft). Sie könnten dies mit derselben NFS-Lösung und einer Volume-Einbindung tun, aber seien Sie sich bewusst, dass Sie möglicherweise mit Dateisperren und höheren Latenzen zu tun haben.