Compose: コンテナの起動を遅らせお、起動時間が長い䟝存サヌビスをサポヌトする方法はありたすか

䜜成日 2014幎08月05日  Â·  314コメント  Â·  ゜ヌス: docker/compose

デヌタをむンポヌトする必芁があるため、起動に少し時間がかかるMySQLコンテナがありたす。

MySQLコンテナに䟝存するAlfrescoコンテナがありたす。

珟時点では、figを䜿甚するず、Alfrescoコンテナ内のAlfrescoサヌビスがMySQLコンテナに接続しようずするず倱敗したす...衚面䞊は、MySQLサヌビスがただリッスンしおいないためです。

図でこの皮の問題を凊理する方法はありたすか

最も参考になるコメント

ええ、私はこのようなものに興味があるでしょう-それに぀いおもっず早く投皿するこずを意味したす。

私たちがこのナヌスケヌスを修正するず私が考えるこずができる最小の圱響パタヌンは、次のようになりたす。

リンクず同様の倀のセマンティクスを䜿甚しお、fig.ymlの新しいキヌずしお「wait」を远加したす。 Dockerはこれを前提条件ずしお扱い、このコンテナヌが終了するたで埅っおから続行したす。

したがっお、私のdockerファむルは次のようになりたす。

db:
  image: tutum/mysql:5.6

initdb:
  build: /path/to/db
  link:
    - db:db
  command: /usr/local/bin/init_db

app:
  link:
    - db:db
  wait:
    - initdb

アプリを実行するず、すべおのリンクコンテナヌが起動し、埅機コンテナヌが実行され、埅機コンテナヌinitdbが終了するず、実際のアプリコンテナヌにのみ進みたす。 initdbは、デヌタベヌスが䜿甚可胜になるのを埅っおから、初期化/移行/その他を実行しお終了するスクリプトを実行したす。

ずにかく、それは私の考えです。

党おのコメント314件

仕事では、リンクがただアップしおいるかどうかをチェックするスクリプトで䟝存サヌビスをラップしたす。 私の同僚の䞀人もこれに興味があるこずを私は知っおいたす 個人的には、サヌビスが利甚可胜になるのを埅぀こずはコンテナレベルの懞念だず感じおいたすが、間違っおいるかもしれたせん:)

ラッピングでも同じこずをしたす。 ここで䟋を芋るこずができたす https 

すべおのリンクをルヌプし、リンクが機胜するたで埅機しおから、枡されたコマンドを開始する゚ントリポむントスクリプトがあるず䟿利です。

これはDocker自䜓に組み蟌たれおいる必芁がありたすが、解決策は道のりです。 コンテナは、公開するリンクが開くたで、開始されたず芋なされるべきではありたせん。

@bfirshは私が想像しおいた以䞊のものですが、玠晎らしいでしょう。

コンテナは、公開するリンクが開くたで、開始されたず芋なされるべきではありたせん。

それこそが人々が必芁ずしおいるこずだず思いたす。

今のずころ、 https//github.com/aanand/docker-waitのバリ゚ヌションを䜿甚し

ええ、私はこのようなものに興味があるでしょう-それに぀いおもっず早く投皿するこずを意味したす。

私たちがこのナヌスケヌスを修正するず私が考えるこずができる最小の圱響パタヌンは、次のようになりたす。

リンクず同様の倀のセマンティクスを䜿甚しお、fig.ymlの新しいキヌずしお「wait」を远加したす。 Dockerはこれを前提条件ずしお扱い、このコンテナヌが終了するたで埅っおから続行したす。

したがっお、私のdockerファむルは次のようになりたす。

db:
  image: tutum/mysql:5.6

initdb:
  build: /path/to/db
  link:
    - db:db
  command: /usr/local/bin/init_db

app:
  link:
    - db:db
  wait:
    - initdb

アプリを実行するず、すべおのリンクコンテナヌが起動し、埅機コンテナヌが実行され、埅機コンテナヌinitdbが終了するず、実際のアプリコンテナヌにのみ進みたす。 initdbは、デヌタベヌスが䜿甚可胜になるのを埅っおから、初期化/移行/その他を実行しお終了するスクリプトを実行したす。

ずにかく、それは私の考えです。

改蚂、以䞋を参照

ここでも+1。 コマンド自䜓でこれを行う必芁があるこずはあたり魅力的ではありたせん。

+1も。 ちょうどこの問題に遭遇したした。 玠晎らしいツヌルずころで、私の人生はずおも楜になりたす

+1はこれがあれば玠晎らしいでしょう。

+1も。 最近、同じ䞀連の問題に遭遇したした

+1も。 dockerguysからの声明はありたすか

珟時点で同期する゚ントリポむントずしおラッパヌスクリプトを䜜成しおいたすが、オヌケストレヌションを別の方法で実行するコンテナヌの他のタヌゲットがある堎合、figにメカニズムがあるこずが賢明かどうかはわかりたせん。 䜜業を行うコンテナの責任ずしお、私に固有のアプリケヌションのようです。

いく぀かの考えず実隓の埌、私はこれにある皋床同意したす。

私が構築しおいるそのようなアプリケヌションは基本的に同期を持っおいたす
アプリケヌションのサヌビスを埅機できるwaitforhost、port関数
䟝存しおいる環境を介しお怜出されるか、明瀺的に怜出される
CLIオプションによる構成。

也杯
ゞェヌムズ

ゞェヌムズミルズ/プロロゞック

E [email protected]
Wprologic.shortcircuit.net.au

午前6時34分PMで金、2014幎8月22日には、マヌク・スチュアヌト[email protected]
曞きたした

珟圚、同期する゚ントリポむントずしおラッパヌスクリプトを䜜成しおいたす。
他のタヌゲットがある堎合、むチゞクにメカニズムがあるこずが賢明かどうかはわかりたせん
別の方法でオヌケストレヌションを実行するコンテナヌ。 ずおもそうです
コンテナの責任ずしお私に固有のアプリケヌション
仕事をしおいたす。

—
このメヌルに盎接返信するか、GitHubで衚瀺しおください
https://github.com/docker/fig/issues/374#issuecomment-53036154 。

はい、ここで必芁ないく぀かの基本的な「䟝存」...
したがっお、コンテナが20個ある堎合は、fig upを実行する必芁はなく、すべおが正しい順序で始たりたす...
ただし、タむムアりトオプションやその他の障害キャッチメカニズムもありたす

ここにもう+1。 Postgresの起動にDjangoよりも時間がかかるため、ハッカヌなしで移行コマンド甚のDBがありたせん。

@ahknight興味深い、なぜrun間に移行が実行されるのですか

buildフェヌズで実際に移行を実行したせんか そうすれば、新鮮な画像をはるかに速く起動できたす。

残念ながら、問題のアプリケヌション甚のより倧きな起動スクリプトがありたす。 今のずころ、最初にDB以倖の䜜業を行っおおり、ルヌプ内でnc -w 1を䜿甚しおDBを埅機しおから、DBアクションを実行しおいたす。 それは動䜜したすが、それは私を汚く感じさせたす。

fig buildフェヌズで、この䜜業を行うこずで倚くの成功を収めたした。 djangoプロゞェクトでのこの䟋が1぀ありたすただ䜜業䞭です https 

起動のためにポヌリングする必芁はありたせん。 私はmysqlで同様のこずをしたしたが、 mysqld initスクリプトがただそれを行っおいなかったため、起動をポヌリングする必芁がありたした。 このpostgresinitスクリプトの方がはるかに優れおいるようです。

これが私が考えおいたものです

docker / docker7445のアむデアを䜿甚しお、この「wait_for_helth_check」属性を図に実装できたすか
それで、それはDockerの問題ではなくむチゞクでしょうか

ずにかく、figにリンクされたコンテナのtcpステヌタスをチェックさせる方法はありたすかそうであれば、これが進むべき道だず思いたす。 =

@dnephinは、これを支揎するためにDockerfilesで䜕をしおいるのかをもう少し説明できたすか
ビルドフェヌズはランタむムに圱響を䞎えるこずができたせんか

@docteurkleinできたす。 䞊からリンクを修正したしたhttps://github.com/dnephin/readthedocs.org/blob/fig-demo/dockerfiles/database/Dockerfile#L21

アむデアは、ビルド䞭にすべおの遅い「セットアップ」操䜜を実行するため、コンテナヌの起動䞭に䜕も埅぀必芁がないずいうこずです。 デヌタベヌスたたは怜玢むンデックスの堎合、次のようになりたす。

  1. サヌビスを開始する
  2. ナヌザヌ、デヌタベヌス、テヌブル、フィクスチャデヌタを䜜成する
  3. サヌビスをシャットダりンしたす

すべお単䞀のビルドステップずしお。 埌でデヌタベヌスコンテナをfig upするず、基本的にすぐに䜿甚できるようになり、これらの䜎速な操䜜にdockerビルドキャッシュを利甚できるようになりたす。

いいね ありがずう:)

@dnephinいい、それに぀いお考えおいなかった。

+1これは間違いなく必芁です。
ほずんどの堎合、醜い時間遅延ハックで十分ですが、_実際の_゜リュヌションは歓迎されたす。

なぜ/い぀必芁なのか、䟋を挙げおいただけたすか

私のナヌスケヌスでは、Elasticsearchサヌバヌず、Elasticsearchに接続しおいるアプリケヌションサヌバヌがありたす。 Elasticsearchの起動には数秒かかるため、Elasticsearchサヌバヌに接続するずすぐにアプリケヌションサヌバヌが倱敗するため、単玔にfig up -d実行するこずはできたせん。

䞀方のコンテナがMySQLを起動し、もう䞀方がMySQLを必芁ずするアプリを起動し、もう䞀方のアプリがより速く起動するこずがわかったずしたす。 そのため、䞀時的なfig up障害が発生したす。

クレヌンには、個別に開始できるグルヌプを䜜成できるようにするこずで、これを回避する方法がありたす。 したがっお、MySQLグルヌプを開始し、5秒埅っおから、それに䟝存する他のものを開始できたす。
小芏暡で機胜したすが、実際の゜リュヌションではありたせん。

@oskarhaneは、この「5秒埅぀」が圹立぀かどうか
たた、他のグルヌプを埅っおロヌドするこずを手動で行う必芁がありたすが、それは䞀皮のラメです、figはあなたのためにそれを行う必芁がありたす= /

@ oskarhane 、 @ dacort 、 @ ddos​​sot 珟実の䞖界では、物事がクラッシュしお再起動したり、ネットワヌク接続が行き来したりするこずなどに。FigがTCP゜ケットで埅機する䟿利さを導入するかどうかにかかわらず、コンテナは接続障害に察する耐性。 そうすれば、どこでも適切に機胜したす。

その通りですが、既存のすべおのアプリを修正しお、起動時に重芁なリ゜ヌスDBなどがない状態から正垞に回埩するたでこれはGreatThing™ですが、残念ながらフレヌムワヌクではほずんどサポヌトされおいたせん、䜿甚する必芁がありたす。 fig start代わりに、遅延を䜿甚しお特定の順序で個々のコンテナヌを開始するためのfig up 。

dockerwinkを制埡するためにfigを制埡するシェルスクリプトが衚瀺されたす。

これがfigに組み蟌たれおいなくおも倧䞈倫ですが、準備が敎うのを埅぀ためのベストプラクティスに関するアドバむスがあればよいでしょう。

以前のコメントからリンクされたいく぀かのコヌドで、これが行われたのを芋たした

while ! exec 6<>/dev/tcp/${MONGO_1_PORT_27017_TCP_ADDR}/${MONGO_1_PORT_27017_TCP_PORT}; do
    echo "$(date) - still trying to connect to mongo at ${TESTING_MONGO_URL}"
    sleep 1
done

私の堎合、 /dev/tcpパスはありたせんが、おそらく別のLinuxディストリビュヌションです-私はUbuntuを䜿甚しおいたす

私は代わりに、うたくいくように芋えるこの方法を芋぀けたした

until nc -z postgres 5432; do
    echo "$(date) - waiting for postgres..."
    sleep 1
done

これは機胜しおいるようですが、堅牢かどうかを知るには十分な知識がありたせん... ncたで衚瀺されるポヌトずpostgresサヌバヌが_本圓に_受け入れるこずができる間に競合状態が発生する可胜性があるかどうかは誰にもわかりたせんコマンド

チェックを逆にするこずができればもっず嬉しいです-䟝存コンテナからポヌリングする代わりに、タヌゲット぀たりpostgresサヌバヌコンテナからすべおの䟝存コンテナにシグナルを送信するこずは可胜ですか

倚分それはばかげた考えです、誰かが䜕か考えを持っおいたすか

@anentropic Dockerリンクは䞀方向であるため、珟圚、ダりンストリヌムコンテナヌからのポヌリングがそれを行う唯䞀の方法です。

ncに衚瀺されるポヌトずpostgresサヌバヌが実際にコマンドを受け入れるこずができる間に競合状態が発生する可胜性があるかどうか誰かが知っおいたすか

䞀般的なケヌスで知る方法はありたせん-postgresの堎合は正しいかもしれたせんが、他のサヌビスの堎合は間違っおいるかもしれたせん-これは図でそれを行わないための別の議論です。

@aanand Docker / Wait Imageアプロヌチを䜿甚しおみたしたが、䜕が起こっおいるのか

埅機コンテナをOrientdbにリンクするこずで、この゚ラヌが衚瀺されないこずを期埅しおいたした。 しかし、残念ながら、私はただそれをランダムに取埗しおいたす。 これが私のセットアップですDockerバヌゞョン1.4.1、Ubuntu 14.04ボックスの図1.0.1

orientdb:
    build: ./Docker/orientdb
    ports:
        -   "2424:2424"
        -   "2480:2480"
wait:
    build: ./Docker/wait
    links:
        - orientdb:orientdb
....
core:
    build:  ./Docker/core
    ports:
        -   "3000:3000"
    links:
        -   orientdb:orientdb
        -   nsqd:nsqd

どんな助けでも倧歓迎です。 ありがずう。

@mindnuts wait画像はデモンストレヌションのようなものです。 fig.ymlでの䜿甚には適しおいたせん。 coreコンテナで同じ手法繰り返しポヌリングを䜿甚しお、 orientdbコンテナが開始するのを埅っおから、メむンプロセスを開始する必芁がありたす。

+1は、fig.ymlでビルドするのではなく、カスタムビルドのむメヌゞをプルしおいるずきにこれに遭遇し始めたした。 mongodbの準備がただできおいないため、ノヌドアプリが倱敗したす...

Dockerを䜿甚しおWordPressを手動で起動したずきにMySQLに到達できる理由ず、Figを起動したずきにMySQLがオフラむンになった理由のデバッグに䜕時間も費やしたした。アプリケヌションを起動するたびに、Figが垞にMySQLコンテナを再起動するこずに気付いたので、WordPressのentrypoint.shが停止したす。ただMySQLに接続できたせん。

実際のentrypoint.shを実行する前に5秒間埅機する独自のオヌバヌラむドされたentrypoint.shを远加したした。 しかし、Docker / FigずMySQL + WordPressコンテナの組み合わせを簡単に起動できるず思われる堎合、これは明らかに䞀般的な゜リュヌションを必芁ずするナヌスケヌスです。

そのため、WordPressのentrypoint.shは、MySQLに接続できずに終了したす。

これはWordPressコンテナの問題だず思いたす。

私は圓初このアむデアのファンでしたが、 https //github.com/docker/docker/issues/7445#issuecomment -56391294を読んだ埌、そのような機胜は間違ったアプロヌチであり、実際には悪い習慣を助長するず思いたす。

この問題が察凊するこずを目的ずしおいる2぀のケヌスがあるようです

初期化を実行するには、䟝存関係サヌビスが利甚可胜である必芁がありたす。

コンテナの初期化は、実際にはbuild間に実行する必芁がありたす。 そうすれば、それはキャッシュされ、画像のすべおのナヌザヌが䜜業を繰り返す必芁はありたせん。

接続を開くには、䟝存関係サヌビスが利甚可胜である必芁がありたす

アプリケヌションは、接続障害に察しお本圓に回埩力があり、接続を再詊行する必芁がありたす。

問題の根本は、サヌビスの準備が敎うのを埅぀責任に぀いおの基本的なルヌルがないこずだず思いたす。 しかし、たずえあったずしおも、開発者がすべおの初期化スクリプトにデヌタベヌス接続の再詊行を远加するこずを期埅するのは少し非珟実的だず思いたす。 このようなスクリプトは、マりントされたばかりの空のデヌタボリュヌムを準備するために必芁になるこずがよくありたすデヌタベヌスの䜜成など。

アプリケヌションコンテナを再起動するずきにFigがリンクされたコンテナ぀たりデヌタベヌスサヌバヌを垞に再起動しない堎合、問題は実際にははるかに目立たなくなりたす。 なぜそうなるのかよくわかりたせん。

アプリケヌションコンテナを再起動するずきにFigがリンクされたコンテナ぀たりデヌタベヌスサヌバヌを垞に再起動しない堎合、問題は実際にははるかに目立たなくなりたす。 なぜそうなるのかよくわかりたせん。

実際には、コンテナを_再起動_するだけでなく、コンテナを_砎棄しお再䜜成_したす。これは、 fig.ymlぞの倉曎を確実に取埗するための最も簡単な方法だからです。 最終的には、「珟圚の構成」ず「目的の構成」を比范し、倉曎されたものだけを再䜜成できる、よりスマヌトな゜リュヌションを実装する必芁がありたす。

元の問題に戻るず、コンテナに接続再詊行ロゞックがあるこずを期埅するのは非珟実的ではないず思いたす。これは、機胜する分散システムを蚭蚈するための基本です。 異なるスクリプトで共有する必芁がある堎合は、実行可胜ファむルたたは、シェルを䜿甚しおいない堎合は蚀語固有のモゞュヌルに分解しお、各スクリプトが䞊郚のwaitfor dbを呌び出すこずができるようにする必芁がありたす。

@kennu --no-recreateどうですか / cc @aanand

@aanand぀たり、Docker Hubは、初期化スクリプトで接続の再詊行を凊理しない可胜性のある公開されたむメヌゞで既にいっぱいになっおいるずいう芳点からの非珟実的なコメントであり、党員に远加しおもらうのはかなりの䜜業です。 しかし、Docker Incが䜕らかの公匏のガむドラむン/芁件を公開しおいれば、それは可胜だず思いたす。

個人的には、コンテナ/むメヌゞをシンプルに保ち、基盀ずなるシステムに䟝存関係の解決に぀いお心配させたいず思いたす。 実際、Dockerの再起動ポリシヌはすでにすべおを解決しおいる可胜性がありたすアプリケヌションコンテナがデヌタベヌスぞの接続に倱敗した堎合、デヌタベヌスが䜿甚可胜になるたで再起動しお再詊行したす。

ただし、再起動ポリシヌに䟝存するずいうこずは、デフォルトで有効にする必芁があるこずを意味したす。そうしないず、問題のデバッグに䜕時間も費やしたす私が行ったように。 たずえば、ポッドの堎合、KubernetesのデフォルトはRestartPolicyAlwaysです。

これに぀いお䜕か進展はありたすか すべおのDockerむメヌゞが倉曎され、コミュニティ党䜓が接続の再詊行方法を実装するこずを期埅するのは合理的ではないこずを繰り返し述べたいず思いたす。 FigはDockerオヌケストレヌションツヌルであり、問​​題はそれが行う順序にある​​ため、DockerやコミュニティではなくFigで倉曎を加える必芁がありたす。

すべおのDockerむメヌゞが倉曎され、コミュニティ党䜓が接続の再詊行方法を実装するこずを期埅するのは合理的ではありたせん

dockerたたはfigが原因で、アプリケヌションを再詊行する必芁があるわけではありたせん。 ネットワヌクは信頌できないため、アプリケヌションは接続の切断に察しお回埩力がある必芁が

個人的には、どのコンテナにも再詊行を実装する必芁はありたせんでした。たた、遅延や起動の埅機も必芁ありたせんでした。 この問題のほずんどのケヌスは、これら2぀のカテゎリに分類されるず思い

すべおの初期化が「ビルド」フェヌズで行われ、次のリク゚ストで接続が再確立されるこずを確認した堎合、再詊行する必芁はありたせんたたは他のコンテナが開始するのを埅぀必芁はありたせん。 接続が最初の芁求が行われたずきに怠惰に開かれた堎合、起動時に熱心にではなく、再詊行する必芁はたったくないず思いたす。

問題は[図]が物事を行う順序にありたす

これたでのずころ、この議論ではそのこずに぀いおの蚀及はありたせん。 Figは、構成で指定されたリンクに基づいお起動を順序付けるため、垞に正しい順序でコンテナヌを起動する必芁がありたす。 順序が正しくないテストケヌスを提䟛できたすか

ここで@dnephinに同意する

Compose / Figはこれらの決定を䞋すこずができず、監芖サヌビスはコンテナ内で実行されおいるアプリケヌションの責任である必芁がありたす。

@dnephinは単に幞運だったこずを瀺唆したいず思いたす。 2぀のプロセスを䞊行しおフォヌクし、䞀方がもう䞀方がリッスンするポヌトに接続する堎合、基本的に競合状態が発生したす。 どのプロセスがより速く初期化されるかを確認するための宝くじ。

たた、WordPressの初期化の䟋を繰り返したいず思いたす。MySQLコンテナにただデヌタベヌスがない堎合は、新しいデヌタベヌスを䜜成するスタヌトアップシェルスクリプトを実行したすこれは、Dockerむメヌゞのビルド時に実行できたせん。倖郚にマりントされたデヌタボリュヌム。 このようなスクリプトは、䞀般的なデヌタベヌス゚ラヌず「デヌタベヌスの準備ができおいたせん」゚ラヌを区別し、シェルスクリプト内に適切な再詊行ロゞックを実装する必芁がある堎合、非垞に耇雑になりたす。 むメヌゞの䜜成者が、䞊蚘の競合状態に察しお起動スクリプトを実際にテストするこずはない可胜性が高いず思いたす。

それでも、コンテナが散発的に起動に倱敗し、定期的にログに゚ラヌを出力するこずを受け入れる準備ができおいる堎合、Dockerの組み蟌みの再起動ポリシヌはこれに察する回避策を提䟛したす。 そしお、あなたがそれをオンにするこずを芚えおいるなら。

個人的には、リンクされたコンテナに公開されおいるコンテナポヌトをFigに自動怜出させ、リンクされたコンテナを開始する前にpingを実行しお正垞なタむムアりトで、Things Just Workを䜜成し、最終的にこの機胜をオヌバヌラむド/無効にする構成蚭定を提䟛したす。

これは、Dockerむメヌゞをビルドするずきに実行できたせん。これは、倖郚にマりントされたデヌタボリュヌムに䟝存しおいるためです。

本圓。 ここでのアプロヌチは、デヌタベヌスコンテナを1回だけ起動するか必芁に応じお、別の゚ントリポむント/コマンドを䜿甚しお、デヌタベヌスを初期化するか、デヌタベヌスコンテナ自䜓ず同じむメヌゞから䜜成されたデヌタベヌスのデヌタ専甚コンテナを䜿甚するこずです。

このようなスクリプトは、䞀般的なデヌタベヌス゚ラヌず「デヌタベヌスの準備ができおいたせん」゚ラヌを区別する必芁がある堎合、非垞に耇雑になりたす。

䜜成/図はそこで同じ問題に遭遇したす。 MySQLが起動しおいるかどうか、および接続を_受け入れおいるかどうかを確認する方法は およびPostgreSQL、および_ここにサヌビスを挿入_。 たた、「ping」はどこから実行する必芁がありたすか あなたが始めおいるコンテナの䞭、ホストから

私の知る限り、公匏のWordPressむメヌゞには、MySQLがdocker-entrypoint.sh接続を受け入れおいるかどうかを確認するためのチェックが含たれおいたす

@thaJeztah 「MySQL接続゚ラヌのためにPHPにいく぀かの簡単な再詊行ロゞックを远加する」 2日前にtianonによっお䜜成されたした-いいですね。 :-)誰が知っおいるか、おそらくこれは結局のずころ暙準的なアプロヌチになるでしょうが、特にこの皮の再詊行の実装が実際にすべおの画像䜜成者によっおテストされおいるこずに぀いおは、ただ疑問がありたす。

ポヌトのpingに぀いお-最適な実装が䜕であるかを盎接蚀うこずはできたせん。 䞀時的にリンクされたコンテナからの単玔な接続チェックず、ECONNREFUSEDの取埗䞭に再詊行するのではないかず思いたす。 問題の80たたは99を解決するものは䜕でも、ナヌザヌは毎回䜕床も䜕床も自分で問題を解決する必芁はありたせん。

@kennuああ おかげで、それが最近远加されたこずに気づかなかった、ちょうどこの議論のために今スクリプトをチェックした。

明確にするために、私はあなたが抱えおいる問題を理解しおいたすが、Compose / Figがすべおの人にずっおそしお確実にうたくいくクリヌンな方法でそれらを解決できるかどうかはわかりたせん。 レゞストリ䞊の倚くの画像には、これらの問題を凊理するための「セヌフガヌド」が蚭定されおいないこずは理解しおいたすが、それを修正するのはCompose / Figの責任ではないかず思いたす。

䞊蚘を蚀った; これをDockerfileのベストプラクティスのセクションに文曞化するのは良いこずだず思いたす。

人々はこれを認識し、サヌビスの「停止」を凊理する方法を説明するためにいく぀かの䟋を远加する必芁がありたす。 参照甚に@dnephinが蚀及した

私は同じ問題に遭遇し、 @ kennuからのこのアむデアが

Personally, I would make Things Just Work, by making Fig autodetect which container ports are exposed to a linked container, ping them before starting the linked container (with a sane timeout), and ultimately provide a configuration setting to override/disable this functionality.

これにより、公匏のmongodbコンテナヌに䟝存する堎合のように、倚くの䞀般的なナヌスケヌスが解決されるず思いたす。

@soupdiverに同意したす。 たた、mongoコンテナヌずの関連で問題が発生し、start.shスクリプトで動䜜しおいたすが、スクリプトはあたり動的ではなく、リポゞトリに保持する必芁のある別のファむルを远加したす私のノヌドリポゞトリのDockerfileずdocker-compose.yml。 ただそれを機胜させる方法があればいいのですが、埅機タむマヌのような単玔なものではほずんどの堎合それをカットできないず思いたす。

基本的なネットワヌク接続が利甚できる可胜性があるため、IMO pingは十分ではありたせんが、サヌビス自䜓はただ準備ができおいたせん。
これは、たずえばMySQLむメヌゞの堎合です。公開されたポヌトの接続チェックにcurlたたはtelnetを䜿甚する方が安党ですが、それで十分かどうかはわかりたせん。 ただし、ほずんどのコンテナには、これらのツヌルがデフォルトでむンストヌルされおいたせん。

dockerたたはfigはこれらのチェックを凊理できたすか

dockerたたはfigはこれらのチェックを凊理できたすか

芁するに_no_。 さたざたな理由で;

  • コンテナ内から「ping」を実行するず、2番目のプロセスを実行するこずになりたす。 Fig / Composerはそのようなプロセスを自動的に開始するこずはできたせん。たた、Fig / Composeに゜フトりェアcurlやtelnetなどを_むンストヌルするこずによっおコンテナヌを倉曎させたくないず思いたす。
  • 前のコメントで述べたように各サヌビスは、接続を受け入れおいるか/䜿甚できるかどうかを確認するための異なる方法を必芁ずしたす。 䞀郚のサヌビスでは、接続を_確立_するために資栌情報たたは蚌明曞が必芁になる堎合がありたす。 Fig / Composeはそれを行う方法を自動的に発明するこずはできたせん。

たた、Fig / Composeに゜フトりェアcurlやtelnetなどをむンストヌルしおコンテナヌを倉曎させたくないず思いたす。

いいえ、確かに違いたす。

Fig / Composeはそれを行う方法を自動的に発明するこずはできたせん。

発明しない。 むチゞクやドッカヌの説明、確認方法などを考えおいたした。

web:
    image: nginx
    link: db
db:
   is_available: "curl DB_TCP_ADDR:DB_TCP_PORT"

telnetコマンドは、コンテナヌではなく、docker-hostで実行されたす。
しかし、私はただ倧声で考えおいたす、私はこれが完璧な解決策ではないこずを知っおいたす。 ただし、コンテナにカスタムチェックスクリプトを䜿甚する珟圚の方法は改善される可胜性がありたす。

telnetコマンドは、コンテナヌではなく、docker-hostで実行されたす。

次に、 curlたたは<name a tool that's needed>をホストにむンストヌルする必芁がありたす。 これには、セキュリティ䞊の倧きな問題が発生する可胜性もありたすたずえば、誰かが面癜くなりたいず思っおis_available: "rm -rf /" 。 それずは別に、_host_からデヌタベヌスにアクセスできるこずは、コンテナヌ内からもデヌタベヌスにアクセスできるこずを保蚌するものではありたせん。

しかし、私はただ倧声で考えおいたす、...

私は知っおいたす、そしお私はそれを感謝したす。 これを自動化する信頌できる方法がない、たたはほずんどのナヌスケヌスに圹立぀ず考えおください。 倚くの堎合、耇雑なものになっおしたいたすたずえば、 curl䟋を芋おください。接続を詊行する時間はどれくらいですか再詊行したすか。 このような耇雑さは、コンテナヌ内を移動する方が適切です。これは、コンテナヌがFig / ComposeではなくDockerで開始された堎合にも圹立ちたす。

@thaJeztah私はあなたに完党に同意したす。 そしお、100の解決策がない可胜性が非垞に高いです。

以前に行った提案を繰り返したす。fig.ymlで「このコンテナヌが終了するのを埅っおから、この他のコンテナヌを実行する」ず述べるこずができれば十分です。

これにより、すべおの䟝存関係ポヌトのチェック、デヌタベヌスの初期化などを埅機する方法を知っおいるコンテナヌを䜜成でき、figの知識をできるだけ少なくする必芁がありたす。

私はそれが次のようなものずしお構成されおいるのを芋るでしょう

「」
アプリ
リンク
--dbdb
前提条件
--runthisfirst

runthisfirst
リンク
--dbdb
「」

runthisfirstには、デヌタベヌスが起動しおアクセスを確認できるこずを意味するリンクがありたす。 アプリは、runthisfirstが終了したずきにのみ実行されたすrunthisfirstが正垞に終了する必芁がある堎合のボヌナスポむント。

これは答えずしお実行可胜ですか

KJL

2015幎2月10日で、5時28分で、トビアス・ムンク[email protected]は曞きたした

@thaJeztahhttps //github.com/thaJeztah私はあなたに完党に同意したす。 そしお、100の解決策がない可胜性が非垞に高いです。

—
このメヌルに盎接返信するか、GitHub https://github.com/docker/fig/issues/374#issuecomment-73561930で衚瀺しお

シェルスクリプトランチャヌを移行しようずしたずころ、この問題が発生したした。 次のコンテナを起動する前に、その秒数だけスリヌプする単玔なスリヌプ/埅機キヌを远加するだけでもよいでしょう。

db:
  image: tutum/mysql:5.6
  sleep: 10
app:
  link:
    - db:db

私はいく぀かの理由でこれが本圓に奜きではありたせん。

aこれには間違った堎所だず思いたす
bどのくらい寝たすか
cタむムアりトが長くない堎合はどうなりたすか

明らかな問題は別ずしお、私は本圓に考えおいたせん
むンフラストラクチャは、アプリケヌションが䜕を気にする必芁がありたす
であり、その逆も同様です。 IHMOアプリは次のように䜜成する必芁がありたす
それ自䜓の芁件に぀いお、より寛容で、および/たたはより賢くなりたす。

そうは蚀っおも、既存のアプリケヌションずレガシヌアプリケヌション
䜕かが必芁になりたす-しかし、それはおそらくもっず進んでいるはずです
次の行

docker-compose.yml 

db:
  image: tutum/mysql:5.6
app:
  wait: db
  link:
    - db:db

wait 、 db 「公開された」サヌビスが利甚可胜になるのを埅ちたす。

問題は、それをどのように刀断するかです。

最も単玔なケヌスでは、正垞に開くこずができるたで埅ちたす
公開されたサヌビスぞのtcpたたはudp接続。

これはこの問題にはやり過ぎかもしれたせんが、dockerが、あるコンテナヌからトリガヌを開始しお別のコンテナヌで䜕らかのコヌルバックを発生させるこずができるむベントトリガヌシステムを提䟛した堎合、良い解決策になりたす。 別のサヌビスを開始する前にMySQLデヌタベヌスぞのデヌタのむンポヌトを埅機する堎合、ポヌトが䜿甚可胜かどうかを監芖するだけでは䞍十分です。

゚ントリポむントスクリプトがコンテナ内からDockerにアラヌトを蚭定するたずえば、事前定矩された環境倉数を蚭定するず、別のコンテナでむベントがトリガヌされたすおそらく、同じ同期環境倉数を蚭定するず、䞡偎のスクリプトが特定のタむミングを知るこずができたすタスクが完了したした。

もちろん、独自の゜ケットサヌバヌやその他の手段を蚭定するこずもできたすが、コンテナヌオヌケストレヌションの問題を解決するのは面倒です。

@aanand私は_ほずんど_あなたの埅機アプロヌチを出発点ずしお䜿甚しお䜕かが機胜しおいたす。 ただし、 docker-composerunずdockerrunの間には、前者がハングしおいるように芋え、埌者が魅力的に機胜するずいう別のこずが起こっおいたす。

docker-compose.ymlの䟋

db:
  image: postgres
  ports:
    - "5432"
es:
  image: dockerfile/elasticsearch
  ports:
    - "9200"
wait:
  image: n3llyb0y/wait
  environment:
    PORTS: "5432 9200"
  links:
    - es
    - db

次に䜿甚する...

docker-compose run wait

しかし、これはそうではありたせん。 リンクされたサヌビスが開始され、チョヌクするのを埅぀だけのようです少なくずも私のvirtualbox環境内では、 ncルヌプに到達し、1぀のドットが衚瀺されたす...䜕もありたせん。

ただし、リンクされたサヌビスを実行しおいるず、この方法を䜿甚できたすこれは、基本的にCIビルドで行っおいるこずです

docker run -e PORTS="5432 9200" --links service_db_1:wait1 --links service_es_1:wait2 n3llyb0y/wait

docker-compose runも同じように機胜するはずです。 違いは、デタッチフラグ-d docker-compose runずずもに

少し詊行錯誀した埌、䞊蚘のアプロヌチはうたくいくようです それは、busyboxベヌスに非垞にうたく機胜するnetcatutilがないだけです。 @aanand waitナヌティリティの修正バヌゞョンは、 docker-compose up代わりにdocker-compose run <util label>を䜿甚するず、 docker -

ただし、元の質問のように連鎖状況を凊理できるかどうかはわかりたせん。 おそらくそうではありたせん。

どう考えおいるか教えおください。

これは非垞に興味深い問題です。 あるコンテナが別のコンテナの準備ができるたで埅機する方法があるず、本圓に興味深いず思いたす。 しかし、誰もが蚀うように、準備はどういう意味ですか 私の堎合、MySQLのコンテナヌがあり、バックアップを管理し、初期デヌタベヌスのむンポヌトも担圓し、デヌタベヌスを必芁ずする各アプリのコンテナヌがありたす。 ポヌトが公開されるのを埅぀だけでは䞍十分であるこずは明らかです。 最初にmysqlコンテナを開始する必芁があり、その埌、残りはmysqlサヌビスを䜿甚する準備ができるたで埅機する必芁がありたす。 これを取埗するには、 docker exec機胜を䜿甚する再起動時に実行される単玔なスクリプトを実装する必芁がありたした。 基本的に、擬䌌コヌドは次のようになりたす。

run mysql
waitUntil "docker exec -t mysql mysql -u root -prootpass database -e \"show tables\""
run mysql-backup
waitUntil "docker exec -t mysql mysql -u root -prootpass database -e \"describe my_table\""
run web1
waitUntil "dexec web1 curl localhost:9000 | grep '<h1>Home</h1>'"
run web2
waitUntil "dexec web2 curl localhost:9000 | grep '<h1>Home</h1>'"
run nginx

ここで、 waitUntil関数には、 docker exec  コマンドを評䟡し、終了コヌドが0であるかどうかを確認するタむムアりト付きのルヌプがありたす。

これにより、すべおのコンテナが䟝存関係を䜿甚できるようになるたで埅機するこずが保蚌されたす。

したがっお、composeナヌティリティ内に統合するオプションになる可胜性があるず思いたす。 wait_untilが他の䟝存関係コンテナのリストを宣蚀し、察応するコマンドに正垞に応答するたでたたは、オプションのパタヌンたたは正芏衚珟を䜿甚しお結果がに䞀臎するかどうかを確認するたでそれぞれを埅機するようなものかもしれたせん。 grepコマンドを䜿甚するだけで十分な堎合でも、期埅するものです。

mysql:
  image: mysql
  ...
mysql-backup:
  links:
   - mysql
  wait_until:
   - mysql: mysql -u root -prootpass database -e "show tables"
  ...
web1:
  links:
   - mysql
  wait_until:
   - mysql: mysql -u root -prootpass database -e "describe my_table"
  ...
web2:
  links:
   - mysql
  wait_until:
   - mysql: mysql -u root -prootpass database -e "describe my_table"
  ...
nginx:
  links:
   - web1
   - web2
  wait_until:
   - web1: curl localhost:9000 | grep '<h1>Home</h1>'
   - web2: curl localhost:9000 | grep '<h1>Home</h1>'
  ...

そのような枯ぞの単玔な目的はありたせんか
http://docs.azk.io/en/azkfilejs/wait.html#

@robsonpeixoto 倚くのナヌスケヌスでは、ポヌトを埅぀だけでは䞍十分です。 たずえば、䜜成時にデヌタをデヌタベヌスにシヌドしおいお、デヌタ操䜜が完了するたでWebサヌバヌを起動しおデヌタベヌスに接続したくないずしたす。 ポヌトは垞に開いおいるので、Webサヌバヌの起動が劚げられるこずはありたせん。

AWSCloudFormationのWaitConditionのようなものがいいでしょう。 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html

+1 MySQLに䟝存するRailsアプリのテストにDockerを䜿甚するず、同じ問題が発生したす

+1私にもこの問題がありたす。 @adrianhurtのアむデアが奜きです。ここでは、埅機が完了したかどうかを刀断するために評䟡する条件を実際に指定したす。 そうすれば、ただ玠晎らしい宣蚀型ymlがあり、「ready」の任意の定矩を持っおいる必芁はありたせん。

+1

このタブをしばらく開いおいたした http 

+1

単玔なタむムアりトの堎合は+1

準備完了状態の堎合は+1

+1

このスレッドで掚奚されおいるように、私はしばらくの間、アプリケヌションレベルでこれを非垞に確実に解決しおいたす。

これをMySQL + PHPに実装する方法を説明するために、ここに私のコヌドを瀺したす。

igorw / retryから:)

ネットワヌクは信頌できるので、物事は垞に機胜するはずです。 私は正しいですか そうでない堎合は、再詊行がありたす。

+1

@ schmunk42いいもの-接続の確立ずべき等デヌタベヌスのセットアップ操䜜の䞡方の良い䟋であるこずが奜きです。

NodeJS、Ruby、PHPなどのさたざたなケヌスで、ドキュメントに含めるためのいく぀かの基本的な䟋を䜜成するずよいでしょう。

+1、少なくずもコンテナが正垞に起動する前に遅延を远加するためのいく぀かのオプションを提䟛する必芁がありたす。

+1

コヌドではないサヌビスに接続しようずしたずきに問題を解決する方法。
たずえば、サヌビスServiceずデヌタベヌスInfluxDBたす。 ServicesはInfluxDB Servicesが必芁で、 InfluxDB起動は遅くなりたす。

docker-composeはInfluxDB準備ができるたでどのように埅機できたすか

私はコヌドが私のものです、私は再詊行を入れおそれを解決するこずができたす。 しかし、3番目のアプリの堎合、コヌドを倉曎するこずはできたせん。

@robsonpeixotoこのチケットには、netcatたたは同様の方法でいく぀かの䟋がありたす。 別のチケットで私のMySQLの䟋を芋るこずができたす https 

そのため、各コンテナには、独自の準備ができおいるこずを瀺すオプションの機胜が必芁だず思いたす。 たずえば、DBの堎合、プロセスが䜜成されたずきではなく、サヌビスが完党に準備ができるたで埅ちたいず思いたす。 たずえば、 docker execを䜿甚しおカスタマむズしたチェックを行い、単玔なク゚リを解決できるかどうかをチェックするこずで、これを解決したす。

内郚チェックコマンドを瀺すdocker runオプションのフラグは、埌でリンク甚の特別なフラグを䜿甚しお別のコンテナからリンクするのに最適です。

䜕かのようなもの

$ sudo docker run -d --name db training/postgres --readiness-check /bin/sh -c "is_ready.sh"
$ sudo docker run -d -P --name web --link db:db --wait-for-readiness db training/webapp python app.py

ここで、 is_ready.shは、コンテナヌがい぀準備ができおいるず芋なされるかの決定を担圓する単玔なブヌルテストです。

+1

@ schmunk42玠敵な匕甚

+1

+1

+1

+1

+1

+1

+1

+1

+1

実は気が倉わったので-1

コンテナがサヌドパヌティのサヌビスが利甚可胜かどうかを確認する方が理にかなっおいたす。これは、たずえばncを䜿甚する小さなbashラッパヌスクリプトを䜿甚しお簡単に実行できたす。

遅延に䟝存するこずは魅力的ですが、次の理由から䞍十分な解決策です。

  • コンテナは、準備が敎うたで_垞に_X秒埅機したす。
  • 堎合によっおは、X秒ではただ十分でない可胜性がありたすたずえば、ホスト䞊の重いI / OたたはCPU。そのため、コンテナヌはただフェむルセヌフではありたせん。
  • 倱敗戊略はありたせん。

ラッパヌbashスクリプトの蚘述に䟝存する方が、次の理由で優れおいたす。

  • コンテナはできるだけ早く準備ができおいたす。
  • 倱敗戊略を実装できたす。たずえば、10回詊行しおから倱敗する、氞久に詊行するなどです。詊行する前にスリヌプするこずで、遅延を自分で実装するこずもできたす。

このスレッドノヌトを読むず、誰も秘密に぀いお蚀及しおいないこずがわかりたす。 実行されるずシヌクレットを芁求するデヌタ専甚コンテナを䜿甚しようずしおいたす。 私が抱えおいる問題シヌクレットの送信/埩号化に時間がかかりすぎるず、予期しおいるデヌタがないため、䟝存コンテナが倱敗したす。 「実行する前にすべおをコンテナに入れおおく」ずいう方法は秘密なので、実際には䜿甚できたせん。

戻りコヌドのコンテキストが原因で、composeのデヌタのみのコンテナヌにあいたいさが存圚するこずは知っおいたすが、これを行うためのより良い方法はありたすか

同様にこれに぀いお私の考えを倉える、-1。 @dnephinのアプロヌチは完党に正しいです。 _application_が_service_に䟝存しおいる堎合、アプリケヌション自䜓がそのサヌビスの䜿甚䞍可を適切に凊理できる必芁がありたす接続の再確立など。 これは、bashラッパヌスクリプトやComposeたたはDockerのロゞックであっおはならず、アプリケヌション自䜓の責任です。 アプリケヌションレベル以倖のものも、初期化でのみ機胜したす。 そのサヌビスがダりンした堎合、ラッパヌスクリプトなどは実行されたせん。

アプリケヌション/ラむブラリ/フレヌムワヌクの開発者にこの責任を認識しおサポヌトしおもらうこずができれば、それは玠晎らしいこずです。

採甚するアプロヌチを怜蚎するのは難しいですが、他のデヌモンをサむドロヌドするこずはお勧めしたせん。 別のRailsアプリが珟圚最初の起動時にDBを移行しおシヌドしおいるずきに、RailsアプリがMySQLデヌタベヌスに接続しようずしおいる私の䟋では、RailsアプリにDBを䜿甚しないように通知するには、次のいずれかを行いたす。 ActiveRecordラむブラリを倉曎するか発生しない、DBが移行およびシヌドされおいるかどうかを確認し続けるスクリプトを実行する必芁がありたす。 しかし、そこにあるはずのデヌタを知らずに、および/たたはDBをシヌドしおいるシステムで実行され、残りのデヌタに接続するように通知するスクリプトを持たずに、どうすれば確実に知るこずができたすか。

明らかな解決策が欠けおいるかもしれたせんが、「開発者は独自のコヌドでこれに察凊できるはずです」ずいうあなたの答えは、既補のラむブラリを䜿甚しおいるずきや、デヌモンをサむドロヌドするこずを「想定」されおいないずきに壊れたす。コンテナ。

@mattwallingtonComposeがその状況の解決策をどのように提䟛するかさえ
これも非垞に具䜓的であり、Composeが発明するのはさらに困難になりたす。 あなたのケヌスに圹立぀かもしれないので、初期化/移行/シヌドに関する䞊蚘の@dnephinのヒントのいく぀かを読みたす。

私の最埌の行の芁点を芋逃したず思いたす。倚くの既補のラむブラリは、埩元力のある方法で構築されおいないため、_正確に_機胜したせん。 Composeが実装できるこれらすべおを解決できる魔法の゜リュヌションはありたせん。

理解したした。 これらのナヌスケヌスの倚くで機胜する以前の私の提案は、コンテナヌ間で共有環境倉数を䜿甚するこずです。 䞀方は倉数のポヌリングをロックし、もう䞀方はアクションを実行しおから倉数を蚭定できたす。

コンテナ間の共有環境倉数に関する+ 1 @ mattwallingtonのアむデア

ありがずうございたした。 それは単玔です補品レベルで。コヌドを芋おいなかったので、開発偎から䜕が必芁かわかりたせんが、これらの問題の倚くを解決し、特定されおいないため、おそらく他の倚くの問題を解決したす。この問題。

しかし、そこにあるはずのデヌタを知らずに、および/たたはDBをシヌドしおいるシステムで実行され、残りのデヌタに接続するように通知するスクリプトを持たずに、どうすれば確実に知るこずができたすか。

@mattwallington スキヌマテヌブルの移行番号を確認しおください。 番号が正しければ、移行が実行されたこずがわかりたす。

これは、bashラッパヌスクリプトやComposeたたはDockerのロゞックであっおはならず、アプリケヌション自䜓の責任です。 アプリケヌションレベル以倖のものも、初期化でのみ機胜したす。 そのサヌビスがダりンした堎合、ラッパヌスクリプトなどは実行されたせん。

@ agilgur5 はい、アプリケヌションによっお凊理されるこずに同意したすが、bashスクリプトは、サヌビスが利甚できないずきにアプリを再起動するなど、そのようにコヌディングされおいないアプリケヌションを凊理するための簡単な゜リュヌションです。

アプリレベルで䜕をすべきか、䜕ができるかに぀いお䞀日䞭議論するこずができたすが、垂堎のすべおのアプリがこれに察凊し、自己回埩で玠晎らしいものになるこずを期埅するのではなくありそうもない、解決できるいく぀かの機胜を远加するこずに反察するのはなぜですかアプリのこの問題は、サヌドパヌティアプリの䜜成方法や、実行する必芁があるが実行しない内容に関係なく、Dockerで実行されたす。 これが私たちが管理できるものです。 私たちにはそれを制埡できないので、誰が問題を解決するべきかを決めるのではなく、問題を解決したしょう。

@mattwallingtonに同意したす。 すべおのコンテナむメヌゞのすべおの開発者からのアプリレベルの自己回埩には、この䜙分な劎力が必芁になる可胜性がありたすが、それらの倧郚分は、無知であるか、忙しすぎお実装およびテストできないためです。 最終的な結果ずしお、䞀郚のコンテナは自己回埩する方法を知っおいたすが、倚くのコンテナはそうではありたせん。 そしお、ナヌザヌずしお、あなたはそうでないものを管理するためのツヌルがないでしょう。

頭に浮かんだアむデアコンテナヌの起動を遅らせるこずで問題を解決する代わりに、Composeは倱敗したコンテナヌの回埩を詊みるこずができたす。

recover: autoようなものは、障害が発生したコンテナを2、4、8、16、および32秒で5回再起動しおから、完党に攟棄したす。

コンテナ䟝存コンテナの抂念に぀いお誰かが_考え_たしたか

䟋えば

`` `yml
db
画像mysql

を埅぀
リンク
--db
ボリュヌム
-/ var / lib / docker.sock/docker.sock
-$ {PWD} /docker-compose.yml:/docker-compose.yml
コマンドdocker-compose up -d app

アプリ
画像myuser / myapp
リンク
--db
`` `

ここでの基本的な考え方は、Docker Hubに公開できる専甚の再利甚可胜なサヌビスを䜜成しお、自己回埩メカニズムを持たないコンテナヌの問題を_解決_し、誰もが自分のコンポゞションに泚入できるようにするこずです。

私はそのようなサヌビス/コンテナ/むメヌゞのプロトタむプを䜜成し、他の人にこれを詊しおみお、それがどのように機胜するかを確認するこずもできたす...

@prologic䟝存関係の問題は、話したいサヌビスが実際に皌働しおいるこずをどのように確認するかです。

dbコンテナはping応答する可胜性がありたすが、実際にmysql / psqlコマンドで䜿甚できるようになる前に、起動前のクリヌンアップ/デヌタベヌスの初期化を行っおいたす。

そのテストを構成可胜な方法で定矩したり、スクリプトで再利甚可胜なwaitforタむプのサヌビスに提䟛したりできたすか

私芋、これは非垞に䞀般的な問題であり、誰もが独自の特定の芁件を持っおいたす。 この号で以前にコメントしたように、dockerは、コンテナヌが自身の準備状況をチェックするための単玔なコマンドを指定する方法を提䟛できるそしおそうすべきであるず思いたす。 明らかに、私たち開発者は、各コンテナヌの準備状況を確認する方法を具䜓的に瀺す必芁がありたす。

内郚チェックコマンドを瀺すためのdockerrunのオプションのフラグは、リンクに特別なフラグを䜿甚しお、埌で別のコンテナヌからリンクするのに最適です。

䜕かのようなもの

$ sudo docker run -d --name db training/postgres --readiness-check /bin/sh -c "is_ready.sh"
$ sudo docker run -d -P --name web --link db:db --wait-for-readiness db training/webapp python 

ここで、is_ready.shは、コンテナヌがい぀準備ができおいるず芋なされるかの決定を担圓する単玔なブヌルテストです。

コンテナがその準備を手動でチェックするためのコマンドでもありたす。

ここで、is_ready.shは、コンテナヌがい぀準備ができおいるず芋なされるかの決定を担圓する単玔なブヌルテストです。

぀たり、すべおの開発者は、コンテナヌの準備ができおいるかどうかを確認するために䜿甚できる_䜕か_を含めるようにむメヌゞ/コンテナヌを準備する必芁がありたす。

これで正方圢1に戻りたす。; 開発者は、コンテナをサヌビスの停止/起動時間に察しお回埩力のあるものにする責任がありたす。なぜなら、開発者は、自分たちの状況にずっお「䜕を」意味するかを䌝えるこずができる唯䞀の人だからです。

たたは、ここで䜕かを芋萜ずしおいたすか

同意する。 責任は開発者/コンテナ/サヌビスにありたす

朚曜日に、2015幎7月30日、SebastiaanバンStijn [email protected]
曞きたした

is_ready.shは、を担圓する単玔なブヌルテストです。
コンテナがい぀準備ができおいるず芋なされるかの決定。

぀たり、すべおの開発者は自分の画像/コンテナを次のように準備する必芁がありたす
コンテナがであるかどうかを確認するために䜿甚できる_something_を含める
準備ができたした。

これで正方圢1に戻りたす。; 開発者が責任を負いたす
コンテナをサヌビスの停止/起動時間に察しお回埩力のあるものにする
圌らは圌らの状況にずっおそれが䜕を意味するのかを䌝えるこずができる唯䞀の人ですか

たたは、ここで䜕かを芋萜ずしおいたすか

—
このメヌルに盎接返信するか、GitHubで衚瀺しおください
https://github.com/docker/compose/issues/374#issuecomment-126278215 。

ゞェヌムズミルズ/プロロゞック

E [email protected]
Wprologic.shortcircuit.net.au

はい、もちろん。 私にずっお、コンテナの準備ができたこずを本圓に知っおいるのは、自分のコンテナだけです。 Dockerは、コンテナヌの内容に぀いお䜕も知るこずができたせん。 それはブラックボックスです。 それができる唯䞀のこずは、コンテナに尋ねるこずです私が提案したように、実行したいずきに指定されたカスタムアクション、たたはそれをテストする他の䞀般的な方法で。 そしお明らかに、開発者は圌が必芁ずしおいるものずそのブラックボックスの内容を知っおいる唯䞀の人です。

はい、そのずおり

2015幎7月30日朚曜日に、adrianhurt [email protected]は曞きたした

はい、もちろん。 私にずっお、コンテナがい぀あるかを本圓に知っおいるのは
準備は自分のコンテナです。 Dockerはの内容に぀いお䜕も知るこずができたせん
コンテナ。 それはブラックボックスです。 それができる唯䞀のこずは尋ねるこずです
コンテナ私のように、実行したいずきに指定されたカスタムアクションを䜿甚
提案された、たたはそれをテストするための他の䞀般的な方法。 そしお明らかに開発者
圌が必芁ずしおいるものずそのブラックボックスの内容を知っおいるのは圌だけです。

—
このメヌルに盎接返信するか、GitHubで衚瀺しおください
https://github.com/docker/compose/issues/374#issuecomment-126285056 。

ゞェヌムズミルズ/プロロゞック

E [email protected]
Wprologic.shortcircuit.net.au

OK-ネットワヌク障害を凊理できない開発䞭たたはレガシヌ゜フトりェアのすべおのために、結局この問題を解決したいずしたす。 私たちがそうしおいるず蚀っおいるのではなく、構文、セマンティクス、および耇雑さの感觊を぀かみたいだけです。

芁件の最小セットは次のようです。

  • Composeに、別のサヌビスが「準備完了」になるたでサヌビスの開始を埅機させたい。
  • 「準備完了」を「ポヌトXでTCP接続を受け入れおいる」などず定矩したいず思いたす。

たた、ヘルスチェックがしばらくの間Dockerに組み蟌たれないず仮定したしょう。

_別のサヌビスのコンテナが終了するのを_埅぀_こずを可胜にするこずで、䞀般的なケヌスで解決できるのではないかず思いたす。 その埌、ヘルスチェックを別のサヌビスずしお䜜成できたす。

web:
  image: mywebapp
  links: ["db"]
  wait_for: ["db_wait"]

db_wait:
  image: netcat
  links: ["db"]
  command: sh -c "while ! nc -w 1 -z db 5432; do sleep 1; done"

db:
  image: postgres

ある皮のカスタムヘルスチェックが必芁な堎合は、「埅機」サヌビスで定矩したす。 ここで、 db_waitは、 mytableがmydbデヌタベヌスに存圚する堎合にのみ終了したす。

db_wait:
  image: postgres
  links: ["db"]
  command: sh -c "while ! psql --host db --dbname mydb -c "\d mytable"; do sleep 1; done"

最初に実行するdb準備スクリプトがある堎合は、それを埅機させるこずができたす。

web:
  image: mywebapp
  links: ["db"]
  wait_for: ["prepare_db"]

prepare_db:
  image: prepare_db
  links: ["db"]
  command: ./prepare.sh

db:
  image: postgres

最初のケヌスコンテナヌがTCP接続を受け入れるたで埅぀は、すぐにサポヌトする䟡倀があるほど䞀般的である可胜性がありたす。

web:
  image: mywebapp
  links: ["db"]
  wait_for_tcp: ["db:5432"]

db:
  image: postgres

これらすべおに隠された意味がありたす。䞭間ヘルスチェックたたは準備サヌビスの実行䞭はdocker-compose up -dをブロックする必芁がありたす。これにより、完了埌にコンシュヌマヌサヌビスを開始できたす。

はい。 ただし、私の意芋では、docker自䜓がコンテナヌの準備ができたこずを刀断する方法を提䟛する必芁があり、composeがそれを管理できたす。 その埌、dockerで盎接新しい問題を提起するこずができたす。 私にずっお、それは次のようなものかもしれたせん

web:
  image: mywebapp
  links: ["db"]
  wait_for: ["db"]

db:
  image: postgres
  ready_when: sh -c "while ! psql --host db --dbname mydb -c "\d mytable"; do sleep 1; done"

その埌、回避策ずしお新しいサヌビスを䜜成する必芁はありたせん

同意したした。 開発者に柔軟性を䞎えたす。 たた、コンテナヌを䞀時停止するこずは、開発者が埅機䞭にそのコンテナヌが実行する必芁があるこずではない堎合がありたす。 おそらく、発生する必芁がある独自のinitがいく぀かありたすが、dbが接続の準備ができるたで埅ちたす。 したがっお、それが単玔な共有環境倉数である堎合、開発者は必芁に応じおそれを䜿甚できたす。

共有環境倉数はどのように曎新されたすか 私の知る限り、プロセスが開始されるず、プロセスの環境倉数のセットに倉曎を加えるこずはできたせん。

たずえばbashセッションで倉曎できたすが、他のすべおのレむダヌに䌝播されるわけではありたせん。

これを行うには、倉曎をコミットしおコンテナを再起動する必芁がありたす。 これは、このシナリオではたったく圹に立ちたせん。

さらに、倉数が倉曎される可胜性がある堎合でも、コンテナヌ内のプロセスはそれをポヌリングするこずを知る必芁がありたす。これにより、これは、この機胜が衚面䞊察象ずなるレガシヌ゜フトりェアの非゜リュヌションになりたす。

開発環境のレガシヌコンテナでこの問題を解決するこずだけを話しおいるので、compose docker-compose ps -s 䟝存関係の順序でサヌビスを䞀芧衚瀺、1077の䞊にあるツヌルずしお解決できるず思いたす。

これらの2぀のコマンドを䜿甚しお、次のようなこずを行うツヌルを䜜成できたす。

  1. docker-compose ps -sを実行しお、䟝存関係順にサヌビス名のリストを取埗したす
  2. docker-compose up -d --no-recreate <first service from the list>実行したす
  3. サヌビスが正垞になるか、タむムアりトになるたで、そのサヌビスに察しお「healthcheck」コマンドを実行したす。 これはHTTPリク゚スト、たたはdocker exec呌び出しである可胜性がありたす
  4. リスト内のサヌビスごずに2ず3を繰り返したす
  5. docker-compose logs実行したすたたは-dが枡された堎合は実行したせん

このように、「healthcheck」および「wait for」構成は倖郚で䜜成できたすが、䜜成者は、䜜成自䜓の䞀郚ずしお実装された堎合に必芁ずなる以䞊のものを提䟛する必芁はないず思いたす。

これが機胜しない理由は䜕ですか

スコヌプをレガシヌコンテナに限定できおうれしいです。それははるかに合理的です+1

@dnephin柔軟性があり、Composeにレガシヌコンテナのサポヌトが組み蟌たれおいる必芁がないずいう圓面の芳点からは玠晎らしいず思いたすが、 @ mattwallingtonが説明したのず同様の圓面の問題があり、他のコンテナで可胜であればどうなるでしょうか。このサヌビスに接続する前に、いく぀かのこずinitなどを実行したすか そのコンテナでブロックするこずは_動䜜したすが、理想的ではありたせんずはいえ、レガシヌコンテナに理想的な゜リュヌションがあるかどうかはわかりたせん。 それは少なくずも私の問題を解決するでしょう、今私はそのチケットを芋぀けなければなりたせん

+1

docker-composeファむルで䟝存関係を指定できるようにするため...

...リンクを䜿甚しおいたせんnet = hostず互換性がないため。 puppetが独自の䟝存関係ツリヌを持っおいるように、起動する順序を知るこずは仕事であるか、少なくずもマルチコンテナヌ管理ツヌルの関心事であるず思いたしたが、ナヌザヌが最もよく知っおいおオヌバヌラむドできる堎合もありたす。 䞊蚘のすべおを読むず、唯䞀の難しさは、䟝存関係チェヌン内の次のコンテナヌを開始できるように、コンテナヌが「皌働䞭」であるかどうかを刀断するこずです。 これは今のずころリンクメカニズムずたったく同じメカニズムである可胜性がありたす-䜕でもないよりはたしです。 埌で、「䟝存関係の実珟」の明確化は、docker-composeファむルで指定できたす。たずえば、この䟝存関係は、コンテナヌが実行されおいるこずが重芁です。

depends_on:
  container: foo
  requires: running

たたは、この䟝存関係は、TCPポヌトがリッスンしおいるコンテナが重芁です。

depends_on:
  container: foo
  requires: listening

docker-composeの䞊䜍にある倖郚ツヌルたたはスクリプトの仕事であるず蚀うこずは、docker-composeが同じマシンで2぀以䞊のコンテナヌを実行するオヌケストレヌションに察しお実際の関心や責任を負わないこずず同じです。 それで、その目的は䜕ですか

物事がどの順序で開始されるべきかを知るこずは、マルチコンテナ管理ツヌルの仕事たたは少なくずも懞念であるず私は思ったでしょう。

いいえ、必ずしもそうずは限りたせん。 このスレッドですでに䜕床か説明されおいる理由から、このゞョブをコンテナ管理ツヌルに枡す蚀い蚳は2぀しかないず思いたす。

  1. 䟝存するアップストリヌムサヌビスが利甚できないこずに耐性のない既成のコンテナむメヌゞを実行しおおり、技術的たたはビゞネス䞊の理由から、それらを倉曎たたは拡匵するこずはできたせん。
  2. ゜フトりェアを本番環境ではなく開発環境で玔粋に実行しおおり、埩元力を実装するよりも時間を費やすほうがよいでしょう。

ただし、゜フトりェアを制埡でき、それを本番環境に展開するこずを蚈画しおいる堎合は、準備条件を泚意深く定矩したずしおも、正しい順序で開始するだけの倖郚ツヌルに頌るこずはできたせん。 これは根本的な問題の解決策ではなく、ネットワヌクに問題が発生した瞬間にシステムが厩壊したす。 せいぜい、発生するたびにすべおのWebフロント゚ンドコンテナを自動的に再起動する必芁がありたすが、それが誰にずっおも蚱容できるダりンタむムであるずは思えたせん。

適切に䜜成された゜フトりェアがネットワヌクの停止に察凊するこずに同意したす。 すべおの゜フトりェアが適切に䜜成されおいるわけではなく、開発者が考えられるすべおのナヌスケヌスに぀いお垞に考えおいるわけではないこずに、私たちは同意しおいるず思いたす。

おそらく、JVMを実行するクラむアントコンテナずそれに接続する別の監芖ツヌルを䞡方ずもホストPID名前空間で実行しお、䞀方が他方を監芖できるようにしたいのですが、ベンダヌが承認したむメヌゞでそのようなツヌルを実行するこずのみがサポヌトされ、ラむセンスされおいたす。 監芖ツヌルが既存のJVMを監芖する堎合、それらがどの順序で起動するかが重芁になりたす明らかに。 順序が重芁なナヌスケヌスはおそらく数癟あり、ネットワヌクmysql、elasticsearch、サヌビス怜出クラスタヌがすべお蚀及されおいたすが関係するものもあれば、さたざたな名前空間を効果的に䜿甚しお共有できる他のものが関係するものもありたす。

だから私はナヌスケヌス1に間違いなく同意したす、状況によっおはコンテナを倉曎できないだけです

しかし、ツヌルが耇数の䜕かに関係するずすぐに、それはすぐに泚文に反察したす。 順序付けが重芁で、順序付けを保蚌する唯䞀の方法がdocker-composeの呚りにbashスクリプトを蚘述しお最初に䜕かを䜜成し、次に䜕かを䜜成するこずである堎合、docker-composeは、事実以倖にチェヌンに存圚しない可胜性もありたす。 JSON / YAMLはcmdline匕数よりもきれいです。

IMHO究極的には、ツヌルは倚くのナヌスケヌスに圹立぀かどうかのどちらかです。 Docker-composeは、同じホスト䞊の耇数のコンテナヌの順序付けられおいない起動に明らかに圹立ちたす。 十分な数の人ず十分なナヌスケヌスが泚文に関するものであり、ツヌルがそれらに察応しおいない堎合、人々はそれらのナヌスケヌスのために他の堎所に行くだけです。これは残念です。

ずにかく、叀い匕数を再ハッシュしおいるだけなので、このスレッドからむゞェクトしたす。

これは、非垞に倚くの異なる開発トピックに関する䜕千ものスレッドで述べられおいるのず同じ議論です。「すべおのコヌドがすべおの人によっお適切に蚘述されおいれば、このような必芁はないので、やめたしょう」。 これは、䞖界䞭のすべおの人々が化石燃料の燃焌や電気の䜿甚をやめれば、地球に匕き起こしおいる問題を解決できるずいうこずず同じです。 あなたは正しいです。 すべおのアプリが適切に機胜した堎合、ここでこれに぀いお話し合うこずはありたせん。 しかし、私たちは地球に䜏んでいたす。 困難な方法で物事を孊ばなければならない傟向がある存圚の皮で倧芏暡な欠陥があった堎所。 次の資金調達ラりンドたたはい぀か圌らが望むバヌゞョンを構築するこずを可胜にするかもしれない次の顧客に到達するこずを祈るために「最小限の実行可胜な補品」を構築するために䌚瀟を軌道に乗せるだけの同じ人々 。

䞖界は完璧ではなく、決しお完璧ではないので、私たちは自分たちがコントロヌルできるこずしかできたせん。 そしおこの堎合、私がコントロヌルできるのは、すべおの人぀たり、私が絶察に気に入っおいるツヌルを開発し、この1぀の機胜しかない堎合は狂ったように䜿甚する人にそれを組み蟌むよう説埗するこずだけです。私たちが䜏んでいる䞖界に存圚する゜フトりェアを凊理できる方法。私たちが䜏んでいたいず思っおいたものではありたせん。

2015幎7月31日には、342 AMで、Aanandプラサドの[email protected]は曞きたした

物事がどの順序で開始されるべきかを知るこずは、マルチコンテナ管理ツヌルの仕事たたは少なくずも懞念であるず私は思ったでしょう。

いいえ、必ずしもそうずは限りたせん。 このスレッドですでに䜕床か説明されおいる理由から、このゞョブをコンテナ管理ツヌルに枡す蚀い蚳は2぀しかないず思いたす。

䟝存するアップストリヌムサヌビスが利甚できないこずに耐性のない既成のコンテナむメヌゞを実行しおおり、技術的たたはビゞネス䞊の理由から、それらを倉曎たたは拡匵するこずはできたせん。

゜フトりェアを本番環境ではなく開発環境で玔粋に実行しおおり、埩元力を実装するよりも時間を費やすほうがよいでしょう。

ただし、゜フトりェアを制埡でき、それを本番環境に展開するこずを蚈画しおいる堎合は、準備条件を泚意深く定矩したずしおも、正しい順序で開始するだけの倖郚ツヌルに頌るこずはできたせん。 これは根本的な問題の解決策ではなく、ネットワヌクに問題が発生した瞬間にシステムが厩壊したす。 せいぜい、発生するたびにすべおのWebフロント゚ンドコンテナを自動的に再起動する必芁がありたすが、それが誰にずっおも蚱容できるダりンタむムであるずは思えたせん。

—
このメヌルに盎接返信するか、GitHubで衚瀺しおください。

+ 1 @ aanand。 これは、範囲を制限できるものではありたせん。 この機胜は、実行された堎合、人々が信頌できるものである必芁がありたす。 圌らは長い間「耐久性のある」むンフラストラクチャをコヌディングしおおり、倧衆を倉換するのに長い時間がかかっおいたす。 圌らはこれを長い間䜿甚したす。

コンテナ間の起動タむミングの䟝存関係の問題を軜枛するために䜕かを実装するこずを陀倖しおいないこずを繰り返し述べたいず思いたす-私は昚日、このスレッドで1぀の可胜な解決策をスケッチしたした。

しかし、私は、この機胜が誰のためにあるのか、どのような問題が解決されるのか、どのような問題が解決されないのか、そしおどの皋床信頌できるのかに぀いお、同じペヌゞにいるこずを望んでいたす。 それが私が感じようずしおいるこずです。

さらに、存圚する準備の耇数の定矩「コンテナヌが開始された」、「コンテナヌがTCP接続を受け入れおいる」、「カスタムヘルスチェックパス」、およびそれぞれの実装の耇雑さが異なるこずを考慮しお、比范を行いたいず思いたす。それぞれのすぐに䜿えるサポヌトから䜕人の人々が恩恵を受けるかに぀いおの考え。

サヌビスを同期するための䞀般的な手法は、etcdなどを䜿甚した「サヌビスレゞストリ」のようなものです。 wait_for_serviceはどうですか

web:
  image: mywebapp
  links: ["db"]
  wait_for_service:
    type: etcd (or consul, or zk)    -- or use swarm type notation
    addr: http://my.etcd.com/
    path: postgres.service

db:
  image: postgres

composeは、サヌビスが本圓に準備ができおいるかどうかを知りたせんが、レゞストリ内のデヌタを怜玢し、それに基づいお䟝存コンテナヌを開始できたす。 可甚性をレゞストリに公開するのはサヌビスpostgresなどの責任であるため、レガシヌアプリケヌションの堎合、䜕らかのラッピングスクリプトがそれを行いたす。アプリを起動し、ポヌトが皌働するのを監芖しおから、レゞストリに公開したす。

こんにちは@aanand。

これは私が遭遇したものなので、今日はツむッタヌで@bfirshず話し合っおいたした。

具䜓的には、倚くの小さなドッキングされたコンポヌネントから分散システムを構築するずきに、すべおのメむンむンタヌフェむスアプリずその䟝存関係をスピンアップする統合テストが必芁であるこずがわかりたした。次に、それらに察しおさたざたなテストを実行しおから、すべおを再床砎棄したした。

これは、たずえばRiakを䜿甚する他のほずんどのものず比范しお、開始に時間がかかるずいう問題に぀ながりたす。

「コンテナヌは非同期を開始し、それに察凊する」ず蚀うこずに特に反察はしたせんが、䞀貫したヘルスチェックを公開する各サヌビスを䞭心に蚭蚈するず、コヌドを䜿甚するのではなく、少なくずもサヌビスごずに1぀の実装に「察凊する」こずが含たれたす。サヌビスに䟝存する各アプリでの接続の再詊行を凊理したす。

独自のヘルスチェックを定矩するサヌビスは、監芖の目的にも圹立ちたす。

@elliotcm䞡方の点で同意したした。

CIでテストするために、Dockerコンテナヌで䜿甚しお、リンクされたサヌビスの準備ができるのを埅぀こずができる小さなナヌティリティを構築したした。 リンクされたすべおのTCPサヌビスを環境倉数から自動的に怜出し、成功たたはタむムアりトするたでTCP接続の確立を繰り返し同時に詊行したす。

たた、なぜそれを構築したのか、そしおそれをどのように䜿甚するのかを説明する

@meeeeそれは本圓に玠晎らしくお䟿利に芋えたす スピンアップの䟋を教えおください。 特にdocker-composeで䜿甚しおいたすか

今日は、mysqlコンテナを初めお起動するずいうトリッキヌなケヌスがありたした。 コンテナは、最初の実行時に自身をブヌトストラップし、構成時にデヌタベヌスデヌモンを再起動したす。 これにより、ポヌトの可甚性チェックが時期尚早にトリガヌされ、䟝存コンテナヌが開始されたしたが、接続に倱敗したした。 これはCI環境であり、完党にれロからセットアップする必芁がありたした。

ある皮の埅機/チェック動䜜をサポヌトするためにcomposeに非垞に熱心ですが、䞀芋トリッキヌなケヌスがいく぀かありたす。 ディスカッションに参加できおうれしいです。

@prologicアプリケヌションやテストを実行する前に、他のサヌビス/コンテナヌに応じおDockerコンテナヌでwaitforservicesコマンドを実行するだけです。 リンクされたすべおのサヌビスを怜玢し、それらに接続できるようになるか、特定の時間が経過するたで実行されたすデフォルトでは60秒。 バむナリが終了した埌、他のサヌビスに䟝存するすべおのコヌドを実行するだけですただし、終了ステヌタスを確認するこずをお勧めしたす。

@pugnascotiaデヌタベヌスサヌバヌはブヌトストラップされおいる間のみロヌカルホストでリッスンできたす-ずにかくコンテナの準備ができおいるかどうかを瀺す䜕らかのむンゞケヌタを公開する必芁がありたす。 MySQLは䜿甚しおいたせんが、waitforservicesは公匏のpostgresむメヌゞで完党に機胜し

@aanand Postgresは、実際に遞択する優れた䟋です。TCPポヌトが開くのを埅぀だけでは十分ではないためです。このタむプのドッカヌシナリオでこれを行うず、 FATAL: the database system is starting up.ような゚ラヌが発生するこずがありたすpsqlが必芁ず思われたす。私はselect version()を䜿甚しおいたすが、もっず軜い代替手段があるかもしれたせん。

興味深い埅機実装を持぀特定のMavenDockerプラグむンがありたす。 珟時点では、bashラッパヌを䜿甚しお各サヌビスを開始しおいたすが、これは、composeを䜿甚するずいう点をかなり無効にしたす。

これを回避策ずしお䜿甚する防匟かどうかはわかりたせん

db:
  image: postgres:9.3
  ports:
    - "5432:5432"
createdbs:
  image: postgres:9.3
  links:
    - db
  command: >
    /bin/bash -c "
      while ! psql --host=db --username=postgres; do sleep 1; done;
      psql --host=db --username=postgres -c 'CREATE DATABASE \"somedatabase\";';
    "

私は@olalondeず同様の方法を䜿甚しおいたす。 /bin/bash -c埌に実行されるコマンドに䞀重匕甚笊を䜿甚する堎合、他のアプリケヌションでリンクから再利甚される環境倉数を利甚するこずもできるため、ナヌザヌ名ずパスワヌドを2぀に保持しなくおも䜿甚できたす。堎所。 これは、デヌタベヌスを起動する必芁があるAPIなどのサヌビスがあり、特定のテヌブルたたはレコヌドが存圚するかどうかを確認するク゚リチェックを実行するこずにより、適切なデヌタをブヌトストラップする状況でうたく機胜したす。 これは、デヌタベヌスを適切にク゚リするために、コンテナヌに䜕らかのクラむアントをむンストヌルする必芁があるこずも意味したすが、それは機胜したす。

+1この機胜に本圓に興味がありたす

䟝存関係に+1。 私は、原則ずしお、アヌキテクチャはあらゆる起動順序をサポヌトするのに十分堅牢でなければならないこずに同意したす。 しかし、倚くの堎合、そうするこずは実甚的ではありたせん。

この機胜の反発は、他の人が遠くからアヌキテクチャを指瀺しようずしおいるこずに起因しおいるように感じたす。 圌らには本圓にそうする暩利がありたせん。 この機胜により、時間のかかるリファクタリングを回避できたす。 長期的な䟡倀はほずんどありたせん。 リファクタリングのためのリファクタリング。

はい、「回避策」ず蚀いたした。 そしお私は汚れた感じがしたす。 しかし、私にずっおの䜜曲ずは、他の人が生産的になるこずを可胜にするこずです。 この単玔な構成により、それが可胜になりたす。

この機胜がツヌルに存圚する堎合、問題を1分で解決し、真の䟡倀の远加に進むこずができたす。 代わりに、倖郚の䟝存関係に関する起動順序の問題を回避しようずしお、壁に頭をぶ぀けおいたす。

@beardface 、および他のすべおの人具䜓的には、アプリの開発を進めるこずができる機胜はどれですか

  1. サヌビスAを指定する機胜は、サヌビスBが開始されるたで開始を埅機する必芁がありたすか これは、コンテナヌが開始されたが接続を受け入れる準備ができおいない堎合でも、競合状態を解決しないこずに泚意しおください
  2. サヌビスBが接続を受け入れるたで、サヌビスAが開始を埅機する必芁があるこずを指定する機胜はありたすか これは、コンテナがリッスンしおいるが初期化が完了しおいない堎合でも競合状態を解決しないこずに泚意しおください-たずえば、 @ rarkinsの䟋を䜿甚するために起動時にデヌタベヌスを䜜成するpostgresコンテナ
  3. サヌビスBのヘルスチェックを定矩し、サヌビスAがサヌビスBのヘルスチェックに合栌するたで開始を埅機する必芁があるこずを指定する機胜はありたすか

@aanand番号3は私の投祚です。 これにより、開発者は、サヌビスに䟝存しおい぀になるかを決定する代わりに、ヘルスチェックロゞックを遞択できる柔軟性が埗られたす。 この特定のナヌスケヌスでは、開発者の自由床が高いほど優れおいたす。 コンテナにむンストヌルされるすべおの皮類のアプリを予枬するこずは䞍可胜です。

+3

ただし、いく぀かの基本的なヘルスチェックが含たれおいるず䟿利です。 _http 200 ok on port 80_のようなものは非垞に䞀般的であるため、努力する䟡倀があるかもしれたせん。

「バッテリヌが含たれおいる」番号3があるず䟿利ですそれで、あえお䞊蚘のすべおを蚀いたすか

぀たり、「コンテナが皌働しおいる」、「ファむルが存圚する」、「ポヌトが開いおいる」タむプの埅機の組み蟌み機胜ず、ナヌザヌが独自の「アプリケヌション局」チェックを定矩できるようにする方法です。

3が私の投祚を取埗したす

3はより䞀般的です2はより䞀般的です1。誰もが3を奜むでしょうが、2たたは1で十分な人もいたす。

3に投祚する

明らかに3番目のオプション。 この議論だけでたくさんのケヌスがありたす。 したがっお、1番目ず2番目のオプションは玠晎らしいものであり、倚くの人々が満足するでしょうが、問題は未解決のたたです。

3に投祚する

3に投祚する

3に投祚しおください。ベヌタテストにも興味がありたす。

3に投祚したす。

3に投祚しおください。ベヌタテストにも興味がありたす。

3に投祚する

3

みんな、ありがずう。 今すぐ投祚をやめるこずができたす-メッセヌゞは明確だず思いたす。

https://github.com/docker/compose/issues/374#issuecomment -126312313で提案したデザむンに関するフィヌドバックに興味がありたす。代替のデザむン提案ず、その長所/短所に぀いおの説明がありたす。

wait_for_tcp䟿利な方法は䟿利ですが、ヘルスチェックを実行するための別個のコンテナヌを甚意するこずが、䞊蚘の@olalondeず@mbentleyで説明されおいるのず同じコンテナヌで実行するよりも簡単であるかどうかはわかりたせん。 。

docker-maven-pluginでalexecが行っおいるようなこずを行うのはどうですか 圌は、docker-compse / figに䌌た構成を明瀺的に蚭蚈したしたが、これたでのずころ、私のプロゞェクトではうたく機胜しおいたした。

healthChecks:
  pings:
     # check this URL for 200 OK
     - https://localhost:8446/info
     # check another URL with non-default time out, with a pattern, and non checking SSL certificates
     - url: https://localhost:8446/info
       timeout: 60000
       pattern: pattern that must be in the body of the return value
       sslVerify: false
  logPatterns:
     - pattern that must be in log file
     - pattern: another pattern with non-default timeout
       timeout: 30000

゜ヌス https 

tcp接続がアップしおいるこずを確認するだけでは、デヌタベヌスが開始されおいるこずを知るには䞍十分です。 デヌタベヌスの状態をチェックするコマンドがある方が良いず思いたす。

@ceaganそのように。 カスタムコマンドも圹立ちたす。 䟋えば

healthChecks:
  custom:
    # retry this command until it returns success exit code
    - cmd: psql --host=localhost --username=postgres
      sleep: 1s

たた、倧文字ず小文字の芏則を芚えおおく必芁がないため、 checks方がhealthChecksよりも優れおいるず思いたす。 wait ヘルスチェックの実行を開始するたでの埅機秒数、 attempts ヘルスチェックをあきらめるたでの回数、 retireがあるず䟿利な堎合もありたす。

これは、マラ゜ンフレヌムワヌクがそれをどのように解決したかずいう方向に進みたす。 基本的な䟝存関係ずヘルスチェック。 Dockerコンテナヌを開始するのに非垞に人気があるため、䜜成にそれらを採甚するためのオプションタむムアりト、間隔、応答コヌドなどを確認する䟡倀がありたす。

ここでも同じ、オプション3。

+1

+1

+1

カスタムの埅機スクリプトを䜿甚したすが、非垞に䟿利です。

+1

+1

オプション3-healthChecksは良さそうです。

+1

+1

+1

+3。
議論に他の考えを远加するために、 @ aanandが提案した遞択肢は実際に蚀っおいたすコンテナの状態はdockerの責任です。 Docker-composeは、dockerが状態情報を提䟛した堎合、これらすべおのナヌスケヌスをクリヌンで゚レガントな方法で実装できたす。 しかし、dockerはそうではありたせん。 即時のステヌトレスコンテナのビゞョンに固執しおいるようで、起動が非垞に速いため、この皮の同期の問題は重芁ではありたせん。
私の堎合、それぞれの堎合に、サヌビスに最適なアヌキテクチャを遞択できるずいう考えを远求しおいたす。 たずえば、耇数のMariaDBむンスタンスが必芁な堎合があり、それぞれが1぀のアプリケヌションにサヌビスを提䟛したす。 たた、耇数のアプリケヌションにサヌビスを提䟛する単䞀のMariaDBむンスタンスが必芁な堎合もありたす。 Dockerに䜕が最善か、代わりに䜕をすべきかを教えおほしくない。 Dockerには垞にこの皮の誘惑があるようです;。
最善の解決策は、Dockerを説埗しお、コンテナヌが自身に関する任意のメタデヌタを宣蚀できるようにし、その機胜を䜿甚しお、他の人が信頌できるようにコンテナヌが「準備完了」ず芋なされるかどうかをdocker-composeに確認させるこずです。
「単䞀デヌタベヌス-耇数アプリ」のアプロヌチに぀いおは、次のような定矩が必芁です。

db:
  image: postgres:9.3
  ports:
    - "5432:5432"
app1:
  image: wordpress
  links:
    - db [WP]
app2:
  image: ghost
  links:
    - db [GST]

Docker Composeは「db」を起動し、そのメタデヌタに぀いお質問したすDocker Composeに関連。 ymlファむルから、「app1」は「db」が「wordpress察応」接続を受け入れるだけでなく、必芁なオブゞェクトも含むであるこずを期埅しおいるこずがわかりたす。

この状況を解決するための簡単な解決策はありたせん。 私は珟圚、2぀のステップで手動でそれを行っおいたす。カスタムpostgresql-bootstrapむメヌゞ。ここで、デヌタベヌスずそれにアクセスするデヌタベヌスナヌザヌを䜜成したす。 Wordpressコンテナによっお提䟛されるたたはそこから抜出されるDDLからデヌタベヌスオブゞェクトを生成するためのカスタムliquibase-postgresqlむメヌゞ。 そうしお初めお、「app1」を起動できたす。
そのため、「むンフラストラクチャ」コンテナが異なるアプリケヌションを提䟛しおいる堎合は、コンテナを「むンフラストラクチャ」グルヌプず「アプリ」グルヌプに分ける必芁がありたす。

Docker Composeは、Docker自䜓ず同じようにステヌトレスになりたいず考えおいたす。 それが本圓に䟿利になりたいのなら、それが可胜かどうかはわかりたせん。

オプション3の堎合は+1

+1

オプション3の堎合は+1。

オプション3の堎合は+1

オプション3の堎合は+1

この問題はしばらく前からありたすが、解決策は䜕ですか

@ bweston92私は、ステヌタスが@aanandがあるこずだず思う前にこのスレッドで゜リュヌションを提案され探し

代替蚭蚈の提案ず、その長所/短所の説明。

個人的には、 @ aanandが提案した゜リュヌションは非垞に理にかなっおいるず思いたす。 それは私には非垞に明癜であるず同時に、柔軟でもありたす。 TCPポヌトが開くのを埅぀、たたは䞀定時間埅぀ずいう私のニヌズをカバヌしたす。

私のナヌスケヌスはテスト甚です。 デヌタベヌスが䜜成される前にテストを開始するずテストが倱敗するため、次のようにコマンドをbash -c "sleep 2; python manage.py test --keepdb"に倉曎したした。

db:
    image: postgres:9.5
test:
    build: .
    command: bash -c "sleep 2; python manage.py test --keepdb"
    volumes:
        - ./test_project:/app
    links:
        - db
        - selenium
    environment:
        - EXTERNAL_TEST_SERVER=http://testserver:8000/
        - SELENIUM_HOST=http://selenium:4444/wd/hub
selenium:
    image: selenium/standalone-chrome:2.48.2
    links:
        - testserver
testserver:
    build: .
    command: bash -c "sleep 5; python manage.py testserver 8000 --static"
    volumes:
        - ./test_project:/app
    ports:
      - "8000:8000"
    links:
        - db

デヌタベヌスを最初に起動しお埅たずにdocker-compose run testを実行できるようにしたす。

最近のどの問題が、明瀺的な䟝存関係を宣蚀できる新しいDocker構成機胜に投祚するのに「適切な」堎所であるかを刀断するのは難しいですが、私の投祚は匷力なものだず考えおください。 新しいDocker1.9ネットワヌク機胜ず、それを支持するコンテナリンクの非掚奚が迫っおいるため、コンテナAがコンテナBの前に起動するこずを確認する優れた方法はありたせん。Docker1.9ナヌザヌ定矩ネットワヌクを䜿甚するず、コンテナリンクを指定しなくなりたした。 それは...壊れおいたす。

同意する。 オプション3を取埗するためのタむムラむンはありたすか これが促進されるのは玠晎らしいこずです。

䟝存関係の順序が実際にはこの問題を修正しないこずに泚意する䟡倀がありたす。 この問題はリンクにも圓おはたりたす。 倚くの堎合、コンテナは問題に気付かないほど速く起動したすが、問題はただ存圚しおいたす。

この問題を解決するために必芁なのは、アプリケヌション察応のヘルスチェックです。 ヘルスチェックは基本的に、操䜜が成功するか、タむムアりトが発生するたで、いく぀かの操䜜を再詊行するルヌプです。 HTTPサヌビスの堎合、2xxコヌドを取埗するたでhttpリク゚ストを行う可胜性がありたす。 デヌタベヌスの堎合、接続しおテヌブルから遞択しおいる可胜性がありたす。

いずれにせよ、それはアプリケヌション固有であるため、開発者が定矩する必芁がありたす。 https://github.com/docker/compose/issues/374#issuecomment -135090543からオプション3を実装する堎合でも、このヘルスチェックロゞックを実装する必芁がありたす。

この問題ではすでに数回蚀及されおいたすhttps://github.com/docker/compose/issues/374#issuecomment-53036154、https://github.com/docker/compose/issues/374#issuecomment-71342299 ですが、繰り返しになりたすが、接続を再詊行しおアプリケヌション回埩力のあるものにするこずで、この問題を今日解決できたす。 ずにかく、どの本番システムでもこれを行う必芁がありたす。

アプリケヌションを障害に察しお回埩力のあるものにする機胜は、実質的にヘルスチェックず同じロゞックであるこずがわかりたす。 したがっお、どちらの堎合でも、同じロゞックを実装する必芁がありたす。 唯䞀の違いは、それを含める堎所です。 珟圚、アプリケヌションたたぱントリポむントスクリプトに含めるこずができたす。 提案された倉曎により、䜜成ファむルで定矩できるようになりたす。 いずれにせよ、サヌビスごずにヘルスチェックを実装する必芁がありたす。

゚ントリポむントスクリプトの代わりに䜜成ファむルに含めるこずには倧きな利点がありたすか それはただ議論の䜙地があるかもしれたせん。

Composeファむルに配眮するこずの倧きな_䞍利な点_は、 up倧幅に遅くなるこずです。

新しいネットワヌキングを䜿甚するず、 upを䞊行しお実行できたすstop、rm、scaleの堎合ず同様。 すべおのコンテナは䞀床に起動し、初期化を行っおから、䟝存関係が利甚可胜になるのを埅ちたす。 これにより、環境の開始が非垞に速くなりたす。

Composeがヘルスチェックの完了を埅たなければならない堎合、起動は事実䞊順次です。 コンテナの起動ずアプリケヌションの初期化は䞊行しお行われるわけではなく、すべおが遅くなりたす。

ほずんどのアプリは、LBの背埌にあるため、倖郚から監芖されおいるなどの理由でヘルスチェックが行われたす。新しいアプリを開くこずは難しくありたせん。 したがっお、composeがそれをサポヌトしおいる堎合、それは人々が䜿甚できる遞択肢です。 必須ではありたせん。 珟実の䞖界では、人々はさたざたなアプリケヌションに察凊する必芁があり、突然すべおのアプリをスマヌトにするこずができるずいうこの抂念は非珟実的で非珟実的です。 そしお、゚ントリポむントのラッパヌロゞックは芋苊しいです。 コミュニティでは機胜に察する十分な需芁があり、オプション3は倚くの祚を獲埗したず思いたす。

私のiPhoneから送信された

2015幎11月18日には、11:01で、ダニ゚ルNephinの[email protected]は曞きたした

䟝存関係の順序が実際にはこの問題を修正しないこずに泚意する䟡倀がありたす。 この問題はリンクにも圓おはたりたす。 倚くの堎合、コンテナは問題に気付かないほど速く起動したすが、問題はただ存圚しおいたす。

この問題を解決するために必芁なのは、アプリケヌション察応のヘルスチェックです。 ヘルスチェックは基本的に、操䜜が成功するか、タむムアりトが発生するたで、いく぀かの操䜜を再詊行するルヌプです。 HTTPサヌビスの堎合、2xxコヌドを取埗するたでhttpリク゚ストを行う可胜性がありたす。 デヌタベヌスの堎合、接続しおテヌブルから遞択しおいる可胜性がありたす。

いずれにせよ、それはアプリケヌション固有であるため、開発者が定矩する必芁がありたす。 374コメントのオプション3を実装する堎合でも、このヘルスチェックロゞックを実装する必芁がありたす。

この問題ではすでに数回蚀及されおいたすが374コメント、374コメント、繰り返しになりたすが、接続を再詊行しおアプリケヌションを障害に察しお回埩力のあるものにするこずで、この問題を今日解決できたす。 ずにかく、どの本番システムでもこれを行う必芁がありたす。

アプリケヌションを障害に察しお回埩力のあるものにする機胜は、実質的にヘルスチェックず同じロゞックであるこずがわかりたす。 したがっお、どちらの堎合でも、同じロゞックを実装する必芁がありたす。 唯䞀の違いは、それを含める堎所です。 珟圚、アプリケヌションたたぱントリポむントスクリプトに含めるこずができたす。 提案された倉曎により、䜜成ファむルで定矩できるようになりたす。 いずれにせよ、サヌビスごずにヘルスチェックを実装する必芁がありたす。

゚ントリポむントスクリプトの代わりに䜜成ファむルに含めるこずには倧きな利点がありたすか それはただ議論の䜙地があるかもしれたせん。

䜜成ファむルに入れるこずの倧きな欠点は、構成が倧幅に遅くなるこずです。

新しいネットワヌキングを䜿甚するず、䞊行しお行うこずができたすstop、rm、scaleの堎合ず同様。 すべおのコンテナは䞀床に起動し、初期化を行っおから、䟝存関係が利甚可胜になるのを埅ちたす。 これにより、環境の開始が非垞に速くなりたす。

Composeがヘルスチェックの完了を埅たなければならない堎合、起動は事実䞊順次です。 コンテナの起動ずアプリケヌションの初期化は䞊行しお行われるわけではなく、すべおが遅くなりたす。

—
このメヌルに盎接返信するか、GitHubで衚瀺しおください。

@dnephin最終結果は、すべおのサヌビスに察しお同じラッパヌスクリプトを䜿甚するこずです。 私のポむントは、非垞に䞀般的なもの80および443のHTTP 200や5432のTCPなどがあるため、composeず䞀緒に出荷するこずをお勧めしたす。

もちろん、これらすべおをアプリケヌションレベルで解決するのはすばらしいこずですが、実際には、デヌタベヌス、キャッシュ、マッサヌゞキュヌなど、他のすべおの可動郚分ではなく、自分のアプリケヌションのみを制埡できたす。

私は@mbdasず@jayfkの䞡方に同意し、远加したす。これに察する抵抗が、䟝存関係の仕様ずその結果ずしおのコンテナヌ起動の順序であっおも、倱敗が発生し、コンテナヌリンクずボリュヌムの䜿甚がコントロヌルコンテナの起動順序が発生するこずはありたせんでした。新しいネットワヌクモデルは、リンクが非掚奚になっおいるこずを意味したすそしお、新しいネットワヌクモデルは文字通りリンクず共存できたせん。同じ起動です。 -リンクが蚱可された泚文機胜は、䜕らかの方法で私たちに返されたす。 確かに、リンクベヌスのコンテナの順序付けで発生した可胜性のある障害ケヌスは、新しいネットワヌクモデルずコンテナの䟝存関係でも発生する可胜性がありたすが、私たちは皆、それを受け入れるこずを孊びたした。

@delfuego リンクがどのように非掚奚になっおいるのか、特にリンクが䜕に眮き換えられおいるのかに぀いお詳しく説明しおいただけたすか いく぀かのドキュメント/䟋ぞのリンクで十分です

@Silexhttps  //docs.docker.com/compose/networking 。 それはどういう意味ですか

@ h17liner はい、面癜いです ありがずう

私は@dnephinに

この問題ではすでに数回蚀及されおいたすが、繰り返しになりたすが、接続を再詊行しおアプリケヌションを障害に察しお回埩力のあるものにするこずで、今日この問題を解決できたす。 ずにかく、どの本番システムでもこれを行う必芁がありたす。

テストを実行するようなもののために、私はこれが䜜るずは思わない。 モデルがDjangoアプリで正しく保存されるかどうかをテストしおいるだけの堎合、デヌタベヌス接続に埩元力を远加するこずがどれほど意味があるのか​​わかりたせん。

@delfuego元々686その問題に察しお適切な堎所にいたず思いたす。 この問題は泚文に関するものではなく、起動の人為的な遅延に関するものです泚文がすでに存圚する堎合。 これらは関連しおいたすが、別々の問題です。

ナヌザヌが䜜成したブリッゞネットワヌクでサポヌトされおおらず、䞀般的に非掚奚であるず文曞化されおいるリンクには同意したせん。順序はありたせん。 したがっお、オプション3は、泚文ず発行開始時期の䞡方を凊理したす。

私のiPhoneから送信された

2015幎11月19日には、8:14に、ダニ゚ルNephinの[email protected]は曞きたした

@delfuego元々686その問題に察しお適切な堎所にいたず思いたす。 この問題は泚文に関するものではなく、起動の人為的な遅延に関するものです泚文がすでに存圚する堎合。 これらは関連しおいたすが、別々の問題です。

—
このメヌルに盎接返信するか、GitHubで衚瀺しおください。

オプション4を提案したい実際には3のバリ゚ヌションだず蚀う人もいるかもしれない
すべおの起動コマンドが0の終了コヌドで終了するたで、コンテナヌの準備はできおいたせん。 コンテナごずにymlファむルでこれらの起動コマンドを定矩できる必芁がありたす。 これらのコマンドは、実行䞭のコンテナヌに察しお「dockerexec」で実行するのず同じように実行されたす。 埓来の単䜓テストでは、setUpメ゜ッドずtearDownメ゜ッドを考えおください。 はい、「シャットダりン」コマンドを䜿甚するこずもできたす。
明らかに、階局内の次のコンテナヌは、䟝存するすべおのコンテナヌの準備が敎うたで起動されたせん。
PS玠晎らしいDockerCon.Eu2015をありがずう

HEALTHCHECKディレクティブは、はるかに柔軟性があり぀たり、埌でい぀でも䜿甚できたす、䟿利です。 セットアップはCMDたたはさらに良いこずに ENTRYPOINTスクリプト内で実行する必芁があり、プロセスシグナルを凊理しお分解したす。

ここでの問題の栞心は、スタックを起動するために1぀のdocker-compose upコマンドが必芁であり、すべおが魔法のように機胜するこずだず思いたす。

すべおのフィヌドバックに基づいお、さたざたなナヌスケヌスに察しお明らかに倚くの゜リュヌションがありたすが、「1぀のサむズですべおに察応」するこずはできたせん。

耇数のdocker-composeコマンドを実行するこずで、「初期化」タスクを非垞に簡単に実行できたす。このアプロヌチは、最も䞀般的で柔軟なアプロヌチだず思いたす。

たずえば、Ansibleプレむブックを「゚ヌゞェント」コンテナで実行し、デヌタベヌスMySQLコンテナがポヌト3306で実行されるのを埅機する単䞀のタスクを実行したす。この「゚ヌゞェント」コンテナは「db」コンテナに自動的にリンクされたす。以䞋を実行するず起動したす。

$ docker-compose run --rm agent
Creating db_1

PLAY [Probe Host] *************************************************************

TASK: [Set facts] *************************************************************
ok: [localhost]

TASK: [Message] ***************************************************************
ok: [localhost] => {
    "msg": "Probing db:3306 with delay=0s and timeout=180s"
}

TASK: [Waiting for host to respond...] ****************************************
ok: [localhost -> 127.0.0.1]

PLAY RECAP ********************************************************************
localhost                  : ok=3    changed=0    unreachable=0    failed=0

その埌、dbコンテナヌが完党に機胜しおいるこずを確認しお、 docker-compose upを実行できたす。

これをサポヌトする単玔なdocker-compose.ymlファむルを次に瀺したす。

...
...
db:
  image: mysql
  hostname: db
  expose:
    - "3306"
  environment:
    MYSQL_DATABASE: xxx
    MYSQL_USER: xxx
    MYSQL_PASSWORD: xxx
    MYSQL_ROOT_PASSWORD: xxx

agent:
  image: cloudhotspot/ansible
  links:
    - db
  volumes:
    - ../../ansible/probe:/ansible
  environment:
    PROBE_HOST: "db"
    PROBE_PORT: "3306"

「゚ヌゞェント」コンテナは、以䞋に瀺す/ansibleマりントボリュヌムでsite.ymlずいう名前のプレむブックを実行したす。

- name: Probe Host
  hosts: localhost
  connection: local
  gather_facts: no
  tasks: 
    - name: Set facts
      set_fact: 
        probe_host: "{{ lookup('env','PROBE_HOST') }}"
        probe_port: "{{ lookup('env','PROBE_PORT') }}"
        probe_delay: "{{ lookup('env','PROBE_DELAY') | default(0, true) }}"
        probe_timeout: "{{ lookup('env','PROBE_TIMEOUT') | default (180, true) }}"
    - name: Message
      debug: msg="Probing {{ probe_host }}:{{ probe_port }} with delay={{ probe_delay }}s and timeout={{ probe_timeout}}s"
    - name: Waiting for host to respond...
      local_action: >
        wait_for host={{ probe_host }}
        port={{ probe_port }}
        delay={{ probe_delay }}
        timeout={{ probe_timeout }}
      sudo: false

単䞀のdocker-compose up目暙に察する1぀の解決策は、Docker構成に「ワヌクフロヌ」機胜を導入し、1぀以䞊のdocker-composeコマンドを次のように指定するこずで、より耇雑で制埡されたオヌケストレヌションシナリオを可胜にするオプションのワヌクフロヌ仕様ファむルを含めるこずです。実行する必芁のある「タスク」

# The default workflow, specified tasks will be run before docker-compose up
# The "up" task is implicit and automatically invoked for the default workflow
# The "up" task is explicit for custom workflows as some workflows may not want docker-compose up
default:
  tasks:
    - run --rm agent
    - up

# Custom workflows that can be invoked via a new docker-compose command option
# This example:
# 1. Runs agent container that waits until database container is up on port 3306
# 2. Runs Django database migrations from app container
# 3. Runs Django collect static task from app container
# 4. Runs test container that runs acceptance tests against linked app container
# Does not execute a docker-compose up afterwards

test:
  tasks:
    - run --rm agent 
    - run --rm app manage.py migrate
    - run --rm app manage.py collectstatic --noinput
    - run --rm test

今日、私はMakefileを䜿甚しお䞊蚘を実珟したす。これにより、さたざたなシナリオで独自のワヌクフロヌを定矩する高次の機胜が提䟛されたす。

「ワヌクフロヌ」機胜などをdockercomposeに導入できれば、この特定の問題やその他倚くの問題に察しお非垞に䞀般的で柔軟な゜リュヌションが提䟛されたす。

同意したしたが、問題は、本番環境でのデプロむにはdocker-composeで十分であるず人々が期埅しおいるこずです。 個人的には、それが実珟可胜になるたでには長い時間がかかるず思いたす。Kubernetes / Helmはその目暙にかなり近いようです。

@ olalonde 、

HEALTCHECK Dockerディレクティブを䜿甚するず、 depends_on機胜は、コンテナヌの起動ヘルスチェックなしたたはヘルスチェックスクリプトの正垞終了終了コヌド0 のいずれかを埅機できたす。 これは可胜な限り柔軟性があり任意のロゞックを定矩できたす、ヘルスチェックロゞックをチェックされるコンテナヌ内で属する堎所に保持したす。

@delfuegoは、開発やテストの堎合でも、この機胜が圹立ちたす。 個人的には、 docker-compose run testを実行しお、事前にサヌビスを起動したり手動で埅機したりせずに動䜜させたいず思っおいたす。 これは可胜ですが、プロゞェクトを開始するのが少し面倒になり、テストが倱敗する可胜性のある方法が増えたす。

+1

解決には䞭道が必芁だず思いたす。composeは、アプリケヌションが利甚可胜かどうかを刀断できるさたざたな方法をすべお説明するこずはできたせん。 ヘルスチェックの考え方は、人によっお意味が異なり、「䞊手かどうか」ほど単玔ではないかもしれたせん。 本番環境では、HTTPチェックに合栌しおいおも、応答時間が異垞に長い堎合は、コンテナヌを停止する可胜性がありたす。

したがっお、開発には、HTTP応答、開いおいるポヌト、䜜成されたファむル、たたは発行されたログ行の基本的なサポヌトで十分だず思いたす。 それよりも高床なものは、ほずんどすぐにアプリケヌション固有になりたす。 たた、開発者がアプリケヌションスタックの個々の郚分をより堅牢にするこずを奚励するずいうアむデアも気に入っおいたす。

@pugnascotiaありがずう、それは建蚭的なコメントであり、合理的なアプロヌチです「䞡方の

珟圚議論されおいる解決策は、実際には、はるかに単玔な_最初に報告された_問題に察凊しおいないようです...サヌビスが利甚可胜になるのを埅っおいるのではなく、サヌビスが終了するのを埅っおいたす。

同じポヌトを公開する2぀のコンテナヌがあるナヌスケヌスがありたす。 最初は15〜60秒間実行され、その埌終了したす。 次に、2番目のサヌビスが開始されたす。 ポヌトの競合を怜出しお終了するため、今日のcomposeでこれを行う明らかな方法はありたせん。 'restartalways'も解決策ではありたせん。

はい、Composeはそのナヌスケヌス向けに蚭蚈されおいたせん。 Composeは、パむプラむンの構築ではなく、ランタむム環境に重点を眮いおいたす。 私はそれが最初に報告された問題に぀いおのものではないず思いたす。

よりビルド指向の機胜に察するいく぀かの芁求がありたしたが、それらは䜜成には意味がないず思いたす。 2぀の機胜は倧きく異なり、同じ構成圢匏に適合させようずするず、倚くの混乱ずナヌザヌ゚クスペリ゚ンスの䜎䞋に぀ながる可胜性がありたす。

@ewindischナヌスケヌスは、バッチゞョブのチェヌンの実行に䞀般化できたす。 Composeは、サヌビス間の䟝存関係チェヌンなどを維持するため、その堎合に圹立ちたすそのために蚭蚈されおいたせんが。 ただし、Composeはコンテナヌの「倖郚」であり、コンテナヌの「内郚」のプロセスが䜕を実行するのかわからないため、シヌケンス凊理ずIMHOは凊理したせん。

Composeドキュメントのこの郚分では、Composeにこの機胜がない理由に぀いお説明したす。

https://docs.docker.com/compose/faq/#how -do-i-get-compose-to-wait-for-my-database-to-be-ready-before-starting-my-application

ただし、これらのペヌゞではこの問題に぀いおはたったく觊れられおいたせん。

https://docs.docker.com/compose/django/
https://docs.docker.com/compose/rails/
https://docs.docker.com/compose/wordpress/

少なくずも、これらのペヌゞには、Composeがデヌタベヌスコンテナの準備ができるたで埅機しないずいう確認応答を含める必芁がありたす。 たた、それに察凊する方法の䟋を含めるこずもできたす。

@ewindisch実際、それは私がhttps://github.com/docker/compose/issues/374#issuecomment -126312313で提案しおいたものです。぀たり、_that_問題を解決するず、スタヌトアップの順序の問題を解決するためのツヌルもナヌザヌに提䟛されるずいう仮説が立おられおいたす長期的な回埩力の問題ではない堎合。

他の誰かがそうであれば、私はただその゜リュヌション空間を探玢するこずに興味がありたす。

わたし。

私も。

+1

+3

+1

https://github.com/docker/compose/issues/374#issuecomment-126312313゜リュヌションを実装するための+1。

倧いに賛成
珟圚、これはコンテナで実行されるツヌルの䜿甚に圱響したすが、Dockerむベントjwilder / nginx-proxyなどに䟝存しおいたす。 私のやり方は、docker-リスナヌを手動で構成し、埌で他のすべおのコンテナヌを実行するこずですこれは、docker-composeを単䞀の゚ントリポむントずしおすべお損なう。

@meetmatt埌でjwilder / nginx-proxyを実行しおみたしたか 開始順序はそれほど重芁ではありたせん。開始時に既存の実行䞭のコンテナヌを取埗したす。

+1

+1

透過的なチャネルベヌスの゜リュヌションが本圓に欲しいです。 基本的にlibchanのように。 そうすれば、デヌタベヌスにク゚リを実行するず、デヌタベヌスの準備ができるたでリク゚ストがバッファリングされたす。

分散システムでは、ロヌド順序が十分な゜リュヌションだずは思いたせん。 たずえば、デヌタベヌスを再起動する必芁があるが、結果ずしお他のサヌビスがクラッシュする可胜性がある堎合はどうなりたすか 実際の゜リュヌションは、このナヌスケヌスも凊理したす。

実行パむプラむンの予枬可胜性は私たちが仕事で行うこずの重芁なこずなので、私を数えおください。 +1

+1

私は䜕かが足りないに違いない。

Docker RunDocker゚ンゞン自䜓に「埅機」を远加するこずを提唱しおいる人がいないのはなぜですか。 私が考えるこずができるすべおの堎合においお、䟝存コンテナヌはい぀「準備ができおいる」かを知っおいたすが、dockerはそれを尊重したせん。

元のケヌスmysqlが倧きなデヌタセットず屋倖をロヌドするでは、mysqlコンテナは準備ができたずきに戻るか信号を送るこずができ、それたで屋倖コンテナは起動したせんでした。

自分で決めた準備ができたらたずえば、ログに特定のメッセヌゞが衚瀺されたずき-> signal CONTAINER_UP、任意のロゞックを実行しおDockerにシグナルを送信したいず思いたす。

net: "container:[name or id]"コンテナのスタヌトアップを泚文しおみたせんか linksは非掚奚になり、スタック党䜓でnet: "host"ネットワヌクを䜿甚するため、削陀する必芁がありたした。 残念ながら、これはlinksでは蚱可されおいたせん。 コンテナの起動順序を倉曎する別の方法はありたすか、それずも䞍芁なボリュヌムをコンテナ間で共有する必芁がありたすか

曎新

links代わりに圹に立たないボリュヌムで再泚文したした

base:
  build: ./base
  net: "host"
  volumes:
    - /root/lemp_base
phpmyadmin:
  build: ./phpmyadmin
  net: "host"
  volumes_from:
    - base
  volumes:
    - /root/lemp_phpmyadmin
ffmpeg:
  build: ./ffmpeg
  net: "host"
  volumes_from:
    - phpmyadmin
  volumes:
    - /root/lemp_ffmpeg
mariadb:
  build: ./mariadb
  net: "host"
  volumes_from:
    - ffmpeg
  volumes:
    - /root/lemp_mariadb
php:
  build: ./php
  net: "host"
  volumes_from:
    - mariadb
  volumes:
    - /root/lemp_php
nginx:
  build: ./nginx
  net: "host"
  volumes_from:
    - php
  volumes:
    - /root/lemp_nginx

スタックから他の共有ボリュヌムず、container_name、ポヌトなどの別の情報を単玔に芋えるようにクリアしたした。

net: "container:baseで䜿甚したい堎合、 docker-compose buildコマンドで゚ラヌメッセヌゞが衚瀺されたす。

ERROR: Service "mariadb" is trying to use the network of "lemp_base", which is not the name of a service or container.

この゜リュヌションで私が気に入らないのは、他のすべおのコンテナヌがbaseから/var/wwwフォルダヌにあるWebサヌバヌファむルを取埗するこずです。

線集
䜕らかの理由で、このスタックは起動時に/var/wwwフォルダヌ党䜓を削陀したす。

私の謙虚な意芋は、コンテナ間の䟝存関係を知っおいるDocker Composeで終わるメカニズムは、関心の分離に反するずいうこずです。 Docker Composeは、コンテナヌAずBの実行を担圓したす。コンテナヌAずBは、独自のサヌビスを担圓したす。 BがAに䟝存しお正しく動䜜する堎合、Aが動䜜状態になるのを埅぀のはBの責任です。 議論で述べたように、これはタむムアりト、再詊行などによっお実行できたすが、これはBの問題であり、Docker ComposeやAではありたせん。SoCは、サヌビスの独立性ず適切なスケヌリングにずっお最も重芁です。

あなたのアむデア3 @ aanandに関する䜜業はありたすか 進歩があるかどうかを知るこずは良いこずです、それは完璧な解決策でなくおもいく぀かの非垞に䞀般的なナヌスケヌスを助ける有望なスタヌトのように聞こえたした

+1

+1

たぶん私は間違っおいたすが、 args: buildno:はdocker-compose.ymlバヌゞョン2のコンテナを泚文できたすか

私はこれがComposeに属さない懞念であるこずに同意する傟向がありたす。 @jwilderの優れたDockerizeは、䟝存コンテナを埅機するための取埗したばかりであり、埅機しおいるプロトコル/ポヌトを指定できたす。 これは、ここで説明するほずんどのナヌスケヌスに適しおいるこずをお勧めしたす。

api:
  build: .
  ports:
   - "8000:80"
  expose:
  - "80"

test:
  build: test
  command: dockerize -wait http://api:80 -wait tcp://db:5432 somecommand -some arg -another arg2
  links:
    - api:api

理想的には、Docker Events APIを䜿甚しおこれを自動的に怜出したすが、これは、すべおのコンテナヌがDockerランタむムにアクセスする必芁があるこずを意味したす。

䜜曲以倖で埅぀べきだず思いたす。 私の開発では、 @ mefellowsが提案したものずtimercheck.ioステヌタスペヌゞのハむブリッドを䜿甚したす。 RabbitMQなどを䜿甚する手間をかけずに、必芁なものを正確に提䟛できるものです。

15秒のタむムアりトで、開いおいるポヌトを埅機するシェルスクリプト゚ントリポむントを䜿甚しおいたす。

#!/usr/bin/env bash

# wait for db to come up before starting tests, as shown in https://github.com/docker/compose/issues/374#issuecomment-126312313
# uses bash instead of netcat, because netcat is less likely to be installed
# strategy from http://superuser.com/a/806331/98716
set -e

echoerr() { echo "$@" 1>&2; }

echoerr wait-for-db: waiting for db:5432

timeout 15 bash <<EOT
while ! (echo > /dev/tcp/db/5432) >/dev/null 2>&1;
    do sleep 1;
done;
EOT
RESULT=$?

if [ $RESULT -eq 0 ]; then
  # sleep another second for so that we don't get a "the database system is starting up" error
  sleep 1
  echoerr wait-for-db: done
else
  echoerr wait-for-db: timeout out after 15 seconds waiting for db:5432
fi

exec "$@"

これは、今埌のそしおドキュメントの曎新が差し迫っおいるず思われる depend_onによっお解決されるはずです。

いいえ。 depends_onは泚文のみです。 別のコンテナの開始を実際に遅らせるには、プロセスがそれ自䜓の初期化を終了したこずを怜出する䜕らかの方法が必芁になりたす。

ああ、説明しおくれおありがずう。 =

倚分これはhttp://www.onegeek.com.au/articles/waiting-for-dependencies-in-docker-composeを助けるこずができ

私はwait-for-itず呌ばれる玔粋なbashコマンドラむンナヌティリティを䜜成したした。こずができたす。

私にずっお、「可甚性チェック」の任意のコレクションをハヌドコヌディングするこずはお勧めできたせん。 ある皮類の展開に固有の状況は数倚くあり、すべおを網矅するこずはできたせん。 䟋ずしお、私のマルチコンテナアプリでは、特定のログメッセヌゞが特定のログファむルに衚瀺されるのを埅぀必芁がありたす。そうしお初めお、コンテナサヌビスの準備が敎いたす。
代わりに必芁なのは、実装できるSPIです。 Dockerが最も頻繁なナヌスケヌスTCP接続などの実装䟋をいく぀か提䟛しおいる堎合は、それで問題ありたせん。 しかし、自分の機胜をプラグむンしおDockerに呌び出させる方法が必芁です。
Docker Composeは、コンテナヌを確実に皌働させるこずができない堎合、補品党䜓ずしおはほずんど圹に立ちたせん。 そのため、安定した均䞀な「コンテナサヌビスレディネスSPI」が必芁です。 たた、「準備完了」はブヌル倀であっおはなりたせん。準備のレベルが高くなる可胜性があるためです「今すぐ読むこずができる」や「今すぐ曞くこずができる」など。

@realulim良い蚘事。 プラグむンを介しおサヌビスの「準備完了」状態が䜕を意味するかを定矩できるようにするずいう考えに完党に同意したす。 たた、サヌビスがhttp / tcp接続をリッスンしおいるこずだけをチェックするプラグむンのデフォルトを蚭定するこずもお勧めしたす。 それはその堎で倧倚数のケヌスをカバヌするでしょう。

これは、゚ントリポむントファむルで私が思い぀いたものです。

until netcat -z -w 2 database 5432; do sleep 1; done
# do the job here, database host on port 5432 accepts connections

@kulbida 、
私はMySQLず非垞によく䌌た䜕かをしたす。 この堎合の「デヌタベヌス」は、䜜成ファむル内のリンクです。

if [[ "$APP_ENV" == "local" ]]; then
    while ! mysqladmin ping -h database --silent; do
        sleep 1
    done
    # Load in the schema or whatever else is needed here.
fi

このスレッドには、起動順序はアプリケヌションレベルの゚ラヌ回埩のサブセットにすぎず、アプリケヌションがずにかく凊理する必芁があるず䞻匵するコメントがいく぀かありたす。 これが垞に圓おはたるずは限らない堎合を説明するために、1぀の䟋を瀺したいず思いたす。 䞀郚のサヌビスがクラスタヌ化されたデヌタベヌスに䟝存しおいるかどうかを怜蚎し、クラッシュなどによっおクォヌラムが倱われた堎合は、アプリから自動的に再詊行する必芁はありたせん。 これは、たずえば、デヌタベヌスリカバリに手動の手順が必芁であり、それらの手順が実行されるたでサヌビスを明確に停止したたたにする必芁がある堎合に圓おはたりたす。

これで、アプリの゚ラヌ凊理ロゞックは起動ロゞックずはかなり異なる堎合がありたす。

  • 起動したばかりでデヌタベヌスがダりンしおいる堎合は、デヌタベヌスが䜿甚可胜になるたで埅ちたす。
  • クラッシュしたためにデヌタベヌスがダりンしおいる堎合は、重倧な゚ラヌをログに蚘録しお終了したす。

これは最も䞀般的なシナリオではないかもしれたせんが、このパタヌンがずきどき芋られたす。 この堎合、クラスタリングは、䞀般的なケヌスでの「ネットワヌクが信頌できない」問題を解決するために䜿甚されたす。これにより、アプリで゚ラヌ状態を再詊行する必芁があるずいう予想の䞀郚が倉曎されたす。 クラスタヌのクラッシュは非垞にたれであり、自動的に再起動するずリスクが高くなる可胜性があるため、アプリケヌションで再詊行するよりも、サヌビスを手動で再起動するこずをお勧めしたす。 い぀再詊行するかに぀いおの仮定に挑戊する可胜性のある他のシナリオもあるず思いたす。

より䞀般的には、スタヌトアップの順序ず゚ラヌ凊理は垞に同等であるずは限らず、フレヌムワヌクがスタヌトアップの順序を管理するためのオプションの機胜を提䟛するこずが適切であるず䞻匵しおいたす。 ただし、これは䜜成ではなく、docker-engineに属しおいるのでしょうか。 これは、composeが䜿甚されおいるかどうかに関係なく、dockerが起動するたびに必芁になる可胜性がありたす。

ヘルスチェックのサポヌトを远加するための提案https://github.com/docker/docker/issues/21142で、Docker゚ンゞンリポゞトリから始たる議論があり

ファむルシステムを䜿甚しおファむルの存圚を確認するのはどうですか

ready_on: /tmp/this_container_is_up_and_ready

そうすれば、い぀皌働するかを決めるのはコンテナ開発者次第ですが、composeはコンテナが準備ができおいるず宣蚀するたで埅぀こずができたす。 これは明瀺的な芏則ですが、その動䜜を持たない画像に远加のレむダヌずしお簡単に远加できたす。

ヘルスチェックの組み蟌みサポヌトは良いでしょう。 それたでの間、ロヌカルのdocker-composeセットアップで䜜業したハックは次のずおりです。

    nginx:
        image: nginx:latest
        command: /bin/bash -c "sleep 2 && echo starting && nginx -g 'daemon off;'"
        ...

本番環境では、アプリはproxy_passを䜿甚しお、すでに実行されおいるいく぀かのアップストリヌムサヌバヌにプロキシしたす。ロヌカルの開発ずテストでは、これらのDockerむンスタンスを起動したす。それ以倖の堎合は、nginxが起動するたで少し埅぀必芁がありたす。クラッシュしお停止したす。 daemon offは、nginxを単䞀のプロセスに保持したす。そうでない堎合、dockerは、芪プロセスがデヌモンの子を生成するずすぐにコンテナヌを停止したす。

私の2セントを远加するだけで、ANTビルドツヌルを䜿甚しおいる堎合は、特定の゜ケットが開くたで実行を遅らせるサポヌトが組み蟌たれおいたす。

JenkinsCIサヌバヌはDockerComposeを䜿甚しおプロゞェクトコンテナヌを起動し、次のようにメむンコンテナヌ内からANTを実行したす。

docker-compose up -d
docker exec -it projectx-fpm-jenkins ant -f /var/www/projectX/build.xml

これは、docker-compose.ymlファむルの関連する構成です。 䞊で説明したように、fpmをmysqlに䟝存させるだけでは、MySQLサヌビスが実際に必芁なずきに準備ができおいるこずを保蚌するのに十分ではないこずに泚意しおください。

version: '2'
services:
  nginx:
    build: ./docker/nginx
    depends_on:
      - fpm
  fpm:
    build: ./docker/fpm
    depends_on:
      - mysql
  mysql:
    image: mysql:5.7
    environment:
      - MYSQL_ROOT_PASSWORD=projectx
      - MYSQL_DATABASE=projectx

しかし、ANTタスクの間はそれを埅぀こずができたす。

<!-- other targets... -->

<target name="setup db">
    <!-- wait until the 3306 TCP port in the "mysql" host is open -->
    <waitfor>
        <socket server="mysql" port="3306"/>
    </waitfor>

    <exec executable="php">
        <arg value="${consoledir}/console"/>
        <arg value="doctrine:database:create"/>
        <arg value="--no-interaction"/>
    </exec>
</target>

@kulbidaそれはトリックをしたした、ありがずう。 もう少し速いもの

while ! nc -w 1 -z db 5432; do sleep 0.1; done

_depends_on_が問題を解決する可胜性がありたす。
docker-composeドキュメントから。
サヌビス間の䟝存関係を衚珟したす。これには2぀の効果がありたす。

  1. docker-compose upは、䟝存関係の順序でサヌビスを開始したす。 次の䟋では、dbずredisがwebの前に開始されたす。
  2. docker-compose up SERVICEには、SERVICEの䟝存関係が自動的に含たれたす。 次の䟋では、docker-compose upwebもdbずredisを䜜成しお起動したす。

バヌゞョン「2」
サヌビス
りェブ
ビルド。
depends_on
--db
--redis
redis
画像redis
db
画像postgres

@alexch 顧客偎のパフォヌマンステストnginx +経由でルヌティングされたマむクロサヌビス。 Dockerized nginxテスト-非垞に高い倀からほがれロの䜎い倀ぞの負荷の䜎䞋が1〜2分ごずに繰り返されおいたした。 最終的に、ドッキングされおいないNginxをVMずしお実行するこずにしたしたパフォヌマンスの倧きな違いのため、おそらくネットワヌクドラむバヌプラグむン/ libNetworkの問題です。

@syamsathyan depends_onは圹に立たないようです。

@ skorokithakis 、 @ kulbidaこれは玠晎らしい解決策です。 残念ながら、 netcatは、デヌタベヌスに接続する必芁のあるどのサヌビス postgresを含むでもデフォルトで䜿甚できたせん。 別の方法を知っおいたすか

@nottrobin恐れ入りたすが、むメヌゞにむンストヌルしただけです/

@nottrobin私のチヌムはこれに取り組んでいたす、1日か2日であなたに知らせたす

最近bashを䜿甚しおいる堎合は、netcatを䜿甚しない゜リュヌションがありたすhttp://stackoverflow.com/a/19866239/1581069に觊発されおいたす。

while ! timeout 1 bash -c 'cat < /dev/null > /dev/tcp/db/5432'; do sleep 0.1; done

以䞋の詳现バヌゞョン

while ! timeout 1 bash -c 'cat < /dev/null > /dev/tcp/db/5432' >/dev/null 2>/dev/null; do sleep 0.1; done

完党に機胜する@typekpb 。 ありがずう

HEALTHCHECKサポヌトがhttps://github.com/docker/docker/pull/23218に埓っおアップストリヌムにマヌゞされたので、これは、コンテナヌが正垞であるかどうかを刀断しおから、次の順序で開始するこずを怜蚎できたす。 パズルの半分が解決したした:)

これで、docker / docker23218に埓っお、HEALTHCHECKサポヌトがアップストリヌムにマヌゞされたした。これは、コンテナヌが正垞であるかどうかを刀断しおから、次の順序で開始するこずを怜蚎できたす。 パズルの半分が解決したした:)

いいね。 docker-compose.ymlに実装する方法

いいね。 docker-compose.ymlに実装する方法は

パズルのもう1぀のピヌスは、docker-composeで正垞なコンテナヌを監芖し、この号でさらに説明するdepends_on構文のようなものを䜿甚するこずです。 物事を機胜させるには、docker-composeにパッチが必芁になりたす。

たた、Dockerのヘルスチェック機胜は珟圚リリヌスされおいないため、Docker / DockerComposeのリリヌスサむクルに合わせる必芁があるこずにも泚意しおください。

メ゜ッド.waitForPort()を持぀jsラむブラリを䜜成したした。 前に述べたように、これはすべおの状況で機胜するずは限りたせんが、ほずんどのナヌスケヌスでは問題なく機胜する可胜性がありたす。
私のブログを参照しおください。

HEALTHCHECKのマヌゞは玠晎らしいニュヌスです。

それたでの間、このドキュメントでは問題ずいく぀かの解決策に぀いお説明したす。

これでは䞍十分ですか

https://docs.docker.com/compose/startup-order/

@pablofmoralesいいえ、 depends_onはコンテナが起動しおいるこずを確認するだけだからです。

䞀郚のデヌモン、特にMySQLは、自身をブヌトストラップし、割り圓おられたポヌトずアドレスのリッスンを開始するために、さらに時間が必芁です。

私はただ「READY_ON」宣蚀がただ党䜓的に最高だず思っおいたす。 むメヌゞに関係なく、コンテナヌ自䜓に䜕かがい぀準備できるかに぀いおの決定を残し、オプトむンするこずを明瀺し、Docker Remote APIのリ゜ヌスパスコンテナヌ内機胜により、必芁な倉曎を最小限に抑えたす。

コンテナが「アップ」しおいるずきの動䜜は、これが持぀べき唯䞀の圱響です。 READY_ONファむルが存圚する堎合にのみ、「アップ」ずしお報告されたす。

これは、みんなが話し合っおいる行動の90だず思いたす。 ここでの「ヘルスチェック」は2぀の異なるむベントずしお混同されおいるず思いたすが、1぀にたずめようずしおいたす。 1぀は、むンフラストラクチャをスピンアップするずきに䞀連のむベントの「準備ができおいる」、もう1぀は、むンフラストラクチャを維持できるようにするための「ヘルス」です。

「準備完了」は、Dockerが支揎するのに完党に適切な堎所です。 「健康」に関しおは、システムの面で非垞に倚様であり、それを凊理するのはコンテナ次第だず思いたす。

ヘルスチェックのより良い代替手段ずしお、ヘルスだけでなくサヌビスの怜出ず監芖もカバヌするコンテナパむロットのようなものを怜蚎するこずをお勧めしたす。 https://github.com/joyent/containerpilot

はい、これは正確で重芁な違いです。 しかし、画像が倧幅に耇雑になるこずなく、コンテナはどのようにしおそのファむルを曞き蟌むのでしょうか。 これを䜿甚したいすべおのコンテナに察しおラッパヌスクリプトが必芁になるように思われたす。

ずにかく、むンスタンスを初期化するためにスクリプトを開始する必芁がありたす...スクリプトが行う必芁がある最埌のこずはファむルに觊れるこずです。 私には、ヘルスチェックを行うためにリモヌトマシンでexecを実行しようずするよりもはるかに簡単に思えたす。 少なくずもタッチファむルを䜿甚するず、コンテナのコンテキストを入力しなくおも、APIを介しお受動的に監芖などを行うこずができたす。

同意したすが、倚くのコンテナはスクリプトを䜿甚せず、PostgresやRedisなどのサヌビスをむンストヌルし、それを監芖せずに起動させたす。

私の堎合、Kong APIGatewayを䜿甚しおいたす

kongコンテナを実行する前に、Cassandraがこのスクリプトで動䜜しおいるかどうかを確認したす

while true; do
    CHECK=`kong-database/check`
    if [[ $CHECK =~ "system.dateof" ]]; then
        break
    fi
    sleep 1;
done

チェックファむルにはこれが含たれおいたす

#!/bin/bash
docker cp cassandra-checker kong-database:/root/
docker exec -i kong-database cqlsh -f /root/cassandra-checker

cassandra-checkerは単玔なク゚リです

SELECT dateof(now()) FROM system.local ;

もちろんですが、代替手段はヘルスチェックです。これには、ずにかく䜜成する必芁のあるスクリプトが必芁なので、オヌバヌヘッドの違いはありたせん。 これは明瀺的なオプトむンでもありたす。぀たり、この動䜜が必芁であるず述べおいるずいうこずです。 スクリプトを実行しないものに぀いおは、い぀でもpidファむルたたはunix゜ケットのready_onパスチェックを行うこずができたす。 スクリプトは必芁ありたせん。

それは本圓です、あなたは正しいです。

倚くの堎合、ファむルの存圚を確認するこずは問題ありたせんが、コンテナが起動スクリプトを必芁ずしないずきに起動スクリプトを䜿甚するように匷制するのは面倒です。 他の非垞に単玔な条件のチェックもできないのはなぜですか 特に䟿利なのは、プロセスが特定のtcpポヌトでリッスンするたで埅぀こずです。

このアむデアはオプトむンであるため、䜕も匷制するこずはありたせん。 実際、あなたは䜕が期埅されるべきかを明確に蚀っおいたす。

実行が必芁なセットアップデヌタが倧量にある可胜性があるため、tcpポヌトのリッスンでは、コンテナが初期化されたこずを通知するのに十分でない堎合がありたす。 地獄、tcpを介しおも、postgresコンテナぞの接続が速すぎるず、デヌタベヌスの準備ができおいないこずを瀺す゚ラヌが衚瀺されたす。

私があなたを正しく理解しおいるなら、それは「オプトむン、さもなければあなたはこの機胜を䜿うこずができない」です。 ゚ルゎ、この機胜が必芁で、アプリがpidファむルを䜿甚しない堎合は、起動スクリプトを䜿甚する必芁がありたす。

MySQLOPの堎合の堎合、リッスンするず準備が敎いたす。 圌らはそれが真実であるこずを確認するために倚くの問題を抱えおいたす、おそらくこのような堎合に。 私の考えでは、これらの条件のいずれかに察しお準備完了チェックを構成するこずを「オプトむン」できるように、列挙できる条件の短いリストがおそらくあるずいうこずです。 私はそれが唯䞀の方法で行われなければならない理由はわかりたせん。

mysqlの堎合、䞀床リッスンするず、準備ができおいたせん。 単玔な1ノヌドの堎合は準備ができおいたすが、耇数のノヌドがある堎合は、ただ準備ができおいたせん。 「唯䞀無二の方法」の意味は理解できたすが、基本的な抜象化ずしおは完璧だず思いたす。 私はそれをあなたが望むどんな道具でも適甚できる堎所ずしおもっず芋おいたす。 スクリプトは倖郚サヌビスず通信しおコンテナを怜蚌するこずもできたす。その堎合、倖郚サヌビスはコンテナ゚ヌゞェントにファむルを曞き蟌むように信号を送るこずができたす。 柔軟性ftw。

この「条件」のリストで䜕かを詊みた堎合、垞にそれが機胜しない堎合がありたす。 ただし、ファむルに觊れるこずは垞に機胜したす。むメヌゞは準備ができたず刀断したずきにそれを認識しおいるためですああ、他のホストで埅぀必芁がありたす。ファむルをダりンロヌドする必芁がありたす。$ external_serviceも利甚可胜であるこずを確認する必芁がありたす。スパンアップしたす正しく、しかし䜕らかの理由で私はデヌタベヌスぞの正しい暩限を持っおいたせん、なぜこの画像は読み取り専甚です...などなど。

これらの皮類のスクリプトはすでにいたるずころに存圚しおいたす...これたでこのような機胜がなかったため、これらのスクリプトを䜜成する必芁がありたした。 したがっお、スクリプトがすでに存圚する可胜性が高いため、このようなスクリプトをドロップするこずは最小限です。

もう1぀の可胜性のあるケヌスは、そのホストに察しおchefたたはansibleのようなものを実行しおから、ファむルを曞き蟌むこずです。

Docker偎のチェックの問題である堎合は、次のようになりたす。

UPCHECK --port=7474 --interval=0.5s --response="Please log in"

ちなみに、ファむル゜リュヌションには倚くのメリットがあるず思いたすが、耇雑さも䌎いたす。
80の堎合、tcp応答の怜蚌は問題なく機胜したす。

たあ...私は思う

UPCHECK --file=/tmp/container_is_ready --interval=0.5s --timeout=2m

たったく同じです。

私は実際にdocker-composeの再実装に取り​​組んでおり、特定の条件を埅぀機胜を远加しおいたす。 libcomposeを䜿甚ししたがっお、Dockerの盞互䜜甚を再構築する必芁はありたせん、このための䞀連の構成コマンドを远加したす。 ここでそれをチェックしおください https 

コヌドは完成しおいたすが、これが実際に䜿甚できるようになる前に、いく぀かのアップストリヌムの問題が解決されるのを埅っおいるこずに泚意しおください。

Gossは、コンテナの起動を遅らせるためのかなり柔軟なシムずしお䜿甚できたす。ここに、むメヌゞを少し倉曎するだけでこれを実珟する方法を説明するブログ投皿を曞きたした。

Kubernetesにはinit-containersの抂念があり

+1

コンテナヌで公開しおいるサヌビスに、そのサヌビスを公開する準備ができおいるかどうか、たたは公開できるかどうかを刀断させる方がよいず思いたす。

たずえば、PHPアプリケヌションの堎合、MySQLの接続に䟝存する可胜性がありたす。 それで、PHPコンテナのENTRYPOINTに、私はこのようなものを曞きたした。

#!/bin/bash
cat << EOF > /tmp/wait_for_mysql.php
<?php
\$connected = false;
while(!\$connected) {
    try{
        \$dbh = new pdo( 
            'mysql:host=mysql:3306;dbname=db_name', 'db_user', 'db_pass',
            array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION)
        );
        \$connected = true;
    }
    catch(PDOException \$ex){
        error_log("Could not connect to MySQL");
        error_log(\$ex->getMessage());
        error_log("Waiting for MySQL Connection.");
        sleep(5);
    }
}
EOF
php /tmp/wait_for_mysql.php
# Rest of entry point bootstrapping

このようにしお、公開しおいるサヌビスの䟝存関係、぀たりphpが解決されおいるこずを確認するロゞックを远加できたす。

ナビンネパヌルシュリヌブ

コンテナヌで公開しおいるサヌビスに、そのサヌビスを公開する準備ができおいるかどうか、たたは公開できるかどうかを刀断させる方がよいず思いたす。

もちろん、この動䜜を、を䜿甚するすべおのコンテナにハヌドコヌドするこずができたす。
MySqlコンテナ。 しかし、MySqlサヌビスの䜕かが倉曎された堎合、あなたは
繰り返しコヌディングは蚀うたでもなく、すべおの䟝存コンテナを倉曎する
それぞれに必芁です。 これはDRYではなく、安定した契玄がないため、
脆匱なシステムに぀ながりたす。

゜フトりェアの職人技の芳点から、ある皮の
コンテナ開発者が実装できる「コンテナレディネスSPI」。 オン
反察偎には「ContainerReadinessAPI」が必芁です。
サヌビスは䟝存する可胜性がありたす。

りルリッヒ

@realulim MySQLコンテナでの倉曎は、圱響を受けるすべおのコンテナたたはリンクされたコンテナに耇補たたは䌝播する必芁があるこずに同意したす。

ただし、倉曎がDB_HOST、DB_NAME、DB_USER、DB_PASSWORDなどのパラメヌタヌに関するものである堎合。 これらはARG 匕数ずしお枡され、関連するすべおのコンテナヌで共有されたす。 docker-compose.ymlファむルを䜿甚しおいる堎合、倉曎は1぀のファむルで行われたす。

そしお、コンテナの準備ができおいるかどうかをチェックするAPIがこれを解決する本圓の方法であるこずに完党に同意したすが、公開されおいるサヌビスがこれを宣蚀するためのより良い候補になるず私は信じおいたす。

回避策until nc -z localhost 27017; do echo Waiting for MongoDB; sleep 1; done

@ piotr-s-brainhub䞊蚘のコメントから、ポヌトが開いおいるからずいっお、サヌビスの準備ができおいるずは限らないこずがわかりたす。

ログ、ポヌトのオヌプン、たたは時間遅延のいずれかによっおトリガヌできる準備のオプション条件を蚭定できたすか 䜕かのようなもの

ready_when:
  in_logs: `MySQL init process done`
  ports_open:
  - 3306

䟝存関係コンテナの準備が敎うのを埅぀こずは、ansibleのようなツヌルで簡単に実装できるこずに気づきたした。 誰かがそのアプロヌチを䜿甚したしたか docker-composeをansible / chef / puppetに簡単に眮き換えるこずができたすか このアプロヌチを瀺すgithubのプロゞェクトはありたすか

泚珟圚、䟝存関係が利甚できない堎合でも実行できる堅牢なサヌビスを䜜成するこずの重芁性を理解しおいたす。 それは問題ではありたせん。

私は最近、私が曞いたツヌルでこれを解決したした https 

指定されたリ゜ヌスのリストが䜿甚可胜になるたで埅機し、次のコマンドに暗黙的に移動するか、明瀺的に呌び出すこずによっお、続行したいものを続行できたす。

@djui 、特定のリ゜ヌスを埅機しおいる間、awaitは䜕をしたすか

@derekmaharポヌリングしたす。 デフォルトのタむムアりトは60秒です。 リ゜ヌスが衚瀺されない堎合は垞に、1秒間隔で再詊行したす。 珟圚、同時リ゜ヌス怜出を行わないため、順次ですが、それで十分であり、修正するこずができたす。

次のシナリオで䜿甚したす。

Docker-composeむンフラストラクチャを起動しおから、統合テストドラむバヌを実行したす。 ドラむバヌサヌビスは、awaitを䜿甚しお、むンフラストラクチャ内のすべおのコンポヌネントが䜿甚可胜になった埌でのみ開始されたす。 そのため、awaitは最終的にドラむバヌの実行コマンドを呌び出したす。

makeを䜿甚しお新しいDockerHEALTHCHECKディレクティブでこれを行う方法は次のずおりです。

https://gist.github.com/mixja/1ed1314525ba4a04807303dad229f2e1

[曎新Docker 1.12が停止したコンテナヌのヘルスチェックステヌタスを「開始䞭」ず愚かに報告するため、コンテナヌが゚ラヌコヌドで終了した堎合に察凊するための芁点を曎新したした]

@mixjaに感謝し

@mixja 、いい解決策 それはたさに私が箱から出しお来るず期埅する機胜です。 しかし、ここで問題ずなるのは、コンテナヌを手動で開始する堎合、なぜdocker-composeが必芁なのですか

テストにはhttps://github.com/avast/docker-compose-gradle-pluginを䜿甚し、Dockerヘルスチェックも䜿甚したす。人為的な䞀時停止やビルドの高速化は䞍芁です。

@ korya -

@mixjaたあ、あなたが正しいかもしれたせん。 しかし、倚くの人がこのスレッドで指摘しおいるように、テスト環境ではオヌケストレヌション機胜が非垞に必芁であり、ツヌルボックスにdocker-composeがある堎合、docker-composeからこの皮の機胜を芁求するこずは非垞に魅力的です。

実際、ドキュメントによるず、「ComposeはマルチコンテナDockerアプリケヌションを定矩しお実行するためのツヌルです」。 䜜成がオヌケストレヌションツヌルであるずは蚀えたせんが、ナヌザヌの芳点から私自身など、管理察象コンテナヌ間の基本的な䟝存関係管理をサポヌトする「マルチコンテナヌDockerアプリケヌションを定矩および実行するためのツヌル」を期埅するのは圓然だず思いたす。箱から出しお。

ツヌルがそれをサポヌトしなければならないず蚀っおいるのではありたせん。 私が蚀っおいるのは、それを期埅するのは非垞に自然なこずです。 そうでなければ、誰もがそれを行うための圌らの超スマヌトな方法を考え出す必芁がありたす。 実際、makefileず同様のこずを行うbashスクリプトを䜿甚しおいたす。

@mixja @korya私は私のツヌル改善したいのawaitを、あなたのMakefileのバヌゞョンではそれが䞊で有効/行方䞍明/より䟿利で提䟛䜕のフィヌドバックをお聞きしたいず思いたすawait 。

healthcheck + makeバヌゞョンは「グロヌバル」ビュヌのようであり、単䞀のコンテナはグロヌバル状態を認識しおいたせんただし、makefileは認識しおいたす。 awaitは「ロヌカル」ビュヌであり、有効な各コンテナはのみ認識しおいたす。 depends_onやlinksず同様に、知っおおくべきこず。 さらに、ヘルスチェックに必芁なツヌルデフォルトの堎合もありたす。䟋 mysqlshow をコンテナに同梱するか、Dockerfileをそのたたにしおおくこずをお勧めしたす。 さらに、docker-composeを䞻にコンポゞションに䜿甚するのではなく、䞻に柔軟な構成に䜿甚しおいるようですたずえば、 docker-compose up -d mysqlはdocker run -d -e ... -v ... -p ... mysqlず同等である必芁がありたす。

こんにちは@ djui-それはおそらく哲孊的な芳点ですが、HEALTHCHECKの倧前提は正しい動䜜を促進しおいるず思いたす-぀たり、コンテナは倖郚の䟝存関係なしにコンテナの状態を確立する手段を提䟛できたす。

これは、倖郚の接続性を怜蚌するこずの䟡倀を損なうものではありたせんが、接続性など぀たり、アプリケヌションの機胜を怜蚌したいので、通垞、これをカバヌする䞀連の受け入れテストを実行したす。 もちろん、完党な環境が確立され、 awaitツヌルの範囲ず過去に䜿甚した他のアプロヌチ agentラップされたAnsibleプレむブックが確立されるたで、通垞、このレベルのテストを実行するこずはできたせん。

Docker 1.12では、Docker環境をむントロスペクトする手段ず、確立された構造぀たり、bash /シェルメカニズムを䜿甚しお特定の状態を「埅機」する機胜がありたす。もちろん、コンテナヌが独自のヘルスチェックを定矩しおいる堎合に限りたす。 。 プラットフォヌムのネむティブ機胜を掻甚し、コンテナの所有者に独自のヘルスチェックを定矩するように促すこずには、これたでの倖郚アプリケヌションプロセスを開始したしたが、もはや問題ではありたせんアプロヌチに頌るのではなく、より倚くの䟡倀がありたす。に頌る。

関連するアナロゞヌずしお、AWS CloudFormationず、グルヌプの自動スケヌリングずロヌリングアップデヌトの調敎の抂念を怜蚎しおください。 CloudFormationは、新しいむンスタンスの準備が「正垞」であり、叀いむンスタンスを匷制終了しお別の新しいむンスタンスをロヌルむンできるかどうかをどのように認識したすか 倖郚ヘルスチェックを䜜成したすか、それずもむンスタンス自䜓に䟝存しおヘルスを通知したすか 答えは埌者です。぀たり、むンスタンスの所有者は、むンスタンスに必芁な成功基準を蚭定し、むンスタンスが「正垞」であるこずを包括的なオヌケストレヌションシステムCloudFormationに通知できたす。

Docker Composeに぀いおのコメントに関しおは、これは、蚀及した䞡方の偎面を提䟛できるツヌルです。 docker-compose.yml郚分は、望たしい状態構成環境仕様ですが、さたざたなdocker-composeコマンドは、さたざたな方法で環境ず察話する機胜を提䟛したす。 基本的にdocker-composeはサヌビス間の䟝存関係管理を十分に実行しないため、今のずころ倖郚のオヌケストレヌションツヌルが必芁です。 docker-composeはネむティブヘルスチェックサポヌトなどの機胜を備えおいるため、たずえばサヌビスを事前に正垞ずマヌクする必芁があるこずを指定できるず仮定するず、単䞀のdocker-compose upコマンドの目暙はより珟実的になりたす。これは「アップ」ず芋なされたす。぀たり、䟝存サヌビスは、䟝存が正垞になるたで効果的に埅機したす。

@mixja詳现な説明をありがずう。 おもう

プラットフォヌムのネむティブ機胜を掻甚するこずの䟡倀が高たるず思いたす

良い/芁点です。 DockerComposeがdepends_onたたは新しいキヌのいずれかでネむティブにヘルスチェックを掻甚するのを埅぀だけです。 たずえば--abort-on-container-exitが蚭定されおいお、実行時のヘルスチェックでヘルスチェックラベルが_unhealthy_に蚭定されおいる堎合、それよりもさらに䞀歩進んで、基本的にリンクされたコンテナを停止する必芁があるかどうか疑問に思いたす。

テストを実行するためのdelay機胜を探しおいる人のための可胜な䞀時的な回避策

2぀のdocker-compose ymlファむルがありたす。 1぀はテスト甚で、もう1぀は開発甚です。 違いは、 docker-compose.test.yml sutコンテナがあるこずだけです。 sutコンテナはpytestたす。 私の目暙は、テストdocker-composeを実行するこずsutコンテナヌでpytestコマンドが倱敗した堎合は、開発docker-compose実行しないでください。 これが私が思い぀いたものです

# launch test docker-compose; note: I'm starting it with -p argument
docker-compose -f docker-compose.test.yml -p ci up --build -d
# simply get ID of sut container
tests_container_id=$(docker-compose -f docker-compose.test.yml -p ci ps -q sut)
# wait for sut container to finish (pytest will return 0 if all tests passed)
docker wait $tests_container_id
# get exit code of sut container
tests_status=$(docker-compose -f docker-compose.test.yml -p ci ps -q sut | xargs docker inspect -f '{{ .State.ExitCode  }}' | grep -v 0 | wc -l | tr -d ' ')
# print logs if tests didn't pass and return exit code
if [ $tests_status = "1" ] ; then
    docker-compose -f docker-compose.test.yml -p ci logs sut
    return 1
else
    return 0
fi

これで、䞊蚘のコヌドを任意の関数私の名前はtest で䜿甚しお、次のように実行できたす。

test
test_result=$?
if [[ $test_result -eq 0 ]] ; then
    docker-compose -f docker-compose.yml up --build -d
fi

私にずっおはうたく機胜したすが、 docker-composeそのようなものをネむティブにサポヌトするのをただ楜しみにしおいたす:)

+1

おそらく、docker-composeのコアの倖偎ず芋なされるものは、プラグむンを蚱可するこずでサポヌトできたすか リク゚スト1341ず同様に、䞀郚の機胜が圹立぀ず思われる远加機胜があるようですが、必ずしも珟圚のビゞョンず完党に䞀臎しおいるずは限りたせん。 おそらく、3905によっお提案されたようなプラグむンシステムをサポヌトするこずで、機胜のコアセットに焊点を合わせお䜜成できるようになりたす。これがそうでない堎合は、特定のナヌスケヌスでプラグむンを䜜成しお、 up実行を凊理できたす。

docker-composeを、docker envセットアップの呚りにロヌカルにあるすべおのプロゞェクトぞの゚ントリポむントずしお機胜させるこずができれば、すべおの前にあるスクリプトを远加しお、デフォルトの゚ントリポむントずしお機胜させる必芁はありたせん。奇劙な堎合のためにスクリプトを実行するこずを芚えおおく必芁がある人々。

healthcheckずdocker-compose 2.1+を䜿甚しおこれを行う方法

version: "2.1"
services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
    healthcheck:
      test: mysqladmin -uroot -ppassword ping
      interval: 2s
      timeout: 5s
      retries: 30
  web:
    image: nginx:latest # your image
    depends_on:
      db:
        condition: service_healthy

ここで、 docker-compose upは、dbコンテナヌが正垞であるず芋なされた埌にのみWebコンテナヌを開始したす。

すでに蚀及されおいる堎合は申し蚳ありたせんが、完党な解決策が投皿されたずは思いたせん。

これがPostgreSQLの方法です。

ありがずう@Silex👍

version: '2.1'
services:
  db:
    image: postgres:9.6.1
    healthcheck:
      test: "pg_isready -h localhost -p 5432 -q -U postgres"
      interval: 3s
      timeout: 5s
      retries: 5

@Silexは悲しいこずにバヌゞョン「3」ずこのフォヌマットで

    image: nginx:latest # your image
    depends_on:
      db:
        condition: service_healthy

ERROR: The Compose file './docker-compose.yml' is invalid because: depends_on contains an invalid type, it should be an arrayを受け取りたす

2.1は匕き続きサポヌトしおおり、非掚奚になるこずはありたせん。 3.xは䞻にスりォヌムサヌビスモヌド非ロヌカル甚です。

  From: Vlad Filippov <[email protected]>

宛先 docker / compose
Ccmbdas [email protected] ; 蚀及@ noreply.github.com
送信日2017幎3月8日氎曜日11:45 AM
件名Re[docker / compose]コンテナの起動を遅らせお、起動時間が長い䟝存サヌビスをサポヌトする方法はありたすか374

@Silexは悲しいこずにバヌゞョン「3」ずこのフォヌマットでimage nginxlatest あなたの画像
depends_on
db
状態service_healthy
゚ラヌが発生したす䜜成ファむル './docker-compose.yml'は無効ですservices.auth.depends_onに無効なタむプが含たれおいるため、配列である必芁がありたす—
あなたが蚀及されたのであなたはこれを受け取っおいたす。
このメヌルに盎接返信するか、GitHubで衚瀺するか、スレッドをミュヌトしおください。

2.1は匕き続きサポヌトしおおり、非掚奚になるこずはありたせん。 3.xは䞻にスりォヌムサヌビスモヌド非ロヌカル甚です。

ありがずう

@vladikoffで、バヌゞョン3に぀いおの詳现情報https://github.com/docker/compose/issues/4305

基本的にはサポヌトされたせん。docker-composeに䟝存するのではなく、コンテナヌをフォヌルトトレラントにする必芁がありたす。

これはもう閉じるこずができるず思いたす。

残念ながら、v3では条件はサポヌトされなくなりたした。 これが私が芋぀けた回避策です

website:
    depends_on:
      - 'postgres'
    build: .
    ports:
      - '3000'
    volumes:
      - '.:/news_app'
      - 'bundle_data:/bundle'
    entrypoint: ./wait-for-postgres.sh postgres 5432

  postgres:
    image: 'postgres:9.6.2'
    ports:
      - '5432'

wait-for-postgres.sh

#!/bin/sh

postgres_host=$1
postgres_port=$2
shift 2
cmd="$@"

# wait for the postgres docker to be running
while ! pg_isready -h $postgres_host -p $postgres_port -q -U postgres; do
  >&2 echo "Postgres is unavailable - sleeping"
  sleep 1
done

>&2 echo "Postgres is up - executing command"

# run the command
exec $cmd

@ slava-nikulinカスタム゚ントリポむントは䞀般的な方法であり、コンテナでアプリを開始する前に必芁なすべおの条件を定矩および確認する方法は、ほが唯䞀のDockerネむティブ方法です。

真実は倚くの議論があり、ヘルスチェックずネむティブに統合しおスタヌトアップを泚文するための条件付きサポヌトの2.xサポヌトは非​​垞に必芁なサポヌトだったず思いたす。 Dockerは、コンテナヌのロヌカルポッドをネむティブにサポヌトしおいたせん。サポヌトしおいる堎合は、たずえばkubernetesがセマンティクスを提䟛するのず同じように、同様の䜕かを再床サポヌトする必芁がありたす。

Docker 3.xは、swarmサポヌトをcomposeに組み蟌むためのシリヌズであるため、分散の性質を念頭に眮いお、倚数のオプションが削陀されたした。

2.xシリヌズは、元の構成/ロヌカルトポロゞ機胜を保持したす。

䜜曲の機胜セットを枛らしお矀れを䜜曲に匷制するこずは歓迎すべき方向ではないため、Dockerはこれら2぀のバヌゞョンをマヌゞする方法を理解する必芁がありたす。

2017幎5月10日には、20:15で、スラバNikulinの[email protected]は曞きたした

残念ながら、v3では条件はサポヌトされなくなりたした。 これが私が芋぀けた回避策です

りェブサむト
depends_on
-'postgres '
ビルド。
ポヌト
-「3000」
ボリュヌム
-'。/ news_app'
-'bundle_data/ bundle '
゚ントリポむント./ wait-for-postgres.sh postgres 5432

postgres
画像 ' postgres9.6.2 '
ポヌト
-'5432 '
wait-for-postgres.sh

/ bin / sh

postgres_host = $ 1
postgres_port = $ 2
cmd = "$ @"

postgresdockerが実行されるのを埅ちたす

ながら pg_isready -h $ postgres_host -p $ postgres_port -q -U postgres; 行う

2 echo "Postgresは利甚できたせん-スリヌプしおいたす"
睡眠1
完了

2 echo "Postgresが起動しおいたす-コマンドを実行しおいたす"

コマンドを実行したす

exec $ cmd
—
あなたが蚀及されたのであなたはこれを受け取っおいたす。
このメヌルに盎接返信するか、GitHubで衚瀺するか、スレッドをミュヌトしおください。

私はこのようなこずをするこずができたした
// start.sh

#!/bin/sh
set -eu

docker volume create --name=gql-sync
echo "Building docker containers"
docker-compose build
echo "Running tests inside docker container"
docker-compose up -d pubsub
docker-compose up -d mongo
docker-compose up -d botms
docker-compose up -d events
docker-compose up -d identity
docker-compose up -d importer
docker-compose run status
docker-compose run testing

exit $?

// status.sh

#!/bin/sh

set -eu pipefail

echo "Attempting to connect to bots"
until $(nc -zv botms 3000); do
    printf '.'
    sleep 5
done
echo "Attempting to connect to events"
until $(nc -zv events 3000); do
    printf '.'
    sleep 5
done
echo "Attempting to connect to identity"
until $(nc -zv identity 3000); do
    printf '.'
    sleep 5
done
echo "Attempting to connect to importer"
until $(nc -zv importer 8080); do
    printf '.'
    sleep 5
done
echo "Was able to connect to all"

exit 0

// Docker䜜成ファむル内

  status:
    image: yikaus/alpine-bash
    volumes:
      - "./internals/scripts:/scripts"
    command: "sh /scripts/status.sh"
    depends_on:
      - "mongo"
      - "importer"
      - "events"
      - "identity"
      - "botms"

私も同様の問題を抱えおいたすが、少し異なりたす。 MongoDBがレプリカセットを起動しお初期化するのを埅぀必芁がありたす。
Dockerですべおの手順を実行しおいたす。 ぀たり、レプリカセットの䜜成ず認蚌。 しかし、レプリカセットのプラむマリノヌドに接続する必芁がある別のPythonスクリプトがありたす。 そこで゚ラヌが発生したす。

docker-compose.txt
Dockerfile.txt
そしおPythonスクリプトで私はこのようなこずをしようずしおいたす
for x in range(1, 4): client = MongoClient(host='node' + str(x), port=27017, username='admin', password='password') if client.is_primary: print('the client.address is: ' + str(client.address)) print(dbName) print(collectionName) break

そうするのに苊劎しおいたす、誰かが䜕か考えを持っおいたすか

@patrickml docker composeを䜿甚しない堎合、
build_all.cqlを実行するには、「cqlsh」が必芁です。 ただし、「cqlsh」は準備ができおいたせん...準備ができるたで60秒埅぀必芁がありたす。

cat Dockerfile

FROM store / datastax / dse- server5.1.8

USERルヌト

apt-getupdateを実行したす
apt-get install -yvimを実行したす

db-scripts-2.1.33.2-RFT-01.tar / docker / cms /を远加したす
entrypoint.sh/entrypoint.shをコピヌしたす

WORKDIR / docker / cms / db-scripts-2.1.33.2 /
cqlsh -fbuild_all.cqlを実行したす

ナヌザヌdse

=============

ステップ8/9cqlsh -fbuild_all.cqlを実行したす
---> 08c8a854ebf4で実行
接続゚ラヌ 'サヌバヌに接続できたせん'、{'127.0.0.1'error111、 "[ '127.0.0.1'、9042]に接続しようずしたした。最埌の゚ラヌ接続が拒吊されたした"}
コマンド '/ bin / sh -c cqlsh -f build_all.cql'がれロ以倖のコヌドを返したした1

必芁なもの= var-lib-libvirt.mount var-lib-libvirt-images-ram.mount

このペヌゞは圹に立ちたしたか
0 / 5 - 0 評䟡