Для чего используется docker
Docker. Зачем и как
Есть множество прекрасных публикаций для тех, кто уже пользуется docker-ом. Есть хорошие статьи для тех, кто хочет этому научиться. Я пишу для тех, кто не только не знает, что такое docker, но и не уверен стоит ли ему это знать.
Я сознательно опускаю некоторые технические подробности, а кое где допускаю упрощения. Если вы увидите, что docker – то, что вам нужно, вы легко найдете более полную и точную информацию в других статьях.
Начну я с описания нескольких типичных проблем.
Проблемы
Первая проблема — как передать продукт клиенту.
Предположим у вас есть серверный проект, который вы закончили и теперь его необходимо передать пользователю. Вы готовите много разных файликов, скриптов и пишите инструкцию по установке. А потом тратите уйму времени на решения проблем клиента вроде: «у меня ничего не работает», «ваш скрипт упал на середине — что теперь делать», «я перепутал порядок шагов в инструкции и теперь не могу идти дальше» и т. п.
Всё усугубляется если продукт тиражируемый и вместо одного клиента у вас сотни или тысячи покупателей. И становится еще сложнее, если вспомнить о необходимости установки новых версий продукта.
Вторая проблема — тиражируемость. Пусть вам нужно поднять 5 (или 50) почти одинаковых серверов. Делать это вручную долго, дорого и подвержено ошибкам.
Наконец, третья проблема — переиспользуемость. Предположим у вас есть отдел, который делает браузерные игры. Предположим, что их у вас уже несколько. И все они используют один и тот же технологический стэк (например — java-tomcat-nginx-postgre). Но при этом, чтобы поставить новую игру вы вынуждены заново подготавливать на новом сервере почти одинаковую конфигурацию. Вы не можете просто так взять и сказать — «хочу сервер, как в игре странники но только с другим веб архивом»
Обычные решения
Как обычно решаются эти проблемы.
Установочный скрипт
Первый подход я уже упомянул — вы можете написать скрипт, который установит всё, что вам нужно и запускать его на всех нужных серверах. ( Скрипт может быть как простым sh файлом, так и чем-то сложным, созданным с использованием специальных инструментов).
Недостатки этого подхода — хрупкость и неустойчивость к ошибкам. Как бы хорошо не был написан скрипт, рано или поздно на какой-то машине он упадёт. И после этого падения машина фактически окажется «испорченной» — просто так «откатить» те действия, которые скрипт успел выполнить, у вашего клиента не получится.
Облачные сервисы
Второй подход — использование облачных сервисов. Вы вручную устанавливаете на виртуальный сервер всё, что вам нужно. Затем делаете его image. И далее клонируете его столько раз, сколько вам надо.
Недостатка здесь два. Во-первых, vendor-lock-in. Вы не можете запускать свое решение вне выбранного облака, что не всегда удобно и может привести к потерям несогласных с этим выбором клиентов. Во-вторых, облака медленны. Виртуальные (и даже «bare-metal») сервера предоставляемые облаками на сегодняшний день сильно уступают по производительности dedicated серверам.
Виртуальные машины
Третий подход — использование виртуальных машин. Здесь тоже есть недостатки:
Размер — не всегда удобно качать образ виртуальной машины, который может быть довольно большим. При этом, любое изменение внутри образа виртуальной машины требует скачать весь образ заново.
Сложное управление совместным использованием серверных ресурсов — не все виртуальные машины вообще поддерживают совместное использование памяти или CPU. Те что поддерживают, требуют тонкой настройки.
Подход докера — контейнеризация
И вот тут появляется docker, в котором
Как работает docker
Создание образа
Сначала создается docker image (или образ). Он создается при помощи скрипта, который вы для этого пишете.
Образы наследуются и, обычно, для создания своего первого образа мы берём готовый образ и наследуемся от него.
Чаще всего мы берем образ в котором содержится та или иная версия linux. Скрипт тогда начинается как-то так:
Кроме этого, мы можем копировать в наш образ любые локальные файлы при помощи директивы COPY.
Докер поддерживает гораздо больше различных директив. Например, директива USER roman говорит докеру что все следующие директивы нужно выполнять из под пользователя roman. А директива ENTRYPOINT [“/opt/tomcat/catalina.sh”] задает исполняемый файл, который будет запускаться при старте.
Я не буду перечислять все остальные директивы — в этом нет смысла. Здесь главное — принцип: вы создаёте вот такой скрипт, называете его Dockerfile и запускаете команду docker build, docker выполняет скрипт и создает image.
Если в процессе возникают какие-то ошибки, докер о них сообщает и вы их исправляете. То есть исправление скрипта происходит на этапе создания image. На этапе установки скрипт уже не используется.
Создание контейнера
Когда у вас уже есть docker image вы можете создать из него контейнер на любом физическом сервере, где установлен докер. Если image – это тиражируемый образ некоторой «машины», то container это уже сама «машина», которую можно запускать и останавливать.
Важный момент — при создании контейнера из image, его можно параметризовать. Вы можете передавать докеру переменные окружения, которые он использует при создании контейнера из image. Так вы сможете создавать немного разные машины из одного образа. Например, передать образу web-сервера его доменное имя.
Хорошей практикой в докере считается «упаковка» в один контейнер ровно одного постоянно работающего серверного процесса. Как я уже упоминал, этот процесс работает на уровне физического сервера и честно регулируется установленной там операционной системой. Поэтому, в отличие от виртуальных машин, контейнеры докера не требуют специального управления памятью и процессорами. Использование ресурсов становится простым и эффективным.
Union filesystem
Ок — память и процессор используется эффективно. А как насчёт файловой системы? Ведь если у каждого контейнера докера своя собственная копия операционной системы, то мы получим ту же проблему, что и с виртуальными машинами — тяжеловесные образы, которые содержат одно и тоже.
На самом деле в докере это не так. Если вы используете 100500 контейнеров, основанных на одном и том же образе операционной системы, то файлы этой системы будут скачаны докером ровно один раз. Это достигается за счёт использования докером union file system.
Union file system состоит из слоёв (layers). Слои как бы наложены друг на друга. Некоторые слои защищены от записи. Например, все наши контейнеры используют общие защищенные от записи слои, в которых находятся неизменяемые файлы операционной системы.
Для изменяемых файлов каждый из контейнеров будет иметь собственный слой. Естественно, докер использует такой подход не только для операционной системы, но и для любых общих частей контейнеров, которые были созданы на основе общих «предков» их образов.
Container registry
Получается, что docker image состоит из слоёв. И хорошо было бы уметь скачивать на наш сервер только те слои, которых на нём пока нет. Иначе для установки 100 контейнеров, основанных на Ubuntu мы скачаем Ubuntu внутри их образов 100 раз. Зачем?
Хорошая новость в том, что докер решает эту проблему. Докер предоставляет специальный сервис, называемый docker registry. Docker registry предназначен для хранения и дистрибуции готовых образов. Собрав новый образ (или новую версию образа) вы можете закачать его в docker registry. Соответственно, потом его можно скачать оттуда на любой сервер. Главная фишка здесь в том, что физически качаться будут только те слои, которые нужны.
Например, если вы создали новую версию образа, в котором поменяли несколько файлов, то в registry будут отправлены только слои, содержащие эти файлы.
Аналогично, если сервер качает из registry какой-то образ, скачаны будут только слои, отсутствующие на сервере.
Docker registry существует и как общедоступный сервис и как open source проект, доступный для скачивания и установки на собственной инфрастуктуре.
Использование контейнеров
Созданные контейнеры можно запускать, останавливать, проверять их статус и т д. При создании контейнера можно дополнительно передать докеру некоторые параметры. Например, попросить докер автоматически рестартовать контейнер, если тот упадёт.
Взаимодействие между контейнерами
Если контейнеров на сервере несколько, управлять ими вручную становится проблематично. Для этого есть технология docker compose. Она существует поверх докера и просто позволяет управлять контейнерами на основе единого конфигурационного файла, в котором описаны контейнеры, их параметры и их взаимосвязи (например контейнер A имеет право соединяться с портом 5432 контейнера B)
Выводы
Таким образом докер очень хорошо подходит для решения перечисленных выше задач:
Что такое Docker?
Docker — это проект с открытым исходным кодом для автоматизации развертывания приложений в виде переносимых автономных контейнеров, выполняемых в облаке или локальной среде. Одновременно с этим, Docker — это компания, которая разрабатывает и продвигает эту технологию в сотрудничестве с поставщиками облачных служб, а также решений Linux и Windows, включая корпорацию Майкрософт.
Рис. 2-2. Docker развертывает контейнеры на всех уровнях гибридного облака.
Контейнеры Docker могут работать в любой среде, например в локальном центре обработки данных, в службе стороннего поставщика или в облаке Azure. Контейнеры образов Docker работают в исходном формате в Linux и Windows. Но образы Windows будут выполняться только на узлах Windows, тогда как образы Linux — на узлах Linux или Windows (на данный момент с помощью виртуальной машины Linux Hyper-V). Термин «узлы» здесь означает физические серверы и виртуальные машины.
Разработчики могут использовать среды разработки на базе Windows, Linux или macOS. На компьютере разработчика выполняется узел Docker, где развернуты образы Docker с создаваемым приложением и всеми его зависимостями. Разработчики, работающие в Linux или macOS, могут использовать узел Docker на базе Linux и создавать образы только для контейнеров Linux. (В macOS разработчики могут изменять код приложения и запускать Docker CLI в macOS, но на момент написания этой статьи они не могут запускать контейнеры непосредственно в macOS.) В Windows разработчики могут создавать образы для контейнеров Linux или Windows.
Docker предоставляет Docker Desktop для Windows и macOS, позволяя размещать контейнеры в среде разработки и использовать дополнительные средства разработки. Оба продукта устанавливают необходимую виртуальную машину (узел Docker) для размещения контейнеров.
Для выполнения контейнеров Windows есть среды выполнения двух типов:
Контейнеры Windows Server изолируют приложение с помощью технологии изоляции процесса и пространства имен. Контейнер Windows Server использует ядро совместно с узлом контейнеров и всеми остальными контейнерами на узле.
Контейнеры Hyper-V увеличивают изоляцию, обеспеченную контейнерами Windows Server, запуская каждый контейнер в оптимизированной виртуальной машине. В этой конфигурации ядро узла контейнера не используется совместно с контейнерами Hyper-V, что улучшает изоляцию.
Образы для этих контейнеров создаются и работают одинаково. Различие заключается лишь в том, что для создания контейнера из образа с контейнером Hyper-V нужен дополнительный параметр. Дополнительные сведения см. в разделе Контейнеры Hyper-V.
Сравнение контейнеров Docker с виртуальными машинами
На рисунке 2-3 показано сравнение между виртуальными машинами и контейнерами Docker.
| Виртуальные машины | Контейнеры Docker |
|---|---|
 |  |
| Виртуальные машины содержат приложение, необходимые библиотеки или двоичные файлы и всю операционную систему. Полная виртуализация требует больше ресурсов, чем создание контейнеров. | Контейнеры включают в себя приложение и все его зависимости. Но они используют ядро ОС совместно с другими контейнерами, которые выполняются в изолированных процессах в пользовательском пространстве операционной системы узла. (Это не относится к контейнерам Hyper-V, где каждый контейнер запускается на отдельной виртуальной машине.) |
Рис. 2-3. Сравнение традиционных виртуальных машин с контейнерами Docker
Для виртуальных машин на сервере узла создается три базовых уровня: самый нижний инфраструктурный слой; затем операционная система узла и низкоуровневая оболочка; и поверх этого каждая виртуальная машина использует собственную ОС и все необходимые библиотеки. Для Docker сервер узла предоставляет только инфраструктуру и операционную систему, а также ядро контейнеров, которое изолирует контейнер с использованием базовых служб операционной системы.
Так как контейнеры требуют гораздо меньше ресурсов (например, им не нужна полная ОС), их проще развертывать и они быстрее запускаются. Это позволяет повысить плотность развертываний, то есть запустить на одной единице оборудования больше служб и сократить затраты на них.
Запуск на одном ядре приводит к тому, что уровень изоляции будет ниже, чем на виртуальных машинах.
Основная цель образа — привести среду (зависимости) к единообразию в различных развертываниях. Это означает, что вы можете отладить образ на одном компьютере, а затем развернуть его на другом компьютере и получить ту же среду.
Образ контейнера — это способ упаковки приложения или службы для надежного и воспроизводимого развертывания. Можно сказать, что Docker является не только технологией, но еще философией и процессом.
При работе с Docker разработчики никогда не жалуются, что приложение работает только на локальном компьютере, но не в рабочей среде. Им достаточно сказать «Выполняется в Docker», так как упакованное приложение Docker будет выполняться в любой поддерживаемой среде Docker. Оно будет работать одинаково во всех сценариях развертывания (разработка, контроль качества, промежуточное размещение и рабочая среда).
Простая аналогия
Возможно, небольшая аналогия поможет вам быстрее освоить ключевую концепцию Docker.
Вернемся ненадолго назад во времени, в 1950-е годы. Тогда еще не было текстовых редакторов, и повсеместно использовались фотокопировальные устройства (то есть то, что тогда так называлось).
Представьте, что вам понадобилось быстро подготовить наборы писем, чтобы отправить их с обычной бумажной почтой в настоящих конвертах с марками и доставить по домашнему адресу клиента (не забывайте, еще не существует электронной почты).
В какой-то момент вы понимаете, что каждое письмо составлено из широкого набора абзацев, которые выбираются и упорядочиваются по мере необходимости с учетом назначения письма. Вы создаете систему, которая быстро создает нужные письма, и обоснованно надеетесь на существенную прибавку.
Вы создали простую систему со следующим алгоритмом:
У вас есть пачка прозрачных листов, каждый из которых содержит один абзац.
Чтобы подготовить комплект писем, вы отбираете листы с нужными абзацами, собираете их в стопку и выравниваете так, чтобы все правильно читалось.
Теперь вы помещаете готовый набор в фотокопировальное устройство и нажмите кнопку запуска, чтобы изготовить нужное количество копий.
Это и есть основная концепция Docker в упрощенной форме.
В Docker каждый слой представляет некоторый набор изменений, которые применяются к файловой системе после выполнения команды, такой как установка программы.
Если вы «посмотрите» на файловую систему после копирования очередного слоя, вы увидите все файлы в том состоянии, которое они приняли после установки программы.
Такой образ можно рассматривать как дополнительный жесткий диск, доступный только для чтения, который готов к установке на «компьютер» с уже установленной операционной системой.
Соответственно, роль «компьютера» здесь выполняет контейнер, в который устанавливается жесткий диск этого образа. Контейнер, как и обычный компьютер, можно включать и отключать.
Знакомство с Docker от А до Я: что, зачем и почему
Docker – достаточно мощный инструмент, который пригодится каждому разработчику. Особенно это касается тех, кто часто «общается» с Линуксом. Специальное программное обеспечение, активно задействованное при работе с разнообразными приложениями.
Несмотря на полезность Докеров, не всем понятно, что представляет собой соответствующий объект. В данной статье будет раскрыта упомянутая тема. А еще каждый сможет разобраться в том, каким образом можно в считанные месяцы «с нуля» начать разбиваться в контейнерах Docker.
Даем определение
Docker – это специальное программное обеспечение для той или иной операционной системы. Некий набор инструментов для разработчика, задействованный для автоматизации развертки и управления приложения. Основное предназначение Докера – контейнеризация.
Его можно использовать при:
За все операции отвечает специальная среда. Она имеет поддержку контейнеризации. За счет контейнеров та или иная утилита начинает стабильно работать, а также с легкостью переносится из одной операционной системы в другую.
Немного о создании
Рассматриваемый «контейнер» изначально увидел свет в 2008 году, но его первые наработки появились в 90-х годах. Тогда контент не пользовался огромным спросом. Тестирование и разработка велась в «замкнутом пространстве». Доступ к подобным «контейнерам» имели только избранные программеры.
К 2013 году Docker получит статус «общего» контента. У его появился открытый исходный код. Работал контейнер под лицензией Apache версии 2.0. В основном проект предназначался для Linux. Лишь через 4 года он стал пользоваться спросом на других ОС.
Принцип функционирования
Контейнеры Docker нужно правильно и грамотно использовать. Соответствующий софт позволяет безопасно работать, «упаковывать» приложения и даже переносить их из системы в систему.
Основным предназначением Докера служит контейнеризация ПО. В его основе лежит своеобразная визуализация, позволяющая производить упаковку приложений по специальным изолированным средам. Каждая имеет название контейнера или «блока».
Докеры используют в зависимости от нужд разработчика. Можно встретить их в:
Для того, чтобы приложение нормально работало, у каждого контейнера «в арсенале» будут собственные настройки и элементы. Это дает определенные преимущества. А именно – удается запустить несколько контейнеров на одном хосте.
Плюсы и минусы инструмента
Каждый разработчик перед тем, как работать с тем или иным инструментом, должен рассмотреть его сильные и слабые стороны. Docker необходимо тщательно изучить, иначе добиться успеха не получится. Несмотря на свою нынешнюю популярность, соответствующий контент имеет как плюсы, так и минусы.
Преимущества
Начать лучше с преимуществ. Среди них выделяют:
Не нужно забывать о том, что рассматриваемый инструментарий поддерживает оптимизацию файловой системы. Образ состоит из слоев, которые отвечают за оптимальное и эффективное использование ОС и ее файловых компонентов.
Недостатки
Управлять образами и контейнерами при определенной сноровке достаточно легко. Хотя кажется, что соответствующий софт не имеет недостатков, это вовсе не так.
Разработчики указывают на то, что Докер требует грамотного обращения. А еще – наличия элементарных навыков программирования, ведь внутри контейнера находится именно код. И его предстоит корректировать под собственные нужды.
В остальном минусов у подобного инструментария нет. Это – отличное решение, которое, в отличие от виртуальных машин, не требует особых ресурсов от используемого устройства.
Терминология – что нужно знать
Изучение любой утилиты осуществляется с учетом рассмотрения его составляющих. Docker контейнеры работают по определенным принципам, задействовав в процессе самые разные элементы.
Особое значение новичкам необходимо уделить внимание следующим терминам и понятиям:
Существуют различные Docker-registry. Вот несколько примеров:
Дополнительно рекомендуется рассмотреть иные важные аспекты, связанные с контейнированием. Этот процесс осуществляется в специальной среде. И она имеет собственное название.
Docker Engine
Существуют самые разные компоненты Докера. Основополагающую роль здесь играет ядро механизма контейнера. Он имеет название Docker Engine.
Это – движок, отвечающий за функционирование и обеспечение связей с Докер-объектами. Сюда принято относить образы, реестры и сами контейнеры.
Engine включает в себя более двух элементов:
Если пользователь намерен освоить принципы создания образа Докера, а также хочет стать настоящим профессионалом в выбранном направлении, с движком придется работать тесно и упорно.
О работе «утилиты»
Для того, чтобы пользователь мог свободно использовать контейнер в своей работе, ему предстоит изучить основы написания программных кодов, а также информатики и даже математики. А еще – по каким принципам и схемам среди доступных можно использовать Докер контейнеры.
Работа рассматриваемого инструмента основывается на принципе архитектуры «клиент-сервер». Она предусматривает взаимодействие клиентов с хостами. Первый время от времени отправляет запросы на получение данных, второй – дает на них ответы, а также производит дальнейшую отправку.
Схема
На картинке ниже представлена наглядная схема работы рассматриваемого механизма. Она основывается на отдельных элементарных шагах.
Стоит запомнить следующий принцип работы контейнеров Docker:
В качестве наглядного примера можно рассмотреть запуск Image при помощи команды Docker Run или процесс удаления контейнера. Для второй операции используют «запрос» Kill.
Как работает образ
Процессы контейнирования требуют хорошей проработки. Не достаточно просто запускать в контейнерах команды, чтобы «все нормально работало». Поэтому приходится учитывать, каким макаром работает каждый элемент механизма.
Образы, которые сделаете в процессе задействования Docker – это готовые шаблоны с пометкой «только для чтения». В них имеются инструкции для формирования хранилищ. Включают в себя слои, которые при помощи Докера собираются в один образ через вспомогательные файловые системы. Такой вариант избавляет от нерационального распределения и использования имеющейся дисковой памяти.
Параметры образа содержатся в DockerFile. Чтобы в режиме работы можно было использовать несколько Images, необходимо привлекать к операциям реестры и Docker-registry. Они предоставляют «список» готовых образов с внешних репозиториев, а также несут ответ за дальнейшее хранение в хостовых реестрах.
Внимание: для модификации Images достаточно корректировать исключительно необходимые файлы, а не весь объект. Такой результат получается за счет наличия слоев у образов. На сервер будут загружаться только те «документы», в которые разработчик вносил необходимые ему изменения.
О работе контейнеров
Стоит обратить внимание на то, что в рабочей сфере Докер рассматривается как объект, функционирующий комплексно. Каждый его элемент достоит отдельной «главы» при изучении. Docker Container базируется на основе Images. Запуск осуществляется напрямую из ядра Ubuntu (или другого Линукса). Такой прием – средство оптимизации использования аппаратных ресурсов.
Процесс функционирования изолированных областей Docker выглядит следующим макаром:
При работе с движками задействуются контрольные группы – crgoups. Приложение получает ограничения по ресурсным наборам. Контрольные группы организовывают обмен аппаратными возможностями с контейнерами, на которые дополнительно устанавливаются разнообразные ограничительные «меры».
Движок объединяет пространство имен, контрольные группы, а также файловые системы. В результате получается формат container. Разработчики подумывают над внедрением новых форматов. Они будут реализовываться через интегрирование BSD или Solaris.
Процессы после запуска
Многие интересуются, что будет происходить после того, как изолированное пространство окажется запущенным. Алгоритм окажется следующим:
Докер контейнеры и его составляющие могут корректироваться. Для этого используются специальные команды. Но это только один из возможных вариантов развития событий. Управление Docker производится и через специальные элементы.