Деплои

При каждом деплое Lizard собирает и выпускает одну версию сервиса. Сервисы работают как поды Kubernetes. Успешная сборка сама по себе не гарантирует, что приложение запустилось или может обслуживать запросы.

Как происходит деплой

Деплой запускается при любом из следующих событий:

• git push в отслеживаемую ветку (для сервисов из github).
• lizard redeploy — повторная сборка из последнего коммита (git) или последней загрузки с текущими переменными.
• lizard up — загрузка текущей директории и её деплой.
• service set, изменяющее поле, влияющее на сборку.

lizard redeploy --service api      # rebuild + redeploy from current source
lizard up                          # upload cwd and deploy

Жизненный цикл

1. Сборка — платформа запускает вашу сборку (см. Конвейер сборки).
2. Пред-деплой: если заданы и preDeployCommand, и startCommand, контейнер выполняет sh -c "<pre> && exec <start>". Команда пред-деплоя запускается при старте каждого контейнера (каждой реплики, при каждом перезапуске), поэтому она должна быть безопасной при многократном и одновременном выполнении. Без startCommand этот шаг пропускается.
3. Запуск — Lizard запускает новый под рядом со старым. У воркеров сначала останавливается старый под.
4. Проверка работоспособности — TCP-проба проверяет порт приложения каждые 2 секунды, и трафик переключается только на готовый под. Lizard ждёт его примерно 30 секунд; если новый под к этому времени не готов, деплой помечается как неудачный. Воркеры пропускают пробу.
5. Верификация — проверьте статус выпуска и вызовите URL приложения. Доступность порта — не полная проверка работоспособности приложения.

Потоковый вывод

При запуске не-детачированного lizard up (или redeploy) логи сборки стримятся в прямом эфире. С --json вы получаете по одному JSON-событию на строку:

{ "event": "log", "line": "..." }
{ "event": "deployed", "status": "...", "url": "https://..." }

завершающееся deployed, failed или deploying. Используйте --detach, чтобы запустить деплой и вернуть управление сразу, без стриминга.

Просмотр истории

lizard events                  # deploy history + per-replica status
lizard events --limit 25       # show more
lizard ps                      # current services, status, and URLs

В дашборде представление Деплои показывает полную таймлайн, логи сборки для каждого деплоя и панель деталей для каждого выпуска.

Перезапуск против повторного деплоя

См. lizard restart и lizard redeploy. Используйте restart для перезапуска реплик (например, чтобы подхватить секрет среды выполнения, который не применился горячей перезагрузкой); используйте redeploy, когда нужна новая сборка.

Восстановление после сбоя

Посмотрите логи последнего сбоя или перезапуска:

lizard logs --restart latest       # log tail around the latest restart
lizard logs --restart <id>         # a specific restart
lizard events                      # see replica status

Изменения конфигурации (без пересборки)

Большинство изменений переменных окружения и секретов применяются без пересборки: Lizard обновляет конфигурацию сервиса и перезапускает его, что занимает несколько секунд. Значения времени сборки (VITE_*, NEXT_PUBLIC_*) и изменения полей сборки заставляют пересобирать работающий сервис — см. таблицу триггеров пересборки и переменные времени сборки.

Неудачные выпуски и восстановление

Неудачная сборка и неудачный запуск приложения по-разному влияют на сервис. В обоих случаях HTTP-сервис, который уже работает, продолжает обслуживать запросы своей предыдущей версией: неудачная сборка ничего не меняет, а новый под, который так и не стал готовым, не получает трафик. Старый под воркера останавливается до запуска нового, поэтому неработающий выпуск воркера оставляет систему без запущенного воркера. Проверьте активный сервис, логи сборки и логи среды выполнения. lizard redeploy собирает выбранный источник заново; это не команда для восстановления предыдущей сборки. При необходимости верните исходный коммит, задеплойте его и проверьте результат. См. известные проблемы.

Обновлено 12 октября 2026 г.