Now we have just one last subject to look at as far as Docker is concerned,
and that's our Dockerfile with an uppercase D.
If we move into our web directory,
it doesn't really matter where we are but it kind of makes sense that we use
our web directory because we're going to build a web image.
We're using any text editor that we like, I'm using Vim, we can edit
our Dockerfile. Don't forget that uppercase D.
Inside of this,
we can then use the from clause to say which image that we start with.
We can then go through and run any commands that we want.
Here we're updating our apt cache and installing the
NGINX web server into our Ubuntu image.
Now, our web server is going to be listening on port 80,
but to make the container listen on port 80,
we have to expose the port to the operating system.
We add in our webpage,
we can reference it just as index.html because we're in the web directory,
and the directory that we need to add it to when we're
working in Ubuntu and NGINX is var/www/html.
The final line, the command,
is the command that is going to run when the container starts.
It's not like a normal service that is going to rely
on systemd to start the service, the service is run by the container.
So we run nginx with the option ‑g and daemon off.
But don't forget the semicolon after daemon off.
We can always research the commands needed to start a
service by looking on the vendor website.
Now with this done, we can then use the docker build command,
‑t for the tag, the name we want to give the image,
and then specifying the directory.
We're using dot, so don't forget the dot,
it is part of the command referencing our current directory.
Now really to see this in action,
we need to start looking at how we build our own images using the Dockerfile.
So come on,
let's get our Bob the Builder hat on and see if we
can build ourselves some images.
Now we're working then again as our standard user, a member of the Docker group.
If we move into the web directory,
we can see we've got just our index page there.
Now this makes a good project directory to add in our Dockerfile.
So we're going to create the Dockerfile,
I'm using Vim, but you can use any editor,
but don't forget the uppercase D for Dockerfile.
So we can then go through and hit the big Enter key,
and we're going to begin by specifying from which image we want to start.
So we're going to start with an Ubuntu‑base image,
so FROM ubuntu,
but we could even use a term from scratch if we wanted
to start with absolutely nothing.
So once we then define where we're starting with,
we can then go through and start running commands.
And pretty much the first thing that we're going to do in Ubuntu is
make sure that the package cache is up to date,
so we can use apt update.
Using the double ampersand, we can say if that command succeeds okay,
we can go ahead and run our apt install,
making sure that we include the ‑y so it can be run non‑interactively,
and install our nginx web server package.
So we're installing NGINX into our Ubuntu system.
The NGINX server will be listening on port 80,
our web port,
but we do need to expose that to the operating
system through the EXPOSE command.
So this makes it then available to our host operating system.
We can add in our index page, so our index.html.
It's in the same web directory, so we can reference it just with its short name.
And in ubuntu, the NGINX web server's home directory is going to be var.www/html,
where it's going to look at serving its web pages from.
The last thing that we need to do is start our web server.
Now the web server isn't going to be managed through systemd,
we are going to start it through the container mechanism.
So when the container starts,
we're going to tell it to run nginx with the option ‑g.
So all of this is specified as a list with comma‑separated
items inside of our square brackets.
The final option,
daemon off and a semicolon, representing that's the end of the command,
and close our quotes, and close off our list.
But there you go,
we have the command that needs to be run to get our
NGINX web server up and running.
We can save our Dockerfile.
When we list the web directory now,
we see we have the Dockerfile and the index page,
and it's a simple matter now, so long as we can spell Docker,
of running our docker build statement, ‑t to give the tag or name,
and we're assigning myweb to it, and . just means the current directory.
So we're building from the Dockerfile in this current directory.
Now as we go through, we can see then that apt is running,
we're setting up our web server, and we're ready to go.
Of course, though, before I fire it up, I might just go through and check,
I don't think I deleted the container from before.
So if I go through and docker container, and then rm ‑f,
and web, I can leave containers running, but obviously
they can't have the same name.
So it just makes sense that once we've finished with a
container, we can get rid of it.
Docker run ‑d, so we're running it in detached mode the same as before.
We have to run everything the same as before, but we just
don't need to do our volume mapping anymore.
We still need though, of course, our port mapping.
So we can have port 8000 on our localhost map through to the exposed port 80.
We still need to assign it a name, rather than having the random name
assigned to it, but, of course, we're using the image now myweb. So
everything is the same, we're just not including the ‑v for our volume
mappings now because our data is added to our container. And we can
prove this by using our curl command, looking at our localhost on port
8000, and, of course, it looks exactly as it did before because it's
exactly the same web page, but this web page now is in‑built into our
image.
Now that makes the command line a little bit more easy to use but gives us less
flexibility. Of course, though, when we go through and look at our docker images
now, we do see the myweb image, so that's there.
And, of course, when we go through and run docker container ls, we're
able to see our container is up and running and the mapped port. So
everything is working as expected, but, of course, we want to leave this
system as clean as when we started.
So if we don't need the images anymore,
and we don't need the containers anymore, we can go
through and clean them up or delete them.
So we know we've already seen with a Docker container we can go through and
do a docker container. We've only got the one container, so I might as well
just use the rm ‑f and then the container name.
But we could also prune containers. When we look at the image,
if I go through and do an image prune ‑a, for all, and ‑f, to
force, so it doesn't prompt me, we can see now that all of those
images have been deleted.
And if we go through and take a look at our docker image
ls, we've now deleted all of the images.
But remember, on a running environment you might prefer to keep the
images because they can be used for other containers.
But there you go, you should be up and running and understanding a
lot more about Docker than when you started. But let's summarize what we've seen.