Moby: „docker stack deploy“ in 1.13 lädt keine „.env“-Datei wie „docker-compose up“.

Erstellt am 5. Dez. 2016  ·  93Kommentare  ·  Quelle: moby/moby

Um die Funktion docker stack deploy --compose-file zu testen, lade ich eines meiner Beispiele docker-compose.yml :

version: '3'
services:
    nginx:
        image: "${DOCKER_USER}/lnmp-nginx:v1.2"
        build:
            context: .
            dockerfile: Dockerfile.nginx
        ports:
            - "80:80"
        networks:
            - frontend
        depends_on:
            - php
    php:
        image: "${DOCKER_USER}/lnmp-php:v1.2"
        build:
            context: .
            dockerfile: Dockerfile.php
        networks:
            - frontend
            - backend
        environment:
            MYSQL_PASSWORD: Passw0rd
        depends_on:
            - mysql
    mysql:
        image: mysql:5.7
        volumes:
            - mysql-data:/var/lib/mysql
        environment:
            TZ: 'Asia/Shanghai'
            MYSQL_ROOT_PASSWORD: Passw0rd
        command: ['mysqld', '--character-set-server=utf8']
        networks:
            - backend
volumes:
    mysql-data:

networks:
    frontend:
    backend:

Im Abschnitt image der Dienste nginx und php habe ich ${DOCKER_USER} verwendet, um die Docker-ID aus Umgebungsvariablen abzurufen. Und wenn ich docker-compose up verwende, wird die Datei .env als Standard-envvar-Dateien geladen, deren Inhalt ist:

DOCKER_USER=twang2218

Wenn ich jedoch docker stack verwende, um dieses docker-compose.yml , erhalte ich folgende Fehler:

$ docker stack deploy --compose-file docker-compose.yml lnmp
Ignoring unsupported options: build

Creating network lnmp_frontend
Creating network lnmp_backend
Creating network lnmp_default
Creating service lnmp_php
Error response from daemon: rpc error: code = 3 desc = ContainerSpec: "/lnmp-php:v1.2" is not a valid repository/tag

Wie Sie sehen, wurde ${DOCKER_USER} durch eine leere Zeichenfolge ersetzt, da der Befehl docker stack deploy $ die Datei .env nicht geladen hat, wodurch der Bildname ungültig wurde.

Wenn die Datei .env geladen wurde, sollte der endgültige Bildname twang2218/lnmp-php:v1.2 lauten.

Die Umgebungsersetzung funktioniert tatsächlich, wenn ich den Befehl folgendermaßen ausführe:

$ DOCKER_USER=twang2218 docker stack deploy --compose-file docker-compose.yml lnmp
Ignoring unsupported options: build

Creating network lnmp_frontend
Creating network lnmp_backend
Creating network lnmp_default
Creating service lnmp_mysql
Creating service lnmp_nginx
Creating service lnmp_php

Und wir können mit dem Befehl docker service inspect überprüfen, ob es funktioniert:

$ docker service inspect lnmp_php | grep Image
                    "Image": "twang2218/lnmp-php:v1.2<strong i="13">@sha256</strong>:4f1aef1350aeef3f757f6b6da8f2e1a79ff849f61382320e4b668bfe2b0d1c5a",

Der Bildname ist twang2218/lnmp-php:v1.2 , was korrekt ist.

Ich habe diese Funktion auf dem Droplet Digtial Ocean getestet, das Docker 1.13.0-rc2 über docker-machine installiert hat.

Hier ist die Fassung:

$ docker version
Client:
 Version:      1.13.0-rc2
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   1f9b3ef
 Built:        Wed Nov 23 06:32:39 2016
 OS/Arch:      linux/amd64

Server:
 Version:             1.13.0-rc2
 API version:         1.25
 Minimum API version: 1.12
 Go version:          go1.7.3
 Git commit:          1f9b3ef
 Built:               Wed Nov 23 06:32:39 2016
 OS/Arch:             linux/amd64
 Experimental:        false

Hier ist die docker info :

root<strong i="25">@d1</strong>:~/docker-lnmp# docker info
Containers: 7
 Running: 1
 Paused: 0
 Stopped: 6
Images: 4
Server Version: 1.13.0-rc2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 43
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: active
 NodeID: vyf3mgcj3uonrnh5xxquasp38
 Is Manager: true
 ClusterID: jb8rxvd6ptrn3psfkiixxed7r
 Managers: 1
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 138.197.195.206
 Manager Addresses:
  138.197.195.206:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 51371867a01c467f08af739783b8beafc154c4d7
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-51-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 488.5 MiB
Name: d1
ID: E6UB:PHX6:I2KY:Q35T:PCCI:MFDQ:ZMMN:2X7K:DEOZ:PAP7:4BUC:FP6X
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 provider=digitalocean
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
arestack areswarm kinenhancement

Hilfreichster Kommentar

@whoan Ich verwende dies als Problemumgehung:

env $(cat .env | grep ^[A-Z] | xargs) docker stack deploy --compose-file docker-compose.yml [STACK_NAME]

Auf diese Weise bleiben Variablen nicht im Terminalfenster hängen

Alle 93 Kommentare

Dies ist beabsichtigt. Die .env -Unterstützung ist eine Funktion von Compose, nicht des Dateiformats.

Wir können diskutieren, dies für eine zukünftige Version hinzuzufügen, aber ich weiß nicht, ob es wirklich die beste Option ist.

Die .env -Unterstützung ist in Compose sehr nützlich, wir haben sie in vielen unserer Compose-Dateien verwendet. Es trennt dynamische Teile und statische Teile der Datei docker-compose.yml . Mit Load .env können wir standardmäßig einfach verschiedene .env -Dateien für verschiedene Umgebungen bereitstellen und docker-compose.yml und zugehörige Skripte statisch halten.

Es ist nicht möglich, env_file oder environment in docker-compose.yml zu verwenden, um dasselbe envvars-Substitutionsergebnis zu erzielen. .env ist der einfachste Weg, dies zu tun.

Andernfalls müssen wir jeder Zeile der Datei .env export voranstellen und jedes Mal manuell source .env vor dem Laden der docker-compose.yml , und die zusätzlichen Schritte sind manchmal anfällig einen Fehler machen.

Das ist mir gerade aufgefallen.
Ich habe angenommen/erwartet, dass es genauso funktioniert wie bei Compose, aber das ist bei docker deploy nicht der Fall.

In meinem speziellen Fall hatte ich erwartet, die Datei .env zu verwenden, um vertrauliche Daten (Passwörter, API-Schlüssel usw.) zu speichern, die in den Diensten verwendet werden, die ich im Stack erstellen werde:

version: '3'

volumes:
  data:
    driver: local

networks:
  backend:
    driver: overlay

services:
  rabbitmq:
    image: rabbitmq:${EXCHANGE_RABBITMQ_TAG}
    volumes: [ "data:/var/lib/rabbitmq" ]
    logging: { driver: gelf, options: { gelf-address: "udp://0.0.0.0:12201" } }
    networks: [ "backend" ]
    ports: [ "15672:15672", "5672:5672" ]
    environment:
      RABBITMQ_DEFAULT_USER: ${EXCHANGE_RABBITMQ_USER}
      RABBITMQ_DEFAULT_PASS: ${EXCHANGE_RABBITMQ_PASS}
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.labels.queue-host == true

Während diese Compose-Datei in Git eingecheckt wird, wird die .env -Datei ignoriert.

Ich habe den ganzen Kram/die Geschichte der *.dab vs. Compose-Dateien verfolgt, und ich habe das Gefühl, dass Sie versuchen, etwas zu vermeiden – oder eine bessere Lösung vorschlagen –, aber ich habe den Überblick über die ganze Diskussion verloren …

Hallo alle,

Docker-Version: v1.13.0-rc4

Ich erhalte eine Fehlermeldung: Ignoriere nicht unterstützte Optionen: build . Bedeutet dies, dass keine Builds aus Dockerfile erstellt werden?

Und es wird auch derselbe Fehler für network_mode angezeigt: Ignorieren nicht unterstützter Optionen: network_mode.

Unten ist Befehl:
DOCKER_IMAGE=akhil123 docker stack deploy -c docker-compose.yml foo

Vielen Dank im Voraus.

@akhildangore bitte kommentiere keine Probleme mit Fragen, die nicht direkt damit zusammenhängen. Die Funktion docker stack deploy , _by design_ führt keine Builds durch. Der Grund dafür ist, dass auf dem Host, von dem aus der Befehl ausgeführt wird, ein _Build_ ausgeführt wird, sodass das Image nur auf _diesem_ Knoten verfügbar ist. Wenn Sie dieses Image in einem Swarm bereitstellen, kann der Dienst nicht auf anderen Knoten gestartet werden. Stellen Sie zum Bereitstellen von Diensten sicher, dass das bereitgestellte Image in eine Registrierung übertragen wird (oder stellen Sie zum Testen sicher, dass das Image auf jedem Knoten im Schwarm verfügbar ist).

Gibt es Fälle/Diskussionen für/gegen die Unterstützung dieses Verhaltens auf docker deploy ?

@vovimayhem Es wurde noch keine Entscheidung über die Datei .env getroffen, aber Sie könnten an https://github.com/docker/docker/pull/30144 interessiert sein, das der Compose-Datei Unterstützung für Geheimnisse hinzufügt

Ich habe gerade diese Diskussion gefunden. Exzellent!

Ich verwende eine Bash-Funktion als Workaround.

Sie können es an Ihre Bedürfnisse anpassen, bis das Feature secrets veröffentlicht wird:

dsd() {
    stack=${1:-${PWD##*/}} # by default, the name of the cointaining folder
    compose_file=${2:-docker-compose.yml}

    if [ ! -f $compose_file ]; then
        echo "Misses compose file: $compose_file" >&2
        return 1
    fi

    # execute as a subcommand in order to avoid the variables remain set
    (
        # export variables excluding comments
        [ -f .env ] && export $(sed '/^#/d' .env)

        # Use dsd your_stack your_compose_file to override the defaults
        docker stack deploy --compose-file $compose_file $stack
    )
}

Für diejenigen, die diese Ausgabe abonnieren; Secrets-Unterstützung für Docker-Compose-Dateien wird in der Version 1.13.1 enthalten sein, die nicht allzu weit in der Zukunft liegen sollte

@whoan Ich verwende dies als Problemumgehung:

env $(cat .env | grep ^[A-Z] | xargs) docker stack deploy --compose-file docker-compose.yml [STACK_NAME]

Auf diese Weise bleiben Variablen nicht im Terminalfenster hängen

Es ist immer schön, Dinge aus einer .env -Datei laden zu können – abgesehen von einem einfacheren Anwendungsfall für Docker-Geheimnisse, der jetzt umgangen werden kann, gibt es immer Docker-Compose-Werte, die Sie nicht hartcodiert haben möchten in deinem Repo.

Angenommen, Sie verwenden docker stack deploy , um einen vollständigen Stack bereitzustellen, und Sie haben die folgenden Anforderungen:

  • Sie möchten genau dieselbe Konfiguration für verschiedene Umgebungen verwenden, z. B. Staging und Produktion

    • Sie müssen für jede Umgebung unterschiedliche Skalierungswerte haben

Wenn Sie dies nicht mit einer .env -Datei konfigurieren können, müssen Sie die docker-compose.yml -Datei jedes Mal manuell ändern, bevor Sie den Stack bereitstellen, da sonst der Dienstskalierungswert wieder auf 1 zurückgesetzt wird.

Sie können das Obige mit Dingen wie Netzwerken erweitern, das DNS konfigurieren, auf das ein Dienst lauschen soll, usw.

Ich kann einen PR entwerfen, der eine .env -Datei lädt, wenn eine im selben Verzeichnis wie docker-compose.yml existiert, wenn wir der Meinung sind, dass die oben genannten Anwendungsfälle sinnvoll sind.

Das Design von docker stack deploy unterscheidet sich etwas von docker-compose Befehlen. Ich denke nicht, dass es sinnvoll ist, standardmäßig nur ein .env zu lesen. Nicht einmal docker-compse.yml wird standardmäßig gelesen, da die standardmäßige Deployment-Quelle in Zukunft wahrscheinlich etwas anderes sein wird.

Sie können immer selbst eine .env -Datei beziehen, bevor Sie stack deploy .

Nur . .env vor dem Aufruf docker stack deploy hilft nicht, $Variablen werden nicht ersetzt. Nur env .. xargs Trick hat geholfen.
Es wäre schön, die Option --env-file=FILE wie in docker run zu haben.

Gerade . .env vor dem Aufrufen von Docker Stack Deploy hilft nicht

Dies sollte @C-Pro helfen - Sie müssen export ... Zeilen in Ihrer .env Datei haben. Alternativ können Sie export $(cat .env) verwenden, was in den meisten Fällen funktionieren würde.

Hallo alle,
Heute habe ich versucht, docker stack deploy auszuführen.
Meine docker-compose.yml -Datei:

version: '3'
services:
  simple:
    image: alpine
    environment:
      - FOO: ${BAR}
    env_file: .env

Und .env Datei im selben Verzeichnis:

BAR=worked

Nach dem Start docker stack deploy -c docker-compose.yml test habe ich den Container inspiziert und Folgendes erhalten:

$ env
BAR=worked
FOO=
...

Scheint, dass .env im Container bereitgestellt, aber nicht auf dem Hostcomputer bereitgestellt werden.
Das bedeutet, dass ich die Datei .env anstelle des Abschnitts environment verwenden kann, aber ich kann die Datei .env nicht mit Variablensubstitution verwenden.
Docker-Version: v17.03

@ddpaimon
Umgebung:
- FOO=${BAR}

Es sieht so aus, als ob diese .env-Datei nur für Container funktioniert, aber nicht für die Ersetzung der Dateivariablen docker-compose.yml.

Docker für MAC, Docker-Version 17.03.1-ce, Build c6d412e

@realcbb
Ja. Aber um .env -Dateivariablen innerhalb des Containers zu verwenden, müssen Sie sie im Abschnitt environment entfernen.
Beispielsweise:
docker-compose.yml

...
environment:
  - FOO=${FOO:-empty}
...

.env

FOO=filled

Im Container habe ich das bekommen:

$ env
FOO=empty

Aber wenn ich FOO aus dem Abschnitt environment in docker-compose.yml entferne, bekomme ich Folgendes:

$ env
FOO=filled

@ddpaimon
In der Umgebung angegebene Umgebungsvariablen überschreiben diese in der .env-Datei angegebenen Werte.

@dnephin : Sie geben an, dass .env nicht Teil des Docker-Compose-Dateiformats ist. Die .env-Dateifunktion ist jedoch in der Referenz zu Compose-Datei Version 3 dokumentiert: https://docs.docker.com/compose/compose-file/#variable -substitution .
Dies erweckt den Eindruck, dass .env auch mit Docker-Stack-Deployment funktionieren sollte.
Abgesehen davon ist, wie bereits von anderen erwähnt, das Trennen der tatsächlichen umgebungsspezifischen Werte von der Stack-Definition yaml eine dringend gewünschte / benötigte Funktion. Insbesondere möchten wir es verwenden, um Image-Versionen und Replikationen anzugeben.

Danke, ich habe https://github.com/docker/docker.github.io/issues/3654 geöffnet, um die Dokumente zu reparieren

docker stack deploy kann eine generierte Datei aufnehmen. Dies funktioniert in Bash für alle meine Variablen und hält auch Geheimnisse geheim:

docker stack deploy --with-registry-auth --compose-file=<(ENV1=value1 ENV2=value2 docker-compose -f docker-compose.yaml -f docker-compose.override.yaml -f third-sample-compose.yaml config) stack-name

Bitte beachten Sie, dass ich die Inline-ENV-Variablen als zusätzliche oder Überschreibungen hinzugefügt habe. Meine Compose-Dateien verweisen auf .env-Dateien und das funktioniert. Hoffe, das ist hilfreich 👍

Die Funktionalität von docker-compose config verbindet dies.

Ich bin auf dieses Problem gestoßen, als ich nach einer Lösung dafür gesucht habe, dass mein .env nicht von docker stack deploy eingelesen wird. Ich war etwas überrascht zu sehen, dass es nicht unterstützt wurde (Dokumente könnten geklärt werden), möchte aber meine Unterstützung für .env hinzufügen, wie z. B. compose.

Mein Anwendungsfall ist, dass ich docker stack deploy in Entwicklungs-, Test- und Staging-Umgebungen verwende und Umgebungsvariablen für Stack-Optionen verwende, um die yml-Datei gleich zu halten.

Verwenden Sie derzeit eine der hier veröffentlichten Problemumgehungen, aber die Verwendung einer .env -Datei wäre die bevorzugte Route.

Nur eine freundliche Erinnerung: Es besteht die Möglichkeit, dass Sie versuchen, dotenv-Dateien zu verwenden, um API-Schlüssel, Passwörter und andere Dinge zu speichern, die als "sensibel" gelten, um sie in den Cluster zu stellen. Für diese Fälle sollten Sie Docker Secrets verwenden.

Kann ich für andere Dinge vorschlagen, eine Compose-Datei pro bereitgestellter/bereitstellbarer Umgebung zu haben? Das meiste, was sich zwischen verschiedenen Umgebungen ändert, sind die verfügbaren Server, die unterschiedliche Serverorganisation usw. und daher werden unterschiedliche Werte für die deploy -Schlüsselinhalte benötigt ( placement -Regeln, resources Reservierungen usw.), was die Verwendung einer einzigen Datei für alles etwas zu kompliziert macht.

Eigentlich möchte ich diese Funktion, Variablen in der Compose-Datei können auf verschiedenen Hosts als unterschiedliche Werte behandelt werden, wenn Docker-Stack-Bereitstellung verwendet wird.

„Darf ich für andere Dinge vorschlagen, eine Compose-Datei pro bereitgestellter/bereitstellbarer Umgebung zu haben? Die meisten Dinge, die sich zwischen verschiedenen Umgebungen ändern, sind die verfügbaren Server, die unterschiedliche Serverorganisation usw. und benötigen daher unterschiedliche Werte für den Bereitstellungsschlüssel Inhalte (Platzierungsregeln, Ressourcenreservierungen usw.), was die Verwendung einer einzigen Datei für alles etwas zu kompliziert macht."

@vovimayhem Tut mir leid, offen zu sein, aber das macht nicht annähernd so viel Sinn wie die Verwendung einer einzelnen Compose-Datei mit Variablenersetzung mit einer env_file. Ich würde es vorziehen, das env_file-Format zu verwenden, da dies es mir auch viel einfacher macht, meinen Kunden Stacks als Liefergegenstand bereitzustellen und sie darin zu schulen, einzelne Vars-Dateien im ini-Stil zu aktualisieren, als mit einer Compose-Datei herumzuspielen (was ich NICHT Ich will).

Dienstkonfigurationen sind eine großartige Ergänzung, aber sie scheinen nicht für die Interpolation der Bereitstellungszeit verwendbar zu sein (z. B. $TAG).

Wenn Umgebungsvariablen überhaupt unterstützt werden, dann seien Sie konsistent in den Mechanismen, die verwendet werden, um sie über Tools hinweg aufzulösen. Die Stack-Bereitstellung scheint sich dafür zu entscheiden, inkonsistent zu sein, ohne das Verhalten von Umgebungsvariablen grundlegend zu ändern. Geheimnisse und Dienstkonfigurationen sind bessere Alternativen zu einigen Verwendungen von Umgebungsvariablen, aber sie werden nicht subsumiert.

Du scheinst es nicht zu verstehen @vovimayhem. Ich spreche nicht davon, Envs an Container zu übergeben; das funktioniert wie erwartet. Was ich meine, ist die Verwendung einer env_file, die während stack deploy genauso geparst wird wie während compose up .

@ntwrkguru Ich dachte nur, diese neue Funktion würde dir helfen ... Ich bin so traurig, dass es das nicht tut.

Dies funktioniert immer noch als Alternative;

$ echo 'BAR=worked' > ./.env

$ export $(cat .env) && docker stack deploy testing -c -<<'EOF'
version: '3'
services:
  simple:
    image: nginx:alpine
    environment:
      FOO: ${BAR}
    env_file: .env
EOF

$ docker inspect testing_simple -f '{{json .Spec.TaskTemplate.ContainerSpec.Env}}'
["BAR=worked","FOO=worked"]

@thaJeztah , in der Tat. Ich habe eine Aufgabe in meinem Playbook, um eine Umgebungsdatei zu beschaffen, aber das fehlt der größere Punkt. Dies war früher mit compose möglich und ist jetzt mit stack nicht mehr möglich. IMO, das ist eine Regression. Außerdem übergeben Sie in Ihrem Beispiel immer noch eine Umgebungsvariable an den Container. Das kann ich heute mit den env_files machen; das Problem ist das Analysieren von env_file während der Operation stack deploy -c docker-compose.yml .

Dies ist besonders schmerzhaft, da stack mehrere Compose-Dateien nicht mehr unterstützt, andernfalls könnte man einfach eine sekundäre Compose-Datei pro Umgebung verwenden. Um dies auf diese Weise zu tun, muss man die Stack-Datei aus den Compose-Dateien erstellen, was einen weiteren Schritt einleitet. So oder so, wie Sie es sehen, sind wir von einem einstufigen Prozess zu einem mehrstufigen Prozess übergegangen, um das gleiche Endergebnis zu erzielen.

Außerdem, FWIW, das configs ist meiner Erfahrung nach für tatsächliche Konfigurationen wirklich unterdurchschnittlich. Ich stellte mir vor (hoffte), dass ich /application/config.conf in der Quelle haben könnte. Aktualisieren Sie diese Datei, Commit, Push und CI würde den Stack mit der neuen Konfiguration erneut bereitstellen. Das ist ohne Hackerangriffe zum Ändern des Dateinamens oder eines anderen Mechanismus nicht möglich. Sicherlich können wir zumindest die Datei prüfen oder nach Inhaltsänderungen suchen und basierend auf der Datei selbst aktualisieren? Alles in allem sieht es so aus, als würden wir rückwärts gehen. Werfen Sie jetzt die Unterstützung für K8s ein und ich frage mich, ob der Schwarm nur an der Rebe schmachten wird, bis er genug Nutzung verliert, um leise fallen gelassen zu werden.

Außerdem, FWIW, die Konfigurationen sind meiner Erfahrung nach wirklich unterdurchschnittlich für tatsächliche Konfigurationen. Ich stellte mir vor (hoffte), dass ich /application/config.conf im Quellcode haben könnte. Aktualisieren Sie diese Datei, Commit, Push und CI würde den Stack mit der neuen Konfiguration erneut bereitstellen. Das ist ohne Hackerangriffe zum Ändern des Dateinamens oder eines anderen Mechanismus nicht möglich.

@ntwrkguru Die einfache Problemumgehung besteht darin, nicht den Dateinamen, sondern den Namen der Konfiguration selbst zu ändern. Ich habe ein Versionsschema für meine Konfigurationsnamen verwendet, zB config_v1 , config_v2 , ..

Denken Sie also daran, diese Version nach dem Ändern der Konfigurationsdatei zu aktualisieren.

services:
  app:
    [...]
    configs:
      - source: config_v2
      - target: /config.yml

configs:
  config_v2:
    file: ./config.yml

Ich verstehe die Gründe dafür, noch keine versionierten Konfigurationen und Geheimnisse zu haben, also bin ich persönlich mit dieser (einfachen) Problemumgehung derzeit einverstanden.

Danke @djmaze , aber das ist letztendlich eine lächerliche Sache, die man tun muss, wenn in jedes Quellcodeverwaltungssystem eine inhärente Versionsverfolgung integriert ist. Auch danke für den Link; Dort habe ich auch kommentiert. Ich verstehe nicht, warum sich Docker um die andere Version als die aktuelle kümmert. Der einzige Grund, warum ich sehen könnte, dass es notwendig ist, diese zu versionieren, ist das Rollback, aber es müssen sowieso Tonnen von Dingen nachverfolgt werden, also was sind ein paar mehr? (sagt der Typ, der den Code nicht schreiben muss) :-)

Versuche dies:
echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

Es verwendet docker-compose, um die Konfigurationsdatei zu analysieren, env vars zu ersetzen, Warnungen aus der Ausgabe zu entfernen und sie dann über stdin an den docker stack deploy weiterzuleiten.
Ersetzen Sie „-f stack.yml“ durch den Namen Ihrer Konfigurationsdatei oder lassen Sie ihn weg, um die Standarddatei „docker-compose.yml“ zu verwenden.

+1

Ein Jahr später müssen wir das immer noch hacken, damit es funktioniert. Ab 17.09.1 ​​ersetzt docker stack deploy -f compose.yml nicht einmal die Verwendung bekannter Shell-Variablen.

$ printenv | grep PORTAINER
PORTAINER_VER=1.14.3
portainer:
    image: "portainer/portainer:${PORTAINER_VER}"
$ sudo docker stack deploy -c /tmp/docker/jedi-core.yml --with-registry-auth --prune --resolve-image always jedi-core
Updating service jedi-core_redis_server (id: 0csjyandro713y13ncitk6c0k)
Updating service jedi-core_api-gateway (id: gzcz2eturuxqkjojsc9e6954l)
Updating service jedi-core_auto_results_api (id: tw43c6e0x98q6f0m2g0zttwhf)
Updating service jedi-core_auto_results_api_mongo (id: qpwpypyzd9aigpa71xgxxdzcp)
invalid reference format

Alle Variablen für Tags erzeugen invalid reference format .

Ein Jahr später müssen wir das immer noch hacken, damit es funktioniert. Ab 17.09.1 ​​wird docker stack deploy -f compose.yml nicht einmal die Verwendung bekannter Shell-Variablen ersetzen.

siehe So behalten Sie Umgebungsvariablen bei der Verwendung von SUDO bei

$ export PORTAINER_VER=1.14.3
$ printenv | grep PORTAINER
PORTAINER_VER=1.14.3

$ sudo printenv | grep PORTAINER

$ sudo -E printenv | grep PORTAINER
PORTAINER_VER=1.14.3


$ cat > docker-compose.yml <<'EOF'
version: '3'
services:
  portainer:
    image: "portainer/portainer:${PORTAINER_VER}"
EOF


$ sudo -E docker stack deploy -c docker-compose.yml foobar
Creating network foobar_default
Creating service foobar_portainer

$ sudo docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                        PORTS
vt4h0g8yygcg        foobar_portainer    replicated          1/1                 portainer/portainer:1.14.3   

Danke, aber irgendein Wort zur einfachen Unterstützung der Variablenersetzung aus einer Datei?

[Bearbeiten] Dies sollte kein Problem sein (könnte es aber sein), da ich Ansible verwende, um die Aufgabe mit become: yes auszuführen, aber der Benutzer ist immer noch derselbe Benutzer, der die Umgebungsvariablen bezieht.

Ich kann nicht glauben, dass das nicht möglich ist. Wir möchten eine einzelne Stapeldatei behalten und die Bereitstellungsoptionen mithilfe dynamischer Variablen ändern können.

Das würde funktionieren, ist aber hässlich und ein Hack:

echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

Ich habe viele Stunden damit herumgespielt und es sieht so aus, als ob ich im Hintergrund Skriptarbeit machen würde (ich werde CI verwenden, um dies zu tun), um eine DAB-Datei aus diesen verschiedenen Teilen zu erstellen. Es wäre schön, ein Docker-Tool zu haben, das dies tun würde ... :-) Vielleicht fügen Sie --env-file version.env zu docker-compose bundle hinzu?

In meinem Anwendungsfall möchte ich ein version.env "Manifest" verwenden, um die Versionen von Containern/Images, aus denen eine Plattform besteht, zu verfolgen und zu steuern. Mein Ablauf sieht so aus:

  • Aktualisieren Sie die Datei .env
  • Quelldatei .env zum Füllen der Shell-Variablen
  • Führen Sie docker-compose -f stack.yml config > docker-compose.yml
  • Führen Sie docker-compose pull aus, um die Bildauszüge zu registrieren
  • Führen Sie docker-compose bundle -o stack.version.dab DAB-Datei aus

An diesem Punkt wäre ich idealerweise in der Lage, docker deploy --host manager.swarm.com --bundle-file stack.version.dab --with-registry-auth --resolve-image always stack-name , aber ich verstehe, dass dies jetzt nicht möglich ist. In diesem Fall würde ich die DAB-Datei an den Manager scp und die docker deploy ausführen.

Ist dies der Workflow, den Docker bei @thaJeztah im Sinn hatte? Gibt es einen besseren Weg?

[Bearbeiten] Dies funktioniert nicht, da ein DAB die Direktiven volume: , network: und deploy: ignoriert. Ich habe mir vorgenommen, einfach eine env-Datei an die Shell zu liefern, eine temporäre Compose-Datei neu zu erstellen und diese dann bereitzustellen.

Ich würde es lieben, wenn .env Dateien standardmäßig wie in Docker Compose gelesen würden und --env-file (kurz -e ) hinzugefügt würden, damit docker stack deploy überschreiben können Umgebungsvariablen und die Standardwerte aus der Datei .env .

+1
Es wäre ziemlich praktisch, die .env-Datei von vornherein zu lesen, wie es docker-compose tut.
Entweder standardmäßig oder übergeben Sie einfach die env-Datei als Parameter in der Docker-Stack-Befehlszeile.

Die beiden bereits erwähnten Problemumgehungen (_finde sie auch unten_) scheinen zu funktionieren, obwohl sie im Vergleich zum vorgeschlagenen 'Fix' etwas hässlich sind.

_echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c-stack_name_

_env $(cat .env | grep ^[AZ] | xargs) Docker-Stack deploy --compose-file docker-compose.yml [STACK_NAME]_

Ich würde hinzufügen, dass es auch ziemlich gefährlich sein kann, docker-compose nur zu installieren, um diese Variablen verarbeiten zu können.

Wenn jemand den Stapel versehentlich mit docker-compose up -d bereitstellt, anstatt docker stack deploy zu verwenden, würde dies höchstwahrscheinlich zu Anwendungsfehlern und Dateibeschädigungen führen.

Die Interpolation von Umgebungsvariablen in der Bereitstellung ist die beste Lösung für kontinuierliche Integration.

Ein Problem bei der Verwendung von „.env“ besteht darin, dass es sich mit ähnlichen Dateinamen überschneidet, die beispielsweise von Ruby on Rails verwendet werden, da die Möglichkeit, eine Umgebungsdatei per Argument anzugeben, überlegen ist.

Die Vorschläge von @ntelisil sind gut aufgenommen, sie könnten ergänzt oder modifiziert werden durch:

https://unix.stackexchange.com/questions/294835/replace-environment-variables-in-a-file-with-their-actual-values :

Sie könnten envsubst (Teil von gnu gettext) verwenden:
envsubst < infile

Ich benutzte:

$ envsubst < docker-compose.yml-template > docker-compose.yml

Und das hat gut funktioniert, aber ich musste meinem Container etwa 3 MB hinzufügen.

Nett @rnickle , aber immer noch "hacky" im Vergleich zu Docker, das dies so tun konnte, wie es früher der Fall war. Es scheint (und bitte korrigiert mich Docker-Typen, wenn ich falsch liege), dass seit der Ankündigung der K8-Unterstützung sehr wenig Aufwand in den Schwarmmodus gegangen ist, daher bezweifle ich, dass eine dieser Rückschritte angegangen wird.

Und das hat gut funktioniert, aber ich musste meinem Container etwa 3 MB hinzufügen.

Wenn die Umgebungsvariablen gesetzt sind, sollte docker slack deploy sie bereits interpolieren

im Vergleich zu Docker, das dies so tun konnte, wie es früher der Fall war.

Docker hatte diese Funktion nie; docker compose hatte; Docker Compose und Docker Stack Deploy teilen das _Dateiformat_, aber nicht unbedingt alle Verhaltensweisen der Software selbst.

dass seit der Ankündigung der K8-Unterstützung sehr wenig Aufwand betrieben wird, um in den Schwarmmodus zu wechseln

Die Handhabung von Compose-Dateien erfolgt vollständig clientseitig und wird sowohl für k8s als auch für swarmkit verwendet, sodass in diesem Bereich nichts verlangsamt wird, außer „es gibt nur so viel, was wir zu einem bestimmten Zeitpunkt tun können“.

Für diejenigen, die auf diese Funktion warten; Die kommende Version wird Unterstützung für mehrere Compose-Dateien für docker stack deploy haben, wenn Sie diese Funktion also derzeit in Docker Compose verwenden: Die kommende Docker-Version wird dies ebenfalls unterstützen

Semantik beiseite, danke für das Update. Wenn ich Docker sage, meine ich nicht unbedingt den Daemon oder die Engine, sondern die Firma, die die Tools baut. Die Genese für den Kommentar, dass es wenig Aufwand gibt, ergibt sich wirklich aus der Tatsache, dass der Swarm-Modus seit über einem Jahr nicht mehr da ist und immer noch VIEL hinter uns zurückbleibt, wo wir mit einem Single-Node mit Compose waren.

Ich kann verstehen, dass sie unterschiedlich sind, aber das gleiche Dateiformat verwenden, aber das führt tatsächlich zu mehr Verwirrung und möglicherweise zu Enttäuschungen, wenn Benutzer feststellen, dass sie Funktionen gegen die Verwendung von Swarm eintauschen müssen. Das und die Tatsache, dass die DAB-Dateien NOCH als experimentell aufgeführt werden. Leider haben wir die Entscheidung getroffen, den Schwarmmodus in einem großen Projekt zu verwenden, sonst wäre es mir egal. Glücklicherweise werden wir diesen Fehler nicht noch einmal machen.

[bearbeiten]

Wenn die Umgebungsvariablen gesetzt sind, sollte Docker Slack Deploy sie bereits interpolieren

Dies in einer CI-Umgebung zu tun, ist ein wahrer Arschschmerz. Im Wesentlichen habe ich am Ende Compose installiert, die envvars beschafft, die Compose-Datei durchgespült (nach dem Ziehen der Bilder) und dann eine neue Compose-Datei zur Verwendung mit stack deploy ausgespuckt. (Und ich werde nicht einmal damit anfangen, wie schmerzhaft es ist, wenn :latest :latest bedeutet, da es hier speziell um Variableninterpolation geht.)

_EDIT: Ich hoffe, dieser Post kommt nicht aggressiv rüber. Ich liebe das Docker-Stack-Konzept und denke, dass die gesamte Docker-Suite ziemlich gut unterstützt wird. Es scheint nur, dass Docker (die Organisation) seine Produkte derzeit nicht so sieht, wie Benutzer es tun, was bedauerlich ist und die Ursache für die meisten Probleme zu sein scheint, auf die ich bei der Verwendung von Compose und Stack gestoßen bin._

Docker hatte diese Funktion nie; docker compose hatte; Docker Compose und Docker Stack Deploy teilen das Dateiformat, aber nicht unbedingt alle Verhaltensweisen der Software selbst.

Ich habe das Gefühl, dass diese Aussage eine grundlegende Diskrepanz zwischen der Art und Weise offenbart, wie Dockers Entwickler und Benutzer diese Produkte sehen. Als Nutzer, egal ob ich mit Docker Engine, Docker Compose oder Docker Swarm arbeite, es ist alles Docker und sollte sich möglichst einheitlich verhalten.

Mein Verständnis des Zwecks dieser Produkte ist:

  • Docker Engine dient zum Erstellen und Ausführen einzelner Container
  • Docker Compose dient zum Ausführen einer Reihe von Containern in der Entwicklung
  • Docker Stack dient zum Bereitstellen von Containern für die Produktion

Eines der wichtigsten Verkaufsargumente von Docker (und Containern im Allgemeinen) ist die einfache Wiederverwendung derselben App in mehreren Umgebungen. Daher sollte Compose zu Engine und Stack zu Compose hinzugefügt werden. Insbesondere da sie dasselbe Dateiformat verwenden, führt Stack, das Funktionen von Compose nicht unterstützt, zu Verwirrung bei Entwicklern und zu zusätzlicher Komplexität in CI-Prozessen.

Ich würde nicht unbedingt sagen, dass Compose für Dev und Stack für Prod ist. Ich betrachte Compose als für eine Multi-Container-Anwendung oder ein "System" und Stack für Multi-Host-Bereitstellungen unter Verwendung des Swarm-Modus als Planer/Orchestrator. Ansonsten trifft dein Kommentar zu 100% zu. Ich bin auch frustriert (wenn es nicht aus meinen anderen Kommentaren hervorgeht), dass es eine Diskrepanz zwischen den Entwicklern und den Benutzern gibt, wie das/die Produkt(e) verwendet werden.

Oh wow. Ich schloss mich der Verwirrung und dem Schmerz an, als ich auch Docker Swarm für ein großes Projekt evaluierte.
Die Geheimnisse sind alle Spaß und Spiel, nur dass nicht alle externen Docker-Images das Lesen von Geheimnissen aus Dateien unterstützen. Ich möchte nicht für jeden von ihnen modifizieren und ein benutzerdefiniertes Bild platzieren. Könnte sie für meine Projekte verwenden, ja, aber für externe Projekte wäre ein No-Go.
Damit bleiben env-Variablen übrig. Aber hey, sie verhalten sich von Compose zu Stack anders! Stellen Sie sich meine Überraschung vor, als ich bemerkte, dass sie nicht wirklich funktionieren.
Wie ist es möglich, einen Docker-Stack ohne env-Unterstützung zu haben? Am besten wäre meiner Meinung nach --env-file=dev.env , damit es andere env-Dateien nicht stört ... aber die Unterstützung dafür ist schrecklich. Ich muss leider zu k8s zurückkehren, da der Stack, der dies von Anfang an vermisst, sich während der Produktion als eine schreckliche Wahl erweisen könnte, wer weiß, wie viele andere Dinge fehlen werden.

Es ist zwei Jahre her und wir sind immer noch so ... Ich möchte nicht unhöflich wirken, aber komm schon! Es geht darum, ein bisschen Code von docker-compose wiederzuverwenden!

Ein weiteres ähnliches Problem, auf das ich gerade gestoßen bin, ist, dass selbst wenn Sie env_file verwenden, das Verhalten immer noch nicht genau dasselbe ist.

Ich verwende env_file, um Pfade zu laden, die aus dem Projektstammverzeichnis angegeben sind, aber meine Compose-Datei befindet sich in einem anderen Unterverzeichnis. Um mit Docker-Compose zu starten, verwende ich einfach --project-directory . -f Pfad/zu/docker-compose.yml

docker stack erlaubt mir nicht, das Projektverzeichnis anzugeben, was dazu führt, dass alle meine env_files nicht geladen werden können.

Das Ändern von env_file in „../../path/to/envrc“ funktioniert nicht mit docker-compose, da sich diese Dateien im Projektstammverzeichnis befinden müssen

+1

+1

+1 das wäre wirklich nützlich. Sehe eigentlich keinen Nachteil.

Es ist unglaublich dumm, dass Docker dies noch nicht unterstützt.

+1 @joao-fidalgo Das ist es definitiv.

+1

Bin gerade auf dasselbe gestoßen, als wir Swarm ausprobieren. Ich habe alle Nachrichten in verschiedenen Threads durchgelesen und bin extrem frustriert. IMO, einige wirklich gute Punkte und starke Argumente wurden von @ntwrkguru und anderen vorgebracht. Ich hoffe, wir können sie in Betracht ziehen, um diese Funktion einzubauen; Hacks werden es nicht schneiden.

.env-Datei

export MYSQL_USER=user

source .env && docker stack deploy

Es funktioniert auch mit docker-compose up für bash

.env-Datei

export MYSQL_USER=user

source .env && docker stack deploy

Es funktioniert auch mit docker-compose up

Das würde nur für Bash und nicht für andere Shells funktionieren.

Das verwirrte mich wie verrückt. Meine App würde mit docker-compose erscheinen, aber nicht mit docker stack deploy. Es sollte zumindest ein Haftungsausschluss gut sichtbar in den Dokumenten angezeigt werden

Aber meiner Meinung nach ist dies ein Fehler und verschlechtert die Docker-Erfahrung.

Darauf brauchen wir eine Antwort

Fast 2 Jahre und niemand hat es aufgegriffen ... halten Sie nicht den Atem an @jorgelimafeitosa

Ich glaube nicht, dass die CLI jemals Unterstützung für .env hinzufügen wird. Der docker stack deploy -Befehl wurde ursprünglich für Distributed Application Bundle-Dateien erstellt (daher die --bundle-file -Option). DAB-Dateien wurden von Docker Compose mit dem Befehl docker-compose bundle generiert. .env und andere Compose-Funktionen würden von docker-compose verarbeitet, bevor sie an docker stack deploy übergeben würden. Die direkte Unterstützung von Compose-Dateien in docker stack deploy war immer eher ein Kompromiss.

Das ursprüngliche Versprechen von DAB-Dateien lebt nun in der Docker-App weiter, die ebenfalls .env nicht verarbeitet.

Ich lasse meine Entwickler docker-compose config verwenden, um Docker Compose-Projekte vorzuverarbeiten, bevor sie an docker stack deploy übergeben werden. Sie können dies in einer Zeile tun mit:

docker stack deploy -c <(docker-compose config) stack-name-here

Auf diese Weise werden alle Docker Compose-Funktionen einschließlich der .env -Verarbeitung vollständig angewendet.

@kinghuang Habe deine Lösung versucht, hat aber nicht funktioniert. „docker-compose config“ erzeugt die korrekte Ausgabe im selben Verzeichnis, aber „docker stack deploy -c docker-compose.yaml my_stack“ ersetzt keine Variablen aus der .env-Datei. Was vermisse ich? Dies ist die Docker-Version 18.09.0, Build 4d60db4.

@kinghuang Habe deine Lösung versucht, hat aber nicht funktioniert. „docker-compose config“ erzeugt die korrekte Ausgabe im selben Verzeichnis, aber „docker stack deploy -c docker-compose.yaml my_stack“ ersetzt keine Variablen aus der .env-Datei. Was vermisse ich? Dies ist die Docker-Version 18.09.0, Build 4d60db4.

docker stack deploy -c <(docker-compose -f docker-compose-frpc-swarm-traefik.yml config) traefik

@kinghuang

open /dev/fd/63: keine solche Datei oder Verzeichnis

WARNUNG: Einige Dienste (Projekt1, Projekt2) verwenden den Schlüssel „Bereitstellen“, der ignoriert wird. Compose unterstützt keine „Deploy“-Konfiguration – verwenden docker stack deploy , um es einem Schwarm bereitzustellen.

@kinghuang
Nur die Root-Umgebung meldet keinen Fehler.

Die Unterstützung .env und env_file ist in einer Bereitstellungs-/Produktionsumgebung nicht immer sinnvoll. Für die anderen Funktionen von Docker Swarm benötigen Sie keinen direkten Zugriff auf das Dateisystem. Ein verantwortungsbewusster Designer/Betreiber dieses Systems möchte Ihnen also nicht die Möglichkeit geben, Umgebungsdateien auf das Dateisystem zu kopieren.

Theoretisch könnte Swarm das automatische Laden von Geheimnissen in die Umgebung unterstützen, aber unter https://github.com/moby/moby/issues/30866#issuecomment -278924983 erfahren Sie, warum dies aus Sicherheitsgründen keine gute Idee ist.

Was Sie heute tun können, ist, Geheimnisse zu verwenden und sie in die Umgebung Ihrer App zu laden, wenn der Container ausgeführt wird. Dadurch haben Sie die Kontrolle darüber, wo die geheimen Umgebungswerte zu sehen sind.

+1
docker stack deploy sollte wirklich --env-file unterstützen.
Ich selbst kämpfe mit der Wiederverwendung derselben .yml-Datei, um verschiedene Stacks für Entwicklungs-/Test-/Produktionsumgebungen bereitzustellen, und ich möchte mich vor der Bereitstellung des Stacks nicht mit einem umständlichen Export/Sourcing von Umgebungsvariablen befassen. Dies ist sehr fehleranfällig (und auch mühsam, sich jedes Mal an die genauen Befehle zu erinnern).
In meinem speziellen Fall möchte ich zB unterschiedliche Index-Namen (Elasticsearch) pro Umgebung setzen - aber der Rest der Konfiguration bleibt gleich. Das hat nichts mit "Geheimnissen" wie in früheren Beiträgen erwähnt zu tun.
Basierend auf dem obigen Kommentarverlauf scheint ein echter Bedarf an --env-file für die Docker-Stack-Bereitstellung zu bestehen, aber leider scheinen die Docker-Entwickler das nicht zu sehen.

In meiner Schwarmumgebung habe ich mich für ein paar Workarounds entschieden:

  • secrets/configs, die ich verwende, um Konfigurationsdateien und Zertifikate hochzuladen.
  • Nachdem ich mir eine Demo der Azure-Entwicklungsumgebung angesehen hatte, in der sie ein variables Interpolationsskript hatten, das sie vor dem Einreichen einer Compose-Datei ausführten, schrieb ich mein eigenes, das ich in meinen GitLab-Release-Flow einfügte.

Geben Sie einfach die .env-Datei in Ihrer docker-compose.yml an und es funktioniert:

env_file:
  - .env

Siehe https://stackoverflow.com/questions/44694640/docker-swarm-with-image-versions-externalized-to-env-file

Eine Problemumgehung in Powershell zur Verwendung unter Windows, um die .env-Datei zu analysieren, bevor Docker aufgerufen wird:

switch -regex -file "./.env" { "^\s ([^#].+?)\s =\s (. )" { $name,$value = $matches[1..2]; Set-Item "env:$name" $value}}

Stark inspiriert vom Parsen von .ini-Dateien: https://stackoverflow.com/questions/417798/ini-file-parsing-in-powershell

Eine andere Problemumgehung ist: set -a && . .env && set +a && docker stack deploy... .

Das ist lächerlich. Ich habe den ganzen Tag damit verbracht, dies zum Laufen zu bringen. Ein Haftungsausschluss wird zumindest irgendwo in den Dokumenten benötigt, dass .env nicht von docker stack -Befehlen gelesen wird.

@cjancsar Das tun sie. Die Dokumentation sagt:

Wichtig: Die .env-Dateifunktion funktioniert nur, wenn Sie den Befehl „docker-compose up“ verwenden, und funktioniert nicht mit der Docker-Stack-Bereitstellung

Aus Interesse. Was machen Leute derzeit, wenn sie sich im Schwarmmodus befinden und ihr neu erstelltes Docker-Image aktualisieren möchten, z. B. von application:v1 auf application:v2 , denselben Dienst (sonst nichts geändert)?

Aus diesem Grund bin ich auf dieses Thema gekommen. Deshalb bin ich interessiert.

Derzeit ist es in Docker-Compose trivial, die Automatisierung dazu zu bringen, mit der nicht nachverfolgten Datei . env der Quellcodeverwaltung zu interagieren, um die Image-Version zu aktualisieren, und dann docker-compose up -d

Oft verwende ich das Commit-Sha als Docker-Image-Version für „Staging“-Bereitstellungen (Git-Tags, die nach ausreichenden Testzyklen für tatsächliche Releases verwendet werden), sodass es nicht wirklich möglich ist, die neue Image-Version an die Quellcodeverwaltung zu übergeben.

Ist es als Problemumgehung möglich, ein Docker-Secret zu aktualisieren (auch wenn es nicht wirklich ein Secret ist)? Ist es das, was Menschen tun, oder gibt es etwas anderes, das getan wird?

Ich bitte um zukünftige Besucher dieser Ausgabe, damit sie tatsächlich ein aktuelles Best Practice erhalten, da die gesuchte Funktionalität (noch?) nicht existiert.

Hallo, ich bin damit beschäftigt, mich mit Stack Deployment für die Verwendung in CI/CD-Pipelines zu befassen. Es wäre sehr nützlich, eine .env-Datei verwenden zu können. Gibt es Feedback dazu, ob diese Option irgendwann eingeführt wird?

Es scheint, dass die offizielle Empfehlung tatsächlich darin besteht, Ihren Bildcode zu migrieren, um das Lesen dieser Arten von Variablen aus einer geheimen Textdatei zu unterstützen – wobei die Möglichkeit erhalten bleibt, diese auch aus Umgebungsvariablen zu lesen, um die Abwärtskompatibilität ohne Stapel/Schwarm zu gewährleisten.

Das Beispiel verwendet ein Geheimnis pro Textdatei, wodurch das Analysieren der alten .env-Datei vermieden wird.

Paraphrasiert aus der Dokumentation unter https://docs.docker.com/engine/swarm/secrets/#use -secrets-in-compose :

services:
   db:
     image: mysql:latest
     environment:
       MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD_FILE: /run/secrets/db_password
     secrets:
       - db_root_password
       - db_password

secrets:
   db_password:
     file: db_password.txt
   db_root_password:
     file: db_root_password.txt

Seufzen

Dies sollte in der Dokumentation deutlicher werden. Obwohl darauf hingewiesen wird, dass .env im Abschnitt Variable Substitution per @lengxuehx nicht unterstützt wird, wird nicht erwähnt, dass env_file für Stack-Bereitstellungen ignoriert wird.

Ich kann bestätigen, dass die von @kinghuang vorgeschlagene Lösung funktioniert und den Bereitstellungsschlüssel nicht ausschließt, wie jemand sagte.

docker stack deploy -c <(docker-compose config) stack-name-here

Dies sollte in der Dokumentation deutlicher werden. Obwohl darauf hingewiesen wird, dass .env im Abschnitt Variable Substitution per @lengxuehx nicht unterstützt wird, wird nicht erwähnt, dass env_file für Stack-Bereitstellungen ignoriert wird.

Ich kann bestätigen, dass env_file verwendet wird und für den Befehl deploy stack funktioniert, genau wie Docker Compose.

docker version
Client: Docker Engine - Community
 Version:           19.03.4
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        9013bf5
 Built:             Thu Oct 17 23:44:48 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.4
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       9013bf5
  Built:            Thu Oct 17 23:50:38 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Zusammenfassend für Leute wie mich, die dies bisher gelesen haben:

  • docker stack deploy unterstützt "Variable Substitution", aber Sie müssen die Umgebungsvariablen in irgendeiner Weise aus der Datei .env setzen. Mehrere Optionen wurden oben erläutert. Eine der saubersten Problemumgehungen ist die Verwendung docker-compose config als Präprozessor.
    So können Sie Ihren Stack mit docker stack deploy -c <(docker-compose config) STACK_NAME erstellen.
  • Obwohl Docker die Configs- und Secret -Fähigkeiten eingeführt hat, haben sie ihre Anwendungsfälle, tun aber nicht dasselbe wie „Variable Substitution“.
  • Der Parameter env_file in der Datei docker-compose.yml setzt die Umgebungsvariablen im erstellten Container und nicht in der Datei docker-compose.yml selbst (und kann daher nicht als Alternative zu " Variablensubstitution").

Aktualisieren:

Ich wurde von @thaJeztah korrigiert.

Docker unterstützt keine Variablensubstitution mit Docker-Stack-Bereitstellung, und keine der vorgeschlagenen Lösungen funktioniert nicht.

docker stack deploy unterstützt Variablensubstitution, wertet aber die .env -Datei nicht aus; Im Beispiel unten ist HELLO_VERSION auf linux gesetzt, und der Dienst verwendet das Tag hello-world:linux (anstelle des standardmäßigen hello-world:latest ).

HELLO_VERSION=linux docker stack deploy -c docker-compose.yml mystack
Creating network mystack_default
Creating service mystack_hello

docker service inspect --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}' mystack_hello
hello-world:linux<strong i="14">@sha256</strong>:d073a5775c0b99d653c413161a8ed0e9685061afe697931d30eddf6afeef40f6

Davon abgesehen können Sie Umgebungsvariablen weiterhin mit dem Parameter env_file in Ihrer docker-compose.yml-Datei verwenden

Das env_file dient einem anderen Zweck (und entspricht docker run --env-file ); Die Option env_file gibt an, welche env-vars für den erstellten Container festgelegt werden sollen, wird jedoch nicht in der Compose-Datei selbst verwendet (und nicht zum Ersetzen von Variablen in der Compose-Datei vor dem Bereitstellen des Stapels).

Ich hatte das gleiche Problem zusammen mit anderen geringfügigen Unterschieden zwischen Docker-Compose und Docker-Stack.
Am Ende habe ich https://github.com/egyel/dcsh script/tool ​​erstellt, um dieses Problem mit Pipes zu lösen.

image
Hallo allerseits, dies hat mir geholfen, env_file in mein Docker-Compose einzufügen:

env_file: /path/to/env/file
nicht

env_file:
  - /path/to/env/file

Ich habe das gerade aus einem anderen Beitrag gesehen und kann nur spekulieren, warum es funktioniert (genau wie Ihre Spekulation), aber wir brauchen eine Bestätigung, warum dies als Docker funktioniert, der ausdrücklich in der Dokumentation erwähnt wird, dass env_file nicht funktioniert.

Mein Verständnis ist, dass env-Dateien nicht zum Ausfüllen von Platzhaltern verwendet werden können
die Docker-Stack.yml-Datei, aber sie können weiterhin Containern bereitgestellt werden.
Beachten Sie, dass das, was Sie tun, es Ihnen nicht erlaubt, den Bildnamen von festzulegen
die env-Datei zum Beispiel.

Am So, 17. Mai 2020, 06:08 schrieb raphyphy [email protected] :

[Bild: Bild]
https://user-images.githubusercontent.com/30310576/82135555-a1e4be00-9836-11ea-9df4-a1b82e014b0e.png
Hallo allerseits, dies hat mir geholfen, env_file in mein Docker-Compose einzufügen:

env_file: /path/to/env/file
nicht

env_file:

  • /pfad/zu/env/datei

Ich habe das gerade in einem anderen Beitrag gesehen und kann nur spekulieren, warum es funktioniert
(wie Ihre Spekulation), aber wir brauchen eine Bestätigung, warum das so ist
Arbeiten als Docker, der ausdrücklich in der Dokumentation erwähnt wird, dass env_file dies nicht tut
arbeiten.


Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/29133#issuecomment-629740002 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/ABHLQMCARDQGJQIBWCQKAYLRR5PMHANCNFSM4CYRHCTA
.

Die oben erwähnte Docker-Compose-Lösung:

docker stack deploy -c <(docker-compose config) stack-name-here

hat (für mich) den Nachteil, dass Dinge wie .env -Dateien und insbesondere docker-compose.override.yml -Dateien normalerweise eher Teil meiner Entwicklungsumgebung sind. Ich möchte nicht wirklich, dass diese bei der Bereitstellung in der Produktion eingeführt werden.

Am Ende hatte ich ein separates docker-compose-production.yml , in dem ich die Dinge sorgfältig kontrollierte, obwohl dies einige Doppelarbeit beinhaltete.

Ich glaube nicht, dass die CLI jemals Unterstützung für .env hinzufügen wird. Der docker stack deploy -Befehl wurde ursprünglich für Distributed Application Bundle-Dateien erstellt (daher die --bundle-file -Option). DAB-Dateien wurden von Docker Compose mit dem Befehl docker-compose bundle generiert. .env und andere Compose-Funktionen würden von docker-compose verarbeitet, bevor sie an docker stack deploy übergeben würden. Die direkte Unterstützung von Compose-Dateien in docker stack deploy war immer eher ein Kompromiss.

Das ursprüngliche Versprechen von DAB-Dateien lebt nun in der Docker-App weiter, die ebenfalls .env nicht verarbeitet.

Ich lasse meine Entwickler docker-compose config verwenden, um Docker Compose-Projekte vorzuverarbeiten, bevor sie an docker stack deploy übergeben werden. Sie können dies in einer Zeile tun mit:

docker stack deploy -c <(docker-compose config) stack-name-here

Auf diese Weise werden alle Docker Compose-Funktionen einschließlich der .env -Verarbeitung vollständig angewendet.

Dies funktioniert wie ein Zauber, denken Sie daran, wenn Ihre Compose-Datei nicht den Namen „docker-compose.yml“ hat, sollte Ihr Befehl den tatsächlichen Namen der Compose-Datei enthalten.

docker stack deploy -c <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config) CUSTOM-STACK

ACHTUNG vor dem <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config HACK!!! Die Ausgabe von docker-compose config und docker-compose -f myfile.yml config ist NICHT unbedingt gleich! Letzteres schließt manchmal env-Variablen in zusätzliche Anführungszeichen ein, sodass die Ausgabe falsch ist!

Beispiel:

environment:
  SERVER_URL: '"xxx"'

anstatt

environment:
  SERVER_URL: xxx

Wird dieses Problem schon irgendwo verfolgt?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen