コンテナーの自動起動

もくじ

Docker では リスタートポリシー というものを提供しています。 これはコンテナーが終了した際、あるいは Docker そのものが再起動した際に、自動的にコンテナーをリスタート (再起動) するかどうかを制御します。 リスタートポリシーはリンクづいているコンテナーを適切な順に再起動します。 Docker ではリスタートポリシーの利用を推奨しているため、プロセスマネージャーなどを用いてコンテナーを起動させることはやめてください。

リスタートポリシーは、dockerd コマンドの --live-restore フラグとは異なります。 --live-restore は Docker がアップグレードしている最中に、ネットワークやユーザー入力が遮断された状態であっても、コンテナーを起動し続けるためのものです。

リスタートポリシーの利用

コンテナーに対するリスタートポリシーの設定は、docker run コマンド実行時に --restart フラグを利用します。 --restart フラグには以下のいずれかの値を指定します。

フラグ内容説明
noコンテナーのリスタート (再起動) を自動的には行いません。(デフォルト)
on-failure[:max-retries]エラー発生によりコンテナーが終了した場合にリスタートします。マニフェストはゼロ以外のエラーコードです。任意指定として :max-retries オプションにより Docker デーモンがリスタートを繰り返す上限数を定めます。on-failure ポリシーはあくまでコンテナーがエラー終了したときに起動するものであって、デーモン再起動時には起動しません。
alwaysコンテナーが終了した場合に常にリスタートします。手動操作による終了を行うなら、Docker デーモンの再起動時またはコンテナー自体の手動再起動時にのみリスタートします。( リスタートポリシーの詳細 における 2 つめの中黒を参照してください。)
unless-stoppedalways と同様。ただしコンテナーが (手動その他により) 終了した場合、あるいは Docker デーモンが再起動した場合にはリスタートしません。

以下のコマンドは Redis コンテナーを起動するものであり、常にリスタートするように設定しています。 ただしコンテナーが明示的に停止された場合やデーモンが再起動された場合は除きます。

$ docker run -d --restart unless-stopped redis

以下のコマンドは実行中のコンテナー redis に対して、そのリスタートポリシーを変更するものです。

$ docker update --restart unless-stopped redis

以下のコマンドは全コンテナーをリスタートさせます。

$ docker update --restart unless-stopped $(docker ps -q)

リスタートポリシーの詳細

リスタートポリシーを利用するにあたっては以下をおさえておく必要があります。

  • リスタートポリシーは、コンテナーが正常起動した場合にこそ有用なものです。 この場合の正常起動とは、コンテナーが起動開始してから最低でも 10 秒が経過し、Docker がその監視をし始めたときを意味します。 これは起動することができないコンテナーが、再起動のループには陥らないようにする目的があります。

  • コンテナーを手動で終了した時点では、リスタートポリシーは無視され、Docker デーモンの再起動かコンテナーの手動による再起動のときに評価されます。 これは再起動ループを避ける目的です。

  • リスタートポリシーはコンテナーにのみ適用されます。 swarm サービスに対するリスタートポリシーを設定する場合は サービスリスタート関連のフラグ を参照してください。

フォアグラウンド実行中のコンテナーのリスタート

コンテナーをフォアグラウンドで実行している場合、そのコンテナーを終了すると、そこに接続していた CLI も同時に終了します。 これはコンテナーのリスタートポリシーがどのように設定されていても同じことです。 この動きは以下の例を通じて確認できます。

  1. Dockerfile を生成して、1 から 5 の数値を出力した後に終了するものとします。

    FROM busybox:latest
COPY --chmod=755 <<"EOF" /start.sh
echo "Starting..."
for i in $(seq 1 5); do
  echo "$i"
  sleep 1
done
echo "Exiting..."
exit 1
EOF
ENTRYPOINT /start.sh

  2. Dockerfile からイメージをビルドします。

    $ docker build -t startstop .

  3. そのイメージからコンテナーを実行します。 リスタートポリシーは always を指定します。

    コンテナーは数字の 1 から 5 を標準出力に表示し終了します。 これに合わせて、接続していた CLI も終了します。

    $ docker run --restart always startstop
Starting...
1
2
3
4
5
Exiting...
$

  4. docker ps を実行すると、リスタートポリシーのおかげでコンテナーは実行中、あるいは再起動が行われています。 ただし CLI セッションは終了したままです。 つまり最初のコンテナーとともに終了したということです。

    $ docker ps
CONTAINER ID   IMAGE       COMMAND                  CREATED         STATUS         PORTS     NAMES
081991b35afe   startstop   "/bin/sh -c /start.sh"   9 seconds ago   Up 4 seconds             gallant_easley

  5. 再起動後にそのコンテナーに対してターミナルを再度接続するには docker container attach コマンドを用います。 これは次にもう一度コンテナーが終了すれば、再度切断されます。

    $ docker container attach 081991b35afe
4
5
Exiting...
$

プロセスマネージャーの利用

Docker 外のプロセスが Docker コンテナーに依存しているといった場合、リスタートポリシーの利用が適当ではないことがあります。 その場合は代わりに systemd や supervisor といったプロセスマネージャーを用いることになります。

警告

Docker のリスタートポリシーとホストレベルのプロセスマネージャーを両方利用することは、衝突が発生するため避けてください。

プロセスマネージャーを用いる場合は、普段コンテナーを手動で起動する際に利用している docker start や docker service といったコマンドを用いて、そのコンテナーを起動するような設定を行います。 プロセスマネージャーの詳細については、個々のドキュメントを参照してください。

コンテナー内のプロセスマネージャーの利用

プロセスマネージャーはコンテナー内部においても起動することができ、プロセスの起動確認や(再)起動を行うことができます。

警告

これは Docker が関与するものではありません。 コンテナー内において稼働しているオペレーティングシステムのプロセスを監視するにすぎません。 Docker ではこの利用をお勧めしません。 それはプラットフォームに依存するものであり、Linux ディストリビューションのバージョンによっては異なるものかもしれないからです。