Введение: Важность CI/CD и автоматизированного развертывания

Автоматизированное развертывание для эффективного рабочего процесса разработки, то есть CI/CD (Непрерывная интеграция/Непрерывная доставка), становится не просто выбором, а необходимостью. Если развертывание происходит автоматически после отправки кода на GitHub, это значительно увеличивает производительность разработки.

Существует множество способов реализовать автоматизированное развертывание, но наиболее распространенными являются использование GitHub Actions, предоставляемых самим GitHub, и реализация логики развертывания с помощью функции Webhook GitHub.

Почему стоит реализовать Webhook вместо использования GitHub Actions?

Кот GitHub, бросающий бумажный самолетик вебхука в Тукса

GitHub Actions определенно является мощным и удобным инструментом CI/CD. Вы можете определить сложные рабочие процессы всего лишь в несколько строк файла YAML, автоматизировав множество процессов, таких как сборка, тестирование и развертывание, через различные торговые площадки действий. Нельзя отрицать, что GitHub Actions является отличным выбором для большинства проектов.

Тем не менее, GitHub Actions не всегда является оптимальным вариантом. Особенно в следующих ситуациях, разработчикам может оказаться гораздо более привлекательно реализовать решение с использованием GitHub Webhook.

  • Чувствительные к затратам индивидуальные разработчики или небольшие команды: GitHub Actions предлагает почти безлимитный бесплатный доступ для публичных репозиториев, однако для частных репозиториев происходит начисление, если превышен определенный объем бесплатных лимитов (время и хранилище). Если вы хотите полностью исключить возможность неожиданных затрат, лучше реализовать решение самостоятельно.

  • Разработчики, управляющие собственными серверами для тестирования (такими как Raspberry Pi 5): Если у вас уже есть физический сервер (включая VPS, облачные инстансы), то гораздо эффективнее использовать ресурсы вашего собственного сервера, нежели арендовать виртуальную среду GitHub (Runner). Получение и развертывание кода на вашем сервере будет более экономически целесообразным и более эффективно с точки зрения использования ресурсов.

  • Разработчики, желающие полного контроля и свободы над логикой развертывания: GitHub Actions использует стандартизированные рабочие процессы и действия, но, реализуя вебхук самостоятельно, вы можете проектировать и управлять каждым аспектом скрипта развертывания, как вам угодно. Это особенно полезно, если вам нужна сложная кастомная логика, специализированная для определенной среды, или если требуется идеальная интеграция с ранее построенным конвейером.

В этой серии мы подробно рассмотрим, как реализовать логику развертывания непосредственно на своем сервере с использованием GitHub Webhook. Мы нацелены на разработчиков на Python и, в частности, будем использовать FastAPI, простой, но мощный веб-фреймворк, для создания конечной точки вебхука. DRF (Django REST Framework) тоже отличное решение, но так как логика всего лишь легкая для обработки запросов вебхука, я считаю FastAPI наилучшим выбором. Не нужно ехать в супермаркет на спортивной машине, если можно взять малый авто.

Основные материалы для создания автоматизированной системы развертывания

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

  1. Репозиторий GitHub:

    • Нужен репозиторий GitHub с проектом Python, в который вы хотите применить автоматизированное развертывание. (Не имеет значения, публичный или приватный)

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

  2. Сервер для тестирования (самостоятельный сервер):

    • Нужен сервер, на котором будет производиться реальное развертывание. Raspberry Pi 5, собственный VPS (виртуальный частный сервер), облачный инстанс (такие как AWS EC2, GCP Compute Engine и т. д.) - все они подходят.

    • Должен быть доступ извне (GitHub) через публичный IP-адрес или домен. (Убедитесь, что настройки брандмауэра правильные.)

    • Рекомендуется операционная система в среде Linux, например, Ubuntu Server.

    • Установка Docker: Docker должен быть предварительно установлен на сервере, чтобы развертываемое приложение могло строиться или выполняться в контейнерах Docker.

  3. Среда разработки Python:

    • На сервере для тестирования должна быть установлена версия Python 3.8 и выше. (Рекомендуется использование виртуальной среды)

  4. Git:

    • На сервере для тестирования должен быть установлен Git. Он будет использоваться для получения последнего кода из репозитория GitHub с помощью команды git pull.

  5. FastAPI и Uvicorn:

    • Потребуются FastAPI — фреймворк для реализации конечной точки вебхука на Python и сервер ASGI Uvicorn. В следующем выпуске мы рассмотрим установку и основные настройки.

  6. SSH-ключ:

    • Для безопасного доступа к репозиторию GitHub и извлечения кода на сервере для тестирования необходимо настроить SSH-ключ. Большинство из вас, вероятно, уже зарегистрировали SSH-ключ в своей учетной записи. (Если вы еще этого не сделали, зарегистрируйте его на GitHub. Обычно используется Deploy key для развертывания.)

  7. Понимание веб-сервера (Nginx или Apache2) и настройка домена/HTTPS:

    • GitHub Webhook обычно рекомендует безопасное соединение через HTTPS. Поэтому заранее подготовьте субдомен, такой как deployer.example.com, чтобы получать вебхуки и настоитте SSL-сертификат (например, бесплатный сертификат Let's Encrypt) для этого домена.

    • Надеюсь, нет никого, кто подключает FastAPI-приложение напрямую через переадресацию портов маршрутизатора вашего интернет-провайдера, но для подстраховки, чтобы вы понимали, что приложение лучше не выставлять напрямую, обычно используют Nginx или Apache2 как обратный прокси для передачи запросов вебхука в FastAPI-приложение, так вы будете более безопасны. Обязательно используйте серверную программу для обеспечения обратного прокси. Базовое понимание и опыт настройки поможет вам существенно.

  8. Понимание службы Systemd (рекомендуется, но не обязательно):

    • Этот сервер вебхука FastAPI должен всегда находиться на сервере для тестирования и выполняться. Рекомендуется зарегистрировать его как Systemd Service, чтобы он автоматически запускался при перезагрузке сервера, и управление службой (запуск/остановка/перезапуск) было бы удобно.

    • Примечание: Создание сложной логики развертывания, в которой необходимо непосредственно выполнять git или docker внутри контейнера, не соответствует цели проектирования контейнера и требует сложных установок, таких как docker-in-docker или docker-out-of-docker, что также небезопасно. Если на сервере уже установлены git и docker, гораздо эффективнее и проще запустить сервер вебхука FastAPI как Systemd Service и использовать команды git и docker из развертывающего скрипта. В этой серии мы сосредоточим свое внимание именно на этом методе.

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