СтатьиQlikИнструментыUI Kit Поиск RSS →
← Все статьи
скилыClaude CodeCursorAI skillsnginx502safe-applydevopssshавтоматизацияИИЧернов пишет

Скил для nginx: правит конфиг и не роняет сайт

Скил для nginx: правит конфиг и не роняет сайт

Знакомая сцена: нужно добавить домен или поправить апстрим. Открываешь конфиг nginx, меняешь пару строк - и из-за лишней точки с запятой или незакрытой скобки всё идёт не так. В лучшем случае правка тихо не применяется, и ты не понимаешь, почему ничего не поменялось. В худшем - кто-то по привычке делает restart, nginx уже не поднимается, и сайт ложится целиком. А пользователи уже видят 502, телефон звонит, и ты лихорадочно вспоминаешь, что именно ты только что стёр.

Самое обидное тут - что ошибка была видна заранее. nginx умеет проверять конфиг, не применяя его: команда nginx -t разбирает весь файл и говорит, где опечатка и на какой строке. Но в спешке об этой проверке забывают: поправил - перезагрузил - и будь что будет. И тут не повезти может по-разному: reload со сломанным конфигом просто молча не применится (мастер залогирует ошибку, старые воркеры дорабатывают - и ты думаешь, что правка уехала, а она нет), а вот привычный restart со сломанным конфигом nginx уже не поднимет - и ляжет весь сервер, со всеми сайтами, а не только тот, что ты правил.

Откатываться под нагрузкой страшно: ты не помнишь, как было, бэкапа нет, а 502 уже сыпется. Хочется, чтобы кто-то ответственный сначала проверил, а уже потом трогал живой сервер. Этим кем-то может быть твой ИИ-ассистент - если задать ему правильный порядок действий.

В чём идея

Скил - это короткая инструкция для ассистента: как называется, когда применять и что сделать. Здесь скил называется nginx-safe-reload, и его задача - править конфиги nginx по ssh (добавить vhost, поменять апстрим, обновить сертификат, разобраться с 502), но по строгому безопасному порядку.

Этот порядок и есть приём урока - safe-apply, “применяй только после проверки”. Четыре шага, всегда в одной последовательности: сначала бэкап файла, потом точечная правка, потом nginx -t, и только при зелёной проверке - reload. Если nginx -t ругается, скил откатывает файл из бэкапа, показывает текст ошибки с номером строки и НЕ перезагружает nginx. То есть на живой сервер попадает только заведомо валидный конфиг.

Почему это работает надёжно? Потому что nginx -t - это не догадка ассистента, а сам nginx, который парсит конфиг тем же кодом, что и при запуске. Он ловит синтаксис, незакрытые блоки, битые пути к сертификатам, кривые директивы - до того, как они дойдут до работающего процесса. Зелёная проверка - единственный пропуск к reload. А reload (в отличие от restart) не рвёт активные соединения: старые воркеры дорабатывают запросы, новые поднимаются на свежем конфиге. Сайт даже не моргает.

Отдельно про 502. Эта ошибка почти всегда значит: nginx-то жив, а бэкенд за proxy_pass - нет. Поэтому скил не лезет править конфиг наугад. Сначала диагностирует чтением: слушает ли апстрим свой порт, что пишет error.log nginx (там реальная причина - connection refused, timeout), поднят ли сервис бэкенда. И только найдя причину, предлагает фикс - через тот же safe-apply.

И ещё важное свойство: скил описывает ЧТО сделать, а не ЧЕМ подключиться. Каким ssh-клиентом ходить на сервер и на какой системе - решает сам ассистент. Поэтому скил переносимый: он про порядок действий, а не про конкретную команду под конкретную ОС. Никаких внешних сервисов и ключей от чужих API - чистый ssh к твоему собственному серверу.

Как себе сделать

Отдай задачу своему ассистенту (Claude Code, Codex, Cursor, Gemini, любому) - он сам разберётся, куда положить файл скила и как подключиться к серверу. Просто скопируй промпт:

Создай мне скил, который правит конфиги nginx на сервере по ssh: добавляет и меняет vhost, апстримы, пути к TLS-сертификатам, а ещё диагностирует ошибку 502.
Срабатывай на просьбы вроде "поправь конфиг nginx", "добавь домен на сервер", "поменяй апстрим", "обнови сертификат", "почему сайт отдаёт 502".
Главное правило - safe-apply, соблюдай его без исключений: сначала сделай бэкап файла, который правишь; потом внеси точечное изменение; потом запусти nginx -t; и делай reload только если nginx -t прошёл успешно. Если проверка не прошла - откати файл из бэкапа, покажи мне текст ошибки с номером строки и не перезагружай nginx.
Для 502 сначала диагностируй чтением (жив ли апстрим, что в error.log, поднят ли бэкенд), и только потом предлагай фикс через тот же безопасный порядок.
Подключайся по ssh любым клиентом системы, не завязывайся на конкретную ОС, и не трогай ничего, о чём я не просил.

Как понять, что заработало: попроси ассистента добавить тестовый vhost, но специально упомяни, что хочешь видеть результат проверки. Если он сначала делает бэкап, прогоняет nginx -t и сообщает “syntax is ok” перед тем как перезагрузить - порядок поймался, скил живой. А чтобы проверить страховку, можно попросить внести заведомо кривую правку: правильный скил остановится на красном nginx -t, откатит файл и не тронет работающий nginx.

Маленькая честная оговорка: nginx -t ловит синтаксис и битые пути, но не логику. Если ты правильно с точки зрения синтаксиса направишь трафик не на тот апстрим - проверка будет зелёной, а сайт поедет не туда. Поэтому диагностику 502 скил делает чтением логов, а не угадыванием. Но именно от падений “на ровном месте” - когда опечатка либо тихо не применяется, либо при restart кладёт весь сервер - safe-apply защищает железно: он проверяет тем же движком, что и применяет, ещё до того как дело дойдёт до перезагрузки.

И всё. Ты только что собрал скил, который правит боевой сервер аккуратнее, чем многие делают руками - и ни строчки кода не написал. Тот же приём “сначала проверь, потом применяй” переносится на любую опасную правку: миграции базы, выкладку, изменение DNS. Один раз описал безопасный порядок - дальше ассистент держит его за тебя.

Смотреть полностью

Коротко