# 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 <> 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 <> 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 <> Drone --> branch_fork : ветка репо branch_fork --> pm ``` ---- ## Общая схема отдельного приложения [наверх](#table-of-contents) Логика работы локально идентична с кубом - получаем реквест и пытаемся обслужить с базы и минио. ```mermaid stateDiagram-v2 User state inet <> 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 <> 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 --> Alertmanagerg state alerts_join <> state dash_join <> Alertmanager --> alerts_join Grafana --> alerts_join alerts_join --> User : алерты Grafana --> dash_join dash_join --> User : дашборды ```