LINUX.ORG.RU
ФорумTalks

Java-enterprise

 


4

2

Когда я была маленькая и наивная, пару месяцев назад, я думала что Java-разработка должна быть гораздо более продвинутой в плане организации процессов, инфраструктуры, тестирования, конфигурации, CI/CD и всего такого прочего, чем какой-нибудь там Python. Это же всё-таки не просто так пришел, написал и заработало, а суровый энтерпрайз, без пяти слоев IDE не разберешься.

И раз все Software Architecture-книги, уроки и конференции у O'Reilly всё о том же, о Java, то все классические проблемы должны быть описаны, решены и изложены в учебниках для первокуров.

Я конечно начала что-то подозревать, когда заметила, что рекомендованный Atlassian init-скрипт для Jira делает ни много ни мало killall java. Но с кем не бывает, и в конце концов у нас же теперь есть systemd, который с подобным справляется на раз.

Странно, конечно, что компания производитель серверного ПО не умеет его настраивать и запускать, но может быть это частный случай?

Нет, дорогие друзья, не частный, а вовсе даже самый распространенный.

JFrog, Atlassian, Sonatype или Cloudbees, конторы, которые просто-таки заполонили весь интернет статейками на тему DevOps и CI/CD, и вроде бы являются лидерами в теме, тем не менее производят чуть ли не самые отсталые в плане этого CI/CD продукты. Управление пакетами и сервисами они так и не осилили, а уж про Infrastructure as a Code не слышали вовсе.

И даже прием «include conf.d/*» для организации конфигов, над банальностью которого мы насмехались в соседнем треде, авторам java-приложений абсолютно неведом.

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

Нет в жизни счастья и работающих инструментов, есть только выбор: заплатить за Artifactory и потом писать обертки и утилиты для того чтобы сделать нечто минимально рабочее и встраиваемое в инфраструктуру, при этом без возможности нормального тестирования и разработки(потому что закрытая проприетарщина без нормальных девелоперских лицензий). Или плюнуть и за неделю насочинять artifact-storage на джанге, маленький, но гордый, и развивать уже его.

★★★★★

Последнее исправление: alpha (всего исправлений: 1)

killall java

Сурово. Быдлокод как он есть.

rezedent12 ☆☆☆
()

когда заметила, что рекомендованный Atlassian init-скрипт для Jira делает ни много ни мало killall java.

Нету там такого... хочу пруфов

WindowsXP ★★
()

Или плюнуть и за неделю насочинять artifact-storage на джанге, маленький, но гордый

Выложить его в опенсорс и выкинуть проприетарщиков на мороз.

tailgunner ★★★★★
()

заплатить за Artifactory ... потому что закрытая проприетарщина...

Она же OpenSource вроде всегда была и бесплатная

WindowsXP ★★
()
Последнее исправление: WindowsXP (всего исправлений: 1)

Настоящий промышленный сервер приложений Java запускается и останавливается ручным вводом команды bin/startup.sh bin/shutdown.sh, иногда даже в отдельной screen-сессии. А эти ваши init-скрипты нужны только ленивым пионерам.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от WindowsXP

емнип в той потсавке только голый репозиторий мавена, но чсх работает адекватно, а вот со всеми плюшками - уже за деньги

Deleted
()
Ответ на: комментарий от WindowsXP

В open-source варианте там не продукт а превью pro версии.

Форматы репозиториев кроме maven не поддерживаются, в интерфейсе куча табов с placeholder-ами по типу «а здесь в платной версии вы могли бы увидеть то-то и то-то». Интеграция с дженкинсом не работает и т.д и т.п.

alpha ★★★★★
() автор топика
Ответ на: комментарий от Legioner

в настоящем промышленном сервере приложений UI админа заточен на роботовсо встроенной в моск jvm (да да это про jboss)

Deleted
()
Ответ на: комментарий от Deleted

Там показываются сборки в отдельной вкладке. Диффы между сборками уже опять же не показываются, добро пожаловать в Pro.

alpha ★★★★★
() автор топика
Ответ на: комментарий от Legioner

промышленный сервер

ленивым пионерам.

Не, ну второй раз я на такие рассуждения уже не поведусь :)

alpha ★★★★★
() автор топика
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

Диффы между сборками уже опять же не показываются

Вы определенно что-то не то желаете, мне был нужен one-click maven репозиторий с проксей - артифакторий все для этого предоставляется. Чтобы он мне звонил в полночь на домашний и томным голосом зачитывал диффы между сборками - такое даже после выкуривания покрышек не пожелается.

Deleted
()
Ответ на: комментарий от joy4eg

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

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

Что-то мне подсказывает что в бенке - не сильно важно в ядре или не очень, там везде легаси, безопасники и факапы

Deleted
()

Вы не с той стороны на проблему смотрите. Интерпрайз это не где стопицот приложений на разных ЯП крутятся на одной машине и взаимодействуют между собой. В интерпрайзе у вас есть сервак, и на нем работает jira. Есть другой - на нем крутится конфля. 'killall java' в таком случае никто и не заметит, зачем стараться? А если у вас падает плагин - купите саппорт, он вам все починит. Приложение жрет память как не в себя - купите еще планку памяти. Адовое использование диска - вам пора купить новую схд. Ну и так далее.

alozovskoy ★★★★★
()
Ответ на: комментарий от Deleted

Во-первых, у меня серьезная полноценная инфраструктура, а не какой-то там наколеночный java app, один в чистом поле.

Мне кроме maven нужны pypi, docker, apt, rubygem, git и все остальные форматы.

(Nexus кстати получше в этом плане будет)

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

Что самое интересное Artifactory эти зависимости от дженкинса получает и хранит, для каждой сборки, но показать и сравнить может только в Pro-версии.

alpha ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

зачем стараться?

так вот и я об этом - наколеночные энтерпрайзные поделки..

alpha ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

А если у вас падает плагин - купите саппорт, он вам все починит.

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

CaveRat ★★
()
Ответ на: комментарий от alpha

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

То есть сижу я третий день сочиняю очередной workaround в salt, который позволил бы мне сконфигурировать сервис перед запуском, несмотря на то что авторы приложения не осилили нормально разделить default-конфигурацию приложения от пользовательской конфигурации самого сервера, и тут мне приходит письмо о том как авторы этого приложения предлагают мне за 2000$ поучаствовать в их конференции, где они меня обучат современным практикам configuration management.

alpha ★★★★★
() автор топика

Это всё фигня !

В одно большой компании в продакшене (на винде) в консоли висит Java приложение, с экраном, которое отвечтает за проведение 100% транзакций. И не дай боже, кто то сделает logout :) или «выгонит» пользователя этого сеанса - все транзакции просто останавливаются.

robot12 ★★★★★
()
Ответ на: комментарий от alpha

у меня серьезная полноценная инфраструктура,

Мне кроме maven нужны pypi, docker, apt, rubygem, git и все остальные форматы.

это называется не инфраструктура, а «ад» (не путать с AD)

(Nexus кстати получше в этом плане будет)

с ним надо разок поработать до состояния оргазма, тогда начнешь ценить артифактори

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

непоможет, и да что у вас там за инфрастуруктура если зависимости могут поменяться «просто так» ?

Deleted
()

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

leave ★★★★★
()
Ответ на: комментарий от robot12

Ты щас описал common practice, я так видел один госпроект работающий на весь город. Только там было три консоли, каждая запускала отдельный tomcat.

Deleted
()
Ответ на: комментарий от alpha

у меня серьезная полноценная инфраструктура, а не какой-то там наколеночный java app, один в чистом поле.

Мне кроме maven нужны pypi, docker, apt, rubygem, git и все остальные форматы

нет, это не «серьезная инфраструктура», это кто-то дал слишком много воли разработчикам. Зоопарк технологий в рамках одного крупного проекта - едва ли не худшее, что можно придумать в продуктовой компании. А если это независимые проекты, то лучше их изолировать друг от друга, чтобы никаких вообще точек соприкосновения не было.

leave ★★★★★
()
Ответ на: комментарий от leave

ну вообще я подозреваю сарказм в устах альфа-герлы.

Deleted
()
Ответ на: комментарий от leave

Это не зоопарк технологий, а каждой задаче своя.

Проект - это не только собственно его код, но и инфраструктура для его разработки и тестирования.

Если тебе банально надо в запустить докер-контейнер с приложением на ruby, то apt-реп тебе уже нужен для системных пакетов, которые ставятся на хост и в контейнер. Если тебе надо запустить дженкинс, который запускает на сервере контейнер с приложением, то тебе уже нужен pypi, потому что jenkins-job-builder. И т.д., и т.п.

alpha ★★★★★
() автор топика
Ответ на: комментарий от Deleted

бенке - не сильно важно в ядре или не очень, там везде легаси, безопасники и факапы

давай в пятницу. я могу проинсайдить просто дохера :)

один только компилятор sql в sql написанный на sql чего стоит...

Rastafarra ★★★★
()
Ответ на: комментарий от alpha

то apt-реп тебе уже нужен для системных пакетов, которые ставятся на хост и в контейнер.

1. аа в контейнер ничего не должно ставится

2. для deb пакетов есть кеширующая прокся (для системных пакетов а не своих есесно)

Если тебе надо запустить дженкинс, который запускает на сервере контейнер с приложением, то тебе уже нужен pypi, потому что jenkins-job-builder.

у нас женкинс пускает docker контейнеры без этой хрени, как так?

Deleted
()
Ответ на: комментарий от Rastafarra

один только компилятор sql в sql написанный на sql чего стоит...

это классика, у нас такое (я не в банке работал) тоже было

любой скульщик должен вырастить базу, посадить такую процедуру чтоб в ней никто не разобрался, и построить sql компилятор на sql

Deleted
()
Ответ на: комментарий от Deleted

почему просто так? большой проект, много подпроектов и модулей, некоторые куски могут разрабатываться разными командами, собирается потом всё в кучку и тестируется на stage.

Вроде как самый стандартный use-case.

alpha ★★★★★
() автор топика
Ответ на: комментарий от Deleted

1. аа в контейнер ничего не должно ставится

ну-ну, а image у нас из воздуха собирается и солнечного света?

2. для deb пакетов есть кеширующая прокся (для системных пакетов а не своих есесно)

Разумеется есть. До тех пор пока тебе не потребуется свой пакет пересобрать, потому что версия системного чуть-чуть отличается.

Потом окажется что для deb-пакетов есть 100500 perl-скриптов и aptly.

А должен быть один artifact storage со снапшотами и версионированием.

у нас женкинс пускает docker контейнеры без этой хрени, как так?

Любите настраивать jenkins вручную? Ну есть такое развлечение, да.

alpha ★★★★★
() автор топика
Ответ на: комментарий от alpha

некоторые куски могут разрабатываться разными командами, собирается потом всё в кучку и тестируется на stage.

Вроде как самый стандартный use-case.

стандартный юзкейс - каждый модуль тестировать, и в идеале (сам такого не видел) там все и вылезет

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

Deleted
()
Ответ на: комментарий от alpha

ну-ну, а image у нас из воздуха собирается и солнечного света?

Разумеется есть. До тех пор пока тебе не потребуется свой пакет пересобрать, потому что версия системного чуть-чуть отличается.

Ты уж определись, тебе системные или свои?

А должен быть один artifact storage со снапшотами и версионированием.

Тотже самый что и для мавена?

Любите настраивать jenkins вручную? Ну есть такое развлечение, да.

Ты его что каждый день настраиваешь? Предлагаю что-то менять.

Deleted
()
Ответ на: комментарий от Deleted

а если ничего не тестируется, а потом собирается из снепшотов...

А почему одно исключает другое-то? Есть разного уровня тестирование: есть уровня компонента, есть уровня целого. И бывает когда компонентное пропускает то, что вылезет уже на общем.

diff зависимостей - это просто один из инструментом для работы.

alpha ★★★★★
() автор топика
Ответ на: комментарий от alpha

А почему одно исключает другое-то? Есть разного уровня тестирование: есть уровня компонента, есть уровня целого. И бывает когда компонентное пропускает то, что вылезет уже на общем.

Да да, только вот модульное позволяет сократить частоту когда вся команда расследует, а сборка из релизов - повысить стабильность оной, а коммуникация в команде - узнать что менялось между релизами модуля

в итоге оказывается дифф нужен раз в год и то для мавена и хватает втроенного в ide.

А те кто не может наладить процесс - плятят за остальным фичи.

Deleted
()
Ответ на: комментарий от alpha

А, теперь понятнее стало. Я просто как-то привык, что эта вся обвязка или один раз поднята и как-то работает, или вообще в компании не парятся и пользуют внешние репы.

leave ★★★★★
()
Ответ на: комментарий от Deleted

Ты уж определись, тебе системные или свои?

Мне все.

Когда наливка сервера или сборка контейнера будет падать из-за того что убунтоиды именно в этот момент зеркало обновляют - понадобятся снапшоты системных.

Когда приедет ядро несовместимое с жизнью докера - понадобятся свои.

Тотже самый что и для мавена?

Ну мы же не хотим разводить «зоопарк технологий».

Ты его что каждый день настраиваешь? Предлагаю что-то менять.

когда будет у тебя больше 10 задач в дженкинсе - приходи :)

У меня одних ночных тестов мастер-ветки было больше 70 штук, и поправить в них одну простую переменную окружения...

alpha ★★★★★
() автор топика

killall java

Ныне модно запускать на каждое приложение выделенную виртуалку/сервер. «Если у Вас крутится там что-то еще кроме нашей жиры, не наши проблемы»

ncrmnt ★★★★★
()
Ответ на: комментарий от alpha

Когда наливка сервера или сборка контейнера будет падать из-за того что убунтоиды именно в этот момент зеркало обновляют - понадобятся снапшоты системных.

Когда приедет ядро несовместимое с жизнью докера - понадобятся свои.

Т.е. у вас там и ядро свое?

Ну мы же не хотим разводить «зоопарк технологий».

Тогда сразу требуй чтобы в атрифактори был мейл сервер, веб сайт и тетрис. Маразм требует жертв.

когда будет у тебя больше 10 задач в дженкинсе - приходи :)

У меня одних ночных тестов мастер-ветки было больше 70 штук, и поправить в них одну простую переменную окружения...

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

А заводит ьпо одной задаче на тест - это норкомания.

Deleted
()
Ответ на: комментарий от alpha

Когда наливка сервера или сборка контейнера будет падать из-за того что убунтоиды именно в этот момент зеркало обновляют - понадобятся снапшоты системных.

Ты не на lts, что ли?

Когда приедет ядро несовместимое с жизнью докера - понадобятся свои.

оО Как вообще может внезапно приехать новое ядро?

leave ★★★★★
()
Ответ на: комментарий от Deleted

заводит ьпо одной задаче на тест - это норкомания.

Зависит от теста. Например когда один требует сервера с 8 CPU, а второй с 24, то делать их разными и вешать на слейвы с разными метками - самый логичный вариант.

Вообще у тебя странные аргументы. Конечно можно найти workaround, без этого обойтись, это не использовать, здесь свой костыль средствами IDE реализовать...

Но мы в этом треде вроде как говорим о инструментах для создания удобной инфраструктуры. То есть управляемой, с возможностью смотреть историю изменения конфигов CI-сервиса, и с возможность ревьюить эти изменения, например. И отказываться от этой возможности по причине того что jenkins-job-builder на питоне написан - это как-то бессмысленно.

По-простому я и maven на баше реализую, делов-то :) Но по уму универсальный прокси для разноплановых репозиториев - это могло бы быть удобно и полезно, если бы работало.

alpha ★★★★★
() автор топика
Ответ на: комментарий от alpha

Зависит от теста. Например когда один требует сервера с 8 CPU, а второй с 24, то делать их разными и вешать на слейвы с разными метками - самый логичный вариант.

Логичный вариант - засунуть их в одну задачу - простестировать усе. Единственно ели ночью как ты говоришь - то «протестировать все ночью», а то так можно получить цифру типа: (колво тестов)*(кол во машин). Это конечно повышает ЧСВ, но неудобно в сопровождении, как ты уже заметила.

Вообще у тебя странные аргументы. Конечно можно найти workaround, без этого обойтись, это не использовать, здесь свой костыль средствами IDE реализовать...

У меня аргументы уровня «сделай это проще». А не «хм, 70 тестов, не будем пытать их объединить, давайте инструмент для управления кучей тестов». И в итоге у тебя стопицот технологий и требуется армия админов, а скоро вы еще будете писать свои инструменты для управления всем этим, такиеже кривые как нексус.

Deleted
()
Ответ на: комментарий от Deleted

Логичный вариант - засунуть их в одну задачу - простестировать усе.

Слушай, ну ты сейчас упираешься совсем не в том месте, где надо было бы.

Запихать все тесты в одну задачу и ждать пока оно пройдет последовательно на одном серваке? Это надо 70 ночей.

Наплевать на ресурсы и завести все серваки по 24 CPU? Ну не знаю как у тебя, а у нас железо считают.

Реализовать параллельный запуск на ферму серверов в зависимости от конфигураций теста из одной дженкинс-задачи? А зачем мне тогда дженкинс, если мне его логику писать придётся на уровне тестового фреймворка?

И все это для того чтобы не использовать готовый механизм шаблонов?

И это ты даже не начал ещё думать про code-review для конфигураций этих самых jenkins-задач.

alpha ★★★★★
() автор топика
Последнее исправление: alpha (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.