|
||
---|---|---|
static | ||
templates | ||
.drone.yml | ||
.gitignore | ||
app.py | ||
boards.py | ||
Dockerfile | ||
README.md | ||
reqs.txt | ||
threads_with_posts.py | ||
threads.py | ||
todo.py |
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 отсылает запрос в куб. Там ингресс закидывает его на деплоймент соответственно доменному имени и после отвечают свободные поды. Когда надо, поды ходят в постгрес и минио.
stateDiagram-v2
state USER
state inet <<join>>
state Nginx
user --> inet : internet
inet --> Nginx : router
state Kube {
NginxIngress
lbServiceMaster
lbServiceDev
state DeploymentMaster {
state "app" as p1
state "app" as p2
}
state DeploymentDev {
state "app" as p1d
state "app" as p2d
}
}
Nginx --> NginxIngress : *.board.vdk2ch.ru, www.vdk2ch.ru
NginxIngress --> lbServiceMaster : master.board.vdk2ch.ru
NginxIngress --> lbServiceDev : dev.board.vdk2ch.ru
lbServiceMaster --> DeploymentMaster
lbServiceMaster --> DeploymentMaster
lbServiceDev --> DeploymentDev
lbServiceDev --> DeploymentDev
state Minio
state Postgresql
state all_join <<join>>
p1 --> all_join
p2 --> all_join
p1d --> all_join
p2d --> all_join
all_join --> Postgres : данные с БД
all_join --> Minio : статика
Логика деплоя в куб по коммиту
Да просто триггерим дев- или мастер-пайплайн, далее дрон локально собирает актуальный докер-образ и обновляет его версию в деплойменте куба.
stateDiagram-v2
committer --> Git
Git --> Drone
state "pipeline-${branch}" as pm {
Runner --> Docker : create ${branch} image with new files
Docker --> Kube : ${branch} deploy with new image
}
state branch_fork <<fork>>
Drone --> branch_fork : ветка репо
branch_fork --> pm
Общая схема отдельного приложения
Логика работы локально идентична с кубом - получаем реквест и пытаемся обслужить с базы и минио.
stateDiagram-v2
User
state inet <<fork>>
User --> inet : дайте борду, запишу свои посты, картинки итд
state Flask {
hmtx : htmx templates
static_files : flask static
}
inet --> Flask
Flask --> Postgres : посты
Flask --> Minio : картинки и шебм
Логика работы мониторинга
Да, собственно, собираем логи в локи, а метрики в пром, далее дефолтным путём получаем алерты и дашборды. Внутри куба поды смотрятся на лайфнесс, рединесс и т.д., чтобы нормально отслеживать деплои.
stateDiagram-v2
App
state enter_monitoring <<fork>>
App --> Kube : liveness, readiness probes
App --> enter_monitoring
enter_monitoring --> Prometheus : metrics
Prometheus --> Grafana
enter_monitoring --> Loki : logs
Loki --> Grafana
state admini {
User : Наш слон
}
Prometheus --> Alertmanager
Loki --> Alertmanager
state alerts_join <<join>>
state dash_join <<join>>
Alertmanager --> alerts_join
Grafana --> alerts_join
alerts_join --> User : алерты
Grafana --> dash_join
dash_join --> User : дашборды