1 00:00:02,510 --> 00:00:04,770 So now we deployed multiple containers 2 00:00:04,770 --> 00:00:06,590 but still there are a couple of areas 3 00:00:06,590 --> 00:00:09,240 where we can improve our setup. 4 00:00:09,240 --> 00:00:12,610 Now let me start by adding a new goal again, 5 00:00:12,610 --> 00:00:15,250 so that we have one goal stored there, 6 00:00:15,250 --> 00:00:18,970 and then let me show you one first issue we might have. 7 00:00:18,970 --> 00:00:21,220 Let's say we change something in our goal, 8 00:00:21,220 --> 00:00:24,840 and if it's just an extra character in a log message, 9 00:00:24,840 --> 00:00:28,430 and therefore, we of course rebuild our image 10 00:00:28,430 --> 00:00:30,223 with the Docker build command. 11 00:00:31,750 --> 00:00:35,470 Thereafter I use the tag command to also 12 00:00:35,470 --> 00:00:38,950 take these latest changes into my repository image 13 00:00:38,950 --> 00:00:39,783 so to say. 14 00:00:39,783 --> 00:00:44,240 And then we push this updated image, to Docker hub. 15 00:00:44,240 --> 00:00:47,320 That's something we will most likely do at some point, 16 00:00:47,320 --> 00:00:49,630 when we are working on a project. 17 00:00:49,630 --> 00:00:51,090 We change something in code 18 00:00:51,090 --> 00:00:54,250 and we wanna deploy these latest changes. 19 00:00:54,250 --> 00:00:57,710 Now I already showed you how you can pick up these changes. 20 00:00:57,710 --> 00:01:01,330 All you need to do in the end is go to yours service, 21 00:01:01,330 --> 00:01:05,193 click update there, click force new deployment, 22 00:01:06,630 --> 00:01:07,830 and then skip to review, 23 00:01:08,770 --> 00:01:11,490 with all the default settings we used before, 24 00:01:11,490 --> 00:01:13,730 and click update service. 25 00:01:13,730 --> 00:01:16,230 And this updates to service, restarts it, 26 00:01:16,230 --> 00:01:18,570 and restarts the tasks in there. 27 00:01:18,570 --> 00:01:21,143 Based on the updated container images. 28 00:01:22,270 --> 00:01:26,190 That's why in your cluster, on your service, 29 00:01:26,190 --> 00:01:28,830 you'll temporarily see two tasks. 30 00:01:28,830 --> 00:01:31,169 The old one keeps on running until the new one 31 00:01:31,169 --> 00:01:34,570 is successfully deployed and up and running, 32 00:01:34,570 --> 00:01:37,890 after which the old one will offer some time 33 00:01:37,890 --> 00:01:41,010 shut down and be removed automatically. 34 00:01:41,010 --> 00:01:42,160 And this new one, 35 00:01:42,160 --> 00:01:45,483 is the new service based on the updated containers. 36 00:01:46,440 --> 00:01:49,353 So let's wait for this start up to finish, 37 00:01:50,270 --> 00:01:53,360 so that this new service, with the new tasks, 38 00:01:53,360 --> 00:01:57,570 based on the updated containers is done and is running. 39 00:01:57,570 --> 00:02:00,560 Let's wait for that to finish. 40 00:02:00,560 --> 00:02:02,010 And once it is up and running, 41 00:02:02,010 --> 00:02:04,080 let's wait until the auburn 42 00:02:04,080 --> 00:02:05,900 the old service shuts down. 43 00:02:05,900 --> 00:02:07,490 Which it will eventually do, 44 00:02:07,490 --> 00:02:08,830 now that the new service 45 00:02:08,830 --> 00:02:11,020 with the new containers is up and running. 46 00:02:11,020 --> 00:02:13,790 It can take a couple of minutes for that old service 47 00:02:13,790 --> 00:02:14,910 to shut down though. 48 00:02:14,910 --> 00:02:16,060 So let's wait for that. 49 00:02:17,460 --> 00:02:22,180 So now, after a couple of minutes, this old task was stopped 50 00:02:22,180 --> 00:02:23,310 and now keep in mind 51 00:02:23,310 --> 00:02:26,730 that previously we had one goal in our database. 52 00:02:26,730 --> 00:02:28,810 Now I'll send the same, GET request 53 00:02:28,810 --> 00:02:33,390 to the same domain, to the same URL and click send. 54 00:02:33,390 --> 00:02:35,170 And you see it works. 55 00:02:35,170 --> 00:02:38,010 We get back some goals, it's not crashing 56 00:02:38,010 --> 00:02:42,180 but the goal we stored in the database before is lost. 57 00:02:42,180 --> 00:02:43,730 And that of course happens, 58 00:02:43,730 --> 00:02:46,860 because our database is running in a container. 59 00:02:46,860 --> 00:02:50,030 And as long as a task is up and running, 60 00:02:50,030 --> 00:02:52,353 data indeed will be persistent. 61 00:02:53,230 --> 00:02:56,670 But if a task is shut down and restarted, 62 00:02:56,670 --> 00:03:00,080 which is what happens when you update a service 63 00:03:00,080 --> 00:03:03,810 for example, because you want to use a new container image, 64 00:03:03,810 --> 00:03:06,163 then all the data is lost. 65 00:03:07,040 --> 00:03:10,360 And that of course is something we saw locally already. 66 00:03:10,360 --> 00:03:13,900 If you stop a container and then you remove it, 67 00:03:13,900 --> 00:03:15,810 either with the rm command, 68 00:03:15,810 --> 00:03:20,450 or because the container was started with the --rm flac. 69 00:03:20,450 --> 00:03:23,280 Then all the data stored into container is lost. 70 00:03:23,280 --> 00:03:25,313 And the same thing is happening here. 71 00:03:26,210 --> 00:03:29,820 Now, locally dissolution wants to use a volume 72 00:03:29,820 --> 00:03:32,573 and we can do the same year on ECS. 73 00:03:33,440 --> 00:03:36,170 For that let's go to task definitions, 74 00:03:36,170 --> 00:03:38,940 and click on goals, and then pick the latest 75 00:03:38,940 --> 00:03:41,140 task definition which you find there. 76 00:03:41,140 --> 00:03:42,560 You might only have one. 77 00:03:42,560 --> 00:03:45,720 I created a couple of definitions off screen, 78 00:03:45,720 --> 00:03:47,080 pick the top most one 79 00:03:47,080 --> 00:03:51,800 and click create new revision to create a new configuration 80 00:03:51,800 --> 00:03:53,223 based on the previous one. 81 00:03:54,340 --> 00:03:57,160 Now in here, you can leave all the settings 82 00:03:57,160 --> 00:03:58,810 which you currently have, 83 00:03:58,810 --> 00:04:00,990 but if we scroll down to volumes, 84 00:04:00,990 --> 00:04:03,443 we now wanna add a volume. 85 00:04:04,420 --> 00:04:07,210 Now you can give this volume any name of your choice. 86 00:04:07,210 --> 00:04:11,270 Al name it data also because this was the name I used 87 00:04:11,270 --> 00:04:13,590 in my Docker compose file before, 88 00:04:13,590 --> 00:04:15,770 though you don't have to use the same name. 89 00:04:15,770 --> 00:04:17,620 This is totally detached. 90 00:04:17,620 --> 00:04:22,020 Still I will go for data, and pick EFS. 91 00:04:22,020 --> 00:04:25,690 EFS stands for elastic file system. 92 00:04:25,690 --> 00:04:29,200 And it's a number service offered by AWS, 93 00:04:29,200 --> 00:04:32,060 which allows us to attach a file system 94 00:04:32,060 --> 00:04:35,280 to our server less executed containers. 95 00:04:35,280 --> 00:04:38,560 And since we're using FARGET they are being executed 96 00:04:38,560 --> 00:04:41,200 without servers managed by us. 97 00:04:41,200 --> 00:04:45,390 EFS, Stanford will allow us to still attach hard drives. 98 00:04:45,390 --> 00:04:47,460 You could say QD containers. 99 00:04:47,460 --> 00:04:51,543 which will survive even if these containers are redeployed. 100 00:04:53,070 --> 00:04:55,835 Now, initially here we have no file system, 101 00:04:55,835 --> 00:04:57,760 which we could attach. 102 00:04:57,760 --> 00:05:01,800 Therefore, we should go to the Amazon EFS console here 103 00:05:01,800 --> 00:05:04,300 to create a new file system. 104 00:05:04,300 --> 00:05:06,970 On this page, you should see something like this 105 00:05:06,970 --> 00:05:10,293 and you can simply click create file system there. 106 00:05:11,210 --> 00:05:13,260 Now you can give this file system, 107 00:05:13,260 --> 00:05:16,780 any name of your choice and I'll name it, db storage. 108 00:05:16,780 --> 00:05:18,790 But again, this name is up to you 109 00:05:18,790 --> 00:05:22,510 and then you need to add a virtual private cloud. 110 00:05:22,510 --> 00:05:24,930 And here, you should use the same vpc 111 00:05:24,930 --> 00:05:27,800 you used for ECS before. 112 00:05:27,800 --> 00:05:32,450 Now don't click create yet though, instead click customize. 113 00:05:32,450 --> 00:05:36,820 And now here we need to customize one specific setting. 114 00:05:36,820 --> 00:05:40,430 You can confirm this first page and move on to the next one. 115 00:05:40,430 --> 00:05:42,730 But here on network access, 116 00:05:42,730 --> 00:05:45,730 here we need to change something. 117 00:05:45,730 --> 00:05:48,290 We should have to mount targets here. 118 00:05:48,290 --> 00:05:51,240 If you don't add them, and add these subnets, 119 00:05:51,240 --> 00:05:54,290 which you have in that vpc we chose. 120 00:05:54,290 --> 00:05:56,310 But then here under security groups, 121 00:05:56,310 --> 00:05:58,430 we need to change something. 122 00:05:58,430 --> 00:06:03,240 For that, go to the ECT service page, in a new browser tab. 123 00:06:03,240 --> 00:06:06,810 So did you keep that EFS tab open as well. 124 00:06:06,810 --> 00:06:10,230 And there go to security groups 125 00:06:10,230 --> 00:06:12,593 and create a new security group. 126 00:06:13,890 --> 00:06:15,230 You can give this any name you want. 127 00:06:15,230 --> 00:06:20,230 Al name it efs-sc for elastic file system security group. 128 00:06:21,180 --> 00:06:25,920 Added to this vpc, which you also use for your file system 129 00:06:25,920 --> 00:06:30,660 and for ECS, and then add an inbound rule. 130 00:06:30,660 --> 00:06:35,660 And there you wanna choose, NFS from the dropdown 131 00:06:37,480 --> 00:06:39,290 and here in the source, 132 00:06:39,290 --> 00:06:43,220 choose that auburn, that goals security group 133 00:06:43,220 --> 00:06:47,540 which you are using for managing your containers. 134 00:06:47,540 --> 00:06:50,420 This setup will allow the containers 135 00:06:50,420 --> 00:06:52,800 which run in this security group, 136 00:06:52,800 --> 00:06:55,970 to then talk to anything running in this 137 00:06:55,970 --> 00:07:00,970 to be created security group on port 2049. 138 00:07:01,250 --> 00:07:02,630 And it turns out 139 00:07:02,630 --> 00:07:06,550 that this is a port used by the elastic file system. 140 00:07:06,550 --> 00:07:09,320 That's why we're creating this new security group, 141 00:07:09,320 --> 00:07:11,660 for this elastic file system service, 142 00:07:11,660 --> 00:07:14,603 and for the file system we're generating there. 143 00:07:15,610 --> 00:07:18,493 So click create security group thereafter, 144 00:07:20,350 --> 00:07:21,977 and give it a description , 145 00:07:23,280 --> 00:07:26,310 like this, then click create. 146 00:07:26,310 --> 00:07:30,030 And once this is created, go back to the EFS wizard 147 00:07:30,030 --> 00:07:32,770 and choose this new security group. 148 00:07:32,770 --> 00:07:34,420 You might not see it there, 149 00:07:34,420 --> 00:07:37,280 simply go back and click next again then. 150 00:07:37,280 --> 00:07:39,480 And now you should be able to pick this, 151 00:07:39,480 --> 00:07:42,560 and use that instead of the default one. 152 00:07:42,560 --> 00:07:44,323 This security group. 153 00:07:46,130 --> 00:07:48,430 With that click next, 154 00:07:48,430 --> 00:07:52,670 confirm this screen and click next, and click create. 155 00:07:52,670 --> 00:07:55,973 And this now creates this file system. 156 00:07:57,240 --> 00:08:00,910 Now back in the ECS console now, 157 00:08:00,910 --> 00:08:03,810 we can now click this refresh button here, 158 00:08:03,810 --> 00:08:07,010 and now select this newly created file system, 159 00:08:07,010 --> 00:08:09,740 which we just generate that there. 160 00:08:09,740 --> 00:08:11,490 We could set an access point, 161 00:08:11,490 --> 00:08:14,950 which basically would allow us to target some nested path 162 00:08:14,950 --> 00:08:16,670 inside of the file system. 163 00:08:16,670 --> 00:08:19,550 You can check out the docs for more information on that. 164 00:08:19,550 --> 00:08:21,010 I will not do that. 165 00:08:21,010 --> 00:08:25,200 I will use the entire file system as my volume here, 166 00:08:25,200 --> 00:08:26,810 but if you had multiple volumes 167 00:08:26,810 --> 00:08:29,890 and you don't want to create multiple files systems. 168 00:08:29,890 --> 00:08:31,840 You could work with access points 169 00:08:31,840 --> 00:08:35,920 to have different nested folders on that single file system 170 00:08:35,920 --> 00:08:37,740 for the different volumes. 171 00:08:37,740 --> 00:08:40,920 But for this one volume, I'll go with this approach 172 00:08:40,920 --> 00:08:41,933 and click add. 173 00:08:42,930 --> 00:08:45,170 Now we defined the volume. 174 00:08:45,170 --> 00:08:48,280 It's a little bit as the finding the volume here 175 00:08:48,280 --> 00:08:51,350 at the end of the Docker compose file. 176 00:08:51,350 --> 00:08:53,160 It's not everything we wanna do. 177 00:08:53,160 --> 00:08:56,820 We now also wanna connect it to our container. 178 00:08:56,820 --> 00:08:59,730 So I'll go to the mongodb container now, 179 00:08:59,730 --> 00:09:03,590 and simply click on the name to open up this confliq 180 00:09:03,590 --> 00:09:06,710 and keep the configuration we used in the past, 181 00:09:06,710 --> 00:09:09,680 but go down to storage and logging. 182 00:09:09,680 --> 00:09:14,170 And here on mount points, you wanna select this data volume, 183 00:09:14,170 --> 00:09:18,680 we just add it and bind it to the data/ db path 184 00:09:18,680 --> 00:09:20,920 inside of the container. 185 00:09:20,920 --> 00:09:23,100 And that's the same path I used here 186 00:09:23,100 --> 00:09:24,913 in my Docker compose file. 187 00:09:25,750 --> 00:09:29,400 We need to use this path because inside of the container 188 00:09:29,400 --> 00:09:32,883 it is that path mongodb will write to. 189 00:09:34,340 --> 00:09:36,250 Click update thereafter. 190 00:09:36,250 --> 00:09:37,660 And once you did all of that, 191 00:09:37,660 --> 00:09:41,533 you can click create to create this new task revision. 192 00:09:42,520 --> 00:09:45,460 Then go to actions, update service, 193 00:09:45,460 --> 00:09:48,260 to force redeployment of your service, 194 00:09:48,260 --> 00:09:49,650 with this new revision. 195 00:09:49,650 --> 00:09:51,623 And you're almost good to go. 196 00:09:52,590 --> 00:09:56,690 I'm saying almost because here on platform version 197 00:09:56,690 --> 00:09:59,310 at least at the point of time, I'm recording this. 198 00:09:59,310 --> 00:10:00,660 You should pick version 1.4 199 00:10:02,230 --> 00:10:04,770 because the strange thing at the moment is, 200 00:10:04,770 --> 00:10:08,560 that latest is not really the latest version. 201 00:10:08,560 --> 00:10:12,440 1.4 is, yeah that is strange. 202 00:10:12,440 --> 00:10:14,020 It will change in the future. 203 00:10:14,020 --> 00:10:17,900 And therefore when you're viewing this latest might work. 204 00:10:17,900 --> 00:10:19,490 But if you try latest 205 00:10:19,490 --> 00:10:22,350 and running this service fails thereafter, 206 00:10:22,350 --> 00:10:23,800 choose 1.4. 207 00:10:23,800 --> 00:10:27,770 Which is a version, which supports EFS volumes. 208 00:10:27,770 --> 00:10:28,983 So for me, I choose 1.4. 209 00:10:29,830 --> 00:10:31,380 Four, it's a new deployment, 210 00:10:31,380 --> 00:10:35,070 click skip to revenue and click update service. 211 00:10:35,070 --> 00:10:39,130 And now this service restarts or to tasks and containers 212 00:10:39,130 --> 00:10:41,890 into service restart to be precise. 213 00:10:41,890 --> 00:10:43,590 And once they are restarted 214 00:10:43,590 --> 00:10:46,390 and one stays task, is the only running task, 215 00:10:46,390 --> 00:10:49,470 we should be able to use our application again. 216 00:10:49,470 --> 00:10:52,623 But now with a database where data persists. 217 00:10:53,510 --> 00:10:56,750 So let's wait for this new task to be up and running. 218 00:10:56,750 --> 00:10:59,430 And to be the only up and running task. 219 00:10:59,430 --> 00:11:01,763 And once that is the case, we can continue. 220 00:11:03,820 --> 00:11:07,210 Now, one stead all did finish starting up. 221 00:11:07,210 --> 00:11:08,720 We can go back to postman 222 00:11:08,720 --> 00:11:12,270 and send the request to our load balancing domain. 223 00:11:12,270 --> 00:11:14,600 Now, of course, we're not able to fetch any goals 224 00:11:14,600 --> 00:11:15,950 but we also don't get an error. 225 00:11:15,950 --> 00:11:18,400 We just don't have any goals in that database. 226 00:11:18,400 --> 00:11:22,270 but now it's for the last time that we don't have any goals. 227 00:11:22,270 --> 00:11:24,040 If we save a new goal now 228 00:11:24,040 --> 00:11:27,770 by sending this post request, we can of course get it. 229 00:11:27,770 --> 00:11:29,710 But now this will all be stored on, 230 00:11:29,710 --> 00:11:33,550 the elastic file system hard drive and therefore now, 231 00:11:33,550 --> 00:11:35,890 even if we restart everything 232 00:11:35,890 --> 00:11:38,450 and deploy brand new containers, 233 00:11:38,450 --> 00:11:40,980 as long as we keep that volume, 234 00:11:40,980 --> 00:11:43,560 our data will still be there. 235 00:11:43,560 --> 00:11:45,560 And of course, we can verify this. 236 00:11:45,560 --> 00:11:49,470 If we go to the goals app here and they are to our service 237 00:11:49,470 --> 00:11:53,560 if we click on update here, we can restart this service, 238 00:11:53,560 --> 00:11:55,810 and I wanna restart it on the same revision, 239 00:11:55,810 --> 00:11:59,650 as before, but I want to force a new deployment, 240 00:11:59,650 --> 00:12:02,400 and this will ensure that everything gets recreated 241 00:12:02,400 --> 00:12:07,220 and dead normally would lead to our data being lost. 242 00:12:07,220 --> 00:12:10,660 So here I'll skip to review and click update service, 243 00:12:10,660 --> 00:12:12,760 and then we can view the service. 244 00:12:12,760 --> 00:12:15,430 Now, again, it will take a couple of minutes now 245 00:12:15,430 --> 00:12:18,510 until all the previous tasks have stopped. 246 00:12:18,510 --> 00:12:21,970 And we only got that most recent task up and running, 247 00:12:21,970 --> 00:12:24,290 but eventually that will be the case. 248 00:12:24,290 --> 00:12:26,240 And when it is the case, 249 00:12:26,240 --> 00:12:29,397 we should still be able to send GET request. 250 00:12:29,397 --> 00:12:33,020 GET requests and get this first test goal here which I added 251 00:12:33,020 --> 00:12:36,150 because it's not just stored on the container 252 00:12:36,150 --> 00:12:38,310 or does temporary storage, 253 00:12:38,310 --> 00:12:41,890 but instead it will be stored on the elastic file system 254 00:12:41,890 --> 00:12:43,337 and that file system. 255 00:12:43,337 --> 00:12:46,340 And the date on there will not be deleted 256 00:12:46,340 --> 00:12:49,173 when we restart our tasks and containers. 257 00:12:50,300 --> 00:12:53,510 So now here, I got this new deployment coming up 258 00:12:53,510 --> 00:12:55,350 and to task being provisioned. 259 00:12:55,350 --> 00:12:58,770 And as I mentioned, it will take a couple of minutes 260 00:12:58,770 --> 00:13:01,540 until this will be the only running task. 261 00:13:01,540 --> 00:13:03,723 And I'll be back one status the case. 262 00:13:04,930 --> 00:13:07,330 And after a while, what you will notice 263 00:13:07,330 --> 00:13:10,310 is that actually our new deployment, 264 00:13:10,310 --> 00:13:12,090 doesn't really start up. 265 00:13:12,090 --> 00:13:16,600 Instead after a while, you'll have a bunch of stopped tasks 266 00:13:16,600 --> 00:13:19,840 and we can see the reason for why does it stop. 267 00:13:19,840 --> 00:13:23,720 If we go into one of the stop tasks, have a look at the logs 268 00:13:23,720 --> 00:13:26,680 and they're the mongodb container logs. 269 00:13:26,680 --> 00:13:29,515 And the error or the problem is something 270 00:13:29,515 --> 00:13:33,567 we can see here in one of the outputs here,. 271 00:13:34,460 --> 00:13:36,620 Unable to lock the lock file. 272 00:13:36,620 --> 00:13:40,950 Data db mongod lock resource temporarily unavailable 273 00:13:40,950 --> 00:13:43,850 and never mongod the instances already running on 274 00:13:43,850 --> 00:13:46,050 data db directory. 275 00:13:46,050 --> 00:13:49,270 The problem is that we're using rolling deployments 276 00:13:49,270 --> 00:13:51,970 which means a new task is started, 277 00:13:51,970 --> 00:13:54,760 whilst the previous one is still running. 278 00:13:54,760 --> 00:13:58,370 And only if the new task started successfully, 279 00:13:58,370 --> 00:14:01,040 and is up and running in a healthy mode, 280 00:14:01,040 --> 00:14:03,550 the previous task will be stopped. 281 00:14:03,550 --> 00:14:05,370 This is a good strategy, 282 00:14:05,370 --> 00:14:08,290 but here it means that it will have two tasks 283 00:14:08,290 --> 00:14:10,500 with two mongodb containers 284 00:14:10,500 --> 00:14:12,050 one container each. 285 00:14:12,050 --> 00:14:14,620 Which are trying to interact with one, 286 00:14:14,620 --> 00:14:18,570 and the same file system, at the same time. 287 00:14:18,570 --> 00:14:21,580 And that causes an error here 288 00:14:21,580 --> 00:14:23,550 because two databases, 289 00:14:23,550 --> 00:14:27,430 try to write to the same file in the same folder, 290 00:14:27,430 --> 00:14:29,210 at the same time. 291 00:14:29,210 --> 00:14:31,970 Now this is a pretty niche scenario though 292 00:14:31,970 --> 00:14:35,370 because we only have two tasks running at the same time, 293 00:14:35,370 --> 00:14:38,700 when we try to deploy a new task, right. 294 00:14:38,700 --> 00:14:40,900 Once it is deployed there only is one task 295 00:14:40,900 --> 00:14:43,090 and we'll never have that problem. 296 00:14:43,090 --> 00:14:46,690 So therefore it also means that both the currently running 297 00:14:46,690 --> 00:14:49,630 and d to be deployed to task, 298 00:14:49,630 --> 00:14:52,830 are trying to write to the exact same file, 299 00:14:52,830 --> 00:14:57,740 in the same folder on EFS, at the same time. 300 00:14:57,740 --> 00:15:00,940 And that won't happen for anything else you're doing 301 00:15:00,940 --> 00:15:02,320 in your application. 302 00:15:02,320 --> 00:15:05,770 If you have something where you try to write a file 303 00:15:05,770 --> 00:15:06,750 to the disc, 304 00:15:06,750 --> 00:15:09,060 when a user sends a request. 305 00:15:09,060 --> 00:15:12,180 That only will happen for the currently running task, 306 00:15:12,180 --> 00:15:15,200 not for the one which is currently to be deployed. 307 00:15:15,200 --> 00:15:18,380 And besides that, you might write to a different file 308 00:15:18,380 --> 00:15:20,550 for every request that's coming in. 309 00:15:20,550 --> 00:15:24,010 So you wouldn't write to the same file twice. 310 00:15:24,010 --> 00:15:27,140 It's really special to this database scenario. 311 00:15:27,140 --> 00:15:31,900 Where both d currently running and to be deployed task rides 312 00:15:31,900 --> 00:15:36,620 to the exact same file in the exact same folder, 313 00:15:36,620 --> 00:15:38,190 on EFS. 314 00:15:38,190 --> 00:15:41,330 And therefore, we could look for some work around, 315 00:15:41,330 --> 00:15:43,330 and we might be able to find . 316 00:15:43,330 --> 00:15:46,970 But actually I will replace the mongodb container 317 00:15:46,970 --> 00:15:49,560 with a different solution anyways. 318 00:15:49,560 --> 00:15:53,710 Therefore I'll not bother solving this niche problem 319 00:15:53,710 --> 00:15:57,940 but instead, I will for now just manually remove 320 00:15:57,940 --> 00:16:00,970 and stop the currently running task so that the 321 00:16:00,970 --> 00:16:05,043 two be deployed task has a chance of becoming active. 322 00:16:06,180 --> 00:16:08,610 Hence we can now wait a second, 323 00:16:08,610 --> 00:16:13,193 until this new task is successfully up and running. 324 00:16:15,150 --> 00:16:16,570 Once this is up and running, 325 00:16:16,570 --> 00:16:19,050 let's try fetching the goals again. 326 00:16:19,050 --> 00:16:21,590 And now you will see that one goal, 327 00:16:21,590 --> 00:16:25,090 which we posted earlier is still there. 328 00:16:25,090 --> 00:16:29,610 And it is still there because now the database files, 329 00:16:29,610 --> 00:16:32,380 get stored on a physical hard drive, 330 00:16:32,380 --> 00:16:35,490 which is detached from the containers. 331 00:16:35,490 --> 00:16:38,620 Put in other words, we are using volumes. 332 00:16:38,620 --> 00:16:40,990 And instead of Docker volumes, 333 00:16:40,990 --> 00:16:43,610 where Docker managed some folders 334 00:16:43,610 --> 00:16:45,860 somewhere on our host machine. 335 00:16:45,860 --> 00:16:49,310 We now set up a volume with help of EFS, 336 00:16:49,310 --> 00:16:50,800 where we indeed know, 337 00:16:50,800 --> 00:16:52,840 where this data will be stored, 338 00:16:52,840 --> 00:16:55,050 but we're still not doing that to change 339 00:16:55,050 --> 00:16:56,810 that data from outside. 340 00:16:56,810 --> 00:16:59,700 But instead to give that container a chance 341 00:16:59,700 --> 00:17:01,820 of storing data somewhere, 342 00:17:01,820 --> 00:17:04,773 where it will survive containers shuts down. 343 00:17:05,850 --> 00:17:09,394 Now, that is how we can deploy multiple containers 344 00:17:09,394 --> 00:17:13,820 at example of ECS, and how we can use volumes 345 00:17:13,820 --> 00:17:18,403 at the example of EFS being used in conjunction with ECS. 346 00:17:19,640 --> 00:17:20,600 As you can see, 347 00:17:20,600 --> 00:17:23,800 it's more than just riding a Docker compose file, 348 00:17:23,800 --> 00:17:26,270 but still overall, just a couple of steps, 349 00:17:26,270 --> 00:17:30,010 you have to memorize and not too complex at all. 350 00:17:30,010 --> 00:17:33,830 In the end, it's all about setting up this task definition, 351 00:17:33,830 --> 00:17:36,410 where we define all our containers. 352 00:17:36,410 --> 00:17:38,240 How they should be executed 353 00:17:38,240 --> 00:17:40,563 and any volumes we might wanna use. 354 00:17:41,610 --> 00:17:43,870 Nonetheless, as I already said, 355 00:17:43,870 --> 00:17:47,270 I will not continue using that mongodb container 356 00:17:47,270 --> 00:17:50,100 and I'll explain why and how to replace it, 357 00:17:50,100 --> 00:17:51,293 in the next lecture.