対象
- docker-compose を雰囲気で使っていて down と stop の違いを把握してなかった人
経緯
永続化していないMySQLコンテナ
を含んだ docker-compose.yml で 開発環境を(プライベートで)構成していました。(永続化したほうが良いでしょって話はおいておくとして)
dockerを業務で使いだして、 いつも docker-compose up -d
で立ち上げて、 docker-compose down
で落としていたので、 downしてupするとMySQLコンテナのデータベースが初期化されていました。
逆に up => DBを構成 => stop => up
という手順を取ると MySQLコンテナのデータベースが初期化されずに残っている事がわかった。
違いを調べてみた
本題
公式ドキュメントとしては以下にあります。
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
でだって起動ができます。
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