Moby: `docker stack deploy` dans 1.13 ne charge pas le fichier `.env` comme le fait `docker-compose up`

Créé le 5 déc. 2016  ·  93Commentaires  ·  Source: moby/moby

Pour tester la fonction docker stack deploy --compose-file , je charge un de mes exemples 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:

Dans la section image du service nginx et php , j'ai utilisé ${DOCKER_USER} pour obtenir l'identifiant du docker à partir des variables d'environnement. Et si j'utilise docker-compose up , il chargera le fichier .env en tant que fichiers envvar par défaut, dont le contenu est :

DOCKER_USER=twang2218

Cependant, si j'utilise docker stack pour déployer ce docker-compose.yml , j'obtiendrai les erreurs suivantes :

$ 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

Comme vous pouvez le voir, comme la commande docker stack deploy n'a pas chargé le fichier .env , le ${DOCKER_USER} a été remplacé par une chaîne vide, ce qui a rendu le nom de l'image invalide.

Si le fichier .env a été chargé, le nom final de l'image devrait être twang2218/lnmp-php:v1.2 .

La substitution d'environnement fonctionne réellement, si j'exécute la commande de cette façon :

$ 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

Et nous pouvons vérifier que cela fonctionne avec la commande docker service inspect :

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

Le nom de l'image est twang2218/lnmp-php:v1.2 , ce qui est correct.

J'ai testé cette fonctionnalité sur Digtial Ocean droplet, qui a installé docker 1.13.0-rc2 via docker-machine .

Voici la version :

$ 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

Voici le 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

Commentaire le plus utile

@whoan j'utilise ceci comme solution de contournement:

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

De cette façon, les variables ne restent pas bloquées sur la fenêtre du terminal

Tous les 93 commentaires

C'est par conception. La prise en charge .env est une fonctionnalité de Compose, pas du format de fichier.

Nous pouvons discuter de l'ajout de cela pour une future version, mais je ne sais pas si c'est vraiment la meilleure option.

Le support .env est très utile dans Compose, nous l'avons utilisé dans plusieurs de nos fichiers de composition. Il sépare les parties dynamiques et les parties statiques du fichier docker-compose.yml . Avec load .env par défaut, nous pouvons simplement fournir un fichier .env différent pour différents environnements, et garder le docker-compose.yml et les scripts associés statiques.

Il n'est pas possible d'utiliser env_file ou environment dans docker-compose.yml pour obtenir le même résultat de substitution d'envvars. .env est le moyen le plus simple de le faire.

Sinon, nous devons préfixer export dans chaque ligne du fichier .env et manuellement source .env chaque fois avant de charger le docker-compose.yml , et les étapes supplémentaires sont parfois sujettes se méprendre.

Je viens de remarquer ça.
J'ai supposé/attendu qu'il fonctionne de la même manière que pour Compose, mais ce n'est pas le cas pour docker deploy .

Dans mon cas particulier, je m'attendais à utiliser le fichier .env pour stocker des données sensibles (mots de passe, clés API, etc.) utilisées dans les services que je vais créer dans la pile :

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

Alors que ce fichier Compose sera archivé sur Git, le fichier .env sera ignoré.

J'ai suivi tout l'historique des fichiers *.dab vs compose, et j'ai l'impression que vous essayez d'éviter quelque chose - ou de proposer une meilleure solution - mais j'ai perdu la trace de toute la discussion...

Bonjour à tous,

Version Docker : v1.13.0-rc4

J'obtiens une erreur : Ignorer les options non prises en charge : build , Cela signifie-t-il qu'il ne créera pas de build à partir de Dockerfile ?

Et obtenir également la même erreur pour network_mode : Ignorer les options non prises en charge : network_mode.

Ci-dessous la commande :
DOCKER_IMAGE=akhil123 docker stack deploy -c docker-compose.yml foo

Merci d'avance.

@akhildangore , veuillez ne pas commenter les problèmes avec des questions qui ne sont pas directement liées. La fonctionnalité docker stack deploy , _by design_ n'effectue pas de builds. La raison en est qu'un _build_ est effectué sur l'hôte à partir duquel la commande est exécutée, de sorte que l'image ne sera disponible que sur _ce_ nœud. Lors du déploiement de cette image dans un Swarm, le service ne peut pas être démarré sur d'autres nœuds. Pour déployer des services, assurez-vous que l'image que vous déployez est poussée vers un registre (ou pour les tests ; assurez-vous que l'image est disponible sur chaque nœud de l'essaim)

Y a-t-il des cas/discussions en faveur de/contre le soutien de ce comportement sur docker deploy ?

@vovimayhem aucune décision n'a encore été prise sur le fichier .env , mais vous pourriez être intéressé par https://github.com/docker/docker/pull/30144 , qui ajoute la prise en charge des secrets au fichier de composition

Je viens de trouver cette discussion. Excellent!

J'utilise une fonction bash comme solution de contournement.

Vous pouvez l'adapter à vos besoins jusqu'à ce que la fonctionnalité secrets soit disponible :

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
    )
}

Pour ceux qui s'abonnent à ce numéro; la prise en charge des secrets pour les fichiers docker-compose sera incluse dans la version 1.13.1, qui ne devrait pas être trop loin dans le futur

@whoan j'utilise ceci comme solution de contournement:

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

De cette façon, les variables ne restent pas bloquées sur la fenêtre du terminal

C'est toujours agréable d'avoir la possibilité de charger des choses à partir d'un fichier .env - à part un cas d'utilisation plus simple des secrets Docker qui peut maintenant être contourné, il y a toujours des valeurs Docker Compose que vous ne voulez pas avoir codées en dur dans votre dépôt.

Supposons que vous utilisiez docker stack deploy pour déployer une pile complète et que vous remplissiez les conditions suivantes :

  • vous souhaitez utiliser exactement la même configuration pour différents environnements - par exemple, la mise en scène et la production

    • vous devez avoir des valeurs d'échelle différentes pour chaque environnement

Si vous ne pouvez pas le configurer avec un fichier .env , vous devez modifier manuellement le fichier docker-compose.yml avant de déployer la pile à chaque fois, sinon la valeur d'échelle de service reviendra à 1.

Vous pouvez étendre ce qui précède avec des éléments tels que les réseaux, la configuration du DNS qu'un service doit écouter, etc.

Je peux rédiger un PR qui chargera un fichier .env , s'il en existe un dans le même répertoire que docker-compose.yml si nous pensons que les cas d'utilisation ci-dessus ont du sens.

La conception du déploiement de docker stack est un peu différente des commandes docker-compose . Je ne pense pas qu'il soit logique de simplement lire un .env par défaut. Même le docker-compse.yml n'est pas lu par défaut, car à l'avenir, la source de déploiement par défaut sera probablement autre chose.

Vous pouvez toujours sourcer vous-même un fichier .env avant d'exécuter stack deploy .

Juste . .env avant d'appeler docker stack deploy n'aide pas, les $variables ne sont pas remplacées. Seul env .. xargs truc a aidé.
Ce serait bien d'avoir l'option --env-file=FILE comme dans docker run .

Juste . .env avant d'appeler le déploiement de la pile de docker n'aide pas

Cela devrait aider @C-Pro - vous devez avoir des lignes export ... dans votre fichier .env . Alternativement, vous pouvez faire export $(cat .env) , ce qui fonctionnerait dans la plupart des cas.

Bonjour à tous,
Aujourd'hui, j'ai essayé d'exécuter docker stack deploy .
Mon fichier docker-compose.yml :

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

Et le fichier .env dans le même répertoire :

BAR=worked

Après le lancement docker stack deploy -c docker-compose.yml test , j'ai inspecté le conteneur et j'ai obtenu ceci :

$ env
BAR=worked
FOO=
...

Il semble que .env fourni dans le conteneur, mais non fourni sur la machine hôte.
Cela signifie que je peux utiliser le fichier .env au lieu de la section environment , mais je ne peux pas utiliser le fichier .env avec la substitution de variable.
Version Docker : v17.03

@dpaimon
environnement:
- FOO=${BAR}

Il semble que ce fichier .env ne fonctionne que pour le conteneur, mais pas pour le remplacement de variable de fichier docker-compose.yml.

Docker pour MAC, Docker version 17.03.1-ce, build c6d412e

@realcbb
Oui. Mais pour utiliser les variables de fichier .env dans le conteneur, vous devez les supprimer dans la section environment .
Par example:
docker-compose.yml

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

.env

FOO=filled

En conteneur j'ai ça :

$ env
FOO=empty

Mais si je supprime FOO de la section environment dans docker-compose.yml , j'obtiens ceci :

$ env
FOO=filled

@dpaimon
Les variables d'environnement spécifiées dans l'environnement remplacent ces valeurs spécifiées dans le fichier .env.

@dnephin : vous déclarez que .env ne fait pas partie du format de fichier docker compose. Cependant, la fonctionnalité de fichier .env est documentée dans la référence du fichier Compose version 3 : https://docs.docker.com/compose/compose-file/#variable -substitution .
Cela donne l'impression que .env devrait également fonctionner avec le déploiement de la pile docker.
En plus de cela, comme déjà mentionné par d'autres, séparer les valeurs spécifiques à l'environnement réel de la définition de pile yaml est une fonctionnalité très recherchée/nécessaire. Plus précisément, nous voulons l'utiliser pour spécifier les versions d'image et les réplications.

Merci, j'ai ouvert https://github.com/docker/docker.github.io/issues/3654 pour corriger les docs

docker stack deploy peut prendre un fichier généré. Cela fonctionne en bash pour toutes mes variables et garde également les secrets secrets :

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

Veuillez noter que j'ai ajouté les variables ENV en ligne en tant que variables supplémentaires ou remplacements. Mes fichiers de composition font référence à des fichiers .env et cela fonctionne. J'espère que cela est utile 👍

La fonctionnalité de docker-compose config est ce qui relie tout cela.

Je suis tombé sur ce problème en cherchant une solution pour que mon .env ne soit pas lu par docker stack deploy . J'ai été un peu surpris de voir qu'il n'était pas pris en charge (la documentation pourrait être clarifiée), mais je souhaite ajouter mon support pour .env , comme composer.

Mon cas d'utilisation est que j'utilise docker stack deploy dans les environnements de développement, de test et de mise en scène et que j'utilise des variables d'environnement pour les options de pile afin de conserver le même fichier yml.

Vous utilisez actuellement l'une des solutions de contournement publiées ici, mais l'utilisation d'un fichier .env serait la route préférée.

Juste un rappel amical : il est possible que vous essayiez d'utiliser des fichiers dotenv pour stocker des clés d'API, des mots de passe et d'autres éléments considérés comme "sensibles" à mettre dans le cluster. Dans ces cas, vous devez utiliser Docker Secrets .

Pour d'autres choses, puis-je suggérer d'avoir un fichier de composition par environnement déployé/déployable ? La plupart des choses qui changent entre différents environnements seront les serveurs disponibles, les différentes organisations de serveurs, etc... et donc nécessitant des valeurs différentes sur le contenu de la deploy placement , resources réservations, etc.), rendant l'utilisation d'un seul fichier pour tout un peu trop compliquée.

En fait, je veux cette fonctionnalité, les variables du fichier de composition peuvent être traitées comme des valeurs différentes sur différents hôtes lors de l'utilisation du déploiement de la pile docker.

"Pour d'autres éléments, puis-je suggérer d'avoir un fichier de composition par environnement déployé/déployable ? La plupart des éléments qui changent entre différents environnements seront les serveurs disponibles, les différentes organisations de serveurs, etc... et nécessitent donc des valeurs différentes sur la clé de déploiement contenu (règles de placement, réservations de ressources, etc.), rendant l'utilisation d'un seul fichier pour tout un peu trop compliquée."

@vovimayhem Désolé d'être franc, mais cela n'a pas autant de sens que d'utiliser un seul fichier de composition avec substitution de variable à l'aide d'un env_file. Je préférerais utiliser le format env_file car cela me permet également de fournir beaucoup plus facilement des piles en tant que livrable à mes clients et de les former à mettre à jour un seul fichier vars de style ini plutôt que de jouer avec un fichier de composition (que je DON 'Je veux).

Les configurations de service sont un excellent ajout, mais elles ne semblent pas utilisables pour l'interpolation du temps de déploiement (par exemple, $TAG).

Si les variables d'environnement sont prises en charge, soyez cohérent dans les mécanismes utilisés pour les résoudre entre les outils. Le déploiement de la pile semble choisir d'être incohérent, sans changer fondamentalement les comportements des variables d'environnement. Les secrets et les configurations de service sont de meilleures alternatives à certaines utilisations des variables d'environnement, mais ils ne se résument pas.

Vous ne semblez pas comprendre @vovimayhem. Je ne parle pas de passer envs aux conteneurs ; qui fonctionne comme prévu. Ce que je veux dire, c'est utiliser un env_file qui est analysé pendant stack deploy comme il l'était pendant compose up .

@ntwrkguru Je pensais juste que cette nouvelle fonctionnalité vous aiderait... Je suis tellement triste que ce ne soit pas le cas.

Cela fonctionne toujours comme une 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 , en effet c'est le cas. J'ai une tâche dans mon playbook pour sourcer un fichier d'environnements, mais il manque le point le plus important. Cela était possible avec compose et n'est plus possible avec stack . OMI, c'est une régression. De plus, dans votre exemple, vous passez toujours une variable d'environnement dans le conteneur. Je peux le faire avec les env_files aujourd'hui ; le problème est d'analyser le env_file pendant l'opération stack deploy -c docker-compose.yml .

Ceci est particulièrement pénible car stack ne prend plus en charge plusieurs fichiers de composition, sinon on pourrait simplement utiliser un fichier de composition secondaire par environnement. Pour ce faire, il faut créer le fichier de pile à partir des fichiers de composition, en introduisant une autre étape. Donc, de toute façon, nous sommes passés d'un processus en une seule étape à un processus en plusieurs étapes pour obtenir le même résultat final.

De plus, FWIW, le configs est vraiment inférieur à mon expérience pour les configurations réelles. J'envisageais (espérais) que je pourrais avoir /application/config.conf dans la source. Mettre à jour ce fichier, valider, pousser et CI redéploierait la pile avec la nouvelle configuration. Ce n'est pas possible sans un peu de piratage pour changer le nom du fichier ou un autre mécanisme. Nous pouvons sûrement vérifier le fichier, au minimum, ou rechercher les modifications de contenu et mettre à jour en fonction du fichier lui-même ? Dans l'ensemble, il semble que nous reculions. Ajoutez le support pour les K8 maintenant et cela me fait me demander si l'essaim va simplement languir sur la vigne jusqu'à ce qu'il perde suffisamment d'utilisation pour qu'il soit discrètement abandonné.

De plus, FWIW, les configurations sont vraiment inférieures à mon expérience pour les configurations réelles. J'envisageais (espérais) que je pourrais avoir /application/config.conf dans la source. Mettre à jour ce fichier, valider, pousser et CI redéploierait la pile avec la nouvelle configuration. Ce n'est pas possible sans un peu de piratage pour changer le nom du fichier ou un autre mécanisme.

@ntwrkguru La solution de contournement simple ne change pas le nom de fichier, mais le nom de la configuration elle-même. J'ai utilisé un schéma de version pour mes noms de configuration, par exemple config_v1 , config_v2 , ..

N'oubliez donc pas de mettre à jour cette version après avoir modifié le fichier de configuration.

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

configs:
  config_v2:
    file: ./config.yml

Je comprends le raisonnement derrière le fait de ne pas avoir encore de configuration et de secrets versionnés, donc personnellement, je suis actuellement d'accord avec cette solution de contournement (facile).

Merci @djmaze , mais c'est finalement une chose ridicule à faire quand il y a un suivi de version inhérent intégré à chaque système de contrôle de source. Aussi, merci pour le lien; J'ai aussi commenté là-bas. Je ne vois pas pourquoi Docker se soucie de la version autre que celle qui est actuelle. La seule raison pour laquelle j'ai pu voir qu'il était nécessaire de les versionner est la restauration, mais des tonnes de choses doivent également être suivies là-bas de toute façon, alors qu'est-ce qu'il y a de plus? (dit le gars qui n'a pas à écrire le code) :-)

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

Il utilise docker-compose pour analyser le fichier de configuration, en remplaçant env vars, supprime les avertissements de la sortie, puis le dirige vers le déploiement de la pile docker via stdin.
Remplacez '-f stack.yml' par le nom de votre fichier de configuration ou omettez-le pour utiliser le docker-compose.yml par défaut.

+1

Un an plus tard et nous devons encore pirater cela pour fonctionner. À partir du 17.09.1, docker stack deploy -f compose.yml ne remplacera même pas les variables shell connues.

$ 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

Toutes les variables pour les balises produiront invalid reference format .

Un an plus tard et nous devons encore pirater cela pour fonctionner. À partir de 17.09.1, docker stack deploy -f compose.yml ne remplacera même pas l'utilisation de variables shell connues.

voir Comment conserver les variables d'environnement lors de l'utilisation de SUDO

$ 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   

Merci, mais un mot sur la simple prise en charge de la substitution de variable à partir d'un fichier ?

[edit] Cela ne devrait pas être un problème (mais pourrait l'être) car j'utilise Ansible pour effectuer la tâche avec become: yes , mais l'utilisateur est toujours le même utilisateur qui source les variables d'environnement.

Je ne peux pas croire que ce n'est pas possible. Nous aimerions conserver un seul fichier de pile et pouvoir modifier les options de déploiement à l'aide de variables dynamiques.

Cela fonctionnerait mais est moche et un hack:

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

Je joue avec cela depuis de nombreuses heures et j'ai l'impression de faire un travail de script en arrière-plan (j'utiliserai CI pour le faire) pour créer un fichier DAB à partir de ces différentes pièces. Ce serait bien d'avoir un outil docker qui ferait ça... :-) Peut-être ajouter un --env-file version.env ajouté à docker-compose bundle ?

Dans mon cas d'utilisation, je souhaite utiliser un "manifeste" version.env pour suivre et contrôler les versions des conteneurs/images qui composent une plate-forme. Mon processus ressemble à ceci:

  • Mettre à jour le fichier .env
  • Fichier source .env pour remplir les variables du shell
  • Courez docker-compose -f stack.yml config > docker-compose.yml
  • Exécutez docker-compose pull pour enregistrer les résumés d'images
  • Exécutez le fichier DAB docker-compose bundle -o stack.version.dab

À ce stade, idéalement, je serais capable de docker deploy --host manager.swarm.com --bundle-file stack.version.dab --with-registry-auth --resolve-image always stack-name , mais je comprends que ce n'est pas possible maintenant. Dans ce cas, je transmettrais le fichier DAB au gestionnaire et exécuterais le docker deploy .

Est-ce le flux de travail que Docker avait en tête @thaJeztah ? Existe-t-il un meilleur moyen?

[edit] Cela ne fonctionne pas car un DAB ignore les directives volume: , network: et deploy: . J'ai commencé à simplement fournir un fichier env au shell, à reconstruire un fichier de composition temporaire, puis à le déployer.

J'aimerais que les fichiers .env soient lus par défaut comme dans Docker Compose et que --env-file (court -e ) soit ajouté pour docker stack deploy pour pouvoir remplacer variables d'environnement et les valeurs par défaut du fichier .env .

+1
Il serait très pratique de lire le .env en premier lieu comme le fait docker-compose.
Soit par défaut, soit passez simplement le fichier env en tant que paramètre dans la ligne de commande de la pile docker.

Les deux solutions de contournement déjà mentionnées (_trouvez-les également ci-dessous_) semblent fonctionner bien qu'un peu laide par rapport au "correctif" proposé.

_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]_

J'ajouterais qu'avoir docker-compose installé uniquement pour pouvoir traiter ces variables peut aussi être assez dangereux en fait.

Si quelqu'un déployait la pile en utilisant docker-compose up -d par erreur au lieu d'utiliser le déploiement de la pile docker, cela entraînerait très probablement des erreurs d'application et une corruption de fichiers.

L'interpolation des variables d'environnement dans le déploiement est la meilleure solution pour l'intégration continue.

Un problème avec l'utilisation de '.env' est qu'il chevauche des noms de fichiers similaires utilisés, par exemple, Ruby on Rails, avoir la possibilité de spécifier un fichier d'environnement par argument est supérieur.

Les suggestions de @ntelisil sont bien prises, elles pourraient être complétées ou modifiées par :

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

Vous pouvez utiliser envsubst (partie de gnu gettext):
envsubst < fichier d'entrée

J'ai utilisé:

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

Et cela a bien fonctionné, mais j'avais besoin d'ajouter environ 3 Mo à mon conteneur.

Nice @rnickle , mais toujours "hacky" par rapport à Docker pouvant le faire comme avant. Il semble (et s'il vous plaît, les gars de Docker me corrigent si je me trompe) qu'il y a très peu d'efforts pour passer en mode essaim depuis l'annonce de la prise en charge de K8, donc je doute que l'une de ces régressions soit corrigée.

Et cela a bien fonctionné, mais j'avais besoin d'ajouter environ 3 Mo à mon conteneur.

Si les variables d'environnement sont définies, docker slack deploy devrait déjà les interpoler

par rapport à Docker pouvant le faire comme avant.

Docker n'a jamais eu cette fonctionnalité ; docker composer avait; docker compose et docker stack deploy partagent le _format de fichier_ mais pas nécessairement tous les comportements du logiciel lui-même.

qu'il y a très peu d'efforts pour passer en mode essaim depuis l'annonce de la prise en charge des K8

La gestion des fichiers de composition est entièrement effectuée côté client et utilisée à la fois pour k8s et swarmkit, donc rien ne ralentit dans ce domaine, à part "nous ne pouvons pas faire grand-chose à un moment donné".

Pour ceux qui attendent cette fonctionnalité ; la prochaine version prendra en charge plusieurs fichiers de composition pour docker stack deploy , donc si vous utilisez actuellement cette fonctionnalité dans docker compose : la prochaine version de docker le prendra également en charge

Sémantique mise à part, merci pour la mise à jour. Quand je dis Docker, je ne parle pas nécessairement du démon ou du moteur, mais de la société qui construit les outils. La genèse du commentaire sur le peu d'effort vient vraiment du fait que le mode essaim est sorti depuis plus d'un an et est toujours BIEN en retard par rapport à ce que nous étions avec un nœud unique utilisant la composition.

Je peux comprendre qu'ils sont différents, mais utilisent le même format de fichier, mais cela conduit en fait à plus de confusion, et potentiellement décevant, lorsque les utilisateurs découvrent qu'ils doivent échanger des fonctionnalités pour utiliser Swarm. Cela et le fait que les fichiers DAB sont TOUJOURS répertoriés comme expérimentaux. Malheureusement, nous avons pris la décision d'utiliser le mode essaim dans un gros projet, sinon je m'en ficherais. Heureusement, nous ne ferons plus cette erreur.

[Éditer]

Si les variables d'environnement sont définies, docker slack deploy devrait déjà les interpoler

Faire cela dans un environnement CI est une douleur royale. Essentiellement, j'ai fini par installer composer, rechercher les envvars, laver le fichier de composition (après avoir extrait les images), puis cracher un nouveau fichier de composition à utiliser avec stack deploy . (Et je ne commencerai même pas par dire à quel point c'est douloureux quand :latest ne signifie pas :latest en mode essaim, car ce problème concerne spécifiquement l'interpolation de variables.)

_EDIT : J'espère que ce message ne sera pas agressif. J'adore le concept Docker Stack et je pense que toute la suite Docker est assez bien prise en charge. Il semble simplement que Docker (l'organisation) ne considère pas actuellement ses produits de la même manière que les utilisateurs, ce qui est regrettable et semble être la cause de la plupart des problèmes que j'ai rencontrés lors de l'utilisation de Compose et Stack._

Docker n'a jamais eu cette fonctionnalité ; docker composer avait; docker compose et docker stack deploy partagent le format de fichier mais pas nécessairement tous les comportements du logiciel lui-même.

J'ai l'impression que cette déclaration révèle une déconnexion fondamentale entre la façon dont les développeurs et les utilisateurs de Docker voient ces produits. En tant qu'utilisateur, que je travaille avec Docker Engine, Docker Compose ou Docker Swarm, tout est Docker et doit se comporter de la manière la plus cohérente possible.

Ma compréhension de l'objectif de ces produits est la suivante :

  • Docker Engine permet de créer et d'exécuter des conteneurs individuels
  • Docker Compose permet d'exécuter une suite de conteneurs en développement
  • Docker Stack permet de déployer des conteneurs en production

L'un des principaux arguments de vente de Docker (et des conteneurs en général) est la réutilisation facile de la même application dans plusieurs environnements. Par conséquent, Compose doit être additif à Engine et Stack doit être additif à Compose. D'autant plus qu'ils partagent le même format de fichier, Stack ne prenant pas en charge les fonctionnalités de Compose entraîne une confusion pour les développeurs et une complexité accrue dans les processus CI.

Je ne dirais pas que la composition est pour le développement et la pile pour la production, nécessairement. Je considère la composition comme étant pour une application ou un "système" multi-conteneurs et une pile pour les déploiements multi-hôtes utilisant le mode essaim comme planificateur/orchestrateur. Sinon, votre commentaire est 100% juste. Je suis également frustré (si ce n'était pas évident par mes autres commentaires) qu'il y ait une déconnexion entre les développeurs et les utilisateurs quant à la façon dont le ou les produits sont utilisés.

Oh wow. J'ai rejoint la confusion et la douleur lors de l'évaluation de l'essaim de docker pour un grand projet également.
Les secrets sont tous amusants et ludiques, mais toutes les images docker externes ne prennent pas en charge la lecture des secrets à partir de fichiers. Je ne veux pas modifier pour chacun d'eux et placer une image personnalisée. Je pourrais les utiliser pour mes projets, oui, mais pour des projets externes, ce ne serait pas possible.
Cela laisse donc des variables env. Mais bon, ils se comportent différemment de composer à empiler ! Imaginez ma surprise quand j'ai remarqué qu'ils ne fonctionnent pas vraiment.
Comment est-il possible d'avoir une pile docker sans support env? Le mieux serait à mon avis --env-file=dev.env , donc cela n'interférerait pas avec les autres fichiers env ... mais le support pour cela est horrible. Je dois malheureusement revenir aux k8, car la pile manquant cela depuis le début pourrait s'avérer être un choix horrible pendant la production, qui sait combien d'autres choses manqueront.

Cela fait deux ans et nous sommes toujours comme ça... Je ne veux pas paraître grossier, mais allez ! Il s'agit de réutiliser un bout de code de docker-compose !

Un autre problème similaire que je viens de rencontrer est que même si vous utilisez env_file, le comportement n'est toujours pas exactement le même.

J'utilise env_file pour charger les chemins spécifiés à partir de la racine du projet, mais mon fichier de composition se trouve dans un sous-répertoire différent. Pour lancer avec docker-compose, j'utilise simplement --project-directory . -f chemin/vers/docker-compose.yml

docker stack ne me permet pas de spécifier le répertoire du projet, ce qui empêche le chargement de tous mes fichiers env_file.

Changer env_file en "../../path/to/envrc" ne fonctionne pas avec docker-compose, car ces fichiers doivent se trouver dans le répertoire racine du projet

+1

+1

+1 ce serait vraiment utile. Je ne vois pas vraiment d'inconvénient.

C'est incroyablement stupide que docker ne le supporte pas encore.

+1 @joao-fidalgo C'est définitivement le cas.

+1

Je viens de tomber sur la même chose alors que nous essayons l'essaim. J'ai lu tous les messages dans divers fils de discussion et je suis extrêmement frustré. IMO, de très bons points et des arguments solides ont été avancés par @ntwrkguru et d'autres. J'espère que nous pourrons les considérer pour intégrer cette fonctionnalité ; les hacks ne suffiront pas.

fichier .env

export MYSQL_USER=user

source .env && docker stack deploy

Cela fonctionnera également avec docker-compose up pour bash

fichier .env

export MYSQL_USER=user

source .env && docker stack deploy

Cela fonctionnera également avec docker-compose up

Cela ne fonctionnerait que pour bash et pas pour les autres shells.

Cela m'a confondu comme un fou. Mon application apparaîtrait en utilisant docker-compose, mais pas avec le déploiement de la pile docker. Il devrait au moins y avoir une clause de non-responsabilité affichée bien en évidence dans les documents

Mais IMO c'est un bug, et dégrade l'expérience docker.

Nous avons besoin d'une réponse à ce sujet

Près de 2 ans et personne ne l'a ramassé... ne retenez pas votre souffle @jorgelimafeitosa

Je ne pense pas que la CLI ajoutera un jour le support .env . La commande docker stack deploy a été construite à l'origine avec les fichiers de bundle d'applications distribuées à l'esprit (d'où l'option --bundle-file ). Les fichiers DAB ont été générés par Docker Compose avec la commande docker-compose bundle . .env et les autres fonctionnalités de composition seraient gérées par docker-compose , avant d'être transmises à docker stack deploy . La prise en charge directe des fichiers Compose dans docker stack deploy a toujours été davantage un compromis.

La promesse initiale des fichiers DAB se perpétue désormais dans l'application Docker, qui ne traite pas non plus .env .

Mes développeurs utilisent docker-compose config pour pré-traiter les projets Docker Compose avant de les transmettre à docker stack deploy . Vous pouvez le faire en une seule ligne avec :

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

De cette façon, toutes les fonctionnalités de Docker Compose, y compris le traitement .env , sont pleinement appliquées.

@kinghuang J'ai essayé votre solution, mais cela n'a pas fonctionné. "docker-compose config" produit la sortie correcte dans le même répertoire, mais "docker stack deploy -c docker-compose.yaml my_stack" ne remplacera pas les variables du fichier .env. Qu'est-ce que je rate? Il s'agit de Docker version 18.09.0, build 4d60db4.

@kinghuang J'ai essayé votre solution, mais cela n'a pas fonctionné. "docker-compose config" produit la sortie correcte dans le même répertoire, mais "docker stack deploy -c docker-compose.yaml my_stack" ne remplacera pas les variables du fichier .env. Qu'est-ce que je rate? Il s'agit de Docker version 18.09.0, build 4d60db4.

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

@kinghuang

ouvrez /dev/fd/63 : aucun fichier ou répertoire de ce type

ATTENTION : Certains services (projet1, projet2) utilisent la clé 'deploy', qui sera ignorée. Compose ne prend pas en charge la configuration 'deploy' - utilisez docker stack deploy pour déployer sur un essaim.

@kinghuang
Seul l'environnement racine ne signalera pas d'erreur.

La prise en charge de .env et env_file n'a pas toujours de sens dans un environnement de déploiement/production. Vous n'avez pas besoin d'un accès direct au système de fichiers pour aucune des autres fonctionnalités de Docker Swarm. Ainsi, un concepteur/opérateur responsable de ce système ne voudrait pas vous donner la possibilité de vider les fichiers d'environnement sur le système de fichiers.

Théoriquement, Swarm pourrait prendre en charge le chargement automatique de secrets dans l'environnement, mais voir https://github.com/moby/moby/issues/30866#issuecomment -278924983 pour savoir pourquoi cela pourrait ne pas être une bonne idée en termes de sécurité.

Ce que vous pouvez faire aujourd'hui, c'est utiliser des secrets et les charger dans l'environnement de votre application lorsque le conteneur s'exécute. Cela vous donne le contrôle sur l'endroit où les valeurs d'environnement secrètes peuvent être vues.

+1
docker stack deploy devrait vraiment prendre en charge --env-file.
Moi-même, j'ai du mal à réutiliser le même fichier .yml pour déployer différentes piles pour les environnements de développement/test/production et je ne veux pas gérer certaines exportations/approvisionnements fastidieux de variables d'environnement avant de déployer la pile. C'est très sujet aux erreurs (et une douleur dans le cul aussi pour se souvenir des commandes exactes à chaque fois).
Dans mon cas particulier, je veux par exemple définir différents noms d'index (elasticsearch) par environnement - mais le reste de la configuration reste le même. Cela n'a rien à voir avec les "secrets" comme mentionné dans les messages précédents.
Il semble y avoir un réel besoin de --env-file pour le déploiement de la pile docker sur la base de l'historique des commentaires ci-dessus, mais malheureusement, les développeurs Docker ne semblent pas le voir.

Dans mon environnement d'essaim, j'ai opté pour quelques solutions de contournement :

  • secrets/configs, que j'utilise pour charger les fichiers de configuration et les certificats.
  • Après avoir regardé une démo de l'environnement de développement Azure où ils avaient un script d'interpolation variable qu'ils exécutaient avant de soumettre un fichier de composition, j'ai écrit le mien que j'ai mis dans mon flux de publication GitLab.

Spécifiez simplement le fichier .env dans votre docker-compose.yml et cela fonctionne :

env_file:
  - .env

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

Un contournement en powershell à utiliser sur windows afin de parser le fichier .env avant d'appeler docker :

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

Grandement inspiré par l'analyse des fichiers .ini : https://stackoverflow.com/questions/417798/ini-file-parsing-in-powershell

Une autre solution de contournement est : set -a && . .env && set +a && docker stack deploy... .

C'est ridicule. J'ai juste passé toute la journée à essayer de faire fonctionner ça. Une clause de non-responsabilité est au moins nécessaire quelque part dans la documentation indiquant que .env n'est pas lu par les commandes docker stack .

@cjancsar Ils le font. La documentation dit:

Important : La fonctionnalité de fichier .env ne fonctionne que lorsque vous utilisez la commande docker-compose up et ne fonctionne pas avec le déploiement de la pile docker

Inintéressant. Que font actuellement les gens lorsqu'ils sont en mode essaim et qu'ils veulent mettre à jour leur image docker nouvellement construite, par exemple, application:v1 à application:v2 , même service (rien d'autre n'a changé) ?

C'est la raison pour laquelle je suis venu à cette question. C'est pourquoi je suis intéressé.

Actuellement dans docker-compose, il est trivial d'obtenir une automatisation pour interagir avec le fichier non suivi du contrôle de source . env pour mettre à jour la version de l'image, puis docker-compose up -d

J'utilise souvent le commit sha en tant que version d'image docker pour les déploiements de "mise en scène" (balises git utilisées pour les versions réelles après des cycles de test suffisants), il n'est donc pas vraiment possible de valider la nouvelle version d'image dans le contrôle de code source.

Est-il possible de mettre à jour un secret docker (même si ce n'est pas vraiment un secret) comme solution de contournement ? Est-ce que c'est ce que les gens font, ou est-ce qu'il y a autre chose qui est fait.

Je sollicite les futurs visiteurs de ce numéro, afin qu'ils repartent effectivement avec une bonne pratique actuelle, puisque la fonctionnalité qu'ils recherchaient n'existe pas (encore ?).

Salut, je suis occupé à étudier le déploiement de la pile pour une utilisation dans les pipelines CI/CD, pouvoir utiliser un fichier .env serait très utile, avez-vous des commentaires sur l'introduction de cette option à un moment donné ?

Il semble que la recommandation officielle soit, en effet, de migrer votre code image pour prendre en charge la lecture de ces types de variables à partir d'un fichier texte secret ± en conservant la possibilité de les lire également à partir de variables environnementales pour une compatibilité descendante non-pile/essaim.

L'exemple utilise un secret par fichier texte, ce qui évite d'avoir à analyser l'ancien fichier .env.

Paraphrasé à partir de la documentation sur 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

soupir

Cela devrait être plus clair dans la documentation. Bien qu'il soit indiqué que .env n'est pas pris en charge dans la section Substitution de variable par @lengxuehx , il n'est pas mentionné que env_file est ignoré pour les déploiements de pile.

Je peux confirmer que la solution proposée par @kinghuang fonctionne et n'exclut pas la clé de déploiement comme quelqu'un l'a dit.

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

Cela devrait être plus clair dans la documentation. Bien qu'il soit indiqué que .env n'est pas pris en charge dans la section Substitution de variable par @lengxuehx , il n'est pas mentionné que env_file est ignoré pour les déploiements de pile.

Je peux confirmer que env_file est utilisé et fonctionne pour la commande deploy stack, exactement comme le fait le 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

Pour résumer, pour les gens comme moi, qui ont lu ceci jusqu'à présent :

  • docker stack deploy prend en charge la "substitution de variables", mais vous devez définir les variables d'environnement à partir du fichier .env d'une manière ou d'une autre. Plusieurs options ont été expliquées ci-dessus. L'une des solutions de contournement les plus intéressantes consiste à utiliser docker-compose config comme pré-processeur.
    Vous pouvez donc créer votre pile avec docker stack deploy -c <(docker-compose config) STACK_NAME .
  • Bien que Docker ait introduit les capacités de configuration et de secrets , elles ont leurs cas d'utilisation mais ne feront pas la même chose que la "substitution variable".
  • Le paramètre env_file dans le fichier docker-compose.yml définira les variables d'environnement dans le conteneur créé et non sur le fichier docker-compose.yml lui-même (et par conséquent, il ne peut pas être utilisé comme alternative à " Substitution Variable").

Mettre à jour:

J'ai été corrigé par @thaJeztah.

Docker ne prend pas en charge la substitution de variables à l'aide du déploiement de la pile Docker, et aucune des solutions proposées ne fonctionne.

docker stack deploy prend en charge la substitution de variables, mais n'évalue pas le fichier .env ; dans l'exemple ci-dessous, HELLO_VERSION est défini sur linux , et le service utilisera la balise hello-world:linux (au lieu de la valeur par défaut 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

Cela étant dit, vous pouvez toujours utiliser des variables d'environnement en utilisant le paramètre env_file dans votre fichier docker-compose.yml

Le env_file a un but différent (et est l'équivalent de docker run --env-file ) ; l'option env_file spécifie les env-vars à définir sur le conteneur créé, mais n'est pas utilisée dans le fichier de composition lui-même (et n'est pas utilisée pour remplacer les variables dans le fichier de composition avant de déployer la pile).

J'ai eu le même problème avec d'autres légères différences entre docker-compose et docker stack.
J'ai fini par créer https://github.com/egyel/dcsh script/tool ​​pour gérer ce problème avec les tuyaux.

image
Bonjour à tous, cela m'a aidé à mettre env_file dans mon docker-compose :

env_file: /path/to/env/file
ne pas

env_file:
  - /path/to/env/file

Je viens de voir cela dans un autre article et je ne peux que spéculer sur la raison pour laquelle cela fonctionne (comme votre spéculation), mais nous avons besoin d'une confirmation quant à la raison pour laquelle cela fonctionne comme docker explicitement mentionné dans le docu selon lequel env_file ne fonctionne pas.

Ma compréhension est que les fichiers env ne peuvent pas être utilisés pour remplir les espaces réservés dans
le fichier docker-stack.yml mais ils peuvent toujours être fournis aux conteneurs.
Notez que ce que vous faites ne vous permet pas de définir le nom de l'image à partir de
le fichier env par exemple.

Le dimanche 17 mai 2020, 06:08, raphyphy [email protected] a écrit :

[image : image]
https://user-images.githubusercontent.com/30310576/82135555-a1e4be00-9836-11ea-9df4-a1b82e014b0e.png
Bonjour à tous, cela m'a aidé à mettre env_file dans mon docker-compose :

env_file : /chemin/vers/env/fichier
ne pas

fichier_env :

  • /chemin/vers/env/fichier

je viens de voir cela dans un autre post et je ne peux que spéculer pourquoi cela fonctionne
(identique à votre spéculation) mais nous avons besoin de confirmation quant à la raison pour laquelle cela est
travailler comme docker explicitement mentionné dans le document que env_file ne fait pas
travail.


Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/29133#issuecomment-629740002 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/ABHLQMCARDQGJQIBWCQKAYLRR5PMHANCNFSM4CYRHCTA
.

La solution docker-compose mentionnée ci-dessus :

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

a l'inconvénient (pour moi) que des choses comme les fichiers .env et, surtout, les fichiers docker-compose.override.yml font normalement plus partie de mon environnement de développement . Je ne veux pas vraiment que ceux-ci soient apportés lors du déploiement en production.

J'ai fini par avoir un docker-compose-production.yml séparé dans lequel je contrôlais soigneusement les choses, même si cela impliquait des doublons.

Je ne pense pas que la CLI ajoutera un jour le support .env . La commande docker stack deploy a été construite à l'origine avec les fichiers de bundle d'applications distribuées à l'esprit (d'où l'option --bundle-file ). Les fichiers DAB ont été générés par Docker Compose avec la commande docker-compose bundle . .env et les autres fonctionnalités de composition seraient gérées par docker-compose , avant d'être transmises à docker stack deploy . La prise en charge directe des fichiers Compose dans docker stack deploy a toujours été davantage un compromis.

La promesse initiale des fichiers DAB se perpétue désormais dans l'application Docker, qui ne traite pas non plus .env .

Mes développeurs utilisent docker-compose config pour pré-traiter les projets Docker Compose avant de les transmettre à docker stack deploy . Vous pouvez le faire en une seule ligne avec :

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

De cette façon, toutes les fonctionnalités de Docker Compose, y compris le traitement .env , sont pleinement appliquées.

Cela fonctionne comme un charme, gardez à l'esprit que si votre fichier de composition n'a pas le nom "docker-compose.yml", votre commande doit inclure le nom réel du fichier de composition.

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

Méfiez -vous du <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config HACK !!! La sortie de docker-compose config et docker-compose -f myfile.yml config n'est PAS nécessairement la même ! Ce dernier enveloppe parfois les variables env dans des guillemets supplémentaires, de sorte que la sortie sera erronée !

Exemple:

environment:
  SERVER_URL: '"xxx"'

à la place de

environment:
  SERVER_URL: xxx

Ce problème est-il déjà suivi quelque part ?

Cette page vous a été utile?
0 / 5 - 0 notes