Основные понятияРазвёртывания

Деплои

Деплой — это одна сборка и выпуск сервиса. Путь выпуска зависит от среды выполнения сервиса. Успешная сборка сама по себе не гарантирует, что приложение запустилось или может обслуживать запросы.

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

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

  • 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, он выполняется один раз (например, миграции).
  3. Запуск — Lizard запускает приложение для настроенной среды выполнения.
  4. Проверка работоспособности — платформа проверяет, что порт приложения доступен (пропускается для воркеров).
  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 --service <svc>Перезапуск текущей сборки — без повторной сборки
lizard redeploy --service <svc>Новая сборка из последнего коммита/загрузки, затем выпуск

Используйте 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_*) и изменения полей сборки заставляют пересобирать — см. таблицу триггеров пересборки.

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

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

Конвейер сборкиОбзор