- [Instructor] There are a great many more options available
to Dockerfiles than I covered in the previous examples,
so I'd just like to briefly go
through the rest of them here
so that you'll know about them when you need them.
We saw the FROM statement, which just says
what image do you start running from.
This should always be the first expression
in your Dockerfile.
It's actually okay to put multiples of them in a Dockerfile.
It means that the Dockerfile produces more than one image.
So, they look like FROM java version eight, build my image.
The MAINTAINER statement.
This is a bit of documentation that defines
who's responsible for creating this image
and who you should contact if it has bugs.
It looks like MAINTAINER Firstname Lastname,
you can put Middlename in there if you want,
and then an email address in the angle brackets.
The RUN statement we encountered,
that says run a command through the shell.
It also takes the command form, which we'll cover later.
RUN unzip the install.zip file into this directory
or RUN hello docker.
The ADD statement.
Really quite a useful expression.
We used it to add a local file,
but it can do a whole lot more.
It can do a whole lot more than just say ADD run.sh
to the image at the location /run.sh,
it can also add the content from an archive.
So, if you say ADD project.tar.gz to /install,
it doesn't copy the file tar.gz into that directory,
it notices that it's a compressed archive
and it uncompresses all the files in that archive
to that directory.
So, it automatically uncompresses tar files for you.
It also works with URLs.
You can say ADD the thing that you download
from this big URL to /project.
That would cause project.rpm to get download
and put in project/project.rmp.
It's a very versatile expression and well worth exploring.
The Environment statement sets environment variable both
for the duration of the Dockerfile,
so while your image is building,
and those environment variables will still be set
in the resulting image.
So, you say, ENV DB_HOST=db.production.example.com
or DB_PORT is 5432.
The ENTRYPOINT and CMD statements.
We used the CMD statement previously in the examples.
ENTRYPOINT is much like CMD, but it specifies the beginning
of the expression to use when starting your container
and lets you tack more on the end.
So, if you container has an entry point of LS,
then anything you type when you say
Docker run my image name would be treated
as arguments to the LS command.
CMD specifies the whole command to run,
and if the person, when they're running the container,
types something after Docker run image name,
that will be run instead of CMD.
ENTRYPOINT gets added to when people add arguments
to your container and CMD gets replaced
when people add arguments to your container.
You can actually use both of them together.
If you have them both, they get strung together,
one after the other.
In general, if you're trying to make something
that looks like a program and you want people to not care
that it's running inside a Docker container,
ENTRYPOINT is for making your containers
look like normal programs.
CMD is probably what you want to use almost all the time,
unless you're trying to do that.
CMD and ENTRYPOINT and RUN can take commands
to run in two different forms.
The shell form looks like what you would normally
type into a shell, nano notes.txt,
and it will be run in a shell.
The exec form looks like this:
bin/nano, note the comma there, it's important, notes.txt,
and this causes nano to be run directly,
not surrounded by a call to a shell such as Bash,
so it's slightly more efficient.
In general, you can use whichever form looks better to you.
The EXPOSE statement maps ports into a container,
EXPOSE 8080.
We did this a lot in the previous examples
where we said -p 1234:1234.
Does the same thing.
The VOLUME statement defines shared volumes
or ephemeral volumes, depending on whether you have one
or two arguments.
If you have two arguments, it maps a host path
into a container path.
If you have one, it creates a volume
that can be inherited by later containers.
You should generally, in Dockerfiles,
avoid using shared folders with the host
because it means that this Dockerfile will
only work on your computer and you'll probably want
to share it around someday,
or at least run it on a different computer.
The WORKDIR statement sets the directory both
for the remainder of the Dockerfile
and for the resulting container when you run it.
It's like typing CD at the beginning
of every run expression after that,
so it's a useful expression to know about.
You say WORKDIR /install, then all the rest
of your run statements will happen in the install directory.
The USER statement says, I would like the commands
run in this container to run as the user Arthur,
or maybe that user's identified by number, USER 1000.
This can be useful if you have
shared network directories involved
that assume a fixed username or a fixed user number.
There are a great many more options.
I've covered only a few of them
that I want you to be aware of right off the bat,
but definitely head on over to the official
Docker reference page and look at the available commands
to Dockerfiles.
They're all spelled out here in a great deal
more detail than I can cover.