Для чего нужен docker

_AMD_

Основатель trigon.im и gm-donate.ru. Интересуюсь айти, текстами, продажами. Меломан, интроверт, альтруист

_AMD_

Docker — платформа для запуска приложений в изолированных контейнерах.

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

Только пакетов не обязательно 2 и в них не обязательно что-то опасное, да и комната (сервер) тоже может быть не одна. Реальные примеры с применением будут описаны ниже.

Нет ничего сложного в использовании докера. Для большинства задач нужны совсем поверхностные знания, которые можно получить, почитав всего пару статей или, еще лучше, раздел Get started официальной документации, затем подкрепить все эти знания практикой. Например, запустить MySQL сервер + Adminer в один клик на этой странице. Там есть кнопочка. Но это только для начала.

Photo by Danielle MacInnes / Unsplash

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

С Docker придется понять, что теперь не панель управления, а вы должны будете придумать, где разместить ваши данные из контейнера, будь то сайт или что-то еще

Тоесть, теперь не будет никаких кнопочек а-ля "Файловый менеджер", которые сразу откроют вам папочку с данными ваших контейнеров. Вы должны сами придумать, где будете работать. У меня это

И маленькое замечание насчет безопасности – вам придется выполнять все команды или от рута или от sudo или добавить вашего пользователя в группу docker (лучше последнее)

А еще насчет портов. Есть Docker port, а есть Published port. Docker port это порт, который контейнер будет считать, что использует, а Published это порт, через который будет доступен Docker port на родительской машине. Простыми словами, это проброс портов

Контейнер

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

Dockerfile

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

docker-compose.yml

В докере один Dockerfile это один сервис. Если вам нужен один сервис, например, торрентокачалка или генерация LetsEncrypt сертификата, вы можете запустить его через docker run . Но если у вас приложение, состоящее из нескольких сервисов (PHP + Nginx + MySQL), то запускать их все по очереди длинными командами с кучей параметров было бы, как минимум, неудобно. Этот файл объединяет все в одном месте и управляется через команду docker-compose

Я выделил популярные команды. Они частично будут описаны ниже

Репозиторий

Есть репозитории, а есть Automated builds. По-простому, репозитории это готовые сборки систем. Например, чистый Ubuntu. Некоторые репозитории это сразу система с установленным приложением, например, CMS Ghost. На Docker HUB репозиторий это куча файлов, а Automated build это всего лишь Dockerfile

Automated build

На первый взгляд ничем не отличаются от репозиториев. Мне даже трудно объяснить разницу. По-обезьяньи я понимаю это так: "у репозиториев я не могу посмотреть Dockerfile, а у autobuilds могу". Automated builds это те же репозитории, только с них вы можете без проблем забрать Dockerfile и поправить его под свои нужды.

Также со временем Automated build может перестать работать, если какая-то инструкция в нем устареет (например, Dockerfile писался под Ubuntu 14.04 ( FROM ubuntu:latest ), а со временем ubuntu:latest обновилась до 18.04 и вжух, проблемы). Репозитории в этом плане монолитные. Какими залиты, такими и будут даже через 100 лет.

Еще есть всякие инструкции для Dockerfile, вроде ADD и COPY , которые добавляют файлы в контейнер во время его создания и которые не работают для репов

Пример Automated Build: cpuminer-multi

Swarm

Вы можете даже ни разу не столкнуться с этим на практике, но на будущее – это что-то вроде кластера. Короче, связка серверов с установленным Docker.

В нем есть главная нода и подчиненные. Главная это та, на которой выполнен docker swarm init , а подчиненные те, которые присоединились через docker swarm join и готовы принимать указания от главной ( docker stack deploy )

• Можно без проблем изучать новые фишки, до которых раньше руки не доходили из-за сложности или не хотелось засорять систему. Например хотели простой блог на JavaScript, торрент качалку или даже целый комбайн из приложений с кучей мусора и зависимостями без заморочки – докер.
• Если вы раньше использовали VirtualBox для запуска приложений, то Docker его не только заменит, но и сделает все быстрее и проще
• Он поможет запустить приложение любой сложности на любой системе всего в пару нажатий клавиш при помощи всего лишь одного Dockerfile файла. Или docker-compose.yml, если нужно запустить пачку сервисов.
• Благодаря докеру вы можете собирать данные кучи приложений в одном, нужном вам месте, благодаря чему их проще будет переносить.
• Или, например, у вас есть веб приложение с кучей заточенных под вас настроек, всяких баз данных, веб серверов, фреймворков и тд и вам нужно расширяться, копировать все это на другие сервера, прописывать все заново. С докером вы выполняете docker swarm init на главной ноде и docker swarm join на всех подчиненных, затем с главной передаете всем остальным задачу деплоя ваших приложений/сервисов при помощи пары команд.
• Еще пример. Вы когда-нибудь использовали WAMP? Это связка Apache + PHP + PHPMyAdmin + MySQL и еще пары ништяков, которые помогают PHP разработчкам писать и тестить сайты, сидя на винде без всяких виртуалок. Так вот WAMP полезен только на винде и только для PHP. А Docker полезен хоть на Windows, хоть на Linux, хоть на Mac OS и для чего угодно, а не только PHP разработчиков

Кстати, этот блог запущен внутри Docker контейнера, а рядом с ним крутится еще контейнер с Nginx, контейнер с MariaDB, при необходимости, запускаю еще контейнер с Adminer (Аналог phpmyadmin) и LetsEncrypt генерилкой. Благодаря этому я могу купить еще хоть 100 VDS с Docker, одной командой подключить их к одному swarm’у (кластеру) и запустить сразу на всех мой блог так же в одну команду. Тогда даже если 99 нод "умрут", блог все равно будет доступен на последней.

Делаем сейчас один небольшой проект, где будут 4 дублирующих друг друга сервера.
Внутри все просто – СУБД, сервер MQ, nginx, десяток сервисов – будет без Докера делать.

Но на больших масштабах, не рисковал бы.

Максим Жаров: Нет. Virtual Box – это полная виртаулизация. Машина с Виртуалбоком загрузится в лучшем случае пару минут (а как правило значительно дольше). Будет откусывать процентов 20% процессора и приличные накладные расходы на память.

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

Поэтому на вашем компьютере нельзя запустить 10 штук VirtualBox одновременно (или можно но будет дико тормозить), но при этом можно запустить несколько сотен Docker-контейнеров.

С другой стороны – ограничения на Docker – внутри может находиться только специально подготовленная операционная система Linux или FreeBSD.

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема – вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача – пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет – им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 – иди на эту машину, нужен php5 – вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так – "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок. И тут появляется Docker! 🙂

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

viiy:
У нас то, что торчит наружу – nginx – не в контейнере.

А самописное – вестимо, в контейнере. Но вы его и не обновите из дистрибутивских реп. Оно же самописное.

viiy:
Можно обновлять (даже автоматически) контейнеры Докера (или создавать заново сразу со свежим ПО).

Если повезет – даже будет работать.

Но это нарушает концепцию CI с изолированным окружением – как только вы что-то меняете – все может сломаться. Но Докер здесь не при чем будет.

viiy:
Может у вас процесс неправильно поставлен?
У нас когда разработчик коммитит в Git запускаются тесты:

1. В индивидуально под тест подготавливаемом окружении (через Докер, естественно).
2. Если тест прошел – то эти же настроки идут в продакшн.
3. Но разработчик коммитит только свой небольшой кусок кода, и этот небольшой кусок кода и запускается в Докере отдельном.
4. Никто не разрешит разработчику свои настройки, как вы писали выше по библиотеки для PHP, затягивать в проект (у нас не PHP, но концепция, думаю, понятна).
5. Окружение, для, допустим, PHP (у нас его нет, в качестве примера), настраивает админ, максимум что может разработчик в конфигурационном файле прописать дополнительный требуемый модуль для PHP.
6. Таким образом, nginx/PHP и пр. вообще проходит мимо разработчика и он не может влиять. Не прошел тест – не сдал работу, денег не получил.

Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере

Идеология Docker предполагает 1 сервис = 1 контейнер.
Запуск множества контейнеров давно решен даже с перебором – т.н. "средства оркестрации". Вплоть до того, что они сами поместят Docker-контейнер на свободную машину, сами запустят.

Ковырять с сторону:

Nomad, Terraform, Mesos, Maraphon, Aurora, Kubernetes, Docker Swarm, HTCondor, AWS ECS, Hadoop YARN, Yandex Cocaine

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

Или админов, которые леняться установить нужные версии.

Для решения этой проблемы и придуман Docker.

Одна физическая машина и куча виртуалок? Думаю, что сильно тормозить будет

Docker – это не виртуалка.
Docker – это контейнеризация. Очень малые накладные затраты, сопоставимые с обычным запуском программы, вне контейнера.

А виртуализация с Docker используется только на машинах разработчиков, которые не хотят работать под Linux, разрабатывая сервера под Linux, а работают под Windows, MacOSX.

В production если используется Docker, то в качетве базовой ОС используется Linux (изредка FreeBSD, там Docker пока экспериментален).

Так что ничего не тормозит, ибо Docker – это не виртуализация под Linux/FreeBSD, а вполне нативное исполнение

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows – через виртуальную машину.

Докер – это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости – ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. – скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать – ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер – это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере – возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows – в принципе в контейнере запустить невозможно.

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

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.

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

Более того – изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы.

Потом плюнули на попытки упорядочить окружение в ОС – и сейчас концепция такова – устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами – то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
• Тот же Докер-контейнер нужно использовать и на сервере.

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

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов – то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата – сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

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

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

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

Docker
Тип	Виртуализация на уровне операционной системы
Автор
Разработчик	Docker, Inc.[d]
Написана на	Go[1]
Операционная система	Linux[2] , Microsoft Windows[3] и macOS[4]
Первый выпуск	13 марта2013[5]
Аппаратная платформа	x86-64
Последняя версия	19.03.5 ( 14 ноября2019 ) [6]
Состояние	Активная разработка
Лицензия	Apache License 2.0[7][8] и проприетарная лицензия[d]
Сайт	docker.com​ (англ.)
Медиафайлы на Викискладе

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением ​Open Container Initiative начался переход от монолитной к модульной архитектуре.

Разрабатывается и поддерживается одноимённой компанией-стартапом, распространяется в двух редакциях — общественной ( Community Edition ) по лицензии Apache 2.0 и для организаций ( Enterprise Edition ) по проприетарной лицензии [9] . Написан на языке Go.

Содержание

История [ править | править код ]

Проект начат как внутренняя собственническая разработка компании dotCloud, основанной Соломоном Хайксом (Solomon Hykes) в 2008 году с целью построения публичной PaaS-платформы с поддержкой различных языков программирования. Наряду с Хайксом в первоначальной разработке значительное участие приняли инженеры dotCloud Андреа Лудзарди (Andrea Luzzardi) и Франсуа-Ксавье Бурле (François-Xavier Bourlet).

В марте 2013 года код Docker был опубликован под лицензией Apache 2.0 [10] . В июне 2013 года генеральным директором в dotCloud приглашён Бен Голуб (англ. Ben Golub ), ранее руководивший фирмой Gluster [en] (разрабатывавшей технологию распределённого хранения GlusterFS и поглощённой за $136 млн Red Hat в 2011 году) [11] . В октябре 2013 года, подчёркивая смещение фокуса к новой ключевой технологии, dotCloud переименована в Docker (при этом PaaS-платформа сохранена под прежним названием — dotCloud).

В октябре 2013 года выпущен релиз Havana тиражируемой IaaS-платформы OpenStack, в котором реализована поддержка Docker (как драйвер для OpenStack Nova). С ноября 2013 года частичная поддержка Docker включена в дистрибутив Red Hat Enterprise Linux версии 6.5 [12] и полная — в 20-ю версию дистрибутива Fedora, ранее было достигнуто соглашение с Red Hat о включении с 2014 года Docker в тиражируемую PaaS-платформу OpenShift [en] [13] . В декабре 2013 года объявлено о поддержке развёртывания Docker-контейнеров в среде Google Compute Engine [en] [14] .

С 2014 года ведутся работы по включению поддержки Docker в среду управления фреймворка распределённых приложений Hadoop; по результатам тестирования вариантов платформы виртуализации для Hadoop, проведённом в мае 2014 года, Docker показал на основных операциях (по массовому созданию, перезапуску и уничтожению виртуальных узлов) существенно более высокую производительность, нежели KVM, в частности, на тесте массового создания виртуальных вычислительных узлов прирост потребления процессорных ресурсов в Docker зафиксирован в 26 раз ниже, чем в KVM, а прирост потребления ресурсов оперативной памяти — втрое ниже [15] .

С 2017 года вдобавок к свободно распространяемой под лицензией Apache 2.0 редакции продукта выпускается редакция для организаций, продаваемая по ценам от $750 до $2 тыс. в год на узел в зависимости от доступных функций [9] .

Применение [ править | править код ]

Программное обеспечение функционирует в среде Linux с ядром, поддерживающим cgroups и изоляцию пространств имён (namespaces); существуют сборки только для платформ x86-64 и ARM [17] . Начиная с версии 1.6 возможно использование в ОС Windows [18] .

Для экономии дискового пространства проект использует файловую систему Aufs с поддержкой технологии каскадно-объединённого монтирования: контейнеры используют образ базовой операционной системы, а изменения записываются в отдельную область. Также поддерживается размещение контейнеров в файловой системе Btrfs с включённым режимом копирования при записи.

В состав программных средств входит демон — сервер контейнеров (запускается командой docker -d), клиентские средства, позволяющие из интерфейса командной строки управлять образами и контейнерами, а также API, позволяющий в стиле REST управлять контейнерами программно.

Демон обеспечивает полную изоляцию запускаемых на узле контейнеров на уровне файловой системы (у каждого контейнера собственная корневая файловая система), на уровне процессов (процессы имеют доступ только к собственной файловой системе контейнера, а ресурсы разделены средствами libcontainer), на уровне сети (каждый контейнер имеет доступ только к привязанному к нему сетевому пространству имён и соответствующим виртуальным сетевым интерфейсам).

Набор клиентских средств позволяет запускать процессы в новых контейнерах (docker run), останавливать и запускать контейнеры (docker stop и docker start), приостанавливать и возобновлять процессы в контейнерах (docker pause и docker unpause). Серия команд позволяет осуществлять мониторинг запущенных процессов (docker ps по аналогии с ps в Unix-системах, docker top по аналогии с top и другие). Новые образы возможно создавать из специального сценарного файла (docker build, файл сценария носит название Dockerfile), возможно записать все изменения, сделанные в контейнере, в новый образ (docker commit). Все команды могут работать как с docker-демоном локальной системы, так и с любым сервером Docker, доступным по сети. Кроме того, в интерфейсе командной строки встроены возможности по взаимодействию с публичным репозиторием Docker Hub, в котором размещены предварительно собранные образы контейнеров, например, команда docker search позволяет осуществить поиск образов среди размещённых в нём [19] , образы можно скачивать в локальную систему (docker pull), возможно также отправить локально собранные образы в Docker Hub (docker push).

Также Docker имеет пакетный менеджер Docker Compose, позволяющий описывать и запускать многоконтейнерные приложения. Конфигурационные файлы Compose описываются на языке YAML. [20]