1 00:00:00,001 --> 00:00:02,434 [No Audio] 2 00:00:02,434 --> 00:00:35,967 [Background Music] 3 00:00:35,967 --> 00:00:40,934 [No Audio] 4 00:00:40,934 --> 00:00:44,034 From a third person's point of view, this may seem 5 00:00:44,034 --> 00:00:47,367 like a funny story, but it can potentially cost 6 00:00:47,367 --> 00:00:50,434 you your job. That's the prime reason why we need 7 00:00:50,434 --> 00:00:53,367 efficient storage solutions with containers. 8 00:00:53,367 --> 00:00:57,034 The logic is pretty simple, containers data needs to 9 00:00:57,034 --> 00:01:00,434 be backed up somewhere as a permanent storage. 10 00:01:00,434 --> 00:01:03,534 And a quick question that will come up in your mind 11 00:01:03,534 --> 00:01:07,267 would be, what or which data should be backed up? 12 00:01:07,901 --> 00:01:10,567 To answer that, we need to look back at the 13 00:01:10,567 --> 00:01:14,001 layered structure of Docker Image and container data. 14 00:01:14,001 --> 00:01:16,501 If you remember, we have two types of 15 00:01:16,501 --> 00:01:20,367 layers, read only layers which hold permanent data, 16 00:01:20,367 --> 00:01:23,834 and is never modified due to Copy-on-Write policy, 17 00:01:23,834 --> 00:01:26,834 and Read/Write layers which hold temporary 18 00:01:26,834 --> 00:01:30,634 or volatile data. If a container stops or dies, 19 00:01:30,634 --> 00:01:34,167 the volatile data vanishes. So now we have our 20 00:01:34,167 --> 00:01:37,467 answer, we need to backup the important data from 21 00:01:37,467 --> 00:01:40,101 the volatile Read/Write layer of the container. 22 00:01:40,101 --> 00:01:44,067 Now the next question is where to store the data? 23 00:01:44,067 --> 00:01:47,667 Well, just anywhere. Do you want to store it on 24 00:01:47,667 --> 00:01:51,601 some machine, which hosts Docker? Go ahead. 25 00:01:51,767 --> 00:01:55,301 Do you want to store it to another server? Go ahead. 26 00:01:55,667 --> 00:01:59,267 Do you want to store it on Cloud? Go ahead as well. 27 00:01:59,701 --> 00:02:02,367 And the last and genuine question which comes to 28 00:02:02,367 --> 00:02:06,601 my mind, is are there any type of storage objects? 29 00:02:06,801 --> 00:02:10,934 Yes, there are. Most commonly used storage object 30 00:02:10,934 --> 00:02:14,601 type is called a Docker Volume. In a Volume, 31 00:02:14,601 --> 00:02:17,434 a container storage is completely isolated from the 32 00:02:17,434 --> 00:02:20,567 host file system. Although the data of Volume is 33 00:02:20,567 --> 00:02:23,601 sorted in a specific directory of the host, they 34 00:02:23,601 --> 00:02:26,667 are controlled and managed by Docker command line. 35 00:02:26,834 --> 00:02:29,501 Compared to other options of storage, which we 36 00:02:29,501 --> 00:02:32,501 will visit soon enough, Volumes are more secure to 37 00:02:32,501 --> 00:02:34,901 ship and more reliable to operate. 38 00:02:35,301 --> 00:02:39,867 Let's understand Volumes. Volumes are storage objects of 39 00:02:39,867 --> 00:02:43,167 Docker, which are mounted to containers. In terms 40 00:02:43,167 --> 00:02:46,067 of implementation, Volumes are dedicated 41 00:02:46,067 --> 00:02:48,701 directories on hosts file system. 42 00:02:48,701 --> 00:02:51,601 If a containerized app is shipped along with the 43 00:02:51,601 --> 00:02:54,501 Volume, people apart from the developer himself, 44 00:02:54,867 --> 00:02:57,434 using the app will end up creating such a 45 00:02:57,434 --> 00:03:00,034 directory on their own Docker hosts. 46 00:03:00,134 --> 00:03:03,967 Container provides data to Docker engine and user provides 47 00:03:03,967 --> 00:03:07,567 commands to store the data in the Volume or to 48 00:03:07,567 --> 00:03:09,734 manage the data in the same. 49 00:03:10,001 --> 00:03:14,767 Although what container knows, is just the name of the Volume, 50 00:03:14,767 --> 00:03:18,467 not the path on the host. The translation takes 51 00:03:18,467 --> 00:03:21,667 place on Docker machines end, so external 52 00:03:21,667 --> 00:03:25,001 applications having access to containers will have 53 00:03:25,001 --> 00:03:27,901 no means to access Volumes directly. 54 00:03:27,901 --> 00:03:32,134 This isolation maintains the integrity and security of 55 00:03:32,134 --> 00:03:34,034 hosts and containers. 56 00:03:34,734 --> 00:03:37,534 Second option is Bind Mounts. 57 00:03:37,534 --> 00:03:40,434 The exchange of information is pretty similar, 58 00:03:40,434 --> 00:03:42,634 apart from the fact that instead of 59 00:03:42,634 --> 00:03:46,001 creating a directory inspired by the name of Volume, 60 00:03:46,001 --> 00:03:49,167 Bind Mounts allow us to use any directory 61 00:03:49,167 --> 00:03:51,767 on Docker host to store the data. 62 00:03:52,467 --> 00:03:56,734 While this might be convenient in some cases, it also exposes the 63 00:03:56,734 --> 00:03:59,534 storage location of the container, which can make 64 00:03:59,534 --> 00:04:02,801 dents on the overall security of the application 65 00:04:02,801 --> 00:04:06,867 or the host itself. Apart from that, the other 66 00:04:06,867 --> 00:04:10,601 users apart from developer himself may not have 67 00:04:10,601 --> 00:04:13,901 such path on the host in creating so may not be 68 00:04:13,901 --> 00:04:16,101 under their privileges or comfort. 69 00:04:16,101 --> 00:04:21,301 Finally, we have tmpfs, or temporary file system. 70 00:04:21,534 --> 00:04:24,834 Volumes and Bind Mounts let you share the files between 71 00:04:24,834 --> 00:04:28,034 host machine and container, so that you can persist 72 00:04:28,034 --> 00:04:30,301 the data even after the container is stopped. 73 00:04:30,301 --> 00:04:36,167 If you're running Docker on Linux, you have a third option, tmpfs mounts. 74 00:04:36,234 --> 00:04:40,134 When you create a container with tmpfs mount, the container can 75 00:04:40,134 --> 00:04:43,401 create files outside the containers writable layer. 76 00:04:43,834 --> 00:04:47,834 As opposed to Volumes and Bind Mounts, a tmpfs mount 77 00:04:47,834 --> 00:04:51,767 is temporary and only persist in the host 78 00:04:51,767 --> 00:04:53,734 memory not in storage. 79 00:04:54,101 --> 00:04:57,501 When the container stops, the tmpfs mount is removed 80 00:04:57,567 --> 00:05:00,667 and the file sitting there won't be persisted. 81 00:05:00,801 --> 00:05:02,934 The only sensible use case 82 00:05:02,934 --> 00:05:05,867 which comes to my mind for tmpfs, is to store 83 00:05:05,867 --> 00:05:08,734 sensitive files, which you don't want to persist 84 00:05:08,734 --> 00:05:11,467 once the application gets deleted, something like 85 00:05:11,467 --> 00:05:16,134 the browsing history, which get deleted if we use the incognito tab. 86 00:05:16,667 --> 00:05:19,634 tmpfs mounts have their limitations, 87 00:05:19,634 --> 00:05:22,034 they can be created, not shipped, 88 00:05:22,034 --> 00:05:24,601 and they won't work on non Linux environments 89 00:05:24,601 --> 00:05:26,467 like Docker on Windows.