Webhook деплой

Webhook-деплой — автоматическое развёртывание приложения при пуше в Git-репозиторий через HTTP-запрос (webhook). Git-платформа (GitHub, GitLab, Gitea) отправляет POST-запрос на URL вашего сервера при каждом коммите, сервер выполняет скрипт обновления.

Как работает

Последовательность событий:

Разработчик делает git push origin main.
GitHub/GitLab отправляет POST на https://myserver.com/deploy с JSON-телом (информация о коммите, ветке, авторе).
Webhook-receiver на сервере проверяет подпись (HMAC-SHA256 секрета) и выполняет скрипт деплоя.
Скрипт: git pull && composer install && php artisan migrate && php artisan cache:clear.

Webhook — простейший способ CI/CD без отдельного сервера сборки.

Реализации webhook-receiver

webhook (adnanh/webhook) — лёгкий Go-сервер специально для этой задачи:

# hooks.json
[{
    "id": "deploy",
    "execute-command": "/opt/deploy.sh",
    "command-working-directory": "/var/www/myapp",
    "trigger-rule": {
        "match": {
            "type": "payload-hmac-sha256",
            "secret": "mysecret",
            "parameter": {"source": "header", "name": "X-Hub-Signature-256"}
        }
    }
}]

# Запуск
webhook -hooks hooks.json -port 9000 -verbose

deploy.sh — скрипт деплоя с откатом:

#!/bin/bash
cd /var/www/myapp
git pull origin main
npm install --production
npm run build
pm2 reload ecosystem.config.js

История

Webhooks появились в GitHub в 2008 году как способ уведомления внешних систем о событиях в репозитории. Термин «webhook» предложил Джефф Линдси в 2007 году. Первоначально использовались для интеграций (Slack-уведомления, Jira-задачи). Применение для деплоя — логичное расширение: раз уж сервер получает уведомление о пуше, почему не задеплоить сразу? Webhook-деплой стал стандартом для небольших проектов до распространения Jenkins и GitLab CI.

Безопасность webhook

Без проверки подписи любой может вызвать деплой, зная URL. Обязательные меры:

HMAC-подпись — GitHub добавляет заголовок X-Hub-Signature-256 с HMAC(secret, payload). Проверяйте на сервере перед выполнением.
IP-фильтрация — UFW принимает webhook только с IP-диапазонов GitHub/GitLab (публикуются в их документации).
HTTPS — webhook-endpoint только через TLS. Без шифрования payload перехватывается.
Минимальные права — скрипт деплоя запускается от непривилегированного пользователя deploy, а не root.

Webhook vs полный CI/CD

Webhook-деплой подходит для: одного сервера, простого стека (PHP, Node.js, Python), команды 1-3 человека, без сложных тестов. Полноценный CI/CD нужен когда: несколько окружений (staging, production), параллельные задачи сборки, матрица тестов, Docker multi-stage build, несколько серверов обновляются одновременно.

На что обращать внимание

Параллельные деплои при быстрых коммитах — race condition: два деплоя одновременно ломают систему. Добавьте mutex: flock -n /tmp/deploy.lock -c "/opt/deploy.sh". Логирование деплоев в файл и уведомление в Telegram о результате — обязательно для отладки проблем. Тайм-аут webhook от GitHub — 10 секунд: если деплой долгий, ответьте 200 сразу, деплой выполняйте в фоне.

Альтернатива webhook-receiver — простой Nginx+PHP скрипт: файл deploy.php проверяет секрет и выполняет shell-команды через exec(). Быстрый старт, но менее безопасен, чем специализированный инструмент. Для серьёзных проектов используйте Woodpecker CI или Jenkins.