web-dev-qa-db-ja.com

Docker-composeで単一のコンテナを再起動する方法

Redis、postgres、api、workerの4つのコンテナを含むdocker-compose.ymlファイルがあります。

ワーカーの開発中、私は変更を適用するためにしばしばそれを再起動する必要があります。他のコンテナを再起動せずにコンテナ（たとえばworker）を再起動する良い方法はありますか？

dockerdocker-compose
228
Bryan Chen

それは非常に簡単です：コマンドを使用します：

docker-compose restart worker

あなたはコンテナを殺す前に停止を待つ時間を（秒単位で）設定することができます

docker-compose restart -t 30 worker

それで全部です ！

282
bmkrio

単一のノードを再起動するための他の答えはdocker-compose restart workerです。それはそのコンテナをバウンスしますが、たとえあなたがそれを別々に再構築したとしても、いかなる変更も含みません。手動でstop、rm、create、およびstartを使用できますが、もっと簡単な方法もあります。

コードを更新した場合は、次の手順でビルドとリロードを1ステップで実行できます。

docker-compose up --detach --build

これは最初に、変更されたコードから画像を再構築します。キャッシュが再利用されてから変更がない場合は高速です。そしてそれは変更されたコンテナを置き換えるだけです。ダウンロードした画像が古くなっている場合は、上記のコマンドの前に次のように入力できます。

docker-compose pull

変更された画像を最初にダウンロードするには（上記のupのようなコマンドを実行するまでコンテナは再起動されません）。初期停止をする必要はありません。

そして、これを単一のサービスに対してのみ行うには、指定したいサービスを使ってupまたはpullコマンドを実行します。

docker-compose up --detach --build worker

これが最初のオプションの簡単な例です。Dockerfileはコードの頻繁に変化する部分を終わり近くに保つように構成されています。実際、そのファイルはほとんど変更されないので、要件はpip installに対して別々に引き込まれます。そして、nginxとredisのコンテナは最新のものだったので、再起動されませんでした。プロセス全体の合計時間は6秒未満でした。

$ time docker-compose -f docker-compose.nginx-proxy.yml up --detach --build
Building counter
Step 1 : FROM python:2.7-Alpine
 ---> fc479af56697
Step 2 : WORKDIR /app
 ---> Using cache
 ---> d04d0d6d98f1
Step 3 : ADD requirements.txt /app/requirements.txt
 ---> Using cache
 ---> 9c4e311f3f0c
Step 4 : RUN pip install -r requirements.txt
 ---> Using cache
 ---> 85b878795479
Step 5 : ADD . /app
 ---> 63e3d4e6b539
Removing intermediate container 9af53c35d8fe
Step 6 : EXPOSE 80
 ---> Running in a5b3d3f80cd4
 ---> 4ce3750610a9
Removing intermediate container a5b3d3f80cd4
Step 7 : CMD gunicorn app:app -b 0.0.0.0:80 --log-file - --access-logfile - --workers 4 --keep-alive 0
 ---> Running in 0d69957bda4c
 ---> d41ff1635cb7
Removing intermediate container 0d69957bda4c
Successfully built d41ff1635cb7
counter_nginx_1 is up-to-date
counter_redis_1 is up-to-date
Recreating counter_counter_1

real    0m5.959s
user    0m0.508s
sys     0m0.076s
121
BMitch

変更を加えてサービスを再起動するには、次の手順を実行します。

docker-compose stop -t 1 worker
docker-compose build worker
docker-compose create worker
docker-compose start worker
18
Jeff

次のコマンド

docker-compose restart worker

コンテナを停止して起動するだけです。すなわち、docker-compose.xmlから変更を読み込まずに

STOPはPCで休止状態に似ています。したがって、stop/startは設定ファイルに加えられた変更を探しません。コンテナのレシピ（docker-compose.xml）からリロードするには、コンテナを削除して作成する必要があります（PCの再起動と同様）。

だからコマンドは以下のようになります

docker-compose stop worker       // go to hibernate
docker-compose rm worker        // shutdown the PC 
docker-compose create worker     // create the container from image and put it in hibernate

docker-compose start worker //bring container to life from hibernation
8
Mr Coder

単純な 'docker'コマンドは、 'worker'コンテナについては何も知りません。このようなコマンドを使う

docker-compose -f docker-compose.yml restart worker

5
Shtlzut

Docker-composeファイルを使ってサービスを再起動する

docker-compose -f compose-file.yml restart servieName

ファイル名がdocker-compose.ymlでサービスがworkerの場合

docker-compose restart worker

ファイル名sample.ymlおよびserviceがworkerの場合

docker-compose -f sample.yml restart worker

これです

4
Jinna Balu

コンテナを再起動

コンテナを再起動するだけの場合：

docker-compose restart servicename

このコマンドは「名前でコンテナを再起動するだけ」と考えてください。これはdocker restartコマンドと同等です。

注意事項：

  1. ENV変数を変更した場合、コンテナでは更新されません。あなたはそれを止めて、もう一度始めなければなりません。または、単一コマンドdocker-compose upを使用して変更を検出し、コンテナを再作成します。

  2. 他の多くの人が言ったように、docker-compose.ymlファイル自体を変更した場合、単純な再起動ではそれらの変更は適用されません。

  3. ビルド段階でコンテナ内にコードをコピーする場合（DockerfileまたはADDコマンドを使用してCOPYで）、コードを変更するたびにコンテナを再構築する必要があります（docker-compose build ）。

コードとの相関

docker-compose restartは、次のようにdocker-compose.ymlのボリュームディレクティブによってコンテナにマップされたパスを取得する場合、完全に正常に動作するはずです。

services:

  servicename:
    volumes:
      - .:/code

しかし、ライブコードのリロードを使用することをお勧めします。これはおそらく、DEBUGモードで選択したフレームワークによって提供されます（または、選択した言語で自動リロードパッケージを検索できます）。これを追加すると、コードを変更した後に毎回コンテナを再起動する必要がなくなり、代わりに内部でプロセスが再ロードされます。

0
Lev Rubel