LINUX.ORG.RU

CI/CD для маленьких приложений

 , , ,


0

2

Здравствуйте!

Появилась необходимость сделать процесс доставки кода для выполнения на сервер удобнее. Сейчас это выглядит так - есть 35-40 маленьких приложений на python, которые доставляются на сервер через внутренний gitlab. То есть, кто-то пишет код, пушит на гитлаб, после этого вручную на сервере клонируется и создается systemd сервис, закидывающийся в крон. В общем при нескольких приложениях проблем особо нет, но уже начинается бардак. Подскажите, пожалуйста, какой правильный концепт доставки кода на выполнение на сервер в данном случае? Как выглядит концепция автоматизации? Чтобы разработчик, грубо говоря, совершил пару действий и код успешно запустился на сервере? Заранее благодарен за ответы!

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

Спасибо большое за ответ!

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

А нет смысла это все в докер заворачивать для удобства? В любом случае venv конфигурируется под каждый апп, либо делать очень раздутую общую библиотеку на весь сервер…

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

А как тогда и где должен происходить процесс сборки контейнера и его доставка? Как цепочка правильно выглядет, чтобы попробовать можно было? С плейбуками уже играюсь, хочется каждый вариант попробовать. Заранее спасибо?

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

разработчик с сайта гитлаба просто запускает нужный плейбук

В интерфейсе гитлаба 40 вариантов действия «деплой» станут кашей. Если есть причины не обновлять всё и сразу, может лучше завести релизную ветку и мерджить в ней только то, что собираешься деплоить, а все приложения с этой ветки деплоить одним действием, без вариантов. Или я не так понял идею?

manntes-live ★★★
()
Ответ на: комментарий от DevQwertoff

То есть сделать два плейбука, как я понимаю?

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

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

С гитлаба обычно не вручную запускают а настраивают триггер на событие, на merge в мастер например.

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

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

Думаю, что так. То есть лучше просто добавлять в пакет новые приложения и каждый раз просто «перезакидывать» мастера всех аппов на сервер? А запуск как-то можно удобнее реализовать нежели создание сервисов systemd? И как им можно управлять? Большинство приложений - парсеры, которые иногда нужно перезапускать вручную. Спасибо!

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

Спасибо! То есть триггер на мердж или пуш в мастер, к примеру, запустит плейбук, который создаст или обновит приложение? Тот же вопрос - а как само приложение разворачивать удобнее, нежели через сервисы? Есть какие-то более практичные варианты?

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

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

Я бы сделала один плейбук параметризованный именем приложения. То есть при запуске с параметром NAME, он брал репу gitlab..NAME.git, копировал её в /opt/NAME, создавал сервис NAME-service, рестартовал этот сервис в конце.

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

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

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

В отдельных репах

Лучше так и оставить тогда. 40 реп + отдельная репа для универсальных плейбуков, что бы всё работало одинаково для всех.

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

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

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

А сборка контейнера как и где должна происходить и доставляться на сервер? Также в плейбуке по мерджу, как вариант, формировать новый контейнер, заменяя старый?

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

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

Если гитлаб-си используешь, то всё на хосте где гитлаб-раннер запущен, конечно.

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

Не понял вопрос.

manntes-live ★★★
()
Ответ на: комментарий от DevQwertoff

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

Если у вас 40 однородных питон-приложений, которым не нужно ни масштабирование ни особое управление и они умещаются на одном стандартном сервере не конфликтуя друг с другом, то автоматизации на базе ansible вам хватит с головой.

Если нужно развиваться, то да, лучше смотреть сразу в сторону kubernetes, и может быть даже serverless варианта. Но это имеет смысл, когда одного сервера станет не хватать.

alpha ★★★★★
()

CI на гитлабе (для каждого приложения):
1. Паковать нужные файлы в отдельный контейнер
2. Сохранять конетейнеры в GitLab или другой приватный registry.

3a. Дополнительная job-а в CI, которая
* обновляет имя используемого контейнера в конфигурационном файле на каждом сервере
* с помощью Ansible загружает новую версию контейнера на сервера (для ускорения первого старта)
4a. На верверах сконфигурированный systemd юнит, который читает имя контейнера (и другие необходимые для запуска параметры) из конфигурационно файла.
5a. Дополнительная джоба, которая через Ansible рестартует systemd юниты, чтобы они «подхватили» новое имя контейнера

3b. Если есть ресурсы на развертывание k8s кластера, то лучше пользоваться интеграцией GitLab и k8s для деплоя.

trex6 ★★★★★
()

Используйте Jenkins. Не знаю как с гитлаб, а для гитхаба есть плагины позволяющие запускать job по событию push commit.

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