https://github.com/halo-lab/hades
Halo deployments
https://github.com/halo-lab/hades
Last synced: 5 months ago
JSON representation
Halo deployments
- Host: GitHub
- URL: https://github.com/halo-lab/hades
- Owner: Halo-Lab
- Created: 2022-11-02T14:55:56.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2022-11-04T13:42:21.000Z (over 3 years ago)
- Last Synced: 2025-07-31T04:44:58.981Z (11 months ago)
- Size: 2.93 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: readme.md
Awesome Lists containing this project
README
# Проект "Hades" (Halo deployments), draft
## Цели
Создать централизованный инструментарий для деплоя и мониторинга студийных проектов (либо найти и адаптировать существующее OpenSource-решение). В качестве «точки отсчёта» можно использовать [CapRover](https://www.notion.so/halolab/Staging-deploy-with-CapRover-356a654b5d774a4ab0e8d9ee343fdbb3), развёрнутый на Halo staging.
## Требования к системе
Общее видение системы: бэкенд (с внутренней базой), выставляющий наружу API; а также UI-dashboard для удобства работы с ресурсами. На первой фазе вместо визуального дашборда можно реализовать «общение» с бэкендом проекта через CLI. В дальнейшем, оба варианта (UI и CLI) могут существовать и развиваться параллельно. Также можно рассмотреть возможность реализации console-based UI (например см. утилиту `htop`). Система должна максимально простым образом разворачиваться на linux-сервере.
Поддержка возможности деплоя как минимум в AWS (static deploy on S3, EC2, RDS, ElastiCache) и на выделенные сервера (в докер-контейнерах, по аналогии с CapRover). В идеале ещё и в аналогичные AWS'овским под-сервисы DigitalOcean и Azure.
Реквизиты доступа к облачным аккаунтам / серверам могут добавляться во write-only режиме, шифроваться на сервере и храниться во внутренней БД проекта в зашифрованном виде.
Источником файлов для деплоя могут быть GitHub, либо вручную загружаемый архив. В случае с GitHub необходимо реализовать поддержку опционального авто-деплоя при детекте изменений в определённой ветке (через вебхуки); но и деплой вручную должен быть доступен (по аналогии с CapRover).
Для серверов проектов должна быть доступна удобная модификация переменных окружения, а также лёгкий доступ в ssh-консоль.
Сбор и централизованное отображение метрик серверов и логов деплойментов/сервисов (здесь большое поле для рисёрча существующих инструментов/библиотек). Важен осмысленный и быстрый поиск по логам, а также поддержка отправки алертов (почта / слак) при достижении метриками заданных пороговых значений.
Критично важно создать систему пользователей с разграничениями прав (и соответствующий инструментарий для управления пользователями). Изначально можно ориентироваться на то, что регулировка доступа необходима будет на уровне отдельных проектов, а также на уровне read-write / read-only (т.е. доступ к потенциально деструктивным действиям вроде деплоя проекта / доступ только к просмотрам логов и метрик).
## Задачи
### 1 — Прототип деплоя по SSH
Собрать небольшой прототип (по сути, несколько запускаемых скриптов), позволяющих на старте указать (пока что в виде открытого конфиг-файла — это совершенно не секьюрно, но на этапе прототипа допустимо):
- публично доступный URL GitHub-проекта (далее GHP)
- параметры коннекта (адрес, имя пользователя, пароль/ключ) к удалённому SSH-серверу для сборки (Build Server — далее BS)
- параметры коннекта (адрес, имя пользователя, пароль/ключ) к удалённому SSH-серверу для деплоя (Deployment Server — далее DS; может совпадать с BS, может отличаться)
- переменные окружения со значениями
Скрипт должен вытащить GHP из гитхаба на BS, собрать докер-образ по инструкциям в докерфайле внутри GHP (можно добавить GHP-конфиг по аналогии с капровером), запустить докерфайл на DS, пробросив необходимые порты наружу (порты могут настраиваться из GHP-конфига). Важно предоставить docker-контейнеру переменные окружения как на этапе сборки, так и на этапе запуска (это часто нужно для Next.js-проектов, например).
В качестве примера GHP можно использовать Next.js-стартер, запускаемый в контейнере в режиме веб-сервера.
Язык, используемый для написания прототипа, можно выбирать произвольно (с учётом задач): от shell-скриптов до программы на Go; но важно учитывать, что далее это решение необходимо будет интегрировать в более массивный продукт, описанный в разделе «Требования к системе» выше.
На этом этапе необходимо также провести рисёрч на тему того, как удобнее будет работать с BS и DS: в режиме SSH-команд, или в режиме дополнительного устанавливаемого на сервер модуля, обслуживающего внешние запросы через открытый порт, например. Второй вариант может быть удобнее в контроле, но будет дольше в реализации; плюс здесь необходимо подумать про безопасность. Также имеет смысл провести исследование существующих продуктов, позволяющих удалённо управлять *nix-сервером.