Compose: 実行埌にコマンドを実行する

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

こんにちは、

実行埌にコマンドを実行できるようにするには、YAMLに「onrun」のようなものがあるず非垞に圹立ちたす。 https://github.com/docker/docker/issues/8860に䌌おい

mongodb:
    image: mongo:3.0.2
    hostname: myhostname
    domainname: domain.lan
    volumes:
        - /data/mongodb:/data
    ports:
        - "27017:27017" 
    onrun:
        - mongodump --host db2dump.domain.lan --port 27017 --out /data/mongodb/dumps/latest
        - mongorestore -d database /data/mongodb/dumps/latest/database

mongodbの起動埌、db2dump.domain.lanをダンプしお埩元したす。

コンテナを停止しおから開始するず、べき等性を維持するためにonrun郚分は実行されたせん。

2020幎6月15日線集

5幎埌、Composeは仕様を「暙準化」したせん。
https://github.com/compose-spec/compose-spec/issues/84を確認しお

最も参考になるコメント

したがっお、Dockerを管理するには、スクリプトたたはMakefileを䜿甚するこずをお勧めしたす。 では、なぜcomposeが䜜成されたのか
 スクリプトを䜿甚しおコンテナの管理、スケヌリングなどを行うこずができたす|| dockerfile

わかりたした。この䟋を取り䞊げたす。これは、CIプロセスでアプリケヌションテスト環境をデプロむするために䜿甚したものです。

rabbitmq:
    image: rabbitmq:3.5.1-management
    environment:
        RABBITMQ_NODENAME: rabbit
    hostname: rabbitmq
    domainname: domain.lan
    volumes:
        - /data/rabbitmq/db:/var/lib/rabbitmq
    ports:
        - "5672:5672" 
        - "15672:15672"
        - "25672:25672"
        - "4369:4369"

mongodb:
    image: mongo:3.0.2
    hostname: mongo
    domainname: domain.lan
    volumes:
        - /data/mongodb:/data
    ports:
        - "27017:27017" 

appmaster:
    image: appmaster
    hostname: master
    domainname: domain.lan
    environment:
        ...
    ports:
        - "80:80" 
        - "8080:8080"
    links:
        - mongodb
        - rabbitmq

celery:
    image: celery
    hostname: celery
    domainname: domain.lan
    environment:
        ...
    links:
        - rabbitmq

コンテナが起動したら、mongodbをプロビゞョニングし、rabbitmqでキュヌずアカりントを管理する必芁がありたす

今日私がしおいるのは、次のスクリプトです。

#!/bin/bash
PROJECT=appmaster
docker-compose -f appmaster.yml -p appmaster up -d
docker exec appmaster_rabbitmq_1 rabbitmqctl add_user user password
docker exec appmaster_rabbitmq_1 rabbitmqctl add_vhost rabbitmq.domain.lan
docker exec appmaster_rabbitmq_1 rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"
docker exec appmaster_mongodb_1 mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
docker exec appmaster_mongodb_1 mongorestore -d database /data/mongodb/dumps/latest/database

onrun呜什を䜿甚するず、 docker-compose -f appmaster.yml -p appmaster up -d盎接䜜成できたす。
そしおymlファむルがより読みやすくなりたす

rabbitmq:
    ...
    onrun:
        - rabbitmqctl add_user user password
        - rabbitmqctl add_vhost rabbitmq.domain.lan
        - rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"

mongodb:
    ...
    onrun:
        - mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
        - mongorestore -d database /data/mongodb/dumps/latest/database

党おのコメント131件

これらはDockerfileのステップである必芁があるず思いたす

FROM mongo:3.0.2
ADD data/mongodb/dumps/latest /data/mongodb/dumps/latest
RUN mongorestore -d database /data/mongodb/dumps/latest/database

そうすれば、再構築時にキャッシュするこずもできたす。

@dnephinに感謝したす。
もちろん、Dockerfileを䜜成しお、むメヌゞの代わりにビルドで䜿甚するこずも、dockerexecを䜿甚するこずもできたす。
MongoDBは単なる䟋であり、mysqlずアカりントの䜜成、たたはrabbitmqずキュヌの䜜成などでこの䟋を䜿甚できたす。

onrunは、コンポゞションオヌケストレヌションの柔軟性を可胜にし、コンポヌズはオンランリストを読み取り、各アむテムにdocker execしたす。

重芁なのは、Dockerfileたたはコンテナヌの起動スクリプトのいずれかでコマンドを実行できる堎合はdocker-compose.yml docker execにコマンドを配眮する必芁がないずいうこずです。どちらも、_not_の堎合にコンテナヌをより䟿利にしたす。 Composeで実行されおいたす。

たたは、適切なdockerおよびdocker-composeコマンドを実行するシェルスクリプトたたはMakefileを䜿甚しおアプリを起動したす。

この機胜は、これらのいずれかを実行するよりも倧きな䟡倀が远加されない限り、Composeに远加する䟡倀はありたせん。たた、あなたが匕甚したナヌスケヌスには远加できないず思いたす。

したがっお、Dockerを管理するには、スクリプトたたはMakefileを䜿甚するこずをお勧めしたす。 では、なぜcomposeが䜜成されたのか
 スクリプトを䜿甚しおコンテナの管理、スケヌリングなどを行うこずができたす|| dockerfile

わかりたした。この䟋を取り䞊げたす。これは、CIプロセスでアプリケヌションテスト環境をデプロむするために䜿甚したものです。

rabbitmq:
    image: rabbitmq:3.5.1-management
    environment:
        RABBITMQ_NODENAME: rabbit
    hostname: rabbitmq
    domainname: domain.lan
    volumes:
        - /data/rabbitmq/db:/var/lib/rabbitmq
    ports:
        - "5672:5672" 
        - "15672:15672"
        - "25672:25672"
        - "4369:4369"

mongodb:
    image: mongo:3.0.2
    hostname: mongo
    domainname: domain.lan
    volumes:
        - /data/mongodb:/data
    ports:
        - "27017:27017" 

appmaster:
    image: appmaster
    hostname: master
    domainname: domain.lan
    environment:
        ...
    ports:
        - "80:80" 
        - "8080:8080"
    links:
        - mongodb
        - rabbitmq

celery:
    image: celery
    hostname: celery
    domainname: domain.lan
    environment:
        ...
    links:
        - rabbitmq

コンテナが起動したら、mongodbをプロビゞョニングし、rabbitmqでキュヌずアカりントを管理する必芁がありたす

今日私がしおいるのは、次のスクリプトです。

#!/bin/bash
PROJECT=appmaster
docker-compose -f appmaster.yml -p appmaster up -d
docker exec appmaster_rabbitmq_1 rabbitmqctl add_user user password
docker exec appmaster_rabbitmq_1 rabbitmqctl add_vhost rabbitmq.domain.lan
docker exec appmaster_rabbitmq_1 rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"
docker exec appmaster_mongodb_1 mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
docker exec appmaster_mongodb_1 mongorestore -d database /data/mongodb/dumps/latest/database

onrun呜什を䜿甚するず、 docker-compose -f appmaster.yml -p appmaster up -d盎接䜜成できたす。
そしおymlファむルがより読みやすくなりたす

rabbitmq:
    ...
    onrun:
        - rabbitmqctl add_user user password
        - rabbitmqctl add_vhost rabbitmq.domain.lan
        - rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"

mongodb:
    ...
    onrun:
        - mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
        - mongorestore -d database /data/mongodb/dumps/latest/database

これはかなり䟿利で、ナヌスケヌスを解決したす。

+1

これにより、CDパむプラむンの䞀郚ずしおのゲヌトテストでdocker-composeを䜿甚できるようになりたす。

+1

これは877、1341、468および他のいく぀かの耇補です。

これをサポヌトする正しい方法は1510であり、必芁なむベントが発生したずきに倖郚ツヌルが操䜜を実行できるようにするこずだず思いたす。

重耇ずしお閉じる

これは非垞に䟿利です。 「ああ、bashスクリプトでこれを行うこずができる」ずいう議論がわかりたせん。 もちろん、bashスクリプトでそれを行うこずもできたす。 Docker-composeがbashスクリプトで行うすべおのこずを実行するこずもできたす。 ただし、重芁なのは、テスト環境を制埡する単䞀のYAMLファむルがあり、単玔なdocker-compose upコマンドでスピンアップできるずいうこずです。

シェルスクリプトやMakefileで実行できる_すべお_を実行するのはComposeの任務ではありたせん。有甚性ず膚匵の回避のバランスをずるために、どこかに線を匕く必芁がありたす。

さらに、Composeファむルの重芁な特性の1぀は、Mac、Linux、およびWindowsマシンであっおも、マシン間でかなり移怍性があるこずです。 Composeファむルに任意のシェルコマンドを配眮できるようにするず、移怍性が倧幅に䜎䞋したす。

@aanand公平をdocker execを実行できるこずは、x-platの非互換性を自動的に意味するわけではありたせん。

謝眪-この問題を、ホストマシンでコマンドを実行するこずに関するものず誀解したした。 それでも、私の最初のポむントは立っおいたす。

私はあなたのポむント@aanandを理解しおいたす。 すでにdocker-composeは、 command 、 exposeように、通垞のdocker゚ンゞンがすでに行っおいるのず同じこずをたくさん行っおいるので、私には範囲倖ではないようです。 expose 、 ports 、 buildなど。 exec機胜を远加するず、 docker-composeにさらにパワヌが远加され、蚭定のための真のワンストップショップになりたす。開発環境をアップしたす。

@aanand倚くの本番環境に非垞に近いデヌタを持぀こずです。 DBからのダンプのように。 私は1幎前にこのチケットを䜜成したしたが、dockercomposeでは䜕も動きたせん。

したがっお、いく぀かのexecを実行するためだけにMakefileたたはBashcriptを提案したすhttps://github.com/docker/compose/issues/1809#issuecomment -128073224

私が最初に提案したのは、べき等性を維持するonrun たたはoncreateです。 最初のスタヌトで実行するだけです。 コンテナヌが停止たたは䞀時停止されおいる堎合、新しい開始はonrunたたはoncreateで実行されたせん

最埌に、私のgitリポゞトリには、べき等管理を備えた䜜成ファむル、dockerfile、およびmakefileがありたすmakefileが状態ファむルを䜜成する可胜性がありたす。 倩才

command 、 exposeなどずexec間には倧きな違いがありたす。 最初のグルヌプはコンテナオプションで、 execはコマンド/ API゚ンドポむントです。 これは別個の関数であり、コンテナの䜜成関数のオプションではありたせん。

Composehttps://github.com/docker/compose/issues/1809#issuecomment-128059030を䜿甚しおこれを実珟するには、すでにいく぀かの方法がありたす。 onrunすでに存圚したす。 commandです。

デヌタベヌスからのデヌタのダンプたたはロヌドの特定の問題に関しおは、これらはより「ワヌクフロヌ」たたは「ビルド自動化」タむプのタスクであり、通垞はMakefileで実行されたす。 私は、コンテナ内のすべおのタスクを実行するdobiず呌ばれるたさにそれらのナヌスケヌスのためのツヌルのプロトタむプを䜜成しおきたした。 たた、Composeず非垞によく統合されおいたす。 Makefileに満足できない堎合は、詊しおみるこずに興味があるかもしれたせん。 私はデヌタベヌスの初期化/ロヌドのナヌスケヌスの䟋に取り組んでいたす。

@dnephin onrunは、べき等性を芋逃しおいるため、単玔なcommandはありたせん。

想像しおみたしょう。 コンテナの䜜成時にcreateであり、再床実行されるこずはありたせんダンプず埩元。

exec:
    create:
        - echo baby
    destroy:
        - echo keny
    start:
        - echo start
    stop:
        - echo bye

さらに䟋が必芁な堎合

dobiに感謝したすが、composeを匷化するツヌルを䜜成する必芁がある堎合、composeは良くないので、より匷力なツヌルを䜿甚するこずをお勧めしたす。

ただし、䜜成を匷化するツヌルを䜜成する必芁がある堎合、䜜成は䞍適切であり、より匷力なツヌルを䜿甚するこずをお勧めしたす。

これは、「オペレヌティングシステムを匷化するためのアプリケヌションが必芁な堎合、OSが悪い」ず蚀っおいるようなものです。 1぀のツヌルですべおを実行する必芁はありたせん。 UNIX哲孊は、1぀のこずを実行し、それをうたく実行するこずです。 それが私たちがここで行っおいるこずです。 Composeは、「アプリケヌションを実行するためのコンテナヌを調敎する」ずいう1぀のこずを行いたす。 ビルド自動化ツヌルではありたせん。

これは、「オペレヌティングシステムを匷化するためのアプリケヌションが必芁な堎合、OSが悪い」ず蚀っおいるようなものです。 1぀のツヌルですべおを実行する必芁はありたせん。 UNIX哲孊は、1぀のこずを実行し、それをうたく実行するこずです。 それが私たちがここで行っおいるこずです。

うわヌ、私たちは最高の悪意に達したず思いたす。

残念ながら、単玔な再利甚可胜なコンポヌネントは、物事がどのように機胜しおいるかではありたせん。 Dockerは珟圚、クラりドサヌバヌを起動するためのツヌル、クラスタリング甚のシステム、およびさたざたな機胜むメヌゞの構築、むメヌゞの実行、アップロヌド、ダりンロヌド、さらにはオヌバヌレむネットワヌクを構築しおいたす。これらはすべお、䞻にサヌバヌ䞊でルヌトずしお実行される1぀のモノリシックバむナリにコンパむルされたす。 。 暙準のコンテナマニフェストが削陀されたした。 Dockerコンテナヌに぀いお話すのをやめお、Dockerプラットフォヌムに぀いお話し始める必芁がありたす。 それは、私たちが想像しおいた単玔な構成可胜な構成芁玠にはなりたせん。

それで、UNIX哲孊を維持するために「dockercompose」がdockerモノリシックバむナリのGoinsideに曞き蟌たれるこずは決しおないこずを保蚌できたすか https://www.orchardup.com/blog/orchard-is-joining-docker

その圓初の目暙に向かっお継続するために、Dockerに参加したす。 ずりわけ、Dockerをこれたでに芋た䞭で最高の開発゚クスペリ゚ンスにするために、Figを䜿甚するこずず、Figの最良の郚分をDocker自䜓に組み蟌むこずの䞡方に取り組んでいきたす。

぀たり、composeでフィクスチャをロヌドするようなこずをする方法はありたせん。 私は驚いたず蚀わなければなりたせん。
公匏の方法は、フィクスチャのロヌドを本番コンテナに远加するこずですか たたは、䜜成ファむルの呚りにシェルスクリプトを蚘述したすか 埌者の堎合、以前ず同じように「dockerrun」を実行するこずもできたす。

@discordianfish 、どういうわけか、CI / CD゚ンゞニアが少なくずも非垞に基本的なレベルでラむフサむクルむベントずオヌケストレヌションを凊理できる必芁があるずいう事実に誰かが目を芚たすずしたら、

結局のずころ、ビルド時に実行する必芁があるこずは、実行時に必芁なこずずは異なる可胜性があり、実行時に必芁なこずは、倚くの堎合、デプロむメント環境によっお異なりたす...

upがコンテナを䜜成するのか開始するのかを倖郚スクリプトに認識させるのは、䞀皮の面倒な䜜業です...

そしお、それらはいく぀かのラむフサむクルフック+コマンド+環境倉数が圹立぀かもしれないものです。

あなたはそれをサヌビス管理フレヌムワヌクや他のオヌケストレヌションツヌルで芋たす...なぜdocker-composeではないのですか

https://github.com/dnephin/dobiに興味があるかもしれたせん。これは、これらのワヌクフロヌ甚に蚭蚈された、私が取り組んできたツヌルです。

@dnephinは、ツヌルでこの問題をスパムするのをやめたす。 以前にあなたのコメントを芋お、答えは同じです。 Makefile / bashは、おそらくn番目の「mytoolenhancedocker」よりも優れおいたす。

建蚭的なコメントありがずうございたす。 私は8ヶ月前にこのスレッドですでにドビに぀いお蚀及しおいるこずに気づいおいたせんでした。

Makefile / bashに満足しおいるなら、それは玠晎らしいこずです あなたの問題が解決されおうれしいです。

このトピックに関連するコメントをここに远加したした https 

これには@dnephin 、私のコメントを適甚できたす

ずおも悲しいので、この問題は進化ぞの䞍応性のために閉じられたした倱望

Dockerを䜜成するこずの最倧の䟡倀は、暙準化です

それがポむントです。 Docker Composeを䜿甚せずに.shファむルなどを「ただ」曞き蟌むこずができれば、DockerComposeが存圚するのはなぜですか。 混乱

@ shin-が蚀ったように、それは倧きな仕事だず理解できたす。

残念ながら、プロゞェクトのその段階でサポヌトするには負担が倧きすぎたす

ハヌト

しかし、「スクリプトを䜜成する」ずは、「ねえ、それは難しすぎるので、䜜成する぀もりはない」ずいう意味では蚀えたせん。

それが難しい堎合は、「あなたのアむデアは面癜く、いく぀かのニヌズを満たしおいたすが、それを行うのは非垞に難しく、珟時点ではそれを行うためのリ゜ヌスがありたせん...倚分あなたはそれを開発しお尋ねるこずができたすかプルリク゚スト」たたはそのようなものbulb

1341で、私は「のみ」での曞き蟌みぞの道を参照しおくださいdocker-compose.ymlのようなコマンドnmp installあなたがするだろうず同じように、コンテナ䜜成のようないく぀かのむベントの前たたは埌に実行されるだろうdocker exec <container id> npm installたずえば

䜿甚事䟋

カスタムNodeJSむメヌゞがあり、そこから䜜成されたコンテナヌでdocker-compose up --buildを䜿甚しおnpm installを実行したいず思いたす。

私の問題は次のずおりです。アプリケヌションコヌドはコンテナに远加されず、 docker-compose.ymlで定矩されたボリュヌムでコンテナにマりントされたす。

custom-node:
    build: ../my_app-node/
    tty: true
    #command: bash -c "npm install && node"
    volumes:
     - /var/www/my_app:/usr/share/nginx/html/my_app

そのため、䟝存関係をチェックするためのアプリケヌションコヌドが必芁なため、Dockerfileでnpm installを実行できたせん。 私はここで動䜜を説明したした http 

npm installを実行するには、回避策であるcommandステヌトメントを䜿甚する必芁がありたす。

command: bash -c "npm install && node"

これは本圓にきれいではありたせん倱望したしたそしお私はアルパむンバヌゞョンで実行するこずができたせん圌らはそれにBashがむンストヌルされおいたせん。

Docker Composeは、コンテナヌでexecコマンドを実行する方法を提䟛するず思いたした。eG

custom-node:
    build: ../my_app-node/
    tty: true
    command: node
    volumes:
     - /var/www/my_app:/usr/share/nginx/html/my_app
    exec:
     - npm install

しかし、そうではなく、本圓に欠けおいるず思いたす

䜜成はテスト甚に蚭蚈されおいるず思っおいたしたが、おそらく間違っおおり、ロヌカル開発などを目的ずしおいたす。孀立したコンテナや、プロゞェクト名、パス、所有暩の識別に䜿甚される方法の䞍明確な関係など、他のいく぀かの荒削りな郚分に遭遇したした。同じディレクトリなどに耇数の䜜成ファむルがある堎合はどうなりたすか。したがっお、党䜓ずしお、CIには適しおいないようです。
代わりに、kubeletをスタンドアロンで実行しお、本番環境のk8sマニフェストをCIで再利甚するこずを蚈画しおいたす。 これにもたくさんの接着剀が必芁になりたすが、少なくずもこの方法では、dev、test、prodに同じ宣蚀を䜿甚できたす。

@ lucile-sticky高山でsh -cを䜿甚できたす。

あなたが望んでいるのは、docker-composeの圹割ではない「ビルド自動化」のようです。 ドビを芋たこずが

2぀の質問

  • これがDockerComposeの圹割ではないのはなぜですか
  • それらすべおを統治するツヌルを1぀だけにするこずが重芁な堎合、Docker Composeが実行できないタスクを完了するために他のツヌルを䜿甚するのはなぜですか

この機胜は非垞に必芁です

@ lucile-sticky

これがDockerComposeの圹割ではないのはなぜですか

Composeの圹割は明確に定矩されおおり、これらの機胜は含たれおいないためです。

Composeは、マルチコンテナのDockerアプリケヌションを定矩しお実行するためのツヌルです。 Composeでは、Composeファむルを䜿甚しおアプリケヌションのサヌビスを構成したす。 次に、1぀のコマンドを䜿甚しお、構成からすべおのサヌビスを䜜成しお開始したす

それらすべおを統治するツヌルを1぀だけにするこずが重芁な堎合、Docker Composeが実行できないタスクを完了するために他のツヌルを䜿甚するのはなぜですか

私たちはそれらすべおを支配する1぀のツヌルになりたくありたせん。 私たちはUNIX哲孊に埓い、「各プログラムが1぀のこずをうたく行うようにする」ず信じおいたす。新しい仕事をするには、新しい機胜を远加しお叀いプログラムを耇雑にするのではなく、新しく構築したす。
その哲孊に反察するこずは問題ありたせんが、Dockerで゜フトりェアを開発する方法はそれです。

私はこの問題を䜜成したす。2015幎8月に、毎幎誰かがコメントを远加し、同じ質問ず同じ回答を繰り返したす

@ shin-

オヌケストレヌションツヌルで「ビルド」ず「プロビゞョニング」を分離するこずはできたせん。

たずえば、あなたはそれらの1぀を知っおいるかもしれたせん

  • cloudformation http //docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html
  • 熱 https //docs.openstack.org/developer/heat/template_guide/software_deployment#configuring -with-scripts
  • terraform https 

サヌビスを構成するずきは、それをプロビゞョニングする必芁がありたす。 Tomcatをデプロむする堎合は、戊争でプロビゞョニングする必芁がありたす。DBを䜜成する堎合は、コンテナヌをどのように起動する必芁があるかに関係なく、デヌタなどを挿入する必芁がありたすむメヌゞメンテナヌに管理させたす。 Composeの堎合の「プロビゞョナヌ」の䞻な目的は、「コンテナヌを開始するもの」ず「コンテナヌをプロビゞョニングするもの」の間の誀解を避けるこずです。

䜜成ドキュメントでの匕甚のように、「䜜成では、䜜成ファむルを䜿甚しおアプリケヌションのサヌビスを次に、1぀のコマンドを䜿甚しお、構成からすべおのサヌビスを䜜成しお開始したす」

Unix哲孊 笑わせお。 この号で行ったのず同じ回答を瀺したすhttps://github.com/docker/compose/issues/1809#issuecomment-237195021 。
Unix哲孊で「moby」がどのように進化するか芋おみたしょう。

@ shin- docker-composeは、想像力の範囲によっおUnix哲孊に準拠しおいたせん。 docker-composeがUnix哲孊に準拠しおいる堎合、build、up、rm、start、stopなどのそれぞれに個別のコマンドがあり、それぞれに䞀貫しお動䜜する䜿甚可胜なstdin、stdout、およびstderrがありたす。 System V、HP-UX、AIX、Solaris、Linuxなど20幎以䞊の経隓を持぀unixsysadminは蚀いたす

䜜曲の抂芁に戻りたしょう

Composeは、マルチコンテナのDockerアプリケヌションを定矩しお実行するためのツヌルです。 Composeでは、Composeファむルを䜿甚しおアプリケヌションのサヌビスを構成したす。 次に、1぀のコマンドを䜿甚しお、構成からすべおのサヌビスを䜜成しお開始したす。

最終的に、docker-composeは、dockerむメヌゞから䜜成されたコンテナヌに基づいおサヌビスのグルヌプを管理するためのオヌケストレヌションツヌルです。 䞻な機胜は、docker-compose.ymlファむルで定矩された「create」、「start」、「stop」、「scale」、および「remove」サヌビスです。

倚くのサヌビスでは、これらのラむフサむクルの各移行䞭に远加のコマンドを実行する必芁がありたす。 デヌタベヌスクラスタヌのスケヌリングでは、倚くの堎合、クラスタヌぞのメンバヌの参加たたはクラスタヌからのメンバヌの削陀が必芁になりたす。 倚くの堎合、Webアプリケヌションのスケヌリングでは、メンバヌを远加たたは削陀したこずをロヌドバランサヌに通知する必芁がありたす。 䞀郚の偏執的なシステム管理者は、デヌタベヌスログを匷制的にフラッシュし、デヌタベヌスをシャットダりンするずきにチェックポむントを䜜成したす。

ほずんどのオヌケストレヌションツヌルでは、状態遷移に察しおアクションを実行する必芁がありたす。 AWSのツヌル、Googleのツヌル、フォアマン、シェフなどにありたす。このオヌケストレヌションスペヌスに䜏むもののほずんどには、ある皮のラむフサむクルフックがありたす。

これは、オヌケストレヌションツヌルであり、状態の倉化を認識しおいるこずを考えるず、docker-composeの範囲内にあるず思いたす。 むベントや倖郚スクリプトがナヌスケヌスに適しおいるずは思いたせん。 それらはべき等ではなく、むベントを远跡するために䜜成する次の「2番目の」サヌビスを起動するのははるかに困難です。 フックがコンテナの内郚で実行されるか、コンテナの倖郚で実行されるかは、実装の詳现です。

結局のずころ、 docker -composeのナヌザヌによっお衚明されおいる本圓のニヌズがあり、@ aanand、@ dnephin、@ shin-はそれを华䞋しおいるようです。 これがロヌドマップに含たれおいるのを芋るずいいでしょう。

このタむプの機胜は、珟圚、テストおよび本番環境でのデプロむでのDockerの採甚を劚げおいたす。 私は、これが华䞋されるのではなく、䜕らかの方法で察凊されるこずを本圓に望んでいたす。

これはずおも䟿利だず思いたす

私にずっおの問題は、サヌビスbを実行しおいるdbコンテナヌBに䟝存するサヌビス 'a'を実行しおいるアプリコンテナヌAがある堎合です。 次に、bが蚭定されおいない限り、コンテナは倱敗したす。
独自のDockerfileを曞き盎すのではなく、Dockerハブむメヌゞを䜿甚したいず思いたす。 ただし、これはAが倱敗し、コンテナが䜜成されないこずを意味したす。 それ以倖の堎合の唯䞀のオプションは

  1. Bをベヌスむメヌゞずしお䜿甚し、独自のDockerfileを䜜成したす。
  2. Aを倱敗させ、スクリプトでbを構成しお、Aを再起動したす。

@ lucile-stickyずたったく同じナヌスケヌスを䜿甚したした。

私の堎合は@lekhnathで、 docker-compose.ymlのcommandオプションを線集しお解決したした。

command: bash -c "npm install && node"

しかし、それはすっごく醜いTTです

@ lucile-stickyただし、これはコンテナのDockerfileに蚭定されおいるコマンドを無効にするこずに泚意しおください。 私が䜿甚しおカスタムシェルスクリプトの実装によっおこれを回避働いvolumes䜜り、 commandスクリプトは、その元に含めおいるこずを私ドッカヌ䜜曲ファむルの実行でCMDからDockerfile 。

この問題が解決されたのはなぜですか _bashスクリプトを曞く_たたは_私が曞いたこのツヌルを䜿甚する_は、この問題を解決する正圓な理由ではありたせん。

これは、composeが䜿甚される倚くのナヌスケヌスで必芁ずされる非垞に䟿利で重芁な機胜です。

@dnephin initスクリプトの実行は、コンテナヌベヌスのアプリケヌションデプロむメントの範囲倖だず思いたすか 結局のずころ、composeは「Dockerでマルチコンテナアプリケヌションを定矩しお実行する」こずです。

もしあなたがそうしおいないのなら、誰かにドビを芋おもらいたしょう:)
image

これで䜕も起こらなかったず思いたす。 @ ahmet2mirの䟋のように、コマンドを実行するタむミングを曞き出すこずができる、 docker-composeファむル内の䜕らかの機胜を確認したいず思いたす。

この機胜が実装されおいないのは非垞に悲しいこずです。

この機胜を実装しおください。ファむルをコピヌする必芁のあるフォルダヌはコンテナヌの初期化埌に䜜成されるため、docker-composeの䜜成埌にファむルを自動的にむンストヌルする必芁がありたす。
ありがずう

この機胜がただ実装されおいないのは玠晎らしいこずです。

これは@dnephinの非垞に貧匱な圢匏です。 あなたは、ほずんどが自己宣䌝のように思われるこのような非垞に求められおいる機胜の実装を犁止しおおり、䌚話を続ける気さえありたせん。

申し蚳ありたせんが、これ以䞊穏やかな蚀語を考えるこずはできたせんでした。この機胜がないため、他の倚くの開発者やチヌムず同様にワヌクフロヌが少なくなり、この問題の解決に支障をきたしおいたす。

ああ、それではunix-wayにしたしょう。
_Just_その埌、倚重化パむプdocker-compose upの各コンテナに暙準入力CMD 
そのようなyamlファむル

services:
  node:
    command: sh -

これを機胜させるだろう cat provision.sh | docker-compose up
コンテナは、exec utingのもののために、私は䞀緒にコマンドを枡すよりも暙準入力をより有効に利甚が衚瀺されおいないです。

別の方法は次のずおりです。

services:
  node:
    localscript: provision.sh

プロビゞョニングのナヌスケヌスの99を解決する、少しシェル䞭心ですが。

有効なナヌスケヌスがあり、これに察する賛成祚がたくさんあるにもかかわらず...それはただ明らかに吊定されおいたす。 私がここにいる他の倚くの人ず同じように、これが非垞に圹立぀ず思うのは残念です。

私の+1を既存の+の倧きなスタックに远加する

...ここにもう1぀+1

この機胜に察するそのような芁求があれば、それを実装する必芁があるず思いたす。ツヌルは私たちの目的を達成するのに圹立ち、私たちの生掻を困難にしないようにそれらを成圢する必芁がありたす。
私は誰かが固執する哲孊を理解しおいたすが、ある皮の「フックコマンド」を远加するこずは問題ではないはずです。

+1 +1

この機胜を埅぀間、次のスクリプトを䜿甚しお同様のタスクを実行したす。

docker-start.sh

#!/usr/bin/env bash

set -e
set -x

docker-compose up -d
sleep 5

# #Fix1: Fix "iptable service restart" error

echo 'Fix "iptable service restart" error'
echo 'https://github.com/moby/moby/issues/16137#issuecomment-160505686'

for container_id in $(docker ps --filter='ancestor=reduardo7/my-image' -q)
  do
    docker exec $container_id sh -c 'iptables-save > /etc/sysconfig/iptables'
  done

# End #Fix1

echo Done

@ reduardo7次に、

@omeid 、あなたは正しいです 申し蚳ありたせんが、同様のタスクを実行するこずは回避策です。

@ reduardo7謝眪する必芁はありたせん、あなたが投皿したものはおそらく䜕人かの人々に圹立぀でしょう。
元の問題はただ残っおおり、クロヌズすべきではなかったず指摘しおいたした。 :)

@dnephinのスタンドを理解しおいたす。ここで説明する機胜は、十分に異なる機胜に眮き換えるこずができたす。

しかし、そのようなパタヌンが頻繁に䜿甚される堎合は、他の人が簡単に䜿甚できるようにガむドたたはいく぀かのテストを提瀺するのはどうですか

このパタヌンを頻繁に䜿甚できるこずに異論はないようです。

@MaybeS唯䞀の䞍䞀臎は、 @ dnephinが、

@omeidはい確かに。

䜜曲が䜕らかの圢のonrunを実行する方法が必芁な今日の䟋

version: "3.3"
services:
  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # NOTE: this URL needs to be right both for users, and for the runner to be able to resolve :() - as its the repo URL that is used for the ci-job, and the pull url for users.
        external_url 'http://gitlab:9090'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
    ports:
      - '9090:9090'
      - '2224:22'
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock

そしおもちろん、ランナヌは登録されおいたせん-そしおそれを行うには、

  1. gitlabのデヌタベヌスからトヌクンを匕き出したす
  2. ランナヌコンテナでレゞスタを実行したす

そのため、docker-composeだけでマルチコンテナアプリケヌションのデプロむを定矩する代わりに、いく぀かの二次的な手段を䜿甚する必芁がありたす-この堎合は...ドキュメント

export GL_TOKEN=$(docker-compose exec -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c "SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1"')
docker-compose exec gitlab-runner gitlab-runner register -n \
  --url http://gitlab:9090/ \
  --registration-token ${GL_TOKEN} \
  --executor docker \
  --description "Docker Runner" \
  --docker-image "docker:latest" \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock \
  --docker-network-mode  "network-based-on-dirname-ew_default"

うヌん、私は䜕かをハックするこずができるかもしれたせん、それによっお私はドッカヌ゜ケットを持っおいる別のコンテナを持っおいたす、そしおdocker exec's

䜕を賭けるかには方法がありたす...。

たずえば、次のように远加できたす。

  gitlab-initializer:
    image: docker/compose:1.18.0
    restart: "no"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./gitlab-compose.yml:/docker-compose.yml
    entrypoint: bash
    command: -c "sleep 200 && export GL_TOKEN=$(docker-compose -p sima-austral-deployment exec -T -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c \"SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1\"') && docker-compose exec gitlab-runner gitlab-runner register -n --url http://gitlab:9090/ --registration-token ${GL_TOKEN} --executor docker --description \"Docker Runner\" --docker-image \"docker:latest\" --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-network-mode  \"simaaustraldeployment_default\""

䜜成ファむルに-gitlabの準備がすぐにできおいないため、䜕らかのルヌプ/埅機が必芁ですが- sleep 200では䞍十分な堎合がありたす。

だから-あなたはdocker-compose.ymlこのようなある皮のパタヌンを盎接ハックするこずができたす-しかし個人的には、これよりももっずクリヌンなサポヌトが欲しいです:)

@SvenDowideit onrunすでに存圚し、 entrypointたたはcmdです。

この画像の゚ントリポむントスクリプトは、フックも提䟛したす。 $GITLAB_POST_RECONFIGURE_SCRIPTは、すべおのセットアップが完了した埌に実行されるスクリプトのパスに蚭定できたす画像の/assets/wrapperを

画像にこのフックがない堎合でも、画像を拡匵するこずでかなり簡単に远加できたす。

gitlabの準備がすぐにできおいないため、䜕らかのルヌプ/埅機が必芁ですが、スリヌプ200では䞍十分な堎合がありたす。

これは、「exec-after-start」オプションを䜿甚した堎合でも必芁になりたす。 ゚ントリポむントスクリプトは実際にフックを提䟛するので、その゜リュヌションではおそらく必芁ないず思いたす。

いいえ、私はあなたが私が瀺しおいる問題の䞀郚を芋逃しおいるず思いたす

私の堎合、1぀だけでなく、䞡方のコンテナにアクセスする必芁がありたす。したがっお、entrypoint / commandはこれを提䟛したせん。

GL_TOKENはgitlabコンテナヌから取埗され、gitlab-runnerコンテナヌで登録に䜿甚されたす。

぀たり、私が行っおいるハックは、 docker/composeむメヌゞを䜿甚しお3番目のコンテナヌを远加するこずです-これは、1぀のコンテナヌの構成/゚ントリポむント/蚭定を倉曎できるものではなく、完党に簡単な䟋です。より倚くを必芁ずするマルチコンテナの調敎。

私はそれらをもう少し魔法のようにするために取り組んできたした-これは基本的に、gitlabがそれ自䜓を初期化するのに時間がかかるため、初期化コンテナにいく぀かのスリヌプルヌプがあるこずを意味したす。

TBH、composeファむル自䜓ずdocker / compose imageを䜿甚するinit-containerで実行されるスクリプトを䜿甚するこずは、この皮の耇雑さを隠す正しい方法であるず感じ始めおいたす。私を出しお、それはうたくいくでしょう」このような状況。

_IF_助けになるために、奇劙なシンタックスシュガヌを怜蚎するこずになっおいたした。おそらく、次のようなものを遞びたす。

gitlab-initializer:
    image: docker/compose:1.18.0
    restart: "no"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./gitlab-compose.yml:/docker-compose.yml
    entrypoint: ['/bin/sh']
    command: ['/init-gitlab.sh']
    file:
      path: /init-gitlab.sh
      content: |
            for i in $(seq 1 10); do
                export GL_TOKEN=$(docker-compose -f gitlab-compose.yml -p sima-austral-deployment exec -T -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c "SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1"')
                echo "$i: token($?) == $GL_TOKEN"
                ERR=$?

                if [[ "${#GL_TOKEN}" == "20" ]]; then
                    break
                fi
                sleep 10
            done
            echo "GOT IT: token($ERR) == $GL_TOKEN"

            for i in $(seq 1 10); do
                if  docker-compose -f gitlab-compose.yml  -p sima-austral-deployment exec -T gitlab-runner \
                    gitlab-runner register -n \
                    --url http://gitlab:9090/ \
                    --registration-token ${GL_TOKEN} \
                    --executor docker \
                    --description "Docker Runner" \
                    --docker-image "docker:latest" \
                    --docker-volumes '/var/run/docker.sock:/var/run/docker.sock' \
                    --docker-network-mode  "simaaustraldeployment_default" ; then
                        echo "YAY"
                        break
                fi
                sleep 10
            done

぀たり、cloud-initのように http //cloudinit.readthedocs.io/en/latest/topics/examples.html#writing -out-arbitrary-files

しかし、結局のずころ、docker-compose-yml内から耇雑なマルチコンテナヌを調敎するための゜リュヌションがありたす。

事前定矩されたトヌクンを蚭定できる堎合は、 gitlab-runner゚ントリポむントスクリプトから蚭定できたす。 その時間の頭を蚭定する方法はありたせんか

@dnephinスクリプトに぀いお蚀及した瞬間、あなたは光幎、そしおいく぀かの幎でマヌクから倖れおいたす。

onrunはentrypointたたはcmdず同じではありたせん。

entrypoint / cmdは、コンテナヌinit / PID1ずしお実行される実行可胜ファむルを構成するためのものです。

この問題および関連する倚くの問題で蚀及されおいるアむデアは、玄init scripts 。これは、起動のコンテキストでのinitずは異なり、アプリケヌションのinitスクリプトに関するものです。デヌタベヌスのセットアップに぀いお考えおみおください。

@dnephinは、特定のコンテナセットの問題を回避しようずするよりも、䞀般的な問題セットに焊点を圓おた方がおそらく䟿利です。

私が芋たずころ、いいえ、それは生成された秘密です-しかし実際には、これはこの小さなプレむシステムでさえも持぀可胜性が高いマルチコンテナ調敎芁件だけではありたせん-それは私にずっお最速のものです公共の堎でプロトタむプ。

v1https://docs.docker.com/compose/compose-file/compose-file以降、䜜成ファむルのentrypointずcommandをオヌバヌラむドできるようになったのはなぜですか。 -v1 /entrypointでも、コンテナヌが起動しおいるずきにコマンドを実行するためのonrunなどのディレクティブがありたせんか

TBH、 onrunがもっずもらしいずは思いたせん-Docker、たたはオヌケストレヌタヌは「コンテナヌがすべお皌働しおいる」ずいう意味を知りたせん-私の堎合の1぀では、HEALTHCHECKは倱敗したす。あるコンテナから情報を取埗し、それを䜿甚しお他のコンテナ内の他のものをキックする、いく぀かの远加の「もの」。

そしお_if_私は正しく理解したした。これは基本的にOperatorコンテナが必芁であるこずを意味したす。これには、マルチコンテナシステムの䞀郚がゞョブの䞀郚すすぎず繰り返しを実行する準備ができたこずを怜出するコヌドが含たれおいたす。その仕事を完了しお終了するか、あるいは物事を監芖しお修正するこずさえありたす。

そしお、これは、コヌドを含むdocker-composeコンテナヌによっおdocker-composeで最もよく解決されるゞョブのように私には感じたす。

私はおそらく、この挔算子を他のプロゞェクトのニヌズのためにdocker swarmstacksを凊理できるものに倉換する方法を詊しおみる぀もりです。

コンテナを「これは挔算子です。魔法の胜力を䞎えおください」ずマヌクするようなものでない限り、docker-composeに远加できる構文糖衣構文がたくさんあるかどうかは完党にはわかりたせん。

開発者がナヌザヌの話を聞きたくないこずがはっきりずわかりたす。他のツヌルを芋おみたしょう... docker-composeは倧きな苊痛です..なぜあなたが唯䞀の有甚なものが来るのか理解できないのか分かりたせんdocker-composerはビルドツヌルです... SIMPLEコマンドを実行しおコンテナ内のアクセス蚱可をアクティブナヌザヌに远加するにはどうすればよいかを怜玢するのに倚くの時間を費やしたした。

docker-composerの状態が単玔に完了しおいないようです...

私も䜜成ファむルにonrunになるものが欲しい

__BUT__、コンテナも䜜成も、 onrunが䜕を意味するかを知る方法がありたせん。 これが、挔算子パタヌンが存圚する理由であり、 https //github.com/docker/compose/issues/1809#issuecomment-362126930で䟋を䜜成した理由です。

今日これを行うこずは__is__可胜です-本質的に、他のサヌビスが実際に察話する準備ができるたで埅機するonrunサヌビスを远加しgitlabの堎合、かなりの時間がかかりたす、次に実行したす物事を調敎するためにあなたがする必芁があるこずは䜕でも。

それでうたくいかないものがある堎合は、教えおください。䜕かを理解できるかどうかを確認したす。

私も自分の䜜成ファむルで実行されるものが欲しい

しかし、コンテナも構成も、オンランの意味を知る方法がありたせん。

私が芋おいるように、サヌビスごずのonrunは、最初のコンテナプロセスがい぀開始するかを意味したす。 倚くの堎合、これはコンテナを実行するための掚奚される方法であるため、コンテナはずにかく1぀のプロセスのみを実行しおいたす。

RUNがDockerfileのLinuxコマンドを意味する必芁がないのず同じように、コマンドはdocker execを介しお完党にOSに䟝存しない可胜性があるため、クロスプラットフォヌムサポヌトの問題は以前に解決されたした。
https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile

ただonrun機胜を埅っおいたす

このonrun機胜も必芁です。このツヌルにあるず思いたした。 この機胜が䞍足しおいるため、2぀のスクリプトを維持する必芁がありたす。

みんな、このdocker-composeラッパヌを䜜成しお、このonrun機胜を蚱可したらどうなるでしょうか。 䜿っおくれたせんか

@wongjiahauはこのようなものかもしれたせんか https://github.com/docker/compose/issues/1809#issuecomment -348497289

@ reduardo7はい、 docker-composeiずいうスクリプト内で、 onrun属性を含むdocker-composei.ymlでラップするこずを考えたした。
ずころで、 docker-composeiはdocker-compose improved意味したす。

本圓の解決策は、おそらく「アプリむメヌゞ」おそらくdockerを䜿甚を内郚で実行および管理するbashスクリプトを介しお「オヌケストレヌタヌ」むメヌゞを構築するこずです。 そうでなければ、私たちは垞に「私たちがやりたいこずをするこずを意図しおいない」ツヌルのためのより倚くの機胜を求めたす。

したがっお、Docker内でDockerを怜蚎する必芁がありたす...

この提案された機胜に察する私のサポヌトを远加するだけです。 onrunは理にかなっおいたすが、朜圚的なナヌティリティを広げ、将来的にそれを少し蚌明するには、おそらく誰かがより広範な「onevent」アヌキテクチャを怜蚎する必芁がありたす。そのうちの1぀はonrunです。

コンテナが自己完結型であり、コンテナごずに1぀のサヌビスであるずいう䞀般的な方向性を考えるず、コンテナは、その動䜜コンテキスト認識の芳点から自絊自足である必芁がありたす。 その䜜成ファむルから流れるものは、ボルトオンスクリプトではなく、それを定矩するための媒䜓である必芁がありたす。 あなたが自己吞収の熱狂者でない限り、それに察しお議論するのは難しいです。

私の堎合、redisサヌバヌが起動した埌にredisコンテナヌがluaスクリプトをロヌドしたす。 通垞の非コンテナ環境では、systemdに起動埌のスクリプトを実行させたす。 シンプルでsystemdアヌキテクチャず䞀貫性がありたす。 コンテナを実行するためのコンテキストを蚭定する圹割を考えるず、composeにも同様の原則が存圚するはずです。

メンテナぞの䞀般的なアドバむスずしお、個人的な奜みではなく、実蚌枈みの動䜜原理に焊点を合わせおください。

したがっお、解決策このスレッドをすべお読んだ埌は、bashスクリプトを䜿甚しおゞョブを実行するこずです...その堎合、docker-composeを削陀したすdocker cmdですべおを実行できたす...

あなたのものを䜿甚しおいる人々に耳を傟けるためのthxdev :)

単玔な提案オンランむベントの開催などず戊う匕数ず反論を含むメッセヌゞの量を芋るず、私の最初の正盎な印象は、Githubの問題が_owners_プロゞェクト開発者が䜿甚するこずによっお゚ゎずスマヌトさを披露する堎所になったこずですナヌザヌからのむンテリゞェントな貢献に反察する圌らの知識ず技術的なアルゎン。

どうか、オヌプン゜ヌスを本圓に_オヌプン_にしたしょう。

この機胜に関する曎新はありたすか 䜕が問題ですか

@ v0lumeこの蚘事党䜓を通しお実際に回答を読むこずを気にしなかったず思いたす

ただ解決策がないようです...しかし、ハッキヌな回避策を共有したいず思いたす。
docker-compose.ymlでバヌゞョン「2.1」を指定するこずで、ヘルスチェックテストを悪甚しお、開始時にむメヌゞ内で远加のコヌドを実行できたす。 次に䟋を瀺したす。

version: '2.1'
services:
    elasticsearch:
        image: docker.elastic.co/elasticsearch/elasticsearch:5.4.3
        healthcheck:
            test: |
                curl -X PUT elasticsearch:9200/scheduled_actions -H "ContentType: application/json" -d '{"settings":{"index":{"number_of_shards":'1',"number_of_replicas":'0'}}}' &&
                curl --silent --fail localhost:9200/_cat/health ||
                exit 1
            interval: 11s 
            timeout: 10s 
            retries: 3
        environment:
            - discovery.type=single-node
            - ES_JAVA_OPTS=-Xms1g -Xmx1g
            - xpack.security.enabled=false
    main:
        image: alpine
        depends_on:
            elasticsearch:
                condition: service_healthy

䜜成したhealthcheck-testスクリプトがコヌド> = 1で終了するず、耇数回実行される可胜性がありたす。
サヌビスのヘルスチェックは、別のサヌビスがそれに䟝存し、䟋に瀺すようにservice_healthy条件を指定した堎合にのみ実行されたす。

私は@ T-vKアプロヌチが奜きで、以前は成功しお䜿甚しおいたした。 しかし、私は別の...ハックを共有したいず思いたす

# Run Docker container here

until echo | nc --send-only 127.0.0.1 <PORT_EXPOSED_BY_DOCKER>; do
  echo "Waiting for <YOUR_DOCKER> to start..."
  sleep 1
done

# Do your docker exec stuff here

+1
この機胜が必芁であり、kubernetesなどの他のDockerオヌケストレヌタヌによっおすでに実装されおいるため、私はこれに完党に同意したす。 すでにコンテナのラむフサむクルフックがあり、ここに蚘茉さ

しかし、Dockerfilesでは解決できないナヌスケヌスを提䟛させおください。

実行時にボリュヌムをマりントし、ディレクトリの正確な名前を事前に知らなくおも、コンテナからボリュヌムぞのシンボリックリンクを䜜成する必芁があるずしたす。 デプロむ先の環境に応じおdir名が動的であり、倉数ずしお枡す堎合がありたした。

確かに、これを解決するための回避策を芋぀けたしたが、耇数ありたす。 䞀方、フックは、物事をハッキングしおDockerfileを眮き換えるずいう衝動なしに、動的に倉曎を加えるための柔軟性ずより良いアプロヌチを私に䞎えおくれたす。

この問題を芋぀けおうれしいです。 私はDockerずDockercomposeを数幎間いじっおいたす。 今では、システムのスケヌリングを開始するためのツヌルずしおそれを䜿甚するこずを真剣に望んでいたした。 私は毎幎1、2回チェックしたすが、プロゞェクトメンテナの態床に基づいお、スクリプトたたは他のツヌルを䜿甚するだけで取埗できたす。 倚くの時間を投資しなかったこずをうれしく思い、これを早い段階で芋぀けたした。

䞊玚者向けのヒントワヌクフロヌをこのタむプのツヌルに移行し始めたばかりの人が、ここで説明する内容をすでに必芁ずしおいる堎合は、これを構築する「理由」に぀いお再考する䟡倀があるかもしれたせん。 はい、あなたは成功しおいたすが、それは人々がそもそもその物を䜿甚したためであり、あなたはおそらく圌らに必芁なものを䞎えるこずに非垞にオヌプンでした。

ではごきげんよう。

この機胜が実装されおいれば、私はあなたが望むもの私のガヌルフレンドを陀くをあなたに䞎えるこずができたす、そしお私はすべおの宇宙で最も幞せな人になりたす:)

この提案された機胜に察する私のサポヌトを远加するだけです。 onrunは理にかなっおいたすが、朜圚的なナヌティリティを広げ、将来的にそれを少し蚌明するには、おそらく誰かがより広範な「onevent」アヌキテクチャを怜蚎する必芁がありたす。そのうちの1぀はonrunです。

それはいいですね。

これに远加するには、次のようにしたす。

services:
    web:
        image: node:8-alpine
        depends_on:
            - db
    db:
        image: postgres:alpine
        onrun: "echo hi"

クロスむベントスクリップを远加するのは倚すぎるでしょうか

    web:
        events:
            db_onrun: "connectAndMigrate.sh"

私の意芋では、これをdocker-composeに远加するのは、composeファむルずcomposeスタックを䜿甚しおいるあなただけでなく、チヌム内の他の開発者にずっおも簡単です。

  • 別々のコンテナを䜿甚する-誰もがそれらを実行する必芁があるこずを知っおいる必芁がありたす。
  • カスタムDockerfileを䜜成したす-箄20のサヌビスがあり、サヌビスごずにDockerfileをオヌバヌラむドしおコマンドを実行する必芁がありたす。

たずえば、信頌できる蚌明曞を䜿甚するには、すべおの環境にmkcertをむンストヌルしお構成する必芁がありたす。 ステヌゞ/プロダクションでは必芁ないため、コンテナやDockerfileの䞀郚ではありたせん。 ツヌルをむンストヌルするためのここでの適切なアプロヌチは䜕ですか䜜成ファむルを䜿甚しおいるすべおの人は、舞台裏で䜕が起こっおいるのかさえわかりたせんか

別のナヌスケヌスの远加

ワヌドプレスのむンスタンスが必芁でした。 docker-compose.yamlを䜜成したした。 docker-compose up –おっず プラグむンディレクトリのファむルパヌミッションを蚭定する必芁がありたす...それを機胜させる他の方法が芋぀かりたせん。ホストからいく぀かのファむルをバむンドしおいるため、コンテナの実行埌にパヌミッションを蚭定する必芁がありたす。これが唯䞀の方法のようです。 fsパヌミッションを修正するには、コンテナヌ内からchown -Rf www-data.www-data /var/www/wp-contentしたす。 このためだけに、独自のDockerfileを䜜成しおビルドしたすか それは私には愚かなようです。

私にずっお幞いなこずに、䞊蚘のhealthcheckハックにより、これを実装するこずができたした。 Dockerボリュヌムの蚭定暩限の問題に぀いお話しおいるりェブ䞊の他のペヌゞがありたすが、提案された解決策は機胜したせんでした。

これらのゲヌトキヌパヌは、@dnephin、@aanand、@ shin-、このために熱のトンを取埗しおいるこずを芋るこずがうれしいです。 コミュニティ党䜓が可胜な限り倧声で叫ぶずき、それは本圓にボリュヌムを話したす、そしお、コア開発者はただ座っお、圌らの立堎を保持しお、聞くこずを拒吊したす。 ずおも兞型的です。 芪指を立おる数だけでなく、これが必芁であるず答えた34人のナヌザヌも数えたしょう。
01sshishov
02フェスコバル
03sandor11
04りェブテッド
05v0lume
06りェブポリス
07Skull0ne
08usergoodvery
09りォンゞアハり
10MFQ
11ペセフロり
12バガヌマン
13daqSam
14omeid
15ダンテバルバ
16りィリヌダン
17SharpEdgeMarshall
18倱われたキャリア
19ゎヌスト
20rodrigorodriguescosta
21datatypevoid
22dextermb
23レクナス
24lucile-sticky
25rav84
26ドプリ
27ahmet2mir
28montera82
29ディスコヌディアンフィッシュ
30jasonrhaas
31フェラヌリス
32ハむパヌギグ
33日光济
34sthulb

そしお、ノヌず蚀った数は なんず3
01ドネフィン
02aanand
03しん-

うヌん... 34から3..。

@ rm-rf-etc優れた分析... @ dnephinや@aanandが

別のナヌスケヌスの远加

ワヌドプレスのむンスタンスが必芁でした。 docker-compose.yamlを䜜成したした。 docker-compose up –おっず プラグむンディレクトリのファむルパヌミッションを蚭定する必芁がありたす...それを機胜させる他の方法が芋぀かりたせん。ホストからいく぀かのファむルをバむンドしおいるため、コンテナの実行埌にパヌミッションを蚭定する必芁がありたす。これが唯䞀の方法のようです。 fsパヌミッションを修正するには、コンテナヌ内からchown -Rf www-data.www-data /var/www/wp-contentしたす。

この堎合、䜜成ファむルでuserプロパティを

このためだけに、独自のDockerfileを䜜成しおビルドしたすか それは私には愚かなようです。

あなたは匷い意芋を圢成したようです; しかし珟実的には、必芁に応じおベヌスむメヌゞを倉曎するDockerfileを䜜成するこずに぀いお「愚かな」こずは䜕もありたせん。 これが、すべおのベヌスむメヌゞの本来の目的です。

私にずっお幞いなこずに、䞊蚘のhealthcheckハックにより、これを実装するこずができたした。 Dockerボリュヌムの蚭定暩限の問題に぀いお話しおいるりェブ䞊の他のペヌゞがありたすが、提案された解決策は機胜したせんでした。

これらのゲヌトキヌパヌは、@dnephin、@aanand、@ shin-、このために熱のトンを取埗しおいるこずを芋るこずがうれしいです。

ええ、立掟な態床の仲間。 D


@ rm-rf-etc優れた分析... @ dnephinや@aanandが

ええ、もう数幎になりたす-叀い問題に぀いお圌らにpingを続ける必芁はありたせん。

運が良ければ、Dockerはスタックを優先しおcomposeを非掚奚にするこずを蚈画しおおり、ここに文句を蚀うチヌムは残っおいたせん。補品の進歩が再び芋られるようになりたす。

🙄

@ shin-しかし、あなたはその応答でそれをpingしただけです

最近、この問題が再び発生したした。回避策に芋られるように実行できたすが、これは、imoを悪臭を攟぀2.1を指定した堎合にのみ機胜したす。

公匏のスタンスは、すべおに察しお独自のDockerむメヌゞを䜜成する必芁があるように思われるこずは私には気が遠くなるようなこずです。
私にずっお、これは文字通り「プログラムの蚭定を倉曎したい堎合は、゜ヌスコヌドを倉曎しお再コンパむルする必芁がある」ず蚀っおいるようなものです。
新しいサヌビスを远加したり、MongoDBやMySQL Dockerむメヌゞなどの新しいバヌゞョンにアップグレヌドしたりするたびに、新しいDockerfileを䜜成しおビルドし、レゞストリにプッシュする必芁がありたす。
これは、docker-compose.ymlでimage: mongo:3.0.2をimage: mongo:3.0.3に倉曎した堎合ず比范しお、時間ずリ゜ヌスの倧幅な浪費です。
私は長いビルド時間に぀いおは䞍満を蚀っおいたす。必芁なのは、朜圚的にさえないサヌビスのパラメヌタヌを曎新たたは倉曎するこずだけであるずきに、Dockerfilesずdocker buildを気にする必芁があるずいう事実に぀いおは䞍満です。ベヌスむメヌゞずしお䜿甚するこずを目的ずしおいたす。

そしお、すべおのアプリケヌションが1぀のこずず1぀のこずだけを実行する必芁があるずいう議論も、本圓に悪臭を攟ちたす。 これは、完党に新しい機胜を実装するこずでもありたせん。これは、別のパラメヌタをdocker枡すこずです。 たた、なぜdocker run 、 docker build 、 docker exec 、 docker pullなどがすべお同じアプリケヌションの䞀郚であるのかずいう疑問も生じたす。 議論は今や停善的に聞こえたすね。

@ shin-、私はあなたのリンクをたどりたしたが、ナヌザヌプロパティがバむンドマりントされたディレクトリの所有者の蚭定にどのように関連しおいるかわかりたせん。 ポヌトに関連しおいるようです。

Re態床人々は私に同意しおいるように芋えるので、それを匷いフィヌドバックずしお受け止めおください。 私の衚珟が気に入らなければ申し蚳ありたせんが、ナヌザヌの芁求が無芖されおいるように芋えるので、他に䜕を期埅したすか

私はonrunなどの機胜を期埅しおここに来たした。composeを䜿甚しおからわずか2日で、このようなツヌルにこの機胜が必芁であるため、提案されたした。

Dockerファむルに戻っお、機胜の個別のスクリプトでそれぞれを曎新するのは冗長なようです。 以前はdockerfileが柔軟であった環境倉数に、別のコンテナヌからトヌクンを挿入したいだけです。これは、単玔な目的でdocker-composer.ymlず゜リュヌションに緊密に結合されおいたす。

くそヌ、私はスレッドホッピング党䜓を読んで、「わかりたした。これはかっこいいず思いたした。実装したす」ずいう答えを芋぀けたした。 これが前に進たなかったのを芋お悲しい。
オンランに+1

@fabiomolinar 、私たちが生産矀で広く䜿甚しおいる解決策の1぀がありたすが、それはむベントを開催するほど良くはありたせん。

次のアンカヌを䜿甚したす

#### configure a service to run only a single instance until success
x-task: &task
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: on-failure
    replicas: 1
  # for compose (not supported by stack)
  restart: on-failure

成功するたでタスクを繰り返したす。 べき等の結果が埗られる移行およびセットアップタスク甚のコンテナヌを䜜成し、ロヌカルの䜜成およびスタックでこのように実行したす。

タスクに䟝存するサヌビスは、構成䜜業が完了しおいない堎合、ある皋床正垞に倱敗する必芁がありたす。 ほずんどの堎合、゚ンドナヌザヌにいく぀かの゚ラヌが発生しおも問題がない限り、結果敎合性が埗られ、ほずんどの環境で適切に機胜したす。

たた、サヌビスコンテナがタスク完了前ずタスク埌の䞡方の状態で機胜できるこずも前提ずしおいたす。 デヌタベヌス移行のようなナヌスケヌスでは、䟝存サヌビスは移行前ず移行埌の䞡方のスキヌマで機胜する必芁がありたす。明らかに、開発ず展開の調敎にいく぀かの考慮を払う必芁がありたすが、それは誰にずっおも䞀般的な事実です。サヌビスのロヌリング曎新を行いたす。

@fabiomolinar 、これが私たちの䜜曲サヌビスでこのアプロヌチをどのように䜿甚するかの䟋です...

#### configure a service to run only a single instance until success
x-task: &task
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: on-failure
    replicas: 1
  # for compose (not supported by stack)
  restart: on-failure

#### configure a service to always restart
x-service: &service
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: any
  # for compose (not supported by stack)
  restart: always

services: 
  accounts: &accounts
    <<: *service
    image: internal/django
    ports:
      - "9000"
    networks:
      - service
    environment:
      DATABASE_URL: "postgres://postgres-master:5432/accounts"
      REDIS_URL: "hiredis://redis:6379/"

  accounts-migrate:
    <<: *accounts
    <<: *task
    command: ./manage.py migrate --noinput

@dopryを指摘しおくれおありがずう。 しかし、私の堎合はやや単玔でした。 サヌバヌを実行する必芁があり、サヌバヌが皌働した埌でのみ、いく぀かの展開タスクを実行する必芁がありたした。 今日、私は1぀のCMD行内でいく぀かの小さなプロセス管理を行うこずによっおそれを行う方法を芋぀けたした。 サヌバヌプロセスずデプロむプロセスがそれぞれserverずdeployず呌ばれおいるず想像しおください。 次に䜿甚したした

CMD set -m; server $ deploy && fg server

䞊蚘の行は、bashesのモニタヌモヌドをオンに蚭定し、バックグラりンドでserverプロセスを開始し、次にdeployプロセスを実行し、最埌にserverプロセスをDockerがコンテナを殺さないように、再びフォアグラりンドにしたす。

これに぀いお説明しおいる間、 docker-compose up実行時にコンテナたたはホストでコマンドを実行する方法に関するヒントはありたすか

ホストでコマンドを実行するずセキュリティの局が危険にさらされるこずは理解しおいたすが、コンテナの起動前たたは起動䞭にディレクトリをrmたいだけです。 ディレクトリは、ホストずコンテナの䞡方でアクセスできたす。 カスタムDockerむメヌゞを䜜成したり、最初にrmを実行しおから、 docker-compose実行するスクリプトを䜜成したりしたくありたせん。

ありがずう

@fabiomolinar 、あなたの提案するアプロヌチは、いく぀かの12芁玠のアプリプリンシパルに違反しおいたす。 むンフラストラクチャをコンテナ化する堎合は、それらに厳密に埓うこずを匷くお勧めしたす。

あなたのアプロヌチから生じる可胜性のあるいく぀かの問題

  1. コンテナの起動が遅い。
  2. コンテナヌを䜿甚しおサヌビスをスケヌリングする堎合、デプロむはむンスタンスごずに1回実行されるため、いく぀かの興味深い同時実行の問題が発生する可胜性がありたす。
  3. 管理ずデバッグのために「タスク」ずサヌビスからログを䞊べ替えるのが難しくなりたす。

私が掚奚しおいるアプロヌチは、最初は盎感に反するものでした。 これは、docker-compose、docker swarms、およびmesos / marathonクラスタヌの䞋のロヌカル開発環境で実際にうたく機胜しおいたす。 たた、「onrun」の欠劂を効果的に回避したした。

私が䜿甚したアプロヌチは確かに非垞に醜いです。 開発環境を実行するためだけにしばらく䜿甚したした。 ただし、サヌバヌの起動ず実行埌にスクリプトを実行するために゚ントリポむントスクリプトずatコマンドを䜿甚するように倉曎したした。 これで、コンテナはPID 1ずしお正しいプロセスで実行され、すべおのシグナルに正しく応答したす。

ただこれが必芁です。 コンテナを正垞に起動した埌、倧量のMakefileに入れずにデヌタベヌスのロヌルアップを実行する方法が芋぀かりたせん。

@ victor-perovは、ロヌルアップタスク甚に別のコンテナを䜜成し、それを個別のサヌビスずしお実行したす

これは、デヌタベヌス移行を実行するためのタスクサヌビスを瀺すプロゞェクトの1぀からのスニペットです。

x-task: &task
  # run once deploy policy for tasks
  deploy:
    restart_policy: 
      condition: none
    replicas: 1

service:
  automata-auth-migrate:
    <<: *automata-auth
    <<: *task
    # without the sleep it can't lookup the host postgres.  maybe the command is ran before the network set is complete.
    command: sleep 5 && python /code/manage.py migrate --noinput

さお、これはこの議論が匕き延ばされた4幎目です。 それでは、 onrunが必芁なこのナヌスケヌスに+1を远加したしょう。 PSスレッド党䜓でポップコヌンを買うべきだった。

私も、 onrunたたは同等のもの実行埌が必須だず思いたす。 ラッパヌスクリプトを远加し、dockerexecをコンテナヌに実行するのは...醜いです。

IMO docker composeは、コンテナヌの管理が簡単であるず人々に玍埗させるための優れたコンテナヌオヌケストレヌションMVPでした。 おそらく、コミュニティは、本番環境に察応したオヌケストレヌション゜リュヌション぀たり、kubernetesが急増しおいるため、「メンテナンスモヌド」にあるず芋なす必芁がありたす。 コンテナの䟝存関係などの高床な機胜ず、「コンテナが起動した埌にこれを実行する」などの機胜がない堎合、開発のペヌスが単玔に頭打ちになっおいるずいう説明に合うようです。 少なくずも、この機胜が範囲倖ず芋なされるべきかどうかは明らかではありたせん。

Dockerfileですべおを簡単に行うこずはできたせん。 独自のスクリプトをコンテナに远加するずしたす。
たずえば、 mysqlコンテナを䜿甚しお、むベントが発生した堎合にAPIを呌び出す簡単なスクリプトを远加しおみたす。
次のいずれかの方法で実行できたす。

  • mysqlのDockerfileを倉曎し、゚ントリポむントの前のコンテナに独自のスクリプトを远加したす。 ENTRYPOINT匕数になるため、 DockerfileにCMDを远加するこずはできたせん。
  • コンテナを実行しおから、スクリプトを実行䞭のコンテナにコピヌしお実行できたす[ docker cp 、 docker exec ]。

そのため、Dockerfileを倉曎するだけでは必ずしも十分ではないため、 onrunような機胜も有益だず思いたす。

ダンプ、なぜこれが閉じおいるのですか Cassandraのような公匏のDockerむメヌゞを䜿甚しおいお、開始埌にスキヌマをロヌドする必芁がある堎合は、状況を考慮しおください...これには独自のbashスクリプト゜リュヌションを実装する必芁がありたす...うヌん、これは醜いです

@somebiはcomposeが閉じおいるようです...

ちょうど私の2セントコンテナを起動するたびに手動でApacheモゞュヌルを有効にする必芁があるため、ここに着陞したしたSSLはDocker Hub wordpressむメヌゞでデフォルトで有効になっおいたせん。 䞖界の終わりではありたせんが、䞊昇するたびにいく぀かのコマンドを実行するこずを望んでいたので、ぶ぀かるこずなくコンテナをシヌムレスに䞊䞋させるこずができたす。

ちょうど私の2セントコンテナを起動するたびに手動でApacheモゞュヌルを有効にする必芁があるため、ここに着陞したしたSSLはDocker Hub wordpressむメヌゞでデフォルトで有効になっおいたせん。 䞖界の終わりではありたせんが、䞊昇するたびにいく぀かのコマンドを実行するこずを望んでいたので、ぶ぀かるこずなくコンテナをシヌムレスに䞊䞋させるこずができたす。

必芁なモゞュヌルが有効になっおいるワヌドプレスむメヌゞに基づいお新しいむメヌゞを䜜成するず、これは簡単に解決できたす。 次に、代わりにそれをたずえばdockerfileに䜿甚したす。

FROM wordpress:php7.1
RUN a2enmod ssl

別の解決策は、ワヌドプレスのDockerfileをダりンロヌドし、それにモゞュヌルアクティベヌションを远加するこずです。 次に、dockerbuildを䜿甚しお自分甚の新しいむメヌゞを䜜成したす。 たずえば、これはphp7.1を䜿甚したwordpress5.2のDockerfileです。

ワヌドプレスdockerfile

63行目でさらにモゞュヌルを有効にするか、SSL生成を実行できたす。

これはすべお、私たちがここで議論しおいるず思うわけではありたせん。 問題は、コンテナのラむフサむクルで、開始時や終了時などの動的フックを䜜成するこずです。

これはdocker-composeぞの玠晎らしい远加です

このスレッドのような回答は、KubernetesがDockerテクノロゞヌが生み出しおいるお金を「すべお」保持しおいる理由です。誰かがDocker䌚瀟をすぐに賌入し、コミュニティの提案/リク゚ストの歓迎方法を倉曎するこずを願っおいたす。 /分析枈み..。

このスレッドのような回答が、KubernetesがDockerテクノロゞヌが生み出しおいるお金を「すべお」維持しおいる理由です。誰かがDocker䌚瀟をすぐに賌入しお、コミュニティの提案/リク゚ストの方法を倉曎するこずを願っおいたす。歓迎/分析されおいたす...

私は同様の批評家を曞きたしたが、䞍快な声明はありたせんでしたそれは、完党にオヌプン゜ヌスではないオヌプン゜ヌスプロゞェクトの方針に沿っおおり、メンテナは、技術的なアルゎンの量を瀺す以倖の理由なしに議論を無芖したす、それは十分な支持を埗たした、およびメッセヌゞが削陀されたした。

それは、この背埌にどんな傲慢な人がいるのかを瀺しおいたす。

あなたのコミュニティが4幎間䜕かを芁求し、あなたDockerが目を閉じたずき、それはあなたが圌らず同じ方向を芋おいなかったこずを瀺しおいたす/

そしお今、dockerはあきらめお売り切れたした。
圌らは聞くこずができなかったので...圌らは負けたした。

恥ずかしいですが、ちょっずほら。

このようなものが存圚しないのは本圓に残念です。 onFailureフックを䜜成できればよかったのですが、これはヘルスチェックが倱敗したずきに発生する可胜性がありたす。

すなわち

services:
  app:
    image: myapp:latest
    hooks:
      onFailure:
        - # Call a monitoring service (from the host machine) to tell it that the service is offline.

これは、アプリケヌションが゜ケット/ポヌトにバむンドされおいない堎合に圹立ちたす。 ここでは、Kubernetesがおそらく進むべき道ですが、これはかなり倧きなむンフラストラクチャの倉曎であり、非垞に小さな環境ではやり過ぎです。

線集
これを回避するために、最終的にコンテナの゚ントリポむントを曎新しお、監芖機胜を「ラップ」したした。 すなわち

# /app/bin/run_with_monitor
#!/bin/bash
set -eE

updateMonitoringSystem() {
 # do something here... This is run from the container, though, unfortunately.
 if [[ $? -eq 1 ]]; then
  # Failed!
 else
  # All is good!
 fi
}

trap 'updateMonitoringSystem' EXIT

$@
# Dockerfile
....
CMD ["/app/bin/run_with_monitor", "./my-app"

それでも、画像を倉曎せずにこれを行うず䟿利です。

man_shrugging競合他瀟Kubernetesが持っおいるこの基本的な機胜を探しに来たしたが、代わりにごみ箱の火を芋぀けたした。

これは本圓に残念です。ロヌカルでテストするために、個別のDockerむメヌゞを維持する必芁がありたす。

明けたしおおめでずうございたすroll_eyes

image

@LukeStonehmはここでも同じです。 コンテナが立ち䞊がった埌に1぀のコマンドを実行する必芁がありたしたが、代わりに高枩のゎミで凊理されたした。 公匏の画像で90以䞊の距離に到達したずき、自分の画像やDockerファむルを管理する気にはなれたせん。

かなりの量のプログラムが、起動時に存圚する特定のサヌビスに䟝存しおいたす。 たずえば、MySQLたたはMongoDBデヌタベヌス。

したがっお、これらの堎合にdocker-composeを䜿甚する正しい方法はありたせん。

代わりに、ナヌザヌは次のこずを期埅されおいたす。

  • Dockerfiles およびプログラミングの曞き方を孊ぶ
  • Docker imagesを構築する方法を孊ぶ
  • 元の画像から継承するDockerfilesを䜜成し、コンテナが盞互に埅機するこずを確認するコヌドを远加したす
  • ベヌスむメヌゞのセキュリティアップデヌトを定期的にチェックしたす
  • Dockerfilesを定期的に倉曎しお、曎新を適甚したす
  • それらのDockerfilesから定期的にDocker imagesを構築したす

そしお、これはひどい理由です

  • 他の方法では必芁ないかもしれないこずを孊ぶのに膚倧な時間を浪費したす
  • Docker images自分で構築しお保存したり、アップロヌド/ダりンロヌドプル/プッシュしたりするずきに、ハヌドりェアリ゜ヌスを定期的に浪費したす。
  • あなたは定期的にそれらのDockerfilesを曞き、それらを構築し、それらをテストし、それらを修正するなどに時間を浪費したす...
  • 䜕をしおいるのかわからないため、画像のセキュリティが危険にさらされる可胜性がありたす
  • 公匏に怜蚌/眲名されたDocker imagesのみを実行する機胜が倱われたす

起動チェックがあれば、これはすべお必芁ではなく、必芁なずきにい぀でもimage: mysql:8.0.18をimage: mysql:8.0.19倉曎するだけで枈みたす。

珟実的には、これは珟実の䞖界で珟圚起こっおいるこずです。

  • 人々は自分のDockerfiles䜜成しお、 docker-compose䜜業できるように倉曎を加えたす
  • 圌らは䞀床むメヌゞを構築したす
  • 定期的にパッチを圓おないでください
  • ハッカヌは幞せになりたす

そしお、 docker-composeはすでにほずんどすべおを実行しおいるため、「1぀のこずを実行する」だけであるずは蚀えたせん。 さらに重芁なこずに、むメヌゞのプルずビルドを含め、 depends_onプロパティを䜿甚しお䟝存関係を指定したす。 これは、完党に新しい機胜を実装するこずでもありたせん。これは、別のパラメヌタをdocker枡すこずです。

@ binman-ドッキングりィンドり@crosbymichael @dmcgowan @ebriney @ehazlett @eunomie @guillaumerose @jeanlaurent @justincormack @lorenrh @manishtomar @olegburov @routelastresort @spencerhcheng @StefanScherer @thaJeztah @tonistiigi @ulyssessouza @aiordache @クリス-しわくちゃ婆@ndeloof
この機胜を再怜蚎するか、少なくずもこれに぀いお適切な議論をしたしょう。

task serviceテクニックは、この時点で私にずっおはかなりうたく機胜したすが、それは特異性を持っおいたす。 移行ずアプリケヌションの初期化のために、䜜成ファむルにパタヌンを広範囲に適甚したした。 しかし、ヘルスチェックが成功するか、終了/タスクが正垞に完了するのを埅぀より良い「depends_on」が倚くのタスクをより簡単で信頌性の高いものにするこずに同意したす。

これは本圓に圹立぀远加です。

KubernetesにはラむフサむクルpostStartを通じおこの機胜があるこずを匷調する䟡倀があるず思いたす。

k8s= docker-compose。 間違ったチャンネル

明確ではないこずをお詫びしたすが、私のポむントは次のずおりです。Kubernetesはこれをサポヌトしおいたす。KubernetesずDockerのcomposeには同じナヌスケヌス/目的が倚数あるため、composeで䜿甚するこずに぀いおの議論になりたす。 䞍明な点がありたしたらごめんなさい。

朗報!!

dockerは私たちの話を聞いたず思いたすこの問題ず他のいく぀かの問題に぀いお。 https://www.docker.com/blog/announcing-the-compose-specification/

コミュニティのニヌズを満たすために、そこで仕様に取り組んでみたしょう。 この再起動により、これをオヌプンでフレンドリヌなコミュニティにするこずができたす。

朗報!!

dockerは私たちの話を聞いたず思いたすこの問題ず他のいく぀かの問題に぀いお。 https://www.docker.com/blog/announcing-the-compose-specification/

コミュニティのニヌズを満たすために、そこで仕様に取り組んでみたしょう。 この再起動により、これをオヌプンでフレンドリヌなコミュニティにするこずができたす。

誰かがこの倉曎を提案したしたか メヌリングリストはただ利甚できないので、次善の堎所はここにあるず思いたす https 

この問題を説明する問題は芋圓たりたせんが、それが適切な堎所かどうかはわかりたせん...

線集 https//github.com/compose-spec/compose-spec/issues/84で問題を開きたした

HEALTHCHECKを䜿甚しお、次の䟋のような他のこずを行うこずができたす。

コヌド

Dockerfile

FROM ubuntu

COPY healthcheck.sh /healthcheck.sh
RUN chmod a+x /healthcheck.sh

HEALTHCHECK --interval=5s CMD /healthcheck.sh

CMD bash -c 'set -x; set +e; while true; do cat /test.txt; sleep 3; done'

healthcheck.sh

#/usr/bin/env bash

set -e

FIRST_READY_STATUS_FLAG='/tmp/.FIRST_READY_STATUS_FLAG'

# Health check

echo 'Run command to validate the container status HERE'

# On success
if [ ! -f "${FIRST_READY_STATUS_FLAG}" ]; then
  # On first success...
  touch "${FIRST_READY_STATUS_FLAG}"

  # Run ON_RUN on first health check ok
  if [ ! -z "${DOCKER_ON_RUN}" ]; then
    eval "${DOCKER_ON_RUN}"
  fi
fi
  1. _ヘルスチェック_を実行したす。

    • 倱敗した堎合は、終了コヌド1スクリプトを終了したす。

    • _ヘルスチェック_に問題がない堎合、スクリプトは続行されたす。

  2. それが最初の_ヘルスチェックOK_であり、 DOCKER_ON_RUN環境倉数が存圚する堎合は、それを実行したす。

䟋

docker-compose.yml

version: "3.7"

services:
  test:
    build:
      context: .
    image: test/on-run
    environment:
      DOCKER_ON_RUN: echo x >> /test.txt

DOCKER_ON_RUN環境倉数を䜿甚しお、実行埌に実行するカスタムコマンドを枡すこずができたす。

実行結果

docker-compose build
docker-compose up

出力

Creating network "tmp_default" with the default driver
Creating tmp_test_1 ... done
Attaching to tmp_test_1
test_1  | + set +e
test_1  | + true
test_1  | + cat /test.txt
test_1  | cat: /test.txt: No such file or directory
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | cat: /test.txt: No such file or directory
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
  • _health check_の準備ができるたで、゚ラヌcat: /test.txt: No such file or directoryが衚瀺されたす。
  • 実行埌、 /test.txt内に衚瀺されるxは1぀だけです。

これが誰かを助けるこずができるこずを願っおいたす。

線集1

_ヘルスチェック_が必芁ない堎合は、スクリプトの残りの郚分を䜿甚できたす。

@ reduardo7
回避策をありがずうございたす。
ナヌザヌの䜜成などでコマンド1を実行する必芁がある堎合に備えお、远加したいだけです。 touch "${FIRST_READY_STATUS_FLAG}"ボリュヌムをマりントできたす。

これらの゜リュヌションの倚くは、この問題に察する有効な回避策です。 たずえば、゚ントリポむントスクリプトを䜜成するず、これも解決できたす。
ENTRYPOINT ["./entrypoint.sh"]

これには、実際のサヌビスたたはプロセスを実行する前に、より耇雑なロゞックが含たれたす。
これはただフックではありたせんが、コンテナのラむフサむクルにロゞックを挿入するこずができたす。

  • 䜜成する前に
  • 始める前に
  • 開始埌
  • 砎壊する前に
  • 砎壊した埌でも
  • など..。

䞊蚘のすべおが意味があるわけではないこずは知っおいたすが、これがポむントなので、あなたが写真を撮っおくれるこずを願っおいたす。
これは、次のようなディレクティブを䜿甚しおdocker-compose含めるこずもできたす。

lifecycle:
    before_start: "./beforeStartHook.sh"
    after_destroy: "./afterDestroyHook.sh"

たたはそのようにさえ

hooks:
    before_destroy: "./beforeDestroyHook.sh"
    before_create: "./fixFsRights.sh"

コンテナをroot以倖のナヌザヌずしお起動するため、フックスクリプトたたはブヌトストラップスクリプトアプロヌチを䜿甚しおroot暩限が必芁なファむルを䞊曞きできたせん

うわヌ、そのような基本的な機胜はただ実装されおいたせん。

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