1
00:00:05,810 --> 00:00:10,720
‫Bagian ini akan penuh dengan kuliah dan tugas seputar data persisten.

2
00:00:11,230 --> 00:00:16,490
‫Pertama, kita akan membahas masalah data persisten dan bagaimana hal itu

3
00:00:16,490 --> 00:00:18,280
‫bahkan menjadi masalah.

4
00:00:18,290 --> 00:00:23,640
‫Konsep-konsep kunci di sana yang perlu Anda pahami adalah gagasan infrastruktur yang tidak berubah.

5
00:00:23,810 --> 00:00:28,580
‫Dan ide tentang wadah secara alami fana dalam desain.

6
00:00:28,880 --> 00:00:36,680
‫Kami akan membahasnya di kuliah pertama. Lalu kami akan menyelami volume data dan bagaimana mereka

7
00:00:36,680 --> 00:00:44,270
‫memecahkan beberapa masalah kami di sekitar data persisten. Kemudian kita juga akan menggali bind mounts dan bagaimana hal

8
00:00:44,360 --> 00:00:50,660
‫itu menyelesaikan masalah yang berbeda dengan data persisten. Kemudian kita akan mengakhiri bagian ini dengan beberapa penugasan seputar

9
00:00:50,720 --> 00:00:57,530
‫cara menyimpan data basis data, sambil mengganti wadah untuk basis data. Dan kemudian juga sekitar benar-benar memasang

10
00:00:57,740 --> 00:01:03,320
‫kode ke dalam wadah dari host saat Anda sedang mengeditnya, sehingga Anda

11
00:01:03,320 --> 00:01:11,560
‫dapat menjalankan kode itu di dalam wadah langsung. Persyaratan untuk kuliah pertama ini hanya memahami cara menjalankan

12
00:01:11,560 --> 00:01:16,970
‫wadah, dan konsep wadah dan gambar yang telah kita bahas sejauh ini.

13
00:01:17,050 --> 00:01:23,230
‫Sampai sekarang, Anda hanya khawatir tentang apa yang diperlukan untuk menjalankan sebuah wadah, bukan data unik yang mungkin dibuat

14
00:01:23,230 --> 00:01:24,920
‫begitu sebuah wadah berjalan.

15
00:01:25,840 --> 00:01:29,200
‫Wadah dimaksudkan untuk menjadi abadi dan tidak kekal.

16
00:01:29,320 --> 00:01:34,220
‫Itu hanya kata kunci mewah untuk tidak berubah dan sementara, atau sekali pakai.

17
00:01:34,480 --> 00:01:40,180
‫Idenya di sini adalah kita bisa membuang wadah dan membuat yang baru dari sebuah gambar,

18
00:01:40,180 --> 00:01:40,770
‫bukan?

19
00:01:41,790 --> 00:01:47,820
‫Maka kita tidak berbicara tentang batasan aktual wadah, tetapi lebih pada tujuan desain, atau

20
00:01:47,820 --> 00:01:49,070
‫praktik terbaik.

21
00:01:49,080 --> 00:01:54,690
‫Ini adalah gagasan infrastruktur tidak berubah di mana kita tidak mengubah hal-hal begitu mereka berjalan.

22
00:01:54,840 --> 00:02:00,330
‫Jika perubahan konfigurasi perlu terjadi, atau mungkin peningkatan versi wadah perlu dilakukan, maka kami memindahkan kembali

23
00:02:00,330 --> 00:02:02,420
‫wadah yang sama sekali baru.

24
00:02:02,490 --> 00:02:08,370
‫Ini memberi kita manfaat besar dalam keandalan dan konsistensi, dan membuat perubahan dapat direproduksi.

25
00:02:08,490 --> 00:02:10,350
‫Tapi ada kompromi.

26
00:02:10,350 --> 00:02:16,140
‫Bagaimana dengan data unik yang akan dihasilkan aplikasi Anda? Database itu, atau nilai kunci disimpan, atau apa pun yang

27
00:02:16,140 --> 00:02:18,150
‫aplikasi Anda keluarkan ke dalam file?

28
00:02:18,330 --> 00:02:24,810
‫Idealnya, wadah tidak boleh berisi data unik Anda dicampur dengan biner aplikasi. Ini dikenal sebagai "pemisahan keprihatinan"

29
00:02:24,810 --> 00:02:30,340
‫dan Docker sebenarnya memberi kita manfaat besar di sini.

30
00:02:30,450 --> 00:02:36,780
‫Kami dapat memperbarui aplikasi kami dengan membuat ulang wadah baru, dengan versi terbaru dari aplikasi kami, dan idealnya, data unik

31
00:02:36,990 --> 00:02:42,530
‫kami masih berada di tempat yang seharusnya dan disimpan untuk kami saat wadah kami didaur ulang.

32
00:02:42,540 --> 00:02:48,510
‫Jika Anda belum menyadarinya, kontainer yang kami gunakan, secara default, tetap ada.

33
00:02:48,510 --> 00:02:53,880
‫Setiap perubahan di dalamnya sebenarnya disimpan di restart dan reboot sampai kami menghapus wadah.

34
00:02:54,240 --> 00:02:57,160
‫Hanya karena kami menghentikan wadah atau me-restart host,

35
00:02:57,300 --> 00:03:00,030
‫bukan berarti perubahan file kontainer hilang.

36
00:03:00,210 --> 00:03:05,910
‫Hanya ketika kita menghapus wadah, lapisan UFS-nya hilang, tetapi kita ingin bisa melakukannya

37
00:03:05,910 --> 00:03:07,160
‫sesuka hati.

38
00:03:07,170 --> 00:03:13,320
‫Masalah data unik ini dikenal di industri sebagai "data persisten" dan hingga kontainer, kami

39
00:03:13,320 --> 00:03:19,230
‫tidak benar-benar memiliki nama untuk itu. Karena, yah, sebagian besar hal yang kami bangun bersifat persisten,

40
00:03:19,230 --> 00:03:24,090
‫seperti Anda tahu server lama yang telah menjalankan aplikasi lama itu selama lima atau 10 tahun atau lebih.

41
00:03:24,270 --> 00:03:26,850
‫Semuanya gigih secara default.

42
00:03:26,850 --> 00:03:32,400
‫Sekarang di dunia baru kontainer dan penskalaan otomatis aplikasi, data yang persisten menciptakan

43
00:03:32,400 --> 00:03:33,280
‫masalah unik.

44
00:03:33,420 --> 00:03:36,640
‫Docker memiliki dua solusi untuk masalah ini, yang

45
00:03:36,720 --> 00:03:42,450
‫dikenal sebagai "volume data" dan "bind mounts. "Volume Docker adalah opsi konfigurasi

46
00:03:42,450 --> 00:03:46,620
‫untuk sebuah wadah yang menciptakan lokasi khusus di luar sistem

47
00:03:46,620 --> 00:03:50,130
‫file penyatuan penyimpan itu untuk menyimpan data unik.

48
00:03:50,210 --> 00:03:55,470
‫Ini menyimpannya di seluruh pemindahan kontainer dan memungkinkan kami untuk menempelkannya ke wadah apa pun yang kita inginkan.

49
00:03:55,940 --> 00:03:58,210
‫Dan wadah hanya melihatnya seperti jalur file lokal.

50
00:03:58,440 --> 00:04:05,670
‫Lalu ada bind mounts, yang hanya kita bagikan atau pasang direktori host, atau file, ke sebuah wadah.

51
00:04:05,970 --> 00:04:10,470
‫Sekali lagi, itu hanya akan terlihat seperti jalur file lokal, atau jalur direktori, ke wadah.

52
00:04:10,470 --> 00:04:12,590
‫Sebenarnya tidak akan tahu bahwa itu berasal dari tuan rumah.