1
00:00:04,670 --> 00:00:10,720
‫わかりました｡  ボリュームとバインドマウントについて､ そしてなぜ永続的なデータについて心配する必要があるのか､

2
00:00:10,720 --> 00:00:16,120
‫すべて学んだところで､ 実際のシナリオであるデータベースのアップグレードをやってみましょう｡

3
00:00:16,120 --> 00:00:21,250
‫あるデータベースの特定のバージョンを実行している状況を想像してください｡

4
00:00:21,250 --> 00:00:30,490
‫例えば､ postgresの場合､ セキュリティ修正､ バグ修正などのため､ パッチバージョンを更新する必要があるとします｡

5
00:00:30,490 --> 00:00:36,730
‫通常､ システム上では､ ソフトウェアのアップデートを行うだけです｡  パッケージマネジメントシステムのアップデートやアップグレードを行うと､

6
00:00:37,030 --> 00:00:41,340
‫ライブラリのアップデートも含めてすべて自分で処理してくれるんです｡

7
00:00:41,650 --> 00:00:43,090
‫しかし､ それをコンテナで行うにはどうしたらいいのか｡

8
00:00:43,180 --> 00:00:48,700
‫というのも､ コンテナ内のアプリケーションを更新するのではなく､ コンテナを新しいバージョンに置き換えるというベストプラクティスに従おうとする場合､

9
00:00:48,700 --> 00:00:52,810
‫データベースでそれを行うにはどうしたらよいでしょうか｡

10
00:00:52,810 --> 00:01:03,910
‫この課題では､ Docker Hubを使って､ 特定のバージョンのpostgresを更新するための情報を取得します｡

11
00:01:03,910 --> 00:01:03,910
‫まずは､

12
00:01:03,910 --> 00:01:12,100
‫具体的にバージョン9を使ってコンテナを作っていただくところから始めます｡ 6. 1となり､ 旧バージョンとなります｡  そして､ 名前付きボリュームを作成する必要があります｡

13
00:01:12,100 --> 00:01:18,820
‫これはDocker Hubのドキュメントに寄りかかって､ postgresの公式リポジトリを利用することになります｡

14
00:01:19,270 --> 00:01:28,260
‫そのバージョンのDockerfileを見て､ 必要なボリュームパスを知る必要があります｡

15
00:01:28,260 --> 00:01:28,260
‫そして､ 左側でボリュームに好きな名前をつけることができます｡

16
00:01:28,270 --> 00:01:34,590
‫ただし､ 右側にあるコロンは､ コンテナ内の実際のデータベースが置かれるパスであることを忘れないでください｡

17
00:01:34,810 --> 00:01:38,680
‫すべてのことを把握し､ コンテナを起動したら､ データベースの作成とすべての起動が終了したことを確認するために､

18
00:01:38,680 --> 00:01:43,390
‫ログをチェックし始める必要があります｡ なぜなら､ データベース・コンテナを最初に起動したとき､

19
00:01:43,390 --> 00:01:51,810
‫通常は管理ユーザーやデフォルトのデータベースを作成するなど､ バックグラウンドでさまざまなことを行うからです｡

20
00:01:51,820 --> 00:01:55,660
‫ログが止まるタイミングがあり､ その後はひたすら走り続けることになります｡

21
00:01:55,660 --> 00:02:02,530
‫正しく実行できていれば､ docker volume ls を実行して､ そこに指定した名前でボリュームが表示されているのを確認し､

22
00:02:02,620 --> 00:02:10,560
‫そのコンテナを停止することができるはずです｡ そして､ 新しいバージョンで新しいコンテナを作るのです｡

23
00:02:10,630 --> 00:02:16,300
‫これは最初のコマンドと非常によく似たコマンドになりますが､

24
00:02:16,310 --> 00:02:24,420
‫異なるバージョンを指定するだけです｡

25
00:02:24,460 --> 00:02:29,450
‫もちろん､ この2つが同時に同じデータにアクセスすることはできないので､ 最初の1つを停止させていることを確認すること｡

26
00:02:29,680 --> 00:02:33,730
‫起動したら､ その新しいコンテナのログをもう一度確認してみてください｡

27
00:02:34,000 --> 00:02:40,900
‫見ていただきたいのは､ 初期起動のすべての作業をする必要がないため､ 起動ログが数行しかないことです｡

28
00:02:40,900 --> 00:02:43,650
‫同じ名前のボリュームを使用していることがわかるのは､

29
00:02:43,660 --> 00:02:48,050
‫2回目に起動したときに､ ログエントリーが4つか5つしかない場合です｡

30
00:02:48,310 --> 00:02:50,070
‫これが現実のシナリオなんですね｡

31
00:02:50,070 --> 00:02:54,860
‫本番用データベースを運用することがある場合など､ 最新の状態を維持する必要がある場合に行うことになります｡

32
00:02:55,000 --> 00:03:00,700
‫ほとんどのデータベースシステムは､ メジャーアップグレードを自動的に行わないことに注意してください｡

33
00:03:00,700 --> 00:03:06,670
‫通常､ 工具が必要です｡  postgresやMySQLでは､ それぞれ別のツールを実行する必要があります｡

34
00:03:06,670 --> 00:03:16,800
‫これは本当にパッチのバージョンアップだけで､ スキーマの変更やデータコード自体の大きな更新は必要ない最後の番号です｡

35
00:03:16,870 --> 00:03:18,080
‫前回同様､ つまづいても､

36
00:03:18,160 --> 00:03:24,400
‫これは新しいことなので､ Docker Hubではそこまで明確になっていないかもしれないので､ 心配は無用です｡

37
00:03:24,730 --> 00:03:28,120
‫もし､ ある時点で行き詰ってしまい､ Docker Hubが助けてくれない場合は､

38
00:03:28,120 --> 00:03:33,180
‫次の講義をチェックしてください｡ 私がこの演習と同じことを行っています｡

39
00:03:33,190 --> 00:03:33,550
‫頑張ってください｡