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

Выкатку описать в Ansible и сконфигурировать запуск плейбука из gitlab ci.

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

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

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

Конечно есть.

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

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

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

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

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

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

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

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

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

Приложения в отдельных репах или в одном?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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