lizard restart
Постепенный перезапуск текущей сборки — без пересборки.
Использование
lizard restart [nameOrId] [flags]Флаги
| Флаг | Описание |
|---|---|
-s, --service <name> | Сервис |
-p, --project <id> | Имя, slug или ID проекта |
--detach | Вернуться после принятия перезапуска, не опрашивая его статус |
--wait | Ждать готовности новой попытки перезапуска; работает с --json |
--timeout <seconds> | Бюджет ожидания готовности с --wait; по умолчанию 120 |
--json | Вернуть JSON для скриптов |
Примеры
Перезапустить сервис
lizard restart --service apiВернуться, не дожидаясь
lizard restart --service api --detachПодождать перед запуском следующей проверки
lizard --json restart --service api --wait --timeout 120Без --wait JSON-режим возвращается после принятия перезапуска. С --wait результат включает ok, status, attemptId и waitedMs. CLI ждёт новую попытку перезапуска, поэтому неизменный статус от до запроса не считается успехом. Неудачное ожидание или таймаут возвращают ненулевой код выхода.
Сервис на паузе отклоняет перезапуск, пока вы его не возобновите.
Для HTTP-сервисов CLI также проверяет домен сервиса дважды. Рабочие процессы с containerPort=0 используют статус готовности из бэкенда и не требуют HTTP-слушателя, даже когда у них есть сгенерированный домен.
lizard --json restart --service worker --wait --timeout 60Таймаут применяется к ожиданию готовности после запроса на перезапуск. Он не отменяет перезапуск, а сетевые вызовы могут сделать общее время выполнения команды дольше. Проверьте данные приложения или эндпоинт здоровья после команды, когда вашему рабочему процессу требуется больше, чем готовность процесса.
См. также
- lizard redeploy — запустить свежую сборку вместо перезапуска текущей
- lizard logs — просмотреть логи вокруг перезапуска с
--restart latestили--restart <id> - Развёртывания — перезапуски против повторных развёртываний и восстановление после сбоя
Обновлено