Введение в GitHub Actions. Делаем пайплайн для деплоя Spring Boot проекта на VPS с помощью Docker

В этой статье я расскажу как построить простой пайплайн для деплоя Spring Boot проекта на сервере используя GitHub Actions и Docker.

Содержание:

1. Регистрация self-hosted раннера на VPS с ОС Linux и установленным Docker.

2. Создание .yml файла с описанием пайплайна — базовая структура, операции и команды. Создание статус — бейджика.

3. Функция оповещений в мобильном приложении GitHub.

Что имеем

• Арендованный VPS с установленным Docker и docker-compose

• Репозиторий базового Spring Boot проекта с Dockerfile и docker-compose.yml

Настройка раннера

Деплоить будем на сервере. Для этого нужно настроить раннер.

Логинимся на VPS. Раннер нельзя запустить от имени root пользователя, поэтому придется создать нового, не забыв предоставить ему права на использование Docker.

Создание пользователя и выдача прав для Docker

useradd -m user
passwd user
groupadd docker
usermod -aG docker user
chsh -s /bin/bash user
su user

В репозитории переходим в Settings → Actions → Runners → New self-hosted runner

Указываем параметры нашего VPS. У меня это Linux. Архитектура процессора - x64. После этого появятся автосгенерированные скрипты для настройки раннера.

Вводим первую группу скриптов.

Запускаем скрипт конфигурации. Из всех дефолтных значений я изменил только название раннера.

Теперь можно запускать раннер. Для демонстрационных целей сделать это можно в фоновом режиме с помощью nohup.

  nohup ./run.sh > runner.logs &

Запуск раннера в качестве сервиса

Для реальных проектов рекомендуется запускать раннер в качестве сервиса. Сделать это можно при помощи скрипта svc.sh, который автоматически загружается при настройке раннера.

доступные команды и их краткое описание

После установки и настройки раннера необходимо выполнить команду install.

вывод при успешном выполнении команды

Затем для исполнения станут доступны остальные команды.

команда start

команда status

команда stop

команда uninstall

Проверим статус раннера в GitHub.

my-runner зарегестрирован и ждет задачи на выполнение

Создание пайплайна.

Все скрипты пайплайнов должны лежать в специальной папке {проект}/.github/workflows .

Создадим скрипт deploy-job.yml и поместим его в эту папку.

В первой строчке укажем название пайплайна. Оно будет отображаться в GitHub.

name: Deploy buy runner

Затем укажем когда запускать этот пайплайн - в нашем случае пускай это будет при пуше в ветку master или develop.

on:
  push:
    branches: [ "master", "develop" ]

Затем начнем описывать джобы.

Первым делом будем запускать тесты.

jobs:
  test: # Название джобы
    runs-on: ubuntu-latest   # Где должна выполняться джоба. 
# Здесь укажем GitHub-hosted runner - среду выполнения, которую предоставляет сам GitHub.
    steps: # Перечень шагов, которые необходимо выполнить в рамках джобы.
      - name: cd into repo # Название шага
        uses: actions/checkout@v3 # Ключевое слово uses используется для запуска заранее
# созданного набора команд. В данном случае используем дефолтную команду
# для обновления проекта до последнего коммита.
      - name: set up Java and Maven # Настраиваем Java и Maven.
        uses: actions/setup-java@v3 
        with:
          java-version: '11'
          distribution: 'temurin'
          cache: maven
      - name: run tests
        run: mvn test # Запускаем тесты.

Стоит отметить что тесты будут запускаться в облаке GitHub. На момент написания статьи GitHub бесплатно предоставляет 2.000 вычислительных минут в месяц.

Затем подготовим окружение - удалим старые контейнеры и имейджы.

  prepare-environment:
    runs-on: self-hosted # Запускаем на раннере, который настроили до этого.
    needs: test # Запускаем только если джоба test прошла успешно
    steps:
      - name: Stop and remove containers, networks
        run: docker-compose down
      - name: Remove unused data
        run: docker system prune -a -f

После этого запустим проект с помощью docker-compose.

  deploy:
    runs-on: self-hosted # Запускаем на раннере, который настроили до этого.
    needs: prepare-environment # Запускаем только если джоба prepare-environment прошла успешно
    steps:
      - name: checkout repo
        uses: actions/checkout@v3
      - name: docker-compose
        run: docker-compose up -d

Итоговый файл:

файл

name: Deploy buy runner

on:
  push:
    branches: [ "master", "develop" ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: checkout repo
        uses: actions/checkout@v3
      - name: set up Java and Maven
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
          cache: maven
      - name: run tests
        run: mvn test
  prepare-environment:
    runs-on: self-hosted
    needs: test
    steps:
      - name: Stop and remove containers, networks
        run: docker-compose down
      - name: Remove unused data
        run: docker system prune -a -f
  deploy:
    runs-on: self-hosted
    needs: prepare-environment
    steps:
      - name: checkout repo
        uses: actions/checkout@v3
      - name: docker-compose
        run: docker-compose up -d

Коммитим, пушим, ждем, смотрим на результат.

Все работает. Теперь можем создать бейджик и запихнуть его в README.md. Шаги отмечены на картинке:

После этого появится окно с настройкой бейджика.

Дефолтные параметры я не менял. Копируем сгенерированную ссылку, вставляем в README.md и получаем следующее:

Мобильные оповещения.

Хотелось бы отметить функцию оповещений о работе пайплайнов в мобильном приложении GitHub. Включить ее можно в настройках. Выглядит это примерно вот так:

В случае фейла можно даже посмотреть логи.

Заключение

В этой статья я описал процесс создания простого пайплайна GitHub Actions для деплоя Spring Boot проекта с использованием Docker.

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

Для дальнейшего изучения функционала GitHub Actions можно обратиться к официальной документации.