1 00:00:02,350 --> 00:00:04,370 Now you will notice one thing. 2 00:00:04,370 --> 00:00:07,100 If you have a look at the command I used 3 00:00:07,100 --> 00:00:08,860 for running this container, 4 00:00:08,860 --> 00:00:13,170 also locally here and later also once I deployed it, 5 00:00:13,170 --> 00:00:15,400 I'm not using a bind mount. 6 00:00:15,400 --> 00:00:16,950 Actually for this application 7 00:00:16,950 --> 00:00:19,350 I'm not using any volumes at all 8 00:00:19,350 --> 00:00:21,320 and there is a reason for that 9 00:00:21,320 --> 00:00:22,840 because there will be a difference 10 00:00:22,840 --> 00:00:25,630 between running a container in development mode 11 00:00:25,630 --> 00:00:28,100 and in production mode. 12 00:00:28,100 --> 00:00:32,060 In development so whilst we're working on the application, 13 00:00:32,060 --> 00:00:35,020 our container of course should encapsulate 14 00:00:35,020 --> 00:00:36,470 the runtime environment, 15 00:00:36,470 --> 00:00:40,620 but not and that's important, not necessarily the code. 16 00:00:40,620 --> 00:00:42,620 So we wanna ensure that the container 17 00:00:42,620 --> 00:00:46,130 has all the tools needed to run the application, 18 00:00:46,130 --> 00:00:49,600 but the code for the application during development 19 00:00:49,600 --> 00:00:51,980 we are actually fine if that's coming 20 00:00:51,980 --> 00:00:53,780 from outside the container 21 00:00:53,780 --> 00:00:57,260 and if the container is able to pick up the latest code 22 00:00:57,260 --> 00:00:59,200 without us rebuilding the image 23 00:00:59,200 --> 00:01:01,200 and restarting the container. 24 00:01:01,200 --> 00:01:05,459 And that's exactly what we enabled or what we added 25 00:01:05,459 --> 00:01:08,810 during development with help of bind mounts 26 00:01:08,810 --> 00:01:13,450 because with that we could bind a localhost project folder 27 00:01:13,450 --> 00:01:16,510 so on our local machine to some folder 28 00:01:16,510 --> 00:01:18,030 inside of the running container 29 00:01:18,030 --> 00:01:20,430 and therefore our latest project code 30 00:01:20,430 --> 00:01:22,900 was always exposed to that container 31 00:01:22,900 --> 00:01:24,990 and we could make changes to that code 32 00:01:24,990 --> 00:01:27,580 and see them being reflected instantly 33 00:01:27,580 --> 00:01:29,300 without restarting the container. 34 00:01:29,300 --> 00:01:32,170 And that's of course very convenient during development 35 00:01:32,170 --> 00:01:35,810 and therefore something you commonly do during development 36 00:01:35,810 --> 00:01:37,860 because it allows for instant updates 37 00:01:37,860 --> 00:01:39,840 and we don't have to restart and rebuild 38 00:01:39,840 --> 00:01:41,113 the image and container. 39 00:01:42,140 --> 00:01:46,350 But for production, so once we take our image and container 40 00:01:46,350 --> 00:01:49,090 and we move that to some remote machine 41 00:01:49,090 --> 00:01:52,410 where we then run it so that users from all over the world 42 00:01:52,410 --> 00:01:56,020 can see the application, there it's different. 43 00:01:56,020 --> 00:01:59,240 There the idea really is that the container 44 00:01:59,240 --> 00:02:03,630 works standalone and that it does not depend on 45 00:02:03,630 --> 00:02:07,920 any surrounding setup on the remote machine. 46 00:02:07,920 --> 00:02:11,450 The image and therefore the container based on the image 47 00:02:11,450 --> 00:02:14,850 should be the single source of truth you could say. 48 00:02:14,850 --> 00:02:17,430 That means we can rely on the fact 49 00:02:17,430 --> 00:02:21,220 that if we take that image and run a container based on it, 50 00:02:21,220 --> 00:02:24,110 we got everything this application needs. 51 00:02:24,110 --> 00:02:27,380 We don't also need to move some source code 52 00:02:27,380 --> 00:02:30,830 into a special folder on that remote machine. 53 00:02:30,830 --> 00:02:34,350 That would totally destroy the idea behind containers 54 00:02:34,350 --> 00:02:37,790 if we now all of a sudden again need to configure 55 00:02:37,790 --> 00:02:39,110 the hosting machine. 56 00:02:39,110 --> 00:02:41,160 We want to have everything, 57 00:02:41,160 --> 00:02:44,440 what our application needs inside of that container. 58 00:02:44,440 --> 00:02:47,430 There should be nothing, absolutely nothing, 59 00:02:47,430 --> 00:02:51,610 around that container on the hosting machine. 60 00:02:51,610 --> 00:02:55,470 And therefore when we build for production, 61 00:02:55,470 --> 00:02:59,390 we use copy instead of bind mounts. 62 00:02:59,390 --> 00:03:03,990 That means that we copy our source code into the image 63 00:03:03,990 --> 00:03:07,380 when we build the image and therefore the built image 64 00:03:07,380 --> 00:03:10,840 has the source code and the application environment. 65 00:03:10,840 --> 00:03:13,863 It has everything it needs to run this application. 66 00:03:14,830 --> 00:03:17,170 So copy instead of bind mounts, 67 00:03:17,170 --> 00:03:19,810 that is what we wanna use for production. 68 00:03:19,810 --> 00:03:23,030 And I mentioned this earlier in the course already 69 00:03:23,030 --> 00:03:25,480 when I first introduce bind mounts. 70 00:03:25,480 --> 00:03:29,173 I just want to highlight and emphasize it again here. 71 00:03:30,180 --> 00:03:32,480 Now it's also worth noting of course 72 00:03:32,480 --> 00:03:37,480 that we do have copy here and still on our local machine 73 00:03:37,600 --> 00:03:40,940 during development we could run this container 74 00:03:40,940 --> 00:03:43,450 and also provide a bind mount 75 00:03:43,450 --> 00:03:45,680 because the bind mount is not something 76 00:03:45,680 --> 00:03:47,350 set up in a Docker file. 77 00:03:47,350 --> 00:03:50,070 It's something we set up on the Docker run command 78 00:03:50,070 --> 00:03:53,303 with the -v flag as you learn throughout the course. 79 00:03:54,230 --> 00:03:57,900 And that is why we set it up on the Docker run command 80 00:03:57,900 --> 00:04:00,540 and not in the Docker file. 81 00:04:00,540 --> 00:04:03,330 By doing that, we can simply differentiate 82 00:04:03,330 --> 00:04:05,260 between development and production 83 00:04:05,260 --> 00:04:07,730 by running a different Docker run command. 84 00:04:07,730 --> 00:04:11,110 We don't have to encode anything into the Docker file 85 00:04:11,110 --> 00:04:14,180 and therefore we can use one and the same Docker file 86 00:04:14,180 --> 00:04:16,339 for production and for development. 87 00:04:16,339 --> 00:04:18,839 That's how we can ensure that we always 88 00:04:18,839 --> 00:04:21,839 work with exactly the same image 89 00:04:21,839 --> 00:04:25,223 and still we have more flexibility during development. 90 00:04:26,480 --> 00:04:29,280 Now of course if we used a Docker compose file, 91 00:04:29,280 --> 00:04:31,420 we might have that bind mount 92 00:04:31,420 --> 00:04:33,320 written into that compose file, 93 00:04:33,320 --> 00:04:35,300 but I will come back to compose files 94 00:04:35,300 --> 00:04:39,860 and how we deploy such multi container projects later. 95 00:04:39,860 --> 00:04:42,580 For the moment it's about one container, one image 96 00:04:42,580 --> 00:04:44,870 and then copy is your friend 97 00:04:44,870 --> 00:04:47,830 to ensure that we have one reproducible code 98 00:04:47,830 --> 00:04:51,090 and environment snapshot inside of the image 99 00:04:51,090 --> 00:04:53,430 because this ensures that every image 100 00:04:53,430 --> 00:04:57,260 runs without any extra surrounding configuration or code 101 00:04:57,260 --> 00:05:00,700 no matter where you run it as a container 102 00:05:00,700 --> 00:05:02,853 and that's really, really important.