Комментарии 13
т.е., не нужно забивать гвозди молотком
Микроскопом что ли?
Не, я не имею ничего против описанного подхода, более того, сам нечто подобное (хотя и не совсем такое) применял, но просто из интереса — нафига изучать внутренности запуска nexus, который (в моей практике) не требует тюнинга, т.е. по сути — того самого изучения?
Какой-то тюнинг все равно нужен. Например, настроить пути, добавить пару опций для мониторинга (JMX, -javaagent) и т.п. Гораздо проще все это сделать напрямую.
Буквально вчера заметил небольшую проблемку, связанную с java.net.preferIPv4Stack=true. Все, что мне нужно было сделать для ее решения, — поменять одну строчку в скрипте. В случае стандартного скрипта (см. фрагмент) пришлось бы задавать для скрипта дополнительную переменную среды KARAF_OPTS. А где ее задавать? В еще одном скрипте? Вот так и получается целая луковица скриптов для решения одной маленькой задачи.
Отсюда и возникает мотивация к упрощению.
Кстати, то что вы показали — стандартные скрипты карафа. И да, KARAF_OPTS задается в другом скрипте, но луковицы там нет — там всего два уровня, и это вполне логично, потому что у карафа один общий скрипт используется скажем для запуска и останова сервера, а также и для запуска клиента. И при этом понятно, что для старта вы например задаете -Xmx<много памяти>, а для останова и для клиента (который просто ssh) это излишне.
В общем, опять же — ничего против базовой идеи (я как-то по аналогичной причине переписывал порядка 600-800 строк шелла на groovy, и сократил их в итоге вдвое, заодно получив больше гибкости), хотя пример с нексусом не очень убедительный.
Если смотреть в целом, то идея даже не в переписывании имеющихся скриптов — это нудное занятие, а в том, чтобы минимизировать и упрощать деплоймент, подстраивая его под конкретную ситуацию вместо использования универсальных bootstrap/startup-скриптов.
Извиняться тут совершенно не за что. Просто мне кажется, что если уж вы пытаетесь логику упростить — понимать специфику желательно. Я это к тому, что попытавшись выяснить, что там за движок внутри, и почитав документацию по карафу, можно добиться большего, чем пытаясь понять код на шелле — вообще не самом удобном для этого языке.
К сожалению, да. Всю статью можно ужать до "если вас парит, когда с софтом идёт 100500 шельников, выкиньте лишнее, остальное заверните в systemd, уныло, хабр скатывается.
А те, кто уже всё понял, могут, например, заняться улучшением качества деплоймент-процессов в opensource-проектах. Потому как на сегодняшний день они зачастую сильно усложнены.
Как сделать простым и понятным запуск Java-процессов в Linux / Docker