So over the last lectures
I showed you how you can deploy a dockerized application
to an AWS EC2 instance and how you can therefore run
your application in a container on a remote host
without installing any extra runtimes
or environments software on that host,
except for Docker, of course.
And that's why Docker is awesome.
Only Docker needs to be installed, no other tools,
it was super easy as you saw
uploading our code is very easy
since we simply pulled the latest image
and therefore we have to exact same app and environment
on our local machine as we have it on the remote machine
because in the end, it's all in the container.
Now that's why Docker is great.
But this specific way of deploying a Docker application
has a couple of disadvantages.
I like to call it the do-it-yourself approach
because we had to create that instance manually,
configure it manually, we had to connect to it manually,
install Docker on it manually,
we had to do a lot of steps on our own,
even though running the actual app
was still fairly easy in the end.
But the main thing you have to keep in mind,
if you use an approach as I showed it here,
so if you use your own remote server
which you started with help of a cloud hosting provider
like the EC2 instance here,
the main thing you have to keep in mind here
is that you fully own this remote machine.
You are fully responsible for it
and most importantly also for its security.
You are responsible for the configuration
of that remote machine,
you have to take care, it's powerful enough.
You have to replace it with a more powerful one,
if you get more traffic,
you have to ensure that all the key system software
stays updated, even if you don't need
to install application specific software
you have to keep the operating system on it up-to-date,
you have full responsibility for that.
You also have to manage the network in which it is
the security groups and therefore the firewall,
and if you don't know what you're doing here
it's easy to set up an insecure EC2 instance
an insecure host, which could be hacked or abused.
In addition to that, which already is a major disadvantage
because you have to learn about things
which you don't natively know as a web developer.
In addition to that, SSHing to the machine
and connecting to it through SSH,
and then installing Docker there's on
works and is not horrible, but it's still a bit annoying.
You might want a deployment workflow
where you don't need to do that,
where you instead maybe can just run a command
on your local host machine or a couple of commands,
and this then automatically
moves your image to some remote host.
And maybe that remote host should also be managed
to ensure that you don't have to take care
about everything on your own there
that the system software do
operating system stays updated automatically.
Maybe you want such a more managed approach.
And I would indeed recommend
that you go for a more managed approach
because then you can focus on writing your source code
and building your dockerized application,
and you don't have to focus
on managing servers and firewalls and networks.
That requires a totally different set of skills,
and as a software and web developer,
you might not have that set of skills.
So that's why using this EC2 instance
was a nice first example, which I mainly used
to show you that you can't really just
install Docker on a different machine
and then use your container data as you used it locally,
but for real applications, bigger applications,
maybe all the applications with multiple containers,
it might not be ideal
unless you really know what you're doing.
Then if you do know what you're doing,
having this full control over everything
could indeed be an advantage.
But in many cases it will not be,
and therefore, throughout the rest of this module,
we are not going to use EC2,
instead I'll show you other services,
which we could use which are managed
and we therefore then,
don't have to take care about everything.