【Docker基礎】Dockerのデータの保存

　Docker コンテナは「作っては捨てる」運用が基本ですが、コンテナ内に保存していたデータまで捨ててしまうと不便になります。そこで重要となるのが、物理マシン（ホスト）のディスクにデータをマウントして保管するという方法です。ここでは、コンテナ内部のデータをどのように扱えばよいのか、マウントの仕組みとあわせて解説します。

コンテナ内データの行方

コンテナを破棄するとデータも消える
・コンテナ内のファイルはコンテナと運命をともにする。
・コマンドや実験で更新したファイルも、コンテナ削除とともに消えてしまう。
「データが消えては困る…」
・アプリケーションのデータやログ、設定ファイルなどが失われると致命的
・特にデータベースなどの永続化が必要な情報は別途対策が必要

ホストにマウントしてデータを保存する

　そこで多くのケースで採用されるのが、ホスト側（物理マシン）のディスクにデータをマウントする方法です。

マウントとは、外付けHDDやUSBメモリをパソコンにつなぐように、Docker コンテナとホスト側のフォルダを紐づけて読み書き可能にすること。
コンテナではあくまで「マウントされたディレクトリ」を通してファイルの読み書きを行い、実体はホストのディスクに保存される。

ポイント
コンテナを破棄しても、データはホスト側に残る。
Docker が動かなくなっても、物理マシン上にファイルが残るので安全。
複数コンテナで同じマウント先を共有し、同じデータを読み書きできる。

「作っては捨てる」スタイルとデータの分離

　Docker の「作っては捨てる」運用において、**アプリケーションや OS の部分（コンテナ）とデータや設定ファイル（ホストなどの外部ストレージ）**を分離するのが鉄則です。

OS やソフトウェア → コンテナを量産・入れ替え
データや設定 → ホスト上に永続化して、コンテナが消えても生き残る

例： WordPress + MySQL

WordPress や MySQL はコンテナで起動しておき、
データベースファイルやアップロードファイル はホスト側のディスクにマウント

　コンテナのバージョンアップや再作成にともなって、データが消えてしまうリスクを回避できるうえ、必要なソフトウェアのアップグレードも気軽に行えるようになります。

マウントの手段

Bind Mount（バインドマウント）
・ホスト上の任意のディレクトリをコンテナ内に紐づける。
・使い慣れたパスを直接マウントできるが、ホスト側のディレクトリ構成がコンテナに依存しやすい
Docker Volume（ドッカーボリューム）
・Docker が管理する専用の領域を作成してコンテナから利用
・Volume 名で管理しやすく、コンテナの実行環境を分離できる。
・Docker Swarm や Kubernetes と連携する際にも便利

注意点

重要なデータがコンテナ内に残っていないか要確認
・開発中や実験中にコンテナ内部にファイルを残したまま破棄しないように
本番運用でのバックアップ戦略
・ホスト上に保存しているとはいえ、物理マシンが壊れたときのために定期的なバックアップが必須
権限やセキュリティ
・マウントするとコンテナからホストを操作できる場合があるため、不要なマウントは行わない。
・ホスト側のディレクトリに十分な権限設定をしておく。

まとめ

コンテナを破棄すると内部データは消える → 永続化が必要なデータはホスト側にマウント
「作っては捨てる」運用 のために、データとアプリ（コンテナ）を分離 する発想が大切
マウント方法としては Bind Mount や Docker Volume などがある。
大切なデータをどこに保管するか、どのような権限で管理するかを計画的に考える。

　具体的にどのようなコマンドや設定ファイル（Dockerfile, Docker Compose など）を使ってマウントを行い、データを守るかについては、6章の「コンテナの応用的な使い方」、7章の「Docker Compose」で詳しく解説します。