Instructor: And running this pushed image
on the remote machine, so on this EC2 instance
is super easy.
For this, we go back to the terminal where we are connected
to this remote EC2 instance via SSH.
And here my connection broke , so I will simply reconnect.
Here we go and here we then simply run Docker, run
with our remote repository image name,
we don't need to log in first if it's a public one, run this
in detached mode, make sure it's removed when stopped,
so basically what we learned for our local machine as well,
because it's the same Docker running on the remote machine.
So we can use the same way of running containers there
and very important, we all want to expose port 80 here
on the remote machine.
And now we can simply hit Enter and you might
get a permissions error, if you do simply add sudo
in front of that and there are better ways of doing that.
And there are ways of avoiding that you always have
to type sudo here, but to be very honest,
this is just a first basic example.
And we'll use a different deployment approach later anyways,
so I'm fine with just using this quick
and dirty approach here.
If you do use EC2 for a real project though,
you might want to dig deeper into their documentation
though and also learn more about Linux and how
to run commands there, because you will
have full responsibility for the security
of your EC2 instance and your remote machine,
I will come back to that later.
So simply add sudo here for now and hit Enter
and now this downloads this image from Docker Hub onto
this remote machine and then starts a container based on it.
And with Docker ps or to be precise sudo Docker ps,
we can see that this container is up and running here.
And that is a major step in the right direction
because now, our Dockerized Node application
is not just running locally on our local host machine,
but we did know started with the help of
this container on a remote machine.
And now the only remaining question for the moment at least
is how can we test it there.
To test this running application, let's go back
to the AWS console, close this window.
And here on your running instances, you will find
a IPv4 public IP, this is the public IP address
of your remote machine.
And you could also connect a custom domain if you wanted to,
the AWS documentation is the place
to go if you plan on using this for your real project.
For the moment, I will just use this IP.
And I will just enter this in the browser and you will see
that it doesn't do anything, it's not able
to contact our remote instance,
it's not able to load this site.
And that's not a bug, that's a security feature.
By default, your instance your EC2 instance,
is basically disconnected from everything
in the world wide web, so that no one is able
to connect except for you with SSH.
And this is controlled with a so called security group.
So in the EC2 dashboard, make sure you scroll down a bit
on the left side here to security groups and click on it.
And you might not have as many groups as I do here,
I do have a couple of groups and the top most group
is the last one that was created.
This was created by the EC2 Launch Wizard
and it is the security group attached to your instance.
If you're not sure you can go back to instances and they're
on the bottom part of the screen.
If you scroll down, you'll find a bunch
of information about this instance and you will also find
the attached security groups here.
And here you also find this Launch-Wizard-4
and you can click on it to be taken to that group.
And now this group basically controls which traffic
is allowed on our EC2 instance.
And there on the bottom part of the screen,
you find inbound and outbound rules, outbound rules controls
which traffic is allowed from the instance queue
somewhere else and here everything is allowed.
That is why Docker run worked, keep in mind that we ran
an image which was stored on Docker Hub,
so Docker on this remote machine, first of all
had to download that image from Docker Hub.
And that worked without any issues
because all outbound traffic is allowed,
the instance was able so the EC2 instance here
was able to communicate to Docker Hub.
Now for inbound rules that's different.
Here, we see all the traffic that is allowed from somewhere
in the world queue this instance and here only one port
is opened and that's port 22, which is the SSH port.
This is open for the entire world, that's what
this source says so not locked down
to a specific IP address but to the entire world.
And therefore the entire world is able
to connect to this instance through port 22.
That's why this key file is so important,
because it's this key file which again allows you
to identify yourself because anyone
can start a SSH connection but only you with this key file
will be able to do so successfully.
Alternatively or in addition, you could narrow down
the source to your specific local host machine IP address.
But it's not about port 22 here, this worked.
But we now also needs to allow HTTP traffic
to go into this instance, because we got
a running node application in there.
And this node application is listening on port 80,
which is the default HTTP port.
Now, it's nice that this container and the application
in there is publishing this port and listening on this port.
But the server, the remote hosting machine is still blocking
all traffic to that port.
So therefore, we need to edit the inbound rules of
this security group which is attached
to this EC2 instance and add a new rule here.
And here, simply choose HTTP, which automatically sets
this to port 80 and make sure anywhere,
so anyone on the entire world is able
to send HTTP requests to this instance.
And then click save rules.
Now, this updates the security group and that's
this second step, which we now actually executed
as a third step but again, the order doesn't matter
of this slide here.
And with this done, we can try talking
to our instance again.
So for this, again, make sure you have
this public IPv4 IP address, enter it in the browser
and now you should see,
"This works! Congratulations, this app seems to run fine".
And this is huge, because this means
that our locally developed application,
our Node application here, which we package up with Docker,
is successfully running on a remote server.
And we didn't need to install Node.js on that remote server
for that I really wanna highlight that,
we only installed Docker on that remote EC2 instance.
And then we used our finished image, which contained Node
and the application code to run our web application there.
And that is the big selling point of containers,
we didn't need to install and configure
a Node.js environment on that remote instance,
we just had to install Docker and the Docker image
and Stanford container then contained everything it needed
to run this application.
And that's why we can successfully visit
it here in the browser.
Now, of course this has one important implication,
it means that we really can run any Docker command
on this remote host and that includes Docker compose.
So if we had a multi container application,
which we would want to deploy, we could take
our compose file and also run this on a remote host.
Though of course, we might need to tweak
that compose file a little bit, to only work with images
which are pushed to Docker Hub and to not build images
on the fly as we're doing it
on our local development environment.
Because in production, we don't wanna build image
we only wanna use finished images.
But I will come back to multi container apps later
and we will indeed not run Docker compose
on our custom control instance later.
But I will explain why that is the case
when we reach that point.
For the moment, it's just important to understand
that you have full control over this instance over
this remote machine and therefore you can run all
the commands there, which you can also run locally
on your machine.