MikaJanBales 26 июл в 10:22

Автоматизация деплоя с помощью GitHub Actions: руководство для чайников

Простой

4 мин

4.2K

Recovery Mode

Привет, Хабр! Меня зовут Микаэль Оганесян, я backend-разработчик, и сегодня хочу поделиться с вами опытом настройки CI/CD с использованием GitHub Actions. В этой статье мы разберём, как автоматизировать процесс деплоя вашего приложения, что сэкономит ваше время и уменьшит количество ошибок при ручном деплое.

Введение в GitHub Actions

GitHub Actions — это мощная платформа для автоматизации рабочих процессов, интегрированная прямо в GitHub. Она позволяет автоматизировать сборку, тестирование и деплой вашего приложения, реагируя на события в репозитории (например, push или pull request).

Преимущества автоматизации деплоя:

⏳ Экономия времени: Автоматизация устраняет рутинные задачи.
🛡️ Уменьшение ошибок: Снижается вероятность человеческих ошибок.
🚀 Повышение надежности: Стандартизированный процесс деплоя обеспечивает консистентность.
🔄 Ускорение цикла разработки: Быстрый деплой позволяет чаще выпускать обновления.

Основные понятия

Прежде чем переходить к практике, давайте разберём ключевые термины:

Workflow: YAML-файл (.github/workflows/your_workflow.yml), определяющий последовательность задач (jobs). Запускается при событиях в репозитории (например, push в ветку).
Job: Группа шагов (steps), выполняемых на одном виртуальном сервере (runner). Jobs могут зависеть друг от друга.
Step: Отдельная задача в рамках job. Это может быть команда shell, скрипт или использование готового Action.
Action: Переиспользуемый модуль для выполнения задач (например, сборка проекта или деплой).
Secrets: Зашифрованные переменные для хранения конфиденциальных данных (пароли, ключи API).
SSH Keys: Ключи шифрования для безопасного подключения к серверу.

Подготовка к работе

Прежде чем настраивать CI/CD, убедитесь, что у вас есть:

Аккаунт GitHub — для создания репозитория и настройки GitHub Actions.
Сервер — Linux-сервер или облачный сервис (AWS, GCP, Azure).
SSH-доступ к серверу.
Docker и docker-compose — установите их на сервере:
sudo apt install docker.io && sudo apt install docker-compose && sudo usermod -aG docker $USER && sudo chmod 666 /var/run/docker.sock
Access Token — создайте в GitHub (Settings → Developer settings → Personal access tokens).
Клонирование репозитория на сервер:
git clone https://<username>:<ваш_токен>@github.com/<path_to_repo/repo_title>.git
Переменные окружения — создайте файл .env в репозитории:
cd <repo_title>
touch .env
echo "<var_title>=<var_value>" >> .env

Как работает GitHub Actions?

Процесс можно описать в несколько этапов:

Событие (push, PR, schedule и др.) инициирует запуск workflow.
GitHub ищет нужный workflow-файл (.github/workflows/*.yml).
Выделяется runner (GitHub-Hosted или Self-Hosted).
Выполняются jobs (параллельно или последовательно).
В рамках jobs выполняются steps (последовательно).
Используются Actions или команды shell.
Обрабатываются Secrets (зашифровано и замаскировано в логах).
Результат (успех/неудача) и, опционально, создание Artifacts или уведомлений.

Типы событий:

Внутренние: push, pull_request, schedule, workflow_dispatch (ручной запуск).
Внешние: через GitHub API (для интеграции с внешними сервисами).

Виды runners:

GitHub-Hosted: Предоставляются GitHub (Linux, Windows, macOS). Бесплатны для публичных репозиториев.
Self-Hosted: Разворачиваются и управляются вами. Полезны для специфических требований.

Практический пример: деплой с Docker

Рассмотрим пример workflow для автоматического деплоя приложения на сервер с использованием Docker.

1. Настройка сервера

Генерация SSH-ключей (без пароля):
ssh-keygen -t rsa -b 4096
Добавление публичного ключа в authorized_keys:
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Копирование приватного ключа (понадобится для GitHub Secrets):
cat ~/.ssh/id_rsa

2. Настройка GitHub Secrets

Перейдите в репозиторий: Settings → Secrets and variables → Actions.
Создайте secrets:
- SSH_PRIVATE_KEY — значение из приватного ключа (шаг 1.3).
- SSH_HOST — IP-адрес сервера.
- SSH_USER — пользователь сервера.
- PROJECT_FOLDER — название репозитория.

3. Создание workflow-файла

Создайте файл .github/workflows/main.yml с содержимым:

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  run_pull:
    name: run pull
    runs-on: ubuntu-latest

    steps:
      - name: install ssh keys
        run: |
          install -m 600 -D /dev/null ~/.ssh/id_rsa
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.SSH_HOST }} > ~/.ssh/known_hosts

      - name: connect, pull and run
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
          cd ${{ secrets.PROJECT_FOLDER }}
          git checkout main
          git pull origin main
          docker-compose down
          docker-compose up --build -d
          EOF

Что делает этот workflow?

При пуше в ветку main или создании PR запускается job run_pull.
Устанавливаются SSH-ключи для доступа к серверу.
Подключается к серверу, обновляет код из репозитория и перезапускает Docker-контейнеры.

Заключение

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

Дальнейшие шаги:

Изучите официальную документацию.
Экспериментируйте с разными Actions и настройками.
Автоматизируйте другие задачи: тестирование, линтинг, уведомления.

Если у вас есть вопросы или дополнения — пишите в комментарии! Буду рад обсудить ваш опыт использования GitHub Actions. 🚀

Хабы: