How to use dockerfile

How to use Dockerfiles

Account Information

Share with Your Friends

How to use Dockerfiles

How to use Dockerfiles

If you’re looking for the most efficient way of working with Docker images, Jack Wallen introduces you to the must-use Dockerfiles.

With Docker images, you can easily deploy containers without having to worry about maintaining the same overhead required by virtual machines. These containers can be pulled from the Docker Hub with ease, for easy use. Let’s say, for example, you want to pull down the latest Ubuntu image for development purposes. However, before you start development, there are a number of changes you need to make to the image (such as updating, upgrading, and adding the build-essential package to the mix). Now, what if you plan on needing that same customized image for a number of development projects? You could always pull the latest Ubuntu image and then manually run the commands to update, upgrade, and install build-essential.

Cloud: Must-read coverage

Or you could make use of Dockerfiles. A Dockerfile is a file used to build a Docker image to your specifics. With a Dockerfile constructed, you could then easily build the same image over and over, without having to walk through the process manually.

I want to show you how to craft a Dockerfile so you can make the process of building a specific image a no-brainer. The image we will create is as described above: The latest image of Ubuntu, updated and upgraded, and with the build-essential package installed. This will be a fairly simple example of how Dockerfiles are used.

The basics

The first thing you need to know is that the Dockerfile is a text file, named Dockerfile, that contains commands. The available commands are:

You do not have to use every command. In fact, I am going to demonstrate a Dockerfile using only FROM, MAINTAINER, and RUN.

Creating your Dockerfile

The first thing we’re going to do is create a new directory to work within; so open a terminal window and issue the command mkdir

/mydockerbuild. Change into that newly created directory with the command cd

/mydockerbuild. Now we create our Dockerfile with the command nano Dockerfile and add the following contents:

FROM ubuntu:latest
MAINTAINER NAME EMAIL

Where NAME is the name to be used as the maintainer and EMAIL is the maintainer’s email address.

Save and close that file.

Building the image

Now we build an image from our Dockerfile. This is run with the command (by a user in the docker group):

Where NAME is the name of the image to be built.

Say I want to build multiple images from this Dockerfile, one for web development, app development, and security development. I could build them with the following commands:

Do note the trailing period is necessary for each command.

Once the build completes, you can issue the command docker images to see all of your newly created images (Figure A).

Figure A

And that is all there is to using Dockerfiles. Granted, this is a very simplistic illustration, but it will give you the springboard by which you can create more complicated Dockerfiles and docker images.

Find out more

For more information on building and using Dockerfiles, I recommend reading this best practices piece from the official docker support page. Docker containers are a very powerful and flexible way to expand your devops and even the services and applications your company offers. Give Dockerfiles a try and see if they don’t make the creation of images significantly more efficient.

20 лучших практик по работе с Dockerfile

Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.

Если вы знакомы с контейнеризованными приложениями и микросервисами, то скорее всего понимаете, что хотя ваши сервисы «микро«, но поиск уязвимостей и устранение проблем с безопасностью способен затруднить управление вашими сервисами, уже с приставкой «макро«.

К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.

Хорошо подготовленный Dockerfile исключает необходимость использовать привилегированные контейнеры, открывать порты, в которых нет необходимости, включать лишние пакеты и избегать утечки чувствительных данных. Старайтесь решить эти проблемы сразу, это поможет в дальнейшем сократить усилия на поддержку ваших приложений.

Избегать избыточных привилегий

Этот совет следует принципу наименьших привилегий, таким образом ваше приложение получает доступ только к тем ресурсам и данным, которые ему необходимы для работы.

1. Rootless контейнеры

Отчет sysdig показал, что 58% образов выполняют процесс в контейнере от root (UID 0). Рекомендуем избегать этого. Существует очень небольшой круг задач, для решения которых нужно запускать контейнер от root, поэтому не забывайте добавлять команду USER и менять UID пользователя на non-root.

Более того ваша среда выполнения контейнеров может по умолчанию блокировать запуск процессов в контейнере от имени root (например, Openshift требует дополнительные SecurityContextConstraints ).

Чтобы настроить non-root контейнер вам потребуется выполнить несколько дополнительных шагов в вашем Dockerfile.

Необходимо убедится, что пользователь, указанный в команде USER существует внутри контейнера.

Предоставить необходимые разрешения на объекты файловой системы, которые процесс читает или записывает.

Вы можете увидеть контейнеры, которые начинаются как root, а затем используют gosu или su-exec для перехода к обычному пользователю.

Если необходимо выполнить команду от имени root, вы можете использовать sudo.

Приведенные рекомендации, намного лучше запуска от имени root, но они работают не во всех окружениях, например OpenShift.

2. Не делайте привязку к определенному UID

Запускайте контейнеры без полномочий root, но также не делайте этот UID пользователя обязательным. Почему?

OpenShift по умолчанию использует произвольные UID при запуске контейнеров.

Возникнут проблемы при запуске этого контейнера с UID отличающимся от myuser, так как приложение не сможет записывать в папку /myapp-tmp-dir folder.

Не нужно жестко задавать путь только для пользователя myuser. Вместо этого можно записать временные данные в /tmp (где любой пользователь может писать, благодаря разрешениям sticky bit). Сделайте ресурсы доступными для чтения (0644 вместо 0640) и убедитесь, что все работает, если UID измениться.

В этом примере наше приложение будет использовать путь из переменной среды APP_TMP_DATA. Путь /tmp позволяет приложению запускаться от любого UID и продолжить записывать временные данные в папку /tmp. Наличие пути в переменной окружения не обязательно, но позволяет избежать проблем при настройке и монтировании разделов для долговременного хранения данных.

3. Назначить root владельцем исполняемых файлов и запретить изменять эти файлы

Рекомендуется назначать root владельцем каждого исполняемого файла в контейнере, даже если он выполняется пользователем без полномочий root. Также исполняемые файлы не должны быть доступны на запись всем пользователям.

Это предотвратить возможность изменения существующих бинарных файлов и скриптов, что может быть использована при различных атаках. Следуя этой рекомендации контейнер должен оставаться неизменяемым. Такой контейнер не изменяет код приложения во время выполнения, что позволяет избежать ситуации, при которой запущенное приложение случайно или злонамеренно изменяется.

Следуя этой рекомендации старайтесь избегать подобной ситуации:

Уменьшение поверхности атаки

Старайтесь минимизировать размер образа.

4. Многоступенчатые сборки

Используйте многоступенчатые сборки (multi-stage builds), чтобы компилировать ваши приложения внутри контейнеров.

При таком подходе используется промежуточный контейнер, который содержит все необходимые инструменты для компиляции артефактов (таких как бинарные файлы). После этого вы копируете в итоговый образ только необходимы артефакты без лишних инструментов, зависимостей и временных файлов.

Хорошо подготовленная многоступенчатая сборка содержит лишь необходимые бинарные файлы и зависимости в итоговом образе и не содержит инструментов для сборки и промежуточных файлов. Это уменьшает поверхность атаки, уменьшая уязвимости.

Это безопасно, а также уменьшает размер образа.

Пример многоступенчатой сборки для приложения на go:

В этом Dockerfile на первом этапе мы создаем контейнер из образа golang:1.15, который содержит необходимые инструменты.

Мы можем скопировать исходный код и выполнить компиляцию.

Затем на втором этапе мы создаем новый контейнер основанный на образе Debian distroless (см. следующий совет).

Итоговый образ будет содержать оптимальный набор библиотек из образа образе Debian distroless и исполняемый файл приложения. При этом образ не содержит инструментов для компиляции, не содержит исходный код.

5. Distroless, from scratch

Лучшим вариантом будет создание контейнера с нуля (scratch), но этот вариант подходит только для бинарных файлов, которые на 100% статичны.

Например, вы используете базовый образ ubuntu:xenial

При проверке образа сканером sysdig inline scanner были обнаружены более 100 уязвимостей. При этом большинство пакетов, содержащих уязвимости, скорее всего вам никогда не потребуются.

Нужен ли вам компилятор gcc или совместимость с systemd в вашем контейнере? Скорее всего нет. То же самое касается dpkg или bash.

Тогда он содержит только базовый набор пакетов, включая библиотеки libc, libssl и openssl.

Для компилируемых приложений, таких как Go, которым не нужна libc, можно использовать более компактный образ:

6. Используйте проверенные базовые образы

Внимательно выбирайте базовые образы.

Ваши контейнеры основанные на непроверенных и неподдерживаемых образах унаследуют все проблемы и уязвимости из этих базовых образов.

Следуйте приведенным рекомендациям при выборе базового образа:

Официальные и проверенные образы из доверенных репозиториев всегда предпочтительнее образов неизвестного происхождения.

Когда вы используете неофициальный образ проверяйте источник и Dockerfile. Создавайте свои собственные базовые образы. Нет гарантий, что образ из публичного репозитория действительно создан из указанного Dockerfile. Так же нет уверенности, что он обновляется.

Но иногда даже официальные образы могут не подойти из соображений безопасности или большого размера. В качестве примера сравните официальный образ node и bitnami/node. Последний предлагает различные версии поверх дистрибутива minideb. Образы часто обновляются с учетом последних исправлений ошибок, подписываются с помощью Docker Content Trust и проходят сканирование безопасности для отслеживания известных уязвимостей.

7. Своевременно обновляйте образы

Используйте базовые образы, которые регулярно обновляются, так же обновляйте ваши образы, основанные на них.

Процесс обнаружение уязвимостей непрерывен, поэтому правильным подходом будет регулярное обновление с учетом последних исправлений безопасности.

При этом нет необходимости стараться всегда использовать последнюю версию, которая может содержать критические уязвимости, но следует придерживаться стратегии версионирования:

Придерживайтесь стабильных или long-term версий поддержки, которые быстро и часто предоставляют исправления безопасности.

Будьте готовы отказаться от старых версий и выполнить миграцию до того, как закончится срок поддержки текущей версии вашего базового образа, и она перестанет получать обновления.

Кроме того, периодически пересобирайте свои собственные образы используя аналогичную стратегию, чтобы получить последние пакеты из базового дистрибутива, Node, Golang, Python и т. Д. Большинство менеджеров пакетов или зависимостей, таких как npm или go mod, предлагают способы указать диапазоны версий для следите за последними обновлениями безопасности.

8. Открытые порты

Используйте команду EXPOSE в Dockerfile только чтобы обозначить и задокументировать необходимые порты, затем используйте указанные порты в процессе запуска контейнеров.

Предотвращение утечки конфиденциальных данных

Будьте осторожны с конфиденциальными данными, при работе с контейнерами.

Приведенные ниже рекомендации помогут избежать случайной утечки данных при работе с контейнерами.

9. Учетные данные и конфиденциальность

Никогда не помещайте чувствительные данные или учетные данные в Dockerfile (через переменные окружения, аргументы или жестко заданными в команде).

Будьте очень осторожны при копировании файлов внутрь контейнера. Даже если файл удален в последующих командах Dockerfile, к нему все еще можно получить доступ на предыдущих слоях, поскольку на самом деле он не удаляется, а только «скрывается» в окончательной файловой системе. При создании образа следуйте этим рекомендациям:

Используйте конфигурационные файлы и монтируйте их в docker или Kubernetes secret

Кроме того, ваши образы не должны содержать конфиденциальную информацию или параметры конфигурации, которые относятся к определенному окружению (например, dev, qa, prod и т. д.).

10. ADD, COPY

Инструкции ADD и COPY предоставляют аналогичные функции в файле Dockerfile. Однако использование COPY является предпочтительным.

Используйте COPY всегда, если вам действительно не нужны возможности ADD, например, для добавления файлов из URL-адреса или из tar-файла. Процесс копирования данных будет более предсказуемым и менее подтверженым ошибкам.

В некоторых случаях предпочтительнее использовать инструкцию RUN вместо ADD, чтобы загрузить пакет с помощью curl или wget, извлечь его, а затем удалить исходный файл за один шаг, уменьшив количество слоев.

Многоступенчатые сборки также решают эту проблему и помогают следовать лучшим практикам, позволяя копировать файлы из архива, распакованного на предыдущем этапе.

11. Контекст сборки и dockerignore

Вот типичное выполнение сборки с использованием Docker с Dockerfile по умолчанию и контекстом в текущей папке:

Остерегайтесь!

Представьте, что у вас есть следующая команда внутри Dockerfile:

Это скопирует все внутри контекста сборки, что для «.». Например, включает сам Dockerfile.

В соответствии с Dockerfile best practice нужно создать подпапку, содержащую файлы, которые необходимо скопировать внутри контейнера, использовать ее в качестве контекста сборки и, когда это возможно, явно указывать инструкции COPY (избегайте подстановочных знаков). Например:

Даже если вы будете особенно осторожны с инструкциями COPY, весь контекст сборки отправляется демону докера перед запуском сборки образа. Это означает, что наличие меньшего и ограниченного контекста сборки сделает ваши сборки быстрее.

Прочие рекомендации

12. Порядок слоев

Помните, что порядок в инструкциях Dockerfile очень важен.

Поскольку RUN, COPY, ADD и другие инструкции создают новый слой контейнера, группировка нескольких команд вместе уменьшит количество слоев.

Можно использовать единственную команду RUN:

Кроме того, сначала разместите команды, которые с меньшей вероятностью будут изменены и которые легче кэшировать.

Лучше бы сделать:

Пакет nodejs с меньшей вероятностью изменится, чем исходный код нашего приложения.

Помните, что выполнение команды rm удаляет файл на следующем уровне, но он все еще доступен и к нему можно получить доступ, поскольку итоговый образ будет содержать все предыдущие слои.

Поэтому не стоит копировать конфиденциальные данные, даже если вы их удалите позже, они не будут видны в файловой системе контейнера, но по-прежнему будут легко доступны.

13. Metadata labels

Рекомендуется включать Dockerfile метки метаданных при создании образа.

Они помогут в управлении образами, например, включая версию приложения, ссылку на веб-сайт, как связаться с командой поддержки и многое другое.

14. Тестируйте ваши Dockerfile

Такие инструменты, как Haskell Dockerfile Linter (hadolint), могут обнаруживать ошибки в вашем Dockerfile и даже обнаружить проблемы внутри таких команд как RUN.

Рассмотрите возможность включения такого инструмента в ваши конвейеры CI.

Сканеры образов также способны обнаруживать уязвимости:

15. Локальное сканирование образов

Лучшей практикой безопасности является применение парадигмы «сдвиг влево» путем непосредственного сканирования ваших образов сразу после их создания в конвейерах CI перед отправкой в ​​реестр.

Периодически проверяйте наличие новых уязвимостей.

За пределами сборки образов

До сих пор мы сосредоточились на процессе создания образа и обсудили советы по созданию оптимальных файлов Docker. Но давайте не будем забывать о некоторых дополнительных предварительных проверках и о том, что происходит после создания образа: его запуск.

16. Docker port socket and TCP protection

17. Цифровая подпись образов

Включение проверки подписи отличается в каждой среде выполнения. Например, в докере это делается с помощью переменной окружения DOCKER_CONTENT_TRUST: экспорт DOCKER_CONTENT_TRUST = 1

18. Изменение тэгов

Теги являются непостоянной ссылкой на конкретную версию образа в определенный момент времени и могут измениться неожиданно и в любой момент.

19. Запуск как non-root

Ранее мы говорили об использовании пользователя без полномочий root при создании контейнера. Инструкция USER установит пользователя по умолчанию для контейнера, но за оркестратором или средой выполнения (например, docker run, kubernetes и т. д.) остается последнее слово в том, кто является пользователем запущенного контейнера.

Избегайте запуска вашей среды от имени пользователя root.

Openshift и некоторые кластеры Kubernetes по умолчанию будут применять ограничительные политики, предотвращая запуск root контейнеров. Избегайте соблазна работать с правами root, чтобы обойти проблемы с разрешениями или владением, и вместо этого устраните реальную проблему.

20. Включить проверки

При использовании Docker или Docker Swarm по возможности включайте инструкцию HEALTHCHECK в свой Dockerfile. Это критически важно для длительно работающих или постоянных служб, чтобы гарантировать их работоспособность и управлять перезапуском службы в противном случае.

Если вы запускаете образы в Kubernetes, используйте конфигурацию livenessProbe внутри определений контейнеров, поскольку инструкция Docker HEALTHCHECK не будет применяться.

How To Use DockerFile To Build Images For Docker Containers?

Docker containers run on and made changes to images. Generally, we use existing images which is like a template to create a new container. A lot of Linux distribution and software provide serve Docker images. But in some cases, we may need to create or enhance the existing image. Dockerfile can be used to create new images by providing instructions about the new images.

Dockerfile

Dockerfile is a simple text file that contains configuration for the Docker Image which will be created. Dockerfile contains Dockerfile Commands to change the properties of the image. We can also call a Dockerfile as a recipe for an image.

Here is a simple and lean Dockerfile. This file simple derive Base Image from current and latest Ubuntu Docker image and then updates the existing packages. After update is completed apache2 package is install. Generally Dockerfile’s are more complicated then this example as we will see below.

Build Dockerfile and Create New Image

After the DockerFile is created with the example content we can build our image with docker build command. We will require sudo because the current user does not have enough rights to create Docker image and we get root privileges.

We can see from image given Dockerfile instructions are executed line by line.

Run and Use Docker Image

Dockerfile Commands

ADD – Copy File From Local System Into Image

Add is very useful command which is used to copy files and folders from local system where docker runs into the image file. This can be used to copy special configuration, copy applications or data. We can also use URL’s for [SOURCE DIRECTORY] like https://www.poftut.com/data

Syntax

ARG – Provide Build Time Arguments

If we want to provide some argument in key value format in the build time we can use ARG directive. This argument provided with the build command. If we want to use default value we can set with ARG directive.

Syntax

In this example we will set build time argument VERSION with the default value 18.10

CMD – Run Command At Container Start

CMD is another useful command which is used to run commands at the start of the container. CMD will not run during image build. When new container is created this command will be run.

Syntax

In this example, we want to print Hello Poftut to the terminal when a new container is created from this image. The command will be echo and argument1 will be «Hello Poftut»

ENTRYPOINT – Run Single Command On Foreground

ENTRYPOINT is used to set single command which will run on foreground when a container starts. For example if we want to run a web server as container we can set the web server daemon as ENTRYPOINT.

Syntax

In this example we will start the httpd command when a container start.

ENV – Set Environment Variables In Key Value

ENV command can be used in a Dockerfile in order to set related image environment variables like key value pairs. This can be used like a database or communication channel with the image.

Syntax

In this example we will set the thread count which will be used by the daemon service as environment variable.

EXPOSE – Redirect Host Port To The Container Port

EXPOSE is used to redirect container port to the local system port which it runs. For example if run web server in a container TCP port 80 and want to use local system port 80 we can use EXPOSE.

Syntax

In this example we will redirect port 8080 to the local system port.

FROM – Use Given Base Image

Syntax

In this example we will use CentOS image from Docker Hub.

If we want we can also specify the version of the image like ubuntu18.10 etc.

MAINTAINER – Set Author Information or Image Metadata

MAINTAINER is used to set information like author name, email etc. Simply we can set some informational data for the container. This information is like comment in programming languages.

Syntax

In this example we will set the author email which is [email protected]

RUN – Run Command During Image Build

During the build of the image we need to take some actions. These actions can be taken with the RUN command. For example we can install a package with the apt command for a ubuntu image.

Syntax

In this example we will install apache2 package and then remove cache files.

USER – Set Username

The USER directive can be used to set UID or username which is to run the image.

Syntax

In this example we will set the user name as ismail

VOLUME – Mount Local System Directory In to Container

In some cases we may need to mount local system path or directory into the running container. We can use VOLUME directive in order to mount local system path like /home/ismail into the running container given path like /myhome etc.

Syntax

In this example we will mount local path /home/ismail into container path /myhome which will be created automatically.

WORKDIR – Change or Set Current Working Directory

As we can run commands during the build of image we may need also change working directory which can affect command execution. We will use WORKDIR to change current working directory.

Syntax

In this example we will set /tmp as the current working directory

What Is a Dockerfile: Everything You Need to Know

Last updated on Jul 13, 2022 73139

Docker Tutorial For Beginners: A Step-by-Step Guide

Getting Started With Docker

What is Docker: Advantages and Components

How To Install Docker on Windows? A Step-by-Step Guide

How to Install Docker on Ubuntu: A Step-By-Step Guide

Docker vs. Virtual Machine: Differences You Need to Know

What Is and What Are the Benefits of Docker Container?

What Is Dockerfile: Everything You Need to Know

What is Docker Compose: Benefits and Basic Commands

What is Docker Swarm: Features and Working

Introduction To Docker Networking: Advantages and Working

Top Docker Commands Tutorial: All You Need to Know

Top 25+ Docker Interview Questions and Answers [2022]

Table of Contents

Docker tool is a vital part of the configuration management tool in most of the global companies. Docker tool runs an application with the help of dockerfile with a high level of abstraction and security. Hence, many companies are extensively adopting the tool to achieve high network availability, service continuity, and service provision with high scalability.В

However, global news wire has confirmed that the demand for docker tools in the market will eventually grow from USD 217 million to USD 993 million by 2024. This growth is exponential.

The reason for Docker being so popular is Docker image, Docker container and Dockerfile. However, Docker Image can be created only with the help of Dockerfiles. Moving forward, let us understand docker and dockerfile in detail.

Explore the opportunities of working with the latest DevOps tools such as Docker, Git, Jenkins, and more by choosing our DevOps Engineer Certification Course. Grab your seat fast by contacting our admission counselor TODAY!

What is Docker?

Docker is a configuration management tool that is used to automate the deployment of software in lightweight containers. These containers help applications to work efficiently in different environments.

Post Graduate Program in DevOps

Features of Docker:

Docker container is a software package that has all the dependencies required to run an application.

Note: A Docker Image is a template of instructions used to create containers

What is a Dockerfile?

Before we discuss what is a Dockerfile, it is important to know what a Docker image is.В

Docker Image:

A Docker Image is a read-only file with a bunch of instructions. When these instructions are executed, it creates a Docker container.

Dockerfile:

Dockerfile is a simple text file that consists of instructions to build Docker images.

Mentioned below is the syntax of a Dockerfile:

Syntax

command argument argument1.

Example

# Print «Get Certified. Get Ahead»

Run echo «Get Certified. Get Ahead»

Now, let’s have a look at how to build a Docker image using a dockerfile.

FREE DevOps Certification Training

List of Docker Commands for Creating a Dockerfile

Before we create our first Dockerfile, it is important to understand what makes up the file.В

Dockerfile consists of specific commands that guide you on how to build a specific Docker image.В

The specific commands you can use in a dockerfile are:

FROM, PULL, RUN, and CMD

Mentioned below is an example of the dockerfile with the important commands

CMD python /file/file.pyВ

Have a look at the diagrammatic representation of how a dockerfile looks in a docker image:

Moving forward, let’s go through some of the most common Docker commands used while creating dockerfiles. Along with the syntax, we are explaining the commands with examples, so you can start experimenting with them right away.В

Syntax

ENTRYPOINT application «arg, arg1».

Example

Syntax

Example

Syntax

Example

Syntax

Example

DevOps Engineer Master’s Program

How to Build a Docker Image and Docker Container Using Dockerfile?

First of all, you should create a directory in order to store all the Docker images you build.

RUN apt-get update

CMD [«echo», «Welcome to Simplilearn»]

Build a Docker Image with Dockerfile

Let’s first declare the path where we will be storing the dockerfile simplidocker

Now, let’s build a basic image using a Dockerfile:В

docker build [location of your dockerfile]

Once the Docker image is created, you can verify by executing the command:

The output should show simpli_docker available in the repository.

Create a New Container

Now, create a Docker container from the Docker image we created in the previous step.

Let’s name the container “simplilearn” and create it with the command:

The message ‘Welcome to Simplilearn’ should appear in the command line, as seen in the image above.

Congratulations, you just created a Docker image and a Docker container using a Dockerfile.В

Enroll for theВ Docker Certified Associate Training CourseВ to learn the core Docker technologies like the Docker Containers, Docker Compose, and more.

Conclusion

With that, we have come to the end of the article, what is dockerfile. In this write-up, we discussed what docker is, what is dockerfile, syntax of dockerfile, important commands to create a docker image using a dockerfile, and how to build a docker image using a dockerfile.В

If you are keen on furthering your knowledge with an in-depth understanding of the Docker tool, Simplilearn can be an ideal destination for you. This Docker In-Depth Training Course helps interested individuals learn both the basic and advanced concepts of Docker. By completing this certification program, you will gain hands-on experience on creating flexible application environments with Docker.

Do you have any doubts about this topic? Please feel free to place your questions in the comments section of this ‘What Is Dockerfile’ article. Our subject matter experts will get back to you at the earliest, on the same!

Find our DevOps Engineer Online Bootcamp in top cities:

About the Author

Sana Afreen is a Senior Research Analyst at Simplilearn and works on several latest technologies. She holds a degree in B. Tech Computer Science. She has also achieved certification in Advanced SEO. Sana likes to explore new places for their cultures, traditions, and cuisines.

How to use dockerfile

This document covers recommended best practices and methods for building efficient images.

A Docker image consists of read-only layers each of which represents a Dockerfile instruction. The layers are stacked and each one is a delta of the changes from the previous layer. Consider this Dockerfile :

Each instruction creates one layer:

When you run an image and generate a container, you add a new writable layer (the «container layer») on top of the underlying layers. All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this writable container layer.

For more on image layers (and how Docker builds and stores images), see About storage drivers.

General guidelines and recommendations

Create ephemeral containers

The image defined by your Dockerfile should generate containers that are as ephemeral as possible. By «ephemeral», we mean that the container can be stopped and destroyed, then rebuilt and replaced with an absolute minimum set up and configuration.

Refer to Processes under The Twelve-factor App methodology to get a feel for the motivations of running containers in such a stateless fashion.

Understand build context

Inadvertently including files that are not necessary for building an image results in a larger build context and larger image size. This can increase the time to build the image, time to pull and push it, and the container runtime size. To see how big your build context is, look for a message like this when building your Dockerfile :

Pipe Dockerfile through stdin

Docker has the ability to build images by piping Dockerfile through stdin with a local or remote build context. Piping a Dockerfile through stdin can be useful to perform one-off builds without writing a Dockerfile to disk, or in situations where the Dockerfile is generated, and should not persist afterwards.

The examples in this section use here documents for convenience, but any method to provide the Dockerfile on stdin can be used.

For example, the following commands are equivalent:

You can substitute the examples with your preferred approach, or the approach that best fits your use-case.

Build an image using a Dockerfile from stdin, without sending build context

Omitting the build context can be useful in situations where your Dockerfile does not require files to be copied into the image, and improves the build-speed, as no files are sent to the daemon.

Note : Attempting to build a Dockerfile that uses COPY or ADD will fail if this syntax is used. The following example illustrates this:

Build from a local build context, using a Dockerfile from stdin

Build from a remote build context, using a Dockerfile from stdin

When building an image using a remote Git repository as build context, Docker performs a git clone of the repository on the local machine, and sends those files as build context to the daemon. This feature requires git to be installed on the host where you run the docker build command.

Use multi-stage builds

Multi-stage builds allow you to drastically reduce the size of your final image, without struggling to reduce the number of intermediate layers and files.

Because an image is built during the final stage of the build process, you can minimize image layers by leveraging build cache.

For example, if your build contains several layers, you can order them from the less frequently changed (to ensure the build cache is reusable) to the more frequently changed:

Install tools you need to build your application

Install or update library dependencies

Generate your application

A Dockerfile for a Go application could look like:

Don’t install unnecessary packages

To reduce complexity, dependencies, file sizes, and build times, avoid installing extra or unnecessary packages just because they might be «nice to have.» For example, you don’t need to include a text editor in a database image.

Each container should have only one concern. Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers. For instance, a web application stack might consist of three separate containers, each with its own unique image, to manage the web application, database, and an in-memory cache in a decoupled manner.

Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule. For example, not only can containers be spawned with an init process, some programs might spawn additional processes of their own accord. For instance, Celery can spawn multiple worker processes, and Apache can create one process per request.

Use your best judgment to keep containers as clean and modular as possible. If containers depend on each other, you can use Docker container networks to ensure that these containers can communicate.

Minimize the number of layers

In older versions of Docker, it was important that you minimized the number of layers in your images to ensure they were performant. The following features were added to reduce this limitation:

Where possible, use multi-stage builds, and only copy the artifacts you need into the final image. This allows you to include tools and debug information in your intermediate build stages without increasing the size of the final image.

Sort multi-line arguments

Whenever possible, ease later changes by sorting multi-line arguments alphanumerically. This helps to avoid duplication of packages and make the list much easier to update. This also makes PRs a lot easier to read and review. Adding a space before a backslash ( \ ) helps as well.

Here’s an example from the buildpack-deps image:

Leverage build cache

Starting with a parent image that is already in the cache, the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated.

In most cases, simply comparing the instruction in the Dockerfile with one of the child images is sufficient. However, certain instructions require more examination and explanation.

For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.

Once the cache is invalidated, all subsequent Dockerfile commands generate new images and the cache is not used.

Whenever possible, use current official images as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in size (currently under 6 MB), while still being a full Linux distribution.

You can add labels to your image to help organize images by project, record licensing information, to aid in automation, or for other reasons. For each label, add a line beginning with LABEL and with one or more key-value pairs. The following examples show the different acceptable formats. Explanatory comments are included inline.

Strings with spaces must be quoted or the spaces must be escaped. Inner quote characters ( » ), must also be escaped.

An image can have more than one label. Prior to Docker 1.10, it was recommended to combine all labels into a single LABEL instruction, to prevent extra layers from being created. This is no longer necessary, but combining labels is still supported.

The above can also be written as:

See Understanding object labels for guidelines about acceptable label keys and values. For information about querying labels, refer to the items related to filtering in Managing labels on objects. See also LABEL in the Dockerfile reference.

Split long or complex RUN statements on multiple lines separated with backslashes to make your Dockerfile more readable, understandable, and maintainable.

Always combine RUN apt-get update with apt-get install in the same RUN statement. For example:

Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions fail. For example, say you have a Dockerfile:

After building the image, all layers are in the Docker cache. Suppose you later modify apt-get install by adding extra package:

Docker sees the initial and modified instructions as identical and reuses the cache from previous steps. As a result the apt-get update is not executed because the build uses the cached version. Because the apt-get update is not run, your build can potentially get an outdated version of the curl and nginx packages.

Version pinning forces the build to retrieve a particular version regardless of what’s in the cache. This technique can also reduce failures due to unanticipated changes in required packages.

Below is a well-formed RUN instruction that demonstrates all the apt-get recommendations.

Some RUN commands depend on the ability to pipe the output of one command into another, using the pipe character ( | ), as in the following example:

In cases such as the dash shell on Debian-based images, consider using the exec form of RUN to explicitly choose a shell that does support the pipefail option. For example:

For external access, your users can execute docker run with a flag indicating how to map the specified port to the port of their choice. For container linking, Docker provides environment variables for the path from the recipient container back to the source (ie, MYSQL_PORT_3306_TCP ).

To make new software easier to run, you can use ENV to update the PATH environment variable for the software your container installs. For example, ENV PATH=/usr/local/nginx/bin:$PATH ensures that CMD [«nginx»] just works.

Lastly, ENV can also be used to set commonly used version numbers so that version bumps are easier to maintain, as seen in the following example:

Similar to having constant variables in a program (as opposed to hard-coding values), this approach lets you change a single ENV instruction to auto-magically bump the version of the software in your container.

Each ENV line creates a new intermediate layer, just like RUN commands. This means that even if you unset the environment variable in a future layer, it still persists in this layer and its value can be dumped. You can test this by creating a Dockerfile like the following, and then building it.

If you have multiple Dockerfile steps that use different files from your context, COPY them individually, rather than all at once. This ensures that each step’s build cache is only invalidated (forcing the step to be re-run) if the specifically required files change.

Because image size matters, using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead. That way you can delete the files you no longer need after they’ve been extracted and you don’t have to add another layer in your image. For example, you should avoid doing things like:

And instead, do something like:

The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command (and then use CMD as the default flags).

Let’s start with an example of an image for the command line tool s3cmd :

Now the image can be run like this to show the command’s help:

Or using the right parameters to execute a command:

This is useful because the image name can double as a reference to the binary as shown in the command above.

The ENTRYPOINT instruction can also be used in combination with a helper script, allowing it to function in a similar way to the command above, even when starting the tool may require more than one step.

For example, the Postgres Official Image uses the following script as its ENTRYPOINT :

This script uses the exec Bash command so that the final running application becomes the container’s PID 1. This allows the application to receive any Unix signals sent to the container. For more, see the ENTRYPOINT reference.

The helper script is copied into the container and run via ENTRYPOINT on container start:

This script allows the user to interact with Postgres in several ways.

It can simply start Postgres:

Or, it can be used to run Postgres and pass parameters to the server:

Lastly, it could also be used to start a totally different tool, such as Bash:

The VOLUME instruction should be used to expose any database storage area, configuration storage, or files/folders created by your docker container. You are strongly encouraged to use VOLUME for any mutable and/or user-serviceable parts of your image.

If a service can run without privileges, use USER to change to a non-root user. Start by creating the user and group in the Dockerfile with something like:

Users and groups in an image are assigned a non-deterministic UID/GID in that the «next» UID/GID is assigned regardless of image rebuilds. So, if it’s critical, you should assign an explicit UID/GID.

Lastly, to reduce layers and complexity, avoid switching USER back and forth frequently.

Examples of Docker Official Images

These Official Images have exemplary Dockerfile s: