web-dev-qa-db-ja.com

「再起動:常に」ポリシーはdocker-composeでどのように機能しますか?

次のように、PostgreSQLと私のアプリケーションを含むdocker composeファイルがあります。

version: '3'

services:
  postgresql:
    image: postgres:9.6.6
    ports:
      - 9932:5432
    expose:
      - "5432"
    environment:
      - POSTGRES_PASSWORD=pass
    restart: always
    volumes:
      - /data:/var/lib/postgresql/data

  myapp:
    image: myapp
    links:
      - postgresql
    depends_on:
      - "postgresql"
    restart: always
    ports:
      - "5000:5000"

問題は、コンテナを強制終了(restart: alwaysを使用してアプリのクラッシュをシミュレート)したときにdocker killポリシーが機能せず、Docker-composeがExit Code 137です。 restart: on-failureポリシーを使用すると、同じ動作が見られます。 docker-composeのバージョン23の動作は同じです。私のシステムはUbuntu Server 16.04 x64です。

私の質問は:

  1. Docker-composeがクラッシュした(killed)コンテナーを再起動しないのはなぜですか?
  2. 再起動ポリシーが機能するかどうかを確認するにはどうすればよいですか?
26
Marcin Zablocki

Docker killを使用すると、Dockerがコンテナーを再起動しないため、これは予想される動作です。「コンテナーを手動で停止した場合、Dockerデーモンが再起動するかコンテナーが手動で再起動されるまで、コンテナーの再起動ポリシーは無視されます。これは、別の試みです。再起動ループ " (reference)

Docker stopまたはdocker killを使用する場合、コンテナーを手動で停止しています。再起動ポリシーに関するいくつかのテストを行うことができます:Dockerデーモンの再起動、サーバーの再起動、コンテナー内のCMDの使用、出口の実行...

たとえば、再起動ポリシーでデプロイされたコンテナーを強制終了すると、コード137で終了したことがわかりますが、docker ps -aに従って再起動されず、終了したままになります。

[root@andromeda ~]# docker ps --all
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                        PORTS               NAMES
819d1264c30a        redis:Alpine        "docker-entrypoint..."   3 minutes ago       Exited (137) 34 seconds ago                       keepalive_redis_1

しかし、デーモンを再起動すると...

[root@andromeda ~]# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
819d1264c30a        redis:Alpine        "docker-entrypoint..."   30 minutes ago      Up 2 seconds        6379/tcp            keepalive_redis_1

再起動ポリシーで設定されたコンテナーは再起動します。これはドキュメントに書かれているとおりです。故意にコンテナーを停止し、Dockerが再起動を防ぐ方法を求めているため、再起動ポリシーをテストする方法はdocker killではありません。ループ、あなたがそれを殺すなら、あなたは本当にそれを殺したいのです。

異なるバージョンで同じ動作を示す次のリンクが貴重であることがわかりました(そのため、バグではなく期待される動作です)。

22
Miguel A. C.