Туториал по Docker (билингв, для ИТ-переводчиков)

Содержание

1. Основы
2. Термины и концепции
3. Файлы Dockerfile
4. Уменьшение размеров образов и ускорение их сборки
5. Команды
6. Работа с данными

Содержание

1. Основы
2. Термины и концепции
3. Файлы Dockerfile
4. Уменьшение размеров образов и ускорение их сборки
5. Команды
6. Работа с данными

Источники:

Изучаем Docker, части 1 — 6 // Блог компании RUVDS.com
Learn Enough Docker to be Useful // Jeff Hale

При изучении тематики мы рекомендуем переводчику обращать внимание на три вещи, которые присутствуют в данном туториале:

отраслевые термины;
выражения с терминами;
стиль формулировок.

Дисклеймер: составители туториала не несут ответственности за возможные терминологические неточности, поэтому просим вас критически относиться к предлагаемым переводческим решениям. Если наше бюро, адаптируя эти материалы под переводчиков, нарушило ваши права, пожалуйста, напишите нам на bartov-e@yandex.ru.

1. Основы


1. Основы	1. The Conceptual Landscape

Технологии контейнеризации приложений нашли широкое применение в сферах разработки ПО и анализа данных. Эти технологии помогают сделать приложения более безопасными, облегчают их развёртывание и улучшают возможности по их масштабированию. Рост и развитие технологий контейнеризации можно считать одним из важнейших трендов современности.	Containers are hugely helpful for improving security, reproducibility, and scalability in software development and data science. Their rise is one of the most important trends in technology today.
Docker — это платформа, которая предназначена для разработки, развёртывания и запуска приложений в контейнерах. Слово «Docker» в последнее время стало чем-то вроде синонима слова «контейнеризация». И если вы ещё не пользуетесь Docker, но при этом работаете или собираетесь работать в сферах разработки приложений или анализа данных, то Docker — это то, с чем вы непременно встретитесь в будущем.	Docker is a platform to develop, deploy, and run applications inside containers. Docker is essentially synonymous with containerization. If you’re a current or aspiring software developer or data scientist, Docker is in your future.



Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.	Don’t fret if you aren’t yet up to speed — this article will help you understand the conceptual landscape — and you’ll get to make some pizza along the way.

Метафоры и Docker

Мы постоянно сталкиваемся с метафорами. Если заглянуть в словарь Ожегова, то окажется, что метафора — это «скрытое образное сравнение, уподобление одного предмета, явления другому».	First, I’m going to shed some light on Docker metaphors. Google’s second definition for Metaphor is what we want: a thing regarded as representative or symbolic of something else, especially something abstract.
Метафоры помогают нам ухватывать суть новых для нас явлений. Например, виртуальные контейнеры можно сравнить с обычными пластиковыми контейнерами. Такое сравнение, через сопоставление уже известных нам свойств обычных контейнеров со свойствами виртуальных контейнеров, поможет сначала с ними познакомиться, а потом и понять их сущность.	Metaphors help us make sense of new things. For example, the metaphor of a physical container helps us quickly grasp the essence of a virtual container.


Контейнер	A physical container

Как вы понимаете, мы собираемся начать разговор о Docker с понятия «контейнер».

Контейнер	Container

Как и обычный пластиковый контейнер, контейнер Docker обладает следующими характеристиками:	Like a physical plastic container, a Docker container:

1. В нём можно что-то хранить. Нечто может находиться либо в контейнере, либо за его пределами.	1. Holds things — Something is either inside the container or outside the container.
2. Его можно переносить. Контейнер Docker можно использовать на локальном компьютере, на компьютере коллеги, на сервере поставщика облачных услуг (вроде AWS). Это роднит контейнеры Docker с обычными контейнерами, в которых, например, перевозят разные милые сердцу безделушки при переезде в новый дом.	2. Is portable — It can be used on your local machine, your coworker’s machine, or a cloud provider’s servers (e.g. AWS). Sort of like that box of childhood knickknacks you keep moving with you from home to home.
3. В контейнер удобно что-то класть и удобно что-то из него вынимать. У обычного контейнера есть крышка на защёлках, которую надо снять для того, чтобы что-то положить в контейнер или что-то из него вынуть. У контейнеров Docker есть нечто подобное, представляющее их интерфейс, то есть — механизмы, позволяющие им взаимодействовать с внешним миром. Например, у контейнера есть порты, которые можно открывать для того, чтобы к приложению, работающему в контейнере, можно было бы обращаться из браузера. Работать с контейнером можно и средствами командной строки.	3. Has clear interfaces for access — Our physical container has a lid for opening and putting things in and taking things out. Similarly, a Docker container has several mechanisms for interfacing with the outside world. It has ports that can be opened for interacting through the browser. You can configure it to interact with data through the command line.
4. Если вам нужен контейнер, его можно заказать в интернет-магазине. Пустой контейнер можно купить, например, на сайте Amazon. В этот магазин контейнеры попадают от производителей, которые делают их в огромных количествах, используя пресс-формы. В случае с контейнерами Docker то, что можно сравнить с пресс-формой, а именно — образ контейнера, хранится в специальном репозитории. Если вам нужен некий контейнер, вы можете загрузить из репозитория соответствующий образ, и, используя его, этот контейнер создать.	4. Can be obtained from a remote location — You can get another empty plastic container from Amazon.com when you need it. Amazon gets its plastic containers from manufacturers who stamp them out by the thousands from a single mold. In the case of a Docker container, an offsite registry keeps an image, which is like a mold, for your container. Then when you need a container you can make one from the image.

Конечно, пластиковые контейнеры, в отличие от контейнеров Docker, никто вам не будет присылать бесплатно, да и когда вы их получите, они будут пустыми. А вот в контейнерах Docker всегда есть что-то интересное.	Unlike a virtual Docker container, a new plastic container from Amazon will cost you money and won’t come with a copy of your goods inside. Sorry 💸.

Живые организмы	Living Instance

Ещё один подход к размышлениям о контейнерах Docker заключается в сравнении их с экземплярами живых организмов. «Экземпляр» — это нечто, существующее в некоей форме. Это не просто код. Это код, который стал причиной существования чего-то большего, чем он сам, чего-то, образно говоря, живого. Как и другие живые организмы, экземпляры контейнеров появляются на свет, живут и умирают.	A second way you can think of a Docker container is as an instance of a living thing. An instance is something that exists in some form. It’s not just code. It’s code that has brought something to life. Like other living things, the instance will eventually die — meaning the container will shut down.


Монстр, вызванный к жизни	An instance of a monster

Контейнеры Docker — это вызванные к жизни образы Docker.	A Docker container is a Docker image brought to life.

Программное обеспечение	Software

Контейнеры Docker можно сравнивать не только с обычными контейнерами или с живыми организмами. Их можно сравнить и с программами. В конце концов, контейнеры — это программы. И, на фундаментальном уровне, контейнер представляет собой набор инструкций, который выполняется на некоем процессоре, обрабатывая какие-то данные.	In addition to the container metaphor and the living instance metaphor, you can think of a Docker container as a software program. After all, it is software. At its most basic level a container is a set of instructions that manipulate other bits.


Контейнер — это программа	Containers are code

Во время выполнения контейнера Docker внутри него обычно выполняется какая-то программа. Она выполняет в контейнере некие действия, то есть — делает что-то полезное.	While a Docker container is running, it generally has programs running inside it. The programs in a container perform actions so your application will do something.
Например, код, который работает в контейнере Docker, возможно, отправил на ваш компьютер тот текст, который вы сейчас читаете. Вполне возможно и то, что именно код, выполняющийся в контейнере Docker, принимает голосовые команды, которые вы даёте Amazon Alexa, и преобразует их в инструкции для ещё каких-нибудь программ, работающих в других контейнерах.	For example, the code in a Docker container might have sent you the content you are reading on this webpage right now. Or it might take your voice command to Amazon Alexa and decode it into instructions another program in a different container will use.
Благодаря использованию Docker можно, на одном и том же компьютере, одновременно запускать множество контейнеров. И, как и любые другие программы, контейнеры Docker можно запускать, останавливать, удалять. Можно исследовать их содержимое и создавать их.	With Docker you can run multiple containers simultaneously on a host machine. And like other software programs, Docker containers can be run, inspected, stopped, and deleted.

Концепции Docker	Concepts

Виртуальные машины	Virtual Machines

Предшественниками контейнеров Docker были виртуальные машины. Виртуальная машина, как и контейнер, изолирует от внешней среды приложение и его зависимости. Однако контейнеры Docker обладают преимуществами перед виртуальными машинами. Так, они потребляют меньше ресурсов, их очень легко переносить, они быстрее запускаются и приходят в работоспособное состояние.	Virtual machines are the precursors to Docker containers. Virtual machines also isolate an application and its dependencies. However, Docker containers are superior to virtual machines because they take fewer resources, are very portable, and are faster to spin up.

Образ контейнера Docker	Docker Image

Выше мы уже говорили об «образах». Что это такое? Хороший вопрос. То, что в терминологии Docker называется «образом», или, по-английски, «image», это совсем не то же самое, что, например, фотография (это — одно из значений слова «image»).	I mentioned images above. What’s an image? I’m glad you asked! The meaning of the term image in the context of Docker doesn’t map all that well to a physical image.


Образы Docker — это не фотографии	Images

Образы контейнеров Docker можно сравнить с чертежами, с формочками для печенья, или с пресс-формами для изготовления пластиковых изделий. Образы — это неизменные шаблоны, которые используются для создания одинаковых контейнеров.	Docker images are more like blueprints, cookie cutters, or molds. Images are the immutable master template that is used to pump out containers that are all exactly alike.


Образы контейнеров Docker похожи на формочки для печенья	Cookie cutters

В образе контейнера Docker содержится образ базовой операционной системы, код приложения и библиотеки, от которых оно зависит. Всё это скомпоновано в виде единой сущности, на основе которой можно создать контейнер.	An image contains the Dockerfile, libraries, and code your application needs to run, all bundled together.

Файл Dockerfile	Dockerfile

Файл `Dockerfile` содержит набор инструкций, следуя которым Docker будет собирать образ контейнера. Этот файл содержит описание базового образа, который будет представлять собой исходный слой образа. Среди популярных официальных базовых образов можно отметить `python`, `ubuntu`, `alpine`.	A `Dockerfile` is a file with instructions for how Docker should build your image. The Dockerfile refers to a base image that is used to build the initial image layer. Popular official base images include `python`, `ubuntu`, and `alpine`.
В образ контейнера, поверх базового образа, можно добавлять дополнительные слои. Делается это в соответствии с инструкциями из `Dockerfile`. Например, если `Dockerfile` описывает образ, который планируется использовать для решения задач машинного обучения, то в нём могут быть инструкции для включения в промежуточный слой такого образа библиотек NumPy, Pandas и Scikit-learn.	Additional layers can then be stacked on top of the base image layers, according to the instructions in the `Dockerfile`. For example, a `Dockerfile` for a machine learning application could tell Docker to add NumPy, Pandas, and Scikit-learn in an intermediate layer.
И, наконец, в образе может содержаться, поверх всех остальных, ещё один тонкий слой, данные, хранящиеся в котором, поддаются изменению. Это — небольшой по объёму слой, содержащий программу, которую планируется запускать в контейнере.	Finally, a thin, writable layer is stacked on top of the other layers according to the Dockerfile code. (You understand that a thin layer is small in size because you intuitively understand the thin metaphor, right 😃?)

Контейнер Docker	Docker Container

Для того чтобы запустить контейнер, нам нужен, во-первых, образ контейнера, во-вторых — среда, в которой установлен Docker, способная понять команду вида `docker run image_name`. Эта команда создаёт контейнер из образа и запускает его.	A Docker image plus the command `docker run image_name` creates and starts a container from an image.

Репозиторий контейнеров	Container Registry

Если вы хотите дать возможность другим людям создавать контейнеры на основе вашего образа, вы можете отправить этот образ в облачное хранилище. Самым крупным подобным хранилищем является репозиторий Docker Hub. Он используется при работе с Docker по умолчанию.	If you want other people to be able to make containers from your image, you send the image to a container registry. Docker Hub is the largest registry and the default.
Мы уже довольно много всего обсудили. Пришло время собрать всё это вместе и сравнить работу с контейнерами Docker с приготовлением пиццы.	Phew! That’s a lot of pieces. Let’s put this all together in terms of making a pizza.

Готовим с Docker	Cooking with Docker


Готовая пицца — это контейнер	Landscape Metaphor

• Рецепт приготовления пиццы — это файл `Dockerfile`. Он сообщает нам о том, что нужно сделать для того, чтобы достичь цели, то есть — получить работающий контейнер.	• The recipe is like the `Dockerfile`. It tells you what to do to get to your end goal.
• Ингредиенты, из которых состоит пицца — это слои образа контейнера. Для нашей пиццы понадобится корж, соус и сыр.	• The ingredients are the layers. You’ve got crust, sauce, and cheese for this pizza.

Если положить на стол рецепт и ингредиенты, то получится, что в одном месте собрано всё, что нужно для того, чтобы приготовить пиццу. Это всё можно сравнить с образом контейнера Docker.	Think of the recipe and the ingredients combined as an all-in-one pizza-making-kit. It’s the Docker image.
Из рецепта (Dockerfile) можно узнать о том, какую последовательность действий нужно выполнить для того, чтобы приготовить пиццу:	The recipe (Dockerfile) tells us what we’re going to do. Here’s the plan:
• Корж уже готов к использованию, мы его не меняем. Его можно сравнить с базовым образом ОС Ubuntu. Это — нижний слой образа, его в образ добавляют первым.	• The crust is preformed and immutable, it’s like a basic ubuntu parent image. It’s the bottom layer and gets built first.
• Затем на корж добавляют сыр. Это — всё равно что добавить в образ второй слой в виде какой-то внешней библиотеки наподобие NumPy.	• Then you’ll add some cheese. Adding this second layer to the pizza is like installing an external library — for example NumPy.
• Затем, поверх сыра, добавляют соус. Это — код приложения, которое должно запускаться в контейнере.	• Then you’ll sprinkle on some basil. The basil is like the code in a file that you wrote to run your app.

Теперь пришло время готовить пиццу в духовке.	Alright, let’s get cooking.


Духовка — это платформа Docker	Oven

• Духовка, в которой готовится пицца, напоминает платформу Docker. Духовку устанавливают на кухне, с её помощью можно готовить еду. Точно так же Docker устанавливают на компьютере для того, чтобы «готовить» контейнеры.	• The oven that bakes the pizza is like the Docker platform. You installed the oven into your house when you moved in so you could make things with it. Similarly, you installed Docker onto your computer so you could cook up containers.
• Духовку, если она электрическая, включают, поворачивая ручку регулятора температуры. Команда `docker run image_name` — это нечто вроде такого регулятора температуры, «поворот» которого приводит к тому, что система создаёт и запускает контейнер.	• You start your oven by turning a knob. The `docker run image_name` command is like your knob — it creates and starts your container.
• Готовая пицца — это и есть контейнер Docker.	• The cooked pizza is like a Docker container.
• А есть пиццу — значит пользоваться приложением, запущенным в контейнере.	• Eating the pizza is like using your app.
Как и приготовление пиццы, подготовка к работе контейнеров Docker занимает некоторое время, но в финале и в том и в другом случаях получается что-то вкусное.	Like making a pizza, making an app in a Docker container takes some work, but at the end you have something great. Enjoy 🍕!

Итоги	Wrap

Здесь мы, на концептуальном уровне, рассмотрели основы Docker. Надеемся, приведённые здесь сравнения помогли вам разобраться в том, что такое Docker, и ощутить ценность метафор в деле освоения новых технологий.	That’s the conceptual framework. Hopefully this overview has helped you better understand the Docker landscape. I also hope it has also opened your eyes to the value of metaphors in understanding new technologies.

2. Термины и концепции


2. Термины и концепции	2. A Delicious Dozen Docker Terms You Need to Know

В этой части мы поговорим об экосистеме Docker и рассмотрим важные термины, с которыми вы можете столкнуться на пути изучения и использования Docker. Продолжив аналогию с разными вкусностями, представим, что наши термины — это пончики. Дюжина пончиков.	In this article I’ll share a dozen additional terms from the Docker ecosystem that you need to know. Keeping with the food theme from the first article in the series. Here’s a dozen delicious Docker donuts. Think of each donut as a Docker container. 😄



Термины экосистемы Docker	Docker Ecosystem Terms

Я разбил термины, с которыми вы можете столкнуться в ходе работы с Docker, на две части. Думаю, это облегчит их запоминание. Первый блок терминов будет относиться к механизмам Docker. Второй — к средствам масштабирования решений, основанных на контейнерах.	I’ve broken Docker terms into two categories for easier mental model creation: Essentials and Scaling. Let’s hit the eight essentials first.

Механизмы Docker	Docker Essentials

Платформа Docker	Docker Platform
Платформа Docker (Docker Platform) — это программа, которая даёт нам возможность упаковывать приложения в контейнеры и запускать их на серверах. Платформа Docker позволяет помещать в контейнеры код и его зависимости. Как результат, системы, основанные на контейнерах, легко масштабировать, так как контейнеры можно переносить и воспроизводить.	Docker Platform is Docker’s software that provides the ability to package and run an application in a container on any Linux server. Docker Platform bundles code files and dependencies. It promotes easy scaling by enabling portability and reproducibility.

Движок Docker	Docker Engine
Движок Docker (Docker Engine) — это клиент-серверное приложение. Компания Docker разделила движок Docker на два продукта.	Docker Engine is the client-server application. The Docker company divides the Docker Engine into two products.
• Docker Community Edition (CE) — это бесплатное ПО, во многом основанное на опенсорсных инструментах. Вероятно, вы будете пользоваться именно этой версией Docker.	• Docker Community Edition (CE) is free and largely based on open source tools. It’s probably what you’ll be using.



• Docker Enterprise — это платная версия системы, дающая пользователям дополнительные возможности в области поддержки систем, управления ими и безопасности. Платная версия Docker даёт компании средства, необходимые для её существования.	• Docker Enterprise comes with additional support, management, and security features. Enterprise is how the Docker firm keeps the lights on.

Клиент Docker	Docker Client
Клиент Docker (Docker Client) — это основное средство, которое используют для взаимодействия с Docker. Так, при работе с интерфейсом командной строки Docker (Docker Command Line Interface, CLI), в терминал вводят команды, начинающиеся с ключевого слова `docker`, обращаясь к клиенту. Затем клиент использует API Docker для отправки команд демону Docker.	Docker Client is the primary way you’ll interact with Docker. When you use the Docker Command Line Interface (CLI) you type a command into your terminal that starts with `docker`. Docker Client then uses the Docker API to send the command to the Docker Daemon.


Клиент Docker и другие механизмы экосистемы (взято из документации)	Diagram from the Docker docs

Демон Docker	Docker Daemon
Демон Docker (Docker Daemon) — это сервер Docker, который ожидает запросов к API Docker. Демон Docker управляет образами, контейнерами, сетями и томами.	Docker Daemon is the Docker server that listens for Docker API requests. The Docker Daemon manages images, containers, networks, and volumes.

Тома Docker	Docker Volumes


Тома	Volumes

Реестр Docker	Docker Registry
Реестр Docker (Docker Registry) представляет собой удалённую платформу, используемую для хранения образов Docker. В ходе работы с Docker образы отправляют в реестр и загружают из него. Подобный реестр может быть организован тем, кто пользуется Docker. Кроме того, поставщики облачных услуг могут поддерживать и собственные реестры. Например, это касается AWS и Google Cloud.	A Docker Registry is the remote location where Docker Images are stored. You push images to a registry and pull images from a registry. You can host your own registry or use a provider’s registry. For example, AWS and Google Cloud have registries.

Хаб Docker	Docker Hub
Хаб Docker (Docker Hub) — это самый крупный реестр образов Docker. Кроме того, именно этот реестр используется при работе с Docker по умолчанию. Пользоваться хабом Docker можно бесплатно.	Docker Hub is the largest registry of Docker images. It’s also the default registry. You can find images and store your own images on Docker Hub for free.

Репозиторий Docker	Docker Repository
Репозиторием Docker (Docker Repository) называют набор образов Docker, обладающих одинаковыми именами и разными тегами. Теги — это идентификаторы образов.	A Docker Repository is a collection of Docker images with the same name and different tags. The tag is the identifier for the image.
Обычно в репозиториях хранятся разные версии одних и тех же образов. Например, Python — это имя популярнейшего официального репозитория Docker на хабе Docker. А вот Python:3.7-slim — это версия образа с тегом 3.7-slim в репозитории Python. В реестр можно отправить как целый репозиторий, так и отдельный образ.	Usually a repository has different versions of the same image. For example, Python is the name of the most popular official Docker image repository on Docker Hub. Python:3.7-slim refers to the version of the image with the 3.7-slim tag in the Python repository. You can push a repository or a single image to a registry.

Теперь поговорим о терминах экосистемы Docker, имеющих отношение к масштабированию.	Now let’s look at Docker terms related to scaling multiple Docker containers.

Масштабирование решений, основанных на контейнерах	Scaling Docker

Следующие четыре термина имеют отношение к одновременному использованию нескольких контейнеров.	The following four concepts relate to using multiple containers at once.

Сеть Docker	Docker Networking
Сетевые механизмы Docker (Docker Networking) позволяют организовывать связь между контейнерами Docker. Соединённые с помощью сети контейнеры могут выполняться на одном и том же хосте или на разных хостах.	Docker Networking allows you to connect Docker containers together. Connected Docker containers could be on the same host or multiple hosts.


Сеть Docker (взято из документации)	Docker Bridge Network

Docker Compose	Docker Compose
Docker Compose — это инструмент, который упрощает развёртывание приложений, для работы которых требуется несколько контейнеров Docker. Docker Compose позволяет выполнять команды, описываемые в файле `docker-compose.yml`. Эти команды можно выполнять столько раз, сколько потребуется. Интерфейс командной строки Docker Compose упрощает взаимодействие с многоконтейнерными приложениями. Этот инструмент устанавливается при установке Docker.	Docker Compose is a tool that makes it easier to run apps that require multiple Docker containers. Docker Compose allows you to move commands into a `docker-compose.yml` file for reuse. The Docker Compose command line interface (cli) makes it easier to interact with your multi-container app. Docker Compose comes free with your installation of Docker.

Docker Swarm	Docker Swarm
Docker Swarm — это решение, предназначенное для управления контейнерными развёртываниями (то есть, как говорят, для оркестрации контейнеров).	Docker Swarm is a product to orchestrate container deployment.


Рой пчёл	Bee swarm

Сервисы Docker	Docker Services
Сервисы Docker (Docker Services) — это различные части распределённого приложения. Вот что о них говорится в документации:	Docker Services are the different pieces of a distributed app. From the docs:
Сервисы — это всего лишь «контейнеры в продакшне». В пределах сервиса выполняется лишь один образ, но сервис определяет то, как именно выполняется образ. В частности, речь идёт о том, какие порты должны использоваться, сколько реплик контейнера должно выполняться для того, чтобы сервис обеспечивал бы необходимую вычислительную мощность, и так далее. Масштабирование сервисов предусматривает изменение количества экземпляров контейнера, в которых работает некая программа, благодаря чему сервису выделяется столько системных ресурсов, сколько ему требуется для решения некоей задачи.	Services are really just “containers in production.” A service only runs one image, but it codifies the way that image runs — what ports it should use, how many replicas of the container should run so the service has the capacity it needs, and so on. Scaling a service changes the number of container instances running that piece of software, assigning more computing resources to the service in the process.
Сервисы Docker позволяют масштабировать контейнеры в пределах нескольких демонов Docker, благодаря им существует и технология Docker Swarm.	Docker services allow you to scale containers across multiple Docker Daemons and make Docker Swarms possible.

Краткий перечень терминов	Recap

Давайте, буквально в двух словах, повторим только что представленные вам термины:	Here’s the one line explanation to help you keep these dozen terms straight.

Механизмы Docker:	Basics

1. Платформа Docker — ПО, благодаря которому можно работать с контейнерами.	Platform — the software that makes Docker containers possible
2. Движок Docker — клиент-серверное приложение (CE или Enterprise).	Engine — client-server app (CE or Enterprise)
3. Клиент Docker — программа, которая позволяет взаимодействовать с демоном Docker посредством CLI.	Client — handles Docker CLI so you can communicate with the Daemon
4. Демон Docker — сервер Docker, отвечающий за управление ключевыми механизмами системы.	Daemon — Docker server that manages key things
5. Тома Docker — хранилище информации, используемое в контейнерах.	Volumes — persistent data storage
6. Реестр Docker — удалённое хранилище образов.	Registry — remote image storage
7. Хаб Docker — самый крупный реестр Docker, используемый по умолчанию.	Docker Hub — default and largest Docker Registry
8. Репозиторий — коллекция образов Docker с одним и тем же именем.	Repository — collection of Docker images, e.g. Alpine

Масштабирование:	Scaling

1. Сетевая подсистема Docker — среда, которая позволяет организовывать взаимодействие контейнеров.	Networking — connect containers together
2. Docker Compose — технология, упрощающая работу с многоконтейнерными приложениями.	Compose — time saver for multi-container apps
3. Docker Swarm — средство для управления развёртыванием контейнеров.	Swarm — orchestrates container deployment
4. Сервисы Docker — контейнеры в продакшне.	Services — containers in production

Выше мы говорили о том, что рассмотрим дюжину терминов экосистемы Docker, сравнивая их с дюжиной пончиков. Мы рассмотрели уже 12 терминов, и, казалось бы, на этом можно и остановиться. Но мы, на всякий случай, добавим в наш список ещё один термин. Этот термин относится не к самой платформе Docker, а к технологии, которая очень часто используется совместно с Docker.	Because we’re keeping with food metaphors, and everyone loves a baker’s dozen, we have one more related term for you: Kubernetes.

Kubernetes	Kubernetes
Kubernetes — это технология, которая позволяет автоматизировать развёртывание и масштабирование контейнеризированных приложений, а также управление ими. Это — бесспорный лидер рынка средств для оркестрации контейнеров. Если вам нужен инструмент для работы с группами контейнеров, для масштабирования решений, основанных на них, используйте не Docker Swarm, а Kubernetes. Kubernetes не является частью Docker. Они с Docker, скорее, похожи на лучших друзей.	Kubernetes automates deployment, scaling, and management of containerized applications. It’s the clear winner in the container orchestration market. Instead of Docker Swarm, use Kubernetes to scale up projects with multiple Docker containers. Kubernetes isn’t an official part of Docker; it’s more like Docker’s BFF.

Теперь, когда вы ознакомились с общими понятиями Docker и с терминологией, вы можете приступить к практическим экспериментам.	Now that you know the conceptual landscape and common terms I suggest you try out Docker.

3. Файлы Dockerfile


3. Файлы Dockerfile	3. A Dozen Dandy Dockerfile Instructions

Мы продолжим вдохновляться выпечкой, а именно — бубликами. Нашей основной темой будет работа с файлами Dockerfile. Мы разберём инструкции, которые используются в этих файлах.	This part is all about Dockerfiles. Keeping with our carb-rich food metaphors, we’ll explore a dozen tasty Dockerfile instructions.


Бублики — это инструкции в файле Dockerfile

Образы Docker	Docker Images

Вспомните о том, что контейнер Docker — это образ Docker, вызванный к жизни. Это — самодостаточная операционная система, в которой имеется только самое необходимое и код приложения.	Recall that a Docker container is a Docker image brought to life. It’s a self-contained, minimal operating system with application code.
Образы Docker являются результатом процесса их сборки, а контейнеры Docker — это выполняющиеся образы. В самом сердце Docker находятся файлы Dockerfile. Подобные файлы сообщают Docker о том, как собирать образы, на основе которых создаются контейнеры.	The Docker image is created at build time and the Docker container is created at run time. The Dockerfile is at the heart of Docker. The Dockerfile tells Docker how to build the image that will be used to make containers.
Каждому образу Docker соответствует файл, который называется Dockerfile. Его имя записывается именно так — без расширения. При запуске команды `docker build` для создания нового образа подразумевается, что Dockerfile находится в текущей рабочей директории. Если этот файл находится в каком-то другом месте, его расположение можно указать с использованием флага `-f`.	Each Docker image contains a file named Dockerfile with no extension. The Dockerfile is assumed to be in the current working directory when `docker build` is called to create an image. A different location can be specified with the file flag (`-f`).
Контейнеры, как мы выяснили ранее, состоят из слоёв. Каждый слой, кроме последнего, находящегося поверх всех остальных, предназначен только для чтения. Dockerfile сообщает системе Docker о том, какие слои и в каком порядке надо добавить в образ.	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.
Каждый слой, на самом деле, это всего лишь файл, который описывает изменение состояния образа в сравнении с тем состоянием, в котором он пребывал после добавления предыдущего слоя. В Unix, кстати, практически всё что угодно — это файл.	Each layer is really just a file with the changes since the previous layer. In Unix, pretty much everything is a file.
Базовый образ — это то, что является исходным слоем (или слоями) создаваемого образа. Базовый образ ещё называют родительским образом.	The base image provides the initial layer(s). A base image is also called a parent image.


Базовый образ — это то, с чего начинается образ Docker	A base (jumping) image

Когда образ загружается из удалённого репозитория на локальный компьютер, то физически скачиваются лишь слои, которых на этом компьютере нет. Docker стремится экономить пространство и время путём повторного использования существующих слоёв.	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.

Файлы Dockerfile	Dockerfile

В файлах Dockerfile содержатся инструкции по созданию образа. С них, набранных заглавными буквами, начинаются строки этого файла. После инструкций идут их аргументы. Инструкции, при сборке образа, обрабатываются сверху вниз. Вот как это выглядит:	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:

`FROM ubuntu:18.04 COPY . /app`

Слои в итоговом образе создают только инструкции `FROM`, `RUN`, `COPY`, и `ADD`. Другие инструкции что-то настраивают, описывают метаданные, или сообщают Docker о том, что во время выполнения контейнера нужно что-то сделать, например — открыть какой-то порт или выполнить какую-то команду.	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.
Здесь мы исходим из предположения, в соответствии с которым используется образ Docker, основанный на Unix-подобной ОС. Конечно, тут можно воспользоваться и образом, основанным на Windows, но использование Windows — это менее распространённая практика, работать с такими образами сложнее. В результате, если у вас есть такая возможность, пользуйтесь Unix.	Here, I’m assuming you are using a Unix-based Docker image. You can also used Windows-based images, but that’s a slower, less-pleasant, less-common process. So use Unix if you can.
Для начала приведём список инструкций Dockerfile с краткими комментариями.	Let’s do a quick once-over of the dozen Dockerfile instructions we’ll explore.

Дюжина инструкций Dockerfile	A Dozen Dockerfile Instructions

1. `FROM` — задаёт базовый (родительский) образ. 2. `LABEL` — описывает метаданные. Например — сведения о том, кто создал и поддерживает образ. 3. `ENV` — устанавливает постоянные переменные среды. 4. `RUN` — выполняет команду и создаёт слой образа. Используется для установки в контейнер пакетов. 5. `COPY` — копирует в контейнер файлы и папки. 6. `ADD` — копирует файлы и папки в контейнер, может распаковывать локальные .tar-файлы. 7. `CMD` — описывает команду с аргументами, которую нужно выполнить когда контейнер будет запущен. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция `CMD`. 8. `WORKDIR` — задаёт рабочую директорию для следующей инструкции. 9. `ARG` — задаёт переменные для передачи Docker во время сборки образа. 10. `ENTRYPOINT` — предоставляет команду с аргументами для вызова во время выполнения контейнера. Аргументы не переопределяются. 11. `EXPOSE` — указывает на необходимость открыть порт. 12. `VOLUME` — создаёт точку монтирования для работы с постоянным хранилищем.	1. `FROM` — specifies the base (parent) image. 2. `LABEL` — provides metadata. Good place to include maintainer info. 3. `ENV` — sets a persistent environment variable. 4. `RUN` — runs a command and creates an image layer. Used to install packages into containers. 5. `COPY` — copies files and directories to the container. 6. `ADD` — copies files and directories to the container. Can upack local .tar files. 7. `CMD` — provides a command and arguments for an executing container. Parameters can be overridden. There can be only one `CMD`. 8. `WORKDIR` — sets the working directory for the instructions that follow. 9. `ARG` — defines a variable to pass to Docker at build-time. 10. `ENTRYPOINT` — provides command and arguments for an executing container. Arguments persist. 11. `EXPOSE` — exposes a port. 12. `VOLUME` — creates a directory mount point to access and store persistent data.

Теперь поговорим об этих инструкциях.	Let’s get to it!

Инструкции и примеры их использования	Instructions and Examples

Dockerfile может быть чрезвычайно простым и коротким. Например — таким:	A Dockerfile can be as simple as this single line:

`FROM ubuntu:18.04`

Инструкция FROM	FROM

Файл Dockerfile должен начинаться с инструкции `FROM`, или с инструкции `ARG`, за которой идёт инструкция `FROM`.	A Dockerfile must start with a `FROM` instruction or an `ARG` instruction followed by a `FROM` instruction.
Ключевое слово `FROM` сообщает Docker о том, чтобы при сборке образа использовался бы базовый образ, который соответствует предоставленному имени и тегу. Базовый образ, кроме того, ещё называют родительским образом.	The `FROM` keyword tells Docker to use a base image that matches the provided repository and tag. A base image is also called a parent image.
В приведенном примере базовый образ хранится в репозитории `ubuntu`. Ubuntu — это название официального репозитория Docker, предоставляющего базовую версию популярной ОС семейства Linux, которая называется Ubuntu.	In the given example, `ubuntu` is the image repository. Ubuntu is the name of an official Docker repository that provides a basic version of the popular Ubuntu version of the Linux operating system.

Обратите внимание на то, что рассматриваемый Dockerfile включает в себя тег `18.04`, уточняющий то, какой именно базовый образ нам нужен. Именно этот образ (`ubuntu:18.04`) и будет загружен при сборке нашего образа. Если тег в инструкцию не включён, тогда Docker исходит из предположения о том, что требуется самый свежий образ из репозитория (`latest`). Для того чтобы яснее выразить свои намерения, автору Dockerfile рекомендуется указывать то, какой именно образ ему нужен.	Notice that this Dockerfile includes a tag for the base image: `18.04`. This tag tells Docker which version of the image in the `ubuntu` repository to pull. If no tag is included, then Docker assumes the `latest` tag, by default. To make your intent clear, it’s good practice to specify a base image tag.

Когда вышеописанный Dockerfile используется на локальной машине для сборки образа в первый раз, Docker загрузит слои, определяемые образом `ubuntu`. Их можно представить наложенными друг на друга. Каждый следующий слой представляет собой файл, описывающий отличия образа в сравнении с тем его состоянием, в котором он был после добавления в него предыдущего слоя.	When the Dockerfile above is used to build an image locally for the first time, Docker downloads the layers specified in the `ubuntu` image. 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.
При создании контейнера слой, в который можно вносить изменения, добавляется поверх всех остальных слоёв. Данные, находящиеся в остальных слоях, можно только читать.	When you create a container, you add a writable layer on top of the read-only layers.


Структура контейнера (взято из документации)	From the Docker Docs

Docker, ради эффективности, использует стратегию копирования при записи. Если слой в образе существует на предыдущем уровне и какому-то слою нужно произвести чтение данных из него, Docker использует существующий файл. При этом ничего загружать не нужно.	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.
Когда образ выполняется, если слой нужно модифицировать средствами контейнера, то соответствующий файл копируется в самый верхний, изменяемый слой. Для того чтобы узнать подробности о стратегии копирования при записи, взгляните на этот материал из документации Docker.	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 here to learn more about copy-on-write.

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

Более сложный Dockerfile	A More Substantive Dockerfile

Хотя файл Dockerfile, который мы только что рассмотрели, получился аккуратным и понятным, он устроен слишком просто, в нём используется всего одна инструкция. Кроме того, там нет инструкций, вызываемых во время выполнения контейнера. Взглянем на ещё один файл, который собирает маленький образ. В нём имеются механизмы, определяющие команды, вызываемые во время выполнения контейнера.	Although our one-line image is concise, it’s also slow, provides little information, and does nothing at container run time. Let’s look at a longer Dockerfile that builds a much smaller size image and executes a script at container run time.


Возможно, на первый взгляд этот файл может показаться довольно сложным. Поэтому давайте с ним разберёмся.	Whoa, what’s going on here? Let’s step through it and demystify.
Базой этого образа является официальный образ Python с тегом 3.7.2-alpine3.8. Проанализировав этот код можно увидеть, что данный базовый образ включает в себя Linux, Python, и, по большому счёту, этим его состав и ограничивается. Образы ОС Alpine весьма популярны в мире Docker. Дело в том, что они отличаются маленькими размерами, высокой скоростью работы и безопасностью. Однако образы Alpine не отличаются широкими возможностями, характерными для обычных операционных систем. Поэтому для того, чтобы собрать на основе такого образа что-то полезное, создателю образа нужно установить в него необходимые ему пакеты.	The base image is an official Python image with the tag 3.7.2-alpine3.8. As you can see from its source code, the image includes Linux, Python and not much else. Alpine images are popular because they are small, fast, and secure. However, Alpine images don’t come with many operating system niceties. You must install such packages yourself, should you need them.

Инструкция LABEL	LABEL
Инструкция `LABEL`(метка) позволяет добавлять в образ метаданные. В случае с рассматриваемым сейчас файлом, она включает в себя контактные сведения создателя образа. Объявление меток не замедляет процесс сборки образа и не увеличивает его размер. Они лишь содержат в себе полезную информацию об образе Docker, поэтому их рекомендуется включать в файл.	The next instruction is `LABEL`. `LABEL` adds metadata to the image. In this case, it provides the image maintainer’s contact info. Labels don’t slow down builds or take up space and they do provide useful information about the Docker image, so definitely use them.

Инструкция ENV	ENV
Инструкция `ENV` позволяет задавать постоянные переменные среды, которые будут доступны в контейнере во время его выполнения. В предыдущем примере после создания контейнера можно пользоваться переменной ADMIN.	`ENV` sets a persistent environment variable that is available at container run time. In the example above, you could use the `ADMIN` variable when your Docker container is created.
Инструкция `ENV` хорошо подходит для задания констант. Если вы используете некое значение в Dockerfile несколько раз, скажем, при описании команд, выполняющихся в контейнере, и подозреваете, что, возможно, вам когда-нибудь придётся сменить его на другое, его имеет смысл записать в подобную константу.	`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.
Надо отметить, что в файлах Dockerfile часто существуют разные способы решения одних и тех же задач. Что именно использовать — это вопрос, на решение которого влияет стремление к соблюдению принятых в среде Docker методов работы, к обеспечению прозрачности решения и его высокой производительности. Например, инструкции `RUN`, `CMD` и `ENTRYPOINT` служат разным целям, но все они используются для выполнения команд.	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.

Инструкция RUN	RUN


Инструкция RUN	RUN

Инструкция `RUN` позволяет создать слой во время сборки образа. После её выполнения в образ добавляется новый слой, его состояние фиксируется.	`RUN` creates a layer at build-time. Docker commits the state of the image after each `RUN`.
Инструкция `RUN` часто используется для установки в образы дополнительных пакетов. В предыдущем примере инструкция `RUN apk update && apk upgrade` сообщает Docker о том, что системе нужно обновить пакеты из базового образа. Вслед за этими двумя командами идёт команда `&& apk add bash`, указывающая на то, что в образ нужно установить `bash`.	`RUN` is often used to install packages into an image. In the example above, `RUN apk update && apk upgrade` tells Docker to update the packages from the base image. `&& apk add bash` tells Docker to install `bash` into the image.
То, что в командах выглядит как `apk` — это сокращение от Alpine Linux package manager (менеджер пакетов Alpine Linux). Если вы используете базовый образ какой-то другой ОС семейства Linux, тогда вам, например, при использовании Ubuntu, для установки пакетов может понадобиться команда вида `RUN apt-get`. Позже мы поговорим о других способах установки пакетов.	`apk` stands for Alpine Linux package manager. If you’re using a Linux base image in a flavor other than Alpine, then you’d install packages with `RUN apt-get` instead of `apk`. `apt` stand for advanced package tool. I’ll discuss other ways to install packages in a later example.
Инструкция `RUN` и схожие с ней инструкции — такие, как `CMD` и `ENTRYPOINT`, могут быть использованы либо в exec-форме, либо в shell-форме. Exec-форма использует синтаксис, напоминающий описание JSON-массива. Например, это может выглядеть так: `RUN ["my_executable", "my_first_param1", "my_second_param2"]`.	`RUN` — and its cousins, `CMD` and `ENTRYPOINT` — can be used in exec form or shell form. Exec form uses JSON array syntax like so: `RUN ["my_executable", "my_first_param1", "my_second_param2"]`.
В предыдущем примере мы использовали shell-форму инструкции `RUN` в таком виде: `RUN apk update && apk upgrade && apk add bash`.	In the example above, we used shell form in the format `RUN apk update && apk upgrade && apk add bash`.
Позже в нашем Dockerfile использована exec-форма инструкции `RUN`, в виде `RUN ["mkdir", "/a_directory"]` для создания директории. При этом, используя инструкцию в такой форме, нужно помнить о необходимости оформления строк с помощью двойных кавычек, как это принято в формате JSON.	Later in our Dockerfile we used the preferred exec form with `RUN ["mkdir", "/a_directory"]` to create a directory. Don’t forget to use double quotes for strings with JSON syntax for exec form!

Инструкция COPY	COPY
Инструкция `COPY` представлена в нашем файле так: `COPY . ./app`. Она сообщает Docker о том, что нужно взять файлы и папки из локального контекста сборки и добавить их в текущую рабочую директорию образа. Если целевая директория не существует, эта инструкция её создаст.	The `COPY . ./app` instruction tells Docker to take the files and folders in your local build context and add them to the Docker image’s current working directory. Copy will create the target directory if it doesn’t exist.


Инструкция COPY	COPY

Инструкция ADD	ADD
Инструкция `ADD` позволяет решать те же задачи, что и `COPY`, но с ней связана ещё пара вариантов использования. Так, с помощью этой инструкции можно добавлять в контейнер файлы, загруженные из удалённых источников, а также распаковывать локальные .tar-файлы.	`ADD` does the same thing as `COPY`, but has two more use cases. `ADD` can be used to move files from a remote URL to a container and `ADD` can extract local TAR files.
В этом примере инструкция `ADD` была использована для копирования файла, доступного по URL, в директорию контейнера `my_app_directory`. Надо отметить, однако, что документация Docker не рекомендует использование подобных файлов, полученных по URL, так как удалить их нельзя, и так как они увеличивают размер образа.	I used `ADD` in the example above to copy a file from a remote url into the container’s `my_app_directory`. The Docker docs don’t recommend using remote urls in this manner because you can’t delete the files. Extra files increase the final image size.
Кроме того, документация предлагает везде, где это возможно, вместо инструкции `ADD` использовать инструкцию `COPY` для того, чтобы сделать файлы Dockerfile понятнее. Полагаю, команде разработчиков Docker стоило бы объединить `ADD` и `COPY` в одну инструкцию для того, чтобы тем, кто создаёт образы, не приходилось бы помнить слишком много инструкций.	The Docker docs also suggest using `COPY` instead of `ADD` whenever possible for improved clarity. It’s too bad that Docker doesn’t combine `ADD` and `COPY` into a single command to reduce the number of Dockerfile instructions to keep straight 😃.

Инструкция CMD	CMD
Инструкция `CMD` предоставляет Docker команду, которую нужно выполнить при запуске контейнера. Результаты выполнения этой команды не добавляются в образ во время его сборки. В нашем примере с помощью этой команды запускается скрипт `my_script.py` во время выполнения контейнера.	`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` file at run time.
Вот ещё кое-что, что нужно знать об инструкции `CMD`:	A few other things to know about `CMD`:
• В одном файле Dockerfile может присутствовать лишь одна инструкция `CMD`. Если в файле есть несколько таких инструкций, система проигнорирует все кроме последней. • Инструкция `CMD` может иметь exec-форму. Если в эту инструкцию не входит упоминание исполняемого файла, тогда в файле должна присутствовать инструкция `ENTRYPOINT`. В таком случае обе эти инструкции должны быть представлены в формате `JSON`. • Аргументы командной строки, передаваемые `docker run`, переопределяют аргументы, предоставленные инструкции `CMD` в Dockerfile.	• Only one `CMD` instruction per Dockerfile. Otherwise all but the final one are ignored. • `CMD` can include an executable. If `CMD` is present without an executable, then an `ENTRYPOINT` instruction must exist. In that case, both `CMD` and `ENTRYPOINT` instructions should be in `JSON` format. • Command line arguments to `docker run` override arguments provided to `CMD` in the Dockerfile.

Ещё более сложный Dockerfile	Ready for more?

Рассмотрим ещё один файл Dockerfile, в котором будут использованы некоторые новые команды.	Let’s introduce a few more instructions in another example Dockerfile.

`FROM python:3.7.2-alpine3.8` `LABEL maintainer="jeffmshale@gmail.com"` `# Install dependencies` `# Устанавливаем зависимости` `RUN apk add --update git` `# Set current working directory` `# Задаём текущую рабочую директорию` `WORKDIR /usr/src/my_app_directory` `# Copy code from your local context to the image working directory` `# Копируем код из локального контекста в рабочую директорию образа` `COPY . .` # Set default value for a variable # Задаём значение по умолчанию для переменной ARG my_var=my_default_value # Set code to run at container run time # Настраиваем команду, которая должна быть запущена в контейнере во время его выполнения ENTRYPOINT ["python", "./app/my_script.py", "my_var"] # Expose our port to the world # Открываем порты EXPOSE 8000 # Create a volume for data storage # Создаём том для хранения данных VOLUME /my_volume

В этом примере, кроме прочего, вы можете видеть комментарии, которые начинаются с символа `#`.	Note that you can use comments in Dockerfiles. Comments start with `#`.
Одно из основных действий, выполняемых средствами Dockerfile — это установка пакетов. Как уже было сказано, существуют различные способы установки пакетов с помощью инструкции `RUN`.	Package installation is a primary job of Dockerfiles. As touched on earlier, there are several ways to install packages with `RUN`.
Пакеты в образ Alpine Docker можно устанавливать с помощью `apk`. Для этого, как мы уже говорили, применяется команда вида `RUN apk update && apk upgrade && apk add bash`.	You can install a package in an Alpine Docker image with `apk`. `apk` is like apt-get in regular Linux builds. For example, packages in a Dockerfile with a base Ubuntu image can be updated and installed like this: `RUN apt-get update && apt-get install my_package`.
Кроме того, пакеты Python в образ можно устанавливать с помощью `pip`, `wheel` и `conda`. Если речь идёт не о Python, а о других языках программирования, то при подготовке соответствующих образов могут использоваться и другие менеджеры пакетов.	In addition to `apk` and `apt-get`, Python packages can be installed through `pip`, `wheel`, and `conda`. Other languages can use various installers.
При этом для того, чтобы установка была бы возможной, нижележащий слой должен предоставить слою, в который выполняется установка пакетов, подходящий менеджер пакетов. Поэтому если вы столкнулись с проблемами при установке пакетов, убедитесь в том, что менеджер пакетов установлен до того, как вы попытаетесь им воспользоваться.	The underlying layers need to provide the install layer with the the relevant package manger. If you’re having an issue with package installation, make sure the package managers are installed before you try to use them. 😃
Кроме того, для установки нескольких пакетов можно поступить и по-другому. Их можно перечислить в файле и передать менеджеру пакетов этот файл с помощью `RUN`. Обычно таким файлам дают имя `requirements.txt`.	Alternatively, you can list your package requirements in a file and `RUN` a package manager on that file. Folks usually name the file `requirements.txt`.

Инструкция WORKDIR	WORKDIR


Рабочие директории	WORKDIRs of some sort

Инструкция `WORKDIR` позволяет изменить рабочую директорию контейнера. С этой директорией работают инструкции `COPY`, `ADD`, `RUN`, `CMD` и `ENTRYPOINT`, идущие за `WORKDIR`. Вот некоторые особенности, касающиеся этой инструкции:	`WORKDIR` changes the working directory in the container for the `COPY`, `ADD`, `RUN`, `CMD`, and `ENTRYPOINT` instructions that follow it. A few notes:
• Лучше устанавливать с помощью `WORKDIR` абсолютные пути к папкам, а не перемещаться по файловой системе с помощью команд `cd` в Dockerfile. • Инструкция `WORKDIR` автоматически создаёт директорию в том случае, если она не существует. • Можно использовать несколько инструкций `WORKDIR`. Если таким инструкциям предоставляются относительные пути, то каждая из них меняет текущую рабочую директорию.	• It’s preferable to set an absolute path with `WORKDIR` rather than navigate through the file system with `cd` commands in the Dockerfile. •`WORKDIR` creates the directory automatically if it doesn’t exist. • You can use multiple `WORKDIR` instructions. If relative paths are provided, then each `WORKDIR` instruction changes the current working directory.

Инструкция ARG	ARG
Инструкция `ARG` позволяет задать переменную, значение которой можно передать из командной строки в образ во время его сборки. Значение для переменной по умолчанию можно представить в Dockerfile. Например: `ARG my_var=my_default_value`.	`ARG` defines a variable to pass from the command line to the image at build-time. A default value can be supplied for `ARG` in the Dockerfile, as it is in the example: `ARG my_var=my_default_value`.
В отличие от `ENV`-переменных, `ARG`-переменные недоступны во время выполнения контейнера. Однако `ARG`-переменные можно использовать для задания значений по умолчанию для `ENV`-переменных из командной строки в процессе сборки образа. А `ENV`-переменные уже будут доступны в контейнере во время его выполнения.	Unlike `ENV` variables, `ARG` variables are not available to running containers. However, you can use `ARG` values to set a default value for an `ENV` variable from the command line when you build the image. Then, the `ENV` variable persists through container run time.

Инструкция ENTRYPOINT


Пункт перехода в какое-то место	ENTRYPOINT to somewhere

Инструкция `ENTRYPOINT` позволяет задавать команду с аргументами, которая должна выполняться при запуске контейнера. Она похожа на команду `CMD`, но параметры, задаваемые в `ENTRYPOINT`, не перезаписываются в том случае, если контейнер запускают с параметрами командной строки.	The `ENTRYPOINT` instruction also allows you provide a default command and arguments when a container starts. It looks similar to `CMD`, but `ENTRYPOINT` parameters are not overwritten if a container is run with command line parameters.
Вместо этого аргументы командной строки, передаваемые в конструкции вида `docker run my_image_name`, добавляются к аргументам, задаваемым инструкцией `ENTRYPOINT`. Например, после выполнения команды вида `docker run my_image bash` аргумент `bash` добавится в конец списка аргументов, заданных с помощью `ENTRYPOINT`. Готовя Dockerfile, не забудьте об инструкции `CMD` или `ENTRYPOINT`.	Instead, command line arguments passed to `docker run my_image_name` are appended to the `ENTRYPOINT` instruction’s arguments. For example, `docker run my_image bash` adds the argument `bash` to the end of the `ENTRYPOINT` instruction’s existing arguments. A Dockerfile should have at least one `CMD` or `ENTRYPOINT` instruction.
В документации к Docker есть несколько рекомендаций, касающихся того, какую инструкцию, `CMD` или `ENTRYPOINT`, стоит выбрать в качестве инструмента для выполнения команд при запуске контейнера:	The Docker docs have a few suggestions for choosing between `CMD` and `ENTRYPOINT` for your initial container command:
• Если при каждом запуске контейнера нужно выполнять одну и ту же команду — используйте `ENTRYPOINT`. • Если контейнер будет использоваться в роли приложения — используйте `ENTRYPOINT`. • Если вы знаете, что при запуске контейнера вам понадобится передавать ему аргументы, которые могут перезаписывать аргументы, указанные в Dockerfile, используйте `CMD`.	• Favor `ENTRYPOINT` when you need to run the same command every time. • Favor `ENTRYPOINT` when a container will be used as an executable program. • Favor `CMD` when you need to provide extra default arguments that could be overwritten from the command line.
В нашем примере использование инструкции `ENTRYPOINT ["python", "my_script.py", "my_var"]` приводит к тому, что контейнер, при запуске, запускает Python-скрипт my_script.py с аргументом `my_var`. Значение, представленное `my_var`, потом можно использовать в скрипте с помощью `argparse`. Обратите внимание на то, что в Dockerfile переменной `my_var`, до её использования, назначено значение по умолчанию с помощью `ARG`. В результате, если при запуске контейнера ему не передали соответствующее значение, будет применено значение по умолчанию.	In the example above, `ENTRYPOINT ["python", "my_script.py", "my_var"]` has the container run the the python script `my_script.py` with the argument `my_var` when the container starts running. `my_var` could then be used by `my_script` via argparse. Note that `my_var` has a default value supplied by `ARG` earlier in the Dockerfile. So if an argument isn’t passed from the command line, then the default argument will be used.
Документация Docker рекомендует использовать exec-форму `ENTRYPOINT: ENTRYPOINT ["executable", "param1", "param2"]`.	Docker recommends you generally use the exec form of `ENTRYPOINT: ENTRYPOINT ["executable", "param1", "param2"]`. This form is the one with JSON array syntax.

Инструкция EXPOSE	EXPOSE


Инструкция EXPOSE	EXPOSEd

Инструкция `EXPOSE` указывает на то, какие порты планируется открыть для того, чтобы через них можно было бы связаться с работающим контейнером. Эта инструкция не открывает порты. Она, скорее, играет роль документации к образу, средством общения того, кто собирает образ, и того, кто запускает контейнер.	The `EXPOSE` instruction shows which port is intended to be published to provide access to the running container. `EXPOSE` does not actually publish the port. Rather, it acts as a documentation between the person who builds the image and the person who runs the container.
Для того чтобы открыть порт (или порты) и настроить перенаправление портов, нужно выполнить команду `docker run` с ключом `-p`. Если использовать ключ в виде `-P` (с заглавной буквой P), то открыты будут все порты, указанные в инструкции `EXPOSE`.	Use `docker run` with the `-p` flag to publish and map one or more ports at run time. The uppercase `-P` flag will publish all exposed ports.

Инструкция VOLUME	VOLUME


Инструкция VOLUME

Инструкция `VOLUME` позволяет указать место, которое контейнер будет использовать для постоянного хранения файлов и для работы с такими файлами. Об этом мы ещё поговорим.	`VOLUME` specifies where your container will store and/or access persistent data. Volumes are the topic of a forthcoming part, so we’ll investigate them then.

Итоги	Wrap
Теперь вы знаете дюжину инструкций, применяемых при создании образов с помощью Dockerfile. Этим список таких инструкций не исчерпывается. В частности, мы не рассмотрели здесь такие инструкции, как `USER`, `ONBUILD`, `STOPSIGNAL`, `SHELL` и `HEALTHCHECK`.	Now you know a dozen Dockerfile instructions to make yourself useful! The five commands we didn’t cover are `USER`, `ONBUILD`, `STOPSIGNAL`, `SHELL`, and `HEALTHCHECK`.
Вероятно, файлы Dockerfile — это ключевой компонент экосистемы Docker, работать с которым нужно научиться всем, кто хочет уверенно чувствовать себя в этой среде.	Dockerfiles are perhaps the key component of Docker to master. I hope this article helped you gain confidence with them.

4. Уменьшение размеров образов и ускорение их сборки


4. Уменьшение размеров образов и ускорение их сборки	4. Slimming Down Your Docker Images

Кэширование	Caching

Одной из сильных сторон Docker является кэширование. Благодаря этому механизму ускоряется сборка образов.	One of Docker’s strengths is that it provides caching to help you more quickly iterate your image builds.
При сборке образа Docker проходится по инструкциям файла Dockerfile, выполняя их по порядку. В процессе анализа инструкций Docker проверяет собственный кэш на наличие в нём образов, представляющих собой то, что получается на промежуточных этапах сборки других образов. Если подобные образы удаётся найти, то система может ими воспользоваться, не тратя время на их повторное создание.	When building an image, Docker steps through the instructions in your Dockerfile, executing each in order. As each instruction is examined, Docker looks for an existing intermediate image in its cache that it can reuse instead of creating a new (duplicate) intermediate image.
Если кэш признан недействительным, то инструкция, в ходе выполнения которой это произошло, выполняется, создавая новый слой без использования кэша. То же самое происходит и при выполнении инструкций, которые следуют за ней.	If cache is invalidated, the instruction that invalidated it and all subsequent Dockerfile instructions generate new intermediate images. As soon as the cache is invalidated, that’s it for the rest of the instructions in the Dockerfile.
В результате, если в ходе выполнения инструкций из Dockerfile оказывается, что базовый образ имеется в кэше, то используется именно этот образ из кэша. Это называется «попаданием кэша». Если же базового образа в кэше нет, то весь процесс сборки образа будет происходить без использования кэша.	So starting at the top of the Dockerfile, if the base image is already in the cache it is reused. That’s a hit. Otherwise, the cache is invalidated.
Затем следующая инструкция сопоставляется со всеми образами из кэша, в основе которых лежит тот же самый базовый образ, который уже обнаружен в кэше. Каждый кэшированный промежуточный образ проверяется на предмет того, имеется ли в нём то, что было создано такой же инструкцией. Если совпадения найти не удаётся, это называется «промахом кэша» и кэш считается недействительным. То же самое происходит до тех пор, пока не будет обработан весь файл Dockerfile.	Then the next instruction is compared against all child images in the cache derived from that base image. Each cached intermediate image is compared to see if the instruction finds a cache hit. If it’s a cache miss, the cache is invalidated. The same process is repeated until the end of the Dockerfile is reached.
Большинство новых инструкций просто сравниваются с тем, что уже есть в промежуточных образах. Если системе удаётся найти совпадение, то при сборке используется то, что уже есть в кэше.	Most new instructions are simply compared with those in the intermediate images. If there’s a match, then the cached copy is used.
Использование кэша способно ускорить сборку образов, но тут есть одна проблема. Например, если в Dockerfile обнаруживается инструкция `RUN pip install -r requirements.txt` , то Docker выполняет поиск такой же инструкции в своём локальном кэше промежуточных образов. При этом содержимое старой и новой версий файла `requirements.txt` не сравнивается.	For example, when a `RUN pip install -r requirements.txt` instruction is found in a Dockerfile, Docker searches for the same instruction in its locally cached intermediate images. The content of the old and new `requirements.txt` files are not compared.
Подобное может приводить к проблемам в том случае, если в `requirements.txt` были добавлены сведения о новых пакетах, после чего, при сборке обновлённого образа, для того, чтобы установить новый набор пакетов, нужно снова выполнить инструкцию `RUN pip install` . Совсем скоро мы поговорим о том, как бороться с этой проблемой.	This behavior can be problematic if you update your `requirements.txt` file with new packages and use `RUN pip install` and want to rerun the package installation with the new package names. I’ll show a few solutions in a moment.
В отличие от других инструкций Docker, при выполнении инструкций `ADD` и `COPY` от Docker требуется проверка содержимого файла или файлов для определения того, можно ли, при формировании образа, воспользоваться кэшем. А именно, контрольная сумма файлов, упомянутых в этих инструкциях, сравнивается с контрольной суммой файлов, которые имеются в промежуточных образах, которые уже есть в кэше. Если изменилось содержимое файлов или их метаданные, тогда кэш признаётся недействительным.	Unlike other Docker instructions, `ADD` and `COPY` instructions do require Docker to look at the contents of the file(s) to determine if there is a cache hit. The checksum of the referenced file is compared against the checksum in the existing intermediate images. If the file contents or metadata have changed, then the cache is invalidated.
Вот несколько советов, касающихся эффективного использования кэша Docker:	Here are a few tips for using caching effectively.
• Кэширование можно отключить, передав ключ `--no-cache=True` команде `docker build`. • Если вы собираетесь вносить изменения в инструкции Dockerfile, тогда каждый слой, созданный инструкциями, идущими после изменённых, будет достаточно часто собираться повторно, без использования кэша. Для того чтобы воспользоваться преимуществами кэширования, помещайте инструкции, вероятность изменения которых высока, как можно ближе к концу Dockerfile. • Объединяйте команды `RUN apt-get update` и `apt-get install` в цепочки для того, чтобы исключить проблемы, связанные с неправильным использованием кэша. • Если вы используете менеджеры пакетов, наподобие `pip`, с файлом `requirements.txt`, тогда придерживайтесь нижеприведённой схемы работы для того, чтобы исключить использование устаревших промежуточных образов из кэша, содержащих набор пакетов, перечисленных в старой версии файла `requirements.txt`. Вот как это выглядит:	• Caching can be turned off by passing `--no-cache=True` with `docker build` . • If you are going to be making changes to instructions, then every layer that follows will be rebuilt frequently. To take advantage of caching, put instructions that are likely to change as low as you can in your Dockerfile. • Chain `RUN apt-get update` and `apt-get install` commands to avoid cache miss issues. • If you’re using a package installer such as `pip` with a `requirements.txt` file, then follow a model like the one below to make sure you don’t receive a stale intermediate image with the old packages listed in `requirements.txt`.
`COPY requirements.txt /tmp/` `RUN pip install -r /tmp/requirements.txt` `COPY . /tmp/`

Уменьшение размеров образов	Size Reduction

Тщательный подбор базового образа

Образы Docker могут быть довольно большими. Это противоречит вполне обоснованному стремлению того, кто их создаёт, к тому, чтобы сделать их как можно более компактными, что облегчит их загрузку из удалённого репозитория и благотворно скажется на объёме свободного места на компьютере, на который они загружаются. Поговорим о том, как уменьшать их размеры.	Docker images can get large. You want to keep them small so they can pulled quickly and use few resources. Let’s skinny down your images!
Одним из способов уменьшения размеров образов является тщательный подбор базовых образов и их последующая настройка.
Так, например, базовый образ Alpine представляет собой полноценный дистрибутив Linux-подобной ОС, содержащий минимум дополнительных пакетов. Его размер — примерно 5 мегабайт. Однако сборка собственного образа на основе Alpine потребует потратить достаточно много времени на то, чтобы оснастить его всем необходимым для обеспечения работы некоего приложения.	An Alpine base image is a full Linux distribution without much else. It is usually under 5mb to download, but it requires you to spend more time writing the code for the dependencies you need to build a working app.
Существуют и специализированные варианты базового образа Alpine. Например, соответствующий образ из репозитория python, в который упакован скрипт `print("hello world")` весит около 78.5 Мб. Вот Dockerfile для сборки такого образа:	If you need Python in your container, the Python Alpine build is a nice compromise. It contains Linux and Python and you supply most everything else. An image I built with the latest Python Alpine build with a `print(“hello world”)` script weighs in at 78.5 MB. Here’s the Dockerfile:

`FROM python:3.7.2-alpine3.8` `COPY . /app` `ENTRYPOINT ["python", "./app/my_script.py", "my_var"]`

При этом на Docker Hub сказано, что этот базовый образ имеет размер 29 Мб. Размер образа, основанного на этом базовом образе, увеличивается за счёт загрузки и установки Python.	On the Docker Hub website the base image is listed as 29 MB. When the child image is built it downloads and installs Python, making it grow larger.
Помимо использования базовых образов, основанных на Alpine, уменьшить размеры образов можно благодаря использованию технологии многоступенчатой сборки.	Besides using Alpine base images, another method for reducing the size of your images is using multistage builds. This technique also adds complexity to your Dockerfile.

Многоступенчатая сборка образов	Multistage Builds

В Dockerfile, описывающем многоступенчатую сборку образа, используется несколько инструкций `FROM`. Создатель такого образа может настроить выборочное копирование файлов, называемых артефактами сборки, из одной ступени сборки в другую ступень. При этом появляется возможность избавиться от всего того, что в готовом образе не понадобится. Благодаря этому методу можно уменьшить размер готового образа.	Multistage builds use multiple `FROM` instructions. You can selectively copy files, called build artifacts, from one stage to another. You can leave behind anything you don’t want in the final image. This method can reduce your overall image size.
Вот как работает каждая инструкция `FROM`:	Each `FROM` instruction
• Она начинает новый шаг сборки. • Она не зависит от того, что было создано на предыдущем шаге сборки. • Она может использовать базовый образ, отличающийся от того, который применялся на предыдущем шаге.	• begins a new stage of the build. • leaves behind any state created in prior stages. • can use a different base.
Вот модифицированный пример файла Dockerfile из документации Docker, описывающего многоступенчатую сборку.	Here’s a modified example of a multistage build from the Docker docs:

`FROM golang:1.7.3 AS build` `WORKDIR /go/src/github.com/alexellis/href-counter/` `RUN go get -d -v golang.org/x/net/html` `COPY app.go .` `RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .` `FROM alpine:latest` `RUN apk --no-cache add ca-certificates` `WORKDIR /root/` `COPY --from=build /go/src/github.com/alexellis/href-counter/app .` `CMD ["./app"]`

Обратите внимание на то, что мы дали имя первой ступени сборки, указав его после инструкции `FROM` . К именованному этапу сборки мы обращаемся в инструкции `COPY --from=` ниже в Dockerfile.	Note that we name the first stage by appending a name to the `FROM` instruction to name. The named stage is then be referred to in the `COPY --from=` instruction later in the Dockerfile.
Применение процесса многоступенчатой сборки образов имеет смысл в некоторых случаях, когда приходится создавать множество контейнеров для продакшн-окружения. Многоступенчатая сборка позволяет максимально сократить размеры готовых образов. Но иногда такой подход приводит к усложнению поддержки образов. Поэтому вы, вероятно, не будете пользоваться многоступенчатой сборкой образов в тех случаях, в которых без неё можно обойтись.	Multistage builds make sense in some cases where you’ll be making lots of containers in production. Multistage builds can help you squeeze every last ounce (gram if you think in metric) out of your image size. However, sometimes multistage builds add more complexity that can make images harder to maintain, so you probably won’t use them in most builds.
Как видите, многоступенчатая сборка — технология интересная, но подходит она далеко не для всех случаев. Тот же способ уменьшения размера образов, который мы обсудим ниже, можно порекомендовать абсолютно всем.	In contrast, everyone should use a `.dockerignore` file to help keep their Docker images skinny.

Файл .dockerignore	.dockerignore

О файлах `.dockerignore` нужно знать абсолютно всем, кто хочет освоить Docker. Эти файлы похожи на файлы `.gitignore`. Они содержат список файлов и папок, в виде имён или шаблонов, которые Docker должен игнорировать в ходе сборки образа.	`.dockerignore` files are something you should know about as a person who knows enough Docker to be useful. `.dockerignore` is similar to `.gitignore.` It’s a file with a list of patterns for Docker to match with file names and exclude when making an image.
Этот файл размещают там же, где находится файл Dockerfile, и всё остальное, входящее в контекст сборки образа.	Put your `.dockerignore` file in the same folder as your Dockerfile and the rest of your build context.
При запуске команды `docker build`, инициирующей сборку образа, Docker проверяет папку на наличие в ней файла `.dockerignore`. Если такой файл найти удаётся, тогда этот файл разбирается, при этом при определении списка файлов, которые нужно игнорировать, используются правила функции `Match()` из пакета `filepath` Go и некоторые собственные правила Docker.	When you run docker build to create an image, Docker checks for a `.dockerignore` file. If one is found, it then goes through the file line by line and uses Go’s `filepath.Match` rules — and a few of Docker’s own rules — to match file names for exclusion. Think Unix-style glob patterns, not regular expressions.
Так, например, если в файле `.dockerignore` встретится шаблон вида `*.jpg`, то при создании образа проигнорированы будут файлы с любым именем и с расширением `.jpg`. Если в файле встретится строка `videos`, то система проигнорирует папку `videos` и всё её содержимое.	So `*.jpg` will exclude files with a `.jpg` extension. And `videos` will exclude the `videos` folder and its contents.
При составлении файла `.dockerignore` его можно снабжать комментариями, используя символ `#`.	You can explain what you’re doing in your `.dockerignore` with comments that start with a `#`.
Вот что даёт тому, кто занимается созданием образов Docker, применение файлов `.dockerignore`:	Using `.dockerignore` to exclude files you don’t need from your Docker image is a good idea. `.dockerignore` can:
• Это позволяет исключать из состава образа файлы, содержащие секретные сведения наподобие логинов и паролей. • Это позволяет уменьшить размер образа. Чем меньше в образе файлов — тем меньше будет его размер и тем быстрее с ним можно будет работать. • Это даёт возможность уменьшить число поводов для признания недействительным кэша при сборке похожих образов. Например, если при повторной сборке образа меняются некие служебные файлы проекта, наподобие файлов с журналами, из-за чего данные, хранящиеся в кэше, по сути, необоснованно признаются недействительными, это замедляет сборку образов.	• help you keep your secrets from being revealed. No one wants passwords in their images. • reduce image size. Fewer files means smaller, faster images. • reduce build cache invalidation. If logs or other files are changing and your image is having its cache invalidated because of it, that’s slowing down your build cycle.
Подробности о файле `.dockerignore` можно почитать в документации к Docker.	Those are the reasons to use a `.dockerignore` file. Check out the docs for more details.

Исследование размеров образов	Size Inspection

Поговорим о том, как, пользуясь средствами командной строки, узнавать размеры образов и контейнеров Docker.	Let’s look at how to find the size of Docker images and containers from the command line.
• Для того чтобы выяснить примерный размер выполняющегося контейнера, можно использовать команду вида `docker container ls -s` . • Команда `docker image ls` выводит размеры образов. • Узнать размеры промежуточных образов, из которых собран некий образ, можно с помощью команды `docker image history my_image:my_tag` . • Команда `docker image inspect my_image:tag` позволяет узнать подробные сведения об образе, в том числе — размер каждого его слоя. Слои немного отличаются от промежуточных образов, из которых состоит готовый образ, но, в большинстве случаев их можно рассматривать как одинаковые сущности. • Для того чтобы исследовать содержимое контейнеров можно установить пакет `dive` .	• To view the approximate size of a running container, you can use the command `docker container ls -s`. • Running `docker image ls` shows the sizes of your images. • To see the size of the intermediate images that make up your image use `docker image history my_image:my_tag`. • Running `docker image inspect my_image:tag` will show you many things about your image, including the sizes of each layer. Layers are subtly different than the images that make up an entire image. But you can think of them as the same for most purposes. • Installing and using the `dive` package makes it easy to see into your layer contents.
Теперь, когда мы обсудили возможности по уменьшению размеров образов, предлагаю вашему вниманию восемь рекомендаций, касающихся уменьшения размеров образов и ускорения процесса их сборки.	Now let’s look at a few best practices to slim things down.

Рекомендации по уменьшению размеров образов и ускорению процесса их сборки	Eight Best Practices to Reduce Image Sizes & Build Times



Этот метод позволяет сократить число слоёв, которые должны быть добавлены в образ, и помогает поддерживать код файла в приличном виде. 4. Включайте конструкцию вида `&& rm -rf /var/lib/apt/lists/*` в конец инструкции `RUN`, используемой для установки пакетов. Это позволит очистить кэш `apt` и приведёт к тому, что он не будет сохраняться в слое, сформированном командой `RUN`. Подробности об этом можно почитать в документации. 5. Разумно пользуйтесь возможностями кэширования, размещая в Dockerfile команды, вероятность изменения которых высока, ближе к концу файла. 6. Пользуйтесь файлом `.dockerignore`. 7. Взгляните на `dive` — отличный инструмент для исследования образов Docker, который помогает в деле уменьшения их размеров. 8. Не устанавливайте в образы пакеты, без которых можно обойтись.	This method reduces the number of layers to be built and keeps things nice and tidy. 4. Include `&& rm -rf /var/lib/apt/lists/*` at the end of the `RUN` instruction to clean up the `apt` cache so it isn’t stored in the layer. See more in the Docker Docks. 5. Use caching wisely by putting instructions likely to change lower in your Dockerfile. 6. Use a `.dockerignore` file to keep unwanted and unnecessary files out of your image. 7. Check out `dive` — a very cool tool for inspecting your Docker image layers and helping you trim the fat. 8. Don’t install packages you don’t need. Duh! But common.

Итоги	Wrap

Теперь вы знаете о том, как сделать так, чтобы образы Docker быстро собирались бы, быстро загружались бы из репозиториев и не занимали бы слишком много места на компьютере.	Now you know how to make Docker images that build quickly, download quickly, and don’t take up much space.

5. Команды


5. Команды	5. 15 Docker Commands You Should Know

Документация Docker содержит подробнейшее описание великого множества команд, но тот, кто только начинает работу с этой платформой, может в них и потеряться, поэтому здесь приведены почти два десятка самых важных команд для работы с Docker.	There are about a billion Docker commands (give or take a billion). The Docker docs are extensive, but overwhelming when you’re just getting started. In this article I’ll highlight the key commands for running vanilla Docker.

Обзор	Overview

Давайте вспомним о том, что образы Docker создают на основе файлов Dockerfile, описывающих всё то, что нужно для сборки образов. Кроме того, не будем забывать и о том, что контейнер — это образ Docker, вызванный к жизни. Для того чтобы эффективно пользоваться командами Docker, в первую очередь нужно выяснить — с чем вы имеете дело — с образом или с контейнером. Если подумать об образах и контейнерах, то можно понять, что образ Docker может либо существовать, либо не существовать. То же самое можно сказать и о контейнерах Docker. Существующий контейнер Docker, кроме того, может пребывать либо в работающем, либо в неработающем состоянии.	Recall that a Docker image is made of a Dockerfile + any necessary dependencies. Also recall that a Docker container is a Docker image brought to life. To work with Docker commands, you first need to know whether you’re dealing with an image or a container. • A Docker image either exists or it doesn’t. • A Docker container either exists or it doesn’t. • A Docker container that exists is either running or it isn’t.
После того, как вы выяснили, с чем именно вам нужно работать, вы можете найти подходящую команду.	Once you know what you’re working with you can find the right command for the job.

Общие сведения о командах Docker	Command Commonalities

Вот кое-что, о чём полезно знать тем, кто хочет работать с Docker:	Here are a few things to know about Docker commands:
• Команды интерфейса командной строки Docker, используемые для управления чем-либо, начинаются с ключевого слова `docker`, за которым идёт пробел, затем идёт указание на то, на что именно будет направлена некая команда, потом ещё один пробел, а потом следует сама команда. Например, именно так построена такая команда: `docker container stop`. • Если команда направлена на конкретный образ или контейнер, то в ней используется имя или идентификатор такого образа или контейнера.	• Docker CLI management commands start with `docker`, then a space, then the management category, then a space, and then the command. For example, `docker container stop` stops a container. • A command referring to a specific container or image requires the name or id of that container or image.
Например, команда `docker container run my_app` — это команда для создания и запуска контейнера с именем `my_app`. В примерах, которые будут приведены ниже, контейнеры мы будем называть `my_container`, образы — `my_image`, теги — `my_tag`, и так далее.	For example, `docker container run my_app` is the command to build and run the container named `my_app`. I’ll use the name `my_container` to refer to a generic container throughout the examples. Same goes for `my_image`, `my_tag`, etc.
Сначала мы будем рассматривать саму команду, потом — флаги, которые можно с ней использовать, если такие флаги существуют. Если перед флагом стоит два тире `--`, то это его полная форма, флаг с одним тире — это сокращённый вариант некоего флага. Действуют они одинаково. Например, `-p` — это сокращённая форма флага `--port`.	I’ll provide the command alone and then with common flags, if applicable. A flag with two dashes in front is the full name of the flag. A flag with one dash is a shortcut for the full flag name. For example, `-p` is short for the `--port` flag.
Цель этого материала заключается в том, чтобы дать вам общие сведения о командах Docker. Так вы, имея общее представление о них и зная о возможностях платформы, доступных благодаря этим командам, сможете, при необходимости, найти подробные сведения о них. Команды, о которых пойдёт речь, испытаны на ОС семейства Linux с использованием движка Docker версии 18.09.1 и API версии 1.39.	The goal is to help these commands and flags stick in your memory and for this guide to serve as a reference. This guide is current for Linux and Docker Engine Version 18.09.1 and API version 1.39.

Команды для управления контейнерами	Containers

Общая схема команд для управления контейнерами выглядит так: `docker container my_command` Вот команды, которые могут быть подставлены туда, где мы использовали `my_command`:	Use `docker container my_command`

• `create` — создание контейнера из образа. • `start` — запуск существующего контейнера. • `run` — создание контейнера и его запуск. • `ls` — вывод списка работающих контейнеров. • `inspect` — вывод подробной информации о контейнере. • `logs` — вывод логов. • `stop` — остановка работающего контейнера с отправкой главному процессу контейнера сигнала `SIGTERM`, и, через некоторое время, `SIGKILL`. • `kill` — остановка работающего контейнера с отправкой главному процессу контейнера сигнала `SIGKILL`. • `rm` — удаление остановленного контейнера.	• `create` — Create a container from an image. • `start` — Start an existing container. • `run` — Create a new container and start it. • `ls` — List running containers. • `inspect` — See lots of info about a container. • `logs` — Print logs. • `stop` — Gracefully stop running container. • `kill` —Stop main process in container abruptly. • `rm`— Delete a stopped container.

Команды для управления образами	Images

Для управления образами используются команды, которые выглядят так: `docker image my_command` Вот некоторые из команд этой группы:	Use `docker image my_command`

• `build` — сборка образа. • `push` — отправка образа в удалённый реестр. • `ls` — вывод списка образов. • `history` — вывод сведений о слоях образа. • `inspect` — вывод подробной информации об образе, в том числе — сведений о слоях. • `rm` — удаление образа.	• `build` — Build an image. • `push` — Push an image to a remote registry. • `ls` — List images. • `history` — See intermediate image info. • `inspect` — See lots of info about an image, including the layers. • `rm` — Delete an image.

Разные команды	Misc

• `docker version` — вывод сведений о версиях клиента и сервера Docker. • `docker login` — вход в реестр Docker. • `docker system prune` — удаление неиспользуемых контейнеров, сетей и образов, которым не назначено имя и тег.	• `docker version` — List info about your Docker Client and Server versions. • `docker login` — Log in to a Docker registry. • `docker system prune` — Delete all unused containers, unused networks, and dangling images.

Теперь рассмотрим эти команды подробнее.

Контейнеры	Containers

Начало существования контейнера	Container Beginnings

На начальном этапе работы с контейнерами используются команды `create`, `start` и `run`. Они применяются, соответственно, для создания контейнера, для его запуска, и для его создания и запуска.	The terms `create`, `start`, and `run` all have similar semantics in everyday life. But each is a separate Docker command that creates and/or starts a container. Let’s look at creating a container first.

Вот команда для создания контейнера из образа: `docker container create my_repo/my_image:my_tag`	`docker container create my_repo/my_image:my_tag` — Create a container from an image.

В следующих примерах конструкция `my_repo/my_image:my_tag` будет сокращена до `my_image`.	I’ll shorten `my_repo/my_image:my_tag` to `my_image` for the rest of the article.

Команда `create` принимает множество флагов. Например, её можно записать в таком виде:	There are a lot of possible flags you could pass to `create`.
`docker container create -a STDIN my_image`

Флаг `-a` представляет собой краткую форму флага `--attach`. Этот флаг позволяет подключить контейнер к `STDIN`, `STDOUT` или `STDERR`.	`-a` is short for `--attach`. Attach the container to `STDIN`, `STDOUT` or `STDERR`.
После того, как контейнер создан, его можно запустить следующей командой: `docker container start my_container`	Now that we’ve created a container let’s start it. `docker container start my_container` — Start an existing container.

Обратите внимание на то, что сослаться на контейнер в команде можно либо используя его `ID`, либо имя.	Note that the container can be referred to by either the container’s `ID` or the container’s name.

Теперь взглянем на команду, которая позволяет создать и запустить контейнер: `docker container run my_image` Эта команда тоже способна принимать множество аргументов командной строки. Рассмотрим некоторые из них на примере такой конструкции:	`docker container run my_image` — Create a new container and start it. It also has a lot of options. Let’s look at a few.
`docker container run -i -t -p 1000:8000 --rm my_image`

Флаг `-i` — это сокращение для `--interactive` . Благодаря этому флагу поток `STDIN` поддерживается в открытом состоянии даже если контейнер к `STDIN` не подключён.	`-i` is short for `--interactive` . Keep `STDIN` open even if unattached.
Флаг `-t` — это сокращение для `--tty` . Благодаря этому флагу выделяется псевдотерминал, который соединяет используемый терминал с потоками `STDIN` и `STDOUT` контейнера.	`-t` is short for `--tty` . Allocates a pseudo terminal that connects your terminal with the container’s `STDIN` and `STDOUT` .
Для того чтобы получить возможность взаимодействия с контейнером через терминал нужно совместно использовать флаги `-i` и `-t` .	You need to specify both `-i` and `-t` to then interact with the container through your terminal shell.
Флаг `-p` представляет собой сокращение для `--port` . Порт — это интерфейс, благодаря которому контейнер взаимодействует с внешним миром. Конструкция `1000:8000` перенаправляет порт Docker `8000` на порт `1000` компьютера, на котором выполняется контейнер. Если в контейнере работает некое приложение, способное выводить что-то в браузер, то, для того, чтобы к нему обратиться, в нашем случае можно перейти в браузере по адресу `localhost:1000`.	`-p` is short for `--port`. The port is the interface with the outside world. `1000:8000` maps the Docker port `8000` to port `1000` on your machine. If you had an app that output something to the browser you could then navigate your browser to `localhost:1000` and see it.
Флаг `--rm` автоматически удаляет контейнер после того, как его выполнение завершится.	`--rm` — Automatically delete the container when it stops running.

Рассмотрим ещё некоторые примеры команды `run` :	Let’s look at some more examples of `run` .

`docker container run -it my_image my_command`

В подобной конструкции может применяться команда `sh` , которая создаст сессию терминала в контейнере, с которой можно взаимодействовать через ваш терминал. При работе с образами, основанными на Alpine, лучше ориентироваться на использование `sh`, а не `bash` , так как в этих образах, по умолчанию, оболочка `bash` не установлена. Для выхода из интерактивной сессии воспользуйтесь командой `exit` .	`sh` is a command you could specify at run time. `sh` will start a shell session inside your container that you can interact with through your terminal. `sh` is preferable to `bash` for Alpine images because Alpine images don’t come with bash installed. Type `exit` to end the interactive shell session.
Обратите внимание на то, что здесь мы скомбинировали флаги `-i` и `-t` в `-it` .	Notice that we combined `-i` and `-t` into `-it` .

Вот ещё один пример работы с командой `run` :
`docker container run -d my_image`
Флаг `-d` — это сокращение для `--detach` . Эта команда запускает контейнер в фоновом режиме. Это позволяет использовать терминал, из которого запущен контейнер, для выполнения других команд во время работы контейнера.	`-d` is short for `--detach` . Run the container in the background. Allows you to use the terminal for other commands while your container runs.

Проверка состояния контейнера	Checking Container Status

Если у вас имеются запущенные контейнеры Docker и вы хотите узнать о том, что это за контейнеры, вам понадобится вывести их список. Сделать это можно такой командой:	If you have running Docker containers and want to find out which one to interact with, then you need to list them.

`docker container ls`

Эта команда выводит список выполняющихся контейнеров и снабжает этот список некоторыми полезными сведениями о них. Вот ещё один пример этой команды:	List running containers. Also provides useful information about the containers.

`docker container ls -a -s`

Ключ `-a` этой команды — это сокращение для `--all` . Благодаря использованию этого ключа можно вывести сведения обо всех контейнерах, а не только о выполняющихся.	`-a` is short for `-all` . List all containers (not just running ones).
Ключ `-s` — это сокращение для `--size` . Он позволяет вывести размеры контейнеров.	`-s` is short for `--size` . List the size for each container.

Вот команда, которая выводит подробные сведения о контейнере: `docker container inspect my_container`	`docker container inspect my_container` — See lots of info about a container.

Вот команда, выводящая логи контейнера: `docker container logs my_container`	`docker container logs my_container` — Print a container’s logs.

Завершение работы контейнера	Container Endings

Иногда работающий контейнер надо остановить.	Sometimes you need to stop a running container.
Для этого используется такая команда: `docker container stop my_container`. Она позволяет останавливать работающие контейнеры, позволяя им корректно завершить работу. У контейнера есть, по умолчанию, 10 секунд, на то, чтобы завершить работу.	`docker container stop my_container` — Stop one or more running containers gracefully. Gives a default of 10 seconds before container shutdown to finish any processes.
Если же контейнер нужно остановить быстро, не заботясь о корректном завершении его работы, можно воспользоваться такой командой: `docker container kill my_container` Команда `kill`, если сравнить работающий контейнер с включенным телевизором, напоминает выключение телевизора путём отключения его от электричества. Поэтому, в большинстве ситуаций, для остановки контейнеров рекомендуется использовать команду `stop`.	Or if you are impatient: `docker container kill my_container` — Stop one or more running containers abruptly. It’s like pulling the plug on the TV. Prefer `stop` in most situations.

Вот команда, которая позволяет быстро остановить все работающие контейнеры: `docker container kill $(docker ps -q)`	`docker container kill $(docker ps -q)` — Kill all running containers.
	Then you delete the container with:
Для удаления остановленного контейнера можно воспользоваться такой командой: `docker container rm my_container`	`docker container rm my_container` — Delete one or more containers.
Вот команда, которая позволяет удалить все контейнеры, которые на момент вызова этой команды не выполняются: `docker container rm $(docker ps -a -q)`	`docker container rm $(docker ps -a -q)` — Delete all containers that are not running.

Подведём итоги этого раздела. Сначала контейнер создают, потом его запускают, или комбинируют эти два шага, используя команду вида `docker run my_container` . После этого запускается контейнеризированное приложение.	To recap, you first create a container. Then, you start the container. Or combine those steps with `docker run my_container` . Then, your app runs. Yippee!
Потом контейнер останавливают командой `docker stop my_container` . Для удаления контейнера используется команда `docker rm my_container` .	Then, you stop a container with `docker stop my_container` . Eventually you delete the container with `docker rm my_container` .
Поговорим теперь о командах, используемых для работы с образами, с теми самыми шаблонами, из которых создают контейнеры.	Now, let’s turn to the magical container-producing molds called images.

Образы	Images

Создание образов	Developing Images

Вот команда, которая позволяет собирать образы Docker: `docker image build -t my_repo/my_image:my_tag .` В данном случае создаётся образ с именем `my_image` , при его сборке используется файл Dockerfile, находящийся по указанному пути или URL.	`docker image build -t my_repo/my_image:my_tag .` — Build a Docker image named `my_image` from the Dockerfile located at the specified path or URL.
Флаг `-t` — это сокращение для `--tag` . Он указывает Docker на то, что создаваемому образу надо назначить предоставленный в команде тег. В данном случае это `my_tag`.	`-t` is short for `--tag` . Tells docker to tag the image with the provided tag. In this case `my_tag` .
Точка в конце команды указывает на то, что образ надо собрать с использованием файла Dockerfile, находящегося в текущей рабочей директории.	The `.` (period) at the end of the command tells Docker to build the image according to the Dockerfile in the current working directory.

После того, как образ собран, его можно отправить в удалённый реестр. Благодаря этому им смогут воспользоваться другие люди, его можно будет загрузить и запустить на другом компьютере. Предположим, вы хотите использовать Docker Hub. Если так — вам понадобится завести там учётную запись. Пользоваться этим ресурсом можно бесплатно.	Once you have an image built you want to push it to a remote registry so it can be shared and pulled down as needed. Assuming you want to use Docker Hub, go there in your browser and create an account. It’s free. 😄
После того, как вы зарегистрируетесь на Docker Hub, вам нужно войти в систему. И хотя команда, которая для этого используется, напрямую к командам, предназначенным для работы с образами, не относится, её полезно будет рассмотреть именно здесь.	This next command isn’t an image command, but it’s useful to see here, so I’ll mention it.
Речь идёт о следующей команде: `docker login` Она позволяет войти в учётную запись на Docker Hub. Для входа в систему вам понадобится ввести имя пользователя и пароль.	`docker login` — Log in to a Docker registry. Enter your username and password when prompted.
После входа в систему можно будет отправлять образы в реестр. Делается это так: `docker image push my_repo/my_image:my_tag`	`docker image push my_repo/my_image:my_tag` — Push an image to a registry.
Теперь, когда у вас наберётся несколько образов, вы можете их исследовать с помощью специальных команд.	Once you have some images you might want to inspect them.

Исследование образов	Inspecting Images

Вот команда, которая выводит список образов, выводя, в том числе, и сведения об их размере: `docker image ls`	`docker image ls` — List your images. Shows you the size of each image, too.
Следующая команда позволяет вывести сведения о промежуточных образах, входящих в состав образа, в частности — данные об их размерах и о том, как они были созданы: `docker image history my_image`	`docker image history my_image` — Display an image’s intermediate images with sizes and how they were created.
Вот команда, которая выводит подробные сведения об образе, в том числе — данные о слоях, из которых состоит образ: `docker image inspect my_image`	`docker image inspect my_image` — Show lots of details about your image, including the layers that make up the image.

Если вы создадите очень много образов, может случиться так, что некоторые из них понадобится удалить.	Sometimes you’ll need to clean up your images.

Удаление образов	Removing Images

Вот команда, которая позволяет удалить указанный образ: `docker image rm my_image` Если образ хранится в удалённом репозитории, он оттуда удалён не будет.	`docker image rm my_image` — Delete the specified image. If the image is stored in a remote repository, the image will still be available there.

Вот команда, которая позволяет удалить все локальные образы: `docker image rm $(docker images -a -q)`	`docker image rm $(docker images -a -q)` — Delete all images.
Пользоваться этой командой стоит с осторожностью, но надо заметить, что при её использовании образы, хранящиеся в удалённом репозитории, удалены не будут. В этом заключается одно из преимуществ хранения образов в репозиториях.	Careful with this one! Note that images that have been pushed to a remote registry will be preserved — that’s one of the benefits of registries. 😃

Мы рассмотрели основные команды, используемые для управления контейнерами и образами. Поговорим теперь ещё о некоторых командах.	Now you know most essential Docker image-related commands.

Разные команды	Misc

Вот команда, которая выводит сведения о версиях клиента и сервера Docker: `docker version`	`docker version` — List info about your Docker Client and Server versions.

Эта, уже известная вам команда, применяется для входа в реестр Docker: `docker login`	`docker login` — Log in to a Docker registry. Enter your username and password when prompted.

Такая команда позволяет удалить неиспользуемые контейнеры, сети и образы, которым не назначено имя и тег: `docker system prune`	`docker system prune` — Delete all unused containers, unused networks, and dangling images.

Вот пример её использования: `docker system prune -a --volumes`	`docker system prune -a --volumes`
Ключ `-a` — сокращение для `--all` , позволяет удалить неиспользуемые образы, а не только те, которым не назначено имя и тег.	`-a` is short for `--all` . Delete unused images, not just dangling ones.
Ключ `--volumes` позволяет удалить неиспользуемые тома.	`--volumes` — Remove unused volumes.

Итоги	Wrap

В этом материале мы рассмотрели полезные команды Docker. Если вы только начинаете работать с Docker, то вам стоит обратить внимание на три следующих важнейших команды:	If you are just getting started with Docker, these are the three most important commands:

Создание и запуск контейнера: `docker container run my_image`	`docker container run my_image` — Create a new container and start it. You’ll probably want some flags here.

Сборка образа: `docker image build -t my_repo/my_image:my_tag .`	`docker image build -t my_repo/my_image:my_tag .` — Build an image.

Отправка образа в удалённый репозиторий: `docker image push my_repo/my_image:my_tag`	`docker image push my_repo/my_image:my_tag` — Push an image to a remote registry.

Для того чтобы посмотреть справку по командам Docker, можете выполнить в терминале команду `docker` .	To view the CLI reference when using Docker just enter the command `docker` in the command line.

6. Работа с данными


6. Работа с данными	6. Pump up the Volumes: Data in Docker

Поговорим о работе с данными. В частности — о томах Docker.	This part is about using data with Docker. In it, we’ll focus on Docker volumes.
Данные в Docker могут храниться либо временно, либо постоянно. Начнём с временных данных.	Data in Docker can either be temporary or persistent. Let’s check out temporary data first.

Временное хранение данных	Temporary Data

В контейнерах Docker организовать работу с временными данными можно двумя способами.	Data can be kept temporarily inside a Docker container in two ways.
По умолчанию файлы, создаваемые приложением, работающим в контейнере, сохраняются в слое контейнера, поддерживающем запись. Для того чтобы этот механизм работал, ничего специально настраивать не нужно. Получается дёшево и сердито. Приложению достаточно просто сохранить данные и продолжить заниматься своими делами. Однако после того как контейнер перестанет существовать, исчезнут и данные, сохранённые таким вот нехитрым способом.	By default, files created by an application inside a container are stored in the writable layer of the container. You don’t have to set anything up. This is the quick and dirty way. Just save a file and go about your business. However, when you container ceases to exist, so will your data.
Для хранения временных файлов в Docker можно воспользоваться ещё одним решением, подходящим для тех случаев, когда требуется более высокий уровень производительности, в сравнении с тем, который достижим при использовании стандартного механизма временного хранения данных. Если вам не нужно, чтобы ваши данные хранились бы дольше, чем существует контейнер, вы можете подключить к контейнеру tmpfs — временное хранилище информации, которое использует оперативную память хоста. Это позволит ускорить выполнение операций по записи и чтению данных.	You have another option if you want better performance for saving temporary data with Docker. If you don’t need your data to persist beyond the life of the container, a tmpfs mount is a temporary mount that uses the host’s memory. A tmpfs mount has the benefit of faster read and write operations.
Часто бывает так, что данные нужно хранить и после того, как контейнер прекратит существовать. Для этого нам пригодятся механизмы постоянного хранения данных.	Many times you will want your data to exist even after the container is long gone. You need to persist your data.

Постоянное хранение данных	Persistent Data

Существуют два способа, позволяющих сделать срок жизни данных большим срока жизни контейнера. Один из способов заключается в использовании технологии `bind mount`. При таком подходе к контейнеру можно примонтировать, например, реально существующую папку. Работать с данными, хранящимися в такой папке, смогут и процессы, находящиеся за пределами Docker. Вот как выглядят монтирование tmpfs и технология bind mount.	There are two ways to persist data beyond the life of the container. One way is to `bind mount` a file system to the container. With a bind mount, processes outside Docker also can modify the data.


Монтирование tmpfs и bind mount	From the Docker Docs

Минусы использования технологии `bind mount` заключаются в том, что её использование усложняет резервное копирование данных, миграцию данных, совместное использование данных несколькими контейнерами. Гораздо лучше для постоянного хранения данных использовать тома Docker.	Bind mounts are difficult to back up, migrate, or share with other Containers. Volumes are a better way to persist data.

Тома Docker	Volumes

Том — это файловая система, которая расположена на хост-машине за пределами контейнеров. Созданием и управлением томами занимается Docker. Вот основные свойства томов Docker:	A Volume is a a file system that lives on a host machine outside of any container. Volumes are created and managed by Docker. Volumes are:
• Они представляют собой средства для постоянного хранения информации. • Они самостоятельны и отделены от контейнеров. • Ими могут совместно пользоваться разные контейнеры. • Они позволяют организовать эффективное чтение и запись данных. • Тома можно размещать на ресурсах удалённого облачного провайдера. • Их можно шифровать. • Им можно давать имена. • Контейнер может организовать заблаговременное наполнение тома данными. • Они удобны для тестирования.	• persistent • free-floating filesystems, separate from any one container • sharable with other containers • efficient for input and output • able to be hosted on remote cloud providers • encryptable • nameable • able to have their content pre-populated by a container • handy for testing
Как видите, тома Docker обладают замечательными свойствами. Давайте поговорим о том, как их создавать.	That’s a lot of useful functionality! Now let’s look at how you make a Volume.

Создание томов	Creating Volumes
Тома можно создавать средствами Docker или с помощью запросов к API.	Volumes can be created via a Dockerfile or an API request.
Вот инструкция в Dockerfile, которая позволяет создать том при запуске контейнера.	Here’s a Dockerfile instruction that creates a volume at run time:

`VOLUME /my_volume`

При использовании подобной инструкции Docker, после создания контейнера, создаст том, содержащий данные, которые уже имеются в указанном месте. Обратите внимание на то, что если вы создаёте том с использованием Dockerfile, это не освобождает вас от необходимости указать точку монтирования тома.	Then, when the container is created, Docker will create the volume with any data that already exists at the specified location. Note that if you create a volume using a Dockerfile, you still need to declare the mountpoint for the volume at run time.
Создавать тома в Dockerfile можно и используя формат JSON.	You can also create a volume in a Dockerfile using JSON array formatting.
Кроме того, тома можно создавать средствами командной строки во время работы контейнера.	Volumes also can be instantiated at run time from the command line.

Работа с томами из командной строки	Volume CLI Commands

Создание тома	Create
Создать самостоятельный том можно следующей командой: `docker volume create —-name my_volume`	You can create a stand-alone volume with `docker volume create —-name my_volume`.

Выяснение информации о томах	Inspect
Для того чтобы просмотреть список томов Docker, воспользуйтесь следующей командой: `docker volume ls`	List Docker volumes with `docker volume ls`.

Исследовать конкретный том можно так: `docker volume inspect my_volume`	Volumes can be inspected with `docker volume inspect my_volume`.

Удаление тома	Remove
Удалить том можно так: `docker volume rm my_volume`	Then you can delete the volume with `docker volume rm my_volume`.

Для того чтобы удалить все тома, которые не используются контейнерами, можно прибегнуть к такой команде: `docker volume prune`	Dangling volumes are volumes not used by a container. You can remove all dangling volumes with `docker volume prune`.
Перед удалением томов Docker запросит у вас подтверждение выполнения этой операции.	Docker will warn you and ask for confirmation before deletion.

Если том связан с каким-либо контейнером, такой том нельзя удалить до тех пор, пока не удалён соответствующий контейнер. При этом, даже если контейнер удалён, Docker не всегда это понимает. Если это случилось — можете воспользоваться следующей командой: `docker system prune` . Она предназначена для очистки ресурсов Docker. После выполнения этой команды у вас должна появиться возможность удалить тома, статус которых до этого определялся неправильно.	If the volume is associated with any containers, you cannot remove it until the containers are deleted. Even then, Docker sometimes doesn’t realize that the containers are gone. If this occurs, you can use `docker system prune` to clean up all your Docker resources. Then you should should be able to delete the volume.

Флаги `--mount` и `--volume`	Working with `--mount` vs. `--volume`
Для работы с томами вам, при вызове команды docker, часто придётся пользоваться флагами. Например, для того чтобы создать том во время создания контейнера можно воспользоваться такой конструкцией:	You will often use flags to refer to your volumes. For example, to create a volume at the same time you create a container use the following:

`docker container run --mount source=my_volume, target=/container/path/for/volume my_image`

В давние времена (до 2017 года) популярен был флаг `--volume`. Изначально этот флаг (ещё им можно пользоваться в сокращённом виде, тогда он выглядит как `-v`) использовался для самостоятельных контейнеров, а флаг `--mount` — в среде Docker Swarm. Однако, начиная с Docker 17.06, флаг `--mount` можно использовать в любых сценариях.	In the old days (i.e. pre-2017) 😏the `--volume` flag was popular. Originally, the `-v` or `--volume` flag was used for standalone containers and the `--mount` flag was used with Docker Swarms. However, beginning with Docker 17.06, you can use `--mount` in all cases.
Надо отметить, что при использовании флага `--mount` увеличивается объём дополнительных данных, которые приходится указывать в команде, но, по нескольким причинам, лучше использовать именно этот флаг, а не `--volume`. Флаг `--mount` — это единственный механизм, который позволяет работать с сервисами или указывать параметры драйвера тома. Кроме того, работать с этим флагом проще.	The syntax for `--mount` is a bit more verbose, but it’s preferred over `--volume` for several reasons. `--mount` is the only way you can work with services or specify volume driver options. It’s also simpler to use.
В существующих примерах команд, направленных на работу с данными в Docker, вы можете встретить множество примеров употребления флага `-v`. Пытаясь адаптировать эти команды для себя, учитывайте то, что флаги `--mount` и `--volume` используют различные форматы параметров. То есть, нельзя просто заменить `-v` на `--mount` и получить рабочую команду.	You’ll see a lot of `-v`’s in existing code. Beware that the format for the options is different for `--mount` and `--volume`. You often can’t just replace a `-v` in your existing code with a `--mount` and be done with it.
Главное различие между `--mount` и `--volume` заключается в том, что при использовании флага `--volume` все параметры собирают вместе, в одном поле, а при использовании `--mount` параметры разделяются.	The biggest difference is that the `-v` syntax combines all the options together in one field, while the `--mount` syntax separates them. Let’s see `--mount` in action!
При работе с `--mount` параметры представлены как пары вида ключ-значение, а именно, это выглядит как `key=value`. Эти пары разделяют запятыми. Вот часто используемые параметры `--mount`:	`--mount` — options are key-value pairs. Each pair is formatted like this: `key=value`, with a comma between one pair and the next. Common options:
• `type` — тип монтирования. Значением для соответствующего ключа могут выступать `bind`, `volume` или `tmpfs`. Мы тут говорим о томах, то есть — нас интересует значение `volume`. • `source` — источник монтирования. Для именованных томов это — имя тома. Для неименованных томов этот ключ не указывают. Он может быть сокращён до `src`. • `destination` — путь, к которому файл или папка монтируется в контейнере. Этот ключ может быть сокращён до `dst` или `target`. • `readonly` — монтирует том, который предназначен только для чтения. Использовать этот ключ необязательно, значение ему не назначают.	• `type` — mount type. Options are `bind`, `volume`, or `tmpfs`. We’re all about the `volume`. • `source` — source of the mount. For named volumes, this is the name of the volume. For unnamed volumes, this option is omitted. The key can be shortened to `src`. • `destination` — the path where the file or directory is mounted in the container. The key can be shortened to `dst` or `target`. • `readonly` —mounts the volume as read-only. Optional. Takes no value.
Вот пример использования `--mount` с множеством параметров:	Here’s an example with lots of options:

`docker run --mount type=volume,source=volume_name,destination=/path/in/container,readonly my_image`

Итоги	Wrap

Вот полезные команды, которыми можно пользоваться при работе с томами Docker:	Recap of Key Volume Commands

`docker volume create` `docker volume ls` `docker volume inspect` `docker volume rm` `docker volume prune`

Вот список часто используемых параметров для `--mount`, применимых в команде вида `docker run --mount my_options my_image`:	Common options for the `--mount` flag in `docker run --mount my_options my_image`:

`type=volume` `source=volume_name` `destination=/path/in/container` `readonly`

Материалы обработал: admin

12.05.2023