Information

Founded
Location
Россия
Website
jugru.org
Employees
51–100 employees
Registered

Habr blog

Pull to refresh
Comments 59

Какой плохой, я б даже сказал вредный материал вы тут наваяли. В основном претензии к Андрей Филатов 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. извините, бомбануло.

даладно, посыл-то понятен — докер ради докера зло, что не так то? везде пихать докер не по феншую жеж

Я ни в коем случае не предлагаю использовать докер везде. Вот только не надо плодить безосновательных слухов о том, что он тормозит, что числодробилки лучше запускать говёньнким bash скриптом, и всё такое.


Вон, CloudFoundry, Kubernetes и подобные системы — все гоняют приложения в контейнерах, и среди них есть такие числодробилки, что никому и не снилось

Вот только не надо плодить безосновательных слухов о том, что он тормозит, что числодробилки лучше запускать говёньнким bash скриптом, и всё такое.


Этого не имелось в виду, от слова совсем, но как мне кажется в всегда нужно выбирать инструмент под задачу а не наоборот.
При использовании Docker могут быть проблемы с производительностью I/O, которые, однако, от Docker как такового не зависят. Если вы используете Device Mapper в качестве драйвера для I/O, то все действительно будет не особо быстро, а если вы еще и изменяли vm.dirty* в сторону уменьшения, то будет по-настоящему тормозить.

Но на производительности CPU Docker (или, если вдаваться в детали, namespaces и cgroups) никак не влияет.

В статье появилась секция от меня, я там привожу ссылки на реальные цифры и исследования, в том числе про IO. В двух словах — на 2016ый год, Docker не влияет на IO — такой результат получили Percona в своём исследовании (ссылка прилагается)

Непонятно, какой драйвер I/O они использовали. Похоже, не Device Mapper. Aufs и OverlayFS не влияет на производительность I/O.
На btrfs тоже всё замечательно, никакого проседания нет.
да, про перфоманс меня тоже повеселило :)

И ничего про упаковку зависимостей вообще, что странно.

А вот что интересно — докер докером, но ведь Linux namespaces & cgroups существуют довольно давно. Вопрос — почему именно докер-то?

Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.


Особенно это поняли те, кому приходилось работать с NS, cgroups, jails, zones, etc — когда это больше не боль, а что-то простое, вплоть до уровня хипстеров. Ведь дай хипстеру чистые cgroups и zones — он повесится в мануалах

Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.

Совершенно согласен: Docker это больше про инструменты вокруг него и именно по этому когда я говорил что Docker'у как тогда когда на него переходили мы так и сейчас нет особых альтернатив.

это точно. я раньше как глянул туда, но увидел глубину этой rabbit hole и решил "не сейчас"
а вот с docker — все (почти) просто. Все дело в тулзах

Ну не только в тулзах, в экосистеме тоже. hub.docker.com, например. Имхо docker это инструменты + экосистема.
Про упаковку зависимостей есть, а про cgroups и прочее уже хорошо сказал bsideup. Удобство и простота использования короче.
да, про перфоманс меня тоже повеселило :)

Когда я говорил про перформанс то имел ввиду накладные расходы на само «содержание» контейнера, а не то что в Docker'е приложение будет работать медленнее, видимо не сумел правильно передать свою мысль.
Это сами придумали, или проводили замеры? Потому что это откровенный Bullshit.

Мы упирались на мастере в производительность и на железной машине, да, нам приходилось несколько раз добавлять в нее памяти и вы хотите сказать что с Decker'ом у нас бы этого не произошло?

Я конечно понимаю, что модно писать «Супир Сервис Лтд»

Тут полностью согласен имелась в виду именно Docker-Machine

А вы не думайте, а проверяйте.

Я верно понимаю что вы бы Docker использовали даже на рендер-фермах и вычеслителях-геномов, а я думал это я лютый фанат Docker
Товарищи! Я конечно понимаю, что модно писать «Супир Сервис Лтд», но Docker-машина? Как прочитавший это newbie поймёт, что речь про Docker Machine, а не про вручную настроенную «bash скриптами» виртуалку?


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

Согласен. Главное — знать меру и стараться не переводить названия, особенно когда оригинал на русском языке :)

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

В любом случае, в посте теперь есть еще одно мнение и внимательный читатель поймет, на что обратить внимание.

И да, спасибо!
Положительный опыт одного человека нерепрезентативен. Совсем. Ещё и бесполезен, т.к. в ситуации «всё пять лет работало, сломалось, никто не знает почему» он не пригодится.
Проблема не в опыте. Проблема в том же, почему пишут дисклеймеры на конференциях. Нужно понимать, что приложения и окружения могут отличаться и то, что отлично работает на 1000 запросов в секунду может взрываться на 1010.
А про работало, потом взорвалось и никто не знает почему — по мне так это очень ценное мнение, но я пока что не слышал такого про докер.

А зря — есть проблемы у докера с storage driver-ами. Правда, всплывают они при деплойменте, а не при работе контейнера, потому и миримся с ними.

Я все-равно не услышал убедительной причины для использования Docker с Java. Docker в первую очередь решает проблему с нативными приложениями, которые требуют установки, конфигурирования и кучи зависимостей. Чтобы не возиться со всем этим, приложения изолируют в отдельный контейнер, в котором есть все необходимое. А JVM сама по себе уже достаточно неплохо виртуализирована. Поэтому многие использует Docker только как некое средство упаковки и доставки своих приложений — некий супер-JAR, при этом не имея реальной необходимости в средствах виртуализации.


Так что призыв паковать свои Java-микросервисы в Docker — это скорей как раз дань моде.

Тут все чуть сложнее.
Это дань моде если уже есть система развертывания, которая удовлетворяет всем требованиям. Тогда встает серьезный вопрос о том стоит оно того или нет.
Но если система строится с нуля, то Docker и вообще контейнеризация — это как минимум очень хороший вариант, хотя и всего лишь один из вариантов
Docker — в случае микросервисов на Java — это не средство виртуализации (хотя тут правильнее говорить о контейнеризации), это, вкупе со средствами оркестрации, инструмент дистрибуции и менеджмента. Например, Docker тебе даёт из коробки инструменты для изоляции ресурсов, унифицированный API для управления жизненным циклом конкретных экземпляров сервисов, и так далее.

Docker — это когда "жаль мы не можем использовать Java 8 потому что админ не хочет обновлять прод" звучит как боль из прошлого


Docker — это когда разработчикам видней, как тюнить JVM параметры


Docker — это когда Java Agent-ы уже не выглядят так страшно для интеграции


Docker — это когда мне не важно, какие порты будут заняты в моём окружении, я девелопер, я не хочу думать, я хочу 8080


Docker — это когда "мы переползли с Tomcat на Netty, а админ даже не заметил"

Прежде всего докер — это когда ВСЁ деплоится одинаково. Естественно, чем больше приложений и чем больше зоопарк, тем больше выигрыш от докера.

Я не спрашиваю админов, когда нужно обновить Java. Зачем ставить ее глобально, когда можно в свою папку как часть приложения, раз уж админы такие нехорошие?


Кроме того, вы в курсе, что Java 7 уже давно не поддерживается? Наши админы и безопасники по своей инициативе нас попросили обновиться везде, даже если кто-то не собирался.


Параметры? И без докера настраиваем, и ничего вроде, никаких особых проблем.


Агенты? Ну опять же, есть они у нас. И что с ними не так?


С Томкат на Netty? А админу зачем это замечать вообще?


Порты? В 99% случаев это параметры настройки, мало чем отличающиеся от тюнинга JVM. Если их много, их все равно надо как-то выбрать и настроить. Возможно централизованно это проще — но эта тема не раскрыта.


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

Поверьте мне, мы тут в ZeroTurnaround отлично знаем, какая версия Java уже не поддерживается :D Вот только наши покупатели всё равно до сих пор сидят на 6ой, а некоторые и на 5ой. И нежелание админов что-то менять — это очень популярная причина "почему".


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

Так 8.5.5.9 по умолчанию на 1.8 стартует и поддерживает весь java 8 совместно с ЕЕ 7.
ага, расскажите об этом владельцам бизнеса, накой им все это когда 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 и соответственно миграция идет года и не факт что завершается.

Вы зря так думаете, он у меня вполне себе кровавый :)


Я вот все равно не понимаю, какая связь между обновлением настроек приложения, и доступом к среде? Настройки все равно нужно менять иногда, какая разница, не желают админы менять настройки просто приложения, или настройки docker? Может это и проще — но суть-то одна.


Кстати, а что, админов не смущает, что новые версии Java попадают к ним в виде контейнеров? Нет? А почему? По-моему это хорошая причина спросить у них, зачем они лезут не в свое дело.

В больших кровавых энтерпрайзах вам и в докере не позволят использовать все по своей прихоти.
Если есть требование, что только tomcat и 7 java, то хоть обдокарись, но только tomcat и 7 java.
Докер в таком случае помогает, если админы готовы перейти на java 8/netty и т.д., но есть большое кол-во другого софта на том же хосте, и все это надо тестить, а это огромный объем работы.
Но имхо в таком случае вам и докер на этот хост поставить не дадут.
Ну, наш пример показывает, что это не совсем так. Как раз таки при его использовании у разработчиков появляется свобода (равно как и ответственность) выбора.

Начинали мы с совсем небольшого количества отдельных виртуальных машин. Поэтому ничего не нужно было тестировать на предмет совместимости.

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


Установка докер требует рута, в отличие от обновлений java, или скажем томката, которые все-таки можно развернуть у себя в папке. И админ ровно также может отказаться, о чем выше и написано.


Или не отказаться явно, как в моем случае, а просто честно ответить — извините, ребята, но у нас нет экспертизы, и мы не можем вам помочь докер запустить. Попробовать обновить ядро? Можно, но работу после этого никто не гарантирует.


То есть, пока мы в рамках своих java технологий — у нас как раз есть свобода. Как только мы выходим на уровень ОС (где собственно и живет докер) — это область ответственности админов. Я могу их попросить, но они могут вполне резонно отказать, по самым разным причинам.

Давайте я попробую объяснить. Т.е. у вас ситуация, когда:


  • приложение — это одна папка (или один архив), и зависимости оно таскает с собой, включая JRE
  • все ваши приложения запускаются одинаково
  • все ваши приложения используют java process watcher (вроде tanuki wrapper), который умеет перезапускать упавший процесс java
  • все ваши приложения пишут логи одинаково (или путь для логов настраивается в конфиге)
  • stdout тоже перехватывается и пишется в лог (важно при крешах jvm)
  • ваши приложения хранятся в центральном репозитории как версионированные артифакты (нексус например)

Если чего-то из вышеперечисленного у вас нет, то докер может это дать. И дополнительно к этому:


  • Умное кеширование — образы докера строятся из слоев, т.е. при деплое новой версии приложения не нужно вместе с ним выкачивать лишних 100+ метров jvm. Это экономит место как в центральном репозитории, так и на хосте. Не говоря уже про скорость деплоя.
  • Безопасность — при взломе приложения хакер получит доступ только к контейнеру, а не к ФС хоста и других приложений
  • Управление запущенными контейнерами — вывести список запущенных приложений, остановить/запустить/перезапустить приложение.
  • Лимиты по памяти и cpu — докер позволяет админам выставлять их унифицированно для всех контейнеров, средствами ОС же придется городить что-то своё.

И дополнительно:


  • построенную инфраструктуру деплоймента можно использовать для не-java (или не ваших) приложений, докер унифицирует.
  • докер гарантирует, что запущенное приложение не использует никаких библиотек и утилит с хоста — это важно для воспроизводимости деплоя
  • если приложению понадобятся библиотеки и утилиты, которые сложно носить с собой (требуется конфигурация с правами рута, установка через apt или вообще перекомпиляция под систему) — докер решает эту проблему.

У нас все перечисленное в первом списке есть. Мне вообще сложно представить себе, почему сегодня всего этого может вдруг не быть?


Именно поэтому я и пишу, что эти проблемы решаются и без докера. Более того, в мире Java они зачастую решены давно. Нормальными системами сборки, OSGI контейнерами типа karaf, например, в каком-то смысле — даже уже JavaEE и деплоем в виде стандартных war/ear, хотите с зависимостями, хотите — без них.


Лишние 100 чего угодно на диске у нас погоды не делают — данных (даже в виде логов, например), все равно больше на порядки. В репозиторий это никто никогда не кладет. Деплоим по локальной сети, так что на скорость жаловаться не приходится. И потом, JVM, даже если пакуется с приложением, совершенно не обязана деплоиться с ним каждый раз.


Безопасность? Ну наверное да.


Управление? Я имею hawtio внутри karaf, и все чем можно управлять, лежит в JMX, мне как-то это все не нужно. Распределенность настроек по куче контейнеров сделает только хуже на первый взгляд.


Не Java не держим. Я заранее согласен, что это частный случай, но я именно про него и говорю.

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


Для новых систем, имхо, альтернативы просто нет. Для существующих, которые уже настроены и работают… не знаю.

Ну… наверное скажем karaf сложнее. Но он тоже дает взамен много чего.


Мы, кстати, не используем докер по весьма простой причине — он тривиально не работает на нашей RHEL 6.5. А заменить версию линукс на кучке серверов — это намного более сложное упражнение, чем заменить все JVM на 8 версию. И вот тут уже я вполне согласен с админами.

вы не используете виртуализацию? Если на этих серверах крутятся только ваши приложения, которые не зависят от ОС… почему бы и не обновить? Я думаю, здесь скорее проблемы лицензионные или с каким-либо другим софтом от того же производителя типа мониторинга или аудита.

Не используем. Это проблемы организационные — поддержка ОС это другое подразделение. У них есть некий стандарт, на сегодня это RHEL семейства 6.x. Экспертизы по 7 пока нет или мало.


Соответственно, это не совсем зависит от разработчиков.


почему бы и не обновить?

Потому что оно не сломано )

собственно, экспертиза… для этого и придумали виртуализацию и облака. Если сервер поломался и экспертизы не хватает — грохнуть и пересоздать, дело пяти минут.

Это не виртуалки. Это prod сервера, там работают приложения. Обновлять на RHEL 7 ради того, чтобы заработал докер? Слишком неочевидный профит, чтобы так делать.


А просто попробовать на виртуалках — это есть в планах, но опять же — ваши вполне подробно описанные плюсы к нам не относятся совершенно — по ряду причин, они нам ничего не дадут. У нас выстроенная инфраструктура, которая зачастую сводит запуск приложения к java -jar dropship.jar <артефакт> (шутка, но с изрядной долей правды) .

Я считал, что вы при таком уровне развития инфраструктуры деплоите приложения в кластер — т.е. поменять сервер на проде проблемой не является.

А зачем?
Даже если считать переезд с существующей инфраструктуры на докер бесплатным (а это не так), то это как минимум новые сервера.

Именно так. У меня нет лишней запасной машинки такой же конфигурации. В ней в общем ничего такого — обычная стоечная железяка, 64 гига RAM, 48 ядер зеон, диск вполне себе рядовой. И вторая железка имеется. Резерв. Но стоит она довольно таки дофига. Т.е. просто поменять ее в существующем проекте — это вряд ли. Запланировать кластер и облако для нового — это другое дело.

Приложение собирается при помощи 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.

Так что не все так однозначно.

Увидел в тексте J2EE, и сразу возникло нехорошее предчувствие...

Специально для тех, кто ставил сюда минус — последняя версия J2EE это 1.4, и это 2003 год. Если вы все еще живете в нем — мне вас искренне жаль. С тех пор существует только JavaEE, без двойки. И нет никаких причин, почему нужно было еще десять лет назад оставаться на более старых версиях.

Да это скорее дело привычки. Мне кажется, что имели ввиду и JavaEE тоже.
У меня иногда в голове тоже проскакивает Catalina вместо Tomcat и Hudson вместо Jenkins, но имею ввиду я, конечно, последние наработки в этих областях.
Ваш комментарий оказался очень полезным для нас
Как хорошо, что я не пользуюсь ни докером, ни альфа-банком…
Only those users with full accounts are able to leave comments. Log in, please.