Основное преимущество работы в стартапе – разнообразные задачи, с которыми приходится разбираться в крайне короткие сроки за минимальный бюджет. И такие условия позволяют находить и придумывать интересные решения, которые не приняты за стандарт большими компаниями.

Сегодня поговорим о том, как можно автоматизировать обновление стенда, тестирование сборки и создание бэкапов баз данных настолько дешево, что даже бесплатно.

Привет, хабровчане!

Однажды нам надоело сливать ветки с репозитория на виртуальную машину тестового сервера и прописывать команды создания бэкапов для всех баз данных. Также очень не хотелось из-за маленького хотфикса поднимать сервисы в Docker, поднимать сам Docker, пересобирать контейнер и запускать тесты. Мы провели исследование не только в чертогах разума, но даже на второй странице результатов поисковиков. И мы пришли к решению, которое нас более чем устроило как по цене, так и по возможностям – Github Actions.

Итак, в нашем распоряжении имеется микросервисная архитектура (ну куда же без неё в наше непростое время), состоящая из 10 контейнеров, среди которых есть базы данных на PostgreSQL, сервисы бэкенда на .NET Core, сервис Nginx, небольшой Telegram-бот для быстрого сбора данных о возможных проблемах в решении, а также один контейнер со статической страничкой, который до релиза мы хотим вынести за пределы не только архитектуры, но и виртуальной машины в целом. Естественно, все это работает внутри системы Docker. Также имеется проект с тестами, которыми мы проверяем работоспособность всех основных модулей решения.

Запуск автотестов

Начнем с создания небольшого флоу для запуска наших тестов на гитхабе. Мы нашли множество примеров реализации запуска Unit-тестов для .NET, но одними Unit-тестами сыт не будешь: большая часть нашего решения покрыта интеграционными тестами Поэтому мы реализовали сборку наших основных сервисов и запуск тестов прямо на Github.

Приводим пример такого флоу с комментариями:

# Имя флоу
name: .NET Core

# Когда действие запустится (триггеры)
on:
  push:
    # при push в master
    branches: [ master ]

  pull_request:
    # при создании pull request на master
    branches: [ master ]

# Что будем делать (экшены)
jobs:
  # Имя действия, придумываем сами
  integration-tests:
    # На какой ОС будет работать виртуальная машина
    # Можно выбрать Ubuntu, Windows Server или macOS
    runs-on: ubuntu-latest
    # Шаги действия
    steps:
      # Шаг 1: собираем сервисы в режиме тестирования
      - uses: actions/checkout@v2
      - name: Build the stack
        run: docker-compose -f docker-compose.prod.yml -f docker-compose.test.yml up -d --build
 
      # Шаг 2: собираем проект с тестами
      - name: Build tests
        run: dotnet build GOT.Tests

      # Шаг 3: запускаем тесты с небольшой детализацией
      - name: Run tests
        run: dotnet test LOT.Tests --verbosity normal

После сохранения файла в репозитории по пути RepositoryName/.github/workflows/FileName.yml мы можем перейти на вкладку «Actions» и обнаружим там наш новый флоу:

Если все было настроено верно, то при открытии pull request на master или при коммите на master (за последнее имеется отдельный котел в известном месте) Github запустит флоу, который пойдет по шагам и сначала соберет и запустит ваши контейнеры, а затем соберет и запустит проект с тестами, попутно выводя всю информацию из консоли своей виртуальной машины прямо в вашем браузере. При желании можно прикрутить бота Github, который будет сообщать о проблемах с тестами, заведет новые ишью, если тест не был пройден, а также сообщит вам в Slack/Telegram о проблемах. Все ограничено лишь фантазией и сроками. Тесты – это хорошо, но как насчет автоматизации доставки?

Автоматизация доставки

Но и тут у Github Actions есть все, что необходимо, но для полного понимания концепции стоит провести небольшой экскурс по возможностям Github:

• Github Packages – используется для хранения сборок. В нашем случае мы используем его как внешний Docker registry. Подробности можно посмотреть тут.

• Secrets – «секреты» на уровне репозитория или организации. С их помощью можно доверить Github такие ценные вещи, как логины, пароли, токены. Преимущество секретов в том, что даже в случае утраты доступа к аккаунту никто не получит доступа к секретам: Github выведет только их название, сами значения после нажатия “Save” останутся секретом для всех. Больше о секретах.

• Github Actions от сторонних разработчиков. Маркетплейс различных экшенов растет очень быстро, с каждым месяцем появляются сотни различных интеграций и возможностей для разработчиков: Jira, Azure, Telegram, Slack и так далее. На момент написания статьи в маркетплейсе было более 9000 экшенов.

Будем использовать все эти возможности, чтобы реализовать полноценный CI для обновления тестового стенда.

Подбираем подходящие экшены

Нам понадобятся экшены для логина в Github Packages, для сборки образов микросервисов, для публикации образов в Github Packages. Также нам пригодится экшен, умеющий устанавливать SSH-соединение к нашей виртуальной машине и выполнять произвольные команды.

После небольшого поиска по маркетплейсу и изучения документации был подобран следующий список экшенов:

• docker/setup-qemu-action@v1 – надстройка для виртуализации

• docker/setup-buildx-action@v1 – модуль Docker для сборки образов

• docker/login-action@v1 – экшен для логина в Docker Registry (в нашем случае – Github Packages)

• docker/build-push-action@v2 – экшен сборки и публикации образа

• appleboy/ssh-action@master – экшен для инициализации подключения по SSH и выполнения скрипта 

Настраиваем секреты

Один из немногих случаев, когда можно сделать скрин из приватного production-репозитория.

Небольшие пояснения:

REGISTRY_TOKEN – токен для авторизации в Github Packages. Его можно получить тут.

SERVER_HOST – IP-адрес сервера в виде «192.168.100.100».

SERVER_KEY – PEM-ключ для подключения к серверу. Обычно выдается провайдером вашей виртуальной машины.

SERVER_PORT – порт сервера для SSH-соединения. По-умолчанию это 22.

SERVER_USERNAME – имя пользователя, под которым авторизовываемся на виртуальной машине.

Как было описано выше про секреты, у нас нет возможности посмотреть, чему равен тот или иной секрет: Github даже не дает нам кнопки для просмотра этих значений.

Самое время готовить стенд: напишем docker-compose и залогинимся в Github Packages. После сборки и публикации образов в Github Packages нам необходимо подключиться к удаленной машине, выгрузить и запустить новую сборку. Для этого будем использовать практически тот же docker-compose файл, что и для локальной сборки и запуска, но немного отредактируем его. Во-первых, в качестве «image» будем использовать ссылку на Github Packages, где у нас будет опубликована сборка. Во-вторых, уберем из docker-compose-файла все параметры, которые касаются именно сборки: тут они нам попросту не нужны, так как сервер отныне не отвечает за сборку.

По итогу у нас получился примерно такой файл (некоторые параметры исправлены на «template»):

version: "3.4"
services:
  template-server:
    image: ghcr.io/template-inc/prod-template-server:latest
    environment:
      DB_CONNECTION_STRING: "${DB_CONNECTION_STRING}"
      DOCKER: "true"
      EMAIL_SERVER: "http://template-email-server"
    restart: always
    links:
      - template-db
    networks:
      template-network: 

  template-db:
    image: postgres:11
    volumes:
      - db-volume:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_NAME}
    restart: always
    networks:
      template-network:

  template-nginx:
    image: ghcr.io/template-inc/prod-template-nginx:latest
    restart: always
    networks:
      template-network:
    depends_on:
      - template-server
    ports:
      - "90:80" 

networks:
  template-network:

volumes:
  db-volume:

Маленькое примечание: ссылка на image не должна содержать заглавных букв. Даже если имя репозитория или логин содержат заглавные буквы, в ссылке приведите их к lower-case формату. Иначе возникнут проблемы.

Опубликуем этот файл прямо в стартовом каталоге виртуальной машины, чтобы не усложнять скрипт запуска. Для примера назовем его «docker-compose.prod-ci.yml». Также, раз мы уже на машине, сразу залогинимся в Github Packages:

«docker login ghcr.io --username yourGithubUsername --password yourGithubToken»

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

Пишем workflow

Просто собираем все наши знания, которые получили по ходу чтения документации соответствующих экшенов, и агрегируем их в одном файле:

name: 'build and deploy test server'
on:
  release:
    types: [published]
  workflow_dispatch:
jobs:
  build:
    name: 'Build & Publish'
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout repository"
        uses: actions/checkout@v2
        
      - name: "Set up QEMU"
        uses: docker/setup-qemu-action@v1
        
      - name: "Set up Docker Buildx"
        uses: docker/setup-buildx-action@v1

      - name: "Login to GitHub Registry"
        uses: docker/login-action@v1 
        with:
          registry: ghcr.io
          username: "yourGithubUsername"
          password: ${{ secrets.REGISTRY_TOKEN }}
          
      - name: "Build&Deploy template-server"
        uses: docker/build-push-action@v2
        with:
          push: true
          tags: |
            ghcr.io/${{ github.repository_owner }}/prod-template-server:${{ github.event.release.tag_name }}
            ghcr.io/${{ github.repository_owner }}/prod-template-server:latest
          secrets: |
            "ASPNETCORE_ENVIRONMENT=Release"
          build-args: |
            build_mode=Release
            
      - name: "Build&Deploy template-nginx"
        uses: docker/build-push-action@v2
        with:
          push: true
          tags: |
            ghcr.io/${{ github.repository_owner }}/prod-template-nginx:${{ github.event.release.tag_name }}
            ghcr.io/${{ github.repository_owner }}/prod-template-nginx:latest
          build-args: |
            build_mode=Release

      - name: "Run deploy on server"
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USERNAME }}
          key: ${{ secrets.SERVER_KEY }}
          port: ${{ secrets.SERVER_PORT }}
          script: |
            sudo docker-compose -f docker-compose.prod-ci.yml -p prod pull
            sudo docker-compose -f docker-compose.prod-ci.yml -p prod up -d

Сохраним этот файл в репозитории по пути .github/workflows/test-server-ci.yml.

На этом настройка закончена. Переходим на вкладку «Actions» и видим новый экшен «build and deploy». Триггерами этого экшена выступают два действия: публикация нового релиза и ручной запуск.

Ручной запуск экшена можно осуществить прямо со страницы экшена. Для этого нажимаем «Run workflow», выбираем ветвь, с которой будет осуществляться сборка, и запускаем.

Для срабатывания триггера нового релиза зайдем в раздел «Releases» репозитория и создадим новый релиз, нажав «Draft a new release»:

Заполним основную информацию про новый релиз:

 Сразу после нажатия «Publish release» сработает триггер и начнет выполнять все те шаги, которые мы описали: виртуальная машина Github’а клонирует себе репозиторий, залогинится в Github Packages, установит необходимые для Docker инструменты, соберет образы, опубликует их, затем подключится к нашей виртуальной машине и выполнит скрипт, который подключится к Github Packages, стянет последние сборки сервисов и развернет их. А за всем процессом можно зорко следить прямо в консоли запуска на Github. Разве это не прекрасно?

Бэкапы баз данных 

Какие шансы, что вы не потеряете свои данные в случае, если совершаете по 2-3 обновления в неделю, многие из которых мигрируют базу?

Поэтому практически сразу встал вопрос о том, как автоматизировать создание бэкапов баз данных. Тем более, когда их несколько, а варианты с готовыми системами управления либо дорогие, либо очень дорогие. И вновь на помощь приходит Github Actions!

В прошлом примере мы рассматривали подключение к серверу и выполнение некоторых скриптов. Кажется, это нам и нужно, ведь порты к базам данных закрыты и извне подключаться к ним – идея не очень хорошая.

Начнем с разметки каталогов на сервере: в корне создадим каталог db_backup, внутри него - template-db и template-identity-db. 

В каталоге db_backup создадим маленький скрипт:

#db username
dbUsername="<your db username>"

# container additionals
containerPrefix="prod_"
containerPostfix="_1"

#container names
templateDb="template-db"
templateIdentityDb="template-identity-db"

#create template-db backup
cd $templateDb
docker exec -t $containerPrefix$templateDb$containerPostfix pg_dumpall -c -U $dbUsername > dump_$(date +%Y-%m-%d_%H_%M_%S).sql
echo "Backup of" $templateDb "created success"
cd ../

#create template-identity-db backup
cd $templateIdentityDb 
docker exec -t $containerPrefix$templateIdentityDb$containerPostfix pg_dumpall -c -U $dbUsername > dump_$(date +%Y-%m-%d_%H_%M_%S).sql
echo "Backup of" $templateIdentityDb "created success"
cd ../

echo "All database backups created success!"

Это максимум, который удалось реализовать за 15 минут, загуглив общий синтаксис sh-скриптов. Но этого нам хватит. Сохраним файл под именем create_backups.sh.

Теперь переходим к репозиторию и создадим новый workflow по аналогии выше:

name: 'Create prod database backups'
on:
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:
  
  # Run action every day
  schedule:
  - cron: "0 0 * * *"

jobs:
  build:
    name: 'Build & Publish'
    runs-on: ubuntu-latest
    steps:
      - name: "Run backup script on server"
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USERNAME }}
          key: ${{ secrets.SERVER_KEY }}
          port: ${{ secrets.SERVER_PORT }}
          script: |
            cd db_backup/
            sudo bash create_backups.sh

К слову, тут появился новый для этого материала тип триггера – schedule. Данный вид триггеров запускается по расписанию, а вот время запуска описано в формате «cron» (подробнее): многим ненавидимый, но в то же время прекрасный формат, позволяющий прописывать правило времени.

Итак, что мы имеем по итогу: раз в сутки (в полночь по UTC) на Github срабатывает триггер и запускает экшен, который, в свою очередь, устанавливает соединение с нашим сервером и выполняет скрипт запуска нашего бэкап-скрипта. Бэкап-скрипт пробегается по контейнерам с базами данных и создает бэкапы в соответствующих каталогах. Также у нас есть возможность создать резервные бэкапы вручную со страницы соответствующего workflow. Все, что вам останется – придумать, куда отправлять бэкапы на долгосрочное хранение.

К слову, автоматизированное создание бэкапов из 5 контейнеров занимает у нас 13-15 секунд вместе с подключением к серверу. Неплохо, не правда ли?

Заключение

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