Docker の実践の理解から基礎となる原則へ (7) | Docker ストレージボリューム

ここに画像の説明を挿入します

序文

そこで、ブロガーが役立つ情報が満載のコラムをいくつか紹介します。

1つ目はブロガーの質の高いブログのまとめです。このコラムのブログはどれもブロガーが丁寧に書いており、役立つ情報が満載です。皆様のお役に立てれば幸いです。

質の高いブログまとめ

そして、ブロガーが最近最も時間を費やしているコラム「Docker の実現から実践、そして基礎原理まで」ですので、ぜひ注目していただければと思います。

Docker は認識から実践、そして基礎となる原則へ

第 7 章 - Docker ストレージボリューム

1. Dockerボリュームの紹介

参考：ビット就職クラス

1.1 ストレージボリュームとは何ですか?

ストレージボリュームは、ホストのローカルファイルシステムに存在するディレクトリと、コンテナ内のファイルシステム上のディレクトリとの間にバインディング関係を直接確立するものである。これは、コンテナ内のこのディレクトリにデータを書き込むと、コンテナはそのコンテンツを、コンテナにバインドされているホスト上のディレクトリに直接書き込むことを意味します。コンテナーにバインドされているホスト上のディレクトリはストレージボリュームと呼ばれます。ボリュームの本質はファイルまたはディレクトリであり、デフォルトのジョイントファイルシステムをバイパスして、ファイルまたはディレクトリの形式でホスト上に直接存在できます。

ホストの /data/web ディレクトリは、コンテナ内の /container/data/web ディレクトリにバインドされています。コンテナ内のプロセスがこのディレクトリにデータを書き込むと、データはコンテナをバイパスして、ホストディレクトリに直接書き込まれます。ファイルシステムはホストのファイルシステムとの関連付けを確立するため、データベースコンテンツをホストとコンテナ間で共有でき、コンテナがホスト内のコンテンツに直接アクセスできるようになり、ホストはコンテナにコンテンツを書き込むこともできます。コンテナとホストのデータの読み書きは同期します。

1.2 ストレージボリュームが必要な理由

1.2.1 データ損失の問題

コンテナは一般に、ビジネスタイプに応じて 2 つのカテゴリに分類できます。

ステートレス (データを永続化する必要がない)
ステートフル (データを永続化する必要がある)

明らかに、コンテナーはステートレスアプリケーションに優れています。永続化データのないコンテナーのルートディレクトリのライフサイクルはコンテナーのライフサイクルと同じであるため、コンテナーファイルシステムの本質は、ミラーレイヤーの上に作成される読み取り/書き込みレイヤーです。実行中のコンテナはこの読み取り/書き込みレイヤーに存在します。コンテナが削除されると、コンテナ内の読み取り/書き込みレイヤーも消えます。コンテナーは、コンテナーをすぐに使用でき、任意にスケジュールできるように、すべてのビジネスが可能な限りステートレスのままであることを望んでいますが、実際のビジネスには、MySQL などのステートフルビジネスや、カフカ。したがって、ステートフルビジネスのニーズを解決するために、Docker はボリュームの概念を提案しました。

1.2.2 パフォーマンスの問題

UnionFS は一般に、変更や削除などに対して非常に非効率的です。永続ストレージを実装する際に、Redis などの比較的高い I/O 要件を持つアプリケーションの場合、基盤となるストレージのパフォーマンス要件は比較的高くなります。

1.2.3 ホストとコンテナが相互にアクセスするのは不便

ホストがコンテナにアクセスするか、コンテナへのアクセスはdocker cp次の方法で完了する必要があります。

1.2.4 コンテナとコンテナの共有が不便

2. ストレージボリュームの分類

現在、Docker では、ホストからコンテナーにデータをマウントする 3 つの方法が提供されています。

/var/lib/docker/volumesボリュームドッカーは、デフォルトでホストの (変更した) ディレクトリにマップされるボリュームを管理します。コンテナ内のコンテナのマウントポイントを指定するだけでよく、バインドされたホストの下のディレクトリはコンテナエンジンデーモン自体によって決定されます。空のディレクトリを作成するか、既存のディレクトリを使用して、ストレージボリュームとのストレージ関係を確立します。この方法により、ボリュームを使用する際のユーザーの結合関係が大幅に軽減されます。欠点は、ユーザーが使用するディレクトリを指定できないことと、一時的なストレージが使用されないことです。より適切な;
バインドマウントは、データボリュームをバインドし、ホスト上の指定されたパスにマップします。ホスト上のパスは、特定のパスとして手動で指定する必要があります。コンテナ内でも、特定のパスを指定する必要があります。2 つの既知のパスが関連付けられています。
tmpfs マウントの一時データボリュームはホストメモリにマップされます。コンテナーの実行が停止すると、tmpfs マウントは削除され、データは失われます。高性能の一時データストレージに使用されます。

3. ボリュームボリュームの管理

3.1 ボリュームコマンド一覧

注文	関数
`docker volume create`	ストレージボリュームの作成
`docker volume inspect`	ストレージボリュームの詳細を表示する
`docker volume ls`	ストレージボリュームのリストを表示する
`docker volume prune`	無駄なデータボリュームをすべてクリーンアップする
`docker volume rm`	ボリュームの削除および使用中のボリュームは削除できません。

3.2 docker ボリュームの作成

キーパラメータ

-d, --driver ：指定驱动，默认是 local
--label ：指定元数据

ここに画像の説明を挿入します

パラメーターを指定しないでください。これはシステムによって与えられるランダムな名前です。

もちろん、ホストマシン上のどのディレクトリにマウントされているかを確認することもできます。

[root@ALiCentos7:~]$ docker volume inspect fd8f7ab68c681a1651faff71a2da89c8b040a1bd0b58c285206e2488cfd9d306
[
    {
    
    
        "CreatedAt": "2023-09-19T18:54:13+08:00",
        "Driver": "local",
        "Labels": {
    
    
            "com.docker.volume.anonymous": ""
        },
        "Mountpoint": "/data/var/lib/docker/volumes/fd8f7ab68c681a1651faff71a2da89c8b040a1bd0b58c285206e2488cfd9d306/_data",
        "Name": "fd8f7ab68c681a1651faff71a2da89c8b040a1bd0b58c285206e2488cfd9d306",
        "Options": null,
        "Scope": "local"
    }
]
[root@ALiCentos7:~]$

名前を付けて作成します。

[root@ALiCentos7:~]$ docker volume create myboltest1
myboltest1
[root@ALiCentos7:~]$ docker volume ls
DRIVER    VOLUME NAME
local     fd8f7ab68c681a1651faff71a2da89c8b040a1bd0b58c285206e2488cfd9d306
local     myboltest1
[root@ALiCentos7:~]$

3.3 Docker ボリューム検査

docker volume inspect [OPTIONS] VOLUME [VOLUME...]

パラメータ

-f：指定相应个格式, 如json

3.4 ドッカーボリューム ls

パラメータ。

--format：指定相应个格式，如 json,table
--filter,-f: 过滤
-q: 仅显示名称

ここに画像の説明を挿入します

3.5 ドッカーボリューム rm

パラメータ。

-f, --force : 强制删除

3.6 Docker ボリュームのプルーン

未使用のローカルボリュームをクリーンアップします。

パラメータ。

--filter : 过滤
-f, --force : 不提示是否删除

[root@ALiCentos7:~]$ docker volume ls
DRIVER    VOLUME NAME
local     fd8f7ab68c681a1651faff71a2da89c8b040a1bd0b58c285206e2488cfd9d306
local     myboltest1
[root@ALiCentos7:~]$ docker volume prune 
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
fd8f7ab68c681a1651faff71a2da89c8b040a1bd0b58c285206e2488cfd9d306

Total reclaimed space: 0B
[root@ALiCentos7:~]$ docker volume ls
DRIVER    VOLUME NAME
local     myboltest1
[root@ALiCentos7:~]$

3.7 管理ボリューム作成方法2`-v`パラメータと`--mount`パラメータ

-v と -mount の両方で管理ボリュームの作成を完了できます

3.7.1`-v`パラメータ

機能: 完全なディレクトリマッピング

docker run -v name:directory[:options] ...

パラメータ

第一个参数：卷名称
第二个参数：卷映射到容器的目录
第三个参数：选项，如 ro 表示 readonly

練習する。

docker run -d  --name myvolnginx1 -v volnginx1:/usr/share/nginx/html/ nginx:1.21.4

ここに画像の説明を挿入します

では、このコンテナに入り、これを削除して現象がどのようなものかを確認してみましょう。

ここに画像の説明を挿入します

オプションを持っていくとどうなるでしょうか-ro？(読み取り専用)

ここに画像の説明を挿入します

[root@ALiCentos7:~]$ docker exec -it myvolnginx1 bash
root@838d01664db5:/# cd /usr/share/nginx/html/
root@838d01664db5:/usr/share/nginx/html# ls
50x.html
root@838d01664db5:/usr/share/nginx/html# rm 50x.html 
rm: cannot remove '50x.html': Read-only file system
root@838d01664db5:/usr/share/nginx/html# rm 50x.html 
rm: cannot remove '50x.html': Read-only file system
root@838d01664db5:/usr/share/nginx/html# 
root@838d01664db5:/usr/share/nginx/html#

この時点で、もう削除することはできません。

3.7.2`--mount`パラメータ

ディレクトリマッピングを完了します。

パラメータ。

type : 类型表示 bind, volume, or tmpfs
source, src : 对于命名卷，这是卷的名称。对于匿名卷，省略此字段。
destination, dst, target : 文件或目录挂载在容器中的路径
ro, readonly : 只读方式挂载

練習する。

docker run -d --name mynginxvol3 --mount 'src=nginxvol3,dst=/usr/share/nginx/html' nginx:1.21.4

[root@ALiCentos7:~]$ docker run -d --name mynginxvol4 --mount 'dst=/usr/share/nginx/html' nginx:1.22.0 
2d04251a15f4a4216a079b798524a1e1c31f841d61417bfcb86aa2956cc63004
[root@ALiCentos7:~]$ docker inspect my
mynginxvol4          mywebsite-yufc:v1.0  
[root@ALiCentos7:~]$ docker inspect mynginxvol4 
[
    {
    
    
        "Id": "2d04251a15f4a4216a079b798524a1e1c31f841d61417bfcb86aa2956cc63004",
        "Created": "2023-09-19T12:05:44.437893015Z",
        "Path": "/docker-entrypoint.sh",
        "Args": [
            "nginx",
            "-g",
            "daemon off;"
        ],

ここに画像の説明を挿入します

3.8 Dockerfile 匿名ボリューム

Docker 管理ボリュームは、Dockerfile の VOLUME を通じて作成できます。これについては、後ほど Dockerfile で詳しく説明します。dockerfile の VOLUME 命令を使用してイメージにデータボリュームを作成することもできるため、イメージを使用して作成されたコンテナーにはマウントポイントが設定されますが、VOLUME 命令を使用して作成されたマウントポイントでは、マウントポイントを指定できないことに注意してください。ホスト上の対応するディレクトリですが、docker によってランダムに生成されます。

3.9 運用事例

3.9.1 ケース 1

コンテナの内容がホスト上で変更されるとどうなりますか? コンテナと同期されます。

まずは環境を準備します。

ここに画像の説明を挿入します

それを変更。

ここに画像の説明を挿入します

同時にコンテナも改造されていたことが判明した。

3.9.2 ケース 2

ro 経由でバインドされている場合でも変更できますか? ホストマシンを改造することはできますか? コンテナ内で変更できますか?

最初にコンテナを実行する

ここに画像の説明を挿入します

ホストマシン上で変更できることが分かりました。

ここに画像の説明を挿入します

コンテナ内では変更できないことがわかりました。

3.9.3 ケース 3

このメソッドを使用して--mount、上記 2 つのケースの操作を繰り返し、コンテナとホストが同期できるかどうかを確認します。

ここに画像の説明を挿入します

--mountコンテナを起動するために使用されます

ホームページに変更を加えます。

ここに画像の説明を挿入します

変更可能です。

3.10 Docker ボリュームのライフサイクル

結論: コンテナを削除してもボリュームの内容は残りますが、結局のところ、このボリュームは本来データを保護するために使用されます。

ここに画像の説明を挿入します

しかし、docker volume rm test3それが確実になくなった場合。

[root@ALiCentos7:~]$ ll /data/var/lib/docker/volumes/test3/_data
total 8
-rw-r--r-- 1 root root 497 Nov  2  2021 50x.html
-rw-r--r-- 1 root root 630 Sep 19 21:09 index.html
[root@ALiCentos7:~]$ docker volume rm test3
test3
[root@ALiCentos7:~]$ ll /data/var/lib/docker/volumes/test3/_data
ls: cannot access /data/var/lib/docker/volumes/test3/_data: No such file or directory
[root@ALiCentos7:~]$

3.11 ボリューム共有

3 つのコンテナを起動し、それらを同じボリュームにバインドして、変更後に何が起こるかを確認します。

結論: 3 つのコンテナが同時に更新されます。

クラウドサーバーはそれほど多くのポートを開きたがらないため、ここではデモンストレーションは行いません。

4. バインドボリュームのバインドマウント

-v と -mount は両方とも、バインドされたボリュームの作成を完了できます。

4.1`-v`バインドされたボリュームを作成するためのパラメータ

docker run -v name:directory[:options] ...

パラメータ

第一个参数：宿主机目录，这个和管理卷是不一样的
第二个参数：卷映射到容器的目录
第三个参数：选项，如 ro 表示 readonly

最初のパラメータがホストのディレクトリの場合はバインドされたボリューム、指定されていない場合は管理ボリュームの匿名ボリューム、名前の場合は管理ボリュームです。

実際の操作

docker run -d --name mynginx -v /root/DockerSrc/Volume/:/usr/share/nginx/html f6987c8d6ed5

ここに画像の説明を挿入します

ホストマシンに変更を加えます。

そこにもいくつかあることがわかりました。

ここに画像の説明を挿入します

4.2`--mount`バインドボリュームを作成するためのパラメータ

--mount '<key>=<value>,<key>=<value>'

パラメータ。

type : 类型表示 bind, volume, or tmpfs
source, src : 宿主机目录，这个和管理卷是不一样的。
destination, dst, target : 文件或目录挂载在容器中的路径
ro, readonly : 只读方式挂载

ここに画像の説明を挿入します

コンテナにファイルを書き込み、それがホストに表示されるかどうかを確認します。

ここに画像の説明を挿入します

4.3 バインディングボリュームの運用例

4.3.1 ケース 1

コンテナ作成の利用方法：nginxコンテナを作成し、コンテナディレクトリに--mountホストディレクトリをマウントしますディレクトリが存在しない場合はエラーとなりますので注意してください。/webapp1 /usr/share/nginx/htmlwebapp1

ここに画像の説明を挿入します

ホストディレクトリが存在しない場合は、エラーが直接報告されます。

ここに画像の説明を挿入します

4.3.2 ケース 2: バインドされたボリュームの共有

結論: ボリューム共有の管理と同じで、ホストが変更されると、すべてのコンテナが変更されます。

5. 一時ボリューム tmpfs

エフェメラルボリュームデータは、コンテナーやホストの外部のメモリ内に存在します。

tmpfs の制限事項

ボリュームやバインドマウントとは異なり、tmpfs マウントはコンテナ間で共有できません。
この機能は、Linux 上で Docker を実行している場合にのみ使用できます。

5.1 ボリュームの作成

方法 1:--tmpfs作成を指定する

ここに画像の説明を挿入します

この時の実験は前回と同じですが、コンテナが停止すると物がなくなってしまいます。

6. 包括的な実践 - MySQL 災害復旧

実用的な目的:

マウントされたボリュームの使い方をマスターし、mysql ビジネスデータを外部に保存する

実際の手順:

MySQL 5.7 イメージを使用してコンテナを作成し、コンテナ内で生成されたデータを保存するための共通データボリューム mysql-data を作成します。コンテナ内の MySQL サービスに接続し、データベーステストを作成し、データベースに単純なテーブルを作成して、そこにデータを挿入する必要があります。

まず、mysqlポイントコンテナーを見つけて実行します。

ここに画像の説明を挿入します

docker run --name mysql -v /root/DockerSrc/Volume/mysql-test:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=yfc@test -d mysql:5.7

これを接続しますmysql。

ここに画像の説明を挿入します

データベースを作成します。

ここに画像の説明を挿入します
テーブルを作成します。

ここに画像の説明を挿入します

この実行中のコンテナを削除します。

ここに画像の説明を挿入します

次に、新しいコンテナを実行し、それを元のディレクトリにバインドして、まだそこに存在するかどうかを確認します。

docker run --name mysql-new -v /root/DockerSrc/Volume/mysql-test:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=yfc@test -d mysql:5.7

ここに画像の説明を挿入します

まだそこにあるものを見つけました。