Compose: バージョン3のDepends_on

depends_onはv3にまだ存在しますが、ヘルスチェックの依存関係（およびその結果として拡張構文）は移植されません。

HTH

しかし、私はdocker-compose v3を作成し、swarmにデプロイしようとしましたが、コンテナーが開始する必要のある方法で開始されていないため、depends_onが機能していません。

docker-composeまたはdocker stack deployますか？

Dockerスタックデプロイを使用しています
そして私はそれを7台のマシンの群れに展開しようとします

ヘルスチェックの依存関係のようなものを実現するために、docker-compose v3で同等のものは何でしょうか？ v3でその機能を削除する場合は、基本的に決して使用しないでください。少なくとも、このための移行パスが必要です。

新しいdocker-composev2.1に導入し、v3にドロップする意図は何ですか？ 現在、アプリケーション用にさまざまな作成ファイルを設定していますが、次のバージョンで削除される機能を使用したくないため、使用を新しいdocker-composeファイルバージョンに更新できません。

現時点では、新しいdepends_on構文がv3に移植される予定はないため、移植されないと想定する必要があります。

多くの人が望んでいる答えではないことは知っていますが、少なくともある程度明確にするのに役立つことを願っています。

なぜ計画に含まれていないのか聞いてもいいですか？ そうすることは非常に役立つと思います。

それは明確さを与えますが、説明しません。 その理由を詳しく説明していただけますか？ そして、代替案（存在する場合）については？
コンテナ内でサービスを処理するのではなく、depends_onを使用すると、サービスに依存する非常に簡単な方法が得られます（つまり、サードパーティのイメージを待機スクリプトでラップして維持する必要がある場合があります）。

@ shin-なぜ2.1でそれを実装したのですか？ 人々がそれを使用してそれに依存するようになると、彼らは決してアップグレードすることができなくなります。 敬意を払って、それはあなたたちの側の非常に貧弱な計画のようです。

では、v3でサポートされているdepends_on構文は何ですか？ https://docs.docker.com/compose/compose-file/#version -3ではdepends_onについて言及されていません。また、docker-compose v1.10を使用してアプリケーションをデプロイすると、v2またはv2.1のdepends_onフレーバーは機能しません。 v3作成ファイルの私...

@mustafaakin

なぜ計画に含まれていないのか聞いてもいいですか？ そうすることは非常に役立つと思います。

@hsmade

その理由を詳しく説明していただけますか？ そして、代替案（存在する場合）については？

https://github.com/docker/docker/issues/30404#issuecomment-274825244から

depends_onは、 docker stack deployと一緒に使用すると、何もしません。 スウォームモードのサービスは、失敗すると再起動されるため、起動を遅らせる理由はありません。 数回失敗しても、最終的には回復します。

@brettmc

では、v3でサポートされているdepends_on構文は何ですか？

docker-composeを使用する場合、v3でサポートされる構文はリスト構文です（2.0で使用される構文と同様）。 docker stack deployを使用している場合、依存関係は尊重されません（正当化については上記を参照してください）

バージョン3形式は、外部のdocker-composeツールから統合されたdocker stackソリューションに移行するための最初のステップです。 現在の実装には、取り組んでいる癖があります。 docker-composeでのバージョン3形式のサポートは、その移行を支援することを目的としています。 fig / Composeが最初に導入されて以来、Dockerでは多くの変更と改善が行われています。つまり、以前は理にかなっていた多くのことが今では時代遅れになっています。 docker stackは、新しい概念を使用した新たなスタートであり、 volumes_fromからdepends_onまで、扱いにくい構文と概念の一部を取り除きます。
これらの変更のいくつかについて特に懸念がある場合は、アクティブに繰り返されている
Dockerサービスとdocker stackに移行する準備がまだできていない場合は、v2形式を引き続き使用してください。 プロジェクトは将来のある時点で日没になると想定するのが妥当ですが、かなり前に発表されます。 その後、コードは引き続き利用可能でオープンソースになります。

ありがとう。 今では理にかなっています。

スウォームモードのサービスは、失敗すると再起動されるため、起動を遅らせる理由はありません。 数回失敗しても、最終的には回復します。

私見これは良いアプローチではありません。 すべてのサービスが、依存する他のサービスの準備ができていないことを適切に検出できるわけではありません。何度も試行して失敗するため、コンテナーが後で停止する可能性があります。 エントリポイントラッパースクリプトを導入する必要がありますが、これはあまり良いことではありません。 ヘルシーチェックの依存関係は非常に良かったですが、スウォームモードをサポートしていません。

スウォームモードのサービスは、失敗すると再起動されるため、起動を遅らせる理由はありません。 数回失敗しても、最終的には回復します。

こんにちは、みなさん！
たとえば、作業を非常に迅速に実行して終了する（そして、設計上1回だけ実行する必要がある）サービスがある場合、そのサービスは何度も何度も開始されるということですか？

@ Marvel77デフォルトでは、はい。ただし、 deploy.restart_policyセクションを使用してその動作をオーバーライドできます： https ：

@ shin-ありがとうございました！

@mustafaakin実際、ベストプラクティスは、依存するサービスへのフォールトトレラント接続を確立することです（
ある意味で、非推奨は良いことです。 これらの便利さは私たちを怠惰にします。

@hsmadeしかし、ほとんどすべてのinit（upstart、systemd）は関係に依存しています。 だから、怠惰なことではなく、それが理にかなっていることです。 SSHDデーモンは、ネットワークデバイスの準備が整うまで起動しません。 所有しているすべてのシステムを制御することはできません。はい、システムをフォールトトレラントにすることができます。 ただし、AがBに依存していると仮定します。Aの初期化には時間がかかり、決定論的ではありません。 では、どうすればBに再起動ポリシーを記述できますか？ 永遠に再起動しますか？ あなたがそれを望まない場合はどうなりますか？

これはComposeよりも大きな問題であり、Composeはそれらを開始するだけです。 スウォームはそれらを実行させるものなので、スウォームはこの健康関係への依存を処理する必要があると思います。

@mustafaakinコンテナ化された環境で実行されているマイクロサービスを従来のinitシステムと比較することはできないと思います。 それは本当に意味がありません。 マイクロサービスの考え方は、自己完結型の最小限のエンティティであるということだと思います。 APIなどの定義は非常に明確です。外界のステータスを想定するべきではありません。 はい、データベースが必要ですが、いいえ、データベースがあるとは限りません。 私が言おうとしたように、あなたの依存関係がスタートアップにあることを知ることはあなたの問題の中で最も少なく、それがなくなったときにそれをうまく処理することがより重要であり、前者も解決するはずです。

しかし、繰り返しになりますが、これらはこの問題に関する私の考えであり、私は間違っている可能性があります;）

ええ、それはマイクロサービスには意味がありませんが、すべてがマイクロサービスであるわけではありません。私はコンテナーでHadoopを実行します。 Dockerはマイクロサービス専用ではありません。 私が言ったように、それは私が制御できる環境には最適ですが、私が制御できないものでは、サービスのエントリポイントをラップする必要があります。 これはhealtcheckを使用したdepends_onで解決されただけで、Swarmにもあるといいと思います。 継続的に再起動することは、怠惰な人の選択です。

みんな、

「フォールトトレラント」と「初めての初期化」という誤解があると思います。
アプローチは最初のアプローチには十分に聞こえますが、後者は本当に苦痛であることに同意します。
私自身だけでなく、一般的には、サービスは多かれ少なかれ相互に依存しているため、特定の順序でサービスを開始する必要があると思います。

初期化フェーズで継続的に再起動し、ある時点でサービスが適切な順序で開始されるのを待つことは、悪夢のようなものです。さらに悪いことが起こった場合、起動プロセスの「ダウンタイム」を計画することはできません。 悪いだけでなく、何かを変更する必要がある「メンテナンス」時間のように、さまざまなサービスが群れによって何度も再起動されるため、システムが実際に起動するのにかかる時間を予測できない場合があります。再び正しい順序を待っています。
私はそれが7つのコンテナーでどのように機能するかを試して待っていましたが、20分間、_swarm_はまだそれを理解しておらず、サービス全体がまだダウンしていました。
したがって、_初期起動_にかかる時間は実際には不明であるため、インフラストラクチャ全体を元に戻して復元するのにかかる時間を述べることすらできません。
私にはばかげているように聞こえます。

まれに（フルダウンで）発生するはずですが、そのような予測可能性がなければ、「本番」に入ることができるとは思いません。
しかし、それでもそれが発生した場合、私はその場にいて、できるだけ早く復元するように求められます。その時点で、コンテナが_startup._中に再起動し続けるという理由だけで、コンテナがどのくらいの時間起動するかはまったくわかりません。

@ozlatkovこれは、ここではなく、 docker issuetrackerに実際に投稿する必要があります。

@ shin-ありがとう！ 私はそれをdocker / dockertrackerに移動しました：

https://github.com/docker/docker/issues/31333

DockerチームがDockerSwarmが使用されていると想定するのは本当に悪いことだと思います。 Composeは、完全に機能するスタンドアロンツールであると想定されています。

ただし、テストパイプラインではDocker Composeを頻繁に使用しており、そのような基本的な機能の削除（実行可能な代替手段を提供しない）は、実際にユーザーに劇的な悪影響を及ぼしています。

私は現在、チームメンバーからの非常に醜いPRをレビューしており、（この機能に大きく依存しているため）これに対するあらゆる種類の回避策を考え出そうとしています。これには、永遠にCompose2.Xを使用することも含まれます。

Dockerは、多くのチームがすでに依存している重要な機能を削除することで、目標を達成するのに役立つはずです。

これらすべてをDockerCompose3に移植することを再検討してください。

大変感謝いたします。

100回目：スウォームサービスを使用する予定がない場合は、v3形式を使用する理由はありません。

それは、チームがスタンドアロン開発ツールとしてcomposeを使用している人のために2.Xフォーマットをサポートすることを約束していることを意味しますか？

まさに私の質問：Composeチームはv2フォーマットを永遠にサポートすることを約束していますか？

v2形式の廃止が予定されている場合、DockerComposeで標準化することはできません。

これにより、すべてのコンテナーがinit containerパターンに強制され、Dockerの再起動ポリシーが削除され、起動順序に対するハッキーなアプローチが作成されるように感じます。 スタックとアプリケーションバンドルの作成に焦点を合わせるために、composeの> = v3がこの方向に移動すると想定する必要がありますか？ そうだとすれば、Dockerスタックで起動順序を維持する方法を教えていただけますか？ wait-for-it.shまたはdockerizeのアプローチはありますか？

スタックのdocker-compose.ymlに相当する宣言型は何ですか？

こんにちはみんな、私がdocker stackを使用してdocker-composeを取り除くつもりなら、ベストプラクティスは何ですか？

これは解決策のようですが、コンテナを初期化するための一種のハッキーなスクリプトを用意することは、良い習慣とは思えません。 そうですか？

ありがとう。

@mustafaakin反対票をありがとう！ とても参考になりました❤️

@VinceOPS 「ベストプラクティス」についてはよくrestart: always使用しているので、機能するまで循環します¯\ _（ツ）_ /¯

@hutchicしかし、上記の会話で述べたように、終了日を設定することはできませんでした。ある種の循環的な障害時の再起動です。

Dockerチームがバージョン3でこの機能を削除し、それらの追加を拒否するのはなぜですか？

@ tianhao-au https://github.com/moby/moby/issues/31333 （およびhttps://github.com/moby/moby/issues/31333#issuecomment-409143581）のディスカッションを参照して

作曲については、 https： //github.com/moby/moby/issues/31333#issuecomment -333265696（ x-depends_on持っている）にも提案を残しました

この機能の変更は、文字通り、docker-composeを使用しない理由です。 本番環境でdockerを使用していて、開発環境用にローカルでdocker-composeを使用している場合、開発環境と本番環境でDockerコンテナーの動作を根本的に変える必要があります。 本番環境では、デプロイメントの正常性と順序を保証するためにオーケストレーションシステムに依存しています。 開発ランドでは、オーケストレーションはdocker-composeによって行われていました。 今、私は自分のシステムを調整するために物事の健全性をチェックするためにたくさんの壊れたスクリプトを書いています。 私がそうするつもりなら、Dockerを管理するためにgolangを書いて、それで済ませてみませんか。 少しぶつかったので落としました。 ちょうど私の2p

最新のdocker-composeバージョンを使用して、より将来性のあるものにしようとすると、この問題に遭遇しました。 これは悲しいです。