Admin/han-app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Перенесены секреты из .env в SM

Browse Source
This commit is contained in:
mi
2026-07-30 19:22:48 +03:00
parent 049c45db5c
commit e24ed9d8ef
58 changed files with 3350 additions and 1054 deletions
Download Patch File Download Diff File Expand all files Collapse all files
releases/#0 deploy-steps.md
+99 -537
View File
@@ -1,555 +1,117 @@
# usefull commands
- Убрать переносы строк: sed -i 's/\r$//' name-file.sh
- find . -type f \( -name '*.sh' -o -name 'validate-env' \) -exec dos2unix {} +
- docker compose stop # мягко останавливает контейнеры (не удаляет)
- sudo shutdown -h now # выглючить ВМ
- Генерация паролей
- (со спец.символами) openssl rand -base64 32
- (без спец.символов) openssl rand -hex 16
- openssl rand -base64 16 | xclip -selection clipboard # Linux
# Release #0: безопасный порядок развертывания
Посмотреть состояние контейнеров
docker compose ps --format "table {{.Service}}\t{{.Status}}\t{{.Ports}}"
Этот файл больше не является журналом реальных адресов, SSH-ключей и локальных
путей. Фактические значения инфраструктуры хранятся в защищённой CMDB/ops wiki,
а не в Git.
Туннель до БД: ssh -i C:\Users\MI\.ssh\hansel -L 5433:192.168.0.211:5432 root@135.106.164.58 -N
## 1. Подготовка ВМ
#Обновление проекта
mkdir -p ~/.ssh
cp /mnt/c/Users/MI/.ssh/hansel ~/.ssh/hansel
chmod 600 ~/.ssh/hansel
Разрешите извне только 80/443 и SSH из административной сети. PostgreSQL
доступен ВМ только через приватную сеть.
1. Скопировать и автоматически почистить артефакты
Когда вы убедитесь, что вывод предыдущей команды вас устраивает, просто уберите флаг -n:
rsync -rltD --no-perms --no-owner --no-group -ivc --delete \
```sh
scp -i <DEPLOY_SSH_KEY> deployment/scripts/setup-vm.sh \
<CLOUD_USER>@<VM_IP>:/tmp/setup-vm.sh
ssh -i <DEPLOY_SSH_KEY> <CLOUD_USER>@<VM_IP>
sudo chmod 0755 /tmp/setup-vm.sh
sudo /tmp/setup-vm.sh
```
После создания пользователя `deploy` проверьте отдельную SSH-сессию до
отключения root login. Не копируйте приватный ключ на ВМ.
## 2. Доставка приложения
Предпочтительно использовать Git либо архив без runtime-данных:
```sh
tar -C HAN_chat_specification/codebase/backend \
--exclude='.env' \
--exclude='*.crt' \
--exclude='*.pem' \
--exclude='*.key' \
--exclude='secrets/' \
--exclude='node_modules/' \
--exclude='dist/' \
--exclude='.expo/' \
--exclude='playwright-report/' \
--exclude='test-results/' \
--exclude='*.log' \
-e "ssh -i ~/.ssh/hansel" \
/mnt/c/Users/MI/Documents/Assistent/HAN_chat_specification/codebase/backend/ \
root@135.106.164.58:/opt/han-chat/backend/
--exclude='secrets' \
--exclude='backups' \
-czf han-chat-backend.tar.gz .
scp -i <DEPLOY_SSH_KEY> han-chat-backend.tar.gz deploy@<VM_IP>:/tmp/
```
-r — рекурсивно.
-l — сохранять символические ссылки.
-t — сохранять время модификации (важно для будущих проверок).
-D — сохранять устройства (на всякий случай, как в -a).
--no-perms --no-owner --no-group — главное исправление: не пытаться копировать права, владельца и группу с Windows на Linux. Это избавит от ложных срабатываний.
-i — покажет только реально измененные файлы (можно заменить на -v, если хотите просто список).
-a (archive) — сохраняет права, время и рекурсивно копирует.
-v (verbose) — выводит список файлов.
-n (dry-run) — главный флаг, показывает, что бы произошло, но не делает этого.
--delete — решение вашей проблемы. Говорит rsync удалять на приемнике (ВМ) файлы, которых нет в источнике (локально).
Важно: не забудьте поставить слэш / в конце пути к локальному проекту, иначе rsync скопирует саму папку внутрь папки на ВМ.
2. Копирование env (опционально)
scp -i C:\Users\MI\.ssh\hansel -r "C:\Users\MI\Documents\job\HAN_new_life\HANapp\Production\.env" root@135.106.164.58:/opt/han-chat/backend
На ВМ:
```sh
sudo install -d -o deploy -g deploy -m 0755 /opt/han-chat/backend
sudo -u deploy tar -C /opt/han-chat/backend \
-xzf /tmp/han-chat-backend.tar.gz
cd /opt/han-chat/backend
find . -type f \( -name '*.sh' -o -name 'validate-env' \) -exec dos2unix {} +
chmod +x scripts/validate-env deployment/scripts/*.sh redis/scripts/*.sh nginx/scripts/*.sh
docker compose --env-file .env build frontend-static keycloak
docker compose --env-file .env up -d \
--no-deps \
--force-recreate frontend-static keycloak
Посмотреть состояние контейнеров
docker compose ps --format "table {{.Service}}\t{{.Status}}"
docker compose ps --format "table {{.Service}}\t{{.Status}}\t{{.Ports}}"
# Архивный способ копирования:
cd /tmp
rm han-chat-backend.tar.gz
cd /opt/han-chat/backend
#команда складывает архив в ту папку, из которой запускается команда
cd C:\Users\MI\Documents\Assistent\
rm C:\Users\MI\Documents\Assistent\han-chat-backend.tar.gz
tar -C C:\Users\MI\Documents\Assistent\HAN_chat_specification\codebase\backend -czf han-chat-backend.tar.gz .
scp -i C:\Users\MI\.ssh\hansel C:\Users\MI\Documents\Assistent\han-chat-backend.tar.gz root@135.106.164.58:/tmp/han-chat-backend.tar.gz
tar -xzf /tmp/han-chat-backend.tar.gz
find . -type f \( -name '*.sh' -o -name 'validate-env' \) -exec dos2unix {} +
chmod +x scripts/validate-env deployment/scripts/*.sh redis/scripts/*.sh nginx/scripts/*.sh
docker compose --env-file .env build frontend-static keycloak
docker compose --env-file .env up -d \
--no-deps \
--force-recreate frontend-static keycloak
# Разворачиваем инфраструктуру в Селектел ч1
## Создание сети
## Создание групп безопасности для сети и для БД
Для сети открываем порты 80, 22, 443
Для БД открываем порты 5432, 5433 но только из CIDR (192.168.0.211\24)
## Создаем ВМ, подключаем к новой сети (через порт) и перезагружаем (либо руками вводить новые сетевые настройки - надо выбрать)
# Подключение к ВМ и первичный скрипт
++ ssh -i C:\Users\MI\.ssh\hansel root@135.106.164.58
++ scp -i C:\Users\MI\.ssh\hansel -r "C:\Users\MI\Documents\Assistent\HAN_chat_specification\codebase\backend\deployment\scripts\setup-vm.sh" root@135.106.164.58:/tmp/setup-vm.sh
chmod +x /tmp/setup-vm.sh
sudo /tmp/setup-vm.sh
# Скрипт создал деплой пользователя. Нужно Перенести туда публичный ключ и дать права на файл и папку
## Вставляем публичный ключ новой строкой Далее даем права
sudo nano /home/deploy/.ssh/authorized_keys
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
## Пароль деплою для использования sudo
sudo passwd deploy
## После этого можно подключаться под деплой пользователем
ssh -i C:\Users\MI\.ssh\han_chat_deploy deploy@135.106.164.58
## GIT не работал. Проект пришлось копировать.
tar -C HAN_chat_specification/codebase/backend -czf han-chat-backend.tar.gz .
scp -i C:\Users\MI\.ssh\han_chat_deploy C:\Users\MI\Documents\Assistent\han-chat-backend.tar.gz deploy@135.106.164.58:/tmp/
scp -i C:\Users\MI\.ssh\hansel C:\Users\MI\Documents\Assistent\han-chat-backend.tar.gz root@135.106.164.58:/tmp/
## Дальше распаковка
cd /opt/han-chat/backend
tar -xzf /tmp/han-chat-backend.tar.gz
## Правим переносы строк и даем права на исполнение
find . -type f \( -name '*.sh' -o -name 'validate-env' \) -exec dos2unix {} +
chmod +x scripts/validate-env deployment/scripts/*.sh redis/scripts/*.sh nginx/scripts/*.sh
# Разворачиваем инфраструктуру в Селектел ч2
## Создаем БД
В базе подключаем pgcrypto
Чтобы корректно работал PgBouncer выбираем session pooling
### Копируем СА сертификат
Вариант Деплоя:
mkdir -p /opt/han-chat/backend/secrets/pg
scp -i C:\Users\MI\.ssh\han_chat_deploy -r C:\Users\MI\Documents\job\HAN_new_life\HANapp\Production\sertificates\CA.pem deploy@135.106.164.58:/opt/han-chat/backend/secrets/pg/ca.pem
chmod 644 /opt/han-chat/backend/secrets/pg/ca.pem
Вариант Селектела:
mkdir -p ~/.postgresql/
wget https://storage.dbaas.selcloud.ru/CA.pem -O ~/.postgresql/root.crt
chmod 0600 ~/.postgresql/root.crt
### Правки DNS-маршрутизации (в прошлый раз, какие-то трабблы были с базовой маршрутизацией) - скрипт ниже создаст
sudo tee /etc/netplan/99-han-dns.yaml <<'EOF'
network:
version: 2
ethernets:
eth0:
nameservers:
addresses:
- 8.8.8.8
- 1.1.1.1
search:
- selcloud.ru
eth1:
dhcp4-overrides:
use-dns: false
use-domains: false
EOF
sudo chmod 600 /etc/netplan/99-han-dns.yaml
sudo netplan apply
resolvectl flush-caches
### Проверка подключения к Postgers в ВМ
nc -zv 192.168.0.211 5433
sudo apt update
sudo apt install postgresql-client
psql "host=master.ef54e3e4-ad3d-4b80-a6af-d63269e0895a.c.dbaas.selcloud.ru \
port=5432 \
dbname=han_chat \
user=dbAdmin \
sslmode=verify-ca"
(psql "host=master.ef54e3e4-ad3d-4b80-a6af-d63269e0895a.c.dbaas.selcloud.ru port=5432 dbname=han_chat user=dbAdmin sslmode=verify-ca")
### Заводим пользователей и схемы
Пользователей создаем через интерфейс селектела.
Под админом даем права на создание в БД:
GRANT CREATE ON DATABASE han_chat TO han_app;
GRANT CREATE ON DATABASE han_chat TO bitrix_local_app;
GRANT CREATE ON DATABASE han_chat TO bitrix_sync_user;
GRANT CREATE ON DATABASE han_chat TO message_safety_app;
GRANT CREATE ON DATABASE han_chat TO keycloak_user;
GRANT CREATE ON DATABASE han_chat TO sms_user
Если создаем пользователей после того как отозвали права from public, надо давать гранты на коннект:
GRANT CONNECT ON DATABASE han_chat TO sms_user
Схемы создаем от лица пользователей, заходя каждым из них в БД.
+ Запрещаем всем посторонним входить в схему han_app и др.
CREATE SCHEMA IF NOT EXISTS han_app;
REVOKE ALL ON SCHEMA han_app FROM PUBLIC;
ALTER ROLE CURRENT_USER IN DATABASE han_chat SET search_path TO han_app;
SHOW search_path; --чтобы заработало надо переподключиться (должно быть han_app)
CREATE SCHEMA IF NOT EXISTS bitrix_local;
REVOKE ALL ON SCHEMA bitrix_local FROM PUBLIC;
ALTER ROLE CURRENT_USER IN DATABASE han_chat SET search_path TO bitrix_local;
SHOW search_path; --чтобы заработало надо переподключиться
CREATE SCHEMA IF NOT EXISTS bitrix_sync;
REVOKE ALL ON SCHEMA bitrix_sync FROM PUBLIC;
ALTER ROLE CURRENT_USER IN DATABASE han_chat SET search_path TO bitrix_sync;
SHOW search_path; --чтобы заработало надо переподключиться
CREATE SCHEMA IF NOT EXISTS message_safety;
REVOKE ALL ON SCHEMA message_safety FROM PUBLIC;
ALTER ROLE CURRENT_USER IN DATABASE han_chat SET search_path TO message_safety;
SHOW search_path; --чтобы заработало надо переподключиться
CREATE SCHEMA IF NOT EXISTS keycloak;
REVOKE ALL ON SCHEMA keycloak FROM PUBLIC;
ALTER ROLE CURRENT_USER IN DATABASE han_chat SET search_path TO keycloak;
SHOW search_path; --чтобы заработало надо переподключиться
CREATE SCHEMA IF NOT EXISTS sms AUTHORIZATION sms_user;
REVOKE ALL ON SCHEMA sms FROM PUBLIC;
ALTER ROLE sms_user IN DATABASE han_chat SET search_path TO sms, public;
SHOW search_path;
Проверка search_path
SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting s
JOIN pg_roles r ON r.oid = s.setrole
JOIN pg_database d ON d.oid = s.setdatabase
WHERE r.rolname in ('han_app',
'bitrix_local_app',
'bitrix_sync_user',
'message_safety_app',
'keycloak_user');
После реализации bitrix_sync (проверить, вероятно не на все таблицы права нужны):
-- Даем право на чтение (SELECT) всех СУЩЕСТВУЮЩИХ таблиц в схеме
GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA han_app TO bitrix_sync_user;
-- Настраиваем права по умолчанию для новых таблиц
ALTER DEFAULT PRIVILEGES IN SCHEMA han_app
GRANT SELECT ON TABLES TO bitrix_sync_user;
-- Если нужно дать право на чтение и для новых последовательностей (sequences):
ALTER DEFAULT PRIVILEGES IN SCHEMA han_app
GRANT USAGE, SELECT ON SEQUENCES TO bitrix_sync_user;
## Заводим S3 хранилища:
Создаем 2 сервисных пользователя и заводим им ключи:
- API backend SELECTEL_S3_ACCESS_KEY / SELECTEL_S3_SECRET_KEY
- Message Safety SELECTEL_S3_QUARANTINE_READ_ACCESS_KEY / SELECTEL_S3_QUARANTINE_READ_SECRET_KEY
Создаем 3 приватных бакета
- han-chat-quarantine (политика доступа API backend RW, Message Safety R)
- han-chat-attachments (политика доступа API backend RW)
- han-chat-documents (политика доступа API backend RW)
RW:
ListBucket
GetBucketLocation
PutObject
GetObject
DeleteObject
ListBucketMultipartUploads
ListMultipartUploadParts
AbortMultipartUpload
R:
ListBucket
GetBucketLocation
GetObject
ListBucketMultipartUploads
ListMultipartUploadParts
Политика CORS (бакет han-chat-quarantine, vHosted обязателен):
Allowed origin: https://chat.han0107.ru
Methods: POST, PUT, GET, HEAD
Headers: * (или явно content-type; wildcard x-amz-* в Selectel не работает)
Expose headers: ETag
# Тест инфраструктуры
mkdir -p /opt/han-chat/infratest
cd /opt/han-chat/infratest
scp -i C:\Users\MI\.ssh\hansel -r "C:\Users\MI\Documents\Assistent\HAN_chat_specification\infratest\*" root@135.106.164.58:/opt/han-chat/infratest
--настраиваю env на локальной машине и копирую на диск
scp -i C:\Users\MI\.ssh\hansel -r "C:\Users\MI\Documents\job\HAN_new_life\HANapp\Production\.env" root@135.106.164.58:/opt/han-chat/infratest/
Создаем изолированное окружение:
python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install -r requirements.txt
Если не работает, то надо DNS переправить на eth0
resolvectl dns eth0 1.1.1.1 8.8.8.8
resolvectl domain eth0 '~.'
resolvectl flush-caches
resolvectl query pypi.org
# Подготовка к запуску
Сертификат рекомендуется скопировать в папку с секретами
cp /root/.postgresql/root.crt /opt/han-chat/backend/secrets/pg/root.crt
chmod 644 /opt/han-chat/backend/secrets/pg/root.crt
В битрикс регистрируем локальное приложение:
Установка: https://chat.example.ru/bitrix/install
Обработчик: https://chat.example.ru/bitrix/handler
??? (не понадобилось) Placement: https://chat.example.ru/bitrix/placement
--настраиваю env на локальной машине и копирую на диск
scp -i C:\Users\MI\.ssh\hansel -r "C:\Users\MI\Documents\job\HAN_new_life\HANapp\Production\.env" root@135.106.164.58:/opt/han-chat/backend
--Проверка .env
cd /opt/han-chat/backend
chmod 600 .env
sudo find . -type f \( -name '*.sh' -o -name 'validate-env' \
-o -name 'han-secrets' -o -name 'han-compose' \) \
-exec dos2unix {} +
sudo chmod 0755 scripts/validate-env deployment/scripts/*.sh \
deployment/secrets/han-secrets deployment/secrets/han-compose \
redis/scripts/*.sh nginx/scripts/*.sh
sudo deployment/scripts/setup-vm.sh
```
## 3. Несекретная конфигурация
`.env` создаётся на самой ВМ из `.env.example` и содержит только URL, resource
names, feature flags и `SECRETS_SOURCE`. Его разрешено передавать как обычный
config, но запрещено добавлять credential-bearing DSN, password, token и key.
```sh
cp .env.example .env
chmod 0600 .env
nano .env
./scripts/validate-env .env
docker compose --env-file .env config --quiet
docker compose --env-file .env config --services
```
## 4. Selectel Secrets Manager
Выполните `deployment/secrets/SELECTEL_RUNBOOK.ru.md`:
1. отдельный проект и service user;
2. provider secrets и audit alerts;
3. root-only JSON-карта;
4. encrypted systemd credential;
5. `SECRETS_SOURCE=selectel`.
Не передавайте значение секрета аргументом команды, через `export`, тикет или
shell history. Старые значения из прежнего `.env` после cutover ротируются.
## 5. Проверка и запуск
```sh
sudo systemctl daemon-reload
sudo systemctl enable han-secrets@production.service
sudo systemctl restart han-secrets@production.service
sudo ./scripts/validate-env .env \
--runtime-manifest /run/han-chat/secrets/manifest
sudo deployment/secrets/han-compose config --quiet
python3 -m unittest discover -s tests -v
--Проверка портов (Публиковаться должны только 80 и 443 у nginx)
docker compose --env-file .env config | grep -n 'published:'
--Собираем локальные образы:
docker compose --env-file .env build --pull
docker compose --env-file .env images
## Миграции БД и начальные настройки
cd /opt/han-chat/backend
PITR_MARKER_CONFIRMED=true deployment/scripts/migrate.sh
deployment/scripts/seed.sh
## Запуск внутренних сервисов
Сначала запустите Redis:
```sh
docker compose --env-file .env up -d redis
docker compose --env-file .env ps redis
sudo deployment/secrets/han-compose build --pull
sudo deployment/scripts/migrate.sh
sudo deployment/secrets/han-compose up -d --wait
sudo deployment/scripts/smoke.sh
```
Затем Keycloak и OpenTelemetry:
Для диагностики используйте `han-compose ps` и ограниченные logs. Не выводите
resolved Compose config, `docker inspect` environment, полный `env` или secret
files.
## 6. Откат
Откат приложения использует immutable image/release ID и подтверждённую
совместимость схемы:
```sh
docker compose --env-file .env up -d keycloak otel-collector
docker compose --env-file .env ps keycloak otel-collector
sudo SCHEMA_BACKWARD_COMPATIBLE_CONFIRMED=true \
deployment/scripts/rollback.sh <PREVIOUS_RELEASE>
```
Первый запуск Keycloak может занять несколько минут: он создаст свои таблицы и
импортирует realm `han-chat`.
Откат секрета выполняется активацией предыдущей версии в Selectel, повторным
sync и пересозданием только затронутых сервисов. Snapshot старого `.env` не
создаётся.
После готовности Keycloak:
## 7. Break-glass
```sh
docker compose --env-file .env up -d message-safety
docker compose --env-file .env up -d api-backend
docker compose --env-file .env up -d bitrix-local-app bitrix-sync
docker compose --env-file .env up -d \
delivery-worker safety-recovery-worker cleanup-worker
docker compose --env-file .env ps
```
Если сервис не становится healthy:
```sh
docker compose --env-file .env logs --tail=200 <SERVICE_NAME>
docker inspect "$(docker compose --env-file .env ps -q <SERVICE_NAME>)"
```
## Первоначальный выпуск TLS-сертификата
Для ACME требуется работающий nginx по HTTP. В `.env` оставьте
`NGINX_TLS_ENABLED=true`, но первый nginx запустите с временным переопределением:
```sh
NGINX_TLS_ENABLED=false \
docker compose --env-file .env up -d frontend-static nginx
```
Проверьте HTTP:
```sh
curl -I http://chat.han0107.ru/
```
Сначала рекомендуется проверить Certbot через staging:
```sh
docker compose --env-file .env --profile certbot run --rm certbot certonly \
--staging \
--webroot -w /var/www/certbot \
-d chat.han0107.ru \
--cert-name chat.han0107.ru-staging \
--email ap@han.ru \
--agree-tos --no-eff-email --non-interactive
```
После успешного staging-теста выпустите рабочий сертификат с основным cert-name
без `--staging`:
```sh
docker compose --env-file .env --profile certbot run --rm certbot certonly \
--webroot -w /var/www/certbot \
-d chat.han0107.ru \
--cert-name chat.han0107.ru \
--email ap@han.ru \
--agree-tos --no-eff-email --non-interactive
```
Пересоздайте nginx уже с TLS:
```sh
docker compose --env-file .env up -d --force-recreate nginx
docker compose --env-file .env exec -T nginx nginx -t -c /tmp/nginx.conf
curl -I https://chat.han0107.ru/
```
Повторно запустите VM setup, чтобы он обнаружил проект и установил systemd-таймер
продления сертификата:
```sh
sudo /opt/han-chat/backend/deployment/scripts/setup-vm.sh
systemctl status han-chat-ssl-renew.timer
## Запуск всего контура
Теперь можно привести весь проект к состоянию, описанному Compose:
```sh
cd /opt/han-chat/backend
docker compose --env-file .env up -d
docker compose --env-file .env up -d --wait \
api-backend keycloak sms-service bitrix-local-app
# Nginx разрешает имена upstream при загрузке конфигурации. Если upstream
# был пересоздан и получил новый Docker IP, без reload edge продолжит ходить
# на старый адрес и вернёт 502.
docker compose --env-file .env exec -T nginx nginx -t -c /tmp/nginx.conf
docker compose --env-file .env kill -s HUP nginx
docker compose --env-file .env ps
```
Проверьте, что контейнеры не перезапускаются:
```sh
docker compose --env-file .env ps
docker compose --env-file .env logs --since=10m
```
## Публичная проверка
Запустите smoke-тест:
```sh
cd /opt/han-chat/backend
deployment/scripts/smoke.sh
```
Также вручную проверьте:
```sh
curl -fsS https://chat.han0107.ru/api/v1/public/app-config | jq
curl -fsS https://chat.han0107.ru/api/v1/public/content | jq
curl -fsS \
https://chat.han0107.ru/auth/realms/han-chat/.well-known/openid-configuration | jq
```
Если после `up`, `build`, `pull`, rollback или `--force-recreate` менялись
`api-backend`, `keycloak`, `sms-service` либо `bitrix-local-app`, всегда
повторяйте проверку `/tmp/nginx.conf` и `docker compose kill -s HUP nginx`.
Команды `nginx -t`/`nginx -s reload` без `-c /tmp/nginx.conf` здесь неверны:
контейнер read-only и рабочий PID расположен в `/tmp/nginx.pid`.
Внутренний API не должен быть опубликован:
```sh
curl -i https://chat.han0107.ru/internal/safety/v1/messages/check
```
Ожидаемый статус — `404`.
Откройте в браузере:
```text
https://chat.example.ru/
```
Для тестовой авторизации используйте значение `KEYCLOAK_OTP_MOCK_CODE` из `.env`.
Настройки keykcloack:
Для битрикса код установки приложения:
docker compose --env-file .env exec -T api-backend python - <<'PY'
import os
import urllib.request
base = os.environ["BITRIX_LOCAL_APP_BASE_URL"]
token = os.environ["BITRIX_LOCAL_APP_INTERNAL_TOKEN"]
request = urllib.request.Request(
base + "/internal/openlines/v1/setup/retry",
method="POST",
headers={"Authorization": "Bearer " + token},
)
print(urllib.request.urlopen(request).read().decode())
PY
## План включения реальной SMS-авторизации
Этот раздел — чек-лист будущего release из `modules/module-11-idgtl-sms.md`, а не подтверждение готовности текущего Compose. Пока отсутствуют реализованные `sms-service`/worker, migrations, callback route и env validation, оставлять `KEYCLOAK_OTP_MOCK_ENABLED=true`.
Prerequisites без placeholders:
- согласованные i-Digital sender и active approved template `auth_otp` с placeholders `code`, `ttl_min`;
- выданный Direct `TOKEN_1` (`IDGTL_SMS_API_KEY`, без повторного Base64);
- отдельные random callback username/password и публичный HTTPS URL;
- повторно подтверждённый source IP callback Direct;
- фактический статический egress IP, измеренный из `sms-worker`, записанный в inventory и переданный Direct для allowlist; при динамическом IP сначала настроить NAT/static IP.
Rollout:
1. Seed новых `otp.phone.*` в App DB.
2. Создать schema/role `sms`, применить versioned migrations и seed template/settings.
3. Проверить Keycloak→`sms-service`→локальный mock Direct в test environment.
4. Развернуть production `sms-service`/worker и nginx callback route, не выключая mock.
5. Применить Keycloak expand migration/SPI; прежние незавершённые challenges истечь по module-11.
6. Выполнить provider smoke на контролируемом номере; проверить `sms_message_id`, journal, callback и redaction.
7. Переключить `KEYCLOAK_OTP_MOCK_ENABLED=false`.
8. Проверить resend→`superseded`, expiry snapshot, limits и то, что Direct reject/timeout после durable order не меняет verify.
Rollback: вернуть Keycloak в mock mode; не удалять schema/journal. Остановить новые real orders, дать worker завершить либо зафиксировать in-flight/`uncertain`. Schema downgrade только при доказанной backward compatibility, иначе forward-fix.
Только при подтверждённом инциденте доставьте root-only recovery file из
защищённой офлайн-копии, установите `SECRETS_SOURCE=file`, выполните
sync/validate/recreate и зафиксируйте событие. Автоматический fallback запрещён.
После восстановления Selectel верните штатный режим и удалите recovery file.