Привет! Это вторая моя статья о новом проекте — telegram bot на python, по продаже товаров. В первой части я описал, с чего начал этот проект и какой был финальный результат. Сегодня я хочу поговорить о CI/CD проекта.
Когда проект достиг стадии MVP (minimum valuable product, минимально жизнеспособный продукт) - очень хотелось вывести его в свет. Для того, чтобы бот постоянно работал, для первых пользователей (тут кто-то был слишком оптимистичен, без рекламы к боту пользователи не придут) и для того, чтобы была возможность выкатывать остальную функциональность маленькими итерациями. Время делать CI/CD.
И снова хотел бы напомнить, что я не профессиональный DevOps, а всего лишь тестировщик. Поэтому текст ниже — всего лишь мой опыт, а не руководство, как делать правильно бота профессионально.
Начнем с CI
Под CI я понимаю запуск тестов, сборку docker image и публикацию артефактов — тех самых images — в репозиторий. Решил не использовать сторонних сервисов, а сделать все на основе GitHub. В целом, как работать с GitHub Actions, можно почитать в официальной документации, тут я попытаюсь описать неочевидные для меня вещи.
Первая неочевидная вещь - как опубликовать docker image в реестр. Я пробовал несколько actions, пытался писать свой скрипт и, в конечном итоге, остановился на официальном Build and push Docker images:
uses: docker/build-push-action@v1
with:
push: true
username: ${ GITHUB_ACTOR }
password: ${{ secrets.PACKAGE_REGISTRY_TOKEN }}
registry: docker.pkg.github.com
repository: yurii-hunter/upsale/upsale
tag_with_ref: true
add_git_labels: true
tag_with_sha: false
Вторая неочевидная вещь - secrets.PACKAGE_REGISTRY_TOKEN. В интернете разработчики используют secrets.github_token - это стандартный токен, с которым пакет соберется и, даже, опубликуется в вашем реестре. Проблема лишь в том, что после публикации пакета не срабатывается триггер у других actions. В моем случае должен был запуститься следующий workflow для CD. Чтобы триггер сработал, нужно создать новый секрет, в моем случае secrets.PACKAGE_REGISTRY_TOKEN и дать ему права на чтение/запись в реестр.
Также интересно: Как создать бота в Telegram: большая инструкция
Переходим к CD
В моем случае CD - это доставка артефактов на сервер, миграция базы, запуск приложения. Возможности автоматического отката или бесшовной поставки - нет, да она и не нужна пока. В случает с CI, использовался GitHub-ранер. В бесплатной версии GitHub пользователю предоставляется несколько машино\часов для сборки проектов, чего вполне достаточно для домашнего проекта. Но для CD нужен собственный ранер, который возможно занять на постоянной основе, и на котором будет запущен весь проект.
Добавляем свой runner в GitHub
Для этого проекта использовались сервера Digital Ocean, так что ниже изложена инструкция по добавлению Docker droplet в качестве ранера к существующему проекту:
- После создания дроплета
Docker 5:19.03.1~3 on 18.04, заходим на него через ssh; - Первое, что нужно сделать - добавить пользователя, так как GitHub Runner не позволяет запустить агент от root;
$ adduser github - Вводим пароль и заполняем информацию о пользователе. Или можно оставить ее пустой;
- Добавляем пользователя в группы sudo и docker;
$ adduser github sudo $ sudo usermod -aG docker github $ newgrp docker - Логинимся только что созданным пользователем;
$ sudo su - github - Скачиваем и устанавливаем ранер, как указанно в инструкции Settings -> Actions -> Add runner. Имена ранера и рабочей директории можно оставить со значениями по умолчанию;
- Чтобы запустить ранер как сервис, останавливаем текущий скрипт
Ctrl+C; - Устанавливаем сервиса ранера;
$ ./svc.sh install - Запускаем ранер как сервис;
$ ./svc.sh start - В workflow yaml файле меняем
runs-on: ubuntu-latestнаruns-on: self-hosted;
Реализация Deploy Workflow
Идея такая, что должно быть два workflow. Первый - CI, срабатывает на каждый комит в master-ветку. Он собирает артефакты и публикует их в репозиторий. Второй - CD, срабатывает на публикацию пакета в реестр и дальше доставляет этот пакет на специальный агент. Так как это бот-магазин, то CD workflow может быть несколько (по одному на каждый магазин). Это основная причина, почему сборку и доставку разделил на два отдельных процесса.
Ниже приведен пример, как указать в yaml файле тригер на публикацию пакета. И как запускать флоу на личном ранере
on: registry_package
jobs:
deploy:
runs-on:
- self-hosted
Дальше выполняются шаги с docker-compose по обновлению приложения. Шаги следующие: остановить приложение, забрать последнюю версию артефактов, мигрировать базу, запустить новую версию приложения.
- name: stop application
run: docker-compose down
- name: pull images
run: docker-compose pull
- name: migrate database
run: docker-compose up migration
- name: start application
run: docker-compose up -d admin bot-client
На данный момент бот постоянно работает и быстро обновляется после выхода новой версии.
Надеюсь, вам было полезно и познавательно. Тема не очень простая, так что любые вопросы и замечания оставляйте в комментариях под этим постом.
Также, если вам интересно следить за дальнейшим развитием этого проекта, то в telegram канале я публикую маленькие заметки по этой теме.
