- [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.
- Installing Docker on Mac, Windows, and Linux
- Understanding the Docker flow
- Running processes in containers
- Managing, networking, and linking containers
- Working with Docker images, volumes, and registries
- Building Dockerfiles
- Managing networking and namespaces with Docker
- Building entire systems with Docker