Комментарии 25
Проходили похожий путь и поверьте использование готового специализированногл софта в разы дешевле, т.к. не нужно еще и велосипед изобретать и чинить его.
Есть разного уровня решения.
Для сборки Jenkins.
Для разворачивания его же можно использовать или Rundeck, Ansible, Puppet etc
Не поленитесь потратить немного времени и оно вернется десятикратно
Почитал комментарии, и понимаю что да, костыльное решение получилось. Могу сказать, что поскольку никто не знал как правильно — делали как умеем.
Я так понимаю, что у вас была такая же ситуация (проходили похожий путь).
К чему вы все же пришли, к какому стеку?
Я склоняюсь пока к варианту поднять Jenkins, и делать что-то вроде:
1) Jenkins из jenkinsfile собирает на той же машине, где запущен jenkins билд — это jar файл.
2) Дальше jar файл копируется на целевую машину
3) Каким-то скриптом убиваем старый процесс, запускаем новый.
Пока до конца не понимаю, зачем использовать ansible, например, если процесс билда — это mvn package.
Jenkins для сборки пакетов или Docker контейнеров, которые кладутся в соответствующие репозитории.
Для деплоймента использовали Rubdeck и Ansible. В результате сейчас для всего используется Jenkins + Git + Helm, но не от хорошей жизни, а отсутствия ресурсов. Все таки деплоймент должен выполняться предназначенным для этого софтом, который знает топологию и умеет работать с инфраструктурой.
остановить сервис
положить файл
запустить сервис
3) напишите systemd юнит для вашего софта
Я еще могу понять — самописный деплой, но самописный билд? Ненене.
Понимаю, о чем вы. Стоял выбор между совсем не автоматизировать, и автоматизировать хоть как-то — никто не умел делать это правильно. Выбрали такой вариант.
Ну и можно не поддерживать. То есть, в крайнем случаем откатиться нужно до ручной сборки, заходя по SSH на сервер, но больше ничего не поломается.
Личто я писал скрипт, который с моего компа цеплялся на указанный хост, используя ключи и конфиги из соответствующего файла параметров. Всё предельно автоматизировано. Корректность запуска проверяется через Exit-коды. Веб-контент — банально через wget/curl/netcat + grep/awk.
Я хорошо знаю Java, и очень базово — bash. Выбрал инструмент, на котором смог сделать решение. Согласен с вами, что исключительно bash + утилиты получше решение, по крайней мере с точки зрения потребляемых ресурсов.
Человек выше правильно указал, и могу добавить — на Linux-серверах утилитарного типа JVM есть крайне редко. Оно там просто не нужно, а ресурсов потребляет как не в себя.
Её ставят только в случае крайней необходимости ввиду очень специфического софта.
А на десктопах — практически только из-за LibreOffice (когда им уже руки подкручивают).
Так что ставить себе в достоинство использование этого прекрасного в своей сфере фотоаппарата как инструмент для забивания гвоздей — идея так себе.
Недавно заменил 250 строк кода на 30 с тем же функционалом и большей отказоустойчивость.
А что происходит когда Ваше приложение падает, чисто гипотетически?
Какой-то мониторинг используете?
Я бы поставил подман, собирал софт в контейнерах с помощью зеркала на гитлабе (бесплатный приватный репо есть у гитхаба и гитлаба), с его gitlab ci (бесплатно 1000 часов, если мало в контейнере запустить бы свой ранер), пушил в приватный репо докерхаба. Потом ансибл раскатывал на сервера. В гитлаб ci сделал пайплайн по расписанию для проверки работы стенда и его перезапуска. Ну и супервизоров получилось бы 2, первый это conman от подмана, второй это системд. Ну и не забудем что у контейнеров есть helthcheck'и. На всё про всё 10000 рублей на фрилансера девопса, и он за день сделал бы. Либо можно и самостоятельно запилить за пару дней. Благо всё примитивно делается, баш скрипты режуться на строчки и в докерфайл или yaml для ci. Никаких своих серверов писать не надо.
Конечно недочеты типо "апдейт сервера по любому push без тестов" (и вообще, это что push в maste… ой, я хотел сказать main?) несколько напрягают, но в остальном не вижу ничего плохого в таком подходе.
Изучать ансибл и кучу приблуд к нему или пролистать N десятков строк кода, это ещё вопрос, что будет быстрее и проще. Это к слову о дальнейшей поддержке.
Хотя писать такие скрипты надо тоже с умом, конечно. Если бы все было на баше и с комментариями, наверное, нарм. Но вот с джавой могут быть проблемы, если обслуживанием инфраструктуры начнёт заниматься человек, который занимается этим профессионально, а не программист.
После программистов, да, периодически приходилось переделывать.
С одним даже крепко спорил насчет баша. Он уверял, что баш это прошлое и не нужен, а все скрипты надо на питоне писать, ибо там все структурированно, с exceptionaми, raiseми и т.д.
Но при этом не люблю и другую крайность, когда в стойке два средних сервера и под них накручены ансибл, дженкинс, и ещё парочка модных приложух. В каждом сервере виртуалки и в виртуалках контейнеры. В контейнерах вся дата гвоздями к локальным папкам прибита, ip чуть ли не статические и образа крутятся уже пару лет без изменений, с периодическими падениями из-за этого и перезагрузками (иногда ручными).
Зато модно и молодежно.
ЗЫ jenkins это вообще crontab с gui. Почему-то админимить сервера с gnome не втыкая в командную строку — это моветон, а использовать jenkins вместо crontab — это быть в курсе современных технологий.
Как я автоматизировал разворачивание приложений на Linux на коленке с помощью Bash скриптов и Java