FastAPi build приложения?

Question

[Кирилл Горелов]

У меня есть приложение написанное на fastapi.
Но у него есть проблема, что бы его запустить на сервере нужно сделать кучу манипуляций для его работы. И если меняется код, то нужно сделать почти туже самую работу.

Как это происходит сейчас.
Я создаю создаю службу в линуксе по примеру

[Unit]
Description=Gunicorn instance to serve MyApp
After=network.target

[Service]
User=user
Group=uuser
WorkingDirectory=/var/www/site.ru/public_html
Environment="PATH=/var/www/site.ru/public_html"
ExecStart=/usr/bin/python3.7 -m uvicorn sql_app.main:app --host xx.xx.xxx

[Install]
WantedBy=multi-user.target

Запускаю саму службу.
Прописываю конфиги в nginx для прокси что бы приложение открывалось по домену, а не по ip.
И если повезет, на новом сервере это все заработает хотя бы с раза 10......

И если я меняю код приложения, то мне нужно перезагрузить службу....
А это чертовский неудобно становится....

По билду приложения в доках примерно это все и описано. Но это неудобно, может есть способ иначе как это сделать?
Как-то же django само подтягивает изменения из гита и ничего перезагружать не нужно.

Скорее всего я делаю что-то не так, но как это переделать пока не представляю ....

Буду рад любой помощи.

Comments

[Александр]

@Kirill-Gorelov

FastAPI не содержит встроенных функций для автоматического билда и деплоя приложений.

Как варианты использовать:
Docker: Вы можете запаковать ваше приложение в образ Docker, который может быть легко развернут на любой системе с Docker. Это поможет избежать проблем с конфигурацией системы и установленными пакетами.

Continuous Integration/Continuous Deployment (CI/CD): Можете использовать системы CI/CD, такие как TravisCI, Jenkins, или GitLab CI, чтобы автоматически билдить и деплоить ваше приложение на сервер.

PaaS: Использование платформы как сервис (PaaS) такой как Heroku, также может упростить процесс деплоя, так как они предоставляют инструменты для автоматического деплоя и обновления кода.

Answer 1

[Jack444]

ExecStart=/usr/bin/python3.7 -m uvicorn sql_app.main:app --host xx.xx.xxx --reload

Comments

[Кирилл Горелов]

нуууууу, блин))
Для дебага - да, норм, для прода..., как то сомнительно....
Но за идею спасибо))

[Jack444]

Кирилл Горелов, для прода тоже можно использовать, там есть ещё настройка --reload-delay 0.25
то есть если поставить --reload то по дефолту будет 4 раза в секунду все файлы в проекте на аптайм проверятся, можно смело поднимать до нескольких секунд или минут, сама проверка обновлений быстро отрабатывает, на фоне секунд блокировка не заметна

[Jack444]

Исходники по увикорну ща почитал, оказывается --reload и --workers совместно нельзя использовать, при релоад будет запущен только один воркер =(

[Кирилл Горелов]

Jack444, спасибо, попробую проверить))

Answer 2

[Ян]

Есть же хороший паттерн для этого.
Dockerfile

FROM python:3.10-alpine
WORKDIR /app

ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

COPY ./src/requirements.txt .
RUN pip install --no-cache-dir -r /app/requirements.txt

COPY ./src .

Тут упаковываете в образ свой проект.

И в docker-compose собираете требуемые сервисы. Nginx, Postgre, Redis и т.д.
docker-compose

version: '3'
services:
  db:
    image: postgres:15-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    expose:
      - 5432
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}

  api:
    build:
      context: .
    command: uvicorn main:app --host 0.0.0.0
    ports:
      - 8080:8000
    environment:
      - DATABASE_DSN=${DATABASE_DSN}
    restart: always
    depends_on:
      - db

volumes:
  postgres_data:

И что бы руками каждый раз инфраструктуру не разворачивать пользуемся Github Actions, при взаимодействии с репозиторием он может прогнать тесты, собрать новый образ, залить все на прод сервер и развернуть.