Moby: 1.13の `docker stack deploy`は、` docker-composeup`のように `.env`ファイルをロードしません

これは仕様によるものです。 .envのサポートは、ファイル形式ではなく、作成の機能です。

将来のリリースでこれを追加することについて話し合うことはできますが、それが本当に最良のオプションであるかどうかはわかりません。

.envのサポートは、作成で非常に役立ちます。多くの作成ファイルで使用しました。 docker-compose.ymlファイルの動的部分と静的部分を分離します。 デフォルトでロード.envを使用すると、環境ごとに異なる.envファイルを提供し、 docker-compose.ymlと関連するスクリプトを静的に保つことができます。

docker-compose.yml env_fileまたはenvironment $を使用して、同じenvvars置換結果を達成することはできません。 .envはそれを行う最も簡単な方法です。

それ以外の場合は、 .envファイルの各行にexportのプレフィックスを付け、 docker-compose.ymlをロードする前に毎回手動でsource .envを付ける必要があり、余分な手順が発生することがあります。間違える。

私はちょうどこれに気づきました。
Composeの場合と同じように機能すると想定/期待していましたが、 docker deployの場合はそうではありません。

私の特定のケースでは、 .envファイルを使用して、スタックに作成するサービスで使用される機密データ（パスワード、APIキーなど）を格納することを期待していました。

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

この作成ファイルはGitにチェックインされますが、 .envファイルは無視されます。

* .dabとcomposeファイルのすべての内容/履歴をたどりましたが、皆さんは何かを避けようとしている、またはより良い解決策を提案しているように感じますが、議論全体を見失いました...

皆さんこんにちは、

Dockerバージョン：v1.13.0-rc4

エラーが発生します：サポートされていないオプションを無視します：ビルド、Dockerfileからビルドを作成しないという意味ですか？

また、network_modeでも同じエラーが発生します：サポートされていないオプションを無視します：network_mode。

以下はコマンドです：
DOCKER_IMAGE = akhil123 docker stack deploy -c docker-compose.yml foo

よろしくお願いします。

@akhildangore直接関係のない質問については、コメントしないでください。 docker stack deploy機能、_bydesign_はビルドを実行しません。 この理由は、コマンドの実行元のホストで_build_が実行されるため、イメージは_that_ノードでのみ使用可能になるためです。 そのイメージをSwarmにデプロイする場合、他のノードでサービスを開始することはできません。 サービスをデプロイするには、デプロイするイメージがレジストリにプッシュされていることを確認します（またはテストのために、イメージが群れのすべてのノードで使用可能であることを確認します）

docker deployでこの動作をサポートすることに賛成/反対するケース/ディスカッションはありますか？

@vovimayhem .envファイルについてはまだ決定されていませんが、作成ファイルにシークレットのサポートを追加するhttps://github.com/docker/docker/pull/30144に興味があるかもしれません。

私はちょうどその議論を見つけました。 優れた！

回避策としてbash関数を使用しています。

secrets機能がリリースされるまで、ニーズに合わせて調整できます。

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

この問題を購読している人のために; docker-composeファイルのシークレットサポートは1.13.1リリースに含まれる予定ですが、将来的にはそれほど遠くないはずです。

@whoanこれを回避策として使用しています：

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

そうすれば、変数がターミナルウィンドウでスタックすることはありません

.envファイルから物事をロードする機能があることは常に素晴らしいことです-回避できるより単純なDockerシークレットのユースケースを除いて、ハードコーディングしたくないDockerCompose値が常にありますリポジトリ内。

docker stack deployを使用して完全なスタックをデプロイし、次の要件があると仮定します。

• ステージングと本番環境など、さまざまな環境でまったく同じ構成を使用したい
  
  
  
  • 環境ごとに異なるスケール値が必要です
  
  

.envファイルでこれを構成できない場合は、毎回スタックをデプロイする前にdocker-compose.ymlファイルを手動で変更する必要があります。そうしないと、サービススケール値が1に戻ります。

ネットワーク、サービスがリッスンするDNSの構成など、上記を拡張できます。

上記のユースケースが理にかなっていると思われる場合、 docker-compose.ymlと同じディレクトリにファイルが存在する場合、 .envファイルをロードするPRを作成できます。

docker stack deployの設計は、 docker-composeコマンドとは少し異なります。 デフォルトで.envを読むだけでは意味がないと思います。 docker-compse.ymlでさえ、デフォルトでは読み取られません。将来、デフォルトのデプロイソースが別のものになる可能性があるためです。

stack deployを実行する前に、いつでも自分で.envファイルを入手できます。

$ docker stack deployを呼び出す前の. .envだけでは役に立ちません。$変数は置き換えられません。 env .. xargsのトリックだけが役に立ちました。
docker run --env-file=FILEオプションがあると便利です。

ただ 。 docker stackdeployを呼び出す前の.envは役に立ちません

これは@ C-Proに役立つはずです- .envファイルにexport ...行が必要です。 または、 export $(cat .env)を実行することもできます。これは、ほとんどの場合に機能します。

皆さんこんにちは、
今日はdocker stack deployを実行しようとしました。
私のdocker-compose.ymlファイル：

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

同じディレクトリにある.envファイル：

BAR=worked

docker stack deploy -c docker-compose.yml testを起動した後、コンテナを調べて次のように取得しました。

$ env
BAR=worked
FOO=
...

.envはコンテナで提供されていますが、ホストマシンでは提供されていないようです。
つまり、 environment .envファイルを使用できますが、変数置換で.envファイルを使用することはできません。
Dockerバージョン：v17.03

@ddpaimon
環境：
--FOO = $ {BAR}

.envファイルはコンテナーに対してのみ機能し、docker-compose.ymlファイル変数の置換に対しては機能しないようです。

Docker for MAC、Dockerバージョン17.03.1-ce、ビルドc6d412e

@realcbb
はい。 ただし、コンテナ内で.envファイル変数を使用するには、 environmentセクションでそれらを削除する必要があります。
例えば：
docker-compose.yml

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

.env

FOO=filled

コンテナで私はこれを手に入れました：

$ env
FOO=empty

しかし、 docker-compose.ymlのenvironment FOOを削除すると、次のようになります。

$ env
FOO=filled

@ddpaimon
環境で指定された環境変数は、.envファイルで指定されたこれらの値をオーバーライドします。

@dnephin ：.envはdockercomposeファイル形式の一部ではないと述べています。 ただし、.envファイル機能は、ファイルの作成バージョン3リファレンス（ https://docs.docker.com/compose/compose-file/#variable -substitution）に記載されています。
これにより、.envはdocker stackdeployでも機能するはずであるという印象を与えます。
それに加えて、他の人がすでに述べたように、実際の環境固有の値をスタック定義yamlから分離することは、非常に必要とされている機能です。 具体的には、これを使用してイメージのバージョンと複製を指定します。

おかげで、私はドキュメントを修正するためにhttps://github.com/docker/docker.github.io/issues/3654を開きました

docker stack deployは、生成されたファイルを取ることができます。 これは私のすべての変数に対してbashで機能し、秘密も秘密にします。

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

インラインENV変数を追加の変数またはオーバーライドとして追加したことに注意してください。 私の作成ファイルは.envファイルを参照しており、これは機能します。 これがお役に立てば幸いです👍

docker-compose configの機能は、これを結び付けるものです。

.envがdocker stack deployに読み込まれないという解決策を探しているときに、この問題に遭遇しました。 サポートされていないことに少し驚いていましたが（ドキュメントを明確にすることができました）、composeのように.envのサポートを追加したいと思います。

私のユースケースは、開発、テスト、ステージング環境でdocker stack deployを使用し、スタックオプションに環境変数を使用してymlファイルを同じに保つことです。

現在、ここに掲載されている回避策の1つを使用していますが、 .envファイルを使用することをお勧めします。

わかりやすいリマインダー：dotenvファイルを使用して、クラスターに配置するのに「機密」と見なされるAPIキー、パスワード、その他のものを保存しようとしている可能性があります。 このような場合は、 Dockerシークレットを使用する必要があります。

他のものについては、デプロイ/デプロイ可能な環境ごとに1つの作成ファイルを用意することをお勧めしますか？ 異なる環境間で変更されるもののほとんどは、使用可能なサーバー、異なるサーバー組織などです。したがって、 deployキーコンテンツ（ placementルール、 resources ）に異なる値が必要になります。

実際にこの機能が必要なのですが、Docker Stack Deployを使用する場合、作成ファイル内の変数を異なるホストで異なる値として扱うことができます。

「他のものについては、デプロイ/デプロイ可能な環境ごとに1つの作成ファイルを用意することをお勧めしますか？異なる環境間で変更されるもののほとんどは、使用可能なサーバー、異なるサーバー組織などです...したがって、デプロイキーに異なる値が必要です内容（配置ルール、リソース予約など）、すべてに1つのファイルを使用するのは少し複雑すぎます。」

@vovimayhem率直に言って申し訳ありませんが、env_fileを使用して変数を置換した単一の作成ファイルを使用するほど意味がありません。 env_file形式を使用することをお勧めします。これにより、スタックを成果物として顧客に提供し、単一のiniスタイルのvarsファイルを更新するようにトレーニングする方が、作成ファイルを混乱させるよりもはるかに簡単になります（私はこれを行います）。 'したくない）。

@ntwrkguru https://docs.docker.com/engine/swarm/configs/

サービス構成は優れた追加機能ですが、展開時間の補間には使用できないようです（$ TAGなど）。

環境変数がまったくサポートされている場合は、ツール間でそれらを解決するために使用されるメカニズムに一貫性があります。 スタックのデプロイは、環境変数の動作を根本的に変更せずに、一貫性がないことを選択しているようです。 シークレットとサービス構成は、環境変数のいくつかの使用法のより良い代替手段ですが、それらは包含しません。

@vovimayhemでは取得できないようです。 envをコンテナに渡すことについて話しているのではありません。 それは期待どおりに機能します。 つまり、 compose upのときと同じように、 stack deployの間に解析されるenv_fileを使用するということです。

@ntwrkguruこの新機能があなたを助けると思っただけです...私はそれが役に立たないのでとても悲しいです。

これはまだ代替手段として機能します。

$ 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 、確かにそうです。 プレイブックに環境ファイルを調達するタスクがありますが、それは大きなポイントを欠いています。 これは、以前はcomposeで可能でしたが、現在はstackでは不可能です。 IMO、それは回帰です。 また、あなたの例では、まだ環境変数をコンテナに渡しています。 今日はenv_filesでそれができます。 問題は、 stack deploy -c docker-compose.yml操作中にenv_fileを解析することです。

stackは複数の作成ファイルをサポートしなくなったため、これは特に苦痛です。そうでなければ、環境ごとに2番目の作成ファイルを使用するだけで済みます。 そのようにするには、作成ファイルからスタックファイルを作成する必要があり、別の手順が必要になります。 したがって、どちらの見方をしても、同じ最終結果を達成するために、シングルステッププロセスからマルチステッププロセスに移行しました。

また、FWIW、 configsは、実際の構成の私の経験では実際には劣っています。 私は、ソースに/application/config.confを含めることができると想像していました（期待していました）。 そのファイルを更新し、コミット、プッシュすると、CIは新しい構成でスタックを再デプロイします。 これは、ファイル名やその他のメカニズムを変更するためのハッカーなしでは不可能です。 確かに、少なくともファイルをチェックサムするか、コンテンツの変更をスキャンしてファイル自体に基づいて更新することができますか？ 全体として、私たちは後退しているように見えます。 今すぐK8sのサポートを投入すると、群れが静かに落とされるのに十分な使用量を失うまで、つるで群れが衰えるのではないかと思います。

また、FWIW、構成は実際の構成の私の経験では本当に劣っています。 私は/application/config.confをソースに含めることができると想像していました（期待していました）。 そのファイルを更新し、コミット、プッシュすると、CIは新しい構成でスタックを再デプロイします。 これは、ファイル名やその他のメカニズムを変更するためのハッカーなしでは不可能です。

@ntwrkguru簡単な回避策は、ファイル名ではなく、構成自体の名前を変更することです。 構成名にバージョンスキームを採用しました。例： config_v1 、 config_v2 、..

したがって、構成ファイルを変更した後は、そのバージョンを更新することを忘れないでください。

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

configs:
  config_v2:
    file: ./config.yml

バージョン管理された構成とシークレットがまだない理由を理解しているので、個人的には現在、この（簡単な）回避策で問題ありません。

@djmazeに感謝しますが、すべてのソース管理システムに固有のバージョン追跡が組み込まれている場合、これは最終的にはばかげたことです。 また、リンクをありがとう。 私もそこにコメントしました。 Dockerが現在のバージョン以外のバージョンを気にする理由がわかりません。 これらをバージョン管理する必要があると私が判断した唯一の理由はロールバックのためですが、とにかくそこにもたくさんのことを追跡する必要があるので、さらにいくつか何がありますか？ （コードを書く必要がない人は言う）:-)

これを試して：
echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

docker-composeを使用して構成ファイルを解析し、env varsに置き換えて、出力から警告を取り除き、stdinを介してdocker stackdeployにパイプします。
'-f stack.yml'を構成ファイルの名前に置き換えるか、省略してデフォルトのdocker-compose.ymlを使用します。

+1

1年後、まだこれをハックして機能させる必要があります。 17.09.1の時点では、 docker stack deploy -f compose.ymlは既知のシェル変数を使用して代用することさえありません。

$ 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

タグの変数はinvalid reference formatを生成します。

1年後、まだこれをハックして機能させる必要があります。 17.09.1の時点で、docker stack deploy -f compose.ymlは、既知のシェル変数を使用して置換することさえしません。

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   

ありがとう、しかしファイルからの変数置換を単にサポートすることについて何か言葉はありますか？

[編集] Ansibleを使用してbecome: yesでタスクを実行しているので、これは問題にはならないはずです（ただし、問題になる可能性があります）が、ユーザーは環境変数を取得するのと同じユーザーです。

これが不可能だとは信じられません。 単一のスタックファイルを保持し、動的変数を使用して展開オプションを変更できるようにしたいと考えています。

これは機能しますが、醜くてハックです：

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

私はこれを何時間もいじっていて、これらのさまざまな部分からDABファイルを作成するためにいくつかのバックグラウンドスクリプト作業（これを行うためにCIを使用します）を行っているように見えます。 これを行うDockerツールがあると便利です... :-) docker-compose bundleに--env-file version.envを追加するかもしれませんか？

私のユースケースでは、 version.envの「マニフェスト」を使用して、プラットフォームを構成するコンテナー/イメージのバージョンを追跡および制御したいと考えています。 私のプロセスは次のようになります。

• .envファイルを更新します
• .envファイルをソースしてシェル変数にデータを入力します
• docker-compose -f stack.yml config > docker-compose.yml実行します
• docker-compose pullを実行して、画像ダイジェストを登録します
• docker-compose bundle -o stack.version.dab DABファイルを実行します

この時点で、理想的にはdocker deploy --host manager.swarm.com --bundle-file stack.version.dab --with-registry-auth --resolve-image always stack-nameができるはずですが、今は不可能だと思います。 この場合、DABファイルをマネージャーにscpして、 docker deployを実行します。

これは、Dockerが@thaJeztahで念頭に置いていたワークフローですか？ もっと良い方法はありますか？

[編集] DABはvolume: 、 network: 、およびdeploy:ディレクティブを無視するため、これは機能しません。 単純にenvファイルをシェルにソーシングし、一時作成ファイルを再構築してから、それをデプロイすることにしました。

.envファイルがDocker Composeのようにデフォルトで読み取られ、 --env-file （短い-e ）がdocker stack deployに追加されて、オーバーライドできるようになるといいのですが。 .envファイルの環境変数とデフォルト。

+1
docker-composeのように、最初に.envを読み取ると非常に便利です。
デフォルトで、または単にenvファイルをdockerstackコマンドラインのパラメーターとして渡します。

提案された「修正」と比較すると少し醜いですが、すでに述べた2つの回避策（_以下でも見つける_）は機能しているようです。

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

これらの変数を処理できるようにするためだけにdocker-composeをインストールすることも、実際には非常に危険である可能性があることを付け加えておきます。

docker stack deployを使用する代わりに、誤ってdocker-compose up -dを使用してスタックをデプロイすると、アプリケーションエラーやファイルの破損が発生する可能性があります。

デプロイ時に環境変数の補間を行うことは、継続的インテグレーションに最適なソリューションです。

'.env'の使用に関する問題の1つは、たとえばRuby on Railsで使用される同様のファイル名と重複し、引数で環境ファイルを指定する機能が優れていることです。

@ntelisilの提案はよく理解されており、次の方法で補足または変更できます。

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

envsubst（gnu gettextの一部）を使用できます。
envsubst <infile

私が使用した：

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

それはうまくいきましたが、コンテナに3Mb程度を追加する必要がありました。

素晴らしい@rnickleですが、Dockerが以前の方法でこれを実行できるのと比較すると、それでも「ハッキー」です。 K8sサポートの発表以来、スウォームモードに入る作業はほとんどないようです（そして、Dockerが間違っている場合は訂正してください）。したがって、これらのリグレッションのいずれかに対処できるかどうかは疑わしいです。

それはうまくいきましたが、コンテナに3Mb程度を追加する必要がありました。

環境変数が設定されている場合、 docker slack deployはすでにそれらを補間しているはずです

Dockerが以前の方法でこれを実行できるのと比較して。

Dockerにはこの機能はありませんでした。 dockercomposeが持っていた; dockercomposeとdockerstack deployは_fileformat_を共有しますが、必ずしもソフトウェア自体のすべての動作を共有するわけではありません。

K8sサポートの発表以来、スウォームモードに入る作業はほとんどありません。

作成ファイルの処理はすべてクライアント側で行われ、k8sとswarmkitの両方で使用されるため、この領域で速度が低下することはありません。

その機能を待っている人のために; 今後のリリースでは、 docker stack deployの複数の作成ファイルがサポートされるため、現在docker composeでその機能を使用している場合は、次のDockerリリースでもこれがサポートされます。

セマンティクスはさておき、更新してくれてありがとう。 Dockerと言うとき、私は必ずしもデーモンやエンジンを意味するのではなく、ツールを構築する会社を意味します。 努力がほとんどないというコメントの起源は、スウォームモードが1年以上使用されておらず、composeを使用したシングルノードの場合よりもはるかに遅れているという事実に由来しています。

それらは異なっているが、同じファイル形式を使用していることは理解できますが、ユーザーが群れを使用するために機能を交換する必要があることに気付いた場合、実際には混乱が生じ、失望する可能性があります。 それとDABファイルがまだ実験的なものとしてリストされているという事実。 残念ながら、私たちは大きなプロジェクトでswarm-modeを使用することを決定しました。そうしないと、私も気にしません。 幸いなことに、私たちはその間違いを二度と犯しません。

[編集]

環境変数が設定されている場合、docker slackdeployはすでにそれらを補間しているはずです

CI環境でこれを行うことは、王室の苦痛です。 基本的に、composeをインストールし、envvarsをソーシングし、composeファイルを（イメージをプルした後）洗い流してから、 stack deployで使用するために新しいcomposeファイルを吐き出すことになりました。 （そして、この問題は特に変数の補間に関するものなので、 :latest ＃$がスウォームモードで:latestを意味しない場合、それがどれほど苦痛であるかについては始めません。）

_編集：この投稿が積極的に出くわさないことを願っています。 私はDockerStackの概念が大好きで、Dockerスイート全体がかなりよくサポートされていると思います。 Docker（組織）は現在、ユーザーと同じように製品を表示していないようです。これは残念なことであり、ComposeとStackを使用して遭遇したほとんどの問題の原因であるようです。_

Dockerにはこの機能はありませんでした。 dockercomposeが持っていた; dockercomposeとdockerstack deployはファイル形式を共有しますが、必ずしもソフトウェア自体のすべての動作を共有するわけではありません。

このステートメントは、Dockerの開発者とユーザーがこれらの製品を見る方法の間の根本的な断絶を明らかにしているように感じます。 ユーザーとして、Docker Engine、Docker Compose、Docker Swarmのいずれを使用していても、すべてDockerであり、可能な限り一貫して動作する必要があります。

これらの製品の目的についての私の理解は次のとおりです。

• Docker Engineは、個々のコンテナーを構築および実行するためのものです
• Docker Composeは、開発中の一連のコンテナーを実行するためのものです
• Docker Stackは、コンテナーを本番環境にデプロイするためのものです

Docker（および一般的なコンテナー）の主なセールスポイントの1つは、複数の環境で同じアプリを簡単に再利用できることです。 したがって、作成はエンジンに追加する必要があり、スタックは作成に追加する必要があります。 特に、同じファイル形式を共有するため、スタックがComposeの機能をサポートしていないと、開発者が混乱し、CIプロセスが複雑になります。

必ずしも、composeがdev用で、stackがprod用であるとは言えません。 私は、composeをマルチコンテナーアプリケーションまたは「システム」用であり、スケジューラー/オーケストレーターとしてswarm-modeを使用するマルチホストデプロイメント用のスタックであると考えています。 それ以外の場合、あなたのコメントは100％スポットです。 また、製品がどのように使用されているかについて、開発者とユーザーの間に断絶があることに不満を感じています（他のコメントで明らかでなかった場合）。

ああすごい。 大きなプロジェクトでもDockerSwarmを評価しているときに、混乱と苦痛に加わりました。
シークレットはすべて楽しくてゲームですが、すべての外部Dockerイメージがファイルからのシークレットの読み取りをサポートしているわけではありません。 それぞれを変更してカスタムイメージを配置したくありません。 はい、私のプロジェクトにそれらを使用するかもしれませんが、外部プロジェクトには使用できません。
つまり、env変数が残ります。 しかしねえ、彼らは作曲ごとに異なった振る舞いをします！ それらが実際には機能しないことに気付いたときの驚きを想像してみてください。
envサポートなしでdockerスタックを作成するにはどうすればよいですか？私の意見では--env-file = dev.envであるため、他のenvファイルに干渉しません...しかし、これのサポートはひどいものです。 残念ながら、k8sに戻らなければなりません。最初からこれが欠落しているスタックは、他にいくつ欠落しているのかを知っている本番環境では、恐ろしい選択になる可能性があります。

２年経ちましたが、今でもそうです…失礼に出くわしたくないのですが、是非！ docker-composeのコードを少し再利用する必要があります。

私が遭遇したもう1つの同様の問題は、env_fileを使用しても、動作がまったく同じではないということです。

env_fileを使用して、プロジェクトルートから指定されたパスをロードしますが、作成ファイルは別のサブディレクトリにあります。 docker-composeで起動するには、-project-directoryを使用します。 -f path / to / docker-compose.yml

docker stackではプロジェクトディレクトリを指定できないため、すべてのenv_fileの読み込みに失敗します。

env_fileを "../../path/to/envrc"に変更しても、docker-composeでは機能しません。これらのファイルはプロジェクトのルートディレクトリ内にある必要があるためです。

+1

+1

+1これは本当に便利です。 マイナス面はあまり見ないでください。

dockerがこれをまだサポートしていないのは信じられないほど愚かです。

+1 @ joao-fidalgo確かにそうです。

+1

私たちが群れを試しているのと同じことに遭遇しました。 私はさまざまなスレッドのすべてのメッセージを読みましたが、非常にイライラしています。 IMO、いくつかの本当に良い点と強い議論が@ntwrkguruと他の人によってなされました。 私たちは、彼らがこの機能を取り入れることを検討できることを願っています。 ハックはそれをカットしません。

.envファイル

export MYSQL_USER=user

source .env && docker stack deploy

また、bashのdocker-compose upでも機能します

.envファイル

export MYSQL_USER=user

source .env && docker stack deploy

docker-compose upでも動作します

これはbashでのみ機能し、他のシェルでは機能しません。

これは私を狂ったように混乱させました。 私のアプリはdocker-composeを使用して起動しますが、docker stackdeployでは起動しません。 少なくとも、ドキュメントに目立つように表示されている免責事項があるはずです

しかし、IMOはこれがバグであり、Dockerエクスペリエンスを低下させています。

これについての答えが必要です

ほぼ2年、誰もそれを手に入れていません...息を止めないでください@jorgelimafeitosa

CLIが.envのサポートを追加することはないと思います。 docker stack deployコマンドは、もともと分散アプリケーションバンドルファイルを念頭に置いて作成されました（したがって、 --bundle-fileオプション）。 DABファイルは、DockerComposeによってdocker-compose bundleコマンドを使用して生成されました。 .envおよびその他の作成機能は、 docker stack deployに渡される前に、 docker-composeによって処理されます。 docker stack deployでのファイルの作成の直接サポートは、常に妥協点でした。

DABファイルの当初の約束は、現在、 .envも処理しないDockerアプリで有効です。

開発者にdocker-compose configを使用して、Docker Composeプロジェクトをdocker stack deployに渡す前に前処理してもらいます。 これは、次の方法で1行で実行できます。

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

このようにして、 .env処理を含むすべてのDockerCompose機能が完全に適用されます。

@kinghuangソリューションを試しましたが、機能しませんでした。 「docker-composeconfig」は同じディレクトリに正しい出力を生成しますが、「docker stack deploy -c docker-compose.yamlmy_stack」は.envの変数を置き換えません。 私は何が欠けていますか？ これはDockerバージョン18.09.0、ビルド4d60db4です。

@kinghuangソリューションを試しましたが、機能しませんでした。 「docker-composeconfig」は同じディレクトリに正しい出力を生成しますが、「docker stack deploy -c docker-compose.yamlmy_stack」は.envの変数を置き換えません。 私は何が欠けていますか？ これはDockerバージョン18.09.0、ビルド4d60db4です。

docker stack deploy -c <（docker-compose -f docker-compose-frpc-swarm-traefik.yml config）traefik

@kinghuang

/ dev / fd / 63を開きます：そのようなファイルまたはディレクトリはありません

警告：一部のサービス（project1、project2）は 'deploy'キーを使用しますが、これは無視されます。 Composeは「deploy」構成をサポートしていません- docker stack deployを使用して群れにデプロイします。

@kinghuang
ルート環境のみがエラーを報告しません。

.envとenv_fileをサポートすることは、デプロイメント/本番環境では必ずしも意味がありません。 Docker Swarmの他の機能のために、ファイルシステムに直接アクセスする必要はありません。 したがって、そのシステムの責任ある設計者/オペレーターは、環境ファイルをファイルシステムにダンプする機能を提供したくないでしょう。

理論的には、Swarmは環境へのシークレットの読み込みを自動的にサポートできますが、セキュリティの観点からそれが適切でない理由については、 https： //github.com/moby/moby/issues/30866#issuecomment-278924983を参照してください。

今日できることは、シークレットを使用して、コンテナーの実行時にアプリの環境にシークレットをロードすることです。 これにより、秘密の環境値を表示できる場所を制御できます。

+1
docker stackdeployは実際に--env-fileをサポートする必要があります。
私自身、同じ.ymlファイルを再利用して、開発/テスト/本番環境用に異なるスタックをデプロイするのに苦労しています。スタックをデプロイする前に、環境変数の面倒なエクスポート/ソーシングに対処したくありません。 これは非常にエラーが発生しやすくなります（また、毎回正確なコマンドを覚えるにはa **も苦痛になります）。
私の特定のケースでは、たとえば、環境ごとに異なるインデックス名（elasticsearch）を設定したいのですが、残りの構成は同じままです。 これは、以前の投稿で述べたように「秘密」とは何の関係もありません。
上記のコメント履歴に基づくと、Dockerスタックのデプロイには--env-fileが本当に必要なようですが、残念ながらDocker開発者はそれを認識していないようです。

私の群れの環境では、いくつかの回避策に落ち着きました。

• 設定ファイルと証明書をロードするために使用しているsecrets / configs。
• 作成ファイルを送信する前に実行される可変補間スクリプトがあるAzure開発環境のデモを見た後、GitLabリリースフローに入れた独自のスクリプトを作成しました。

docker-compose.ymlで.envファイルを指定するだけで、次のように機能します。

env_file:
  - .env

https://stackoverflow.com/questions/44694640/docker-swarm-with-image-versions-externalized-to-env-fileを参照してください

dockerを呼び出す前に.envファイルを解析するためにWindowsで使用するPowerShellの回避策：

switch -regex -file "./。env" {"^ \ s （[^＃]。+？）\ s = \ s （。 ）" {$ name、$ value = $ matches [1..2]; Set-Item "env：$ name" $ value}}

.iniファイルの解析に大きく影響を受けています： https ：//stackoverflow.com/questions/417798/ini-file-parsing-in-powershell

別の回避策は次のとおりです： set -a && . .env && set +a && docker stack deploy... 。

ばかげてる。 私はこれを機能させるために一日中過ごしました。 少なくともドキュメントのどこかで、.envがdocker stackコマンドによって読み取られないという免責事項が必要です。

@cjancsar彼らはそうします。 ドキュメントには次のように書かれています。

重要：.envファイル機能は、docker-compose upコマンドを使用する場合にのみ機能し、docker stackdeployでは機能しません。

興味がない。 人々は現在、スウォームモードで何をしていて、新しく構築されたDockerイメージを、たとえば、アプリケーション：v1からアプリケーション：v2に、同じサービス（他に何も変更されていない）に更新したいと考えていますか？

これが私がこの問題に出くわした理由です。 だから私は興味があります。

現在docker-composeでは、自動化してソース管理の追跡されていないファイル. envを操作して画像バージョンを更新し、次にdocker-compose up -dを操作するのは簡単です。

多くの場合、コミットshaを「ステージング」デプロイのDockerイメージバージョン（十分なテストサイクル後の実際のリリースに使用されるgitタグ）として使用するため、新しいイメージバージョンをソース管理にコミットすることは実際には不可能です。

回避策として、Dockerシークレットを更新することは可能ですか（実際にはシークレットではありませんが）？ それは人々がしていることなのか、それとも他に何かされていることなのか。

彼らが探していた機能が（まだ？）存在しないので、彼らが実際に現在のベストプラクティスを思い付くように、私はこの問題の将来の訪問者を求めています。

こんにちは、私はCI / CDパイプラインで使用するためのスタックデプロイを検討するのに忙しいです。.envファイルを使用できることは非常に便利です。このオプションがいずれかの段階で導入されるかどうかについてのフィードバックはありますか？

実際、公式の推奨事項は、シークレットテキストファイルからのこれらのタイプの変数の読み取りをサポートするように画像コードを移行することです。±非スタック/スウォームの下位互換性のために、環境変数からもこれらを読み取る機能を保持します。

この例では、テキストファイルごとに1つのシークレットを使用しているため、古い.envファイルを解析する必要がありません。

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

はぁ

これは、ドキュメントでより明確になっているはずです。 @lengxuehxのVariableSubstitutionセクションでは.envがサポートされていないことが指摘されていますが、スタックデプロイでenv_fileが無視されることについては言及されていません。

@kinghuangによって提案されたソリューションが機能し、誰かが言ったようにデプロイキーを除外していないことを確認できます。

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

これは、ドキュメントでより明確になっているはずです。 @lengxuehxのVariableSubstitutionセクションでは.envがサポートされていないことが指摘されていますが、スタックデプロイでenv_fileが無視されることについては言及されていません。

docker composeとまったく同じように、env_fileが使用され、deploystackコマンドで機能していることを確認できます。

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

要約すると、これまでにこれを読んだ私のような人々のために：

• docker stack deployは「変数置換」をサポートしていますが、何らかの方法で.envファイルから環境変数を設定する必要があります。 いくつかのオプションが上で説明されています。 最も簡単な回避策の1つは、プリプロセッサとしてdocker-compose configを使用することです。
  したがって、 docker stack deploy -c <(docker-compose config) STACK_NAMEを使用してスタックを作成できます。
• Dockerは構成機能とシークレット機能を導入しましたが、それらにはユースケースがありますが、「変数置換」と同じことはしません。
• docker-compose.ymlファイルのenv_fileパラメータは、 docker-compose.ymlファイル自体ではなく、作成されたコンテナに環境変数を設定します（したがって、 "の代わりに使用することはできません。可変置換」）。

アップデート：

@thaJeztahによって修正されました。

Dockerは、docker stack deployを使用した変数置換をサポートしておらず、提案されたソリューションのいずれも機能しません。

docker stack deployは変数置換をサポートしますが、 .envファイルを評価しません。 以下の例では、 HELLO_VERSIONはlinuxに設定されており、サービスは（デフォルトのhello-world:latestの代わりに） hello-world:linuxタグを使用します。

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

そうは言っても、docker-compose.ymlファイルのenv_fileパラメーターを使用して環境変数を使用することはできます。

env_fileは別の目的を果たします（ docker run --env-fileと同等です）。 env_fileオプションは、作成されたコンテナーに設定するenv-varsを指定しますが、作成ファイル自体では使用されません（また、スタックをデプロイする前に作成ファイルの変数を置き換えるためには使用されません）。

docker-composeとdockerstackの間の他のわずかな違いに沿って、同じ問題が発生しました。
パイプでこの問題を処理するために、 https：//github.com/egyel/dcsh script / toolを作成することになりました。

みなさん、こんにちは。これは、env_fileをdocker-composeに配置するのに役立ちました。

env_file: /path/to/env/file
いいえ

env_file:
  - /path/to/env/file

私は別の投稿からこれを見たばかりで、なぜそれが機能するのかを推測することしかできません（あなたの推測と同じです）が、env_fileが機能しないというドキュメントで明示的に言及されているdockerとしてこれが機能している理由を確認する必要があります。

私の理解では、envファイルを使用してプレースホルダーを入力することはできません
docker-stack.ymlファイルですが、コンテナーに提供することはできます。
あなたがしていることはあなたがから画像名を設定することを許可しないことに注意してください
たとえば、envファイル。

2020年5月17日、06：08 [email protected]は次のように書いています。

【画像：画像】
https://user-images.githubusercontent.com/30310576/82135555-a1e4be00-9836-11ea-9df4-a1b82e014b0e.png
みなさん、こんにちは。これは、env_fileをdocker-composeに配置するのに役立ちました。

env_file：/ path / to / env / file
いいえ

env_file：

• / path / to / env / file

私は別の投稿からこれを見ただけで、なぜそれが機能するのか推測することしかできません
（あなたの推測と同じです）しかし、これがなぜであるかについての確認が必要です
env_fileがしないことをドキュメントで明示的に言及したdockerとして機能する
仕事。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/29133#issuecomment-629740002 、または
登録を解除する
https://github.com/notifications/unsubscribe-auth/ABHLQMCARDQGJQIBWCQKAYLRR5PMHANCNFSM4CYRHCTA
。

上記のdocker-composeソリューション：

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

（私にとって） .envファイルのようなもの、特にdocker-compose.override.ymlファイルは通常私の開発環境の一部であるという欠点があります。 本番環境にデプロイするときに、それらを持ち込まないようにします。

いくつかの重複があったとしても、私は物事を注意深く制御する別のdocker-compose-production.ymlを持つことになりました。

CLIが.envのサポートを追加することはないと思います。 docker stack deployコマンドは、もともと分散アプリケーションバンドルファイルを念頭に置いて作成されました（したがって、 --bundle-fileオプション）。 DABファイルは、DockerComposeによってdocker-compose bundleコマンドを使用して生成されました。 .envおよびその他の作成機能は、 docker stack deployに渡される前に、 docker-composeによって処理されます。 docker stack deployでのファイルの作成の直接サポートは、常に妥協点でした。

DABファイルの当初の約束は、現在、 .envも処理しないDockerアプリで有効です。

開発者にdocker-compose configを使用して、Docker Composeプロジェクトをdocker stack deployに渡す前に前処理してもらいます。 これは、次の方法で1行で実行できます。

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

このようにして、 .env処理を含むすべてのDockerCompose機能が完全に適用されます。

これは魅力のように機能します。作成ファイルに「docker-compose.yml」という名前がない場合は、コマンドに実際の作成ファイル名を含める必要があることに注意してください。

docker stack deploy -c <（docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config）CUSTOM-STACK

$ <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml configハックに注意!!! docker-compose configとdocker-compose -f myfile.yml configの出力は、必ずしも同じではありません。 後者は環境変数を余分な引用符で囲むことがあるため、出力は間違っています。

例：

environment:
  SERVER_URL: '"xxx"'

それ以外の

environment:
  SERVER_URL: xxx

この問題はすでにどこかで追跡されていますか？