Автоматическое развертывание Python проекта на виртуальном хостинге через GitHub Actions

Просмотров статьи: 39

Содержание

Подготовка (важнейший пункт)

Hello World! всем участвующим и обучающимся!
Хотите, что бы ваш python проект работал в интернете но вы ни капли не девопс и постоянно лазить на сервер обновляя код совсем вам не нравится?

Умные люди придумали для таких ленивых как мы все уже давно и заранее!

Кстати, хотите мудрость народную?

Трудные времена рождают хороших программистов.
Хорошие программисты создают фреймворки и сервисы.
Фреймворки и сервисы рождают плохих программистов.
Плохие программисты порождают трудные времена.

На каком мы уровне решайте сами, а мы начнем разжевывать элементарщину)

p.s. Я самоучка, я могу называть какие-то вещи не так как называют профессиональные прогеры из офиса с латте в руках, но у меня есть один плюс: все, что я пишу — работает и я это проверяю в процессе создания статьи. Контент не ради контента. Считайте личным конспектом в открытом доступе.

План статьи будет такой

Регистрируемся на хостинге и покупаем сервер
Создаем Github репозиторий и настраиваем ключи авторизации и SSH ключи сервера
Создаем на сервере сервис для автоматического запуска проекта
Создаем Workflow для CI/CD
Разбираемся что такое «workflow и ci/cd»
Делаем изменения в проекте на локальной машине и пушим обновления в Github, проверяем работу.
Думаем как нам на сервер закинуть .env файл не загружая его в github (подсказка FTP-костыль)
Подписываемся на все, что я оставлю в конце статьи ибо не зря я столько накатал просто так )

1. Хостинг и VPS сервер для самых маленьких

Хостинг это организация у которых есть железо и за денежку они дают вам возможность пользовать частичку их железа в своих целях.

Из популярных русскоязычных могу назвать те, которые я использовал или использую:

Timeweb
Beget
Reg.ru

В иностранном сегменте пытался работать с godaddy но сгорел от тех поддержки и адового количества функций и настроек в панели управления от которого хочется выпилиться сразу. Запросил возврат денег так и не прислали. (100$ в пустую ушли крч.)

Сейчас работаю с Beget и Timeweb

Оба хостинга хороши, но по моему скромному мнению Timeweb семимильными шагами идет в сторону добавления в свой функционал дополнительных плюшек типа VPN сети и авторазвертывания приложений на Django, Flask, FastApi, React и куче других фреймворков

Я Django развернул тупо подключив репозиторий гитхаба сюда и оно все само там натворилось.

Beget больше для WordPress подошел, там есть тоже аренда VPS сервера но как то мало

Отвлеклись.

Идем на Timeweb Cloud платформу и регистрируемся (ссылочка реферальная, регистрируйтесь по ней там 300р на баланс начислят при покупке VPS, на месяц хватит)

Сразу смотрим на виртуальные серверы и что мы можем купить

Все доступы есть сразу в панели

2. Создаем Github репозиторий и настраиваем ключи авторизации и SSH ключи сервера

Откройте терминал (для Windows Win+R и выполнить команду cmd).
Введите следующую команду для генерации нового SSH-ключа:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Укажите имя файла для сохранения ключа (по умолчанию: ~/.ssh/id_rsa). Нажмите Enter, если хотите использовать стандартное имя.
По желанию, установите пароль для ключа. Если хотите использовать ключи без пароля, просто нажмите Enter.

Копирование публичного ключа на сервер Timeweb

Теперь нужно добавить публичный ключ на сервер:

Скопируйте публичный ключ на сервер (для Linux пользователей):
ssh-copy-id user@your_server_ip
Здесь user — ваше имя пользователя на сервере(root по умолчанию), а your_server_ip — IP-адрес вашего сервера на Timeweb.
Для Windo-нутых людей начинается карусель)
2.1 Идем в C/Пользователи(users)/Ваш пользователь/.ssh/
2.2 Открываем блокнотиком id_rsa.pub (или как вы там его назвали)
2.3 Открываем консоль на компьютере и идем на наш сервер по логину и паролю
2.4 Копируем из блокнотика наш публичный ключик
2.5 Пишем echo «ВАШПУБЛИЧНЫЙ КЛЮЧ» >> ~/.ssh/authorized_keys
2.6 В кавычках вставляем ваш ключ из блокнота (вставка в консоли винды на ПКМ)
Проверяем вход без пароля на наш сервер из консоли (p.s. если все верно — будет заходить сразу)

Итак, для работы с Github нам в первую очередь нужен ключ доступа (PAT или Personal Access Token) к нашей учетке вместо пароля

Жмем на свою аватарку
Settings — > Developer Settings (внизу самом) -> Personal Access Token -> Tokens (classic)

Создаем токен, определяем ему права которые ходим себе дать (все дааа) (важно обязательно права на workflow натыкать галочку)

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

ТЕПЕРЬ ЭТО ВАШ ПАРОЛЬ ОТ GITHUB ЕСЛИ ПОТРЕБУЕТСЯ!

Создаем пустой репозиторий, пусть висит

Что касается наших ключей для доступа к серверу

ВНИМАНИЕ! Теперь нам понадобится SSH приватный ключик

Для того чтобы GitHub мог подключаться к вашему серверу через SSH, нужно добавить приватный ключ в секцию Secrets в вашем репозитории на GitHub:

Идем на страницу вашего репозитория на GitHub.
Нажмите на вкладку «Settings» и выберите «Secrets and variables» -> «Actions».
Нажмите «New repository secret» и добавьте новый секрет с именем SSH_PRIVATE_KEY.
Вставьте в поле значение вашего приватного ключа (его содержимое из файла ~/.ssh/id_rsa).

Там по необходимости можете задать еще секреты, содержащие IP сервера и имя пользователя, если есть такое желание.

Клонируем наш репозиторий на локальный компьютер и пишем какой-никакой простенький код, который можем проверить

Простой без библиотек код с выводом в браузер, что бы было легче отследить изменения

Пушим код в Github и переходим на наш сервер

На сервере нам нужно клонировать ваш репозиторий в папку home. Логин и пароль просить не должно, но вдруг запросит то пароль — это ваш ключ который мы создавали вначале (PAT)

Клонирование вручную поможет заранее настроить пути к файлам при настройке сервиса и файла авторазвертывания

3. Создаем сервис для запуска скрипта VPS

Чтобы создать системный сервис, который будет запускать наш сервер, вам нужно создать файл службы в /etc/systemd/system/

Переходим в каталог
cd /etc/systemd/system/
Создаем файл torch happy.service

p.s. можно создать файл через редактор nano или vi, но я люблю midnight commander поэтому создаю пустой файл. Здесь на ваш вкус.

Открываем файл через midnight commander (mc)

Пишем сервис
[Unit]
Description=Happy Server
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/Happy_Python_Teach_Workflow/main.py
WorkingDirectory=/home/Happy_Python_Teach_Workflow
StandardOutput=inherit
StandardError=inherit
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Разбор systemd unit файла

[Unit]

Description=Happy Server
Описание сервиса. Это краткое описание, которое будет отображаться в списке сервисов.
After=network.target
Указывает, что сервис должен запускаться только после того, как будет поднята сеть. Это важно для сервисов, которые зависят от наличия сети.

[Service]

ExecStart=/usr/bin/python3 /home/Happy_Python_Teach_Workflow/main.py
Команда для запуска сервиса. Здесь указано, что должен запускаться Python интерпретатор и выполняться скрипт main.py, который расположен по указанному пути.
WorkingDirectory=/home/Happy_Python_Teach_Workflow
Рабочая директория, из которой будет запускаться сервис. Это важно, если ваш скрипт использует относительные пути для доступа к файлам.
StandardOutput=inherit
Весь вывод в стандартный поток вывода (stdout) будет перенаправляться в журнал systemd.
StandardError=inherit
Весь вывод в стандартный поток ошибок (stderr) также будет перенаправляться в журнал systemd.
Restart=always
Указывает, что сервис должен автоматически перезапускаться в случае его завершения (ошибки, падения и т.д.).
User=root
Определяет пользователя, от имени которого будет запущен сервис. В данном случае сервис запускается от имени root.

[Install]

WantedBy=multi-user.target
Указывает, что сервис должен автоматически запускаться в режиме multi-user, который является обычным многопользовательским режимом без графического интерфейса.

Ремарка: Использование виртуального окружения (venv)

Что изменится, если вы используете venv?

Если ваше приложение использует виртуальное окружение, вам нужно будет скорректировать ExecStart, чтобы указать на интерпретатор Python, установленный внутри виртуального окружения.

[Unit]
Description=Happy Server
After=network.target

[Service]
ExecStart=/home/Happy_Python_Teach_Workflow/venv/bin/python /home/Happy_Python_Teach_Workflow/main.py
WorkingDirectory=/home/Happy_Python_Teach_Workflow
StandardOutput=inherit
StandardError=inherit
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Сразу даю команды для управления systemd-сервисом.

Запуск сервиса: sudo systemctl start имя.service
Остановка сервиса: sudo systemctl stop имя.service
Перезапуск сервиса: sudo systemctl restart имя.service
Включение автозапуска при старте системы: sudo systemctl enable имя.service
Перезапуск конфигурации systemd (после изменений в юнит-файле): sudo systemctl daemon-reload
Просмотр статуса сервиса: sudo systemctl status имя.service
Просмотр журнала ошибок: sudo journalctl -u имя.service

Сейчас, если сделать daemo-reload и потом start то наше приложение запустится и будет доступно по адресу сервера на порту 8000)

Это может быть как бот, так и любой другой скрипт. Вебку делал для наглядности

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

Теперь настраиваем наше авторазвертывание.

3. Создаем Workflow для CI/CD (Github Actions)

В корне вашего проекта создайте директорию .github/workflows/.

Внутри нее создайте файл deploy.yml и добавьте следующий код

name: Deploy by Happy Python

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Deploy to VPS via SSH
      uses: appleboy/ssh-action@master
      with:
        host: 188.225.86.62
        username: root
        key: ${{ secrets.SSH_PRIVATE_KEY}}
        script: |
          cd /home/Happy_Python_Teach_Workflow
          git pull origin main
          sudo systemctl restart happt.service

Ух, поехали.
Как я и говорил хост и юзера можете спрятать там же где и ключ и заменить переменной по аналогии с SSH_PRIVATE_KEY

Особенности!

Если есть requirements и venv то код будет слегка дополнен в поле script:
script: |
cd /home/Happy_Python_Teach_Workflow
git pull origin main
source venv/bin/activate
pip install -r requirements.txt
sudo systemctl restart happt.service

Если заметили, то в файле есть шаги (steps) и если дальше упороться, то можно добавить еще один или два отдельных шага с запуском виртуального окружения и установкой зависимостей

В начале нашей инструкции вы заметили наверное
on push branches main

Автодеплой сработает при пуше в main

Есть и такой вариант, он сработает при слиянии веток в main. Тоже на ваш вкус и цвет.

4. Разбираемся что такое «workflow и ci/cd»

Workflow: Как это работает?

Представьте себе workflow как чёткий план для вашего проекта. Это как рецепт, по которому мы готовим наш цифровой пирог. Каждое действие — от проверки кода до развертывания приложения — описано в виде последовательности шагов. Так что, если вы когда-нибудь хотели, чтобы кто-то готовил вашу работу за вас (в хорошем смысле или нет), вот это оно!

Пример:

Шаг 1: Проверьте код.
Шаг 2: Запустите тесты.
Шаг 3: Разверните приложение.

И всё это делается автоматически. Вам не нужно думать о том, чтобы что-то проверить вручную. Workflow как добрый волшебник, который делает всю черновую работу за вас (черновую прошу не читать буквально).

CI/CD: Чудо-спасатель от багов

Теперь поговорим о CI/CD. Это как супергеройский костюм для вашего проекта. » глубокий вдох»

CI (Continuous Integration): Это когда ваш код постоянно интегрируется в основную ветку. Всё, что вам нужно, — это добавлять свои изменения, а CI будет заниматься всем остальным: проверять, тестировать и интегрировать. Ваш проект не остановится, потому что один разработчик забыл что-то проверить. Вроде как регулярные проверки на здоровье, но для кода.
CD (Continuous Delivery/Deployment): Это когда ваш код не просто интегрируется, но и автоматически развертывается в продакшене. Если CI — это доктор, который следит за здоровьем вашего кода, то CD — это врач, который делает всё, чтобы ваш код всегда был готов выйти на сцену. Он развертывает всё за вас, как мега-менеджер по подготовке мероприятий.

«выдох»

В итоге

Workflow и CI/CD превращают вашу разработку в гладкую и эффективную машину. Представьте себе, что они как умный помощник, который делает всю работу по проверке и развертыванию, позволяя вам сосредоточиться на создании крутого контента и фич!

Так что, если хотите, чтобы ваш код путешествовал по разработке как по автостраде, а не как по ухабистой дорожке, workflow и CI/CD — это ваш путеводитель к успеху.

Выдал базу как говорится!

5. Делаем изменения кода, проверяем работу деплоя

Если мы поменяем наш код в локальном проекте (обращаю внимание, что наш деплой настроен только на пуш в ветку main для примера), я добавлю к тексту пару слов, то при пуше изменений мы должны увидеть кой-чего

В нашем репозитории появится вот такой значечек)
И если тыкануть на details то увидим все процессы

А еще, обновив браузер вон че увидел

Теперь мы просто пишем проект, кидаем пуши в main ( плохая практика не делайте так ) или делаем слияния веток ( тогда перенастройте deploy.yml) и работаем с удвоенной скоростью

6. Как можно добавить .env файл на хостинг

Вообще ну это костыль еще тот, переменные окружения вы можете отдельно прописать на хостинге без всяких .env файлов, но так уже давайте подумаем

Выход простой ( если Timeweb юзать будете)

Качаем FileZilla и подключаемся к серверу по зашифрованному каналу используя данные для входа, котоырые для ssh. Там у нас и ключи уже есть ну вообще да, просто качайте FTP клиент и зашвыривайте туда все, что идет мимо гитхаба.

p.s но я вас этому не учил, это плохо так нельзя, вроде как. Для обучения пойдет схема.