215 lines
5.8 KiB
Markdown
215 lines
5.8 KiB
Markdown
|
||
# Table of Contents
|
||
1. [Локальная сборка и запуск ](#локальная-сборка-и-запуск)
|
||
1. [Логика доступа к контенту ](#логика-доступа-к-контенту)
|
||
1. [Логика деплоя в куб по коммиту ](#логика-деплоя-в-куб-по-коммиту)
|
||
1. [Общая схема отдельного приложения](#логика-деплоя-в-куб-по-коммиту)
|
||
1. [Логика работы мониторинга](#логика-работы-мониторинга)
|
||
|
||
|
||
Вообще суть такова:
|
||
|
||
Мы берём фласк, кидаем в контейнер, далее контейнер педалим в кубернетес в деплоймент соответствующий ветке (мастер/дев) с 2-3 подами на деплоймент, всё это должен уметь делать CI/CD
|
||
|
||
Далее возможно добавление в схему волта
|
||
|
||
Также нужна будет схема федерализации борд
|
||
|
||
----
|
||
## Локальная сборка и запуск
|
||
[наверх](#table-of-contents)
|
||
|
||
Запуск элементарный, с единственным моментом - нужно предварительно заполнить локальный файл с переменными где лежат пароли, хосты, итд.
|
||
Локальный запуск независим от деплойментов.
|
||
|
||
```shell
|
||
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
|
||
```
|
||
|
||
----
|
||
|
||
## Логика доступа к контенту
|
||
[наверх](#table-of-contents)
|
||
|
||
Попадаем на сервер, nginx отправляет в куб. Там ингресс закидывает на деплоймент соответственно доменному имени. Из деплоймента отвечают свободные поды. Поды ходят в постгрес и минио когда надо.
|
||
|
||
|
||
```mermaid
|
||
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 : статика
|
||
|
||
```
|
||
|
||
----
|
||
|
||
## Логика деплоя в куб по коммиту
|
||
[наверх](#table-of-contents)
|
||
|
||
Да просто триггерим дев- или мастер-пайплайн, дрон далее локально собирает докер-образ актуальный и обновляет его версию в деплойменте куба.
|
||
|
||
```mermaid
|
||
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
|
||
|
||
```
|
||
|
||
----
|
||
|
||
## Общая схема отдельного приложения
|
||
[наверх](#table-of-contents)
|
||
|
||
Логика работы идентичная локально и в кубе: получаем реквест и пытаемся обслужить с базы и минио.
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
|
||
|
||
User
|
||
|
||
state inet <<fork>>
|
||
|
||
User --> inet : дайте борду, запишу свои посты, картинки итд
|
||
|
||
state Flask {
|
||
|
||
hmtx : htmx templates
|
||
static_files : flask static
|
||
|
||
}
|
||
|
||
inet --> Flask
|
||
|
||
Flask --> Postgres : посты
|
||
Flask --> Minio : картинки и шебм
|
||
|
||
```
|
||
|
||
----
|
||
|
||
## Логика работы мониторинга
|
||
[наверх](#table-of-contents)
|
||
|
||
|
||
Да собственно собираем логи в локи, а метрики в пром, далее дефолтным путём получаем алерты и дашборды. Внутри куба поды смотрятся на лайфнесс, рединесс, итд чтобы нормально отслеживать деплои.
|
||
|
||
|
||
```mermaid
|
||
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 : дашборды
|
||
|
||
``` |