vdk2ch/flask-htmx-board1
5
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

not yet

Browse Source
This commit is contained in:
Simple_Not 2023-07-01 21:36:45 +10:00
parent ba26ae8fda
commit 8391536996
1 changed files with 36 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
README.md
View File

@ -1,5 +1,6 @@
# Table of Contents # Table of Contents
1. [Локальная сборка и запуск ](#локальная-сборка-и-запуск)
1. [Логика доступа к контенту ](#логика-доступа-к-контенту) 1. [Логика доступа к контенту ](#логика-доступа-к-контенту)
1. [Логика деплоя в куб по коммиту ](#логика-деплоя-в-куб-по-коммиту) 1. [Логика деплоя в куб по коммиту ](#логика-деплоя-в-куб-по-коммиту)
1. [Общая схема отдельного приложения](#логика-деплоя-в-куб-по-коммиту) 1. [Общая схема отдельного приложения](#логика-деплоя-в-куб-по-коммиту)
@ -12,6 +13,33 @@
Далее возможно добавление в схему волта Далее возможно добавление в схему волта
Также нужна будет схема федерализации борд
----
## Локальная сборка и запуск
[наверх](#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
```
---- ----
## Логика доступа к контенту ## Логика доступа к контенту
@ -82,6 +110,7 @@ stateDiagram-v2
## Логика деплоя в куб по коммиту ## Логика деплоя в куб по коммиту
[наверх](#table-of-contents) [наверх](#table-of-contents)
Да просто триггерим дев- или мастер-пайплайн, дрон далее локально собирает докер-образ актуальный и обновляет его версию в деплойменте куба.
```mermaid ```mermaid
stateDiagram-v2 stateDiagram-v2
@ -111,6 +140,7 @@ stateDiagram-v2
## Общая схема отдельного приложения ## Общая схема отдельного приложения
[наверх](#table-of-contents) [наверх](#table-of-contents)
Логика работы идентичная локально и в кубе: получаем реквест и пытаемся обслужить с базы и минио.
```mermaid ```mermaid
stateDiagram-v2 stateDiagram-v2
@ -141,6 +171,10 @@ stateDiagram-v2
## Логика работы мониторинга ## Логика работы мониторинга
[наверх](#table-of-contents) [наверх](#table-of-contents)
Да собственно собираем логи в локи, а метрики в пром, далее дефолтным путём получаем алерты и дашборды. Внутри куба поды смотрятся на лайфнесс, рединесс, итд чтобы нормально отслеживать деплои.
```mermaid ```mermaid
stateDiagram-v2 stateDiagram-v2
@ -148,6 +182,8 @@ stateDiagram-v2
state enter_monitoring <<fork>> state enter_monitoring <<fork>>
App --> Kube : liveness, readiness probes
App --> enter_monitoring App --> enter_monitoring
enter_monitoring --> Prometheus : metrics enter_monitoring --> Prometheus : metrics