1 00:00:02,460 --> 00:00:04,440 Now there is one other thing related 2 00:00:04,440 --> 00:00:06,800 to volumes which I wanna show you. 3 00:00:06,800 --> 00:00:09,553 And that would be read only volumes. 4 00:00:10,640 --> 00:00:13,680 Let's say we start our container again with Docker run 5 00:00:13,680 --> 00:00:15,910 the same container we've been starting over 6 00:00:15,910 --> 00:00:18,020 and over for all this module, 7 00:00:18,020 --> 00:00:22,410 we started this feedback app with our named volume 8 00:00:22,410 --> 00:00:25,480 with our bind mount and with our anonymous volume 9 00:00:25,480 --> 00:00:29,340 for node modules to save those dependencies 10 00:00:29,340 --> 00:00:30,890 from the bind mount. 11 00:00:30,890 --> 00:00:34,350 But now let's have a closer look at our bind mount 12 00:00:34,350 --> 00:00:36,780 before we start this container. 13 00:00:36,780 --> 00:00:38,920 If we think about this bind mount, 14 00:00:38,920 --> 00:00:42,710 the idea is that we can edit our source code here, 15 00:00:42,710 --> 00:00:45,490 and changes are automatically available 16 00:00:45,490 --> 00:00:47,450 inside of the container right? 17 00:00:47,450 --> 00:00:51,430 The idea is definitely not that the container should be able 18 00:00:51,430 --> 00:00:53,600 to write into the app folder, 19 00:00:53,600 --> 00:00:56,340 the container should not be able to change the files 20 00:00:56,340 --> 00:00:59,100 in there, only we should be able to change them 21 00:00:59,100 --> 00:01:01,260 on our host machine file system, 22 00:01:01,260 --> 00:01:04,489 not from inside the container, the running application 23 00:01:04,489 --> 00:01:07,490 in the container should not change these files. 24 00:01:07,490 --> 00:01:10,740 And that's why we might want to enforce this. 25 00:01:10,740 --> 00:01:13,690 Also to make it really clear what our intention is, 26 00:01:13,690 --> 00:01:16,570 by turning this volume this bind mount 27 00:01:16,570 --> 00:01:19,480 into a read only volume. 28 00:01:19,480 --> 00:01:22,120 By default volumes, are read write, 29 00:01:22,120 --> 00:01:25,320 which means the container is able to read data from there 30 00:01:25,320 --> 00:01:27,340 and write data to them. 31 00:01:27,340 --> 00:01:31,200 But you can restrict that by adding an extra colon 32 00:01:31,200 --> 00:01:33,450 after the container internal path, 33 00:01:33,450 --> 00:01:36,513 and then RO for read only. 34 00:01:37,520 --> 00:01:41,430 This ensures that docker will now not be able to write 35 00:01:41,430 --> 00:01:45,410 into this folder or any of its sub-folders. 36 00:01:45,410 --> 00:01:48,580 Of course, we on our hosting machine still will be able 37 00:01:48,580 --> 00:01:51,210 to change these files, this does not affect us, 38 00:01:51,210 --> 00:01:54,280 it only affects the container and the application running 39 00:01:54,280 --> 00:01:55,810 in the container. 40 00:01:55,810 --> 00:01:59,450 Still, this is not all we need to do in this scenario, 41 00:01:59,450 --> 00:02:02,660 because you have to keep in mind that we bind 42 00:02:02,660 --> 00:02:05,940 this entire project folder as a bind mount. 43 00:02:05,940 --> 00:02:08,350 So all the folders and files here. 44 00:02:08,350 --> 00:02:11,950 And at the moment, this would mean that we also restrict 45 00:02:11,950 --> 00:02:16,210 the write ability to feedback and temp. 46 00:02:16,210 --> 00:02:19,710 These, however, are folders to which we wanna write 47 00:02:19,710 --> 00:02:21,740 from inside our source code. 48 00:02:21,740 --> 00:02:25,890 In server.js, I will definitely try to write a file 49 00:02:25,890 --> 00:02:30,230 into my temp folder and into my final folder, 50 00:02:30,230 --> 00:02:31,730 so the feedback folder. 51 00:02:31,730 --> 00:02:34,140 Hence, we should make sure that writing is possible 52 00:02:34,140 --> 00:02:35,580 to those folders. 53 00:02:35,580 --> 00:02:38,540 And here the logic is the same as before 54 00:02:38,540 --> 00:02:41,520 with this anonymous node modules folder. 55 00:02:41,520 --> 00:02:46,500 If we specify another volume, inside of this entire project 56 00:02:46,500 --> 00:02:49,430 folder volume here inside of the entire app folder 57 00:02:49,430 --> 00:02:54,120 in the container, if we specify a more specific sub-volume, 58 00:02:54,120 --> 00:02:59,120 so to say, then that sub-volume overrides the main volume, 59 00:02:59,500 --> 00:03:03,200 you could say, just like this anonymous volume ensures 60 00:03:03,200 --> 00:03:06,530 that node modules is not taken from the bind mount, 61 00:03:06,530 --> 00:03:09,030 but instead we stick to the one created 62 00:03:09,030 --> 00:03:11,780 during the image building. 63 00:03:11,780 --> 00:03:15,260 So that means that for example, for app/feedback, 64 00:03:15,260 --> 00:03:16,700 we're already good. 65 00:03:16,700 --> 00:03:20,070 We already have this extra volume of course, 66 00:03:20,070 --> 00:03:22,760 because we wanna persist the data that's in there, 67 00:03:22,760 --> 00:03:24,630 we want the data to survive. 68 00:03:24,630 --> 00:03:28,270 And since this has a longer container internal path 69 00:03:28,270 --> 00:03:32,420 than just a /app, and this is not read only this named 70 00:03:32,420 --> 00:03:35,783 volume here, this feedback folder will be writable. 71 00:03:36,650 --> 00:03:39,460 Now we just need to do something similar for the temp 72 00:03:39,460 --> 00:03:43,000 folder, which means we need to add an additional volume. 73 00:03:43,000 --> 00:03:47,133 And that can be an anonymous volume to app/temp. 74 00:03:48,180 --> 00:03:50,450 That might be a good idea anyways, 75 00:03:50,450 --> 00:03:54,450 because even though that will not survive container removal 76 00:03:54,450 --> 00:03:58,700 and restarts, it actually will ensure that the container 77 00:03:58,700 --> 00:04:03,500 can write this temporary data to the host file system. 78 00:04:03,500 --> 00:04:06,510 And that actually will make it a bit more efficient 79 00:04:06,510 --> 00:04:10,520 internally I did talk about this before. 80 00:04:10,520 --> 00:04:13,210 And we did add this in the Dockerfile already. 81 00:04:13,210 --> 00:04:15,400 However, we should remove it there 82 00:04:15,400 --> 00:04:19,827 because we actually only overwrite our bind mount here. 83 00:04:21,370 --> 00:04:25,300 If we specify this anonymous volume here in the command line 84 00:04:25,300 --> 00:04:29,110 on Docker run, not when we do it inside of the Dockerfile. 85 00:04:29,110 --> 00:04:32,120 This is actually required to be specified 86 00:04:32,120 --> 00:04:35,300 in the command line on Docker run in order to ensure 87 00:04:35,300 --> 00:04:39,270 that it really overrides this bind mount here. 88 00:04:39,270 --> 00:04:40,660 So I removed it from the Dockerfile 89 00:04:40,660 --> 00:04:42,800 and instead added it here. 90 00:04:42,800 --> 00:04:45,990 And now with that, we should be good. 91 00:04:45,990 --> 00:04:49,520 We ensure that all the volumes where we need to write 92 00:04:49,520 --> 00:04:51,910 from inside the container are writable 93 00:04:51,910 --> 00:04:56,160 and the outer volumes where this is not required or not. 94 00:04:56,160 --> 00:05:00,443 So if we now hit Enter, we start this container. 95 00:05:02,050 --> 00:05:04,573 We can reload this page. 96 00:05:07,920 --> 00:05:11,080 And if we leave a number feedback here, 97 00:05:11,080 --> 00:05:14,640 that all works just as before, but now actually, 98 00:05:14,640 --> 00:05:18,810 we have this extra clarity regarding our bind mount. 99 00:05:18,810 --> 00:05:20,500 Now, of course, in this application, 100 00:05:20,500 --> 00:05:22,460 we never tried writing to it. 101 00:05:22,460 --> 00:05:24,690 But this is simply a good practice, you could say 102 00:05:24,690 --> 00:05:27,800 a good idea to ensure that you don't accidentally 103 00:05:27,800 --> 00:05:30,460 change files inside of your container 104 00:05:30,460 --> 00:05:34,870 which you shouldn't change, then this might be worth a look 105 00:05:34,870 --> 00:05:38,223 it might actually be a useful pattern to use here.