Comments 18
Вместо обещанного процесса «создания цепочек DevOps с помощью инструментов с открытым исходным кодом» увидел картинки, картинки с табличками со списком продуктов, и мало что поясняющий текст. Зато тегов много.
Travis CI MIT? Я что-то проспал?
Очень хочу услышать аргументы за докер для Java.
Понимаю, что это перевод и просьба до автора не дойдет.
Потому приглашаю дать комментарии тех, кто везде твердит "докер это круто", вместо "некоторые вещи хорошо решаются с помощью докера".
- Можно тащить несколько версий Явы
- Унификация тестовой и продакшен среды. И среды, где бежит сборка
- Потенциально — возможность поехать в кубернетес, но запаковка в контейнер — это только первый и самый простой (не всегда!) шаг
А что не так с докером для Java? Собрал jar и запустил spring-boot например.
наверное, имеется в виду, что на хосте и так прекрасно уживается 100500 версий джавы и проблема окружения высосана из пальца. А вот настройка джавы для работы в докере (лимиты и прочая дрянь) — вполне себе дополнительная сложность.
Проблемы в мультиверсионировании нету, это так. И с дополнительными настройками не вижу проблем, один раз сделал и оно работает на каждый билд.
А вот контейнеризация того, что уже по своей сути контейнером является, вызывает у меня взрыв мозга.
А вот контейнеризация того, что уже по своей сути контейнером является, вызывает у меня взрыв мозга.
ну, Ваш сервис джавы все равно оборачивать в тот же systemd юнит… Почему бы не обернуть в докер? Или чем Вы их там планируете менеджить?
systemd ≠ container
Не равно (я и не утверждал, что равно), но часть решаемых ими задач пересекается.
Верно, пересекаются.
Мне недоступно понимание плюсов/профита от засовывания явы в докер против systemd.
Мне недоступно понимание плюсов/профита от засовывания явы в докер против systemd.
Docker позволяет создать минимальное окружение для запуска вашего приложения. Удобнее выполнить docker build на основании написанного Вами Dockerfile, чем проходить квест с установкой нужной версии Java, дополнительных пакетов определенных версий и т.д. до тех пор, пока Вы не перейдете на новую версию Java и не придется проходить по новой квест. Да и сделав docker-образ больше не придется его билдить, что бы запустить его на другой машине, а просто воспользовавшись docker registry перенести его куда угодно и где бы он не был запущен, он будет работать. Удобнее чем копировать с сервера на сервер все эти вот jar/war-ники.
Собственно для Java самый распространенный вариант запуска в docker-контейнере, это сборка проекта. Я уже даже не вспомню когда последний раз готовил стенды для сборки Java, сейчас только указываю в каком образе выполнить сборку проекта, т.е. стенд стал динамическим и управляется с помощью кода. Т.е. мне как админу разбираться в этих особенностях больше не надо, а это экономит наши с вами время и нервы.
Ну и docker это не просто упаковка приложений и либ в один файл, а инфраструктура позволяющая гибко управлять Вашими приложениями, опять же управляемое кодом.
Ну а дальше идут OpenShift, Kubernetes и т.д., которые на голову обходят сложные и неповоротливые Wildfly и IBM WS, хотя их сравнивать неверно. Но на сегодня я лучше запущу в контейнере в Kubernetes полностью рабочую инфраструктуру за пару часов, чем буду неделю разбираться почему в WildFly не работает одно приложение.
Собственно Ваша позиция только со стороны Dev, что творится в Ops Вам безразлично, как следствие не щупали Вы DevOps как следует.
Попробуйте с помощью systemd быстро мигрировать Ваше приложение вместе с БД на другой кластер и попробуйте это же сделать с помощью docker swarm в связке с consul и confd, например. Которые так же можно развернуть в docker (да, и docker можно запустить в docker, называется dind).
Ну а разработкой заниматься с помощью docker одно удовольствие, так что docker-compose Вам в помощь.
Вариантов использования docker очень много. Попробуйте, Вам понравится.
Собственно для Java самый распространенный вариант запуска в docker-контейнере, это сборка проекта. Я уже даже не вспомню когда последний раз готовил стенды для сборки Java, сейчас только указываю в каком образе выполнить сборку проекта, т.е. стенд стал динамическим и управляется с помощью кода. Т.е. мне как админу разбираться в этих особенностях больше не надо, а это экономит наши с вами время и нервы.
Ну и docker это не просто упаковка приложений и либ в один файл, а инфраструктура позволяющая гибко управлять Вашими приложениями, опять же управляемое кодом.
Ну а дальше идут OpenShift, Kubernetes и т.д., которые на голову обходят сложные и неповоротливые Wildfly и IBM WS, хотя их сравнивать неверно. Но на сегодня я лучше запущу в контейнере в Kubernetes полностью рабочую инфраструктуру за пару часов, чем буду неделю разбираться почему в WildFly не работает одно приложение.
Собственно Ваша позиция только со стороны Dev, что творится в Ops Вам безразлично, как следствие не щупали Вы DevOps как следует.
Попробуйте с помощью systemd быстро мигрировать Ваше приложение вместе с БД на другой кластер и попробуйте это же сделать с помощью docker swarm в связке с consul и confd, например. Которые так же можно развернуть в docker (да, и docker можно запустить в docker, называется dind).
Ну а разработкой заниматься с помощью docker одно удовольствие, так что docker-compose Вам в помощь.
Вариантов использования docker очень много. Попробуйте, Вам понравится.
Да, в Java сделано все то, что контейнеры сотоварищи сделали для всех остальных ЯП. Поэтому Java в контейнеры пихают в основном для унификации процесса со всем остальным. Но если у вас в компании на Java всё — действительно, контейнеры типа Docker вам незачем.
Как Amazon, Google и Netflix успевают столько выкатывать? А все просто: они поняли, как создать почти идеальную цепочку DevOps.
И нигде не написано, зачем они столько раз выкатывают.
Вот бы глянуть список решенных задач того же Амазона хотя бы за 1 час, а то пока это больше похоже на «у кого больше?»
А по сути статьи… Это как гвозди микроскопом забивать. У людей процессы разработки не выстроены были, а они сразу в devOps. По пути процессы выстроили, счастье наступило, но так и не поняли, что счастье наступило от процессов, а не от devops'a, который под их проблемы, в общем-то, нафиг не был нужен
И нигде не написано, зачем они столько раз выкатывают.
очень просто. Они ставят A/B эксперименты. Причем, когда у тебя посещаемость сайта 1 млн пользователей, то ты можешь эти эксперименты ставить по 10 штук на дню. Был доклад от Яндекса, как они это делают… habr.com/ru/company/yandex/blog/342704
По пути процессы выстроили, счастье наступило, но так и не поняли, что счастье наступило от процессов, а не от devops'a, который под их проблемы, в общем-то, нафиг не был нужен
примерно, но девопс — он про процессы, в общем-то, а не про технологии.
очень просто. Они ставят A/B эксперименты. Причем, когда у тебя посещаемость сайта 1 млн пользователей, то ты можешь эти эксперименты ставить по 10 штук на дню.
10, да пусть при их объеме даже 1000 экспериментов. Но 23 тысячи это все равно за гранью, как мне кажется.
девопс — он про процессы, в общем-то, а не про технологии
А потом заходим на условный hh и видим, что уже давно идет смысловая миграция и большинству нужны именно технологии, а не процессы. А «Однако, исследование, выпущенное в январе 2017 года компанией „F5 Labs“, на основе опроса почти 2200 ИТ-руководителей и специалистов отрасли, показало, что только один из пяти опрошенных полагает, что DevOps оказывает стратегическое влияние на их организацию, несмотря на рост использования.» вообще удручает, поскольку косвенно показывает, что большинство внедряли его просто потому что модно, а не для решения каких-то проблем. Вангую, что у них внедрен такой же DevOps, как у эффективных менеджеров Agile
И нигде не написано, зачем они столько раз выкатывают.Это не сразу понятно, потому что термин Сontinuous Integration был девальвирован.
Но вот как раз здесь вы видите настоящий continuous в его оригинальном значении на английском языке — «непрерывный».
Нет никаких агрегаций фич/багфиксов в версию. Нет простоев на тестирование.
Все вытекает из под пера художника сразу в продакшен.
Continuous!
Sign up to leave a comment.
Руководство для чайников: создание цепочек DevOps с помощью инструментов с открытым исходным кодом