1 00:00:05,810 --> 00:00:10,720 ‫このセクションでは､ 永続的なデータにまつわる講義や課題が満載です｡ 2 00:00:11,230 --> 00:00:18,280 ‫まず､ 永続的なデータの問題点と､ そもそもなぜそれが問題になったのかについて説明します｡ 3 00:00:18,290 --> 00:00:23,640 ‫そこで理解すべき重要なコンセプトは､ イミュータブル・インフラストラクチャという考え方です｡ 4 00:00:23,810 --> 00:00:28,580 ‫そして､ コンテナは本来､ 儚いデザインであるという考え方です｡ 5 00:00:28,880 --> 00:00:44,270 ‫それらは第1回目の講義で取り上げます｡ 次に､ データボリュームについて､ そして永続的なデータに関する問題のいくつかを解決する方法について説明します｡ 6 00:00:44,270 --> 00:00:44,270 ‫さらに､ 7 00:00:44,360 --> 00:00:50,660 ‫バインドマウントと､ それが永続的なデータに関するさまざまな問題をどのように解決するのかについても掘り下げます｡ そして､ このセクションの最後に､ データベースのコンテナを置き換えながら､ 8 00:00:50,720 --> 00:00:57,530 ‫データベースのデータを保持する方法について､ いくつかの課題を提示します｡ また､ 編集中にホストからコンテナにコードをマウントして､ 9 00:00:57,740 --> 00:01:11,560 ‫コンテナ内でコードをライブで実行できるようにすることも可能です｡ 10 00:01:11,560 --> 00:01:11,560 ‫この最初の講義の要件は､ 11 00:01:11,560 --> 00:01:16,970 ‫コンテナの実行方法と､ これまでに説明したコンテナとイメージの概念を理解していることだけです｡ 12 00:01:17,050 --> 00:01:24,920 ‫これまでは､ コンテナの実行に必要なものだけを考え､ コンテナ実行後に作成される可能性のあるユニークなデータについては考えなかったのです｡ 13 00:01:25,840 --> 00:01:29,200 ‫コンテナは､ イミュータブルでエフェメラルであることを意味します｡ 14 00:01:29,320 --> 00:01:34,220 ‫それらは､ 不変で一時的な､ あるいは使い捨ての､ 空想上の流行語に過ぎない｡ 15 00:01:34,480 --> 00:01:40,770 ‫ここでは､ コンテナを捨てて､ イメージから新しいコンテナを作ればいいという発想ですね？ 16 00:01:41,790 --> 00:01:49,070 ‫そうなると､ コンテナの実際の制限の話ではなく､ 設計目標やベストプラクティスの話になります｡ 17 00:01:49,080 --> 00:01:54,690 ‫これは､ 一度稼働させたものは変えないというイミュータブルインフラの考え方です｡ 18 00:01:54,840 --> 00:02:02,420 ‫もし､ 設定変更が必要な場合や､ コンテナのバージョンアップが必要な場合は､ 全く新しいコンテナを再デプロイします｡ 19 00:02:02,490 --> 00:02:08,370 ‫これにより､ 信頼性と一貫性､ そして変更の再現性において大きなメリットを得ることができます｡ 20 00:02:08,490 --> 00:02:10,350 ‫しかし､ そこにはトレードオフがあります｡ 21 00:02:10,350 --> 00:02:18,150 ‫アプリが生成するユニークなデータについてはどうでしょうか｡ データベースやキー・バリュー・ストアなど､ アプリがファイルに吐き出すものは？ 22 00:02:18,330 --> 00:02:24,810 ‫理想を言えば､ コンテナにはアプリケーションのバイナリに混じって､ あなた固有のデータが含まれていないことが望ましい｡ これは「関心事の分離」として知られていますが､ 23 00:02:24,810 --> 00:02:30,340 ‫実はDockerはここで大きなメリットを与えてくれます｡ 24 00:02:30,450 --> 00:02:36,780 ‫新しいコンテナを再作成して､ アプリケーションを更新することができます｡ 理想的には､ コンテナがリサイクルされる間､ 25 00:02:36,990 --> 00:02:42,530 ‫私たちのために保存された固有のデータが､ 必要な場所に残っていることです｡ 26 00:02:42,540 --> 00:02:48,510 ‫これまでお気づきでなかったかもしれませんが､ これまで使っていたコンテナは､ デフォルトではパーシステントでした｡ 27 00:02:48,510 --> 00:02:53,880 ‫コンテナを取り外すまで､ 再起動や再起動の際にも､ 実際に変更が加えられていました｡ 28 00:02:54,240 --> 00:03:00,030 ‫コンテナを停止したり､ ホストを再起動したからといって､ コンテナのファイル変更がなくなるわけではありません｡ 29 00:03:00,210 --> 00:03:07,160 ‫コンテナを取り外すときに初めてUFS層がなくなるのですが､ それを自由にできるようにしたいのです｡ 30 00:03:07,170 --> 00:03:19,230 ‫このユニークなデータの問題は､ 業界では「パーシステントデータ」と呼ばれ､ コンテナまではその名称がなかったのです｡ 31 00:03:19,230 --> 00:03:19,230 ‫というのも､ 32 00:03:19,230 --> 00:03:24,090 ‫私たちが作ったもののほとんどは､ 5年､ 10年､ あるいはそれ以上にわたって古いアプリを動かし続けている古いサーバーのように､ 永続的なものだったからです｡ 33 00:03:24,270 --> 00:03:26,850 ‫デフォルトですべてパーシステントになっていました｡ 34 00:03:26,850 --> 00:03:33,280 ‫コンテナやアプリケーションのオートスケーリングという新しい世界では､ 永続的なデータがユニークな問題を引き起こします｡ 35 00:03:33,420 --> 00:03:42,450 ‫Dockerはこの問題に対して､ 「データボリューム」と「バインドマウント」という2つの解決策を用意しています｡ 36 00:03:42,450 --> 00:03:42,450 ‫「Dockerボリュームはコンテナの設定オプションで､ 37 00:03:42,450 --> 00:03:50,130 ‫そのコンテナのユニオンファイルシステムの外側に特別な場所を作成し､ 固有のデータを保存するものです｡ 38 00:03:50,210 --> 00:03:55,470 ‫これにより､ コンテナの取り外しの際にも保存され､ 好きなコンテナに装着することができます｡ 39 00:03:55,940 --> 00:03:58,210 ‫そして､ コンテナはそれをローカルファイルのパスのように見るだけです｡ 40 00:03:58,440 --> 00:04:05,670 ‫そして､ バインドマウント｡ これは､ ホストのディレクトリやファイルをコンテナに共有したりマウントしたりすることです｡ 41 00:04:05,970 --> 00:04:10,470 ‫ここでも､ コンテナへのローカルファイルパス､ またはディレクトリパスのように見えるだけでしょう｡ 42 00:04:10,470 --> 00:04:12,590 ‫実際には､ ホストから来たということはわからないでしょう｡