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 скриптом, и всё такое.
Этого не имелось в виду, от слова совсем, но как мне кажется в всегда нужно выбирать инструмент под задачу а не наоборот.
Но на производительности CPU Docker (или, если вдаваться в детали, namespaces и cgroups) никак не влияет.
И ничего про упаковку зависимостей вообще, что странно.
А вот что интересно — докер докером, но ведь Linux namespaces & cgroups существуют довольно давно. Вопрос — почему именно докер-то?
Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.
Особенно это поняли те, кому приходилось работать с NS, cgroups, jails, zones, etc — когда это больше не боль, а что-то простое, вплоть до уровня хипстеров. Ведь дай хипстеру чистые cgroups и zones — он повесится в мануалах
Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.
Совершенно согласен: Docker это больше про инструменты вокруг него и именно по этому когда я говорил что Docker'у как тогда когда на него переходили мы так и сейчас нет особых альтернатив.
это точно. я раньше как глянул туда, но увидел глубину этой rabbit hole и решил "не сейчас"
а вот с docker — все (почти) просто. Все дело в тулзах
да, про перфоманс меня тоже повеселило :)
Когда я говорил про перформанс то имел ввиду накладные расходы на само «содержание» контейнера, а не то что в Docker'е приложение будет работать медленнее, видимо не сумел правильно передать свою мысль.
Это сами придумали, или проводили замеры? Потому что это откровенный Bullshit.
Мы упирались на мастере в производительность и на железной машине, да, нам приходилось несколько раз добавлять в нее памяти и вы хотите сказать что с Decker'ом у нас бы этого не произошло?
Я конечно понимаю, что модно писать «Супир Сервис Лтд»
Тут полностью согласен имелась в виду именно Docker-Machine
А вы не думайте, а проверяйте.
Я верно понимаю что вы бы Docker использовали даже на рендер-фермах и вычеслителях-геномов, а я думал это я лютый фанат Docker
Товарищи! Я конечно понимаю, что модно писать «Супир Сервис Лтд», но Docker-машина? Как прочитавший это newbie поймёт, что речь про Docker Machine, а не про вручную настроенную «bash скриптами» виртуалку?
Это мой косяк, но текст в котором на русском только междометия тоже выглядит инородно.
В любом случае, в посте теперь есть еще одно мнение и внимательный читатель поймет, на что обратить внимание.
И да, спасибо!
А про работало, потом взорвалось и никто не знает почему — по мне так это очень ценное мнение, но я пока что не слышал такого про докер.
Я все-равно не услышал убедительной причины для использования Docker с Java. Docker в первую очередь решает проблему с нативными приложениями, которые требуют установки, конфигурирования и кучи зависимостей. Чтобы не возиться со всем этим, приложения изолируют в отдельный контейнер, в котором есть все необходимое. А JVM сама по себе уже достаточно неплохо виртуализирована. Поэтому многие использует Docker только как некое средство упаковки и доставки своих приложений — некий супер-JAR, при этом не имея реальной необходимости в средствах виртуализации.
Так что призыв паковать свои Java-микросервисы в Docker — это скорей как раз дань моде.
Это дань моде если уже есть система развертывания, которая удовлетворяет всем требованиям. Тогда встает серьезный вопрос о том стоит оно того или нет.
Но если система строится с нуля, то Docker и вообще контейнеризация — это как минимум очень хороший вариант, хотя и всего лишь один из вариантов
Docker — это когда "жаль мы не можем использовать Java 8 потому что админ не хочет обновлять прод" звучит как боль из прошлого
Docker — это когда разработчикам видней, как тюнить JVM параметры
Docker — это когда Java Agent-ы уже не выглядят так страшно для интеграции
Docker — это когда мне не важно, какие порты будут заняты в моём окружении, я девелопер, я не хочу думать, я хочу 8080
Docker — это когда "мы переползли с Tomcat на Netty, а админ даже не заметил"
Прежде всего докер — это когда ВСЁ деплоится одинаково. Естественно, чем больше приложений и чем больше зоопарк, тем больше выигрыш от докера.
Я не спрашиваю админов, когда нужно обновить Java. Зачем ставить ее глобально, когда можно в свою папку как часть приложения, раз уж админы такие нехорошие?
Кроме того, вы в курсе, что Java 7 уже давно не поддерживается? Наши админы и безопасники по своей инициативе нас попросили обновиться везде, даже если кто-то не собирался.
Параметры? И без докера настраиваем, и ничего вроде, никаких особых проблем.
Агенты? Ну опять же, есть они у нас. И что с ними не так?
С Томкат на Netty? А админу зачем это замечать вообще?
Порты? В 99% случаев это параметры настройки, мало чем отличающиеся от тюнинга JVM. Если их много, их все равно надо как-то выбрать и настроить. Возможно централизованно это проще — но эта тема не раскрыта.
В общем, как-то это все неубедительно звучит. Возможно, докер решает эти проблемы, но они и без него вполне решаемы. Возможно, вам это очевидно, и вы просто кратко излагаете.
Поверьте мне, мы тут в ZeroTurnaround отлично знаем, какая версия Java уже не поддерживается :D Вот только наши покупатели всё равно до сих пор сидят на 6ой, а некоторые и на 5ой. И нежелание админов что-то менять — это очень популярная причина "почему".
Вы явно пишете от лица того, у кого есть доступ к конфигурации окружений. В реальной жизни, в больших кровавых энтерпрайзах, это мягко говоря не так.
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.5 с ядром >= 2.6.32 в EPEL
вы не используете виртуализацию? Если на этих серверах крутятся только ваши приложения, которые не зависят от ОС… почему бы и не обновить? Я думаю, здесь скорее проблемы лицензионные или с каким-либо другим софтом от того же производителя типа мониторинга или аудита.
Не используем. Это проблемы организационные — поддержка ОС это другое подразделение. У них есть некий стандарт, на сегодня это RHEL семейства 6.x. Экспертизы по 7 пока нет или мало.
Соответственно, это не совсем зависит от разработчиков.
почему бы и не обновить?
Потому что оно не сломано )
собственно, экспертиза… для этого и придумали виртуализацию и облака. Если сервер поломался и экспертизы не хватает — грохнуть и пересоздать, дело пяти минут.
Это не виртуалки. Это prod сервера, там работают приложения. Обновлять на RHEL 7 ради того, чтобы заработал докер? Слишком неочевидный профит, чтобы так делать.
А просто попробовать на виртуалках — это есть в планах, но опять же — ваши вполне подробно описанные плюсы к нам не относятся совершенно — по ряду причин, они нам ничего не дадут. У нас выстроенная инфраструктура, которая зачастую сводит запуск приложения к java -jar dropship.jar <артефакт> (шутка, но с изрядной долей правды) .
Я считал, что вы при таком уровне развития инфраструктуры деплоите приложения в кластер — т.е. поменять сервер на проде проблемой не является.
Даже если считать переезд с существующей инфраструктуры на докер бесплатным (а это не так), то это как минимум новые сервера.
Именно так. У меня нет лишней запасной машинки такой же конфигурации. В ней в общем ничего такого — обычная стоечная железяка, 64 гига RAM, 48 ядер зеон, диск вполне себе рядовой. И вторая железка имеется. Резерв. Но стоит она довольно таки дофига. Т.е. просто поменять ее в существующем проекте — это вряд ли. Запланировать кластер и облако для нового — это другое дело.
Для запуска используем «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, и сразу возникло нехорошее предчувствие...
Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»