1 00:00:01,525 --> 00:00:04,100 And running this pushed image 2 00:00:04,100 --> 00:00:07,310 on the remote machine, so on this EC2 instance 3 00:00:07,310 --> 00:00:09,040 is super easy. 4 00:00:09,040 --> 00:00:12,860 For this, we go back to the terminal where we are connected 5 00:00:12,860 --> 00:00:16,460 to this remote EC2 instance via SSH. 6 00:00:16,460 --> 00:00:20,163 And here my connection broke , so I will simply reconnect. 7 00:00:21,290 --> 00:00:26,290 Here we go and here we then simply run Docker, run 8 00:00:26,660 --> 00:00:30,123 with our remote repository image name, 9 00:00:31,020 --> 00:00:35,460 we don't need to log in first if it's a public one, run this 10 00:00:35,460 --> 00:00:39,370 in detached mode, make sure it's removed when stopped, 11 00:00:39,370 --> 00:00:42,530 so basically what we learned for our local machine as well, 12 00:00:42,530 --> 00:00:46,000 because it's the same Docker running on the remote machine. 13 00:00:46,000 --> 00:00:48,980 So we can use the same way of running containers there 14 00:00:50,000 --> 00:00:54,450 and very important, we all want to expose port 80 here 15 00:00:54,450 --> 00:00:56,670 on the remote machine. 16 00:00:56,670 --> 00:01:00,560 And now we can simply hit Enter and you might 17 00:01:00,560 --> 00:01:05,047 get a permissions error, if you do simply add sudo 18 00:01:05,900 --> 00:01:09,393 in front of that and there are better ways of doing that. 19 00:01:10,272 --> 00:01:13,020 And there are ways of avoiding that you always have 20 00:01:13,020 --> 00:01:15,640 to type sudo here, but to be very honest, 21 00:01:15,640 --> 00:01:18,050 this is just a first basic example. 22 00:01:18,050 --> 00:01:21,810 And we'll use a different deployment approach later anyways, 23 00:01:21,810 --> 00:01:23,730 so I'm fine with just using this quick 24 00:01:23,730 --> 00:01:25,230 and dirty approach here. 25 00:01:25,230 --> 00:01:28,730 If you do use EC2 for a real project though, 26 00:01:28,730 --> 00:01:31,850 you might want to dig deeper into their documentation 27 00:01:31,850 --> 00:01:35,680 though and also learn more about Linux and how 28 00:01:35,680 --> 00:01:38,020 to run commands there, because you will 29 00:01:38,020 --> 00:01:41,480 have full responsibility for the security 30 00:01:41,480 --> 00:01:44,840 of your EC2 instance and your remote machine, 31 00:01:44,840 --> 00:01:47,360 I will come back to that later. 32 00:01:47,360 --> 00:01:50,670 So simply add sudo here for now and hit Enter 33 00:01:50,670 --> 00:01:54,470 and now this downloads this image from Docker Hub onto 34 00:01:54,470 --> 00:01:58,700 this remote machine and then starts a container based on it. 35 00:01:58,700 --> 00:02:03,700 And with Docker ps or to be precise sudo Docker ps, 36 00:02:04,510 --> 00:02:08,830 we can see that this container is up and running here. 37 00:02:08,830 --> 00:02:12,710 And that is a major step in the right direction 38 00:02:12,710 --> 00:02:16,970 because now, our Dockerized Node application 39 00:02:16,970 --> 00:02:21,160 is not just running locally on our local host machine, 40 00:02:21,160 --> 00:02:23,850 but we did know started with the help of 41 00:02:23,850 --> 00:02:27,450 this container on a remote machine. 42 00:02:27,450 --> 00:02:30,780 And now the only remaining question for the moment at least 43 00:02:30,780 --> 00:02:34,070 is how can we test it there. 44 00:02:34,070 --> 00:02:37,020 To test this running application, let's go back 45 00:02:37,020 --> 00:02:40,640 to the AWS console, close this window. 46 00:02:40,640 --> 00:02:44,870 And here on your running instances, you will find 47 00:02:44,870 --> 00:02:49,870 a IPv4 public IP, this is the public IP address 48 00:02:50,400 --> 00:02:52,850 of your remote machine. 49 00:02:52,850 --> 00:02:56,740 And you could also connect a custom domain if you wanted to, 50 00:02:56,740 --> 00:02:59,120 the AWS documentation is the place 51 00:02:59,120 --> 00:03:03,310 to go if you plan on using this for your real project. 52 00:03:03,310 --> 00:03:05,820 For the moment, I will just use this IP. 53 00:03:05,820 --> 00:03:09,950 And I will just enter this in the browser and you will see 54 00:03:09,950 --> 00:03:13,310 that it doesn't do anything, it's not able 55 00:03:13,310 --> 00:03:15,990 to contact our remote instance, 56 00:03:15,990 --> 00:03:19,430 it's not able to load this site. 57 00:03:19,430 --> 00:03:23,160 And that's not a bug, that's a security feature. 58 00:03:23,160 --> 00:03:27,120 By default, your instance your EC2 instance, 59 00:03:27,120 --> 00:03:31,260 is basically disconnected from everything 60 00:03:31,260 --> 00:03:34,090 in the world wide web, so that no one is able 61 00:03:34,090 --> 00:03:37,283 to connect except for you with SSH. 62 00:03:38,170 --> 00:03:42,520 And this is controlled with a so called security group. 63 00:03:42,520 --> 00:03:45,650 So in the EC2 dashboard, make sure you scroll down a bit 64 00:03:45,650 --> 00:03:50,500 on the left side here to security groups and click on it. 65 00:03:50,500 --> 00:03:54,380 And you might not have as many groups as I do here, 66 00:03:54,380 --> 00:03:57,490 I do have a couple of groups and the top most group 67 00:03:57,490 --> 00:04:00,210 is the last one that was created. 68 00:04:00,210 --> 00:04:03,250 This was created by the EC2 Launch Wizard 69 00:04:03,250 --> 00:04:07,080 and it is the security group attached to your instance. 70 00:04:07,080 --> 00:04:11,660 If you're not sure you can go back to instances and they're 71 00:04:11,660 --> 00:04:14,550 on the bottom part of the screen. 72 00:04:14,550 --> 00:04:17,240 If you scroll down, you'll find a bunch 73 00:04:17,240 --> 00:04:20,540 of information about this instance and you will also find 74 00:04:20,540 --> 00:04:22,863 the attached security groups here. 75 00:04:23,770 --> 00:04:26,900 And here you also find this Launch-Wizard-4 76 00:04:26,900 --> 00:04:30,750 and you can click on it to be taken to that group. 77 00:04:30,750 --> 00:04:34,680 And now this group basically controls which traffic 78 00:04:34,680 --> 00:04:38,010 is allowed on our EC2 instance. 79 00:04:38,010 --> 00:04:41,050 And there on the bottom part of the screen, 80 00:04:41,050 --> 00:04:46,050 you find inbound and outbound rules, outbound rules controls 81 00:04:47,020 --> 00:04:50,620 which traffic is allowed from the instance queue 82 00:04:50,620 --> 00:04:54,033 somewhere else and here everything is allowed. 83 00:04:54,970 --> 00:04:59,970 That is why Docker run worked, keep in mind that we ran 84 00:05:00,460 --> 00:05:04,730 an image which was stored on Docker Hub, 85 00:05:04,730 --> 00:05:08,730 so Docker on this remote machine, first of all 86 00:05:08,730 --> 00:05:12,420 had to download that image from Docker Hub. 87 00:05:12,420 --> 00:05:15,020 And that worked without any issues 88 00:05:15,020 --> 00:05:18,270 because all outbound traffic is allowed, 89 00:05:18,270 --> 00:05:21,400 the instance was able so the EC2 instance here 90 00:05:21,400 --> 00:05:24,363 was able to communicate to Docker Hub. 91 00:05:25,330 --> 00:05:28,560 Now for inbound rules that's different. 92 00:05:28,560 --> 00:05:32,840 Here, we see all the traffic that is allowed from somewhere 93 00:05:32,840 --> 00:05:37,840 in the world queue this instance and here only one port 94 00:05:38,380 --> 00:05:43,013 is opened and that's port 22, which is the SSH port. 95 00:05:44,090 --> 00:05:47,230 This is open for the entire world, that's what 96 00:05:47,230 --> 00:05:50,330 this source says so not locked down 97 00:05:50,330 --> 00:05:54,490 to a specific IP address but to the entire world. 98 00:05:54,490 --> 00:05:56,960 And therefore the entire world is able 99 00:05:56,960 --> 00:06:01,540 to connect to this instance through port 22. 100 00:06:01,540 --> 00:06:04,320 That's why this key file is so important, 101 00:06:04,320 --> 00:06:08,420 because it's this key file which again allows you 102 00:06:08,420 --> 00:06:11,550 to identify yourself because anyone 103 00:06:11,550 --> 00:06:16,070 can start a SSH connection but only you with this key file 104 00:06:16,070 --> 00:06:18,970 will be able to do so successfully. 105 00:06:18,970 --> 00:06:22,950 Alternatively or in addition, you could narrow down 106 00:06:22,950 --> 00:06:27,233 the source to your specific local host machine IP address. 107 00:06:28,090 --> 00:06:32,160 But it's not about port 22 here, this worked. 108 00:06:32,160 --> 00:06:36,180 But we now also needs to allow HTTP traffic 109 00:06:36,180 --> 00:06:39,080 to go into this instance, because we got 110 00:06:39,080 --> 00:06:41,210 a running node application in there. 111 00:06:41,210 --> 00:06:45,050 And this node application is listening on port 80, 112 00:06:45,050 --> 00:06:47,623 which is the default HTTP port. 113 00:06:48,550 --> 00:06:51,670 Now, it's nice that this container and the application 114 00:06:51,670 --> 00:06:55,720 in there is publishing this port and listening on this port. 115 00:06:55,720 --> 00:06:59,900 But the server, the remote hosting machine is still blocking 116 00:06:59,900 --> 00:07:02,150 all traffic to that port. 117 00:07:02,150 --> 00:07:05,470 So therefore, we need to edit the inbound rules of 118 00:07:05,470 --> 00:07:07,830 this security group which is attached 119 00:07:07,830 --> 00:07:12,430 to this EC2 instance and add a new rule here. 120 00:07:12,430 --> 00:07:17,430 And here, simply choose HTTP, which automatically sets 121 00:07:18,480 --> 00:07:21,810 this to port 80 and make sure anywhere, 122 00:07:21,810 --> 00:07:25,040 so anyone on the entire world is able 123 00:07:25,040 --> 00:07:28,363 to send HTTP requests to this instance. 124 00:07:29,580 --> 00:07:32,840 And then click save rules. 125 00:07:32,840 --> 00:07:36,260 Now, this updates the security group and that's 126 00:07:36,260 --> 00:07:39,720 this second step, which we now actually executed 127 00:07:39,720 --> 00:07:43,020 as a third step but again, the order doesn't matter 128 00:07:43,020 --> 00:07:44,683 of this slide here. 129 00:07:46,290 --> 00:07:48,940 And with this done, we can try talking 130 00:07:48,940 --> 00:07:50,800 to our instance again. 131 00:07:50,800 --> 00:07:53,030 So for this, again, make sure you have 132 00:07:53,030 --> 00:07:58,030 this public IPv4 IP address, enter it in the browser 133 00:07:59,470 --> 00:08:00,967 and now you should see, 134 00:08:00,967 --> 00:08:05,917 "This works! Congratulations, this app seems to run fine". 135 00:08:07,198 --> 00:08:10,630 And this is huge, because this means 136 00:08:10,630 --> 00:08:13,610 that our locally developed application, 137 00:08:13,610 --> 00:08:18,340 our Node application here, which we package up with Docker, 138 00:08:18,340 --> 00:08:22,340 is successfully running on a remote server. 139 00:08:22,340 --> 00:08:26,560 And we didn't need to install Node.js on that remote server 140 00:08:26,560 --> 00:08:29,210 for that I really wanna highlight that, 141 00:08:29,210 --> 00:08:34,080 we only installed Docker on that remote EC2 instance. 142 00:08:34,080 --> 00:08:37,890 And then we used our finished image, which contained Node 143 00:08:37,890 --> 00:08:42,060 and the application code to run our web application there. 144 00:08:42,060 --> 00:08:45,810 And that is the big selling point of containers, 145 00:08:45,810 --> 00:08:48,650 we didn't need to install and configure 146 00:08:48,650 --> 00:08:52,340 a Node.js environment on that remote instance, 147 00:08:52,340 --> 00:08:56,310 we just had to install Docker and the Docker image 148 00:08:56,310 --> 00:09:00,470 and Stanford container then contained everything it needed 149 00:09:00,470 --> 00:09:02,780 to run this application. 150 00:09:02,780 --> 00:09:05,190 And that's why we can successfully visit 151 00:09:05,190 --> 00:09:07,790 it here in the browser. 152 00:09:07,790 --> 00:09:11,000 Now, of course this has one important implication, 153 00:09:11,000 --> 00:09:15,070 it means that we really can run any Docker command 154 00:09:15,070 --> 00:09:19,530 on this remote host and that includes Docker compose. 155 00:09:19,530 --> 00:09:22,630 So if we had a multi container application, 156 00:09:22,630 --> 00:09:25,450 which we would want to deploy, we could take 157 00:09:25,450 --> 00:09:30,300 our compose file and also run this on a remote host. 158 00:09:30,300 --> 00:09:32,750 Though of course, we might need to tweak 159 00:09:32,750 --> 00:09:36,960 that compose file a little bit, to only work with images 160 00:09:36,960 --> 00:09:41,120 which are pushed to Docker Hub and to not build images 161 00:09:41,120 --> 00:09:43,020 on the fly as we're doing it 162 00:09:43,020 --> 00:09:45,210 on our local development environment. 163 00:09:45,210 --> 00:09:47,880 Because in production, we don't wanna build image 164 00:09:47,880 --> 00:09:50,720 we only wanna use finished images. 165 00:09:50,720 --> 00:09:54,220 But I will come back to multi container apps later 166 00:09:54,220 --> 00:09:57,320 and we will indeed not run Docker compose 167 00:09:57,320 --> 00:10:00,450 on our custom control instance later. 168 00:10:00,450 --> 00:10:02,700 But I will explain why that is the case 169 00:10:02,700 --> 00:10:04,540 when we reach that point. 170 00:10:04,540 --> 00:10:07,420 For the moment, it's just important to understand 171 00:10:07,420 --> 00:10:11,040 that you have full control over this instance over 172 00:10:11,040 --> 00:10:14,170 this remote machine and therefore you can run all 173 00:10:14,170 --> 00:10:17,420 the commands there, which you can also run locally 174 00:10:17,420 --> 00:10:18,523 on your machine.