Comments 7
Интересно, давно искал подобный механизм, мы на своих проектах использовали самописный сборщик, который хранил приватный ключ, чтобы избежать его утечки из репозитория. Есть подобный механизм деплоя для gitlab?
В тексте написано: вместо использования статических паролей или ключей CI-платформа (GitHub Actions или GitLab CI)...
Если я правильно понимаю, то работает с GitHub и GitLab, хотя, могу и ошибаться.
Привет! Да, GitLab CI поддерживается: там стандартный OIDC через id_tokens. В репозитории есть готовый include-шаблон gitlab/deploy.yml (job .cd-deploy, достаточно сделать extends), а клиент deploy.sh сам подхватывает токен из CD_ID_TOKEN.
На сервере проект добавляется с флагом --gitlab, а для self-hosted GitLab с --issuer https://gitlab.example.com. Проверка токена та же, что и для GitHub, но правила строятся по GitLab-claims: project_path, ref и ref_protected. Поэтому ветка, с которой идёт деплой, должна быть защищённой.
Честно уточню по практике: каждый день я гоняю cd на проектах с GitHub Actions. Ветка GitLab покрыта unit-тестами на правила claims, но на реальном инстансе GitLab я её ещё не прогонял, так что боевого опыта именно там пока нет.
Репозиторий: https://github.com/Dmitry-Fedotov-Dev/cd. Если попробуете на GitLab и упрётесь в нюансы с claims или конфигом, пишите в Issues, поправлю.
Пока не до конца понял, почему нельзя было использовать готовые механизмы. Хоть поставить gitlab-runner на VPS, и пусть он там деплоит. Работает без SSH-ключей и без рута.
Надо запретить разработчикам доступ к произвольному запуску команд? Делаете custom executor. И ни девелопер, ни даже овнер проекта не смогут на проде запустить ничего лишнего.
Ну и дополнительно:
1. Собирать проекты на проде я бы не стал. Во-первых, любой, даже самый докер-ограниченный чрут со всеми сигруппами и сброшенными capabilities, может положить систему. Во вторых, из чрутов иногда вырываются. И лучше, если это всё случается не на проде. В третьих, если сам прод сломают, то сразу попадают в ваш там же находящийся дев-контур со всеми исходниками и возможностью подкинуть чего-нибудь интересного в сборку.
2. Пуш на прод мне видится не самой классной идеей. Это всегда лишняя плоскость атаки. А в вашем случае с демонком от рута, да ещё и слушающим http, плоскость атаки выглядит весьма широкой. Всё это конечно чуть-чуть заизолировано в systemd и т.д., но даже без учета фактического рута конструкция выглядит очень хрупкой с точки зрения долговременной поддержки.
Спасибо за развёрнутый разбор! Со сборкой согласен: ей место в CI, а не в CD (это поправимо).
Сам проект cd решает конкретную задачу: нужен был лёгкий и простой механизм деплоя личных GitHub-проектов (pet-проектов, проверки бизнес-гипотез) на прод, с изоляцией, чтобы проекты не мешали друг другу. Без лишних зависимостей и нетребовательный к ресурсам, чтобы не душить и без того слабенький VPS на самом дешёвом тарифе.
По сути это аналог custom executor для GitHub: там такого механизма нет, а self-hosted runner выполняет то, что написано в workflow репозитория. В cd же что и как запускать решает сервер, а репозиторий может только запросить деплой своего проекта.
Про root-демон согласен, это слабое место. cdd слушает только localhost за обратным прокси, а без валидного токена дальше проверки JWT запрос не проходит, но это осознанный компромисс для моего масштаба.
Можно долго не останавливать старую версию, поднять новую, прогнать health-check и smoke-тесты, а затем переключить трафик. После переключения несколько минут сравнивать показатели с предыдущим релизом: latency, HTTP 5xx, потребление CPU/RAM.
Если показатели деградируют — автоматически вернуть трафик на старый контейнер, который всё это время остаётся запущенным.
Деплой на VPS по push без SSH-ключей в CI: архитектура cd, механика OIDC и границы применимости