Перейти на PRO

Какие инструменты и подходы вы используете для деплоя Python-приложений

Тип вопроса: Devops Вероятность: 10% Категория: Python Разработчик

Ответ

Мой стандартный подход к деплою Python-приложений основан на контейнеризации с Docker и автоматизации с помощью CI/CD (например, GitHub Actions или GitLab CI).

1. Контейнеризация (Docker)

Каждое приложение упаковывается в Docker-образ для изоляции и переносимости. Это гарантирует, что окружение будет одинаковым на машине разработчика и на продакшн-сервере.

Пример Dockerfile для веб-приложения:

# 1. Используем легковесный базовый образ
FROM python:3.10-slim

# 2. Устанавливаем рабочую директорию внутри контейнера
WORKDIR /app

# 3. Устанавливаем переменные окружения
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# 4. Копируем и устанавливаем зависимости
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 5. Копируем исходный код проекта
COPY . .

# 6. Запускаем приложение через Gunicorn
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "my_project.wsgi:application"]

2. Автоматизация (CI/CD)

Процесс сборки, тестирования и развертывания автоматизируется. При каждом пуше в основную ветку запускается пайплайн, который:

  1. Собирает Docker-образ.
  2. Прогоняет тесты.
  3. Пушит образ в Docker Registry (Docker Hub, GitLab Registry).
  4. Подключается к серверу и обновляет запущенный контейнер.

Пример .github/workflows/deploy.yml:

name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: your-repo/my-app:latest

      - name: Deploy on server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            docker pull your-repo/my-app:latest
            docker-compose up -d --force-recreate

3. Серверная инфраструктура

  • Reverse Proxy: Nginx для обработки входящих запросов, терминирования SSL и раздачи статики.
  • Оркестрация: Docker Compose для простых проектов или Kubernetes для сложных систем, требующих масштабирования и отказоустойчивости.
  • Мониторинг: Prometheus + Grafana для сбора метрик и визуализации состояния системы.

Ответ 18+ 🔞

А, ну вот, опять про деплой питонячего говна. Слушай, я тебе сейчас как свой, так сказать, стандартный подход изложу, а ты не ори, что сложно. Просто я уже на этом собаку съел, а потом и собаку эту задеплоил, блядь.

1. Контейнеризация (Docker)

Первое дело — всё это добро в банку закатать, то есть в контейнер. Чтобы у тебя на ноуте работало, и на серваке потом не вылезло «ой, а у меня библиотека другой версии, ёпта». Всё изолируем, как грешника в аду.

Вот смотри, как Dockerfile для веб-приложения выглядит, обычный такой:

# 1. Берём питон, но не толстый, а тощий, чтоб не жирный был образ
FROM python:3.10-slim

# 2. Говорим: «Работать будешь тут, в этой папке, и не рыпайся»
WORKDIR /app

# 3. Ставим переменные окружения, чтоб питон не мусорил байткодом и не буферизовал вывод
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# 4. Тащим файлик с зависимостями и ставим их все разом
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 5. Ну а теперь уже и весь наш код, со всеми костылями и велосипедами
COPY . .

# 6. И поехали! Запускаем через Gunicorn, чтоб не сдохло от первого запроса
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "my_project.wsgi:application"]

2. Автоматизация (CI/CD)

А теперь, чтобы не бегать каждый раз на сервер и не орать «docker-compose up -d, блядь!», настраиваем автомат. На каждый пуш в основную ветку — пайплайн сам всё сделает: соберёт, протестирует, зальёт и перезапустит. Красота, ёпта!

Вот пример .github/workflows/deploy.yml, смотри:

name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: your-repo/my-app:latest

      - name: Deploy on server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            docker pull your-repo/my-app:latest
            docker-compose up -d --force-recreate

3. Серверная инфраструктура

Ну а на сервере у нас, понятное дело, не голый докер стоит.

  • Reverse Proxy: Nginx спереди. Он запросы принимает, SSL-сертификаты обрабатывает, статику раздаёт — в общем, тяжёлую работу делает.
  • Оркестрация: Для простоты — Docker Compose. А если приложение раздулось до овердохуища сервисов, то тут уже Kubernetes в дело идёт, со всеми его подами и деплойментами, блядь.
  • Мониторинг: Ну и конечно, Prometheus + Grafana. Чтобы не гадать, почему всё легло, а видеть красивые графики, как всё падает. Шучу. Чтобы вовремя заметить, что память кончается или процессор грузится, как проклятый.

Вот так вот, нехитро, но работает. Главное — начать, а там уже и сам втянешься, как Герасим в историю с Муму, только с менее трагичным концом, надеюсь.

© ХакСобесов, 2026
support@hacksobesov.com