1 00:00:02,250 --> 00:00:03,730 With Docker, we actually 2 00:00:03,730 --> 00:00:07,470 have multiple external data storage mechanisms, 3 00:00:07,470 --> 00:00:10,770 if we wanna call them like this, two to be precise. 4 00:00:10,770 --> 00:00:14,300 And that would be volumes and bind mounts. 5 00:00:14,300 --> 00:00:17,040 Now, we'll worry about bind mounts later. 6 00:00:17,040 --> 00:00:19,590 For the moment we'll focus on volumes. 7 00:00:19,590 --> 00:00:23,980 And it looks like they don't fully work as we want to. 8 00:00:23,980 --> 00:00:27,630 Because we actually also have two types of volumes, 9 00:00:27,630 --> 00:00:31,770 and both have their own special purposes and use cases. 10 00:00:31,770 --> 00:00:35,523 Currently we're using anonymous volumes. 11 00:00:36,640 --> 00:00:39,220 Or to be precise with this instruction 12 00:00:39,220 --> 00:00:40,380 in the Docker file, 13 00:00:40,380 --> 00:00:44,670 we add an anonymous volume to this image and data for it 14 00:00:44,670 --> 00:00:47,323 to the containers running based on that image. 15 00:00:48,320 --> 00:00:52,060 Now, we can also assign named volumes, 16 00:00:52,060 --> 00:00:55,470 and that's not something we're doing up to this point. 17 00:00:55,470 --> 00:00:57,330 Now in both cases, 18 00:00:57,330 --> 00:00:59,860 no matter if it's anonymous or named, 19 00:00:59,860 --> 00:01:01,920 however that works, we'll see it soon. 20 00:01:01,920 --> 00:01:05,640 In both cases, Docker sets up some folder 21 00:01:05,640 --> 00:01:07,550 and path on your host machine. 22 00:01:07,550 --> 00:01:09,410 You don't know where. 23 00:01:09,410 --> 00:01:11,840 After all, here we only specified a path 24 00:01:11,840 --> 00:01:13,450 inside of the container, 25 00:01:13,450 --> 00:01:15,590 no path on our host machine. 26 00:01:15,590 --> 00:01:18,650 So we don't know where the folder is 27 00:01:18,650 --> 00:01:19,970 in which this is mirrored. 28 00:01:19,970 --> 00:01:21,890 It's somewhere managed by Docker, 29 00:01:21,890 --> 00:01:23,680 but we don't know where. 30 00:01:23,680 --> 00:01:25,560 And the only way for us to get access 31 00:01:25,560 --> 00:01:29,023 to these volumes is with help of the Docker volume command. 32 00:01:29,880 --> 00:01:31,340 And I can show this to you. 33 00:01:31,340 --> 00:01:34,589 If we go back here to the terminal, 34 00:01:34,589 --> 00:01:39,589 we can run Docker volume --help to see our options. 35 00:01:39,810 --> 00:01:42,050 And here it's Docker volume ls 36 00:01:42,050 --> 00:01:45,840 to list all volumes Docker is currently managing. 37 00:01:45,840 --> 00:01:48,470 And we see one volume here. 38 00:01:48,470 --> 00:01:49,990 Let me show it to you again. 39 00:01:49,990 --> 00:01:53,793 We see one volume here with a very strange cryptic name. 40 00:01:54,730 --> 00:01:56,730 This name is this cryptic 41 00:01:56,730 --> 00:01:59,600 because it's an automatically generated name. 42 00:01:59,600 --> 00:02:01,870 Because it's an anonymous volume, 43 00:02:01,870 --> 00:02:03,950 we didn't assign any name to it. 44 00:02:03,950 --> 00:02:06,860 Hence Docker automatically assigned one. 45 00:02:06,860 --> 00:02:08,580 Now here's the gotcha. 46 00:02:08,580 --> 00:02:12,020 If we stop our feedback app container, 47 00:02:12,020 --> 00:02:15,040 and therefore for we shut down this application, 48 00:02:15,040 --> 00:02:18,010 if we inspect our volumes again 49 00:02:18,010 --> 00:02:19,920 this anonymous volume is gone. 50 00:02:19,920 --> 00:02:22,290 It doesn't exist anymore. 51 00:02:22,290 --> 00:02:24,810 Now as I said, it's managed by Docker. 52 00:02:24,810 --> 00:02:26,740 And because it's anonymous, 53 00:02:26,740 --> 00:02:31,270 it actually only exists as long as our container exists. 54 00:02:31,270 --> 00:02:34,640 And that doesn't help us at all with the problem I outlined, 55 00:02:34,640 --> 00:02:36,710 which was that our data disappears 56 00:02:36,710 --> 00:02:38,970 if we shut down a container. 57 00:02:38,970 --> 00:02:39,990 Now I will come back 58 00:02:39,990 --> 00:02:43,520 to where anonymous volumes can be helpful, 59 00:02:43,520 --> 00:02:46,160 but let's have a look at named volumes, then. 60 00:02:46,160 --> 00:02:48,180 Maybe these'll help us. 61 00:02:48,180 --> 00:02:50,360 Because they share one key concept 62 00:02:50,360 --> 00:02:53,630 with anonymous volumes and actually all the bind mounts, 63 00:02:53,630 --> 00:02:55,230 as you will learn later, 64 00:02:55,230 --> 00:02:57,290 which will be helpful to us. 65 00:02:57,290 --> 00:02:59,690 A defined path in a container 66 00:02:59,690 --> 00:03:03,090 is mapped to some created volume. 67 00:03:03,090 --> 00:03:06,230 So to some created path on the host machine. 68 00:03:06,230 --> 00:03:07,990 So for example here, 69 00:03:07,990 --> 00:03:09,850 this app feedback path 70 00:03:09,850 --> 00:03:13,950 in a container is mapped to some folder on the host machine. 71 00:03:13,950 --> 00:03:16,410 We just don't know which path 72 00:03:16,410 --> 00:03:18,460 because it's managed by Docker. 73 00:03:18,460 --> 00:03:21,920 I can tell you it's hidden somewhere on your computer, 74 00:03:21,920 --> 00:03:24,610 and it's not meant to be accessed by you. 75 00:03:24,610 --> 00:03:27,380 So it's hard to find out where exactly it is, 76 00:03:27,380 --> 00:03:29,490 but also we shouldn't access 77 00:03:29,490 --> 00:03:31,590 and work in that folder anyways. 78 00:03:31,590 --> 00:03:33,440 So that's why this is fine. 79 00:03:33,440 --> 00:03:36,350 But that theoretically is a promising concept 80 00:03:36,350 --> 00:03:38,810 if only the volume wouldn't be deleted 81 00:03:38,810 --> 00:03:40,370 when a container shuts down. 82 00:03:40,370 --> 00:03:41,610 If that would be the case 83 00:03:41,610 --> 00:03:44,550 and the folder would survive on our local machine, 84 00:03:44,550 --> 00:03:46,690 then everything would be good. 85 00:03:46,690 --> 00:03:49,360 And here's the good news, finally. 86 00:03:49,360 --> 00:03:52,390 With named volumes, that will be the case. 87 00:03:52,390 --> 00:03:54,090 With named volumes, 88 00:03:54,090 --> 00:03:57,470 volumes will survive container's shutdown. 89 00:03:57,470 --> 00:04:00,170 The folders on your hard drive will survive. 90 00:04:00,170 --> 00:04:03,150 And therefore, if you start new containers thereafter, 91 00:04:03,150 --> 00:04:06,020 the volumes will be back, the folder will be back, 92 00:04:06,020 --> 00:04:08,080 and all the data stored in that folder 93 00:04:08,080 --> 00:04:10,060 will still be available. 94 00:04:10,060 --> 00:04:12,760 So named volumes are great for data 95 00:04:12,760 --> 00:04:14,850 which should be persistent, 96 00:04:14,850 --> 00:04:16,200 and that's important, 97 00:04:16,200 --> 00:04:19,050 which you don't need to edit or view directly, 98 00:04:19,050 --> 00:04:20,899 because you don't really have access 99 00:04:20,899 --> 00:04:23,110 to that folder on your host machine. 100 00:04:23,110 --> 00:04:26,810 As I just said, it's hidden somewhere managed by Docker, 101 00:04:26,810 --> 00:04:28,770 and it's hard to find out where it is. 102 00:04:28,770 --> 00:04:31,640 And it's not meant to be edited by you. 103 00:04:31,640 --> 00:04:34,923 I'll come back to an option which you can edit later. 104 00:04:35,930 --> 00:04:38,840 So named volumes would be interesting here. 105 00:04:38,840 --> 00:04:40,970 I'll come back to anonymous volumes 106 00:04:40,970 --> 00:04:43,180 and where they can help us as well. 107 00:04:43,180 --> 00:04:46,370 But for the moment we need named volumes. 108 00:04:46,370 --> 00:04:51,290 And we can't create named volumes inside of a Docker file, 109 00:04:51,290 --> 00:04:53,980 hence we can remove this instruction actually. 110 00:04:53,980 --> 00:04:56,880 Instead we have to create a named volume 111 00:04:56,880 --> 00:04:59,010 when we run a container. 112 00:04:59,010 --> 00:05:00,590 So therefore first of all, 113 00:05:00,590 --> 00:05:03,230 I'll rebuild my image here 114 00:05:04,270 --> 00:05:07,090 since I removed that volume's instruction. 115 00:05:07,090 --> 00:05:09,210 So first of all, I'll remove it. 116 00:05:09,210 --> 00:05:11,690 And then I will repeat that build command 117 00:05:11,690 --> 00:05:13,703 to build that image with that tag. 118 00:05:15,120 --> 00:05:17,450 And once it was rebuilt, 119 00:05:17,450 --> 00:05:20,500 I will now once again restart my container 120 00:05:20,500 --> 00:05:23,900 based on that image with the Docker run command, 121 00:05:23,900 --> 00:05:25,520 but not like this. 122 00:05:25,520 --> 00:05:28,583 Instead now I add another flag, 123 00:05:28,583 --> 00:05:31,490 another option to this command. 124 00:05:31,490 --> 00:05:36,220 And that's the -V option, which stands for volume, 125 00:05:36,220 --> 00:05:38,650 which allows me to add a volume to this container. 126 00:05:38,650 --> 00:05:41,440 But unlike in the Docker file, 127 00:05:41,440 --> 00:05:45,963 not just an anonymous volume but actually a named volume. 128 00:05:46,860 --> 00:05:48,760 And here's how that works. 129 00:05:48,760 --> 00:05:51,500 We still specify the path inside 130 00:05:51,500 --> 00:05:54,930 of the container file system which we wanna save. 131 00:05:54,930 --> 00:05:57,640 And in our case, that's app/feedback. 132 00:05:57,640 --> 00:05:58,913 This hasn't changed. 133 00:05:59,910 --> 00:06:02,030 But in front of this path, 134 00:06:02,030 --> 00:06:04,980 we now provide any name of our choice. 135 00:06:04,980 --> 00:06:07,990 For example, feedback. 136 00:06:07,990 --> 00:06:12,000 We then add a colon to separate our name from that path. 137 00:06:12,000 --> 00:06:16,150 And this is a syntax Docker will understand, 138 00:06:16,150 --> 00:06:21,150 and it will now store app feedback in a managed volume. 139 00:06:21,440 --> 00:06:24,270 So it will create a folder on our hosting machine 140 00:06:24,270 --> 00:06:28,160 and connect it to this folder inside of the container, 141 00:06:28,160 --> 00:06:32,830 but it will store this volume under a name chosen by us. 142 00:06:32,830 --> 00:06:35,230 And the key difference to anonymous volumes 143 00:06:35,230 --> 00:06:38,650 is that named volumes will not be deleted 144 00:06:38,650 --> 00:06:41,770 by Docker when the container shuts down. 145 00:06:41,770 --> 00:06:45,830 Anonymous volumes are deleted because they are recreated 146 00:06:45,830 --> 00:06:47,850 whenever a container is created. 147 00:06:47,850 --> 00:06:49,560 And therefore, keeping them around 148 00:06:49,560 --> 00:06:52,750 after a container was removed makes no sense. 149 00:06:52,750 --> 00:06:55,940 Anonymous volumes are closely attached 150 00:06:55,940 --> 00:06:58,180 to one specific container. 151 00:06:58,180 --> 00:07:02,310 Named volumes are not attached to a container. 152 00:07:02,310 --> 00:07:05,950 And therefore here, if I now run this, 153 00:07:05,950 --> 00:07:09,443 I can go back to local host 3000, 154 00:07:12,160 --> 00:07:17,160 add another feedback or another message here, save this. 155 00:07:18,810 --> 00:07:23,730 And of course, visit feedback/awesome.txt. 156 00:07:23,730 --> 00:07:25,450 And see that. 157 00:07:25,450 --> 00:07:30,450 But now, finally, I promise if we stopped this 158 00:07:30,740 --> 00:07:33,540 with Docker stop feedback app, 159 00:07:33,540 --> 00:07:35,320 and this will remove the container 160 00:07:35,320 --> 00:07:38,220 because of the -- rm flag, 161 00:07:38,220 --> 00:07:40,210 our volume will still be there. 162 00:07:40,210 --> 00:07:42,490 And hence, if we restart a new container 163 00:07:42,490 --> 00:07:45,483 with the same volume, our data will still be there. 164 00:07:46,370 --> 00:07:50,320 So let's first check for the volume with Docker volume ls. 165 00:07:50,320 --> 00:07:52,830 And you see that's the name we chose, 166 00:07:52,830 --> 00:07:56,320 and it's still there even though the container was stopped. 167 00:07:56,320 --> 00:07:59,570 That's different compared to before. 168 00:07:59,570 --> 00:08:03,680 And if we now restart the container by using Docker run. 169 00:08:03,680 --> 00:08:05,930 So I'm not restarting the same container. 170 00:08:05,930 --> 00:08:07,440 I'm creating a new container. 171 00:08:07,440 --> 00:08:11,030 But if I do that, and that's important, 172 00:08:11,030 --> 00:08:15,050 the same -V option with the same volume name, 173 00:08:15,050 --> 00:08:17,220 so the same name as before, 174 00:08:17,220 --> 00:08:18,650 now, this restarts. 175 00:08:18,650 --> 00:08:20,010 And now if I reload here, 176 00:08:20,010 --> 00:08:24,250 you see finally the data is still there. 177 00:08:24,250 --> 00:08:28,140 So finally we managed to persist data 178 00:08:28,140 --> 00:08:29,890 with the help of volumes, 179 00:08:29,890 --> 00:08:33,703 to be precise, with the help of named volumes.