1
00:00:04,670 --> 00:00:09,710
‫わかりました｡  ボリュームは､ 一見シンプルに見えますが､ 実はいろいろあるんです｡

2
00:00:09,710 --> 00:00:16,480
‫ボリュームを気にする必要があることをコンテナに伝えるには､ まずDockerfileを使用します｡

3
00:00:16,480 --> 00:00:18,540
‫そのいくつかをチェックしてきましょう｡

4
00:00:18,590 --> 00:00:21,040
‫よくやることをやるだけです｡

5
00:00:21,170 --> 00:00:24,110
‫MySQLを検索してみる｡

6
00:00:24,320 --> 00:00:30,320
‫Dockerfilesの正しい使い方については､ 公式リポジトリにきちんとしたデフォルトとベストプラクティスが組み込まれているため､

7
00:00:30,380 --> 00:00:34,040
‫この方法で多くを学びました｡

8
00:00:34,040 --> 00:00:45,040
‫MySQL 1に移動したら､ ここで最新のDockerfileをクリックするだけです｡  データベースだから､ きっとVolumeコマンドが入ってるんでしょうね｡

9
00:00:45,200 --> 00:00:45,950
‫これでよしとしよう｡

10
00:00:45,950 --> 00:00:52,640
‫これは､ MySQLデータベースのデフォルトの場所です｡  このイメージは､ Dockerに対して､ このイメージから新しいコンテナを起動すると､

11
00:00:52,640 --> 00:01:05,450
‫実際に新しいボリュームロケーションを作成し､ コンテナ内のこのディレクトリに割り当てるようにプログラムされています｡

12
00:01:05,450 --> 00:01:05,450
‫つまり､

13
00:01:05,450 --> 00:01:08,600
‫コンテナ内に置いたファイルは､ ボリュームを手動で削除するまで､ コンテナよりも長持ちするのです｡

14
00:01:08,660 --> 00:01:13,250
‫そして､ ここで指摘しておかなければならないのは､ ボリュームは手動で削除する必要があるということです｡

15
00:01:13,280 --> 00:01:15,900
‫容器を外しただけではきれいにならない｡

16
00:01:15,930 --> 00:01:21,350
‫余計なお世話なんです｡  ボリュームコマンドのポイントは､ このデータが特に重要で､

17
00:01:21,380 --> 00:01:26,990
‫少なくともコンテナそのものよりもずっと重要であることを示すことですから､ これは単なる保険です｡

18
00:01:26,990 --> 00:01:29,930
‫MySQLでdocker pullを行い､ MySQLでdocker

19
00:01:33,500 --> 00:01:40,360
‫image inspectを行うと､ Dockerfileが表示されません｡ Dockerファイルはイメージのメタデータの一部ではないので､

20
00:01:40,370 --> 00:01:47,680
‫この設定領域で､ そのボリュームを指定していることに気がつくでしょう｡

21
00:01:47,810 --> 00:01:54,460
‫ビルド時にDockerfileから出力されたコンフィグが､ そのパスにボリュームを割り当てていることは常に確認できます｡

22
00:01:54,470 --> 00:01:57,150
‫そこからコンテナを動かしてみましょう｡

23
00:02:00,990 --> 00:02:05,640
‫そこで､ docker container run -d --name mysqlを実行します｡

24
00:02:05,730 --> 00:02:09,120
‫MySQLのほうは､ ちょっと特殊なんです｡

25
00:02:09,230 --> 00:02:13,450
‫動作させる前に環境変数を必要とするようになりました｡

26
00:02:13,530 --> 00:02:19,090
‫MYSQL_ALLOW_EMPTY_PASSWORDです｡

27
00:02:19,180 --> 00:02:19,430
‫OKです｡

28
00:02:22,810 --> 00:02:29,020
‫表示されているのは､ MySQLの実行です｡  docker container inspect

29
00:02:29,170 --> 00:02:37,200
‫mysqlを実行すると､ configでボリュームがあることを教えてくれるのと同じことが表示されるはずです｡

30
00:02:38,360 --> 00:02:39,370
‫これです｡

31
00:02:39,450 --> 00:02:47,400
‫また､ マウントの下にあるこの上にも見ることができます｡  これは､ 実行中のコンテナがホスト上の独自の場所を取得してデータを保存し､

32
00:02:47,400 --> 00:02:55,770
‫バックグラウンドでコンテナ内のその場所にマッピングまたはマウントして､ コンテナ内の場所が実際には /var/lib/mysql

33
00:02:55,770 --> 00:03:02,040
‫に書き込んでいると考えるようにしたものです｡

34
00:03:02,310 --> 00:03:08,570
‫この場合､ データは実際にホスト上のその場所に住んでいることがわかる｡  では､ docker volume ls を実行してみましょう｡

35
00:03:08,570 --> 00:03:16,760
‫これでボリュームは1つになりました｡

36
00:03:16,760 --> 00:03:16,760
‫さて､

37
00:03:16,760 --> 00:03:18,560
‫これがユニークなIDを持っていることに気づきましたが､ これが何に使われているのかはわかりませんよね？

38
00:03:18,560 --> 00:03:21,090
‫では､ それについてインスペクションをしてみましょう｡

39
00:03:21,150 --> 00:03:22,310
‫全部打ち込む必要はありません｡

40
00:03:22,310 --> 00:03:28,390
‫最初の数文字を入力してTabキーを押せば完了です｡  ボリューム自体についても､ それと同様の情報を得ることができます｡

41
00:03:29,440 --> 00:03:36,790
‫Linuxマシンで実際にやっているのであれば､ ハードディスクのその場所に移動して､ データを見ることができます｡

42
00:03:37,090 --> 00:03:38,530
‫そこには､ 実際にデータベースが存在することになります｡

43
00:03:38,560 --> 00:03:43,870
‫MacやWindowsをお使いの方は､ Windows版DockerとMac版Dockerは､ 実はバックグラウンドでLinux

44
00:03:43,870 --> 00:03:49,620
‫VMを作成するという､ 私たちからは見えないところでちょっとした作業をしていることを思い出してください｡

45
00:03:49,750 --> 00:03:55,420
‫つまり､ このデータは技術的にはそのLinux VMの中にあるわけです｡  WindowsやMacのマシンでそのパスにアクセスしても､

46
00:03:55,450 --> 00:03:59,530
‫データを見ることができないのです｡ 実はそのVMの中に入っているんです｡

47
00:03:59,530 --> 00:04:04,210
‫この制限をどのように回避するかは､ 実装されたボリュームを見ながら､ 少しずつ考えていきたいと思います｡

48
00:04:04,210 --> 00:04:14,250
‫これを見ると､ 何が入っているのか､ このボリュームは何に割り当てられているのか､ あまり使い勝手が良くないことに気がつきますね｡

49
00:04:14,260 --> 00:04:22,150
‫コンテナの視点からは､ それがどのボリュームを使用しているかはわかりますが､ ボリュームの視点からは､ それが何に接続されているかは見えません｡

50
00:04:22,150 --> 00:04:22,910
‫そうだろ？

51
00:04:23,230 --> 00:04:28,910
‫上矢印を押して､ 例えば､ mysql2を作成するとします｡

52
00:04:29,170 --> 00:04:32,190
‫これで､ バックグラウンドで動作する別のMySQLサーバーが作成されました｡

53
00:04:32,200 --> 00:04:36,430
‫もう一回docker volume lsをすると､ 2つ出てきますね｡

54
00:04:36,430 --> 00:04:37,770
‫問題が見えてきましたね？

55
00:04:37,790 --> 00:04:41,630
‫簡単に見分ける方法はないんです｡

56
00:04:41,740 --> 00:04:54,930
‫例えば､ docker container stop mysql と docker a container stop mysql2 を実行すると､ 以下のようになります｡

57
00:04:55,190 --> 00:05:06,900
‫docker container lsを実行すると､ 実行中のコンテナは表示されません｡  ls -aを実行すると､ それらすべてを見ることができます｡

58
00:05:06,900 --> 00:05:06,900
‫そして､ 止まっていることに気づく｡  そして､

59
00:05:06,910 --> 00:05:08,580
‫docker volume lsを実行すると､ まだ2つのボリュームがあることに気づきます｡

60
00:05:08,590 --> 00:05:16,390
‫docker container rm mysql と mysql2 を実行すると､ 1つのコマンドで両方を実行できるため､

61
00:05:16,390 --> 00:05:26,560
‫両方のコンテナを削除することができます｡ 今､ docker volume lsを実行すると､ 私のボリュームはまだそこにあります｡

62
00:05:26,560 --> 00:05:26,560
‫私のデータはまだ安全です｡

63
00:05:26,560 --> 00:05:28,510
‫そこで､ ひとつの問題を解決しました｡

64
00:05:28,510 --> 00:05:31,660
‫データベースは実行ファイルより長持ちする｡

65
00:05:31,660 --> 00:05:34,180
‫どうすればもう少し使いやすくなるのか？

66
00:05:35,090 --> 00:05:40,850
‫そこで登場したのが､ Docker runコマンドで指定できる名前付きボリュームです｡

67
00:05:41,120 --> 00:05:49,600
‫ドッカーコンテナの実行まで上矢印を何回か押せば､ どれをもう一度実行してもいいんだ｡

68
00:05:50,820 --> 00:05:59,340
‫今回は､ 実際に-vコマンドを投入してみます｡  vを指定すると､ これから実行するコンテナ用に作成する新しいボリュームを指定するか､

69
00:05:59,370 --> 00:06:07,500
‫他の2つのオプションを指定することができます｡

70
00:06:07,500 --> 00:06:10,320
‫ここではその1つとして､ 名前付きボリュームを作成する｡

71
00:06:10,320 --> 00:06:20,040
‫もし､ -vして､ var lib mysqlとすれば､ Dockerfileのvolumeコマンドがしたことと同じことができます｡

72
00:06:20,040 --> 00:06:29,930
‫ここでは､ その必要はないんです｡  しかし､ 私たちにできることは､ その前にコロンで名前を付けることができることです｡

73
00:06:29,930 --> 00:06:29,930
‫それを「ネームドボリューム」といいます｡  「これを実行し､

74
00:06:30,080 --> 00:06:39,300
‫docker volume ls を実行すると､ 新しいコンテナが新しいボリュームを使用しており､ フレンドリーな名前を使っていることがわかります｡

75
00:06:39,320 --> 00:06:45,980
‫そのmysqlにdocker volume inspectを行うと､ こちらの方が使いやすいことがわかると思います｡

76
00:06:46,010 --> 00:06:49,550
‫またコンテナを削除して､ まだ動いているので-fを付けて､

77
00:06:52,470 --> 00:07:04,280
‫もう一回実行したら｡ そして今回は､ 別の名前をつけることにします｡

78
00:07:04,280 --> 00:07:04,280
‫そして､

79
00:07:04,280 --> 00:07:09,420
‫もう一回docker volume lsを実行すると､ 新しいボリュームが作成されていないように見えることがわかります｡ 同じボリュームを使い続けています｡

80
00:07:09,420 --> 00:07:17,680
‫mysql3のdocker container inspectをやってみましょう｡  そして､ ここに表示されるのは､ はい､ これは設定されたものですが､

81
00:07:18,990 --> 00:07:22,860
‫私たちは何を実行しているのでしょうか？

82
00:07:22,880 --> 00:07:24,300
‫ここが私たちのマウントです｡

83
00:07:24,560 --> 00:07:30,980
‫名前だけでなく､ 実際にソースの場所も少し友好的に変更されたことがここでわかります｡

84
00:07:31,280 --> 00:07:38,480
‫私の場合は､ 何日も何週間も特定のデータベースを特定のコンテナで運用し､ 何度も繰り返し使用する必要があり､

85
00:07:38,540 --> 00:07:43,460
‫空のデータベースサーバーが必要ない場合､ この方法でコンテナを作成し､

86
00:07:43,460 --> 00:07:53,900
‫プロジェクト用に名前を付けて､ そのボリュームが何のためにあり､ 定着する必要があるのかが分かるようにします｡

87
00:07:57,840 --> 00:07:59,200
‫ここで最後にもうひとつ｡

88
00:08:00,130 --> 00:08:06,390
‫なぜ､ docker volume createをするのか？

89
00:08:06,550 --> 00:08:18,670
‫実行時にDockerコンテナのrunコマンドから作成でき､ Dockerfileに指定して作成できるのであれば､ 先に作成しておきたいケースは限られていますね｡

90
00:08:18,670 --> 00:08:18,670
‫そして､

91
00:08:18,670 --> 00:08:21,320
‫実はhelpコマンドを使えば､ すぐにわかるんです｡

92
00:08:22,210 --> 00:08:26,580
‫なぜなら､ 実際に別のドライバを指定できるのはここだけだからです｡

93
00:08:26,590 --> 00:08:28,890
‫後でお話しするプラグインのこと､ 覚えていますか？

94
00:08:29,020 --> 00:08:33,370
‫次に､ -oを使用したいドライバオプションを指定します｡

95
00:08:33,370 --> 00:08:37,090
‫それから､ ラベルを貼る場合ですが､ これも後ほど制作編で説明します｡

96
00:08:37,090 --> 00:08:42,530
‫特殊なケースでは､ 先にDocker Volumeを作成する必要がある場合もありますが､ 通常はローカルでの開発目的であれば､

97
00:08:42,540 --> 00:08:46,610
‫Dockerfileや実行コマンドで指定するだけでよいでしょう｡