はじめに（Dockerは「動かす」より「守る」が難しい）
第4回ではDocker Composeを使い、Web＋DBのような構成をまとめて起動できるようになりました。
ここまで来ると、Dockerは「とりあえず動く」状態になります。
しかし、業務で本当に困るのは次の瞬間です。
- ある日突然、DBが初期化された
- ログが見つからず原因調査ができない
- データのバックアップがなく復旧できない
- ディスクがいっぱいになってサーバーが止まる
Dockerは便利ですが、運用の基本を押さえないと、事故が起きやすい道具でもあります。
そこで最終回では、Docker入門の締めとして
「最初に覚えるべき運用の型」を整理します。
第5回のゴール
この記事のゴールは、以下の状態になることです。
- データが消えない構成を作れる（ボリューム）
- ログを確認できる（調査できる）
- 最低限のバックアップが取れる（復旧できる）
- 不要なものを削除できる（ディスクを守れる）る
Dockerの運用は奥が深いですが、最初はこの4点だけで十分です。
ボリューム：データを守る最重要ポイント
Dockerで最も重要なのは、まずこれです。
- コンテナは「消して作り直せる」もの
- データは「消えたら終わる」もの
この2つを分けて管理する必要があります。
なぜボリュームが必要なのか
コンテナは、次のような操作で簡単に消えます。
- docker compose down
- docker rm
- docker system prune
このとき、DBのデータがコンテナ内部に入っていると、
コンテナと一緒にデータが消えることがあります。
そのため、DBには必ずボリュームを使います。
Composeでのボリューム設定例
以下はMariaDBの典型的な設定です。
services:
db:
image: mariadb:11
environment:
MARIADB_ROOT_PASSWORD: rootpass
MARIADB_DATABASE: appdb
volumes:
- dbdata:/var/lib/mysql
volumes:
dbdata:
この dbdata が「データの保存場所」です。
ボリュームができているか確認する
次のコマンドで確認できます。
docker volume lsボリュームが見えていれば、基本はOKです。
ログ：調査できないシステムは運用できない
Docker運用で次に重要なのがログです。
アプリが止まったとき、最初に見るべきものはログです。
Composeでログを見る
以下で「全サービスのログ」が見られます。
docker compose logs -f特定サービスだけ見るならこうです。
docker compose logs -f web
docker compose logs -f dbdocker logsとの違い
初心者が混乱しやすい点ですが、
- docker logs は「コンテナ単体」
- docker compose logs は「Compose単位」
という違いがあります。
Composeを使っているなら、基本は docker compose logs でよいです。
ログが増えすぎる問題
Dockerのログは、放置すると増え続ける場合があります。
業務で長期間動かす場合は、ログの上限を設定します。
例：
services:
web:
image: nginx:latest
logging:
options:
max-size: "10m"
max-file: "3"
これにより、ログが肥大化してディスクを圧迫する事故を減らせます。
バックアップ：最初の一歩（これだけはやる）
Docker運用で「最初にやるべきバックアップ」は、難しくありません。
ポイントは次の考え方です。
- DBは「SQLダンプ」でバックアップする
- ファイルは「ボリューム」ごとに退避する
DBのバックアップ（mysqldump）
MariaDBの場合、よく使うのは mysqldump です。
Compose構成なら、次のように実行できます。
docker compose exec db mysqldump -u root -p appdb > backup.sql実行するとパスワード入力が求められます。
この backup.sql が復旧用のファイルです。
DBの復元（リストア）
復元は以下です。
cat backup.sql | docker compose exec -T db mysql -u root -p appdbこれができるだけで、万が一の事故で復旧できる確率が上がります。
ボリューム自体のバックアップ（最小構成）
「とにかく最初の一歩」としては、
ボリュームの中身をコピーする
という方法もあります。
Dockerにはボリュームの中身を直接見る仕組みがあるため、
バックアップ用のコンテナを一時的に起動してコピーします。
ただし、初心者の段階では
- DBはmysqldump
- ファイルはGit管理（可能な範囲）
という方針が現実的です。
ディスクを守る：不要なものを消す
Dockerは便利ですが、使い続けるとディスクを圧迫します。
理由は単純で、
- 使わなくなったイメージ
- 止めたコンテナ
- 使われないネットワーク
- ビルドのキャッシュ
が残り続けるためです。
まず使用量を確認する
以下で、Dockerがどれくらい容量を使っているか確認できます。
docker system df不要なものを削除する（安全寄り）
以下は比較的安全な削除です。
docker image prune使われていないイメージだけが消えます。
強めに掃除する（注意）
以下は強力です。
docker system prune停止中コンテナや未使用のネットワークなどが消えます。
ただし、状況によっては「後で必要だったもの」も消えます。
業務では、実行前に内容を理解してから使うのが安全です。
再起動で勝手に立ち上がる設定（業務で重要）
業務では、サーバー再起動後にコンテナが自動で起動することが重要です。
Composeでは以下を設定します。
services:
web:
image: nginx:latest
restart: unless-stopped
よく使う値は次の2つです。
- no：自動再起動しない（初期値）
- unless-stopped：止めない限り再起動する（業務向き）
Docker運用の最小チェックリスト
最後に、入門者が「最低限これだけ押さえる」ためのチェック項目です。
ボリューム
- DBには必ずボリュームがある
- downしてもデータが残ることを確認した
ログ
- docker compose logs が使える
- どのサービスが落ちているか判断できる
バックアップ
- mysqldumpでSQLを取れる
- SQLから復元できる
ディスク
- docker system df を知っている
- prune系コマンドの存在を知っている
次回予告（続編の方向性）
ここまでで、Docker入門（全5回）は一区切りです。
続編として、CI/CD（自動テスト・自動デプロイ）やKubernetes入門といったテーマを取り上げたいと思います。
