Table of Contents
- Локальная сборка и запуск
- Логика доступа к контенту
- Логика деплоя в куб по коммиту
- Общая схема отдельного приложения
- Логика работы мониторинга
Вообще, суть такова:
Мы берём фласк, кидаем в докер-образ, далее контейнер педалим в кубернетес в деплоймент, соответствующий ветке (мастер/дев) с 2-3 подами на деплоймент. Всё это должен уметь делать CI/CD
Далее возможно добавление в схему волта
Также нужна будет схема федерализации борд
Локальная сборка и запуск
Запуск элементарный. Единственный момент - нужно предварительно заполнить локальный файл с переменными где лежат пароли, хосты, и т.д. Локальный запуск независим от деплойментов.
git clone https://git.vdk2ch.ru/vdk2ch/flask-htmx-board1.git
cd flask-htmx-board1
# если нужна виртуальная среда
python -m venv venv
## линус
. ./venv/bin/activate
## вин
./venv/Scripts/Activate.ps1
# ставим зависимости
pip install -r reqs.txt
# запускаем приложение
python app.py
Логика доступа к контенту
Попадаем на сервер, где nginx отсылает запрос в куб. Там ингресс закидывает его на деплоймент соответственно доменному имени и после отвечают свободные поды. Когда надо, поды ходят в постгрес и минио.
Логика деплоя в куб по коммиту
Да просто триггерим дев- или мастер-пайплайн, далее дрон локально собирает актуальный докер-образ и обновляет его версию в деплойменте куба.
Общая схема отдельного приложения
Логика работы локально идентична с кубом - получаем реквест и пытаемся обслужить с базы и минио.
Логика работы мониторинга
Да, собственно, собираем логи в локи, а метрики в пром, далее дефолтным путём получаем алерты и дашборды. Внутри куба поды смотрятся на лайфнесс, рединесс и т.д., чтобы нормально отслеживать деплои.