fix: PageHead header alignment, analytics proxy, and infra improvements (#64)
🤖 Pull request created from `various-fixes` containing PageHead
breadcrumbs and navigation alignment fixes, Umami analytics proxy, and
infrastructure updates.
This commit is contained in:
deytenit authored and 
GitHub committed
1 parent
ff5a50bad8
commit
9ee672504f
110 files changed
+2649
-1760
No files matched your search
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: Начало работы с узлом apex
|
||||
description: Начальная настройка репозитория узла и перевод хоста под управление apex.
|
||||
title: Начало работы с узлом apex
|
||||
description: Начальная настройка репозитория узла и перевод хоста под управление apex.
|
||||
weight: 5
|
||||
---
|
||||
|
||||
Это краткое руководство проведёт новый хост от склонированного репозитория [узла](/apex/glossary#node) до работающего стека сервисов. Предполагается, что репозиторий узла уже существует — чтобы собрать его с нуля, см. [Руководство: Сборка репозитория узла](/apex/guides/node-repository).
|
||||
В этом руководстве показано, как настроить новый хост: от клонирования репозитория [узла](/apex/glossary#node) до запуска рабочего стека сервисов. Предполагается, что репозиторий узла уже создан; если его нужно собрать с нуля, см. [Руководство: Сборка репозитория узла](/apex/guides/node-repository).
|
||||
|
||||
## Предварительные требования
|
||||
|
||||
- Хост на базе Debian. Подойдёт любой FQDN — [идентичность узла](/apex/glossary#node-identity) объявляется явно в `node.env` (`APEX_NODE_FQDN`, `APEX_NODE_HOST`, `APEX_SUBNET`), а не выводится из обязательного формата имени хоста.
|
||||
- `git` и Python 3 — [движок](/apex/glossary#engine) использует только стандартную библиотеку; `pip` никогда не требуется.
|
||||
- Docker с Compose версии v2.20 или новее ([базовая композиция](/apex/glossary#core-composition) подключается через директиву `include:`).
|
||||
- Пользователь для входа с возможностью sudo.
|
||||
- Три места хранения для [уровней](/apex/glossary#tier) (например, три точки монтирования).
|
||||
- Хост на базе Debian. Подойдёт любой FQDN: [идентичность узла](/apex/glossary#node-identity) задаётся явно в `node.env` (`APEX_NODE_FQDN`, `APEX_NODE_HOST`, `APEX_SUBNET`), а не выводится из имени хоста.
|
||||
- `git` и Python 3 — [движок](/apex/glossary#engine) использует только стандартную библиотеку, `pip` не нужен.
|
||||
- Docker с Compose версии 2.20 или новее ([базовая композиция](/apex/glossary#core-composition) подключается через директиву `include:`).
|
||||
- Учётная запись с правами sudo для входа на хост.
|
||||
- Три хранилища под [уровни](/apex/glossary#tier) (например, три точки монтирования).
|
||||
|
||||
## Начальная настройка
|
||||
|
||||
@@ -27,7 +27,7 @@ cd <node-repo>
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
||||
`init.sh` инициализирует субмодуль `commons/`, указывает `core.hooksPath` на `commons/githooks`, помечает чекаут как `safe.directory` и добавляет `commons/` в начало `PATH` — лаунчер находится в `commons/apex`.
|
||||
Скрипт `init.sh` инициализирует субмодуль `commons/`, настраивает `core.hooksPath` на `commons/githooks`, помечает чекаут как `safe.directory` и добавляет `commons/` в начало `PATH` (лаунчер находится в `commons/apex`).
|
||||
|
||||
### Проверьте обнаружение действий
|
||||
|
||||
@@ -35,7 +35,7 @@ source ~/.bashrc
|
||||
apex --help
|
||||
```
|
||||
|
||||
В списке отображается каждое действие [commons](/apex/glossary#commons) плюс любые локальные [проприетарные модули](/apex/glossary#proprietaries) узла с меткой `(local)`. Когда в `node.env` отсутствует `APEX_NODE_FQDN`, движок выводит предупреждение и откатывается к имени хоста ОС — безобидно на рабочей станции, но на самом узле задайте `APEX_NODE_FQDN` явно. (`APEX_SUBNET` обязателен: если он отсутствует, движок завершается с кодом `66`.)
|
||||
В списке отображается каждое действие [commons](/apex/glossary#commons) плюс любые локальные [проприетарные модули](/apex/glossary#proprietaries) узла с меткой `(local)`. Если в `node.env` не задан `APEX_NODE_FQDN`, движок выводит предупреждение и использует имя хоста ОС. На рабочей станции это безобидно, но на самом узле задайте `APEX_NODE_FQDN` явно. Параметр `APEX_SUBNET` обязателен: без него движок завершит работу с кодом `66`.
|
||||
|
||||
### Свяжите уровни хранилища
|
||||
|
||||
@@ -43,7 +43,7 @@ apex --help
|
||||
apex tiers/link <tier1-path> <tier2-path> <tier3-path>
|
||||
```
|
||||
|
||||
Создаёт ссылки `compositions/@tierN` уровня узла, директории уровней и ссылки `@tierN` для каждого проекта, области `shared/` и символьную ссылку `.env` каждого проекта в уровень 1. Успех завершается сообщением `@tier setup completed.`
|
||||
Команда создаёт ссылки `compositions/@tierN` на уровне узла, каталоги уровней и ссылки `@tierN` для каждого проекта, области `shared/`, а также символьную ссылку на `.env` каждого проекта в уровень 1. При успешном выполнении выводится сообщение `@tier setup completed.`.
|
||||
|
||||
### Заведите пользователей проектов
|
||||
|
||||
@@ -52,11 +52,11 @@ apex tiers/useradd
|
||||
apex tiers/chown
|
||||
```
|
||||
|
||||
`tiers/useradd` создаёт по одному системному пользователю `noroot-<project>` на каждую композицию плюс группу `noroot-shared`, а также добавляет `APEX_UID`/`APEX_GID`/`APEX_SHARED_GID` в `.env` каждого проекта. Затем `tiers/chown` применяет матрицу владения (см. [Концепция: Многоуровневое хранилище](/apex/concepts/tiered-storage)) и завершается сообщением `Permissions applied.`
|
||||
Команда `tiers/useradd` создаёт по одному системному пользователю `noroot-<project>` для каждой композиции и общую группу `noroot-shared`, а также прописывает `APEX_UID`, `APEX_GID` и `APEX_SHARED_GID` в `.env` каждого проекта. Затем `tiers/chown` выставляет права по матрице владения (см. [Концепция: Многоуровневое хранилище](/apex/concepts/tiered-storage)) и выводит сообщение `Permissions applied.`.
|
||||
|
||||
### Заполните базовые секреты
|
||||
|
||||
Отредактируйте `compositions/apex/.env` (символьная ссылка в хранилище уровня 1, никогда не коммитится), указав ключи, задокументированные в файле `SECRETS.md` репозитория узла:
|
||||
Отредактируйте `compositions/apex/.env` (символьная ссылка в хранилище уровня 1, никогда не коммитится), указав ключи из файла `SECRETS.md` репозитория узла:
|
||||
|
||||
```ini {filename="compositions/apex/.env"}
|
||||
APEX_RESTIC_PASSWORD=...
|
||||
@@ -67,7 +67,7 @@ APEX_TRAEFIK_ACME_EMAIL=...
|
||||
APEX_OBS_BASIC_AUTH_PASS=... # только когда включён профиль наблюдаемости alloy
|
||||
```
|
||||
|
||||
`APEX_UID`/`APEX_GID`/`APEX_SHARED_GID` уже присутствуют — `tiers/useradd` поддерживает их между комментариями-маркерами. Несекретные скалярные значения (`APEX_RESTIC_REPOSITORY`, push-URL-ы, `COMPOSE_PROFILES`, `TZ`, …) хранятся в коммитируемом `compositions/apex/apex.env` — см. [Руководство: Сборка репозитория узла](/apex/guides/node-repository).
|
||||
Переменные `APEX_UID`, `APEX_GID` и `APEX_SHARED_GID` уже добавлены: `tiers/useradd` сохраняет их между специальными комментариями-маркерами. Несекретные скалярные значения (`APEX_RESTIC_REPOSITORY`, push-URL, `COMPOSE_PROFILES`, `TZ` и др.) хранятся в отслеживаемом файле `compositions/apex/apex.env` (см. [Руководство: Сборка репозитория узла](/apex/guides/node-repository)).
|
||||
|
||||
### Настройте хост
|
||||
|
||||
@@ -75,7 +75,7 @@ APEX_OBS_BASIC_AUTH_PASS=... # только когда включён проф
|
||||
apex configure
|
||||
```
|
||||
|
||||
Запускает каждое действие `configure/*` в фиксированном порядке: `base`, `ufw`, `crowdsec`, `cron`, `systemd`, `routing`. Каждый шаг можно вызвать и по отдельности; некоторые принимают `--dry-run`. См. [Руководство: Эксплуатация узла](/apex/guides/host-operations).
|
||||
Команда запускает все действия `configure/*` в строгом порядке: `base`, `ufw`, `crowdsec`, `cron`, `systemd`, `routing`. Каждый шаг можно выполнить и отдельно; некоторые из них поддерживают флаг `--dry-run` (см. [Руководство: Эксплуатация узла](/apex/guides/host-operations)).
|
||||
|
||||
### Поднимите стек
|
||||
|
||||
@@ -83,15 +83,15 @@ apex configure
|
||||
apex compose up
|
||||
```
|
||||
|
||||
Сначала поднимается базовая композиция (она владеет сетями), затем каждая композиция сервиса в алфавитном порядке.
|
||||
Сначала запускается базовая композиция (она создаёт общие сети), затем — композиции отдельных сервисов в алфавитном порядке.
|
||||
|
||||
{{% /steps %}}
|
||||
|
||||
## Проверка
|
||||
|
||||
- `apex --help` выводит список действий без предупреждений на работающем хосте.
|
||||
- `docker ps` показывает базовые контейнеры (`apex-traefik`, `apex-socket-proxy` плюс любые сервисы, включённые профилями) и якорь каждого проекта.
|
||||
- `apex utils/lint-docker-compose` сообщает `Anchor IP validation passed.`
|
||||
- `apex --help` выводит список действий без предупреждений на работающем хосте.
|
||||
- `docker ps` показывает базовые контейнеры (`apex-traefik`, `apex-socket-proxy` и дополнительные сервисы активных профилей), а также якорный контейнер каждого проекта.
|
||||
- `apex utils/lint-docker-compose` завершается сообщением `Anchor IP validation passed.`.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in new issue
Block a user