Table of Contents

1. Локальная сборка и запуск
2. Логика доступа к контенту
3. Логика деплоя в куб по коммиту
4. Общая схема отдельного приложения
5. Логика работы мониторинга

Вообще, суть такова:

Мы берём фласк, кидаем в докер-образ, далее контейнер педалим в кубернетес в деплоймент, соответствующий ветке (мастер/дев) с 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 отсылает запрос в куб. Там ингресс закидывает его на деплоймент соответственно доменному имени и после отвечают свободные поды. Когда надо, поды ходят в постгрес и минио.

---

Логика деплоя в куб по коммиту

наверх

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

---

Общая схема отдельного приложения

наверх

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

---

Логика работы мониторинга

наверх

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