Go to file
Simple_Not 3e935e4d1b
All checks were successful
continuous-integration/drone/push Build is passing
check posts
2023-07-13 20:13:33 +10:00
static check posts 2023-07-13 20:03:01 +10:00
templates check posts 2023-07-13 20:13:33 +10:00
.drone.yml kube 2023-07-02 01:05:11 +10:00
.gitignore favicon 2023-07-03 23:54:26 +10:00
app.py check posts 2023-07-13 19:57:40 +10:00
boards.py some structure 2023-07-03 22:58:08 +10:00
Dockerfile annother hexxo 2023-07-12 01:57:15 +10:00
README.md asdf 2023-07-01 22:30:06 +10:00
reqs.txt annother hexxo 2023-07-12 01:57:15 +10:00
threads_with_posts.py annother hexxo 2023-07-12 02:14:07 +10:00
threads.py some structure 2023-07-03 23:18:37 +10:00
todo.py Now this is a TODO APP !!! 2023-07-01 22:41:34 +10:00

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

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