docker-composeのstopとdownの違いを把握しておく

対象

  • docker-compose を雰囲気で使っていて down と stop の違いを把握してなかった人

経緯

永続化していないMySQLコンテナ を含んだ docker-compose.yml で 開発環境を(プライベートで)構成していました。(永続化したほうが良いでしょって話はおいておくとして)

dockerを業務で使いだして、 いつも docker-compose up -d で立ち上げて、 docker-compose down で落としていたので、 downしてupするとMySQLコンテナのデータベースが初期化されていました。

逆に up => DBを構成 => stop => up という手順を取ると MySQLコンテナのデータベースが初期化されずに残っている事がわかった。

違いを調べてみた

本題

公式ドキュメントとしては以下にあります。

docs.docker.com

docs.docker.com

docker-compose down

Stops containers and removes containers, networks, volumes, and images created by up.

この辺がそうですね。

「コンテナを停止し、docker-compose up で作成した コンテナ、ネットワーク、ボリューム、イメージを削除する」 というのが docker-compose down の振る舞いのようです。

docker-compose stop

Stops running containers without removing them.

この辺がそうですね。

「削除せずにコンテナを停止する」 というのが docker-compose stop の振る舞いでした。

down と stop の使い分けのポイントは?

公式ドキュメントをそのまま解釈すると、「コンテナなどを削除するかどうか」 という所が振る舞いの違いのポイントでした。

例えばプライベートでざっくり docker-compose の環境を作って勉強していて、「もうこのコンテナを起動させる事ないかな」ってときは down で消しきってしまえば良さそうですね〜。

逆に 頻繁に使っていて、めったにコンテナイメージが変わる事がないとかの場合は stop で良さそうだな、って所感を持ちました。

up と start

ちなみに stop で停止したコンテナは start で再度起動が出来ます。 でも up でだって起動ができます。

docs.docker.com

Builds, (re)creates, starts, and attaches to containers for a service. Unless they are already running, this command also starts any linked services

この辺かな。雰囲気ですけど、 まだ起動してなかったら、サービスを起動するよ 的な話っぽい。

まとめ

デフォルト stop で動かせばいいよねw

という事で もっと早くに知っておけばよかったな、という感じでしたw