Skip to content

deploy.md

Latest commit

 

History

History
145 lines (108 loc) · 7.44 KB

deploy.md

File metadata and controls

145 lines (108 loc) · 7.44 KB
Raw

Деплой Provodox Lite в Yandex Cloud

Все команды — yc CLI. Подставь свои значения вместо <...>.

Деплой Lite — две команды по существу: создать функцию и создать шлюз. Конфигурировать нечего: апстрим (platform-api2.max.ru) зашит в src/index.js, переменных окружения нет, а значит нет ни Lockbox, ни сервис-аккаунтов, ни секретов, которые можно забыть выдать. Разворачивается с нуля примерно за десять минут и дальше работает само.

0. Предусловия: профиль и облако

Проверь, что активный профиль yc смотрит в нужные облако и каталог:

yc config list          # сверь cloud-id / folder-id
# при необходимости:
yc config set cloud-id <CLOUD_ID>
yc config set folder-id <FOLDER_ID>

(Опционально) отдельный каталог — так стенд изолирован от остальных ресурсов по правам, квотам и биллингу, и его удаление ничего лишнего не заденет:

yc resource-manager folder create --name provodox-lite

1. Функция-прокси

Собери чистый пакет только из нужных файлов. Не пакуй --source-path ./: туда попадут .git и прочее — лишнее в артефакте.

PKG=$(mktemp -d)
mkdir -p "$PKG/src"
cp src/index.js "$PKG/src/index.js"
cp package.json "$PKG/package.json"
yc serverless function create --name provodox-lite

yc serverless function version create \
  --function-name provodox-lite \
  --runtime nodejs18 \
  --entrypoint src/index.handler \
  --memory 128MB \
  --execution-timeout 120s \
  --source-path "$PKG"

Про --execution-timeout 120s: столько живёт запрос к апстриму. Дольше — рантайм снимает функцию, и клиент получает от шлюза 504 Gateway Timeout (не 502: до обработчика ошибок в коде дело не доходит, функция просто не успевает ответить). 120 секунд покрывают самый долгий вызов MAX (GET /updates принимает timeout до 90 с). Это не предел платформы: обычная функция допускает до 10 минут, API Gateway — тоже до 10 (по умолчанию 5). Скрытого 30-секундного потолка у шлюза нет, проверено замером.

Таймаут шлюза отдельный от таймаута функции и живёт в самом шлюзе, а не в интеграции:

yc serverless api-gateway get --name provodox-lite --format json | grep execution_timeout
# execution_timeout: 300s — дефолтные 5 минут, менять не нужно: 300 > 120

Вывод version create — YAML, а не JSON. Если разбираете его скриптом, передайте --format json: команда успевает создать версию до того, как разбор упадёт, и повторный запуск создаст дубликат.

Откат на прежнюю версию. Шлюз ходит в функцию по тегу $latest (см. api-gateway.yaml), а $latest — системный тег: он всегда указывает на самую свежую созданную версию и вручную не переназначается (yc ... version set-tag --tag '$latest' падает с Field does not match the pattern /[a-z][-_0-9a-z]*/). Поэтому при текущей конфигурации откат — это создание новой версии из прежнего кода.

Сделать вызов без авторизации (шлюз будет звать функцию без сервис-аккаунта):

yc serverless function allow-unauthenticated-invoke --name provodox-lite

Узнать FUNCTION_ID:

yc serverless function get --name provodox-lite --format json | grep '"id"'

2. API Gateway

Шлюз обязателен. Без него функция вызывается по https://functions.yandexcloud.net/<id>, а такой вызов не передаёт путь: /me в этом URL платформа считает частью идентификатора и отвечает 400 invalid functionID (проверено). Прозрачное проксирование путей MAX (/me, /messages, /updates) работает только через шлюз.

Подставь FUNCTION_ID в api-gateway.yaml (поле function_id) и создай шлюз:

sed "s/FUNCTION_ID/<FUNCTION_ID>/" api-gateway.yaml > /tmp/provodox-lite-apigw.yaml
yc serverless api-gateway create --name provodox-lite --spec /tmp/provodox-lite-apigw.yaml
yc serverless api-gateway get --name provodox-lite --format json | grep -i domain

Домен вида https://<id>.apigw.yandexcloud.net — это базовый URL прокси. Он выдан GlobalSign, поэтому ему доверяют среды без корня Минцифры. Своего домена и сертификата Lite не требует.

3. Проверка

BASE="https://<GATEWAY_ID>.apigw.yandexcloud.net"

# Без токена MAX — прокси до апстрима дошёл, забраковал уже MAX
curl -s "$BASE/me"
# 401 {"code":"verify.token","message":"No access token"}

# С токеном — JSON бота, HTTP 200
curl -s "$BASE/me" -H "Authorization: $MAX_TOKEN"

Первый ответ и есть главный признак живой цепочки: раз пришёл 401 от MAX (а не ошибка TLS и не ошибка шлюза), значит запрос прошёл через прокси и был принят апстримом. Любой 401 здесь приходит от MAX — собственных ответов прокси не подмешивает.

⚠️ С этого момента доступ к прокси — это знание его адреса. Пока адрес известен только вам, всё в порядке; попав к посторонним, он даёт им запросы к MAX за ваш счёт. Домен шлюза не публикуют. Там, где адрес не удержать в секрете, нужен контроль доступа — см. README, раздел «Куда это растёт».

4. Обновление и удаление

Обновить код — собрать пакет заново и создать новую версию (шлюз подхватит её сам, он ходит по $latest):

yc serverless function version create --function-name provodox-lite \
  --runtime nodejs18 --entrypoint src/index.handler \
  --memory 128MB --execution-timeout 120s --source-path "$PKG"

Убрать всё созданное:

yc serverless api-gateway delete --name provodox-lite
yc serverless function delete --name provodox-lite