1 00:00:02,170 --> 00:00:04,300 Well, it's not that difficult. 2 00:00:04,300 --> 00:00:07,939 In the end in AWS ECS, 3 00:00:07,939 --> 00:00:10,830 we now just wanna get rid of that Mongo container 4 00:00:10,830 --> 00:00:13,910 and make sure that we run the node back in container 5 00:00:13,910 --> 00:00:17,000 such that we pass in the correct connection string 6 00:00:17,000 --> 00:00:19,770 and credentials and database name 7 00:00:19,770 --> 00:00:23,000 for our cloud MongoDB database. 8 00:00:23,000 --> 00:00:27,510 For that, we can go to task definitions on AWS ECS 9 00:00:27,510 --> 00:00:31,050 and go to our latest goals, task definition, 10 00:00:31,050 --> 00:00:32,973 and create a new revision. 11 00:00:33,840 --> 00:00:37,300 Now, here we can leave all this settings we had, 12 00:00:37,300 --> 00:00:41,180 but of course we wanna get rid of the MongoDB container. 13 00:00:41,180 --> 00:00:43,223 So simply delete it from that list. 14 00:00:44,100 --> 00:00:47,550 We therefor can also get rid of that volume 15 00:00:47,550 --> 00:00:50,530 and therefore we can, of course also get rid 16 00:00:50,530 --> 00:00:53,710 of all the other volume-related resources. 17 00:00:53,710 --> 00:00:56,570 So we can open EFS in a new tab, 18 00:00:56,570 --> 00:01:01,570 this EFS service, and delete this EFS file system, 19 00:01:02,620 --> 00:01:05,410 unless we also use it for something else, 20 00:01:05,410 --> 00:01:08,640 but here, since I only used it for MongoDB, 21 00:01:08,640 --> 00:01:11,270 I can delete this file system. 22 00:01:11,270 --> 00:01:15,030 And of course you can then also go to the EC2 area 23 00:01:15,030 --> 00:01:17,420 and delete the security group, 24 00:01:17,420 --> 00:01:20,530 which we created just for this file system. 25 00:01:20,530 --> 00:01:21,580 This one. 26 00:01:21,580 --> 00:01:22,860 You don't have to do that, 27 00:01:22,860 --> 00:01:25,850 but I like to keep my things cleaned up 28 00:01:25,850 --> 00:01:28,630 so that I don't have resources lying around 29 00:01:28,630 --> 00:01:30,113 which I don't need anymore. 30 00:01:31,340 --> 00:01:32,760 So with that cleaned up, 31 00:01:32,760 --> 00:01:36,390 back in the task definition page here, 32 00:01:36,390 --> 00:01:38,750 we now wanna change the configuration 33 00:01:38,750 --> 00:01:43,060 of goals-backend of this node, API container. 34 00:01:43,060 --> 00:01:45,780 It generally stays the way it is, 35 00:01:45,780 --> 00:01:50,050 but we now need to connect to MongoDB differently. 36 00:01:50,050 --> 00:01:53,150 Our URL is no longer local host, 37 00:01:53,150 --> 00:01:56,990 instead, this is now this cluster URL here. 38 00:01:56,990 --> 00:01:59,480 So we should use stat here. 39 00:01:59,480 --> 00:02:02,470 Now my username is this username 40 00:02:03,590 --> 00:02:07,453 and my password now is this password. 41 00:02:08,419 --> 00:02:10,532 So we should copy that over. 42 00:02:11,730 --> 00:02:15,140 In addition, we have to new MongoDB name variable 43 00:02:15,140 --> 00:02:19,970 for the database name, and that should be just goals here, 44 00:02:19,970 --> 00:02:23,400 not goals-dev, because that's my development database, 45 00:02:23,400 --> 00:02:26,253 but just goals here for production. 46 00:02:27,490 --> 00:02:30,470 And with that, we should be fine. 47 00:02:30,470 --> 00:02:32,970 Now we can click Update, 48 00:02:32,970 --> 00:02:36,020 and then create this new task revision, 49 00:02:36,020 --> 00:02:39,820 and then update our service to redeploy itself 50 00:02:39,820 --> 00:02:42,120 or rerun this task. 51 00:02:42,120 --> 00:02:45,460 Now we can also go back to the latest platform version 52 00:02:45,460 --> 00:02:48,420 since we're not using an EFS volume anymore, 53 00:02:48,420 --> 00:02:51,270 we can also click force new deployment 54 00:02:51,270 --> 00:02:55,373 and skip to review and update this service. 55 00:02:56,520 --> 00:03:00,550 And now this service will again replace a curly running task 56 00:03:00,550 --> 00:03:03,920 with a brand new one based on these new settings 57 00:03:03,920 --> 00:03:05,670 and once that is done, 58 00:03:05,670 --> 00:03:08,060 which again, will take a couple of minutes, 59 00:03:08,060 --> 00:03:11,110 we again will have our application up and running 60 00:03:11,110 --> 00:03:14,060 again with no data for the moment, 61 00:03:14,060 --> 00:03:18,790 but now connected to this cloud MongoDB service. 62 00:03:18,790 --> 00:03:21,010 And that of course means that in the future, 63 00:03:21,010 --> 00:03:24,760 we don't have to worry about this database at all. 64 00:03:24,760 --> 00:03:26,770 It's fully managed for us, 65 00:03:26,770 --> 00:03:29,750 the backups there are managed for us, and so on, 66 00:03:29,750 --> 00:03:31,600 and we can manage and configure it 67 00:03:31,600 --> 00:03:35,350 from inside this MongoDB Atlas screen, 68 00:03:35,350 --> 00:03:38,890 which has nothing to do with AWS and containers, 69 00:03:38,890 --> 00:03:42,010 but which can make a lot of sense to be used 70 00:03:42,010 --> 00:03:44,020 instead of database containers, 71 00:03:44,020 --> 00:03:48,490 since database containers bring their very own complexity. 72 00:03:48,490 --> 00:03:53,490 So with that, let's wait for this new task revision, 73 00:03:53,980 --> 00:03:56,090 this new task to be up and running, 74 00:03:56,090 --> 00:03:59,100 and therefore our updated node API container 75 00:03:59,100 --> 00:04:02,403 to be up and running, and let's then give it a try. 76 00:04:04,340 --> 00:04:08,670 So now only my latest task is up and running 77 00:04:08,670 --> 00:04:11,770 and I can now again, use PostMan to test it. 78 00:04:11,770 --> 00:04:14,920 The load balancing URL hasn't changed, 79 00:04:14,920 --> 00:04:16,720 so we should still be able to use that 80 00:04:16,720 --> 00:04:21,720 and send a request to goals, and does seems to fail. 81 00:04:22,460 --> 00:04:26,860 Now, actually, of course, I forgot one important thing. 82 00:04:26,860 --> 00:04:29,950 It's nice that I updated my Docker file 83 00:04:29,950 --> 00:04:32,870 within new a environment variable and my code, 84 00:04:32,870 --> 00:04:36,670 but what did I forget for deploying this to the cloud? 85 00:04:36,670 --> 00:04:39,310 Well, of course we need to rebuild our image 86 00:04:39,310 --> 00:04:41,720 and push it to Docker hub again, 87 00:04:41,720 --> 00:04:44,050 otherwise, we restart this task 88 00:04:44,050 --> 00:04:47,040 still based on the old node image, 89 00:04:47,040 --> 00:04:50,690 which still tries to connect to the MongoDB container 90 00:04:50,690 --> 00:04:52,000 in the end, 91 00:04:52,000 --> 00:04:54,160 or which didn't have the updated code 92 00:04:54,160 --> 00:04:56,410 for connecting to Atlas at least. 93 00:04:56,410 --> 00:04:59,990 It didn't use this new connection string and so on. 94 00:04:59,990 --> 00:05:02,180 So of course that is a mistake from my side, 95 00:05:02,180 --> 00:05:03,990 but it's also good to see that too. 96 00:05:03,990 --> 00:05:06,890 Well, keep in mind that you always need to do that. 97 00:05:06,890 --> 00:05:10,010 Repost your images if you changed your code, 98 00:05:10,010 --> 00:05:12,100 and that's why I left it in here, 99 00:05:12,100 --> 00:05:14,690 because, well, it is easy to overlook. 100 00:05:14,690 --> 00:05:18,850 So we wanna rebuild our backend image and give it a tag, 101 00:05:18,850 --> 00:05:21,940 ad now to save some time, I will immediately name it, 102 00:05:21,940 --> 00:05:26,430 academind/goals-node, 103 00:05:26,430 --> 00:05:31,330 which is my Docker hub repository name I've been using here, 104 00:05:31,330 --> 00:05:34,803 and built this image under the name, 105 00:05:36,410 --> 00:05:41,410 then log into Docker and then push academind/goals-node. 106 00:05:44,960 --> 00:05:48,580 So that this updated image with the updated source code 107 00:05:48,580 --> 00:05:50,650 is pushed to Docker hub, 108 00:05:50,650 --> 00:05:53,060 and that is required to ensure 109 00:05:53,060 --> 00:05:55,703 that its latest image is considered. 110 00:05:56,790 --> 00:06:01,790 So now with debt back in my ECS goals app service, 111 00:06:02,210 --> 00:06:04,660 we can go to that service, 112 00:06:04,660 --> 00:06:08,090 click update and force a new deployment, 113 00:06:08,090 --> 00:06:10,750 which will then pull the latest image. 114 00:06:10,750 --> 00:06:14,050 So click Update Service here, view the service, 115 00:06:14,050 --> 00:06:16,430 and now let's wait for this to finish. 116 00:06:16,430 --> 00:06:20,070 Let's wait for this latest version to now start up so that 117 00:06:20,070 --> 00:06:23,540 we now finally do have our container up and running again 118 00:06:23,540 --> 00:06:25,683 with that latest image being used. 119 00:06:27,700 --> 00:06:30,440 So now finally, that this is up and running, 120 00:06:30,440 --> 00:06:32,870 we can try sending this request again, 121 00:06:32,870 --> 00:06:37,200 and now this looks better and I can see my empty goals here. 122 00:06:37,200 --> 00:06:40,120 Adding a goal should of course, all the work now, 123 00:06:40,120 --> 00:06:43,720 so adding this first test goal, here it is. 124 00:06:43,720 --> 00:06:46,040 And now of course we can also fetch this. 125 00:06:46,040 --> 00:06:49,390 And since our database is now managed by a cloud provider 126 00:06:49,390 --> 00:06:52,480 and running totally detached from our containers, 127 00:06:52,480 --> 00:06:56,170 data will automatically persist because MongoDB Atlas 128 00:06:56,170 --> 00:06:58,520 will take care about that. 129 00:06:58,520 --> 00:07:01,760 And that's how we can move from a database container 130 00:07:01,760 --> 00:07:03,860 to a cloud provider. 131 00:07:03,860 --> 00:07:05,910 In this case, MongoDB Atlas, 132 00:07:05,910 --> 00:07:08,550 and why we might wanna do this. 133 00:07:08,550 --> 00:07:11,210 Again, if you are an expert on all of that, 134 00:07:11,210 --> 00:07:12,480 if you're a cloud expert, 135 00:07:12,480 --> 00:07:14,400 you can manage all of that on your own, 136 00:07:14,400 --> 00:07:16,490 you don't have to make that switch, 137 00:07:16,490 --> 00:07:18,630 but if you wanna build a big application 138 00:07:18,630 --> 00:07:21,860 and you're not a database administration expert, 139 00:07:21,860 --> 00:07:24,780 and you don't wanna deal with availability 140 00:07:24,780 --> 00:07:27,800 and multiple database nodes and backups, 141 00:07:27,800 --> 00:07:30,380 then using managed services like this 142 00:07:30,380 --> 00:07:31,883 can be worth a thought.