Skip to content

PRODUCTION.md

Latest commit

 

History

History
70 lines (50 loc) · 16.4 KB

PRODUCTION.md

File metadata and controls

70 lines (50 loc) · 16.4 KB
Raw

Вывод в эксплуатацию: профиль Standalone

Чек-лист для первого промышленного профиля: один сервер с API, completion worker, агентом резервных копий, PostgreSQL и локальным диском хранения; клиенты (CI/CD, агенты развёртывания, консоль) работают с других машин. Это не HA: обновление и отказ сервера означают перерыв, клиенты продолжают передачи через resume/retry. Подробности каждого шага — по ссылкам; документ не вводит новых настроек.

Пункты выполняются по порядку. Пункт без отметки — не выполненный, а не «необязательный».

1. Сервер, диски и PostgreSQL

  • Каталог хранения (ARKVORY_DATA_DIR) — локальный том, не сетевой share, с запасом под рост. ARKVORY_CAPACITY_BYTES — лимит логических резервов, а не измерение диска; ARKVORY_STORAGE_RESERVE_BYTES (1 GiB по умолчанию) оставляет место, которое не отдаётся загрузкам (конфигурация).
  • Для vault резервных копий подготовлен отдельный зашифрованный том (LUKS, BitLocker, шифрование NAS): тот же диск, что storage, не защищает от отказа диска, а vault по умолчанию шифруется Arkvory (ADR 0070); том шифруется дополнительно (vault без шифрования хранит каталог, хеши паролей и все файлы открытым текстом). На Windows — локальный или iSCSI том: UNC/SMB отклоняются. Том NAS монтируется до старта служб.
  • PostgreSQL: отдельная БД для одного Arkvory. Графические EXE/DEB/RPM создают собственный кластер на 127.0.0.1 (порт выбирается при установке: 54329 или первый свободный из 45329–45348, на Windows только из них, с постоянным исключением порта из резервируемых Windows диапазонов; см. ARKVORY_DATABASE_URL); командным установщикам нужна существующая PostgreSQL. max_connections рассчитан по пулу API, пулу служебных сессий, пулу блокировок записи (ARKVORY_MAX_UPLOADS), пулам worker и соединениям агента копий; собственный кластер установщика запускается с max_connections=200 (ADR 0073). Если БД не на этом хосте, ARKVORY_DATABASE_URL содержит sslmode=verify-full (TLS до PostgreSQL); в журнале запуска нет database.plaintext_exposed.
  • Установка вне домашних каталогов и пользовательских профилей (установка).

2. Установка

  • Выбран вариант: Windows Arkvory-Setup-x64.exe, Linux Arkvory-amd64.deb / Arkvory-x86_64.rpm, командный install.sh / install.ps1 или Compose (варианты). Встроенный HTTPS доступен только нативной установке; для Compose нужен reverse proxy.
  • После установки работают три службы: arkvory-api, arkvory-worker, arkvory-backup (Windows: Arkvoryapi, Arkvoryworker, Arkvorybackup; Compose: api, worker, backup). Установка от 0.2.x, обновлённая своим старым кодом, получает службу агента после arkvory updates-connect --root <root>.

3. Сеть и HTTPS

  • Сертификат на публичное имя сервера выпущен внешним инструментом (certbot, win-acme, корпоративный УЦ) и продлевается им же. Ключ без пароля, читать его может только учётная запись службы.
  • HTTPS включён одной из двух схем (HTTPS, ADR 0055):
    • встроенный: arkvory configure --root <root> --tls-cert <fullchain.pem> --tls-key <privkey.pem> --listen-host 0.0.0.0 — проверка файлов, перезапуск и откат при сбое; продлённые файлы подхватываются без перезапуска;
    • reverse proxy: API остаётся на loopback, proxy указан в ARKVORY_TRUSTED_PROXIES и не буферизует тела (nginx.conf.example); журнал доступа proxy не пишет строку запроса — в ней ссылки на скачивание несут свой секрет (ADR 0062).
  • Firewall: снаружи открыт только порт HTTPS (API или proxy) и только для сетей клиентов. PostgreSQL слушает loopback. HTTP-порт API на внешнем адресе без proxy не открыт; в журнале запуска нет http.plaintext_exposed.
  • С клиентской машины GET https://<имя>/health/status отвечает 200, цепочка сертификата проверяется без исключений. Проверку TLS на клиентах не отключать.

4. Доступ

  • config/bootstrap-token.txt — ключ восстановления, а не рабочий ключ: доступ только у root/Administrators, не копировать на клиенты и в CI. Инструменты установки (создание владельца, configure --backup-vault, проверка агента после обновления) читают его локально, поэтому файл не удалять. При ручной ротации меняйте токен и его SHA-256 в config/keys.json вместе и перезапускайте API. config/health-token.txt и запись deployment-health сохраняйте (установка).
  • Созданы личные учётные записи администраторов; группы получают read/write на конкретные репозитории (пользователи и группы, IDENTITY). Самостоятельная регистрация выключена (по умолчанию).
  • Для каждого потребителя (CI/CD, агент развёртывания, внешняя система) — свой сервисный аккаунт и ключ с минимальными правами на точные репозитории, ключ передаётся через хранилище секретов, не аргументом (SERVICE_KEYS, CLI).
  • Для Prometheus — отдельный сервисный ключ без прав на репозитории.

5. Резервные копии

  • Vault подключён: arkvory configure --root <root> --backup-vault <каталог> --vault-key-file <файл ключа агента> (Windows: & "$root\runtime\node.exe" "$root\manage.mjs" configure …). Команда принимает изменение, только когда агент сообщил этот vault доступным (служба и vault, ADR 0057).
  • В консоли → «Резервные копии» включён план: явный IANA-пояс, время и retention (по умолчанию 7/4/6). Время копии не пересекается с окном автоматических обновлений (03:00–03:59 UTC по умолчанию): обновление останавливает агента, копия прерывается и повторяется позже.
  • Первая копия выполнена («Создать копию сейчас» или arkvoryctl backup run), структурная проверка прошла, в состоянии нет критических предупреждений (arkvoryctl backup status выходит с кодом 9 при critical).
  • Пробное восстановление первой точки выполнено в пустую БД и пустой каталог на другом томе или сервере, отдельный экземпляр API проверен: вход, каталог, скачивание контрольного файла (restore). Статуса restore drill в продукте пока нет (B4): дату и результат пробы ведёт оператор. Повторяйте пробу по своему регламенту и после обновлений со сменой схемы.
  • Решено, где хранится вторая копия. Offsite/immutable профиль и S3 встроенно не поддерживаются (B3/B4); реплика vault средствами NAS — это копия тома, а не проверенная Arkvory точка: проверяйте восстановление из неё.

6. Мониторинг и журналы

  • Prometheus собирает GET /health/metrics с ключом из п. 4 (job arkvory), подключены правила оповещений: недоступность, 5xx, задержки, очередь завершения, допуск передач, журнал, срок сертификата, возраст копии, агент, предупреждения копий и повторные перезапуски (метрики).
  • Место на томах storage, vault и PostgreSQL контролируется node_exporter / postgres_exporter: метрик свободного места storage и БД у Arkvory нет, для vault есть только предупреждение vault_low_space. Готовые правила — arkvory-host-alerts.yml; перед подключением замените в них mountpoint на свои тома.
  • Журналы собираются: journald (arkvory-api, -worker, -backup, -update) или <root>/logs на Windows (20 MiB × 5), Compose — logs. Ошибки клиентов ищутся по requestId из ответа или вывода CLI.
  • Оповещение проверено вживую: например, остановка arkvory-backup вызывает ArkvoryBackupAgentOffline примерно через 7–8 минут (2 минуты без heartbeat, затем for: 5m правила и интервал опроса Prometheus).

7. Обновления

  • Выбран режим: автоматические stable-обновления в окно или pin версии с ручным update (UPDATES). Любое обновление — перерыв обслуживания, не rolling update.
  • Решено про статистику ProAnimaStudio (по умолчанию включена; configure --statistics off) и канал обновлений; сервер имеет исходящий HTTPS к hub.proanima.net и github.com/objects.githubusercontent.com или обновляется вручную из файлов (UPDATES).
  • Для релизов со сменой схемы подключён vault и есть хотя бы одна завершённая копия. Тогда установщик сам снимает и проверяет свежую точку перед миграцией (UPDATES). Без vault: перед upgrade --backup-record сделана и проверена точка (arkvoryctl backup run, затем backup verify <id>); файл — запись оператора, а не доказательство полноты копии.
  • Процедура после аварии updater известна: journal, operation.lock, recover.

8. Приёмка перед открытием доступа

  • С клиентской машины по HTTPS: вход в консоль, загрузка и скачивание контрольного файла ключом CI, совпадение SHA-256.
  • Перезапуск сервера: все три службы поднимаются сами, /health/status 200, агент online.
  • Выполнены пункты 5 (первая копия и пробное восстановление) и 6 (оповещение пришло).

Ограничения профиля

  • Один сервер: автоматического failover нет. Вторая площадка с зеркалами и ручным переходом — SECOND_SITE; синхронный HA одной площадки реализован только для Linux отдельным профилем (ADR 0072, wiki «High availability cluster»), этот чек-лист его не покрывает.
  • На Windows записи каталога хранилища не синхронизируются на диск (fsync каталога недоступен, ADR 0004): потеря питания вскоре после публикации может оставить артефакт без файла. Нужны ИБП и диск с защищённым кэшем записи; восстановление — из резервной копии или зеркала (RELIABILITY).
  • Vault шифруется приложением по умолчанию; recovery kit хранится вне сервера (два экземпляра в двух местах) и проверяется (vault key verify --vault <каталог> --key-file <kit>): без kit и ключа агента копии не прочитать. Vault без шифрования (--no-encryption) оставляет шифрование и права тома обязанностью оператора. Шифрование не скрывает имена, размеры и число точек; удаление слота не перешифровывает прежние точки.
  • Нет S3/restic, offsite и immutable профиля, мастера восстановления и статуса restore drill (BACKUP_RECOVERY).
  • На Windows API, worker и агент работают под общей учётной записью LocalService.
  • Проверки служб, нативных установщиков, контейнеров и HA выполняются на подходящих одноразовых стендах; публичный CI содержит обязательную матрицу (CI). Локальный прогон без нужной инфраструктуры не считается прошедшим. Для модулей Pro дополнительно проверьте совместимость, восстановление и ограничения.