最初に
本記事「Dockerコンパクトマニュアル」は4項目で構成されております。
他の記事はこちらです。
| 投稿番号 | サブタイトル及びアクセス先 |
|---|---|
| 1 | 初歩・基本コマンド |
| 2 | マウントとデータ永続化 (＊本記事） |
| 3 | docker-compose |
| 4 | カスタムイメージを作成する |
この記事の目的
前回記事からの続きです。
今回はコンテナを使う上で避けて通れないマウント、volume、
データ永続化についてまとめます。
重要
今回は大事です。私は身を持って、マウントと永続化を知らずに後悔した事があります。
しっかりマウント・永続化を行って快適なコンテナ環境を構築してみて下さい。
コンテナデータの永続化
コンテナ内のデータはコンテナを破棄すると失われてしまいます。
試験動作などで使い捨てするなら大丈夫ですが、Databaseなどで使う分にはデータ抹消は避けたい事態です。
コンテナ内で失ってはいけないデータはコンテナの外に出して、コンテナが外を見にいく設定が必要です。
実行システム ＝ コンテナ内
取得データ・更新データ ＝ コンテナ外
のイメージでいいと思います。
このコンテナ外に出す作業をマウントを使って行います。
マウントの種類
マウントには２種類あります。どちらが優れているのかではなく、
扱う内容によって使い分けが必要であると思います。
| マウントの種類 | マウント先 | 推奨される使用方法 |
|---|---|---|
| ボリューム | Docker Engine上で確保した領域 | Dockerコンテナから見せたくないデータ データベースのデータ等 |
| バインド | Docker Hostのディレクトリ | Docker Hostのファイルをコンテナに見せたい時 設定ファイルの受け渡しデータ 変更を即座に反映したいデータ |
ボリューム作成のコマンド
ボリュームはdocker volume のコマンドで作成・リスト表示・削除が行えます。
inspectを使えばvolumeのMountpointで保存先がわかります。
| サブコマンド | 内容 | 利用例 |
|---|---|---|
| create | ボリューム作成 | docker volume create --name 'ボリューム名' |
| inspect | ボリュームの詳細内容確認 | docker volume inspect 'ボリューム名' |
| ls | ボリュームのリスト | docker volume ls |
| prune | マウントされていないボリューム全削除 | docker volume prune |
| rm | ボリューム削除 | docker volume rm 'ボリューム名' |
マウントの設定について
マウントの設定（docker runと組み合わせての使用等）ですが、
-vまたは--mountフラグで設定を行います。
今までは-vが使われる事が多く本や参考資料でも記述が多いですが、
--mountを使った方がいいと思われます。
理由として
1.ボリュームが存在しない場合勝手に作成がされてしまう。
下記は公式サイトからの抜粋記述ですが、
-vの場合、万一タイプミスしてしまった際には新規にボリュームが作成され、
以前のデータが見えないというエラーが発生します。
このエラーが発生し開発を進めた場合、後で気づいた際対応に苦慮すると思います。
それに対して--mountでは存在しない場合はエラーを返すので安心です。
-v または --volume を使ってファイルやディレクトリをバインドマウントした際に、そのファイルやディレクトリが Docker ホスト上にまだ存在していなかった場合、-v はそのマウントエンドポイントを生成します。 その場合には常にディレクトリとして生成されます。
--mount を使ってファイルやディレクトリをバインドマウントした際に、そのファイルやディレクトリが Docker ホスト上に存在していなかった場合、Docker はそのファイルやディレクトリを自動的に生成することはしません。 かわりにエラーが出力されます。
2.バインドマウントかボリュームマウントかわかりづらい
-vでの設定
-v /home/ubuntu/***:/usr/local/*** バインドマウント
-v mysqlvolume:/var/lib/mysql ボリュームマウント
上記の差は最初の/があるかないかで、わかりづらい
--mount
--mount type=bind,src=/home/ubuntu/***.dst=/usr/local/*** バインドマウント
--mount type=volume,src=mysqlvolume,dst=/var/lib/mysql ボリュームマウント
--mountでは typeで bindまたはvolumeマウントを、
src=sorce（マウント元）,dst=destination（マウント先）でどこのデータをどこにマウントするか指定
こちらでの運用の方が間違いが少なくなると思われます。
データのバックアップ
バインドマウントですとバックアップは簡単ですが
（ホストに存在する為、そのままデータコピー等で対応できます。）
volumeマウントですとバックアップは作業が必要となります。
先にバックアップ用のサンプルコマンドを下記に記載します。
docker run --rm --mount type=volume,src=*****,dst=/src --mount type=bind,src="$PWD",dst=/dest busybox tar czf /dest/backup.tar.gz -C /src .
内容を順番に見ていきます。
-
docker run --rmで実行後に破棄 -
--mount type=volume,src=*****,dst=/srcで busyboxの/srcにvolumeマウントの実行指定 -
--mount type=bind,src="$PWD",dst=/destで busyboxの/destにbindマウントの指定
"$PWD"でDockerホストのカレントディレクトリを指定 - busybox で軽量Linuxの稼働
- tar（アーカイブファイルを扱うためのコマンド）+gzfでgz形式のファイル作成を/srcから/destにコピー
- PWDでバインドマウントされているのでカレントディレクトリに書き出される
以上でボリュームのバックアップが完了します。
上記が１つのバックアップ方法ですが
この方法では バックアップ先のボリューム名 を知っている必要があります。
多くのコンテナ管理の際にはどのコンテナがどのボリュームを使っているのか把握は難しいと思います。
その際には
volumes-from を使用します。
--volumes-fromはコンテナを起動する時に、
別のコンテナマウント情報を引き継いで同じ設定のマウントを実行します。
バックアップ対象をボリューム名ではなくて、コンテナのディレクトリ名で指定できるので
コンテナのディレクトリがどのボリュームにマウントされているか意識する必要がありません。
データバックアップの際には非常に便利です。
サンプルコード
docker run --rm --volumes-from {{コンテナ名}} -v "$PWD":/dest busybox tar czf /dest/backup.tar.gz -C {{対象アドレス}} .
1.volumes-fromの指定
2.busyboxを起動しコンテナをバックアップする
以上２ステップで簡単です。
またボリュームを使用する場合は データボリュームコンテナ を設けた方がいいそうです。
データボリュームコンテナはコンテナ活動としては主だった稼働は行わず、
必要なディレクトリだけをマウントしたものです。
このデータボリュームコンテナは主だった稼働はしませんが
1.ボリュームのマウント先を意識せずマウント設定を使用できる
2.データボリュームコンテナでボリュームのマウント情報が管理できるのでバックアップ対象が明確化される
という利点があり、活用されているそうです。
バックアップのリストア
リストアはボリュームバックアップと反対の対応となります。
まずはvolumeを作成します。
docker volume create *****
その上でデータバックアップと逆向きにコマンドを入力します。
docker run --rm --mount type=volume,src=*****,dst=/dest --mount type=bind,src="$PWD",dst=/src busybox tar xzf /src/backup.tar.gz -C /dest
- リストア先のボリュームを/destにボリュームマウント
- カレントディレクトリを/srcにバインドマウント
- tar xzfで展開
- リストアされたボリュームをマウントすればデータを再度利用できます。
（コマンド掲載省略）