Репозиторий: github.com/DirektorBani/DataSafeS3
Лицензия: Apache-2.0
Релиз: DataSafeS3 CE v1.3.0 (3 августа 2026)

Контекст и боль

В статье про v1.1.0 HA v2 остался lab-фундаментом: erasure, Postgres leader lock, скрипты в scripts/ha/. Trusted clusters закрыли pairing двух сайтов. Кластерный «три ноды → Apply → failover» до тега мы ещё не доказывали.

Между 1.1.0 и 1.3.0 вышли v1.1.1 (MinIO migration kit) и v1.2.0 (Object Lock + versioning в консоли). Отдельные посты под них не писал — это админские гайды а не смена модели доверия к релизу. v1.3.0 как раз про модель доверия: появился cluster installer и SSH Docker lab, на котором release gate прошёл с 0 SKIP.

Серия, если заходите впервые:

• v1.0.0 — честный разбор

• v1.0.1 / v1.0.2 — что чинили

• v1.1.0 — trusted clusters, metrics, Teams

Конкретная боль после 1.1.0 выглядела так.

1. Offline compose-lab зелёный, но VIP/Patroni - скипались.
etcd + Postgres + erasure поднимаются без registry. Keepalived (multicast VRRP) и Patroni promote в этом режиме мы осознанно пропускали: Docker Desktop и L2 multicast живут в разных мирах. Для локальной отладки — ок. Для annotated tag — плохо: «все зелёное», а самое рискованное не гоняли.

2. Ручной Apply на трёх «нодах» в 2 часа ночи.
Inventory разъезжается. HAProxy и Patroni дерутся за :5432. storage-server стартует до кворума. В secrets попадает replication password вместо superuser: healthz 200, бакеты «почему-то» пустые.

Нужен был не ещё один README, а воспроизводимый путь: inventory → plan → render → apply → drills, который можно прогнать перед v1.3.0 и получить fail=0 skip=0.

Что сделали в v1.3.0

Cluster installer (Waves 1–2)

Скрипты: scripts/cluster/. Шаблоны: deploy/cluster/templates/. Тесты: scripts/tests/cluster-installer-w1|w2.

Два фикса из стенда, без которых Apply «почти работает»:

1. HAProxy биндится только на VIP; Patroni слушает fabric NODE_IP:5432. Иначе colocated LB + Postgres делят порт.

2. storage-server после Patroni quorum; в secrets — пароль superuser, не replication.

Это не сертификация Patroni и не automatic multi-AZ. Это воспроизводимый Apply + набор installer-тестов.

Архитектура SSH Docker lab

Три контейнера-VM: ds-lab-node0..2 на 10.88.0.10–12, SSH host ports :2221–2223, VIP 10.88.0.100 (S3), .101 (console), .102 (Postgres) через unicast keepalived.

flowchart LR
  subgraph host["Host / Docker Desktop"]
    OPS["Apply + drills<br/>via SSH :2221–2223"]
  end

  subgraph fab["fabric 10.88.0.0/24"]
    N0["ds-lab-node0<br/>10.88.0.10"]
    N1["ds-lab-node1<br/>10.88.0.11"]
    N2["ds-lab-node2<br/>10.88.0.12"]
    VIP_S3["VIP .100 S3"]
    VIP_UI["VIP .101 console"]
    VIP_PG["VIP .102 Postgres"]
  end

  OPS -->|ssh| N0
  OPS -->|ssh| N1
  OPS -->|ssh| N2

  N0 --- N1
  N1 --- N2
  N0 -. unicast VRRP .-> VIP_S3
  N1 -. unicast VRRP .-> VIP_UI
  N2 -. unicast VRRP .-> VIP_PG

  N0 --- etcd["etcd ×3"]
  N1 --- Patroni["Patroni / Postgres"]
  N2 --- HAP["HAProxy on VIP only"]
  HAP --> Patroni
  HAP --> storage["storage-server<br/>after quorum"]

Unicast VRRP выбран потому, что на Docker bridge multicast keepalived обычно не даёт честный L2-сценарий. Lab доказывает Apply/drill-path, не parity с bare-metal.

Release gate: как гоняли

На Windows-хосте (PowerShell) — один раз собрать offline-бандл и образ ноды (из корня клона репозитория):

powershell -NoProfile -File scripts\cluster\lab\fetch-offline-bundle.ps1
powershell -NoProfile -File scripts\cluster\lab\fetch-apk-closure.ps1
docker build -f deploy\cluster\lab\Dockerfile.offline -t datasafe-cluster-node:lab deploy\cluster\lab

Дальше lab-скрипты (Bash / Git Bash / WSL):

bash scripts/cluster/lab/up-ssh.sh
bash scripts/cluster/lab/run-apply-ssh.sh
bash scripts/cluster/lab/run-drills-ssh.sh
# ожидание: skip=0 fail=0

Прогон 3 августа 2026: Apply PASS; drills 9 PASS / 0 FAIL / 0 SKIP; Patroni promote ≈ 36 с (порог ≤ 60 с). README: deploy/cluster/lab/README.md.

Типичные грабли стенда (то, из-за чего раньше «Apply был на одной ноде»):

• Alpine account lock → usermod -p '*'

• ssh без -n съедает stdin → Apply не доходит до node1/node2

• CRLF в render/apply на Windows

• etcd: не экспортировать ETCD_*, если CLI уже на флагах

Кластер в Grafana + install entrypoints

Gauge’и datasafe_cluster_node_* / overall / HA, дашборд deploy/docker/grafana/dashboards/datasafe-cluster.json. Пустой Admin Cluster.Nodes → fallback localhost:9000.

SSH lab и основной compose — разные сети. «Пустая» Grafana чаще значит «смотрите не тот Prometheus», а не «метрики сломаны».

В корне: install.ps1 / install.sh / install.cmd, optional identity profile; публичный login-options для LDAP/OIDC кнопок без утечки секретов; overlays в deploy/compose/.

Между 1.1.0 и 1.3.0

Если вы на 1.1.0 и цель — кластерный lab, разумнее сразу 1.3.0.

Честно про пределы

• Unicast VRRP на Docker Desktop ≠ bare-metal L2 multicast keepalived.

• Offline compose-lab по-прежнему может SKIP VIP/Patroni — no-skip path только SSH lab.

• Installer + drills не делают из CE automatic multi-AZ orchestrator и не «сертифицируют» Patroni.

• Grafana multi-node требует настроенный Cluster.Nodes (и reachable targets); иначе один localhost-fallback.

• Object Lock из 1.2.0 не превращает бакет в WORM сам по себе.

Как воспроизвести / проверить

Образы релиза:

docker pull ghcr.io/direktorbani/datasafe-storage-server:v1.3.0
docker pull ghcr.io/direktorbani/datasafe-console:v1.3.0

CHANGELOG: CHANGELOG.md. Notes: v1.3.0. Upgrade: operations-guide/ru/upgrade.md.

Итог и вопрос в комментарии

v1.3.0 закрывает разрыв между «HA lab есть в README» и «перед тегом прогнали Apply + promote + VIP move с нулём SKIP». Это CE и Docker-lab доказательство, не паспорт ЦОД.

Уязвимости — SECURITY.md. Баги — GitHub Issues.

Вопрос к тем, кто уже крутит Patroni/keepalived не в Docker: насколько для вас приемлем unicast VRRP как явный lab-контракт, или release gate обязан требовать multicast на «настоящих» VM? Напишите, где бы вы провели черту — интересен именно ops-опыт а не «нужен Enterprise».

Серия на Habr

Автор: Илья Трачук — разработчик DataSafeS3