Ребят, а кто как деплоит приложеньки с гитлаба? Хочу пример

с ансиблом найти..

А как у тебя приложение в прод должно поставляться?

Без докера. Склонировать, собрать, остановить старое, скопировать бинарь, запустить. Все выглядит так, как ансибл, но пока не получается найти подробно как из гитлаб ci запустить плейбук

Можно без ансибла через докер https://habr.com/ru/post/449952/

Надо без докера, но статейку не видел, может чего почерпну,спасибо)

раз без докера, тогда лучше тогда RPM/DEB-пакет собирать

а разница?

спроси у админов ))))) они тебе расскажут

Вот пример с деплоем по SSH без докера и ансибла. https://golangforall.com/ru/post/go-build-and-deploy-ssh-gitlab.html

Собрать RPM (или deb) - это не сложно. Плюсом имеешь быстрое обновление, плюс историю, в которой можешь всегда сделать rollback на нужный шаг.

но отвечая на вопрос: ты можешь поставить, удалить, обновить, задаунгрейдить/откатить приложение средствами ОС банально узнать какая его версия стоит - тоже в пакете (нормального приложения) есть дока, релиз-ноутс ,etc при установке, обновлении, откате выполнить определённые действия в ОС - тоже... и т.п.

+ инфа о том, где оно установлено какие файлы использует (необходимы для работы) не изменено ли оно с момента установки.. на эти вопросы легко получить ответ админу без обращения к разработчику

вот это — ssh -p$SSH_PORT $SSH_USER@$SSH_HOST 'sudo service project stop && cp ~/binary_tmp /var/www/project/binary && sudo service project restart' прям доставляет у меня первый вопрос, откуда на хосте, например, изначально взялся project.service (т.е. /etc/systemd/system/project.service`) файл?

тогда по хорошему надо ещё репу поднимать, верно?

ну, это прям совсем по хорошему, да приложение собирается и релизится в репу (или в артифактори/нексус) и ансиблом(если ансибл) уже деплоится из репы на все хосты (мы же помним, что на проде у нас может быть не один инстанс)

есть некоторая предварительная работа на хосте - там должен появиться systemd (что дефолтно для многих систем, собственно он и использован потому как дефолтный, иначе можно было бы еще в supervisord закопаться). ну и надо создать деплой юзера с sudo правами на перезапуск сервиса.

"прям доставляет" деплой без виртуализации вообще я бы сказал - мне кажется, это огромная редкость и потому там кругом кастомные операции, зависящие от системы. И тот же ансибл у каждого свой. Если на хосте больше 500 мб оперативы - то я бы все же рекомендовал докер. Небольшой оверхед на его работу, но зато все сразу встает на рельсы.

не, про системд всё понятно.. я про файл с описанием сервиса... т.е. с нуля (первый раз) приложение этим скриптом не поставишь.. это - хрень, как по мне )) вредный совет от автора

у меня мейкфайлом системд сервис создается

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

у меня lxc контейнеры под проксмоксом, докер в виртуалке поднимать спецом не хочется

Ну хз)

нуу.. это не значит, что это best practice

и я о том же

согласен, но рпм/деб пакеты также делают)

они это делают стандартным всем админам понятным способом

с одним бинарником как раз удобство в деплое образов FROM scratch, вес которых равен весу бинарника, только есть инфраструктура докера для деплоя

да я не против докера )) я к тому, что не у всех есть докеры/куберы, и приложение на Го вполне себе счастливо может жить без проблем с зависимостями в ОС

Тогда, я бы предпочел выстроить систему деплоя и найти ansible роли (или как оно там называлось), которые по сути сделают тот же деплой. С deb я видел в реализации отдельного деб-репозитория - может потребоваться время. Про плюсы в виде различных версий - не то, чтобы был солюшн решаем только deb-пакетами. При обычном деплое по SSH, можно делать папки с новой версией, старые оставлять (например, 10 последних) и менять только симлинк.

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