## 1. Почему мой сервер останавливается при каждом деплое? {#sec-4f4fee2fcd28}

При работе над личными проектами нередко приходится补лять ограниченные ресурсы (микро‑инстансы GCP, Raspberry Pi и т.п.). Я управляю несколькими машинами: от мощных серверов для AI‑вычислений до скромных VM, едва поддерживающих DNS. Особенно мне нравится Raspberry Pi 5 — он работает круглосуточно без заметных расходов на электроэнергию и при этом достаточно производителен.

Но, как и любой «домашний питомец», если заставить его выполнять слишком много задач, появляются проблемы: при деплое процессор достигает 100 % из‑за Celery‑worker'ов. При одновременном запуске «синей» и «зелёной» групп количество воркеров удваивается, и система не справляется. Сократить их количество — значит замедлить обработку, а оставить как есть — риск полностью вывести сервер из строя.

![Изображение, символизирующее автоматический скрипт для слабого ПК](/media/editor_temp/6/feadd998-56ed-4ccb-9fca-acbb54ef62f2.png)

Для решения этой задачи я создал **кастомный скрипт Blue‑Green деплоя**, который минимизирует расход ресурсов и сохраняет надёжность.

---

## 2. Стратегия: экономим ресурсы, повышаем стабильность {#sec-84df4175f98f}

Обычный Blue‑Green деплой поднимает обе среды одновременно, но я внедрил несколько приёмов, чтобы снизить нагрузку на CPU:

1. **Предварительная остановка фоновых сервисов (Celery).** Прежде чем запустить новый веб‑сервер, я останавливаю тяжёлые фоновые задачи (Worker, Beat) старой версии, освобождая процессор.
2. **Постепенный запуск.** Сначала поднимаются только `Web + Redis`, после чего проходит health‑check.
3. **Human‑in‑the‑loop.** После завершения автоматических шагов администратор проверяет состояние и только потом удаляет старую версию.

Проблема заключалась в том, что сразу после инициализации Celery‑worker'ы получали задачи и пытались их выполнить, что резко повышало нагрузку. Снижение параметра concurrency помогало, но замедляло асинхронную обработку, чего я не хотел.

Идея заключалась в том, чтобы на этапе пере‑деплоя временно остановить старых Celery‑друзей, освободив CPU, а затем запустить новый код без простоев.

---

## 3. Ключевые фрагменты кода {#sec-049262c64613}

Полный проект доступен в моём [GitHub‑репозитории](https://github.com/mikihands/linuxscript/tree/main/zero-downtime). Ниже — несколько основных частей скрипта.

### ① Изоляция проектов с помощью Docker Compose {#sec-31c03a8ae526}

Опция `docker compose -p` позволяет создать отдельные проекты (namespace) `blue` и `green` даже при использовании одного и того же файла конфигурации.

```bash
dc() {
  # Динамически задаём имя проекта (-p) для изоляции окружения
  docker compose -f "$COMPOSE_FILE" "$@"
}
```

### ② Тщательная проверка состояния (Health Check) {#sec-d10311b76a14}

Трафик переключается только после того, как новая версия полностью готова.

```bash
health_check() {
  # Пытаемся получить 200 OK от указанного порта, максимум 10 попыток
  if curl -fsSIL --max-time "$HEALTH_TIMEOUT" "$url"; then
    ok "Health check passed"
    return 0
  fi
}
```

### ③ Откат в случае ошибки {#sec-53e921d110b5}

Если новая версия падает, мы мгновенно восстанавливаем старые сервисы, чтобы пользователи не заметили проблем. Вместо полного `rm -f` для Celery‑worker'ов и beat я использую карты `stop`, позволяющие быстро освободить CPU и при необходимости быстро перезапустить их.

---

## 4. Практический совет: эстетика «удалять после проверки» {#sec-cbbf7ab93b4f}

Последний шаг скрипта — не удалять старую версию автоматически, а вывести сообщение администратору:

> "Деплой завершён успешно. Проверьте работу вручную, и если всё в порядке, скопируйте команду ниже для очистки старой версии."

Эта небольшая защита убирает 1 % ошибок, которые автоматизация могла бы пропустить.

---

## 5. Заключение {#sec-942f631956ee}

Скрипт отражает мои размышления о том, как достичь максимальной эффективности при ограниченных ресурсах. Хотя он прост, я использую его каждый день и уверен, что он будет полезен и другим разработчикам с небольшими серверами.

**Полезные ссылки:**

* [Перейти к репозиторию на GitHub](https://github.com/mikihands/linuxscript/tree/main/zero-downtime)  
* [Автоматический деплой с GitHub Webhook — часть 5: Nginx, HTTPS и финальная интеграция](/ko/whitedec/2025/7/24/github-webhook-final-nginx-https/)  
* Пишите вопросы в комментариях или создавайте Issue в GitHub!