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 : дашборды