Финальная работа курса "Python Advanced". Корпоративный сервис микроблогов

Задача

Для корпоративного сервиса микроблогов необходимо реализовать бэкенд приложения. Поскольку это корпоративная сеть, то функционал будет урезан относительно оригинала.

Более подробно задача и требуемый функционал описаны в ТЗ.

Функциональные требования:

• Пользователь может добавить новый твит.
• Пользователь может удалить свой твит.
• Пользователь может зафоловить другого пользователя.
• Пользователь может отписаться от другого пользователя.
• Пользователь может отмечать твит как понравившийся.
• Пользователь может убрать отметку «Нравится».
• Пользователь может получить ленту из твитов отсортированных в порядке убывания по популярности от пользователей, которых он фоловит.
• Твит может содержать картинку.

Нефункциональные требования:

• Систему должно быть просто развернуть. Например, через Docker Compose.
• Система не должна терять данные пользователя между запусками.
• Все ответы сервиса должны быть задокументированы через Swagger.
• Документация должна быть доступна в момент запуска приложения.

Стэк

• Python >= 3.9
• FastAPI
• SQLAlchemy
• Alembic
• PostgreSQL
• Docker

Запуск окружения разработки

1. Поднять ВМ (на ВМ будут установлены ansible, docker и docker-compose)

   # On Linux
   make vm-up-provision NAME=dev
   
   # On Windows
   vagrant up dev --provision

2. Подключиться к ВМ

   # On Linux
   make vm-connect NAME=dev
   
   # On Windows
   vagrant ssh dev

3. В терминале ВМ перейти в директорию с проектом

   cd /vagrant

4. Поднять контейнеры для разработки

   make up

Документация Swagger

При работе через VM Vagrant документация Swagger доступна по адресу http://192.168.1.33:5000/docs.

Миграции

make migrate

Тестирование

make lint

make test

Структура БД

Структура спроектирована в dbdiagram.io.

Демо-стенд

Для демонстрации и проработки полного цикла CI/CD можно развернуть демо-стенд, основанный на виртуальных машинах Vagrant. Конфигурация ВМ описана в Vagrantfile. Виртуальные машины разворачиваются и настраиваются автоматически, но может потребоваться небольшая ручная конфигурация, описанная ниже.

Компонентная схема

Запуск и настройка демо-стенда

1. Поднять демо-стенд. Автоматическое настраивание виртуальных машин займет где-то 15-20 минут.

   vagrant up gitlab backend frontend

2. Перейти в GitLab http://192.168.1.34/ и зарегистрировать нового пользователя

3. Узнать пароль пользователя root от GitLab

   vagrant ssh gitlab -c "docker exec gitlab grep 'Password:' /etc/gitlab/initial_root_password"

4. Одобрить регистрацию нового пользователя из под пользователя root

5. Сделать дефолтной веткой ветку master. Ветка master нужна, потому что автоматическое версионирование настроено на эту ветку.

   

6. Войти под созданным ранее пользователем и создать новую публичную группу python_advanced_diploma и новый публичный проект tweetty в созданной группе. На самом деле имена группы и проекта не важны, но с целью упрощения последующих команд в них используются именно эти имена.

7. Зарегистрировать новый Gitlab Runner

   vagrant ssh gitlab -c "docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register"

   

8. Получить публичный ключ dokku для деплоя из гит-репозитория

   vagrant ssh backend -c "dokku git:public-key"

9. Добавить полученный на предыдущем шаге ключ в GitLab

   

10. После всех настроек должна появиться возможность синхронизации с гит-репозиторием. Следующей командой можно проверить доступность ВМ gitlab через платформу Dokku, которая настроена на ВМ backend

    vagrant ssh backend -c "dokku git:sync tweetty [email protected]:python_advanced_diploma/tweetty.git master"

    В результате должны увидеть на консоли что-то похожее

    -----> Cloning tweetty from [email protected]:python_advanced_diploma/tweetty.git#
           Detected branch, setting deploy-branch to master

Настройка автоматического версионирования и создания релизов

Для авоматического версионирования и создания релизов используется библиотека python-semantic-release. Конфиг для python-semantic-release настроен на основной репозиторий проекта, поэтому на демо-стенде эта функция работать не будет. Чтобы процесс CI/CD продолжал работать без ошибок, автоматическое версионирование отключено на уровне .gitlab-ci.yml.

Дальнейшие шаги приводятся для справки.

1. Создать Access Token в проекте tweetty. После создания токена нужно скопировать его, потому что он потребуется на следующем шаге

   

2. Создать переменную GL_TOKEN в переменных CI/CD и указать в качестве значения токен с предыдущего шага. Эта переменная нужна для автоматического создания релизов

   

Настройка деплоя из GitLab через SSH

Подробно требования по настройке описана в документации GitLab.

1. Получить содержимое приватного ключа, сгенерированного на ВМ gitlab

   vagrant ssh gitlab -c "cat /home/vagrant/.ssh/gitlab_id_ed25519"

2. Создать переменную SSH_PRIVATE_KEY с типом File в проекте tweetty и поместить в нее содержимое приватного ключа, полученное на предыдущем шаге.

   

   Очень важно, чтобы значение переменной содержало в конце одну пустую строку

   

3. Получить значение публичного ключа, сгенерированного на ВМ gitlab

   vagrant ssh gitlab -c "cat /home/vagrant/.ssh/gitlab_id_ed25519.pub"

4. Добавить публичный ключ в список авторизованных на ВМ backend

   vagrant ssh backend -c "echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMPENs+2RCvgZiTbH43jgD3RNIgYLDudV25yiJx1UFih gitlab_key' | sudo tee --append /home/dokku/.ssh/authorized_keys"

Публикация изменений в репозиторий демо-стенда

1. Добавить новый remote в свой гит

   git remote add demo http://192.168.1.34/python_advanced_diploma/tweetty.git

2. Пушить в GitLab демо-стенда можно командой

   git push --tags -u demo <local_branch>:<remote_branch>

Полезные материалы

• Коды статусов HTTP
• pyproject.toml
• CI: Python Semantic Release
• CI: Python Semantic Release example
• Angular commit message styleguide
• SQLAlchemy: relationship для асинхронного подключения, способ 1
• SQLAlchemy: relationship для асинхронного подключения, способ 2
• SQLAlchemy: множественные ForeignKey на одно и то же поле
• FastAPI: Переопределение имен полей в респонсе
• FastAPI: Авторизация с APIKey, пример 1
• FastAPI: Авторизация с APIKey, пример 2
• FastAPI: Передача файлов в запросе
• FastAPI: Как ограничить размер загружаемого файла
• FastAPI: Параметризация зависимостей
• FastAPI: Обработка ошибок
• Pydantic: Вычисляемые поля
• HTTPX: Передача файлов в запросе AsyncClient
• Pytest: Использование фикстур из различных модулей
• GitLab: Установка GitLab из docker-образа
• GitLab: Установка gitlab-runner
• GitLab: Использование SSH-ключей в CI/CD
• Dokku: Установка
• Dokku: Установка из репозитория