docs: Update docs for the correctness (#13)
This commit is contained in:
deytenit authored and 
GitHub committed
1 parent
8dba55272c
commit
51a783f93a
60 files changed
+2456
-380
No files matched your search
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Концепции
|
||||
description: Теоретические основы, архитектура и модели безопасности.
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Теоретические основы, архитектура и модели безопасности общих модулей корневой инфраструктуры ermnvldmr.com.
|
||||
|
||||
{{% cards %}}
|
||||
{{< card link="principles" title="Принципы инфраструктуры" icon="book-open" subtitle="Предсказуемость, минимум зависимостей и децентрализация." >}}
|
||||
{{< card link="architecture" title="Архитектура инфраструктуры" icon="share" subtitle="Децентрализованная оркестрация и модели развертывания." >}}
|
||||
{{< card link="security-model" title="Модель безопасности и изоляция" icon="shield-check" subtitle="Изоляция привилегий и защита сети." >}}
|
||||
{{< card link="tiered-storage" title="Модель многоуровневого хранения" icon="database" subtitle="Стандартизированная классификация хранения данных сервисов." >}}
|
||||
{{% /cards %}}
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: Архитектура инфраструктуры
|
||||
description: Децентрализованная модель оркестрации и структура развертывания.
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Фреймворк Root работает на децентрализованной модели оркестрации, разработанной для независимых, самодостаточных проектов. Он обеспечивает строгое разделение между оркестратором («мозгом») и задачами автоматизации («мышцами»).
|
||||
|
||||
## Основная философия {#philosophy}
|
||||
|
||||
Фреймворк построен на принципе **Smart Root, Stupid Actions** («Умный Root, глупые Action-скрипты»). Такой дизайн гарантирует, что отдельные скрипты автоматизации остаются декларативными и не знают о глобальном состоянии системы, в то время как центральный диспетчер берет на себя разрешение окружения и инициализацию библиотек.
|
||||
|
||||
### Smart Root (Диспетчер)
|
||||
|
||||
Точка входа `root` является единственным интерфейсом для пользователей. Она отвечает за:
|
||||
|
||||
- **Разрешение окружения** → Поиск репозиториев `commons` и `configs`.
|
||||
- **Подготовка библиотек** → Разовая загрузка пространств имен (modules) библиотек.
|
||||
- **Установление контекста** → Определение целевого [Узла (Node)](/root/glossary#node) и связанных с ним путей.
|
||||
|
||||
### Stupid Actions (Задачи)
|
||||
|
||||
[Action-скрипты (Actions)](/root/glossary#action) — это декларативные скрипты, расположенные в `scripts/actions/`. Они называются «глупыми», потому что:
|
||||
|
||||
- Они не вычисляют пути и не ищут репозитории.
|
||||
- Они полностью зависят от переменных окружения `ROOT_`.
|
||||
- Они фокусируются исключительно на одной атомарной задаче (например, `compose`, `ufw`).
|
||||
|
||||
## Модель развертывания {#deployment}
|
||||
|
||||
Они обычно развертываются как общий репозиторий [Commons](/root/glossary#commons), подключенный как Git-субмодуль внутри репозитория конфигураций. Движок, на котором построена эта общая инфраструктура, размещен по адресу [GitHub: ermnvldmr.com-root-commons](https://github.com/deytenit/ermnvldmr.com-root-commons).
|
||||
|
||||
{{< filetree/container >}}
|
||||
{{< filetree/folder name="configs-repo" state="open" >}}
|
||||
{{< filetree/folder name=".operator" state="open" >}}
|
||||
{{< filetree/folder name="shared (submodule)" state="open" >}}
|
||||
{{< filetree/folder name="scripts" >}}
|
||||
{{< filetree/folder name="run" >}}
|
||||
{{< filetree/file name="root (dispatcher)" >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< filetree/folder name="lib" >}}
|
||||
{{< filetree/file name="shared libraries" >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< filetree/folder name="actions" >}}
|
||||
{{< filetree/file name="shared actions" >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< filetree/folder name="local" state="open" >}}
|
||||
{{< filetree/folder name="scripts" >}}
|
||||
{{< filetree/folder name="actions" >}}
|
||||
{{< filetree/file name="node-specific overrides" >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< filetree/folder name="daedalus (node)" >}}
|
||||
{{< filetree/file name="docker-compose.yml" >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< filetree/file name="init.sh (bootstrap)" >}}
|
||||
{{< /filetree/folder >}}
|
||||
{{< /filetree/container >}}
|
||||
|
||||
---
|
||||
|
||||
**See also:**
|
||||
|
||||
- [Concept: The ROOT_ API](/root/reference/root-api)
|
||||
- [Guide: Installation](/root/guides/installation)
|
||||
- [GitHub: ermnvldmr.com-root-commons](https://github.com/deytenit/ermnvldmr.com-root-commons)
|
||||
-commons)
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Принципы инфраструктуры
|
||||
description: Основные принципы, обеспечивающие безопасную, предсказуемую среду с минимальными зависимостями.
|
||||
weight: 5
|
||||
---
|
||||
|
||||
Общие модули построены на ключевых принципах, предназначенных для обеспечения безопасной, предсказуемой среды с минимальными зависимостями для независимых self-hosted проектов.
|
||||
|
||||
## Предсказуемость через структуру {#predictability}
|
||||
|
||||
Ручная настройка сервера подвержена «дрейфу конфигурации» (configuration drift), когда хосты, которые должны быть идентичными, со временем начинают различаться. Общие модули решают эту проблему следующим образом:
|
||||
|
||||
- **Git как источник истины**: Каждая конфигурация, от правил UFW до crontab, хранится в репозитории.
|
||||
- **Идемпотентная автоматизация**: [Action-скрипты](/root/glossary#action) разработаны так, чтобы их можно было запускать многократно без побочных эффектов, гарантируя, что хост всегда соответствует заданному состоянию.
|
||||
|
||||
## Минимальное количество зависимостей {#minimalism}
|
||||
|
||||
Для обеспечения долгосрочной поддерживаемости общие модули избегают сложных инструментов управления конфигурацией (таких как Ansible или Salt). Вместо этого они полагаются на:
|
||||
|
||||
- **Bash**: Универсальный язык Unix-систем.
|
||||
- **Docker**: Для изоляции приложений и согласованности окружения.
|
||||
- **Стандартные инструменты Linux**: Прямое использование `systemd`, `ufw` и `cron`.
|
||||
|
||||
## Децентрализация {#decentralization}
|
||||
|
||||
Каждый [Узел (Node)](/root/glossary#node) является независимым. Хотя они используют библиотеку общих модулей ([Commons](/root/glossary#commons)), они не зависят от центрального «мастер»-сервера. Такая архитектура гарантирует, что сбой на одном хосте не повлияет на несвязанные сервисы.
|
||||
|
||||
---
|
||||
|
||||
**См. также:**
|
||||
|
||||
- [Концепция: Модель безопасности и изоляция](/root/concepts/security-model)
|
||||
- [Концепция: Модель многоуровневого хранения](/root/concepts/tiered-storage)
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Безопасность и изоляция привилегий
|
||||
description: Меры безопасности, изоляция привилегий и песочница на уровне проектов.
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Безопасность в Root достигается за счет строгой изоляции привилегий и создания «песочниц» на уровне проектов для минимизации последствий в случае взлома отдельных сервисов.
|
||||
|
||||
## Принцип «No-Root» {#noroot}
|
||||
|
||||
Запуск приложений под пользователем `root` внутри контейнеров является значительным риском безопасности. Общие модули обеспечивают изоляцию с помощью действий `tiers/useradd` и `tiers/chown`.
|
||||
|
||||
### Пользователи для конкретных проектов
|
||||
|
||||
Каждому проекту, расположенному по пути `{repository root}/{node}/{project}`, назначается выделенный системный пользователь на хосте.
|
||||
|
||||
- **Изоляция**: Если контейнер будет взломан, злоумышленник получит только привилегии этого конкретного низкопривилегированного пользователя.
|
||||
- **Безопасность файловой системы**: Проекты могут читать и записывать данные только в свои собственные директории в рамках [Уровней (Tiers)](/root/glossary#tier).
|
||||
|
||||
## Защита сокета Docker {#socket-protection}
|
||||
|
||||
Прямой доступ к `/var/run/docker.sock` эквивалентен правам root на хосте. В качестве лучшей практики настоятельно рекомендуется защищать сокет Docker. Один из способов достижения этого — использование **Socket Proxy** (например, на базе `tecnativa/docker-socket-proxy`) для фильтрации и ограничения доступа к Docker API.
|
||||
|
||||
```yaml filename="docker-socket-proxy-example.yml"
|
||||
services:
|
||||
socket-proxy:
|
||||
image: tecnativa/docker-socket-proxy:0
|
||||
container_name: root-socket-proxy
|
||||
user: "0:0"
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
environment:
|
||||
CONTAINERS: 1
|
||||
SERVICES: 1
|
||||
TASKS: 1
|
||||
networks:
|
||||
socket: {}
|
||||
restart: unless-stopped
|
||||
|
||||
traefik:
|
||||
# ...
|
||||
depends_on:
|
||||
- socket-proxy
|
||||
command:
|
||||
# Использовать прокси вместо локального сокета
|
||||
- "--providers.docker.endpoint=tcp://root-socket-proxy:2375"
|
||||
networks:
|
||||
socket: {}
|
||||
```
|
||||
|
||||
## Мониторинг безопасности (CrowdSec) {#crowdsec}
|
||||
|
||||
Фреймворк интегрирует **CrowdSec** для поведенческого анализа и автоматического реагирования.
|
||||
|
||||
- **Обнаружение вторжений**: CrowdSec отслеживает логи [Traefik](https://traefik.io/) и SSH на предмет подозрительных паттернов (например, брутфорс-атаки, сканирование портов).
|
||||
- **Автоматическая блокировка**: При обнаружении угрозы **CrowdSec Firewall Bouncer** автоматически обновляет правила [UFW](https://help.ubuntu.com/community/UFW), блокируя вредоносный IP на уровне хоста.
|
||||
- **Обмен данными об угрозах**: CrowdSec делится анонимизированными данными об угрозах со своим сообществом, обеспечивая превентивную защиту от известных злоумышленников.
|
||||
|
||||
## Сетевое ужесточение {#networking}
|
||||
|
||||
Root использует `configure/ufw` для реализации политики «Запрещено по умолчанию» (Default Deny).
|
||||
|
||||
- **Внутренняя маршрутизация**: Сервисы взаимодействуют через выделенную сеть-мост `root-proxy`, которая часто настраивается как `internal: true`.
|
||||
- **Изоляция анклавов**: Исходящий трафик может быть направлен через выделенный узел выхода (egress node) для детального контроля.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: Модель многоуровневого хранения
|
||||
description: Стандартизированная таксономия хранения данных сервисов.
|
||||
weight: 15
|
||||
---
|
||||
|
||||
Фреймворк навязывает стандартизированную таксономию хранения. Это гарантирует, что каждый сервис имеет предсказуемое местоположение для своих данных, что упрощает стратегии резервного копирования и распределение оборудования.
|
||||
|
||||
## Таксономия хранения {#taxonomy}
|
||||
|
||||
Данные разделены на три логических [Уровня (Tiers)](/root/glossary#tier) на основе их требований к производительности, жизненного цикла и важности.
|
||||
|
||||
### Уровень 1 (Tier 1): Конфигурации и Кэш
|
||||
|
||||
**Путь:** `${ROOT_NODE_DIR}/@tier1`
|
||||
|
||||
- **Содержимое**: Конфигурационные файлы, небольшие базы данных SQLite, SSL-сертификаты, кэш приложений.
|
||||
- **Характеристики**: Чрезвычайно высокая ценность, объем от низкого до среднего, требует минимальных задержек (latency).
|
||||
- **Оборудование**: Высокоскоростные SSD-накопители, обычно общие с операционной системой.
|
||||
|
||||
### Уровень 2 (Tier 2): Данные приложений
|
||||
|
||||
**Путь:** `${ROOT_NODE_DIR}/@tier2`
|
||||
|
||||
- **Содержимое**: Пользовательские загрузки, большие базы данных, постоянное состояние приложений.
|
||||
- **Характеристики**: Высокая ценность, объем от среднего до высокого, требует высокой надежности.
|
||||
- **Оборудование**: Надежные HDD-кластеры, RAID-массивы или выделенные хранилища.
|
||||
|
||||
### Уровень 3 (Tier 3): Временные файлы и объемные медиа
|
||||
|
||||
**Путь:** `${ROOT_NODE_DIR}/@tier3`
|
||||
|
||||
- **Содержимое**: Логи, временные файлы, объемные медиа (фильмы, музыка) и другие некритичные большие данные.
|
||||
- **Характеристики**: Низкая ценность, очень высокий объем.
|
||||
- **Оборудование**: HDD большой емкости, оптимизированные для непрерывной последовательной записи/чтения (например, WD Purple). Обратите внимание, что Tier 3 **слишком медленный для кэша**.
|
||||
|
||||
## Стратегия резервного копирования {#backup}
|
||||
|
||||
Общие модули не навязывают конкретную стратегию резервного копирования и не предоставляют реализацию по умолчанию, обеспечивая полную гибкость на уровне узла. Ожидается, что операторы сами реализуют логику резервного копирования.
|
||||
|
||||
### Пример: Резервное копирование с помощью Restic
|
||||
|
||||
Распространенной лучшей практикой является использование **Restic** для резервного копирования. Например, вы можете создать файл compose узла оператора для запуска Restic:
|
||||
|
||||
```yaml filename="operator-compose.yml"
|
||||
services:
|
||||
restic:
|
||||
image: restic/restic:0.18.1
|
||||
container_name: operator-restic
|
||||
volumes:
|
||||
- ./@tier2/{project}/{service}/{data}:/data/@tier2/{project}/{service}/{data}:ro
|
||||
- ./@tier1/{project}/{service}/{data}:/data/@tier1/{project}/{service}/{data}:ro
|
||||
- ./@tier1/.operator/restic/cache:/var/restic-cache
|
||||
environment:
|
||||
RESTIC_REPOSITORY: "s3:example.com/bucket"
|
||||
RESTIC_PASSWORD: ${RESTIC_PASSWORD}
|
||||
# ... учетные данные AWS/S3
|
||||
network_mode: "host"
|
||||
entrypoint: [ "restic" ]
|
||||
user: "0:0"
|
||||
```
|
||||
|
||||
### Реализация стратегии
|
||||
|
||||
Операторы могут реализовать свою стратегию, определив локальный Action в `.operator/local/scripts/actions/sync/tiers`. Диспетчер `root` затем сможет выполнить этот скрипт для запуска резервного копирования, позволяя детально контролировать способ сохранения данных.
|
||||
|
||||
## Обоснование {#justification}
|
||||
|
||||
1. **Оптимизация оборудования**: Сопоставляя уровни с конкретным оборудованием (SSD для Tier 1, RAID для Tier 2, Purples для Tier 3), мы оптимизируем как производительность, так и стоимость.
|
||||
2. **Выборочное резервное копирование**: Отделение временных логов и объемных медиа (Tier 3) от критических конфигураций (Tier 1) предотвращает трату дорогостоящего места в хранилище резервных копий.
|
||||
3. **Архитектурная ясность**: Любой оператор может проинспектировать директорию [Узла (Node)](/root/glossary#node) и сразу понять требования к хранению и приоритет его содержимого.
|
||||
Reference in new issue
Block a user