Глава 42 / 51
Том 5 · Расширения, эксплуатация и практика

Развёртывание: от «запускается» до «можно доверить хостингу»

Развёртывание приложения XServer просто до «скопировал каталог» — сложное всё в сервисном облуживании: автозапуск, перезапуск при падении и внешняя подстраховка корректной остановки. В главе — реальные скрипты продакшна home.

Обзор

Позиционирование: последняя миля глазами эксплуатации. «Остановка без принудительного демонтажа» из гл. 06 здесь оборачивается параметром сервис-менеджера.

42.1 Введение

Развёртывание приложения XServer не знает ни списка зависимостей, ни подготовки среды, ни шагов установки — всё это свёрнуто ещё в главе 2. Остаются лишь три эксплуатационных вопроса: где разместить (планировка), как держать резидентным (сервис-менеджер) и как красиво останавливать (корректная остановка + внешний тайм-аут). Глава разбирает их по очереди.

42.2 Поставка и рабочая планировка

Продакшн-планировка home (реальная форма)источник: репозиторий home /opt/www
/opt/www/                  /* корень развёртывания = каталог exe = каталог конфигурации */
├── xs                     /* единственный бинарник (компилятор/SDK/рантайм внутри) */
├── xs.json                /* главный конфиг: services + все vhost */
├── host/default/...       /* ферма сайтов (планировка гл. 20) */
├── host/xxdevs/...
├── tools/  dev/           /* эксплуатационные помощники и dev-копии */
└── (никаких иных зависимостей)
  • Версионирование: весь каталог — одна единица; откат = вернуть прошлую копию каталога (xs.exe и исходники/конфиг всегда одной версии)
  • Пути обновления: структурное изменение = скопировать в новый каталог и перезапустить; текущие правки = перезаписать файлы скриптов + reload (минутная дисциплина изменений, гл. 31)
  • Изоляция данных: db/ лежит внутри каталога сайта — стратегия бэкапа делается по каталогам

42.3 Сервисное управление

Реальный скрипт запуска продакшна home (дословно из репозитория):

xs.service (оригинал home, стиль SysV)продакшн-образецисточник: home/xs.service
#!/bin/sh
case "${1}" in
  start)
    cd /opt/www
    sudo nohup /opt/www/xs /opt/www/xs.json &
    ;;
  stop)
    sudo pkill -9 -f /opt/www/xs        /* внимание: -9 жёсткое убийство */
    ;;
  restart)
    sudo pkill -9 -f /opt/www/xs
    cd /opt/www; sudo nohup /opt/www/xs /opt/www/xs.json &
    ;;
esac

Что только что произошло: скрипт показывает минимально жизнеспособную форму и обнажает точку роста — pkill -9 бьёт насмерть, минуя корректную остановку (пять фаз гл. 06). Рекомендуемая форма — юнит systemd, где сначала вежливо по умолчанию:

Рекомендация: xs.service (юнит systemd)
[Unit]
Description=xs application server
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/www
ExecStart=/opt/www/xs /opt/www/xs.json
/* корректная остановка: сперва SIGTERM со запасом времени, SIGKILL лишь по тайм-ауту */
KillSignal=SIGTERM
TimeoutStopSec=120
Restart=on-failure
RestartSec=3
/* вывод в journald; внутри приложения уровни — через xrtLogger */
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Эквивалент на Windows: обёртка-служба (или назначенное задание + net stop, доставляющий сигнал группе процессов через CTRL_BREAK — именно этим занят инструмент wingrp из test.bat).

42.4 Дисциплина остановки

  • Внутри: SIGTERM/Ctrl+C → пятифазная корректная остановка (гл. 06) — без принудительного демонтажа, длинные соединения ждут до конца
  • Снаружи: подстраховку даёт сервис-менеджер — TimeoutStopSec у systemd, stopwaitsecs у supervisor. Сколько давать? Чуть больше самого длинного легального запроса (например, потолок отдачи больших файлов + буфер)
  • Порядок: ритм прокатки «новый экземпляр готов → переключить трафик → SIGTERM старому → дождаться осушения → подстраховочный добой»

42.5 Контракт

  • Каталог: корень развёртывания = exe = конфигурация; каталог версонируется целиком, откат — смена каталога.
  • Сервис: резидентность у сервис-менеджера; Restart=on-failure — подстраховка от падений.
  • Остановка: внутренняя корректность + внешний тайм-аут, одно без другого не живёт.

Частые ошибки

kill -9 как штатное средство
Симптом
Каждый «релиз» рвёт все соединения; пользователи считают это аварией.
Причина
-9 перепрыгивает корректный путь — ServiceUnit не выполняется, запросы в полёте режутся пополам. Штатное средство — SIGTERM; -9 принадлежит только подстраховке.
Настроил WorkingDirectory — и пути можно писать как угодно
Симптом
На части машин «не найден xs.json / корень статики».
Причина
XServer по умолчанию ищет конфигурацию в каталоге исполняемого файла (гл. 02) — WorkingDirectory влияет лишь на операции относительно CWD. Передавайте полный путь к xs.json или унифицируйте планировку, на CWD не надейтесь.

Упражнения

БазовыйВыход на systemd

По юниту 42.3 зарегистрируйте своё приложение системной службой.

Приёмка: start/stop/status/автозапуск — всё работает; в логе остановки все пять фаз.
ПродвинутыйЗамер окна остановки

Под нагрузкой и отдачей большого файла подайте stop; подберите TimeoutStopSec до минимального значения без отказов.

Приёмка: названо рекомендованное окно остановки вашего бизнеса с обоснованием.
ВызовСине-зелёные каталоги

Реализуйте скрипт blue-green: два каталога + переключение символической ссылки + осушение старого экземпляра.

Приёмка: доступность 100% на всём пути; откат одной командой.

Итоги

ТезисВывод
Поставкакорень развёртывания = exe = конфигурация; каталог версонируется целиком
Резидентностьsystemd: Restart страхует от падений, journal собирает логи
Остановкакорректность SIGTERM + внешняя подстраховка TimeoutStopSec
Релизытекущие — reload / структурные — смена каталога с рестартом / blue-green прокатка
API, затронутые в главе
Что дальше по xrt
  • справочник xrt · signal — платформенные различия обработки сигналов (хост уже обработал их за вас)