какую проблему решает docker каковы его плюсы и минусы
Docker: обзор экосистемы
Рассказываем о том, что такое Docker и как он помогает современному разработчику.
Что такое PaaS-решения
Без облачных сервисов сегодня трудно представить не только разработку программного обеспечения и веб-приложений, но и нашу обычную жизнь. Разницу между SaaS, Iaas и Paas наглядно демонстрирует прием Pizza as a Service с помощью такой диаграммы:
PaaS (Platform as a Service) — это виртуальная облачная платформа, средствами которой вы можете обеспечить полный цикл создания и поддержки веб-приложения: разработку, развертывание, тестирование и обслуживание. Все это будет реализовано удобным и быстрым способом.
Вам не нужно приобретать лицензии на программное обеспечение, управлять средствами разработки и сложной инфраструктурой — вы занимаетесь только своими приложениями, а все остальное делает платформа.
Здесь мы обзорно рассмотрим одно из самых популярных подобных решений для разработчиков — Docker.
Суть и возможности Docker
Принцип работы Docker метафорически можно описать как погрузку контейнеров на корабль в порту. До шестидесятых годов прошлого века доставка грузов была сложным процессом: перевозчику приходилось учитывать их различные типы — например, чтобы не повредить хрупкий и мягкий товар. Разгрузка занимала множество времени.
Эту проблему решил контейнер: любые грузы внутри него — будь то бананы или запчасти для авто — можно удобно расположить и перемещать с помощью автоматического крана. Необходимость выгружать при этом содержимое из контейнера исчезла — он не открывается до окончания поездки, и товары не могут случайно смешаться или испортиться из-за движения.
Так и Docker позволяет операционной системе запускать программы изолированно друг от друга — каждую в собственном окружении. Основа его работы — функции linux namespaces, благодаря которым можно виртуализировать и изолировать ресурсы системы. Сегодня уже существуют версии Docker для Windows и macOS. Несмотря на то что лежащие в основе Docker технологии придумали давно, именно он стал идеальной реализацией для решения сложных задач разработки.
Docker — программное обеспечение с открытым исходным кодом на базе Linux, но есть два варианта: бесплатное решение для свободного пользования и платное для корпоративного сегмента.
Компоненты Docker
Рассмотрим, из чего состоит экосистема этого ПО:
Данные передаются от клиента к нему, и тот выполняет всю работу.
Контейнеры (docker containers)
Внутри них вы запускаете свои приложения. По сути, контейнер — не что иное,
как процесс вашей ОС, но запущенный в изолированном окружении, а не на компьютере.
Образы (docker images)
Вы запускаете контейнеры из образов — готовых шаблонов, которые можно скачать или создать самостоятельно.
В них система держит созданные вами образы. Они бывают публичными и частными. Официальный реестр называется DockerHub, в нем более 10 тысяч образов.
Способы применения Docker
Чтобы собрать программу из исходных файлов обычным способом, нужно совершить несколько действий: найти, скачать и установить зависимости для вашей операционной системы, распаковать архив, запустить конфигурирование, компиляцию, установить. Docker заменяет всё это выполнением одной команды.
В целом он используется разработчиками веб-приложений по всему миру
для решения следующих задач:
Kubernetes
Перед пользователями Docker возник вопрос: как разворачивать контейнеры на многих хостах? Как раз для управления их большим количеством в Google был создан Kubernetes. Он предлагает высокоуровневый API, благодаря которому можно группировать контейнеры, задавать их размещение и балансировать нагрузку.
Преимущества и недостатки
Трудно представить, но раньше подавляющее большинство проектов в интернете развертывались на один большой неповоротливый проприетарный сервер. Управлять им было неудобно, сложно и болезненно, даже несмотря на наличие специальных программ.
Docker полностью изменил подход к этому: теперь программы запускаются в отдельных контейнерах. Обновления версий одной программы не могут повлиять на другие обновления и всю систему в целом. Число ошибок и сбоев из-за этих факторов при использовании Docker стремится к нулю.
Плюсы Docker
У инструмента есть недостатки, перечислим их:
Однако плюсы применения Docker в проектах с лихвой перекрывают все это.
Заключение
Это лишь основы, которые необходимо знать о Docker. В его использовании множество нюансов, которые открываются уже при самостоятельном взаимодействии с программным обеспечением. Чтобы разобраться глубже, рекомендуем курс
«PHP-разработчик», где вы узнаете о работе серверов, баз данных и backend-разработке более подробно.
Компьютерная программа в системах класса UNIX, запускаемая самой системой и работающая в фоновом режиме без прямого взаимодействия с пользователем.
Автор в сфере IT, digital, экономики и финансов. Ведет некоммерческий проект для начинающих писателей «ЛитЦех».
Что должен уметь разработчик? «Программировать», — ответите вы и… Угадаете. Но если раньше список необходимых знаний на этом заканчивался, то теперь в век DevOps он только начинается. Когда мы пишем код, нам обязательно надо знать структуру сети: что с чем взаимодействует. Требуется поддержка сразу нескольких языков программирования, а разные куски кода в проекте могут быть написаны на чем угодно.
Мы должны знать, как откатить ПО, если обнаружится ошибка. Мы должны управлять конфигурациями для разных используемых в компании сред — это как минимум несколько dev-сред, тестовые и боевые среды. Ах да, надо еще разбираться в скриптах на разных серверах/операционных системах, ведь далеко не все можно сделать с помощью кода, иногда приходится и скрипты писать.
Мы должны знать требования безопасности, а они становятся все жестче и отъедают у разработчика очень много времени. Не забудем также о поддержке и развитии сопутствующего ПО: Git, Jenkins и так далее. Времени на чисто разработку в итоге у разработчика может просто не хватить.
Что же делать? Выход есть, и кроется он в Docker-контейнерах и системе их управления. Стоит один раз развернуть всю эту сложную махину, и вы, как в старые добрые времена, опять будете писать только код. Всем остальным будут управлять либо другие люди, либо сама система.
Разбираемся в контейнерах
На нижнем уровне развернут Windows Nanoserver. Это мегаобрезанная выжимка из Windows Server, которая не умеет ничего, кроме сопровождения развернутой сервисной программы. Зато и объем у нее в 12 раз меньше.
Если сравнить физические и виртуальные сервера и контейнеры, то выгода последних очевидна.
Контейнеры призваны были стать недорогим и удобным решением, минимально зависимым от ОС. Посмотрим, чем они отличаются. Виртуальные серверы внутри системы располагаются примерно так.
Нижний слой – это хостовый сервер. Он может быть как физическим, так и виртуальным. Следующий слой – любая ОС с виртуализацией, выше – гипервизор. Сверху идут виртуальные серверы, которые можно разделить на гостевую ОС и приложения. То есть под каждый виртуальный сервер поверх ОС развернута гостевая ОС, а это лишняя трата ресурсов.
Посмотрим, как в системе располагаются Linux-контейнеры.
Как видите, над хостовым сервером и ОС сразу располагаются бинарники с приложениями. Гостевая ОС не нужна, ресурсы освобождаются, лицензии на гостевые ОС не нужны.
Windows-контейнеры немного отличаются от линуксовых.
Базовые слои те же: инфраструктура, хостовая ОС (но теперь Windows). А вот дальше контейнеры могут работать напрямую с ОС или быть развернуты поверх гипервизора. В первом случае изоляция процессов и пространств есть, но они используют одно ядро с другими контейнерами, что с точки зрения безопасности — не айс. Если же использовать контейнеры через Hyper-V, то все будет изолировано.
Изучаем Docker под VS
Перейдем к самому Docker. Допустим, у вас есть Visual Studio, и вы проводите первую установку клиента Docker под Windows. При этом Docker развернет сервер Docker demon, интерфейс на Rest для доступа к нему и сам клиент — командную строку Docker. Она позволит нам управлять всем, что связано с контейнерами: сеть, образы, контейнеры, слои.
На слайде показаны самые простые команды: вытянуть Docker-контейнер, запустить его, собрать, закоммитить, отправить обратно.
Docker очень органично сопряжен с Visual Studio. На скриншоте приведена панельная менюшка из Visual Studio 2017. Прямо в Intellisense интегрирована поддержка Docker compose, поддерживаются Dockerfile, а все артефакты работают в командной строке.
Интересно, что мы можем Docker`ом отлаживать контейнеры прямо в режиме реального времени. И если у вас контейнеры связаны друг с другом, то они непосредственно дебажатся все сразу, и запускать несколько сред не потребуется.
Как осуществляется сборка контейнеров? Основной элемент здесь – это файл dockerfile, который содержит инструкции для сборки образа. На каждый проект создается свой dockerfile. В нем указывается: откуда мы берем базовый образ, какие передаем аргументы, как называется рабочая директория с файлами, порты.
Вот этот аргумент source имеет два параметра. Второй параметр – путь, по которому в проект будет размещаться результат сборки, значение задано по умолчанию. На мой взгляд, это не очень удачный вариант. В этой папке часто много мусора, его периодически нужно вычищать, и мы при вычистке этой папки можем потереть сборку. Так что при желании ее можно поменять, она задается системным параметром Docker_build_source, который также можно забить руками.
ASP.Net 4.5+ размещен под управлением IIS или IIS Express, использует Microsoft Visual Studio Debugger и исходники корня сайта в IIS.
Для отладки есть две среды: Debug и Release. Тег образа при дебаггинге помечается как dev, а релиз latest. Аргумент Source при дебаггинге лучше устанавливать на obj/Docker/empty, чтобы не путалось, а при релизе obj/Docker/publish. Здесь вы можете использовать все те же бинарники, вьюхи, wwwroot папку и все зависимости, которые есть.
Осваиваем Docker Compose
Перейдем к самому интересному – инструмент оркестрации Docker-compose. Рассмотрим пример: у вас есть какая-то бизнес-услуга, которая затрагивает 5-6 контейнеров. И вам надо как-то зафиксировать, как они должны собираться, в какой очередности. Здесь пригодится Docker-compose, который обеспечит всю сборку, запуск и масштабирование контейнеров. Управляется он просто, все собирается одной командой.
Docker-compose использует YAML файлы, хранящие конфигурацию, как именно нужно собирать контейнеры. В них описывается, какие настройки нужно использовать для самих образов, сборок, сервисов, томов, сетей, сред. Синтаксис идентичен для публикации в кластерах. То есть один раз написали такой файл, и если в дальнейшем нужно будет разворачивать бизнес-услугу в кластер, не придется ничего больше дописывать.
Рассмотрим структуру YAML-файла. Image — это образ Docker. Образом называется контейнер без слоя приложения, он неизменен.
Build указывает, как нужно производить сборку, куда надо собрать и где развернуть.
Depends_on — зависимость от каких сервисов он зависим.
Environment — здесь мы задаем среду.
Ports — маппинг портов, на каком порту будет доступен ваш контейнер.
Рассмотрим пример. У нас есть просто API без службы, по сути 3 контейнера: есть SQL.data на Линуксе, есть само приложение, оно зависит от webapi, а webapi зависит от SQL.data.
Неважно, в какой последовательности в файле записаны компоненты. Если все правильно описано, Compose автоматически правильно выстроит эту информацию на основе зависимостей в проекте. Этого файла достаточно для того, чтобы собрать все контейнеры сразу, на выходе получится готовый релиз.
Существует этакий «контейнер контейнеров», специальный контейнер docker-compose.ci.build.yml, в котором собрана вся композиция. Из командной строки Visual Studio можно запустить этот спецконтейнер, и он сможет осуществить всю сборку на build сервере, например, в Jenkins.
Заглянем внутрь файла. В примере прописана рабочая директория и откуда что берется. Он восстанавливает из GIT проект, сам делает публикацию этого солюшена, конфигурация Release и выкладывает результат. Вот и вся команда для сборки, больше ничего не нужно прописывать. Достаточно один раз это прописать, а потом запускать публикацию одной кнопкой.
На что еще стоит обратить внимание. Docker-compose для каждой среды собирает образы, для каждой конфигурации отдельный файл. Для каждой конфигурации в Visual Studio есть файл с настройками, которые вам нужны для среды.
Прямо из VS можно удаленно запускать отладку всей композиции.
Оркестраторы кластера
Напоследок коснемся такой темы, как оркестраторы кластера. Мы не должны думать о том, как контейнеры дальше существуют, какими людьми или системами управляются. Для этого есть 4 самые популярные системы управления контейнерами: Google Kubernetes, Mesos DC/OS, Docker Swarm и Azure Service Fabric. Они позволяют управлять кластеризацией и композицией контейнеров.
Эти системы способны управиться с огромным слоем микросервисов, обеспечив их всем необходимым. От разработчика потребуется только один раз настроить этот слой.
Полная версия выступления на Panda Meetup доступна ниже.
Тем, кто хочет глубже погрузиться в тему, советую изучить следующие материалы:
Http://dot.net
Http://docs.docker.com
Http://hub.docker.com/microsoft
Http://docs.microsoft.com
Http://visualstudio.com
И напоследок важный совет из практики: самое сложное — запомнить, где что лежит.
Документирование при работе с docker-контейнерами ляжет на ваши плечи. Без документации вы забудете, где в каком контейнере что с чем связано и что с чем работает. Чем больше сервисов, тем больше итоговая паутина связей.
Docker: по ту сторону Hello World
В мире программирования существуют технологии, must have для каждого разработчика, к числу которых относится и Docker. Подразумевается, что это просто, как таблица умножения, и известно всем. О том, зачем в 2021 году в 100500й раз заводить разговор про докер — статья Сергея Кушнарева, руководителя отдела разработки ZeBrains.
С одной стороны — про него все знают. С другой — если тебя устраивают небольшие веб-проекты, особенно на какой-то конкретной CMS, то докер очень часто оказывается тем самым «первым лишним», и все сводится к инструкции «возьми готовый докер-файл, запусти в терминале docker run и будет тебе счастье». А когда понимаешь, что этого уже недостаточно — натыкаешься на статьи, написанные по тому же принципу «скачайте-запустите-получите». Кому этого мало — читайте дальше.
Зачем программисту холодильник
Кто сказал: «Не люблю пить теплое»? Убираем емкость подальше и смотрим на принципиальную схему девайса:
Холодильник — это блок питания, компрессор, хладагент, конденсатор и камера, в одну из стенок которой спрятаны капиллярные трубки. Все это хозяйство утрамбовано в большой, в меру красивый шкаф с дверцей наружу, за которой и прячется то, что требуется пить охлажденным.
А теперь представим, что в доме программиста появилось существо противоположного пола, считающее, что в холодильнике можно хранить мясо. Что характерно — замороженное. Но при этом, как несложно догадаться, замерзнут до непотребного состояния и напитки, что нас в некотором смысле не совсем устраивает.
У нас два пути: купить второй холодильник или разделить тот, что у нас есть, на две камеры с датчиками температуры на входе, чтобы управлять клапаном подачи хладагента внутрь. Ура, мы только что изобрели двухкамерный холодильник. А заодно — разобрались с тем, для чего программистам понадобились виртуальные машины и докер.
Проекты, которые мы делаем, не сильно отличаются от продуктов в холодильнике — каждому нужны свои условия. Для одного — PHP 7.4, база MySQL 7.6, Sphinx и мейлер на Golang. Для другого — нода 12 версии, Angular 7 и база MySQL 8.0. Проектов может быть не один десяток. Установить это все на одну машину — все равно, что запихнуть все продукты в одну камеру холодильника.
Нужно как-то изолировать один проект (продукт) от другого. На помощь приходит или виртуальная машина (еще один холодильник), или докер (вторая камера со своими настройками). Давайте немного изменим схему нашего устройства:
Включаем воображение и смекалку, поехали!
Итак, у нас есть квартира (компьютер) со своей инфраструктурой, от которой нам требуется электричество (жесткий диск, сетевая плата, процессор, etc). Для установки второго холодильника (виртуальной машины) нам нужен разветвитель розеток (hypervisor). Довольно просто, но мы видим, что для изоляции мяса от напитков нам потребовалось два комплекта оборудования (Guest OS), хотя по факту условия хранения определяет только датчик, управляющий клапаном к капиллярной системе (bins/lib).
В случае, когда мы физически разделяем холодильную и морозильную камеры (container engine), нам не нужна вторая розетка (hypervisor) и место для второго холодильника (полноценная Guest OS). Мы получили два независимых контейнера — каждый со своими условиями (bins/lib), которые подходят нужному продукту (app).
Что ты, черт возьми, такое, Докер?
Разделим вопрос на две части: «как с этим работать» и «как это работает». Эта статья посвящена ответу на первую часть. Если интересно углубиться в детали, пишите в комментариях — поговорим про изоляцию процессов, пространства имен и прочее. А может быть, напишу еще одну статью.
Из схемы выше очевидно, что ответ на вопрос «что такое докер» спрятан в блоке «Container/Docker engine», иначе говоря — движок контейнеризации. Давайте посмотрим на него внимательней:
Первым делом нам потребуется некий сервис (Docker daemon), который будет управлять всем процессом — набор инструкций, как создавать изолированные пространства. Поселим его на своем компьютере!
Сам процесс установки прост и у вас не должно возникнуть трудностей.
Неважно, какую операционную систему вы выберете — все равно выполнение произойдет на Linux. В Windows и Mac будет запускаться виртуализированное ядро Линукса для докера.
Для того, чтобы мы могли как-то управлять этим сервисом, воспользуемся REST API, а команды будем выдавать посредством CLI, назовем его для удобства клиентом (Docker client).
Сами приложения и нужные для их работы библиотеки мы будем хранить в виде файлов-образов (Docker-images). Можете воспринимать их по аналогии с ISO-образами DVD-дисков или как специфический вид архива с данными.
Чтобы все заработало, мы должны с помощью клиента попросить Docker daemon взять конкретный образ и развернуть его в работающий контейнер. Но откуда он его возьмет? Добавим немного логики и инфраструктуры — пусть Docker daemon создаст на нашем компьютере реестр образов и при запросе находит нужный. А если не нашел — отправляется в сеть, находит Docker Hub (сетевой реестр), находит там нужный образ и копирует к нам на локальный компьютер.
Указать, какой конкретно образ нам нужен, мы можем или при запуске контейнера из готового образа (docker run), или при создании нового образа (docker build), или просто запросив скачивание (docker pull).
Получив нужный образ, докер-демон запустит на его основе контейнер, и мы получим работающее приложение. Заодно докер пробросит внутрь изолированного контейнера сеть (network), чтобы мы смогли увидеть результаты работы приложения, и при необходимости «прикрутит» к нему хранилище для сохранения данных (data volumes).
Повторение — мать учения
Теперь все вышеизложенное — но на примере демонстрационного приложения Hello World. Считаем, что демона мы на своем компе уже поселили, ссылка на установку — чуть выше по тексту.
Выполняем команду docker run hello-world и видим следующий результат:
Первое что произошло после команды «докер, запусти образ с именем hello-world», это попытка найти его локально и запустить.
Попытка не увенчалась успехом (у меня была чистая установка докера), причем, обратите внимание, искался образ не hello-world, а hello-world:latest.
Через двоеточие указывается тег — что-то вроде версии или модификации образа. Если его не указать, будет искаться самая свежая версия с общепринятым тегом latest.
Тогда докер решает поискать этот образ на docker hub`е и скачать его оттуда.
https://hub.docker.com/_/hello-world
Примерно такие строки будут друг друга заменять, но это может произойти очень быстро, так как образ очень мал. Вы будете их чаще видеть при загрузке больших и многослойных (про слои чуть позже) образов.
А далее видим следующие строки:
Тут нам сообщают хэш образа и статус, говорящий, что загружен новый образ. Также в этот момент выводится и приветствие с сообщением. Но перед этим происходит еще кое-что.
А именно — из только что скачанного образа был создан контейнер. Если перевести на язык ООП, создался объект sleepy_antonelli (контейнер) экземпляр класса hello-world (образа). Sleepy_antonelli — это рандомно сгенерированное имя контейнера, поскольку мы не указали его явно.
Ну и, наконец, сам текст появляется на экране. Он, кстати, и есть результат работы приложения в контейнере.
Собственно, это тут и написано (вместе с призывом не останавливаться на достигнутом и ссылкой на документацию). Но давайте проверим сами.
Если выполнить команду docker images, мы увидим скачанный образ.
Имена можно задавать и самим, но нам пока это не нужно, поэтому докер сам генерирует для имени два рандомных слова. Также тут видны его ID, образ, с которого он был сделан, команду, ради которой был запущен (в данном случае — написать приветствие), когда был создан, код завершения работы (0 — это штатное завершение) со временем, порты (в данном случае они никак не пробрасывались, потому и пусто) и, наконец, имя.
«Людоеды — как лук, многослойные!»
Осталась еще одна тонкость, которую следует рассказать. Если образ неизменен, а контейнеры смертны, то тогда придется под каждую задачу создавать свой образ?
Нет, для этого придуманы слои. Каждое изменение образа можно выносить в отдельный слой. Это позволяет комбинировать их в разные итоговые образы. И вдобавок, уже готовый образ можно взять за основу и «наслоить» что-то свое.
Это можно представить в виде стопки блинов — тех, что железные. Мы надеваем на гриф блины, чтобы получить нужную нам конфигурацию (вес). Но при этом мы не можем вынуть или заменить какой-то блин в середине — придется пересобрать конфигурацию или довесить новые поверх имеющихся.
Если выполнить предложенную команду из hello world:
То мы увидим, что там несколько слоев:
Подведем итоги
Что же дает нам докер? Во-первых, это изоляция — мы можем запускать что угодно на своем компьютере, не опасаясь за целостность как системы, так и приложения. Они просто не пересекаются.
Во-вторых — чистота. Образ на диске — это самые обычные «инертные» файлы, которые «оживают» только при создании контейнера. Контейнеры же изолированы от внешнего мира.
В-третьих — скорость. Благодаря тому, что мы пользуемся операционной системой хоста, не требуется тратить время на полноценную инициализацию гостевой OS, как это происходит в виртуальной машине. Кроме того, можно удалить из сборки образа весь функционал, не относящийся к конкретному приложению, что тоже уменьшает и размер сборки, и время запуска.
Наконец, это предсказуемость. Контейнеру все равно, что находится снаружи. Поэтому если ваше приложение работало в контейнере на вашем локальном компьютере, оно заработает на любом другом. Забудьте про dependencies hell — эта фраза дорогого стоит!
Можно, конечно, вспомнить еще и о том, что тот же Kubernetes является развитием идеи контейнеров, перенесенной на уровень DevOps, но достаточно и того, что изложено выше.
Вопросы, уточнения и комментарии можно оставлять прямо под текстом — буду рад пообщаться.