Что такое zero-downtime?

Zero-downtime — это цель, при которой пользователи не замечают перерывов обслуживания при деплое: HTTP-запросы возвращают валидный ответ, соединения не обрываются, а кластер или сервер продолжает принимать трафик. На практике под "zero" обычно понимают Критерии измерения: процент ошибок (HTTP 5xx) в течение 2 минут после релиза, медианная задержка (p50) и p99. Для проектов с SLA 99.95% целевой рост ошибок при деплое — Zero-downtime — не магия: это комбинация graceful shutdown, контролируемого запуска процесса и инфраструктурных механизмов (socket activation / load balancer).

Как реализовать через systemd?

Systemd даёт два основных инструмента, полезных для zero-downtime: Socket activation — systemd владеет слушающим сокетом и передаёт его сервису; новый процесс не конфликтует за порт. Type=notify и sd_notify — сервис сообщает systemd, что готов, что позволяет отслеживать точки готовности и сокращать «время мёртвого окна». Комбинация socket activation + graceful shutdown (server.Shutdown с таймаутом) обеспечивает минимальные сбои при рестартах: старый процесс завершает текущие запросы, systemd передаёт новый слушающий сокет, новый процесс начинает обслуживать новые подключения. Для корректной работы необходимо: Имплементировать поддержку передачи Listener (coreos/go-systemd/activation). Вызывать sd_notify("READY=1") после того как все инициализировано и прослушивание FD передано (github.com/coreos/go-systemd/daemon). Настроить TimeoutStopSec в unit файле > graceful shutdown таймаута в коде. Пример вызова sd_notify в Go (псевдокод): import "github.com/coreos/go-systemd/daemon" //...

Альтернативы?

Socket activation + graceful shutdown — надёжный и минималистичный метод для одиночных инстансов. Если инфраструктура сложнее, есть альтернативы и дополнения: Load balancer + blue/green или canary deploys. Nginx/Haproxy/Envoy на фронте распределяет трафик между версиями, health checks выключают старые инстансы без потери соединений. Минус — требуется лишний слой и конфигурация, плюс стоимость ресурсов (две версии одновременно). Kubernetes rolling updates. K8s делает rolling-update с readiness probes и liveness probes, даёт встроенные инструменты для zero-downtime при корректной конфигурации probe и preStop hooks. Требует знания K8s и затрат на кластер. Re-exec библиотеки (tableflip). Cloudflare tableflip позволяет родительскому процессу передать слушающие FDs новому процессу и корректно переключаться; даёт очень низкий downtime для long-lived connections, но добавляет сложность в код. SO_REUSEPORT + multiple instances. Подходит для горизонтального масштабирования: запускаешь N...

Как быстро проверить, работает ли socket activation?

Запустите только socket unit: sudo systemctl start myapp.socket, затем проверьте netstat/sockstat: ss -ltn | grep 8080 покажет слушающий FD принадлежащий systemd (PID 1). После этого запустите service: sudo systemctl start myapp.service и в логах journalctl -u myapp.service вы увидите sd_notify READY=1. Для полной проверки отправьте HTTP-запросы и посмотрите, что при рестарте сервиса новые запрсы обслуживаются новым процессом без ошибки Connection refused.

Что делать, если после restart наблюдаются 5xx ошибки?

Сначала смотрите journalctl -u myapp.service --no-pager --since "1 minute ago". Частые причины: новый бинарник падает на старте (отсутствуют env-переменные), NotifyAccess=all настроен, но приложение не вызывает sd_notify, из-за чего systemd считает сервис неготовым и может считать restart неудачным. Для быстрого отката переключите симвссылку на предыдущую версию и sudo systemctl restart myapp.service. Также увеличьте TimeoutStartSec, если инициализация занимает больше времени.

Где хранить артефакты релизов и какой ретеншн разумен?

Храните бинарники в /opt/myapp/releases с симвссылкой current. Держите минимум 3 релиза для быстрой отладки/отката. Диск для релизов обычно занимает 50–200 MB на несколько последних сборок; планируйте политику хранения на CI: хранить 10–30 релизов в зависимости от частоты деплоев и доступного пространства.

Зачем нужен Type=notify и sd_notify?

Type=notify позволяет процессу сообщить systemd о своей готовности (READY=1). Если приложение выполняет асинхронную инициализацию (подключение к БД, миграции, загрузка конфигурации), sd_notify гарантирует, что systemd не пометит сервис как ready до фактической готовности. В 2025 этот механизм помогает сократить ложные перезапуски и уменьшить окно недоступности при старте.

Какие ограничения у этого подхода?

Socket activation и graceful shutdown подходят для короткоживущих HTTP-запросов; для long-lived соединений (WebSocket, gRPC streams) потребуется дополнительная логика: либо использовать tableflip/re-exec, либо маршрутизировать через балансировщик, умеющий плавно переводить трафик. Также при очень высокой нагрузке лучше использовать нескольких бэкэндов за балансировщиком, а systemd-метод — как часть решения.

Zero-downtime deploy для Go + systemd

package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    srv := &http.Server{
        Addr: ":8080",
        Handler: http.DefaultServeMux,
        ReadTimeout: 10 * time.Second,
        WriteTimeout: 30 * time.Second,
        IdleTimeout: 60 * time.Second,
    }

    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("ok"))
    })

    go func() {
        log.Println("starting server on", srv.Addr)
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("listen: %s", err)
        }
    }()

    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit
    log.Println("shutdown signal received")

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    if err := srv.Shutdown(ctx); err != nil {
        log.Fatalf("server forced to shutdown: %v", err)
    }
    log.Println("server exiting")
}

import (
    "github.com/coreos/go-systemd/activation"
    "net"
)

listeners, err := activation.Listeners()
if err != nil { /* handle */ }
var ln net.Listener
if len(listeners) > 0 {
    ln = listeners[0] // systemd передал слушающий сокет
} else {
    ln, _ = net.Listen("tcp", ":8080")
}
// передать ln серверу http.Serve(ln, handler)

# /etc/systemd/system/myapp.socket
[Unit]
Description=MyApp socket (zero-downtime)

[Socket]
ListenStream=8080
# В backlog задаём 1024 для высокой нагрузки
Backlog=1024
Accept=no

[Install]
WantedBy=sockets.target

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp service
After=network.target
Requires=myapp.socket

[Service]
Type=notify
NotifyAccess=all
# Передавать уведомления systemd через sd_notify
ExecStart=/opt/myapp/myapp-current
Restart=on-failure
RestartSec=2
# Не убивать group, чтобы дочерние процессы корректно завершились
KillMode=control-group
TimeoutStopSec=60
# Для логов используем стандартный журнальщик
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.socket
# service будет стартовать по запросу socket или явно
sudo systemctl start myapp.service

#!/bin/sh
set -e
RELEASE_DIR=/opt/myapp/releases/$1
if [ ! -d "$RELEASE_DIR" ]; then
  echo "release not found" >&2
  exit 1
fi
ln -sfn "$RELEASE_DIR" /opt/myapp/myapp-current
# перезапуск с контролем статуса
sudo systemctl restart myapp.service
sleep 1
sudo systemctl status myapp.service --no-pager

ln -sfn /opt/myapp/releases/myapp-v2026.02.28 /opt/myapp/myapp-current
sudo systemctl restart myapp.service

import "github.com/coreos/go-systemd/daemon"

// после запуска goroutine, которая слушает и ready
daemon.SdNotify(false, "READY=1")

Zero-downtime deploy для Go + systemd | KtoHto

Zero-downtime deploy для Go + systemd

Комментарии (0)

Шаг 1: Подготовить Go-приложение к graceful shutdown

Шаг 2: Добавить поддержку socket activation

Шаг 3: Написать unit-файлы systemd (.socket и .service)

Шаг 4: Сборка и атомарный деплой на сервер

Шаг 5: Мониторинг и откат