Идея контейнеризации появилась уже давно, однако 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 октября).
Комментарии (59)
bsideup
05.10.2016 11:14+18Какой плохой, я б даже сказал вредный материал вы тут наваяли. В основном претензии к Андрей Филатов lincore:
Нет, мастер – большая железная машина: когда тебе нужно собрать что-то маленькое, запустить один-два билда, можно применять Docker, но у нас 20-30 процессов работают 24/7, и Docker не очень подходит, мы бы уперлись в производительность.
Это сами придумали, или проводили замеры? Потому что это откровенный Bullshit.
За год Jenkins-а в Docker-е в ZeroTurnaround у меня ни разу не было проблем с производительностью.
Пришлось, правда, для нескольких quality assurance инженеров написать на wiki подробную инструкцию, как скачать и поставить Docker-машину
Товарищи! Я конечно понимаю, что модно писать "Супир Сервис Лтд", но Docker-машина? Как прочитавший это newbie поймёт, что речь про Docker Machine, а не про вручную настроенную "bash скриптами" виртуалку?
Я думаю, в числодробилки его ставить не имеет смысла. Если у вас reporting-инструмент, который переваривает огромные объемы данных, то накладные расходы от Docker’а будут сказываться на производительности
А вы не думайте, а проверяйте. Я с Docker-ом с 2014 года, гонял везде, и дев, и билд системы, и прод. Docker показывает отличную производительность (и это не удивительно, если потратить хотя бы пол часа на изучение, как он работает и что это вообще такое)
У нас (ZeroTurnaround) сейчас активный проект — APM (application performance monitoring), всё бегает в Docker-е, чуть более чем быстро.
Даже не так: там, где есть возможность применять виртуальные машины – Docker подойдет идеально.
Ясно-понятно.
Дорогие JUG.ru, Вас слушают десятки тысяч разработчиков, пожалуйста, следите за качеством материала и проводите пост-модерацию. А то наплодите сотни таких вот экспертов.
P.S. извините, бомбануло.
kristoferrobin
05.10.2016 11:48+2даладно, посыл-то понятен — докер ради докера зло, что не так то? везде пихать докер не по феншую жеж
bsideup
05.10.2016 11:57+12Я ни в коем случае не предлагаю использовать докер везде. Вот только не надо плодить безосновательных слухов о том, что он тормозит, что числодробилки лучше запускать говёньнким bash скриптом, и всё такое.
Вон, CloudFoundry, Kubernetes и подобные системы — все гоняют приложения в контейнерах, и среди них есть такие числодробилки, что никому и не снилось
lincore
05.10.2016 13:11Вот только не надо плодить безосновательных слухов о том, что он тормозит, что числодробилки лучше запускать говёньнким bash скриптом, и всё такое.
Этого не имелось в виду, от слова совсем, но как мне кажется в всегда нужно выбирать инструмент под задачу а не наоборот.
ValdikSS
05.10.2016 13:37При использовании Docker могут быть проблемы с производительностью I/O, которые, однако, от Docker как такового не зависят. Если вы используете Device Mapper в качестве драйвера для I/O, то все действительно будет не особо быстро, а если вы еще и изменяли vm.dirty* в сторону уменьшения, то будет по-настоящему тормозить.
Но на производительности CPU Docker (или, если вдаваться в детали, namespaces и cgroups) никак не влияет.bsideup
05.10.2016 13:57В статье появилась секция от меня, я там привожу ссылки на реальные цифры и исследования, в том числе про IO. В двух словах — на 2016ый год, Docker не влияет на IO — такой результат получили Percona в своём исследовании (ссылка прилагается)
23derevo
05.10.2016 12:26да, про перфоманс меня тоже повеселило :)
И ничего про упаковку зависимостей вообще, что странно.
А вот что интересно — докер докером, но ведь Linux namespaces & cgroups существуют довольно давно. Вопрос — почему именно докер-то?bsideup
05.10.2016 12:29+7Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.
Особенно это поняли те, кому приходилось работать с NS, cgroups, jails, zones, etc — когда это больше не боль, а что-то простое, вплоть до уровня хипстеров. Ведь дай хипстеру чистые cgroups и zones — он повесится в мануалах
lincore
05.10.2016 13:04Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.
Совершенно согласен: Docker это больше про инструменты вокруг него и именно по этому когда я говорил что Docker'у как тогда когда на него переходили мы так и сейчас нет особых альтернатив.
Dreyk
05.10.2016 13:16это точно. я раньше как глянул туда, но увидел глубину этой rabbit hole и решил "не сейчас"
а вот с docker — все (почти) просто. Все дело в тулзах
hudson
05.10.2016 22:35+1Ну не только в тулзах, в экосистеме тоже. hub.docker.com, например. Имхо docker это инструменты + экосистема.
aatarasoff
05.10.2016 12:48Про упаковку зависимостей есть, а про cgroups и прочее уже хорошо сказал bsideup. Удобство и простота использования короче.
lincore
05.10.2016 13:19да, про перфоманс меня тоже повеселило :)
Когда я говорил про перформанс то имел ввиду накладные расходы на само «содержание» контейнера, а не то что в Docker'е приложение будет работать медленнее, видимо не сумел правильно передать свою мысль.
lincore
05.10.2016 12:59Это сами придумали, или проводили замеры? Потому что это откровенный Bullshit.
Мы упирались на мастере в производительность и на железной машине, да, нам приходилось несколько раз добавлять в нее памяти и вы хотите сказать что с Decker'ом у нас бы этого не произошло?
Я конечно понимаю, что модно писать «Супир Сервис Лтд»
Тут полностью согласен имелась в виду именно Docker-Machine
А вы не думайте, а проверяйте.
Я верно понимаю что вы бы Docker использовали даже на рендер-фермах и вычеслителях-геномов, а я думал это я лютый фанат Docker
Trans00
05.10.2016 13:14Товарищи! Я конечно понимаю, что модно писать «Супир Сервис Лтд», но Docker-машина? Как прочитавший это newbie поймёт, что речь про Docker Machine, а не про вручную настроенную «bash скриптами» виртуалку?
Это мой косяк, но текст в котором на русском только междометия тоже выглядит инородно.bsideup
05.10.2016 13:16Согласен. Главное — знать меру и стараться не переводить названия, особенно когда оригинал на русском языке :)
ARG89
05.10.2016 13:43+1По поводу модерирования замечание справедливое, но формат интервью такой, что мы передаем опыт наших коллег в массы:) Иногда опыт не бесспорный, что поделать?
В любом случае, в посте теперь есть еще одно мнение и внимательный читатель поймет, на что обратить внимание.
И да, спасибо!
mrobespierre
05.10.2016 14:46Положительный опыт одного человека нерепрезентативен. Совсем. Ещё и бесполезен, т.к. в ситуации «всё пять лет работало, сломалось, никто не знает почему» он не пригодится.
Trans00
05.10.2016 15:23Проблема не в опыте. Проблема в том же, почему пишут дисклеймеры на конференциях. Нужно понимать, что приложения и окружения могут отличаться и то, что отлично работает на 1000 запросов в секунду может взрываться на 1010.
А про работало, потом взорвалось и никто не знает почему — по мне так это очень ценное мнение, но я пока что не слышал такого про докер.Scf
05.10.2016 15:34А зря — есть проблемы у докера с storage driver-ами. Правда, всплывают они при деплойменте, а не при работе контейнера, потому и миримся с ними.
Throwable
05.10.2016 11:38Я все-равно не услышал убедительной причины для использования Docker с Java. Docker в первую очередь решает проблему с нативными приложениями, которые требуют установки, конфигурирования и кучи зависимостей. Чтобы не возиться со всем этим, приложения изолируют в отдельный контейнер, в котором есть все необходимое. А JVM сама по себе уже достаточно неплохо виртуализирована. Поэтому многие использует Docker только как некое средство упаковки и доставки своих приложений — некий супер-JAR, при этом не имея реальной необходимости в средствах виртуализации.
Так что призыв паковать свои Java-микросервисы в Docker — это скорей как раз дань моде.
Trans00
05.10.2016 11:45+4Тут все чуть сложнее.
Это дань моде если уже есть система развертывания, которая удовлетворяет всем требованиям. Тогда встает серьезный вопрос о том стоит оно того или нет.
Но если система строится с нуля, то Docker и вообще контейнеризация — это как минимум очень хороший вариант, хотя и всего лишь один из вариантов
aatarasoff
05.10.2016 11:49+6Docker — в случае микросервисов на Java — это не средство виртуализации (хотя тут правильнее говорить о контейнеризации), это, вкупе со средствами оркестрации, инструмент дистрибуции и менеджмента. Например, Docker тебе даёт из коробки инструменты для изоляции ресурсов, унифицированный API для управления жизненным циклом конкретных экземпляров сервисов, и так далее.
bsideup
05.10.2016 11:55+7Docker — это когда "жаль мы не можем использовать Java 8 потому что админ не хочет обновлять прод" звучит как боль из прошлого
Docker — это когда разработчикам видней, как тюнить JVM параметры
Docker — это когда Java Agent-ы уже не выглядят так страшно для интеграции
Docker — это когда мне не важно, какие порты будут заняты в моём окружении, я девелопер, я не хочу думать, я хочу 8080
Docker — это когда "мы переползли с Tomcat на Netty, а админ даже не заметил"
Scf
05.10.2016 12:55Прежде всего докер — это когда ВСЁ деплоится одинаково. Естественно, чем больше приложений и чем больше зоопарк, тем больше выигрыш от докера.
sshikov
05.10.2016 13:02-2Я не спрашиваю админов, когда нужно обновить Java. Зачем ставить ее глобально, когда можно в свою папку как часть приложения, раз уж админы такие нехорошие?
Кроме того, вы в курсе, что Java 7 уже давно не поддерживается? Наши админы и безопасники по своей инициативе нас попросили обновиться везде, даже если кто-то не собирался.
Параметры? И без докера настраиваем, и ничего вроде, никаких особых проблем.
Агенты? Ну опять же, есть они у нас. И что с ними не так?
С Томкат на Netty? А админу зачем это замечать вообще?
Порты? В 99% случаев это параметры настройки, мало чем отличающиеся от тюнинга JVM. Если их много, их все равно надо как-то выбрать и настроить. Возможно централизованно это проще — но эта тема не раскрыта.
В общем, как-то это все неубедительно звучит. Возможно, докер решает эти проблемы, но они и без него вполне решаемы. Возможно, вам это очевидно, и вы просто кратко излагаете.
bsideup
05.10.2016 13:07+4Поверьте мне, мы тут в ZeroTurnaround отлично знаем, какая версия Java уже не поддерживается :D Вот только наши покупатели всё равно до сих пор сидят на 6ой, а некоторые и на 5ой. И нежелание админов что-то менять — это очень популярная причина "почему".
Вы явно пишете от лица того, у кого есть доступ к конфигурации окружений. В реальной жизни, в больших кровавых энтерпрайзах, это мягко говоря не так.
kristoferrobin
05.10.2016 13:19+1+1, WAS и этим все сказано. И хоть убейся
gotozero
05.10.2016 23:32Так 8.5.5.9 по умолчанию на 1.8 стартует и поддерживает весь java 8 совместно с ЕЕ 7.
kristoferrobin
06.10.2016 10:31+1ага, расскажите об этом владельцам бизнеса, накой им все это когда WAS куплен десятилетия назад и апдейты
1) платные за кучу бабла
2) еще и не факт что приложения писанные непонятно когда непонятно кем стартанут as is на новом WAS
3) саппорт как правило сборище людей которые в лучшем случае могут кнопочку тыркнуть если в мануале есть, зато с кучей сертификатов от IBM/Microsoft/%companyname% и не обучен работать с версией отличной от текущей т.к. думать они не обучены
за всех не скажу, но я работал в 4 топ банках в Украине в штате, а софт пилил для >100, соответственно сталкивался. и в 99,9% случаев все именно так. WAS больше 8.5 я впринципе не видел, причем это 6 Java без патчей на 7 и это считалось «офигеть, смотрите какие мы крутые», а, как правило, это 7.0 и не волнует. Ну справедливости ради стараются прыгнуть 7.0->8.5, но смотрим первые два пункта, помним о 3 и соответственно миграция идет года и не факт что завершается.
sshikov
05.10.2016 13:23+1Вы зря так думаете, он у меня вполне себе кровавый :)
Я вот все равно не понимаю, какая связь между обновлением настроек приложения, и доступом к среде? Настройки все равно нужно менять иногда, какая разница, не желают админы менять настройки просто приложения, или настройки docker? Может это и проще — но суть-то одна.
Кстати, а что, админов не смущает, что новые версии Java попадают к ним в виде контейнеров? Нет? А почему? По-моему это хорошая причина спросить у них, зачем они лезут не в свое дело.
nApoBo3
05.10.2016 21:32В больших кровавых энтерпрайзах вам и в докере не позволят использовать все по своей прихоти.
Если есть требование, что только tomcat и 7 java, то хоть обдокарись, но только tomcat и 7 java.
Докер в таком случае помогает, если админы готовы перейти на java 8/netty и т.д., но есть большое кол-во другого софта на том же хосте, и все это надо тестить, а это огромный объем работы.
Но имхо в таком случае вам и докер на этот хост поставить не дадут.aatarasoff
05.10.2016 21:55+1Ну, наш пример показывает, что это не совсем так. Как раз таки при его использовании у разработчиков появляется свобода (равно как и ответственность) выбора.
Начинали мы с совсем небольшого количества отдельных виртуальных машин. Поэтому ничего не нужно было тестировать на предмет совместимости.sshikov
06.10.2016 09:23Понимаете, штатно в комплекте скажем нашего линукса докера нет. Поэтому аргумент "наш админ не хочет обновлять java" мне прямо скажем кажется слегка притянутым за уши.
Установка докер требует рута, в отличие от обновлений java, или скажем томката, которые все-таки можно развернуть у себя в папке. И админ ровно также может отказаться, о чем выше и написано.
Или не отказаться явно, как в моем случае, а просто честно ответить — извините, ребята, но у нас нет экспертизы, и мы не можем вам помочь докер запустить. Попробовать обновить ядро? Можно, но работу после этого никто не гарантирует.
То есть, пока мы в рамках своих java технологий — у нас как раз есть свобода. Как только мы выходим на уровень ОС (где собственно и живет докер) — это область ответственности админов. Я могу их попросить, но они могут вполне резонно отказать, по самым разным причинам.
Scf
05.10.2016 13:35+3Давайте я попробую объяснить. Т.е. у вас ситуация, когда:
- приложение — это одна папка (или один архив), и зависимости оно таскает с собой, включая JRE
- все ваши приложения запускаются одинаково
- все ваши приложения используют java process watcher (вроде tanuki wrapper), который умеет перезапускать упавший процесс java
- все ваши приложения пишут логи одинаково (или путь для логов настраивается в конфиге)
- stdout тоже перехватывается и пишется в лог (важно при крешах jvm)
- ваши приложения хранятся в центральном репозитории как версионированные артифакты (нексус например)
Если чего-то из вышеперечисленного у вас нет, то докер может это дать. И дополнительно к этому:
- Умное кеширование — образы докера строятся из слоев, т.е. при деплое новой версии приложения не нужно вместе с ним выкачивать лишних 100+ метров jvm. Это экономит место как в центральном репозитории, так и на хосте. Не говоря уже про скорость деплоя.
- Безопасность — при взломе приложения хакер получит доступ только к контейнеру, а не к ФС хоста и других приложений
- Управление запущенными контейнерами — вывести список запущенных приложений, остановить/запустить/перезапустить приложение.
- Лимиты по памяти и cpu — докер позволяет админам выставлять их унифицированно для всех контейнеров, средствами ОС же придется городить что-то своё.
И дополнительно:
- построенную инфраструктуру деплоймента можно использовать для не-java (или не ваших) приложений, докер унифицирует.
- докер гарантирует, что запущенное приложение не использует никаких библиотек и утилит с хоста — это важно для воспроизводимости деплоя
- если приложению понадобятся библиотеки и утилиты, которые сложно носить с собой (требуется конфигурация с правами рута, установка через apt или вообще перекомпиляция под систему) — докер решает эту проблему.
sshikov
05.10.2016 13:46+3У нас все перечисленное в первом списке есть. Мне вообще сложно представить себе, почему сегодня всего этого может вдруг не быть?
Именно поэтому я и пишу, что эти проблемы решаются и без докера. Более того, в мире Java они зачастую решены давно. Нормальными системами сборки, OSGI контейнерами типа karaf, например, в каком-то смысле — даже уже JavaEE и деплоем в виде стандартных war/ear, хотите с зависимостями, хотите — без них.
Лишние 100 чего угодно на диске у нас погоды не делают — данных (даже в виде логов, например), все равно больше на порядки. В репозиторий это никто никогда не кладет. Деплоим по локальной сети, так что на скорость жаловаться не приходится. И потом, JVM, даже если пакуется с приложением, совершенно не обязана деплоиться с ним каждый раз.
Безопасность? Ну наверное да.
Управление? Я имею hawtio внутри karaf, и все чем можно управлять, лежит в JMX, мне как-то это все не нужно. Распределенность настроек по куче контейнеров сделает только хуже на первый взгляд.
Не Java не держим. Я заранее согласен, что это частный случай, но я именно про него и говорю.
Scf
05.10.2016 14:02+1Докер — это один инструмент. Инструмент весьма простой в понимании и использовании. Не знаю, насколько сложнее тот набор технологий, который обеспечивает вам те же преимущества… Но он наверняка сложнее.
Для новых систем, имхо, альтернативы просто нет. Для существующих, которые уже настроены и работают… не знаю.
sshikov
05.10.2016 14:15+1Ну… наверное скажем karaf сложнее. Но он тоже дает взамен много чего.
Мы, кстати, не используем докер по весьма простой причине — он тривиально не работает на нашей RHEL 6.5. А заменить версию линукс на кучке серверов — это намного более сложное упражнение, чем заменить все JVM на 8 версию. И вот тут уже я вполне согласен с админами.
Scf
05.10.2016 14:22вы не используете виртуализацию? Если на этих серверах крутятся только ваши приложения, которые не зависят от ОС… почему бы и не обновить? Я думаю, здесь скорее проблемы лицензионные или с каким-либо другим софтом от того же производителя типа мониторинга или аудита.
sshikov
05.10.2016 14:34Не используем. Это проблемы организационные — поддержка ОС это другое подразделение. У них есть некий стандарт, на сегодня это RHEL семейства 6.x. Экспертизы по 7 пока нет или мало.
Соответственно, это не совсем зависит от разработчиков.
почему бы и не обновить?
Потому что оно не сломано )
Scf
05.10.2016 17:49+1собственно, экспертиза… для этого и придумали виртуализацию и облака. Если сервер поломался и экспертизы не хватает — грохнуть и пересоздать, дело пяти минут.
sshikov
05.10.2016 18:20+2Это не виртуалки. Это prod сервера, там работают приложения. Обновлять на RHEL 7 ради того, чтобы заработал докер? Слишком неочевидный профит, чтобы так делать.
А просто попробовать на виртуалках — это есть в планах, но опять же — ваши вполне подробно описанные плюсы к нам не относятся совершенно — по ряду причин, они нам ничего не дадут. У нас выстроенная инфраструктура, которая зачастую сводит запуск приложения к java -jar dropship.jar <артефакт> (шутка, но с изрядной долей правды) .
Scf
05.10.2016 18:34+1Я считал, что вы при таком уровне развития инфраструктуры деплоите приложения в кластер — т.е. поменять сервер на проде проблемой не является.
Trans00
05.10.2016 18:46+1А зачем?
Даже если считать переезд с существующей инфраструктуры на докер бесплатным (а это не так), то это как минимум новые сервера.sshikov
06.10.2016 09:13Именно так. У меня нет лишней запасной машинки такой же конфигурации. В ней в общем ничего такого — обычная стоечная железяка, 64 гига RAM, 48 ядер зеон, диск вполне себе рядовой. И вторая железка имеется. Резерв. Но стоит она довольно таки дофига. Т.е. просто поменять ее в существующем проекте — это вряд ли. Запланировать кластер и облако для нового — это другое дело.
Throwable
06.10.2016 12:31+2Приложение собирается при помощи Maven/Gradle и экспортирует все свои зависимости. JRE не таскаем — это уже реквизит клиента.
Для запуска используем «Yet Another Java Service Wrapper». На Java корректно упавшее приложение в случае исключительной ситуации — это большая редкость. Чаще всего процесс висит, но не обрабатывает запросы. Поэтому всегда приходится делать велосипеды типа Watchdog-ов и интегрировать их с YAJSW.
Про логи не понял. Однозначно slf4j+logback. Для кластерного приложения лучше поднять logging server и сбрасывать туда.
Артефакты для деплоя хранятся в центральном репозитории, который есть SVN (не смейтесь) со всеми своими версиями, ветками, экономией места, etc… Деплой делается простой командой svn update. Более того, она иногда стоит в скрипте (пере)запуска.
Теперь что огорчает:
— Разрабатываю на Windows. Пускать VirtualBox, чтобы поднять контейнер, чтобы просто сделать билд приложению по-моему накладно. На данный момент билд приложения можно сделать на любой машине с JDK (спасибо Maven wrapper).
— Упс. А у клиента Solaris :( И вообще они сказали, что это их инфраструктура и они хотят контролировать и мониторить что и как на ней вертится.
— Меппинг портов из контейнера сильно усложняет использование извне таких API как JMX, и делает невозможным использование RMI. А также усложняет конфигурацию многих распределенных систем, использующих multicast протокол для service discovery.
— И вообще service discovery в docker — отдельная и достаточно нетривиальная тема. Например уже так просто не запустить в контейнерах приложение с embedded Zookeeper или Hazelcast.
Так что не все так однозначно.
sshikov
05.10.2016 12:51+1Увидел в тексте J2EE, и сразу возникло нехорошее предчувствие...
sshikov
05.10.2016 13:48Специально для тех, кто ставил сюда минус — последняя версия J2EE это 1.4, и это 2003 год. Если вы все еще живете в нем — мне вас искренне жаль. С тех пор существует только JavaEE, без двойки. И нет никаких причин, почему нужно было еще десять лет назад оставаться на более старых версиях.
Prototik
05.10.2016 14:13Да это скорее дело привычки. Мне кажется, что имели ввиду и JavaEE тоже.
У меня иногда в голове тоже проскакивает Catalina вместо Tomcat и Hudson вместо Jenkins, но имею ввиду я, конечно, последние наработки в этих областях.
past
Секта свидетелей докера.