Идея контейнеризации появилась уже давно, однако Docker оказался первой технологией, которая смогла достичь массовой популярности. О том, почему это случилось, насколько Docker «повзрослел» за 3 года, а заодно о том, когда можно перестать волноваться и начать использовать Docker в своем production приложении, мы поговорили с нашими экспертами:
Александр aatarasoff Тарасов — Software Architect в Альфа-Лаборатории. В настоящее время внедряет микросервисную архитектуру и двигает направление DevOps, а больше года назад рассказывал про свой опыт внедрения Docker в Альфа-Банке.Docker in production: Нельзя использовать инструмент только потому, что он модный
– Почему вы стали использовать Docker?
– Начиналось все не с Docker’а, разумеется: в прошлом году у нас произошел тектонический сдвиг в сторону распределенных систем и микросервисной архитектуры. В рамках этого процесса мы стали перерабатывать свою систему и переходить к более легковесным API и UI, разрабатывать распределенные frontend-системы.
В какой-то момент мы поняли, что с внедрением новых технологий, таких как NodeJS, встает вопрос деплоймента в тестовые и прод-окружения. Появилась необходимость в инструменте, который позволил бы унифицировать способы упаковки и доставки софта до клиента, и при этом максимально облегчил работу сопровождения, так что для нас Docker в первую очередь выполняет функции инкапсуляции, скрывая особенности реализации приложения за унифицированным API. Это позволяет разработчикам более свободно подходить к выбору технологий, а приложению достичь состояния, которое мы с Кириллом Толкачевым на одном из выступлений назвали «stressless architecture»: в контейнере сразу есть все необходимое, чтобы софт был корректно запущен и не конфликтовал с другим ПО, размещенным в одном кластере/машине, и саппорт чувствует себя увереннее при обновлении отдельных частей приложения.
Для примера «stressful» архитектуры можно посмотреть на классическое J2EE приложение: мы зависим от версии Java, версии J2EE-сервера, и это накладывает на нас определенные ограничения, а миграция на новые версии требует масштабного тестирования и выполняется достаточно редко. Переходя на Docker, мы меняем эту концепцию: так как все необходимые зависимости уже находятся внутри нашего контейнера, то ничего не мешает начать использовать новую версию Java или сервера.
– Но ведь Docker не избавляет от тестирования при миграции. За счет чего она становится проще в случае Docker’а?
– Docker построен вокруг концепции одного приложения на контейнер, так что ты уходишь от ситуации, когда необходимо обновить J2EE-сервер, на котором задеплоено два десятка различных компонент. Вместо этого необходимо иметь дело с изолированными приложениями, которые используют более легковесные embedded-сервера. Это позволяет «разнести» обновление по времени (временной шкале) и мигрировать по кусочкам, вместо миграции всего и сразу.
– То есть Docker активно подталкивает переходить на микросервисную архитектуру?
– Я бы не сказал, что подталкивает, но он очень хорошо в нее ложится. Два этих явления очень гармонично дополняют друг друга.
Мы не перестраивали нашу систему только для того, чтобы использовать Docker, наоборот, мы исходили из необходимости раздробить существовавший на тот момент J2EE-сервер, и решение использовать Docker появилось из задач, которые перед нами встали. Я считаю это очень правильным подходом, потому что если ты не знаешь, зачем тебе технология, не можешь ясно понять, какие проблемы она решает, то она тебе не нужна. Нельзя использовать инструмент только потому, что он модный.
– То есть у вас микросервисная архитектура никогда не жила без Docker’а? Если представить себе обратную ситуацию, стали бы вы переводить на Docker уже работающее микросервисное приложение?
– Очень тяжело говорить про абстрактный проект в вакууме. Надо понимать, что Docker решает определенные задачи. Нам бы в любом случае случае понадобились средства оркестрации, менеджмента и так далее. Если бы мы уже написали что-то сами, то перед миграцией на Docker необходимо было бы серьезно взвешивать плюсы, которые Docker нам принесет относительно текущего состояния, и принимать решение исходя из соотношения выгод и затрат такой миграции
– А рассматривали какие-то инструменты, кроме Docker’а?
– Когда мы выбирали инструмент, каких-то альтернатив Docker’у по факту не было, более того, Docker полтора года назад и Docker сейчас – это абсолютно разные вещи. На тот момент существовали LXC-контейнеры, но Docker показался более удобным в первую очередь с точки зрения разработчика.
Сейчас, помимо Docker’а, появился проект Rocket – тоже система контейнеризации со своим API.
В какой-то момент многие крупные компании поняли, что контейнеризация – очень перспективная технология, и создали консорциум Open Container Initiative, в рамках которого разрабатывается рантайм runC. Он полностью опенсорсный, позволяет запускать Docker-образы и любые другие совместимые виды контейнеров. На базе runC сейчас работает и сам Docker. Так что, если использование Docker’а и является вендор lock’ом, то очень незначительно.
– Раз мы заговорили о вендор lock’е: использовать чистый Docker’ в продакшене все равно плохо получается: требуются сопровождающие сервисы для оркестрации, обработки логов и так далее. Не получится ли так, что все такие решения будут созданы для Docker’а, и заменить его будет сложно еще и по этой причине?
Безусловно, так как Docker сейчас является лидером рынка, то все решения в этой сфере поддерживают Docker или имеют на него фокус. Однако, если говорить про Marathon, который мы используем сейчас, то это просто фреймворк над Mesosphere, который специализируется на запуске контейнеров, точнее долго работающих задач.
Я думаю, если Rocket будет иметь популярность, то люди напишут новый фреймворк для Mesosphere, который будет поддерживать Rocket, ну или Rocket напишет свои средства оркестрации и будет использовать их.
– А не получается, что всем разработчикам приходится изучать Docker?
– Короткий ответ: да. Длинный заключается в том, что это вопрос культуры и того, что разработчик является инженером и способен решать задачу в комплексе.
Хорошей аналогией является тестирование: разработка юнит-тестов – это не задача специального человека, даже интеграционные тесты могут быть работой разработчика. Мы считаем, что инженер должен создавать полные и верифицированные решения, готовые к работе у клиента. Если ты сам пишешь тесты на свой софт, запускаешь их на CI-сервере согласно процессу доставки, то выделенный тестировщик нужен для проработки тест-кейсов и тестовой модели, а не самого процесса тестирования. Так же и в мире контейнеризации: инженеры пишут скрипты развертывания своего ПО, они же собирают контейнеры и умеют запускать Docker-образы. Да, это дополнительные знания, которые они имеют, но это не означает, что они должны быть экспертами в системном администрировании или тонкой настройке чего-либо из системного софта, хотя подобные знания смежных предметных областей никогда не бывают лишними.
Это вопрос культуры и культурного сдвига. Разработка – это не just a code, для нас разработка – это выпуск готового решения, которое можно доставить клиенту.
– Много потребовалось тонкой настройки, чтобы деплоиться Docker’ом?
– Тонкой настройки Docker’а – немного, но на инфраструктурный софт: разные системы хранения конфигураций (Consul, Zookeeper), средств оркестрации (Mesosphere и Marathon), обработки логов (Elasticsearch, Kibana, Kafka) – на них времени ушло довольно много.
Если вопрос в том, больше ли стало работы после интеграции с Docker’м, я бы сказал, что существует паритет. Где-то ее становится меньше из-за независимых и самодостаточных компонент, где-то приходится вносить поправки на особенности Docker’а, которые нужно понимать и учитывать при развертывании.
Что же до настройки самого Docker’а, может быть, у нас пока не было таких задач, но тонко настраивать docker engine, менять storage driver от приложения к приложению нам не приходилось.
– Где Docker находится на кривой Гартнера для вашей команды?
– Я думаю, мы на плато продуктивности. Была довольно большая эйфория из-за того, что Docker решает много проблем и имеет минимум недостатков, постепенно мы понимали, что серебряной пули не существует, решали или обходили появлявшиеся проблемы, и теперь мы способны эффективно решать бизнес-задачи с помощью этой технологии.
Prod-ready. Когда ты это кушаешь, тебе, как минимум, не противно, особенно если ты знаешь, как готовить
Андрей Филатов lincore — ведущий системный инженер в компании EPAM Systems, специалист по облачным решениям, фанат Docker и DevOps.– Как вы используете Docker?
– Ну, на одном проекте у нас полностью автоматизирован CI при помощи Docker’а и Jenkins’а.
Docker используется для всего: slave’ы запускаются в Docker-контейнерах, в других контейнерах происходит развертывание тестовых окружений, ну и само приложение тоже запускается в Docker-контейнере.
– А мастер?
– Нет, мастер – большая железная машина: когда тебе нужно собрать что-то маленькое, запустить один-два билда, можно применять Docker, но у нас 20-30 процессов работают 24/7, и Docker не очень подходит, мы бы уперлись в производительность. Даже в текущей конфигурации мы нашу большую железную машину утилизируем по максимуму при том, что на мастере происходит только запуск и оркестрация, все собирается на Doker’зированых slave’ах.
– Как вы пришли к Docker’у?
– Ну, если говорить об этом проекте, то когда я на него пришел, никакого Docker’а там не было. Была классическая связка: два полупустых постоянно простаивающих slave’а, большинства пайплайнов просто не существовало, все кнопки нажимались людьми. То есть с точки зрения CI мало что было сделано. Я выбрал Docker как инструмент, потому что уже знал, что он будет хорошо работать и по максимуму утилизировать ресурсы, которые на тот момент были.
– А если говорить о применении Docker’а в проде?
– Могу рассказать о Docker’е «со вкусом Амазона». Есть у Амазона сервис, который называется Elastic Contaiers Service. При помощи этого инструмента за полчаса я написал bash-скрипт, который организует Zero-downtime деплоймент. Там под капотом используется Docker: у нас есть машинка, которая собирает образы и отправляет их в registry в Амазоне, а дальше магия самого ECS: создаешь задачу, выбираешь сервис и задаешь, какое количество экземпляров должно быть поднято, и все, просто волшебство! Тут нужно заметить, что с Амазоном я знаком давно и привык к JSON-программированию, но важен сам факт, что за полчаса можно организовать доставку приложения от CI до деплоя с gradual rollout и прочими фишечками. Амазон предоставляет все необходимые инструменты вплоть до того, что если ты правильно настроишь свои метрики и Auto Scaling, то вообще ни о чем не нужно заботиться: начинают наваливаться пользователи – и автоматически поднимаются новые инстансы и новые контейнеры на них.
– А до Docker’а вы как жили?
– Как все живут: Jenkins, jenkins slave’ы, у slave‘ов лежат ssh-ключи: они заходят на машины, раскладывают war, jar и так далее по своим местам и рестартуют сервисы. С Docker’ом все стало более гибко и переносимо: сейчас мы можем, в принципе, развернуться где угодно, ничего не меняя – по сути развернуть из образов Docker-контейнеры, ничего не пересобирая.
– А как разработчики переходили на Docker?
– У разработчиков Linux и там весь переход занимает одну строчку. Пришлось, правда, для нескольких quality assurance инженеров написать на wiki подробную инструкцию, как скачать и поставить Docker Machine, как поставить Docker Compose и как сделать так, чтобы это все заработало под Windows, но все ограничивается установкой Docker Machine в Virtual Box, а дальше можно пользоваться cli-утилитами. Docker очень простой инструмент.
– Когда вы переходили на Docker, смотрели другие технологии? Что в тот момент было на рынке?
– Были реализации на виртуальных машинах, давно существующий Virtuozzo, но удобных инструментов, которые позволяли бы сделать то, что мы сделали на Docker’е, не было, и пришлось бы все строить с помощью большой конфигурации Vagrant, но такое решение быстро перестает быть переносимым.
Мы смотрели на Hashicorp Otto, он подавал надежды, но уж очень он недавно на тот момент появился, его было страшновато использовать. Так что альтернатив Docker’у у нас не было, да и сейчас, как мне кажется, их нет, по крайней мере зрелых.
– Насколько хорошо развиваются платформа и экосистема?
– Экосистема движется в правильном направлении, что же до самого Docker’а: Swarm очень сильно недотягивает до того, что дает Амазон, когда дело доходит до оркестрации, но и тут все достаточно неплохо. Я даже проводил небольшой R&D: выяснилось, что, если возникнет необходимость, мы сможем малой кровью мигрировать на Swarm.
– Даже без применения сторонних сервисов вроде mesosphere?
– Ну, для наших нужд – да, все что нужно, в Swarm есть. Мы не используем сложный networking, не используем взаимную интеграцию контейнеров. У нас достаточно простая инфраструктура.
– Можно о ней в двух словах?
– У нас есть три слоя: точка входа на nginx, есть frontend-контейнеры, есть несколько разных типов API, обработчиков информации, и есть несколько сервисов, которые общаются с базами данных. API-сервисы либо сами читают из базы данных, либо отправляют запросы в redis, а те, кто занимаются данными и их модификацией, берут из redis всю необходимую информацию. Если нам нужно будет мигрировать с Амазона, где есть redis и база данных как сервис, то нужно будет поднимать их самостоятельно.
– Для чего бы не стоило использовать Docker?
– Я думаю, в числодробилки его ставить не имеет смысла. Если у вас reporting-инструмент, который переваривает огромные объемы данных, то накладные расходы от Docker’а будут сказываться на производительности, на рендеринг-фермах он тоже не имеет смысла. В общем, там, где нужен «raw performance», Docker не очень годится. Даже не так: там, где есть возможность применять виртуальные машины – Docker подойдет идеально.
Ну и, насколько я знаю, Docker не работает с Windows-контейнерами, хотя на днях была новость, что в 2016 сервере будет поддержка docker-контейнеров, так что Microsoft сотрудничает с командой Docker’a и, скорее всего, это в ближайшее время изменится.
– А если говорить не про инфраструктуру, а про сами приложения: изменились ли подходы с приходом Docker’а?
– Практически нет. Мы изначально готовились к тому, что инфраструктура будет на мелких или средних виртуалках и должна хорошо горизонтально масштабироваться, так что Docker просто заменил нижний уровень. Конечно, в некоторых участках добавились проверки на состояния, в которых находится приложения. То есть, если раньше мы рассчитывали, что приложение или виртуалка могут рестартовать и данные не потеряются, то сейчас все понимают, что если контейнер умрет, то твои данные умрут вместе с ним, и их нужно их хранить в другом месте, но redis и postgresql решают эту проблему.
– Насколько Doker зрелая технология?
– Prod-ready. Когда ты это кушаешь, тебе, как минимум, не противно, особенно если ты знаешь, как готовить.
Docker — это про tooling. До него существовали и cgroups, и zones, и куча других технологий. Но именно Docker сделал их доступными и популярными.
Сергей Егоров bsideup — Full Stack Engineer в компании ZeroTurnaround. Переехал в Эстонию в 2013 году, до этого занимался разработкой игр в различных компаниях России. Любит Docker, строить высоконагруженные системы, ковыряться в Groovy компиляторе, а так же других OpenSource проектах. – Как вы пришли к Docker’у? На каких проектах он у вас крутится?
В 2014 году я работал в компании Creative Mobile и отвечал за разработку и разворачивание серверов в нашем отделе. Это был проект соц. игры, с пиками до 1000 запросов в секунду.
На тот момент я использовал Puppet, которым разворачивал кластер JBoss AS (позже — Wildfly) в EC2 Autoscaling Group, но, к сожалению, такое решение было крайне шатким из-за того, что для быстрого разворачивания серверов (а у нас был Continuous Delivery с десятками деплоев в день) приходилось жертвовать иммутабильностью деплоев.
В итоге иногда присходила ситуация, когда старые пакеты/конфигурация (которая была в XML виде, читать как «один из самых неудобных форматов для изменения из командой строки») конфликтовали с новыми.
Начал изучать варианты имутабельных деплоев. Т.к. хостились на AWS, на тот момент был выбор между OpsWorks и ElasticBeanstalk. После долгого изучения выбор пал на ElasticBeanstalk, где я заметил возможность использовать «какой-то там Docker версии 0.9», который был как опция «если вам не подходит ни один из заранее объявленных решений, то вот вам абстрактная система объявления того, как вы хотите запускать своё приложение». Сразу же полез изучать, что это такое и как готовить, и вот уже на следующий день наш production бегал в Docker-е. Да-да, Docker в 2014 в проде, ещё до того, как мы перешли на него в локальной разработке.
После этого я успешно интегрировал Docker на нескольких других высоконагруженных проектах Creative Mobile. Перейдя в TransferWise, я активно продвигал идею докеризации, а т.к. это было время активной миграции на микросервисы в компании, то долго объяснять преимущества не пришлось, разве что пришлось повоевать с операционистами :)
– Есть мнение, что в некоторых сценариях Docker не выдает высокую производительность за счет накладных расходов. Что вы думаете на этот счет?
Я думаю, что это одна из самых популярных баек про Docker. Лично я верю только цифрам в таких вопросах и личному опыту. И, если ко второму доверия мало, то цифры не врут, и я рекомендую обратить внимание на исследования крупных игроков рынка, таких как IBM, например.
Обратите внимание, документ от Июля 2014 года, а ведь за два года команда Docker'а проделала колосcальное количество улучшений, в том числе производительности.
Например, в 2016 году компании Percona проводила замеры влияния Докера на производительность IO базы данных. Результат — даже не стали выкладывать красивые графики, т.к. результаты были идентичны тем же, но на bare metal.
Примерно те же самые результаты я получил в собственной практике, гоняя в Docker'е всё, от локального окружения разработки до билд систем (да-да, мы гоняем Jenkins-мастер в Docker'е) и продакшна.
– Для чего бы не стоило использовать Docker?
На текущий момент времени, несмотря на огромное количество решений, гонять stateful приложения (базы данных с постоянным хранилищем, разного рода кэши с горячим стартом, нескалируемые бекенды) — это боль. Боль не из-за Докера как такового, а из-за того, что сами приложения не готовы быть запущены на другом хосте, с перенесённой файловой системой, и так далее.
Также если Ваше приложение активно работает с железом, то прокидывание железа внутрь контейнера — до сих пор считается чем-то нетривиальным. Это возможно, но tooling (а я считаю, что Docker — он не про контейнеризацию, но про tooling) к этому не готов из коробки, чтобы совсем просто было.
– Вы с Докером уже несколько лет работаете. Рассматриваете ли альтернативы? Есть ли они вообще?
Альтернативы есть и будут всегда, т.к. некоторым просто не нравится мейнстрим :)
Так же, крупные игроки рынка обеспокоены тем, что они не имеют достаточного влияния на разработку Docker-а.
Благо, ребята из Docker Inc. далеко не глупые, и их попытки стандартизировать всё в виде Open Container Initiative, например, лишь демонстрируют, что они не желают бороться за рынок контейнеров, их рынок — это первокласный tooling.
Напоследок, не могу не поделиться моей Docker-гордостью :D
Если хотите узнать больше о Continuous Delivery, оркестровке и контейнеризации, вам скорее всего окажутся интересны следующие доклады Joker 2016 (СПб, 14-15 октября).
