Введение: Установка последнего кусочка головоломки

Здравствуйте! Наконец, мы подошли к последней части длинной серии. В предыдущих четырех частях мы начали с теории автоматической системы развертывания, реализовали основную логику вебхука FastAPI и создали стабильную рабочую среду с помощью службы Systemd.

Предыдущие посты этой серии можно найти по следующим ссылкам:

① Почему стоит разрабатывать самостоятельно?

② Общее архитектурное решение и проектирование процесса

③ Настройка окружения стейджинга и базовая установка вебхука FastAPI

④ Подробности о хендлере развертывания и регистрация службы в Systemd

Но еще один шаг остался. В настоящее время наш вебхук-сервер FastAPI работает только на порту 8000 и не использует HTTPS, что делает его уязвимым с точки зрения безопасности. Более того, GitHub настоятельно рекомендует использовать открытые домены и HTTPS-соединения.

В этой пятой части мы установим последние кусочки и завершим систему. Давайте настроим Nginx как обратный прокси, чтобы безопасно выставить сервер FastAPI наружу, применим бесплатный HTTPS через Let's Encrypt, а затем в конечном итоге интегрируем GitHub вебхук, чтобы завершить автоматическую систему развертывания.

Минутку, почему Nginx, а не Apache2? Apache2 и Nginx являются отличными веб-серверами, которые делят рынок серверных программ. Однако такие асинхронные веб-фреймворки, как FastAPI, лучше всего сочетаются с Nginx. Nginx разработан на основе асинхронных событий, позволяя в полной мере использовать асинхронные возможности FastAPI в условиях высокой нагрузки. По этой причине сообщество FastAPI настоятельно рекомендует использовать Nginx в производственной среде, и эта статья также сосредоточена на Nginx.

Установка Nginx и настройка обратного прокси

Почему стоит использовать Nginx?

  1. Обратный прокси: Приложение сервера, такое как FastAPI, не предназначено для прямого приема внешнего трафика. Nginx выступает в роли обратного прокси, принимая запросы вебхука и безопасно передавая их серверу FastAPI.

  2. Безопасность: Nginx предоставляет различные настройки безопасности и функции защиты от DDoS-атак.

  3. Применение HTTPS: Управление и применение HTTPS-сертификатов осуществляется такими веб-серверами, как Nginx.

Установка и настройка Nginx

Подключитесь к серверу стейджинга через SSH и установите Nginx. Предполагается, что читатели этой статьи уже имеют некоторый опыт и знания о Nginx, поэтому подробное объяснение метода установки, структуры файлов или принципа работы будет пропущено.

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx # автостарт после перезагрузки
sudo systemctl start nginx # запуск nginx
sudo systemctl status nginx # Проверка состояния Active

Теперь создадим файл настроек Nginx для передачи входящих запросов на наш вебхук-сервер FastAPI. Предположим, что используем домен deployer.example.com. Вот пример конфигурации.

#/etc/nginx/sites-available/deployer.example.com

# HTTP запросы перенаправляем на HTTPS
server {
    listen 80;
    server_name deployer.example.com;
    return 308 https://$host$request_uri;
}

# Обработка HTTPS запросов
server {
    listen 443 ssl;
    server_name deployer.example.com;

    # Установка пути к SSL сертификату
    ssl_certificate /etc/letsencrypt/live/deployer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/deployer.example.com/privkey.pem;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off;
    }
}

  • Настройка HTTP на 80 порту: Блок listen 80, где server_name — это deployer.example.com, временно перенаправляет все входящие HTTP запросы на HTTPS с помощью команды return 308 https://$host$request_uri;.

  • Настройка HTTPS на 443 порту: Блок listen 443 ssl; обрабатывает HTTPS запросы.

  • ssl_certificate & ssl_certificate_key: Предполагается, что сертификаты были получены через Let's Encrypt. В этом блоке мы указываем путь к выданным SSL сертификату и файлу ключа. Этот путь будет автоматически создан certbot при выдаче сертификатов.

  • Блок location /: Настройка обратного прокси передает запросы, преобразованные в HTTPS, на наш сервер FastAPI (http://127.0.0.1:8000).

После перезапуска Nginx с этим конфигурационным файлом все запросы вебхука теперь будут обрабатываться безопасным HTTPS.

# Создание символической ссылки на файл конфигурации в директории sites-enabled
sudo ln -s /etc/nginx/sites-available/deployer.example.com /etc/nginx/sites-enabled/

# Проверка синтаксиса файла конфигурации Nginx.
sudo nginx -t

# Перезапуск Nginx для применения изменений.
sudo systemctl restart nginx

Применение HTTPS (Let's Encrypt + Certbot)

GitHub вебхуки настоятельно рекомендуют использовать HTTPS для соображений безопасности. Let's Encrypt — это некоммерческий сертификатор, предлагающий бесплатные SSL/TLS сертификаты всем желающим, а Certbot — отличное средство для автоматизации получения и обновления сертификатов. Здесь мы пропустим процесс установки.

После успешного завершения, перейдите в браузере по адресу https://deployer.example.com и проверьте API документацию FastAPI (.../docs) или конечную точку /. Если вы видите сообщение Webhook server is running!, значит Nginx и настройка HTTPS были выполнены успешно.

Окончательная интеграция и тестирование GitHub вебхука

Теперь все готово. Давайте подключим нашу систему автоматического развертывания к репозиторию на GitHub.

  1. Переход к репозиторию GitHub: Перейдите к репозиторию проекта, для которого вы хотите применить автоматическое развертывание.

  2. Настройка вебхуков: В верхнем меню щелкните Settings -> слева выберите Webhooks.

  3. Добавление вебхука: Нажмите кнопку Add webhook и введите следующую информацию.

    • Payload URL: Введите адрес вебхука сервер с Nginx и HTTPS. (Например: https://deployer.example.com/webhook)

    • Content type: Выберите application/json.

    • Secret: Точно скопируйте значение GITHUB_WEBHOOK_SECRET, которое вы устанавливали в файле ~/projects/webhook_server/.env в третьем посте, и вставьте его.

    • Какие события вы хотите использовать для триггера этого вебхука?: Выберите Just the push event.

    • Active: Убедитесь, что флажок активирован.

  4. Сохранить: Нажмите кнопку Add webhook, чтобы сохранить вебхук.

Скриншот настройки GitHub вебхука

Если вебхук зарегистрирован успешно, в разделе Recent Deliveries появится зеленая галочка, что будет свидетельствовать о том, что тестовый запрос был успешно отправлен.

Теперь давайте проведем финальное тестирование.

  1. Изменение кода локально: Внесите небольшие изменения в код проекта, выполните коммит и отправьте его.

  2. Проверка состояния:

    • На странице настройки вебхука GitHub проверьте раздел Recent Deliveries, чтобы убедиться, что вебхук с последнего пуша успешен (зеленая галочка).

    • Подключитесь к серверу стейджинга через SSH и выполните команду sudo journalctl -u github-webhook-deployer.service -f, чтобы просмотреть лог в реальном времени. Если вы видите сообщения типа Git pull successful и Deployment task finished, то тест прошел успешно.

    • Проверьте состояние развернутого Docker-контейнера, чтобы убедиться, что последний код корректно внедрен.

В заключение: Система автоматического развертывания завершена!

Поздравляю! Вы успешно построили полностью рабочую CI/CD пайплайн, от локальной разрабатки до GitHub и вашего собственного развертываемого сервера.

В этой серии мы достигли следующих целей:

  • Поняли, почему стоит самостоятельно разрабатывать вебхук-систему автоматического развертывания.

  • Спроектировали и реализовали архитектуру вебхука сервера на основе FastAPI.

  • Узнали, как стабильно управлять сервисом с помощью Systemd.

  • Укрепили безопасность, применив настройки Nginx и HTTPS.

  • В конечном итоге автоматизировали весь процесс, интегрировав его с GitHub.

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

Спасибо за то, что прошли этот долгий путь вместе!