Now that you know a bit about running containers, how do we manage them?
Well, first you need to make sure that you provide Docker run
arguments behind run and before the name of the container image.
So if you want to do anything specific to Docker run, the arguments must
follow Docker run directly and cannot be behind the name of the container image.
One thing that you might want to do is to make containers accessible.
Even if my nginx container has been started on port 80, that's
port 80 within the container, but that's not reachable on the host.
If you want to access your containers, you need to configure port forwarding.
This is how you would do it. Docker run d to run it in the background P8080 to make it accessible on port 8080 externally.
So the first port is support on the host. The second port is port within the container.
Also important is the option to provide persistent storage to containers.
That is happening by creating a bind mount and you do so using
docker run D P8080 80v web var libhtml followed by the container image.
The interesting part here is the part where you are using the bind mount.
V is followed by the name of a directory on the host.
And after that we have varlib HTML that is the name of the directory within the container.
You should also know that if you are on an selinux system, and that goes for all
in the red hat family, some more configuration is required. In fact, it's not very complicated.
You put colon z behind the bind mount and then you should be okay. If
you want to provide environment variables to container applications, you can use the env argument.
So you use Docker run d n MariaDB root
password is password to start mariadb for instance.
Now, sometimes it's not going right when you try to start a container. So if a
container fails to start, it doesn't show in the Docker PS output. You can use Docker
PS a instead of and to find out why a container has failed to start. You
use Docker log's container name to investigate parameters that are used for starting the container.
You can use Docker inspect on either the container name or the image. Let me show you.
So let me get started with a docker run D P8080 for nginx
and then I can use docker ps to verify if it is listening.
And there we can see that it is. Here the automatically generated name
is modest gates and it is accessible on localhost port 8080.
So if I would use curl to localhost 8080
that is forwarding the traffic to the container.
Oh, then we do need curl. Well let's use sudo apt install curl curl between APT and snap. I would always
go for the APT packages because they are faster and if it's command line only, just use it. So here we
have the response that I'm getting from my curl command and as you can see it's welcome to nginx.
So that should be good enough.
Next I'm going to run the MariaDB container. So docker run D MariaDB and
let's just try to run it and figure out what is happening. Well the
first thing that is happening is that it can't find the MariaDB image locally,
so it needs to fetch it before it can start it.
Now it has done so. So how about Docker ps?
Well, Docker PS is showing a lot but no mariadb. Uh oh. So we need to
do some troubleshooting. Docker PS A and there we can see an overview of all the
containers that are currently running and also containers that have failed to get started.
So I can see this affectionate banzai and I want to know what is going on with this container.
And that is where Docker logs comes in.
So Docker logs is followed by the name or if you want the ID of the container and that
will give you output to the errors that were generated while starting the primary application in the container.
And what you see here is that the database is uninitialized and the password option
is not specified and you need to specify of mariad root password and much more.
So let's do this last command again. Docker run d
ENV mariadb root password is password followed by mariadb and
then when I use Docker PS then I can see
that my mariadb is up and running this time.
Now if you are starting an application like MariaDB then probably you
also want your MariaDB to be able to store data persistently.
The problem is that containers by default have non persistent data.
And that means that everything you write in the container is written inside the container
and if ever the container is deleted, all your data is gone. The simple solution
to fix that is by using the bind mount. So I'm going to create directories.
Let me create it in my home directory and I'm calling it web and
I'm going to run another MariaDB container using this bind mount option V home
student web and I'm going to mount that to varlib MYSQL because varlib mysql
that is where inside the container mariadb would normally create the the database.
So when the mariadb container is going to write internally to varlib mysql
it is going to end up in this home student web directory.
So let's use Docker PS to figure out if that worked all right. And that seems to
be working all right. It is up and running, and as a result, if I check the
contents of this web directory, you can see that in fact MariaDB data is available here.
Now, the nice thing about this is that if ever the container gets deleted, your data will exist persistently.
And that concludes our short introduction to containers.
Check out my Getting Started with Containers Recorded Video Course if you want to know more.