Пользователь
-
Автор темы
- #1
CI/CD с Github Actions для самых маленьких
Сегодня мы поговорим об одной крутой штуке, которая поможет нам автоматизировать процесс сборки и деплоя нашего приложения.
Постараюсь сильно не углубляться в подробности, но если интересна эта тема - пишите комментарии :)
Что такое CI?
Ну, смотри, CI - это почти "казино" для разработчиков (или по-человечески "непрерывная интеграция"), завалятся тесты (если ты их, конечно, написал) или нет.
Что нужно для реализации CI?
Если с ветками и тестами все понятно, то что такое CI-сервер?
CI-сервер - это сервер, который будет запускать тесты и выдавать результаты, а так же сигнализировать об ошибках, если тесты завалились.
Примерами таких серверов могут быть:
Так, вникай. Если лототрон из предыдущего "казино" выбил тебе джекпот ввиде успешных тестов, то ты можешь смело деплоить свое приложение на сервер.
А как проходит этот ваш "деплой"? Зависит от того, как работает твой проект, но в общем случае это выглядит так:
Практика
Мы будем использовать Github Actions для нашего CI/CD.
Почему? Потому что это бесплатно (ну почти, сервер на 2000 минут наш, либо ставь свой Runner на свой сервер), просто и удобно.
Установка Github Actions Runner (Если хочешь, чтобы твой раннер работал на твоем сервере)
Так, приступим. Я начну с установки своего Github Actions Runner`а на свой сервер.
Для установки раннера нужно подготовить сервер, на котором он будет работать.
Я буду использовать сервер на Ubuntu 22.04.
Создаем отдельного пользователя для раннера, чтобы не мучиться с правами:
Выдадим пользователю права суперпользователя:
Переключимся на пользователя:
Приступаем к самому интересному - установке раннера.
Открываем репозиторий вашего проекта и переходим раздел "Settings", у него еще шестеренка в названии.
Далее переходим в раздел "Actions/Runners" и нажимаем на кнопку "New self-hosted runner". Выбираем нашу ОС и архитекрутуру, на которой будет работать раннер. Вводим команды, которые нам выдал Github и запускаем их на сервере, ты же разберешься, как это сделать, да?
После ввода последней команды, инсталлер Github Actions будет спрашивать дополнительную информацию (на это мы пока забьем), тыкаем Enter пока все не закончится.
Так, теперь желательно сделать раннер сервисом, чтобы он работал в фоне и не выключался при закрытии терминала.
После всей этой мишуры, в списке раннеров должно быть видно что-то подобное, можем закрывать терминал и эту вкладку.
Создаем пайпланы
Что такое пайплайн? Пайплайн - это набор шагов, которые выполняются нашим раннером, почти бесплатный раб, да?
Создаем файлик в корне репозитория .github/workflows/deploy.yml и пишем туда следующее:
Пушим в репозиторий и смотрим на результаты.
Статусы пайплайна:
- Если видим жёлтый кружочек - раннер все еще выполняет работу или ждет освобождение раннера.
- Если красный крестик - все плохо, сборка или что-то еще завалилось, в разделе Actions можно посмотреть логи твоего пайплайна.
- Если зеленую галочку - все хорошо, тесты пройдены, сборка выполнена, проект задеплоен.
Сегодня мы поговорим об одной крутой штуке, которая поможет нам автоматизировать процесс сборки и деплоя нашего приложения.
Постараюсь сильно не углубляться в подробности, но если интересна эта тема - пишите комментарии :)
Что такое CI?
Ну, смотри, CI - это почти "казино" для разработчиков (или по-человечески "непрерывная интеграция"), завалятся тесты (если ты их, конечно, написал) или нет.
Что нужно для реализации CI?
- Во-первых, должна быть базовая ветка (например, master, ты ведь пользуешься Git? :) ).
- Во-вторых, должны быть тесты, которые будут проверяться при каждом коммите, мердже или пулл реквесте в эту ветку.
- В-третьих, должен быть CI-сервер, который будет запускать тесты и выдавать результаты.
Если с ветками и тестами все понятно, то что такое CI-сервер?
CI-сервер - это сервер, который будет запускать тесты и выдавать результаты, а так же сигнализировать об ошибках, если тесты завалились.
Примерами таких серверов могут быть:
- Пожалуйста, авторизуйтесь для просмотра ссылки.
- Пожалуйста, авторизуйтесь для просмотра ссылки.
- Пожалуйста, авторизуйтесь для просмотра ссылки.
- Пожалуйста, авторизуйтесь для просмотра ссылки.(одобряем, но не любим)
- Пожалуйста, авторизуйтесь для просмотра ссылки.(сегодня мы именно про него и поговорим)
Так, вникай. Если лототрон из предыдущего "казино" выбил тебе джекпот ввиде успешных тестов, то ты можешь смело деплоить свое приложение на сервер.
А как проходит этот ваш "деплой"? Зависит от того, как работает твой проект, но в общем случае это выглядит так:
- CI дает зеленый свет на деплой
- CI/CD-сервер забирает твой репозиторий и запускает скрипт сборки, билдит Dockerfile и т.д.
- После успешного билда CI/CD-сервер деплоит твое приложение на сервер, по твоему сценарию (например, через SSH)
Практика
Мы будем использовать Github Actions для нашего CI/CD.
Почему? Потому что это бесплатно (ну почти, сервер на 2000 минут наш, либо ставь свой Runner на свой сервер), просто и удобно.
Установка Github Actions Runner (Если хочешь, чтобы твой раннер работал на твоем сервере)
Так, приступим. Я начну с установки своего Github Actions Runner`а на свой сервер.
Для установки раннера нужно подготовить сервер, на котором он будет работать.
Я буду использовать сервер на Ubuntu 22.04.
Создаем отдельного пользователя для раннера, чтобы не мучиться с правами:
Код:
sudo adduser <ник пользователя>
Код:
sudo usermod -aG sudo <ник пользователя>
Код:
su - <ник пользователя>Открываем репозиторий вашего проекта и переходим раздел "Settings", у него еще шестеренка в названии.
Далее переходим в раздел "Actions/Runners" и нажимаем на кнопку "New self-hosted runner". Выбираем нашу ОС и архитекрутуру, на которой будет работать раннер. Вводим команды, которые нам выдал Github и запускаем их на сервере, ты же разберешься, как это сделать, да?
После ввода последней команды, инсталлер Github Actions будет спрашивать дополнительную информацию (на это мы пока забьем), тыкаем Enter пока все не закончится.
Так, теперь желательно сделать раннер сервисом, чтобы он работал в фоне и не выключался при закрытии терминала.
Код:
sudo ./svc.sh install
sudo ./svc.sh startСоздаем пайпланы
Что такое пайплайн? Пайплайн - это набор шагов, которые выполняются нашим раннером, почти бесплатный раб, да?
Создаем файлик в корне репозитория .github/workflows/deploy.yml и пишем туда следующее:
Код:
name: 'Название пайплайна'
on: # Когда будет запускаться пайплайн
push: # При коммите в ветки указанные ниже
branches:
- master # Название ветки, на которую будет реагировать пайплайн
jobs:
deploy: # Имя задачи может быть каким угодно, делай как нравится
runs-on: self-hosted # указываем, что пайплайн будет запускаться на нашем раннере, или укажи ubuntu-latest,
# если хочешь, чтобы пайплайн запускался на серверах Github
steps:
- name: 'Checkout' # Название шага, делай как нравится
uses: actions/checkout@v2 # Используем встроенный шаг для скачивания репозитория в папку раннера.
- name: 'Run tests'
run: 'go test ./...' # Запускаем тесты, в случае Golang проекта, если у тебя другой язык, то пиши свои команды,
# Если тесты завалились, то пайплайн завершится с ошибкой и сборка и деплой не начнется.
- name: 'Build' # Собираем бинарник. Ты напиши свои команды, которые будут собирать твое приложение.
run: |
cd cmd
go build -o app
- name: 'Deploy' # для примера, перезапустим сервис приложения.
# Ты же напиши список своих команд, которые будут деплоить твое приложение.
run: sudo service myBackend restartСтатусы пайплайна:
- Если видим жёлтый кружочек - раннер все еще выполняет работу или ждет освобождение раннера.
- Если красный крестик - все плохо, сборка или что-то еще завалилось, в разделе Actions можно посмотреть логи твоего пайплайна.
- Если зеленую галочку - все хорошо, тесты пройдены, сборка выполнена, проект задеплоен.
