Как сделать docker контейнер
Создание собственного образа Docker
Docker позволяет не только загружать и использовать готовые контейнеры, но создавать свои. В данной инструкции мы пошагово разберем установку Docker на Linux, создание собственного образа и загрузку его на Docker Hub.
Установка Docker
Рассмотрим примеры установки на базе операционных систем Red Hat/CentOS и Debian/Ubuntu.
Red Hat/CentOS
Устанавливаем репозиторий — для этого загружаем файл с настройками репозитория:
* если система вернет ошибку, устанавливаем wget командой yum install wget.
. и переносим его в каталог yum.repos.d:
mv docker-ce.repo /etc/yum.repos.d/
yum install docker-ce docker-ce-cli containerd.io
. с помощью данной ссылки выполняем установку:
yum install http://mirror.centos.org/centos/7/extras/x86_64/Packages/container-selinux-2.99-1.el7_6.noarch.rpm
После повторяем команду на установку докера:
yum install docker-ce docker-ce-cli containerd.io
Debian/Ubuntu
В deb-системе ставится командой:
apt-get install docker docker.io
После установки
Разрешаем запуск сервиса docker:
systemctl enable docker
systemctl start docker
docker run hello-world
.
Hello from Docker!
This message shows that your installation appears to be working correctly.
.
Сборка нового образа
Сборка начинается с создания файла Dockerfile — он содержит инструкции того, что должно быть в контейнере. В качестве примера, соберем свой веб-сервер nginx.
И так, чтобы создать свой образ с нуля, создаем каталог для размещения Dockerfile:
* где /opt/docker/mynginx — полный путь до каталога, где будем создавать образ.
. переходим в данный каталог:
. и создаем Dockerfile:
MAINTAINER Dmitriy Mosk
* подробное описание инструкций Dockerfile смотрите ниже.
* где dmosk — имя автора; nginx — название для сборки; v1 — тег с указанием версии. Точка на конце указывает, что поиск Dockerfile выполняем в текущей директории.
. начнется процесс сборки образа — после его завершения мы должны увидеть что-то на подобие:
Successfully built eae801eaeff2
Successfully tagged dmosk/nginx:v1
Посмотреть список образов можно командой:
Создаем и запускаем контейнер из образа:
* в данном примере мы запустим контейнер из образа dmosk/nginx:v1 и укажем, что необходимо опубликовать внешний порт 8080, который будет перенаправлять трафик на порт 80 внутри контейнера.
Открываем браузер и переходим по адресу http:// :8080 — мы должны увидеть страницу приветствия с нашим docker-nginx:
Посмотреть созданные контейнеры можно командой:
Запустить или остановить контейнеры можно командами:
docker stop 5fe78aca2e1d
docker start 5fe78aca2e1d
* где 5fe78aca2e1d — идентификатор контейнера.
Редактирование образа
В примере выше мы рассмотрели создание нового образа с нуля. Также, мы можем взять любой другой образ, отредактировать его и сохранить под своим названием.
Скачаем образ операционной системы CentOS:
docker pull centos:latest
Войдем в скачанный образ для его изменения:
Внесем небольшие изменения, например, создадим учетную запись:
[root@8f07ef93918f /]# passwd dmosk
* в данном примере мы создали пользователя dmosk и задали ему пароль.
* где -m — параметр для указания комментария; -a — указывает автора; 8f07ef93918f — идентификатор контейнера, который был нами изменен (его можно было увидеть в приглашении командной строки); centos:my — название нашего нового образа.
Новый образ создан.
Загрузка образа на Docker Hub
Заходим на Docker Hub страницу регистрации. Создаем пользователя:
На следующей странице также заполняем данные профиля. После переходим в почтовый ящик, который был указан при регистрации и переходим по ссылке Confirm Your Email With Docker для подтверждения регистрации. Регистрация закончена.
Переходим на страницу Repositories и создаем свой репозиторий, например, dmosk. Теперь можно загрузить наши образы в репозиторий.
Сначала авторизуемся в Linux под нашим зарегистрированным пользователем:
Задаем тег для одного из образов и загружаем его в репозиторий:
docker tag centos:my dmosk/dmosk:centos
docker push dmosk/dmosk:centos
Загрузим второй образ:
docker tag dmosk/nginx:v1 dmosk/dmosk:nginx
docker push dmosk/dmosk:nginx
В Docker Hub должны появиться наш образы:
Чтобы воспользоваться образом на другом компьютере, также авторизуемся под зарегистрированным пользователем docker:
docker pull dmosk/dmosk:nginx
Описание инструкций Dockerfile
Резервное копирование и восстановление контейнера
Созданный нами контейнер можно сохранить в виде архива и, при необходимости, перенести на другой сервер или оставить как бэкап.
Создание резерва
И так, для создания резервной копии контейнера, смотрим их список:
. и для нужного выполняем команду:
* в данном примере мы создаем архив контейнера в файл /backup/docker/container.tar.
Чтобы уменьшить размер, занимаемый созданным файлом, раархивиркем его командой:
* в итоге, мы получим файл container.tar.gz.
Восстановление
Сначала распаковываем архив:
После восстанавливаем контейнер:
Смотрим, что нужный нам контейнер появился:
Дополнительные команды
В данном подразделе приведем примеры команд, которые могут оказаться полезными при работе с образами.
1. Удалить один образ:
docker rmi dmosk/nginx:v1
2. Удалить все образы:
Мы можем получить ошибки на подобие:
Это значит, что для удаляемого образа есть действующие контейнеры — они могут быть как включены, так и находится в отключенном состоянии. Удалить все нерабочие контейнеры можно командой:
Если нужно, можно остановить все действующие контейнеры командой:
Также мы можем принудительно удалить все образы, даже если они используются для контейнеров в данный момент:
* добавлена опция -f.
3. Для выявления проблем при запуске или в работе контейнера очень полезна опция для просмотра логов:
docker logs my_nginx
Также можно смотреть логи непрерывно (follow):
Докер с нуля: создание образов
Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)
В этом учебном пособии из двух частей я подробно изучаю образы Docker. В первой части я обсудил основные принципы, соображения проектирования и осмотр внутренних образов. В этой части я расскажу о том, как создавать собственные образы, устранять неполадки и работать с репозиториями образов.
Когда вы выйдете с другой стороны, у вас будет четкое представление о том, что именно представляют из себя образы Docker и как их эффективно использовать в ваших собственных приложениях и системах.
Создание образов
Существует два способа создания образов. Вы можете изменить существующий контейнер, а затем зафиксировать его как новый образ, или вы можете написать свой Dockerfile и создать его для образа. Мы перейдем к обоим и объясним плюсы и минусы.
Ручные сборки
С помощью ручных сборок вы обрабатываете свой контейнер как обычный компьютер. Вы устанавливаете пакеты, вы пишете файлы, и когда все это будет сказано и сделано, вы фиксируете его и получаете новый образ, который вы используете в качестве шаблона, чтобы создать еще много идентичных контейнеров или даже основывать другие образы.
Вот так. Приятно, мы уже в корневом каталоге. Посмотрим, что там.
Какой редактор доступен? Нет vim, нет nano?
Ну что ж. Мы просто хотим создать файл:
Здесь я создаю новый образ из контейнера «vibrate_spence». Я добавил сообщение о фиксации «mine, mine, mine» в качестве отметки.
Давайте посмотрим. Да, есть новый образ, и в его истории вы можете увидеть новый слой с комментарием «mine, mine, mine».
Теперь для настоящего теста. Удалим контейнер и создадим новый контейнер из образа. Ожидаемый результат заключается в том, что файл «yeah» будет присутствовать в новом контейнере.
Что я могу сказать? Да, это работает!
Использование Dockerfile
Создание образов из модифицированных контейнеров классно, но нет ответственности. Трудно отслеживать изменения и знать, каковы были конкретные изменения. Дисциплинированный способ создания образов состоит в их создании с помощью Dockerfile.
Здесь я просто продемонстрирую пару команд для создания другого образа «oh-yeah-alpine» на основе Dockerfile. В дополнение к созданию печально известного файла «yeah», давайте также установим vim. В альпийском дистрибутиве Linux используется система управления пакетами под названием «apk». Вот наш Dockerfile:
Базовым образом является alpine. Он копирует файл «yeah» из одного и того же каталога хоста, где находится файл Dockerfile (путь контекста сборки). Затем он выполняет apk update и устанавливает vim. Наконец, он устанавливает команду, которая выполняется при запуске контейнера. В этом случае он выведет на экран содержимое файла « yeah».
ОК. Теперь, когда мы знаем, к чему мы стремимся, давайте построим наш орбраз. Параметр «-t» задает репозиторий. Я не указал тег, поэтому он будет по умолчанию «последним».
Выглядит неплохо. Давайте проверим, что образ был создан:
Обратите внимание, что установка vim и его зависимостей раздула размер контейнера с 4,8 Мбайт базового альпийского образа до массивных 30,5 МБ!
Все очень хорошо. Но работает ли это?
Если вы все еще подозрительны, давайте перейдем в контейнер и откроем файл «yeah» с помощью нашего недавно установленного vim.
Я не сказал вам, но изначально, когда я пытался построить oh-yeah-alpine образ, он просто висел в течение нескольких минут. Проблема в том, что я просто поместил Dockerfile в свой домашний каталог. Когда Docker создает образ, он сначала упаковывает весь каталог, в котором находится Dockerfile (включая подкаталоги), и делает его доступным для команд COPY в Dockerfile.
Docker не пытается быть умным и анализирует ваши команды COPY. Он просто собирает все это. Обратите внимание, что содержимое сборки не будет заканчиваться вашим образом, но это замедлит вашу команду сборки, если ваш контекст сборки излишне большой.
В контексте сборки нет необходимости включать сам файл Dockerfile или файл «.dockerignore».
Копирование против монтажа
Копирование файлов в образ иногда требуется вам, но в других случаях вы можете захотеть, чтобы ваши контейнеры были более динамичными и работали с файлами на хосте. Именно здесь вступают в силу тома и монтаж файловой системы.
Тегирование образов
Маркировка образов очень важна, если вы разрабатываете систему на основе микросервисов и генерируете много образов, которые иногда должны быть связаны друг с другом. Вы можете добавить образу столько меток, сколько хотите.
Вы уже видели по умолчанию «latest» тег. Иногда имеет смысл добавлять другие теги, такие как «tested», «release-1.4» или git коммит, соответствующий этому образу.
Вы можете пометить образ во время сборки или позже. Вот как добавить тег к существующему образу. Обратите внимание, что, хотя он называется тегом, вы также можете назначить новый репозиторий.
Вы также можете отменить тег удаляя образ по имени своего тега. Это немного страшно, потому что если вы удаляете последний тег случайно, вы теряете образ. Но если вы создаете образы из Dockerfile, вы можете просто его пересобрать.
Если я попытаюсь удалить последний оставшийся помеченный образ, я получаю сообщение об ошибке, потому что он используется контейнером.
Ага. Он исчез. Но не волнуйся. Мы можем его пересобрать:
Верно, он вернулся. Dockerfile помог!
Работа с реестрами образов
Образы очень похожи в некоторых отношениях на git-хранилища. Они также построены из упорядоченного набора коммитов. Вы можете думать о двух образах, которые используют те же базовые образы, как о ветках в git (хотя в Docker нет слияния или перезагрузки). Реестр образов является эквивалентом центрального сервиса git-хостинга, такого как GitHub. Угадайте, как называется официальный реестр образов Docker? Правильно, Docker Hub.
Вытягивание образов
Когда вы запускаете образ, если он не существует, Docker попытается вытащить его из одного из ваших настроенных реестров образов. По умолчанию он переходит в Docker Hub, но вы можете управлять этим в файле «
/.docker/config.json». Если вы используете другой реестр, вы можете следовать их инструкциям, которые обычно включают вход с использованием их учетных данных.
Он исчез. Теперь вытаскиваем.
Последний hello-world был заменен более новой версией.
Выгрузка образов
Выгрузка образов немного более сложная. Сначала вам нужно создать учетную запись на Docker Hub (или другом реестре). Затем вы входите в систему. Затем вам нужно пометить образ, который вы хотите выложить, в соответствии с именем вашей учетной записи («g1g1» в моем случае).
Теперь я могу выложить образ помеченный, тегом g1g1/hello-world.
Вывод
Docker предоставляет множество инструментов для регистрации, проверки, создания и маркировки образов. Вы можете загружать и перемещать образы в реестры образов, такие как Docker Hub, для простого управления и обмена образами.
Docker. Начало
Примерно такие же эмоции я и мои коллеги испытывали, когда начинали работать с Docker. В подавляющем большинстве случаев это происходило от недостатка понимания основных механизмов, поэтому его поведение казалось нам непредсказуемым. Сейчас страсти поутихли и вспышки ненависти происходят все реже и все слабее. Более того, постепенно мы на практике оцениваем его достоинства и он начинает нам нравиться… Чтобы снизить степень первичного отторжения и добиться максимального эффекта от использования, нужно обязательно заглянуть на кухню Docker’a и хорошенько там осмотреться.
Начнем с того, для чего же нам нужен Docker:
Предыстрория
Для изоляции процессов, запущенных на одном хосте, запуска приложений, предназначенных для разных платформ, можно использовать виртуальные машины. Виртуальные машины делят между собой физические ресурсы хоста:
На каждой ВМ устанавливаем нужную ОС и запускаем приложения. Недостатком такого подхода является то, что значительная часть ресурсов хоста расходуется не на полезную нагрузку(работа приложений), а на работу нескольких ОС.
Контейнеры
Альтернативным подходом к изоляции приложений являются контейнеры. Само понятие контейнеров не ново и давно известно в Linux. Идея состоит в том, чтобы в рамках одной ОС выделить изолированную область и запускать в ней приложение. В этом случае говорим о виртуализации на уровне ОС. В отличие от ВМ контейнеры изолированно используют свой кусочек ОС:
Т.о. приложение, запущенное в контейнере думает, что оно одно во всей ОС. Изоляция достигается за счет использования таких Linux-механизмов, как namespaces и control groups. Если говорить просто, то namespaces обеспечивают изоляцию в рамках ОС, а control groups устанавливают лимиты на потребление контейнером ресурсов хоста, чтобы сбалансировать распределение ресурсов между запущенными контейнерами.
Т.о. контейнеры сами по себе не являются чем-то новым, просто проект Docker, во-первых, скрыл сложные механизмы namespaces, control groups, а во-вторых, он окружен экосистемой, обеспечивающей удобное использование контейнеров на всех стадиях разработки ПО.
Образы
Образ в первом приближении можно рассматривать как набор файлов. В состав образа входит все необходимое для запуска и работы приложения на голой машине с докером: ОС, среда выполнения и приложение, готовое к развертыванию.
Но при таком рассмотрении возникает вопрос: если мы хотим использовать несколько образов на одном хосте, то будет нерационально как с точки зрения загрузки, так и с точки зрения хранения, чтобы каждый образ тащил все необходимое для своей работы, ведь большинство файлов будут повторяться, а различаться — только запускаемое приложение и, возможно, среда выполнения. Избежать дублирования файлов позволяет структура образа.
Образ состоит из слоев, каждый из которых представляет собой неизменяемую файловую систему, а по-простому набор файлов и директорий. Образ в целом представляет собой объединенную файловую систему (Union File System), которую можно рассматривать как результат слияния файловых систем слоев. Объединенная файловая система умеет обрабатывать конфликты, например, когда в разных слоях присутствуют файлы и директории с одинаковыми именами. Каждый следующий слой добавляет или удаляет какие то файлы из предыдущих слоев. В данном контексте «удаляет» можно рассматривать как «затеняет», т.е. файл в нижележащем слое остается, но его не будет видно в объединенной файловой системе.
Можно провести аналогию с Git: слои — это как отдельные коммиты, а образ в целом — результат выполнения операции squash. Как мы увидим дальше, на этом параллели с Git не заканчиваются. Существуют различные реализации объединенной файловой системы, одна из них — AUFS.
Слои являются read only и, если в слое MyApplication нужно изменить файл, находящийся в слое dotnet, то файл сначала копируется в нужный слой, а потом в нем изменяется, оставаясь в исходном слое в первозданном виде.
Неизменяемость слоев позволяет использовать их всеми образами на хосте. Допустим MyApplication — это веб-приложение, которое использует БД и взаимодействует также с NodeJS сервером.
Совместное использование проявляется также и при скачивании образа. Первым загружается манифест, который описывает какие слои входят в образ. Далее скачиваются только те слои из манифеста, которых еще нет локально. Т.о. если мы для MyApplication уже скачали ядро и ОС, то для PostgreSQL и Node.js эти слои уже загружаться не будут.
Docker-контейнеры
Docker-контейнер строится на основе образа. Суть преобразования образа в контейнер состоит в добавлении верхнего слоя, для которого разрешена запись. Результаты работы приложения (файлы) пишутся именно в этом слое.
Например, мы создали на основе образа с PostgreSQL сервером контейнер и запустили его. Когда мы создаем БД, то соответствующие файлы появляются в верхнем слое контейнера — слое для записи.
Можно провести и обратную операцию: из контейнера сделать образ. Верхний слой контейнера отличается от остальных только лишь разрешением на запись, в остальном это обычный слой — набор файлов и директорий. Делая верхний слой read only, мы преобразуем контейнер в образ.
Теперь я могу перенести образ на другую машину и запустить. При этом на сервере PostgreSQL можно будет увидеть БД, созданные на предыдущем этапе. Когда при работе контейнера будут внесены изменения, то файл БД будет скопирован из неизменяемого слоя с данными в слой для записи и там уже измененен.
Docker
Когда мы устанавливаем докер на локальную машину, то получаем клиент (CLI) и http-сервер, работающий как демон. Сервер предоставляет REST API, а консоль просто преобразует введенные команды в http-запросы.
Registry
Registry — это хранилище образов. Самым известным является DockerHub. Он напоминает GitHub, только содержит образы, а не исходный код. На DockerHub также есть репозитории, публичные и приватные, можно скачивать образы (pull), заливать изменения образов (push). Скачанные однажды образы и собранные на их основе контейнеры хранятся локально, пока не будут удалены вручную.
Существует возможность создания своего хранилища образов, тогда при необходимости Docker будет искать там образы, которых еще нет локально. Надо сказать, что при использовании Docker хранилище образов становится важнейшим звеном в CI/CD: разработчик делает коммит в репозиторий, запускаются тесты. Если тесты прошли успешно, то на основе коммита обновляется существующий или собирается новый образ с последующим деплоем. Причем в registry обновляются не целые образы, а только необходимые слои.
При этом важно не ограничивать восприятие образа как некой коробки в которой приложение просто доставляется до пункта назначения и потом запускается. Приложение может и собираться внутри образа (правильнее сказать внутри контейнера, но об этом чуть позже). На схеме выше сервер, занимающийся сборкой образов, может иметь только установленный Docker, а не различные среды, платформы и приложения, необходимые для сборки разных компонентов нашего приложения.
Dockerfile
Рассмотрим отдельно каждую инструкцию:
Рассмотрим еще один Dockerfile, который демонстрирует прекрасную возможность Docker, обеспечивающую легковесность образов. Подобный файл генерирует VisualStudio 2017 для проекта с поддержкой контейнеров и он позволяет собирать образ из исходного кода приложения.
Инструкции в файле разбиты на две секции:
Напоследок хочу отметить, что намеренно для простоты оперировал понятием образ, рассматривая работу с Dockerfile. На самом деле изменения, вносимые каждой инструкцией происходят конечно же не в образе (ведь в нем только неизменяемые слои), а в контейнере. Механизм такой: из базового образа создается контейнер (добавляется ему слой для записи), выполняется инструкция в данном слое (она может добавлять файлы в слой для записи: COPY или нет: ENTRYPOINT ), вызывается команда docker commit и получается образ. Процесс создания контейнера и коммита в образ повторяется для каждой инструкции в файле. В итоге в процессе формирования конечного образа создается столько промежуточных образов и контейнеров, сколько инструкций в файле. Все они автоматически удаляются после окончания сборки конечного образа.
Заключение
Конечно же Docker не панацея и его использование должно быть оправдано и мотивировано не только желанием использовать современную технологию, о которой многие говорят. При этом я уверен, что Docker, примененный грамотно и к месту, может принести много пользы на всех стадиях разработки ПО и облегчить жизнь всем участникам процесса.
Надеюсь смог раскрыть базовые моменты и заинтересовать к дальнейшему изучению вопроса. Конечно же для овладения Docker одной этой статьи недостаточно, но, надеюсь, она станет одним из элементов пазла для осознания общей картины происходящего в мире контейнеров под управлением Docker.
Изучаем Docker, часть 1: основы
Технологии контейнеризации приложений нашли широкое применение в сферах разработки ПО и анализа данных. Эти технологии помогают сделать приложения более безопасными, облегчают их развёртывание и улучшают возможности по их масштабированию. Рост и развитие технологий контейнеризации можно считать одним из важнейших трендов современности.
Docker — это платформа, которая предназначена для разработки, развёртывания и запуска приложений в контейнерах. Слово «Docker» в последнее время стало чем-то вроде синонима слова «контейнеризация». И если вы ещё не пользуетесь Docker, но при этом работаете или собираетесь работать в сферах разработки приложений или анализа данных, то Docker — это то, с чем вы непременно встретитесь в будущем.
Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.
Метафоры и Docker
Мы постоянно сталкиваемся с метафорами. Если заглянуть в словарь Ожегова, то окажется, что метафора — это «скрытое образное сравнение, уподобление одного предмета, явления другому». Метафоры помогают нам ухватывать суть новых для нас явлений. Например, виртуальные контейнеры можно сравнить с обычными пластиковыми контейнерами. Такое сравнение, через сопоставление уже известных нам свойств обычных контейнеров со свойствами виртуальных контейнеров, поможет сначала с ними познакомиться, а потом и понять их сущность.
Как вы понимаете, мы собираемся начать разговор о Docker с понятия «контейнер».
Контейнер
Как и обычный пластиковый контейнер, контейнер Docker обладает следующими характеристиками:
Живые организмы
Ещё один подход к размышлениям о контейнерах Docker заключается в сравнении их с экземплярами живых организмов. «Экземпляр» — это нечто, существующее в некоей форме. Это не просто код. Это код, который стал причиной существования чего-то большего, чем он сам, чего-то, образно говоря, живого. Как и другие живые организмы, экземпляры контейнеров появляются на свет, живут и умирают.
Монстр, вызванный к жизни
Контейнеры Docker — это вызванные к жизни образы Docker.
Программное обеспечение
Контейнеры Docker можно сравнивать не только с обычными контейнерами или с живыми организмами. Их можно сравнить и с программами. В конце концов, контейнеры — это программы. И, на фундаментальном уровне, контейнер представляет собой набор инструкций, который выполняется на некоем процессоре, обрабатывая какие-то данные.
Контейнер — это программа
Во время выполнения контейнера Docker внутри него обычно выполняется какая-то программа. Она выполняет в контейнере некие действия, то есть — делает что-то полезное.
Например, код, который работает в контейнере Docker, возможно, отправил на ваш компьютер тот текст, который вы сейчас читаете. Вполне возможно и то, что именно код, выполняющийся в контейнере Docker, принимает голосовые команды, которые вы даёте Amazon Alexa, и преобразует их в инструкции для ещё каких-нибудь программ, работающих в других контейнерах.
Благодаря использованию Docker можно, на одном и том же компьютере, одновременно запускать множество контейнеров. И, как и любые другие программы, контейнеры Docker можно запускать, останавливать, удалять. Можно исследовать их содержимое и создавать их.
Концепции Docker
▍Виртуальные машины
Предшественниками контейнеров Docker были виртуальные машины. Виртуальная машина, как и контейнер, изолирует от внешней среды приложение и его зависимости. Однако контейнеры Docker обладают преимуществами перед виртуальными машинами. Так, они потребляют меньше ресурсов, их очень легко переносить, они быстрее запускаются и приходят в работоспособное состояние. В этом материале можно найти подробное сравнение контейнеров и виртуальных машин.
▍Образ контейнера Docker
Выше мы уже говорили об «образах». Что это такое? Хороший вопрос. То, что в терминологии Docker называется «образом», или, по-английски, «image», это совсем не то же самое, что, например, фотография (это — одно из значений слова «image»).
Образы Docker — это не фотографии
Образы контейнеров Docker можно сравнить с чертежами, с формочками для печенья, или с пресс-формами для изготовления пластиковых изделий. Образы — это неизменные шаблоны, которые используются для создания одинаковых контейнеров.
Образы контейнеров Docker похожи на формочки для печенья
В образе контейнера Docker содержится образ базовой операционной системы, код приложения, библиотеки, от которого оно зависит. Всё это скомпоновано в виде единой сущности, на основе которой можно создать контейнер.
▍Файл Dockerfile
Файл Dockerfile содержит набор инструкций, следуя которым Docker будет собирать образ контейнера. Этот файл содержит описание базового образа, который будет представлять собой исходный слой образа. Среди популярных официальных базовых образов можно отметить python, ubuntu, alpine.
И, наконец, в образе может содержаться, поверх всех остальных, ещё один тонкий слой, данные, хранящиеся в котором, поддаются изменению. Это — небольшой по объёму слой, содержащий программу, которую планируется запускать в контейнере.
▍Контейнер Docker
▍Репозиторий контейнеров
Если вы хотите дать возможность другим людям создавать контейнеры на основе вашего образа, вы можете отправить этот образ в облачное хранилище. Самым крупным подобным хранилищем является репозиторий Docker Hub. Он используется при работе с Docker по умолчанию.
Мы уже довольно много всего обсудили. Пришло время собрать всё это вместе и сравнить работу с контейнерами Docker с приготовлением пиццы.
Готовим с Docker
Готовая пицца — это контейнер
Духовка — это платформа Docker
Духовка, в которой готовится пицца, напоминает платформу Docker. Духовку устанавливают на кухне, с её помощью можно готовить еду. Точно так же Docker устанавливают на компьютере для того, чтобы «готовить» контейнеры.
Духовку, если она электрическая, включают, поворачивая ручку регулятора температуры. Команда docker run image_name — это нечто вроде такого регулятора температуры, «поворот» которого приводит к тому, что система создаёт и запускает контейнер.
Готовая пицца — это и есть контейнер Docker.
А есть пиццу — значит пользоваться приложением, запущенным в контейнере.
Как и приготовление пиццы, подготовка к работе контейнеров Docker занимает некоторое время, но в финале и в том и в другом случаях получается что-то вкусное.
Итоги
Здесь мы, на концептуальном уровне, рассмотрели основы Docker. Надеемся, приведённые здесь сравнения помогли вам разобраться в том, что такое Docker, и ощутить ценность метафор в деле освоения новых технологий.
Уважаемые читатели! Эта публикация представляет собой перевод первой статьи из серии учебных материалов по Docker. По словам автора, всего планируется выпустить 5 таких материалов. Уже готовы вторая, третья и четвёртая части. Подскажите нам, стоит ли переводить следующие статьи этой серии?