vault backup: 2026-05-24 15:03:28
This commit is contained in:
@@ -0,0 +1,118 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- homelab
|
||||
- infrastructure
|
||||
- devops
|
||||
created: 2026-05-18
|
||||
updated: 2026-05-18
|
||||
title: Infrastructure — ada-dev
|
||||
source: "[[Infrastructure]]"
|
||||
---
|
||||
|
||||
# Infrastructure — ada-dev
|
||||
|
||||
Заметка фиксирует текущую схему homelab-инфраструктуры `ada-dev`: публичный VPS, домашние узлы, reverse proxy, overlay-сеть и пользовательские сервисы.
|
||||
|
||||
![[infra.excalidraw.md.md|950]]
|
||||
|
||||
## Общая схема
|
||||
|
||||
Инфраструктура состоит из трех ключевых зон:
|
||||
|
||||
- `Internet` — внешний доступ пользователей.
|
||||
- `ru-vps` с белым IP — публичная точка входа.
|
||||
- локальные узлы `mini-pc` и `cloud-pc`, связанные с VPS через ZeroTier overlay network.
|
||||
|
||||
VPS принимает внешний трафик и проксирует его дальше. Домашние сервисы не обязаны напрямую светиться в интернет: доступ к ним можно строить через публичный [[CA и NGINX|Nginx]]/NPM и приватную overlay-сеть.
|
||||
|
||||
## Узлы
|
||||
|
||||
### ru-vps
|
||||
|
||||
`ru-vps` — публичный сервер с белым IP. На схеме он выполняет роль внешнего шлюза:
|
||||
|
||||
- `NPM (публичный)` — reverse proxy для публичных доменов и маршрутов;
|
||||
- `Nginx (80, 443)` — входная точка HTTP/HTTPS;
|
||||
- `ufw` — базовый firewall;
|
||||
- `ZeroTier` — связь с домашним сегментом;
|
||||
- `Portainer Agent` — управление контейнерной средой через Portainer.
|
||||
|
||||
Практический смысл VPS — держать наружу только минимальный набор портов и не раскрывать домашнюю сеть напрямую.
|
||||
|
||||
### mini-pc
|
||||
|
||||
`mini-pc` описан как `N150 / 12 GB / 256 GB`. По схеме это небольшой домашний узел для инфраструктурных сервисов:
|
||||
|
||||
- `AdGuard Home`;
|
||||
- `NPM (локальный)`;
|
||||
- `Vaultwarden`;
|
||||
- `ZeroTier`;
|
||||
- `Portainer Agent`.
|
||||
|
||||
Логика узла: локальная инфраструктура и сервисы, которым полезно быть рядом с домашней сетью.
|
||||
|
||||
### cloud-pc
|
||||
|
||||
`cloud-pc` описан как `i5 / 16 GB / 256 GB + 5 TB`. Это более крупный узел для сервисов и хранения:
|
||||
|
||||
- `Portainer Server`;
|
||||
- `Cockpit`;
|
||||
- `Gitea + Registry`;
|
||||
- `Gitea Actions Runner`;
|
||||
- `Nextcloud`;
|
||||
- `SMB/BU/Files (5 TB HDD)`;
|
||||
- `ZeroTier`.
|
||||
|
||||
Логика узла: сервисы разработки, файлы, backup/storage и управление контейнерами.
|
||||
|
||||
## Сетевой слой
|
||||
|
||||
ZeroTier используется как overlay-сеть между VPS и домашними узлами. Это позволяет:
|
||||
|
||||
- проксировать трафик с публичного VPS на локальные сервисы;
|
||||
- не открывать сервисные порты домашней сети наружу;
|
||||
- держать управление и межузловые соединения в приватном сегменте;
|
||||
- упростить маршрутизацию между VPS, `mini-pc` и `cloud-pc`.
|
||||
|
||||
`ufw` на VPS должен ограничивать внешний периметр. Базовая модель: наружу открыты только необходимые публичные порты, а внутренние сервисы доступны через ZeroTier и reverse proxy.
|
||||
|
||||
## Reverse proxy
|
||||
|
||||
На схеме есть два уровня NPM:
|
||||
|
||||
- `NPM (публичный)` на VPS — отвечает за публичный доступ;
|
||||
- `NPM (локальный)` на `mini-pc` — может обслуживать локальные маршруты и внутренние сервисы.
|
||||
|
||||
Такой подход полезен, если нужно разделить внешний и внутренний контуры. Публичный NPM принимает домены из интернета, локальный NPM может маршрутизировать сервисы внутри homelab.
|
||||
|
||||
Смежная заметка: [[Nginx Proxy Manager под path]].
|
||||
|
||||
## Сервисы
|
||||
|
||||
Ключевые пользовательские сервисы:
|
||||
|
||||
- `Vaultwarden` — self-hosted password manager;
|
||||
- `Gitea + Registry` — Git-сервер и container registry;
|
||||
- `Gitea Actions Runner` — CI runner;
|
||||
- `Nextcloud` — файловая синхронизация;
|
||||
- `SMB/BU/Files` — файловое хранилище и backup на 5 TB HDD;
|
||||
- `AdGuard Home` — DNS/ad blocking;
|
||||
- `Cockpit` — web-управление сервером;
|
||||
- `Portainer Server/Agent` — управление контейнерами.
|
||||
|
||||
## Замечания по устойчивости
|
||||
|
||||
- Публичный VPS — критическая точка входа. Если он падает, внешний доступ к сервисам пропадает, даже если домашние узлы живы.
|
||||
- ZeroTier — критическая зависимость для связности между VPS и домашними узлами.
|
||||
- `cloud-pc` несет сразу несколько ролей: Git, registry, runner, Nextcloud и storage. Для важных данных нужен отдельный backup-контур.
|
||||
- `Vaultwarden` стоит держать максимально изолированным: отдельный volume, backup, HTTPS, минимальный доступ к админке.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[CA и NGINX]] — TLS-сертификаты и Nginx как входной HTTP/HTTPS-слой.
|
||||
- [[VPN]] — близкая идея приватного сетевого контура.
|
||||
- [[Docker - Дополнительные знания]] — контейнерная эксплуатация сервисов.
|
||||
- [[Основы - Docker]] — базовая модель контейнеризации.
|
||||
- [[DevOps - основы]] — инфраструктура, автоматизация и эксплуатация.
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
status: stable
|
||||
type: lab
|
||||
tags:
|
||||
- admin
|
||||
- network
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: CA И NGINX
|
||||
---
|
||||
|
||||
# CA И NGINX
|
||||
При запросе в локальный центр сертификации Microsoft, он выдает два файла:
|
||||
|
||||
1. certnew.cer - сертификат
|
||||
2. certnew.p7b - цепочка сертификатов
|
||||
|
||||
Для работы в Nginx необходимо их перевернуть в pem-формат.
|
||||
|
||||
Если экспортированы они в base64, то cer уже в нужном формате, а p7b надо разделить на блоки:
|
||||
|
||||
```text
|
||||
openssl pkcs7 -print_certs -in certnew.p7b -out chain.pem
|
||||
```
|
||||
|
||||
И надо объединить их в одну цепочку сертификатов:
|
||||
|
||||
```text
|
||||
cat certnew.cer chain.pem > fullchain.pem
|
||||
```
|
||||
|
||||
Далее в конфигурации Nginx:
|
||||
|
||||
```text
|
||||
...
|
||||
server {
|
||||
ssl_certificate /path/to/fullchain.pem
|
||||
ssl_certificate_key /path/to/server.key
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
- [[VPN]] — ассиметричное шифрование (открытый/закрытый ключ) из VPN-ноты — это и есть PKI, на котором строится TLS-сертификат от CA
|
||||
- [[Docker Swarm]] — встроенный mTLS между нодами Swarm использует ту же инфраструктуру CA и сертификатов
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
status: seed
|
||||
type: guide
|
||||
tags:
|
||||
- admin
|
||||
- nginx
|
||||
- reverse-proxy
|
||||
- homelab
|
||||
created: 2026-05-18
|
||||
updated: 2026-05-18
|
||||
title: Nginx Proxy Manager под path
|
||||
source: "[[Лайфхак для NPM. Как проксировать не на поддомен а на под путь]]"
|
||||
---
|
||||
|
||||
# Nginx Proxy Manager под path
|
||||
|
||||
Кейс: сервис нужно опубликовать не на отдельном поддомене вида `service.domain.ru`, а в подкаталоге основного домена: `domain.ru/<path>`.
|
||||
|
||||
## Решение
|
||||
|
||||
В Nginx Proxy Manager нужно добавить `location` для нужного маршрута и в дополнительных настройках срезать prefix перед проксированием:
|
||||
|
||||
```nginx
|
||||
rewrite ^/<path>/?(.*)$ /$1 break;
|
||||
```
|
||||
|
||||
Смысл правила:
|
||||
|
||||
- пользователь открывает `domain.ru/<path>/...`;
|
||||
- Nginx убирает `/<path>` из URI;
|
||||
- upstream получает путь так, будто сервис открыт в корне `/`.
|
||||
|
||||
## Когда это нужно
|
||||
|
||||
Подход полезен, если:
|
||||
|
||||
- не хочется заводить отдельный поддомен под мелкий сервис;
|
||||
- сервис живет за reverse proxy в homelab;
|
||||
- внешний URL должен быть компактным;
|
||||
- нужно спрятать несколько внутренних сервисов за одним доменом.
|
||||
|
||||
## Ограничения
|
||||
|
||||
Не каждый сервис нормально работает под path-prefix. Возможные проблемы:
|
||||
|
||||
- абсолютные ссылки на `/assets`, `/api`, `/static`;
|
||||
- WebSocket-маршруты;
|
||||
- OAuth/callback URL;
|
||||
- hardcoded base URL внутри приложения;
|
||||
- редиректы на `/`, из-за которых пользователь выпадает из `/<path>`.
|
||||
|
||||
Если приложение поддерживает настройку base path/base URL, лучше указать ее явно. Rewrite в proxy — рабочий хак, но не полноценная замена поддержке subpath внутри приложения.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Infrastructure — ada-dev]] — где NPM используется как публичный и локальный reverse proxy.
|
||||
- [[CA и NGINX]] — TLS и базовая настройка Nginx.
|
||||
- [[Docker - Дополнительные знания]] — эксплуатация сервисов в контейнерах.
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- homelab
|
||||
created: 2026-02-12
|
||||
updated: 2026-05-14
|
||||
title: Проблемы дистрибутивов
|
||||
---
|
||||
|
||||
# Проблемы дистрибутивов
|
||||
## Arch Linux
|
||||
- Из-за слишком новой версии OpenSSL не запускаются проекты на RoR
|
||||
**Решение**: Запускать их из под контейнера
|
||||
- Пока абсолютный лидер!
|
||||
|
||||
## NixOS
|
||||
- Невозможно установить новейшую версию пакетов, даже с nix-ld
|
||||
- Сложность разворачивания окружений
|
||||
- Заморочки для workflow
|
||||
|
||||
## Fedora
|
||||
- SELinux.
|
||||
- недоступность репозиториев без VPN
|
||||
|
||||
## Ubuntu
|
||||
- Устаревшие пакеты (не решается даже PPA)
|
||||
- Нестабильная работа (что странно, лол)
|
||||
- SNAP-пакеты вовсюду, господи...
|
||||
- Но хорош как серверное решение
|
||||
## VanillaOS
|
||||
- Проблема аналогична NixOS - сложность с установкой приложений
|
||||
- Особенно, неясно, как поставить VirtualBox (но Virt-Manager лучше)
|
||||
|
||||
## PopOS
|
||||
- База - Ubuntu, что дает свои фишки в работе
|
||||
- COSMIC иногда лагает, все же
|
||||
- Вышла стабильная версия на 24.04 с хорошей поддержкой NVIDIA, можно на ПК в будущем
|
||||
|
||||
## Связанные заметки
|
||||
- [[Docker - Дополнительные знания]] — "запускать Rails из под контейнера" — прямой кейс отсюда; контейнер решает проблему несовместимости версий OpenSSL
|
||||
- [[Ruby On Rails]] — проекты на RoR не запускаются на Arch из-за OpenSSL; решение — запуск в изолированном контейнере
|
||||
Reference in New Issue
Block a user