{"id":1590,"date":"2019-03-22T05:57:28","date_gmt":"2019-03-22T05:57:28","guid":{"rendered":"http:\/\/kusuaks7\/?p=1195"},"modified":"2023-07-13T10:30:25","modified_gmt":"2023-07-13T10:30:25","slug":"learn-enough-docker-to-be-useful-part-3-a-dozen-dandy-dockerfile-instructions","status":"publish","type":"post","link":"https:\/\/www.experfy.com\/blog\/bigdata-cloud\/learn-enough-docker-to-be-useful-part-3-a-dozen-dandy-dockerfile-instructions\/","title":{"rendered":"Learn Enough Docker to be Useful – Part 3: A Dozen Dandy Dockerfile Instructions"},"content":{"rendered":"

This article is all about Dockerfiles. It\u2019s the third installment in a six-part series on Docker. If you haven\u2019t read\u00a0Part 1<\/a>, read it first and see Docker container concepts in a whole new light. Part 2<\/a>\u00a0is a quick run-through of the Docker ecosystem. In\u00a0future articles, I\u2019ll look at slimming down Docker images, Docker CLI commands, and using data with Docker.<\/p>\n

\n

Let\u2019s jump into the dozen Dockerfile instructions to know!<\/p>\n

<\/canvas><\/figure>\n

Jump in. True picture\u00a0\ud83d\ude09<\/p>\n

Docker Images<\/h3>\n

Recall that a Docker container is a Docker image brought to life. It\u2019s a self-contained, minimal operating system with application code.<\/p>\n

The Docker image is created at build time and the Docker container is created at run time.<\/p>\n

The Dockerfile is at the heart of Docker. The Dockerfile tells Docker how to build the image that will be used to make containers.<\/p>\n

Each Docker image contains a file named\u00a0Dockerfile\u00a0<\/em>with no extension. The Dockerfile is assumed to be in the current working directory when\u00a0docker build<\/code>\u00a0is called to create an image. A different location can be specified with the file flag (-f<\/code>).<\/p>\n

Recall that a container is built from a series of layers. Each layer is read only, except the final container layer that sits on top of the others. The Dockerfile tells Docker which layers to add and in which order to add them.<\/p>\n

Each layer is really just a file with the changes since the previous layer. In Unix, pretty much everything is a\u00a0file<\/a>.<\/p>\n

The base image provides the initial layer(s). A base image is also called a parent image.<\/p>\n

When an image is pulled from a remote repository to a local machine only layers that are not already on the local machine are downloaded. Docker is all about saving space and time by reusing existing layers.<\/p>\n

<\/canvas><\/figure>\n

A base (jumping) image<\/p>\n

A Dockerfile instruction is a capitalized word at the start of a line followed by its arguments. Each line in a Dockerfile can contain an instruction. Instructions are processed from top to bottom when an image is built. Instructions look like this:<\/p>\n

FROM ubuntu:18.04\r\nCOPY . \/app<\/code><\/pre>\n
Only the instructions FROM, RUN, COPY, and ADD create layers in the final image. Other instructions configure things, add metadata, or tell Docker to do something at run time, such as expose a port or run a command.<\/p>\n
In this article, I\u2019m assuming you are using a Unix-based Docker image. You can also used Windows-based images, but that\u2019s a slower, less-pleasant, less-common process. So use Unix if you can.<\/p>\n
Let\u2019s do a quick once-over of the dozen Dockerfile instructions we\u2019ll explore.<\/p>\n
A Dozen Dockerfile Instructions<\/h3>\n
FROM<\/code>\u200a\u2014\u200aspecifies the base (parent) image.
\nLABEL<\/code>\u00a0\u2014provides metadata. Good place to include maintainer info.
\nENV<\/code>\u200a\u2014\u200asets a persistent environment variable.
\nRUN<\/code>\u00a0\u2014runs a command and creates an image layer. Used to install packages into containers.
\nCOPY<\/code>\u200a\u2014\u200acopies files and directories to the container.
\nADD<\/code>\u200a\u2014\u200acopies files and directories to the container. Can upack local\u00a0.tar files.
\nCMD<\/code>\u200a\u2014\u200aprovides a command and arguments for an executing container. Parameters can be overridden. There can be only one CMD.
\nWORKDIR<\/code>\u200a\u2014\u200asets the working directory for the instructions that follow.
\nARG<\/code>\u200a\u2014\u200adefines a variable to pass to Docker at build-time.
\nENTRYPOINT<\/code>\u200a\u2014\u200aprovides command and arguments for an executing container. Arguments persist.
\nEXPOSE<\/code>\u200a\u2014\u200aexposes a port.
\nVOLUME<\/code>\u200a\u2014\u200acreates a directory mount point to access and store persistent data.<\/p>\n
Let\u2019s get to it!<\/p>\n
Instructions and\u00a0Examples<\/h3>\n
A Dockerfile can be as simple as this single line:<\/p>\n
FROM ubuntu:18.04<\/pre>\n
FROM<\/strong><\/a><\/h4>\n
A Dockerfile must start with a FROM instruction or an ARG instruction followed by a FROM instruction.<\/p>\n
The FROM\u00a0<\/em>keyword tells Docker to use a base image that matches the provided repository and tag. A base image is also called a\u00a0parent image<\/a>.<\/p>\n
In this example,\u00a0ubuntu\u00a0<\/em>is the image repository. Ubuntu is the name of an\u00a0official Docker repository<\/a>\u00a0that provides a basic version of the popular Ubuntu version of the Linux operating system.<\/p>\n
<\/p>\n
Linux mascot\u00a0Tux<\/span><\/p>\n
Notice that this Dockerfile includes a tag for the base image:\u00a018.04<\/em>\u00a0. This tag tells Docker which version of the image in the\u00a0ubuntu<\/em>\u00a0repository to pull. If no tag is included, then Docker assumes the\u00a0latest\u00a0<\/em>tag,\u00a0<\/em>by default. To make your intent clear, it\u2019s good practice to specify a base image tag.<\/p>\n
When the Dockerfile above is used to build an image locally for the first time, Docker downloads the layers specified in the\u00a0ubuntu<\/em>\u00a0image. The layers can be thought of as stacked upon each other. Each layer is a file with the set of differences from the layer before it.<\/p>\n
When you create a container, you add a writable layer on top of the read-only layers.<\/p>\n
<\/canvas><\/figure>\n
From the\u00a0Docker\u00a0Docs<\/a><\/p>\n
Docker uses a copy-on-write strategy for efficiency. If a layer exists at a previous level within an image, and another layer needs read access to it, Docker uses the existing file. Nothing needs to be downloaded.<\/p>\n
When an image is running, if a layer needs modified by a container, then that file is copied into the top, writeable layer. Check out the Docker docs\u00a0here<\/a>\u00a0to learn more about copy-on-write.<\/p>\n<\/section>\n
\n
\n
A More Substantive Dockerfile<\/h4>\n
Although our one-line image is concise, it\u2019s also slow, provides little information, and does nothing at container run time. Let\u2019s look at a longer Dockerfile that builds a much smaller size image and executes a script at container run time.<\/p>\n
Whoa, what\u2019s going on here? Let\u2019s step through it and demystify.<\/p>\n
The base image is an official Python image with the tag\u00a03.7.2-alpine3.8<\/em>. As you can see from its\u00a0source code<\/a>, the image includes Linux, Python and not much else. Alpine images are popular because they are small, fast, and secure. However, Alpine images don\u2019t come with many operating system niceties. You must install such packages yourself, should you need them.<\/p>\n
LABEL<\/strong><\/a><\/h4>\n
The next instruction is LABEL. LABEL adds metadata to the image. In this case, it provides the image maintainer\u2019s contact info. Labels don\u2019t slow down builds or take up space and they do provide useful information about the Docker image, so definitely use them. More about LABEL metadata can be found\u00a0here<\/a>.<\/p>\n
<\/canvas><\/figure>\n
ENV<\/a><\/h4>\n
ENV sets a persistent environment variable that is available at container run time. In the example above, you could use the ADMIN variable when when your Docker container is created.<\/p>\n
ENV is nice for setting constants. If you use a constant several places in your Dockerfile and want to change its value at a later time, you can do so in one location.<\/p>\n
<\/canvas><\/figure>\n
Environment<\/p>\n
With Dockerfiles there are often multiple ways to accomplish the same thing. The best method for your case is a matter of balancing Docker conventions, transparency, and speed. For example, RUN, CMD, and ENTRYPOINT serve different purposes, and can all be used to execute commands.<\/p>\n
RUN<\/a><\/h4>\n
RUN creates a layer at build-time. Docker commits the state of the image after each RUN.<\/p>\n
RUN is often used to install packages into an image.\u00a0<\/em>In the example above,\u00a0RUN apk update && apk upgrade<\/code>\u00a0tells Docker to update the packages from the base image.\u00a0<\/em>&& apk add bash<\/code>\u00a0tells Docker to install\u00a0bash<\/em>\u00a0into the image.<\/p>\n
apk\u00a0<\/em>stands for\u00a0Alpine Linux package manager<\/a>. If you\u2019re using a Linux base image in a flavor other than Alpine, then you\u2019d install packages with RUN\u00a0apt-get<\/em>\u00a0instead of\u00a0apk<\/em>.\u00a0apt<\/em>\u00a0stand for\u00a0advanced package tool<\/em>. I\u2019ll discuss other ways to install packages in a later example.<\/p>\n
<\/canvas><\/figure>\n
RUN<\/p>\n
RUN\u200a\u2014\u200aand its cousins, CMD and ENTRYPOINT\u200a\u2014\u200acan be used in exec form or shell form. Exec form uses JSON array syntax like so:\u00a0RUN [\"my_executable\", \"my_first_param1\", \"my_second_param2\"]<\/code>.<\/p>\n
In the example above, we used shell form in the format\u00a0RUN apk update && apk upgrade && apk add bash<\/code>.<\/p>\n
Later in our Dockerfile we used the preferred exec form with\u00a0RUN [\"mkdir\", \"\/a_directory\"]<\/code>\u00a0to create a directory. Don\u2019t forget to use double quotes for strings with JSON syntax for exec form!<\/p>\n
COPY<\/a><\/h4>\n
The\u00a0COPY\u00a0.\u00a0.\/app<\/code>\u00a0<\/em>instruction tells Docker to take the files and folders in your local build context and add them to the Docker image\u2019s current working directory. Copy will create the target directory if it doesn\u2019t exist.<\/p>\n
<\/canvas><\/figure>\n
COPY<\/p>\n
ADD<\/strong><\/a><\/h4>\n
ADD does the same thing as COPY, but has two more use cases.\u00a0ADD can be used to move files from a remote URL to a container and ADD can extract local TAR files.<\/p>\n
I used ADD in the example above to copy a file from a remote url into the container\u2019s\u00a0my_app_directory<\/em>. The\u00a0Docker docs<\/a>\u00a0don\u2019t recommend using remote urls in this manner because you can\u2019t delete the files. Extra files increase the final image size.<\/p>\n
The\u00a0Docker docs<\/a>\u00a0also suggest using COPY instead of ADD whenever possible for improved clarity. It\u2019s too bad that Docker doesn\u2019t combine ADD and COPY into a single command to reduce the number of Dockerfile instructions to keep straight<\/p>\n
Note that the ADD instruction contains the\u00a0<\/code>\u00a0line continuation character. Use it to improve readability by breaking up a long instruction over several lines.<\/p>\n
CMD<\/strong><\/a><\/h4>\n
CMD provides Docker a command to run when a container is started. It does not commit the result of the command to the image at build time. In the example above, CMD will have the Docker container run the my_script.py<\/em>\u00a0file at run time.<\/p>\n
<\/canvas><\/figure>\n
That\u2019s a\u00a0CMD!<\/p>\n
A few other things to know about CMD:<\/p>\n