System administration
Programming
Java
Server Administration
DevOps
Comments 13
+2
А стандартный скрипт nexus имел какие-нибудь проблемы при его запуске?
+1
Стандартный скрипт вполне рабочий, но без изучения его внутренностей непонятно, что именно он делает, как его настраивать, и т.п.
+1
А можно узнать, зачем вам это?

Не, я не имею ничего против описанного подхода, более того, сам нечто подобное (хотя и не совсем такое) применял, но просто из интереса — нафига изучать внутренности запуска nexus, который (в моей практике) не требует тюнинга, т.е. по сути — того самого изучения?
0

Какой-то тюнинг все равно нужен. Например, настроить пути, добавить пару опций для мониторинга (JMX, -javaagent) и т.п. Гораздо проще все это сделать напрямую.


Буквально вчера заметил небольшую проблемку, связанную с java.net.preferIPv4Stack=true. Все, что мне нужно было сделать для ее решения, — поменять одну строчку в скрипте. В случае стандартного скрипта (см. фрагмент) пришлось бы задавать для скрипта дополнительную переменную среды KARAF_OPTS. А где ее задавать? В еще одном скрипте? Вот так и получается целая луковица скриптов для решения одной маленькой задачи.


Отсюда и возникает мотивация к упрощению.

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

Кстати, то что вы показали — стандартные скрипты карафа. И да, KARAF_OPTS задается в другом скрипте, но луковицы там нет — там всего два уровня, и это вполне логично, потому что у карафа один общий скрипт используется скажем для запуска и останова сервера, а также и для запуска клиента. И при этом понятно, что для старта вы например задаете -Xmx<много памяти>, а для останова и для клиента (который просто ssh) это излишне.

В общем, опять же — ничего против базовой идеи (я как-то по аналогичной причине переписывал порядка 600-800 строк шелла на groovy, и сократил их в итоге вдвое, заодно получив больше гибкости), хотя пример с нексусом не очень убедительный.
0
Извините, я — не Java-разработчик и не понимаю, например, специфики Karaf'а. Может быть, поэтому что-то в моём примере не выглядит убедительным. В принципе, это и не важно.

Если смотреть в целом, то идея даже не в переписывании имеющихся скриптов — это нудное занятие, а в том, чтобы минимизировать и упрощать деплоймент, подстраивая его под конкретную ситуацию вместо использования универсальных bootstrap/startup-скриптов.
0
>В принципе, это и не важно.

Извиняться тут совершенно не за что. Просто мне кажется, что если уж вы пытаетесь логику упростить — понимать специфику желательно. Я это к тому, что попытавшись выяснить, что там за движок внутри, и почитав документацию по карафу, можно добиться большего, чем пытаясь понять код на шелле — вообще не самом удобном для этого языке.
0
Я верно вас понял, статья о том, что для удобоваримости надо юзать systemd? Кажется, если это так, то много текста.
0
А вы статью прочитали? Если да, то что осталось непонятным?
0

К сожалению, да. Всю статью можно ужать до "если вас парит, когда с софтом идёт 100500 шельников, выкиньте лишнее, остальное заверните в systemd, уныло, хабр скатывается.

+3
А, ну так вы всё уже и без меня знаете. Так это же здорово! Статья как раз и написана для того, чтобы тех, кто это понимает, стало больше.

А те, кто уже всё понял, могут, например, заняться улучшением качества деплоймент-процессов в opensource-проектах. Потому как на сегодняшний день они зачастую сильно усложнены.
Only those users with full accounts are able to leave comments., please.