Общие сведения о приложениях контейнеров Python в Azure

В этой статье объясняется, как взять проект Python (например, веб-приложение) и развернуть его как контейнер Docker в Azure. Он охватывает общий рабочий процесс контейнеризации, варианты развертывания Azure для контейнеров и конфигурации контейнеров для Python в Azure. Создание и развертывание контейнеров Docker в Azure следует стандартному процессу на разных языках с конфигурациями для Python в Dockerfile, requirements.txtи параметрами для веб-платформ, таких как Django, Flask и FastAPI.

Сценарии рабочего процесса контейнера

При разработке контейнеров Python в следующей таблице описаны некоторые типичные сценарии перехода от кода к контейнеру.

Сценарий Описание Рабочий процесс
Разработка Создайте образы Docker Python локально в среде разработки. Код. Клонирование кода приложения локально с помощью Git (с установленным Docker).

Сборка: использование Интерфейса командной строки Docker, VS Code (с расширениями), PyCharm (с подключаемым модулем Docker). Описано в разделе "Работа с образами и контейнерами Python Docker".

Тест. Запуск и проверка контейнера локально.

Отправка образа в реестр контейнеров, например Реестр контейнеров Azure, Docker Hub или частный реестр.

Развертывание: развертывание контейнера из реестра в службе Azure.
Гибрид Создайте образы Docker в Azure, но инициируйте процесс из локальной среды. Код: клонирование кода локально (не требуется для установки Docker).

Сборка. Чтобы активировать сборки в Azure, используйте VS Code (с удаленными расширениями) или Azure CLI.

Отправка: отправка созданного образа в реестр контейнеров Azure.

Развертывание: развертывание контейнера из реестра в службе Azure.
Лазурный Используйте Azure Cloud Shell для создания и развертывания контейнеров полностью в облаке. Код. Клонирование репозитория GitHub в Azure Cloud Shell.

Сборка: используйте Azure CLI или Docker CLI в Cloud Shell.

Отправка образа в реестр, например Реестр контейнеров Azure, Docker Hub или частный реестр.

Развертывание: развертывание контейнера из реестра в службе Azure.

Конечной целью этих рабочих процессов является контейнер, работающий в одном из Azure ресурсов, поддерживающих контейнеры Docker, как указано в следующем разделе.

Среда разработки может быть:

Параметры контейнера развертывания в Azure

Приложения контейнеров Python поддерживаются в следующих службах.

Услуга Описание
веб-приложение для контейнеров Служба приложений Azure — это полностью управляемая платформа размещения для контейнерных веб-приложений, включая веб-сайты и веб-API. Он поддерживает масштабируемые развертывания и легко интегрируется с рабочими процессами CI/CD с помощью Docker Hub, реестра контейнеров Azure и GitHub. Эта служба идеально подходит для разработчиков, которые хотят простого и эффективного пути к развертыванию контейнерных приложений, а также преимущества всех возможностей платформы службы приложений Azure. Упаковав приложение и все его зависимости в один развернутый контейнер, вы получаете переносимость и простоту управления, не требуя управления инфраструктурой.

Пример: Развертывание веб-приложения Flask или FastAPI в Служба приложений Azure.
Приложения контейнеров Azure (ACA) Приложения контейнеров Azure (ACA) — это полностью управляемая служба контейнеров с поддержкой Kubernetes и технологий с открытым кодом, таких как Dapr, KEDA и envoy. Его дизайн включает в себя отраслевые рекомендации и оптимизирован для выполнения контейнеров общего назначения. ACA абстрагирует сложность управления инфраструктурой Kubernetes— прямой доступ к API Kubernetes не требуется или не поддерживается. Вместо этого он предлагает конструкции приложений более высокого уровня, такие как редакции, масштабирование, сертификаты и среды для упрощения рабочих процессов разработки и развертывания. Эта служба идеально подходит для команд разработчиков, желающих создавать и развертывать контейнерные микрослужбы с минимальными эксплуатационными затратами, позволяя им сосредоточиться на логике приложений вместо управления инфраструктурой.

Example: Deploy a Flask или Веб-приложение FastAPI на Контейнеры приложений Azure.
экземпляры контейнеров Azure (ACI) Экземпляры контейнеров Azure (ACI) — это бессерверное предложение, которое предоставляет один модуль pod Hyper-V изолированных контейнеров по запросу. Выставление счетов основано на фактическом использовании ресурсов, а не на предварительно выделенной инфраструктуре, что хорошо подходит для кратковременных или быстро изменяющихся рабочих нагрузок. В отличие от других служб контейнеров, ACI не включает встроенную поддержку таких концепций, как масштабирование, балансировка нагрузки или сертификаты TLS. Вместо этого он обычно функционирует как базовый строительный блок контейнера, часто интегрированный со службами Azure, такими как Служба Kubernetes Azure (AKS) для оркестрации. ACI является легким вариантом, если не нужны более высокий уровень абстракции и функции Контейнеры приложений Azure

Пример: Создание образа контейнера для развертывания в экземпляры контейнеров Azure. (Учебник не относится к Python, но эти понятия применяются ко всем языкам.)
Служба Azure Kubernetes (AKS) Служба Azure Kubernetes (AKS) — это полностью управляемый параметр Kubernetes в Azure, который обеспечивает полный контроль над средой Kubernetes. Он поддерживает прямой доступ к API Kubernetes и может выполнять любую стандартную рабочую нагрузку Kubernetes. Весь кластер размещается в вашей подписке, включая конфигурации и операции кластера, находящиеся в пределах вашего контроля и ответственности. AKS идеально подходит для команд, требующих точного контроля над масштабированием, сетью и развертыванием контейнерных приложений. Azure обрабатывает уровень управления и подготовку инфраструктуры, но повседневные операции и безопасность кластера находятся под контролем вашей команды. Эта служба идеально подходит для команд, которые хотят гибкости и мощности Kubernetes с дополнительным преимуществом управляемой инфраструктуры Azure, сохраняя полное владение средой кластера.

Пример. Развертывание кластера службы Azure Kubernetes с помощью Azure CLI.
Функции Azure Azure Функции предоставляют платформу бессерверных функций как услуги (FaaS), основанную на событиях, которая позволяет запускать небольшие фрагменты кода (функции) в ответ на события без необходимости управления инфраструктурой. Функции Azure используют множество характеристик с приложениями контейнеров Azure для масштабирования и интеграции с событиями, но оптимизированы для краткосрочных функций, развернутых как код или контейнеры. Идеально подходит для команд, желающих активировать выполнение функций на событиях; например, для привязки к другим источникам данных. Как и в приложениях контейнеров Azure, Функции Azure поддерживают автоматическое масштабирование и интеграцию с источниками событий (например, HTTP-запросы, очереди сообщений или обновления хранилища BLOB-объектов). Эта служба идеально подходит для команд, создающих упрощенные рабочие процессы, активированные событиями, такие как обработка отправки файлов или реагирование на изменения базы данных, на Python или других языках.

Пример. Создание функции в Linux с помощью пользовательского контейнера.

Более подробное сравнение этих служб см. в статье "Сравнение приложений контейнеров" с другими параметрами контейнера Azure.

Виртуальные среды и контейнеры

Виртуальные среды в Python изолируют зависимости проекта от установок Python на уровне системы, обеспечивая согласованность в средах разработки. Виртуальная среда включает в себя собственный изолированный интерпретатор Python, а также библиотеки и скрипты, необходимые для выполнения конкретного кода проекта в этой среде. Вы управляете зависимостями для проектов Python с помощью файла requirements.txt. Указав зависимости в файлеrequirements.txt , можно воспроизвести точную среду, необходимую для проекта. Этот подход упрощает более плавный переход на контейнерные развертывания, такие как Служба приложений Azure, где согласованность среды необходима для надежной производительности приложений.

Подсказка

В контейнерных проектах Python обычно не требуется виртуальные среды, так как контейнеры Docker предоставляют изолированные среды с собственными Python интерпретатором и зависимостями. Однако для локальной разработки или тестирования можно использовать виртуальные среды. Чтобы обеспечить производительность образов Docker, исключите виртуальные среды с помощью файла dockerignore , который предотвращает копирование ненужных файлов в образ.

Контейнеры Docker можно рассматривать как возможности, аналогичные Python виртуальным средам, но с более широкими преимуществами в воспроизводимости, изоляции и переносимости. В отличие от виртуальных сред, контейнеры Docker могут работать согласованно в разных операционных системах и средах, если среда выполнения контейнера доступна.

Контейнер Docker включает код проекта Python вместе с всем, что необходимо выполнить, например зависимости, параметры среды и системные библиотеки. Чтобы создать контейнер, сначала создайте образ Docker из кода проекта и конфигурации, а затем запустите контейнер, который является запускаемым экземпляром этого образа.

Для контейнеризации проектов Python ключевые файлы описаны в следующей таблице:

Файл проекта Описание
requirements.txt Этот файл содержит окончательный список зависимостей Python, необходимых для приложения. Docker использует этот список во время процесса сборки образа для установки всех обязательных пакетов. Этот процесс обеспечивает согласованность между средами разработки и развертывания.
Dockerfile Этот файл содержит инструкции по созданию образа Docker Python, включая выбор базового образа, установку зависимостей, копирование кода и команды запуска контейнера. Он определяет полную среду выполнения для приложения. Дополнительные сведения см. в разделе Инструкции Dockerfile для Python.
.dockerignore Этот файл указывает файлы и каталоги, которые следует исключить при копировании содержимого в образ Docker с помощью COPY команды в Dockerfile. В нем используются шаблоны, аналогичные .gitignore для определения исключений. Дополнительные сведения см. в файле dockerignore.

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

Параметры контейнера для веб-платформ

Веб-платформы обычно привязываются к портам по умолчанию, таким как 5000 для Flask и 8000 для FastAPI. При развертывании контейнеров в службах Azure, таких как Экземпляры контейнеров Azure, Azure Kubernetes Service (AKS) или Служба приложений для контейнеров, явным образом предоставляют и настраивают порт прослушивания контейнера, чтобы обеспечить правильную маршрутизацию входящего трафика. Настройка правильного порта гарантирует, что инфраструктура Azure может направлять запросы к правильной конечной точке в контейнере.

Веб-платформа Порт
Django 8 000
Flask 5000 или 5002
FastAPI (uvicorn) 8000 или 80

В следующей таблице показано, как задать порт для различных решений контейнеров Azure.

Решение контейнера Azure Настройка порта веб-приложения
Веб-приложение для контейнеров По умолчанию служба приложений предполагает, что пользовательский контейнер прослушивается через порт 80 или порт 8080. Если контейнер прослушивает другой порт, настройте соответствующим образом параметр WEBSITES_PORT приложения в приложении Службы приложений. Дополнительные сведения см. в статье "Настройка пользовательского контейнера для службы приложений Azure".
Приложения контейнеров Azure Приложения контейнеров Azure позволяют предоставлять приложение-контейнер в общедоступном интернете, в виртуальной сети или другим приложениям-контейнерам в той же среде, включив входящий трафик. Настройте вход узла targetPort на порт, к которому контейнер ожидает входящие запросы. Входная точка приложения всегда открыта на порту 443. Дополнительные сведения см. в разделе "Настройка HTTPS или TCP-входа" в Контейнеры приложений Azure.
Экземпляры контейнеров Azure, Azure Kubernetes Вы задаёте порт, на котором ваше приложение прослушивает, при создании контейнера или пода. Образ контейнера должен содержать веб-платформу, сервер приложений (например, gunicorn, uvicorn), а также веб-сервер (например, nginx). В более сложных сценариях можно разделить обязанности между двумя контейнерами — один для сервера приложений и другой для веб-сервера. В этом случае контейнер веб-сервера обычно предоставляет порты 80 или 443 для внешнего трафика.

Python Dockerfile

Dockerfile — это текстовый файл, содержащий инструкции по созданию образа Docker для приложения Python. Первая инструкция обычно указывает базовый образ для начала. Последующие инструкции описывают действия, такие как установка необходимого программного обеспечения, копирование файлов приложений и настройка среды для создания запускаемого образа. В следующей таблице приведены примеры, характерные для Python, для часто используемых инструкций Dockerfile.

Инструкция Цель Пример
ОТ Задает базовый образ для последующих инструкций. FROM python:3.9-slim
РАСКРЫТЬ Сообщает Docker, что контейнер прослушивает указанный порт во время выполнения. EXPOSE 5000
КОПИРОВАТЬ Копирует файлы или каталоги из указанного источника и добавляет их в файловую систему контейнера по указанному пути назначения. COPY . /app
Запустить Выполняет команду внутри образа Docker. Например, подключение зависимостей. Команда выполняется сразу во время сборки. RUN python -m pip install -r requirements.txt
CMD Эта команда предоставляет значение по умолчанию для выполнения контейнера. Существует только одна инструкция CMD. CMD ["gunicorn", "--bind", "0.0.0.0:5000", "wsgi:app"]

Команда сборки Docker создаёт образы Docker из Dockerfile и контекста. Контекст сборки — это набор файлов, расположенных по указанному пути или URL-адресу. Как правило, вы создаете образ из корневого каталога проекта Python, а путь к команде сборки — ".", как показано в следующем примере.

docker build --rm --pull  --file "Dockerfile"  --tag "mywebapp:latest"  .

Процесс сборки может ссылаться на любой из файлов в контексте. Например, сборка может использовать инструкцию COPY для ссылки на файл в контексте. Ниже приведен пример dockerfile для проекта Python с помощью платформы Flask :

FROM python:3.13-slim

EXPOSE 5000

# Keeps Python from generating .pyc files in the container.
ENV PYTHONDONTWRITEBYTECODE=1

# Turns off buffering for easier container logging
ENV PYTHONUNBUFFERED=1

# Install pip requirements.
COPY requirements.txt .
RUN python -m pip install -r requirements.txt

WORKDIR /app
COPY . /app

# Creates a non-root user with an explicit UID and adds permission to access the /app folder.
RUN adduser -u 5678 --disabled-password --gecos "" appuser && chown -R appuser /app
USER appuser

# Provides defaults for an executing container; can be overridden with Docker CLI.
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "wsgi:app"]

Можно создать Dockerfile вручную или создать его автоматически с помощью VS Code и расширения Docker. Дополнительные сведения см. в разделе "Создание файлов Docker".

Команда сборки Docker входит в интерфейс командной строки Docker. При использовании таких сред разработки, как VS Code или PyCharm, команды пользовательского интерфейса для работы с образами Docker выполняют команду сборки и автоматизируют задание параметров.

Работа с образами и контейнерами Python Docker

VS Code и PyCharm

Интегрированные среды разработки (IDEs), такие как Visual Studio Code (VS Code) и PyCharm упрощают разработку контейнеров Python, интегрируя задачи Docker в рабочий процесс. С помощью расширений или плагинов эти IDE упрощают создание образов Docker, запуск контейнеров и развертывание в службах Azure, таких как Azure App Service или Azure Экземпляры контейнеров. Ниже приведены некоторые действия, которые можно сделать с помощью VS Code и PyCharm.

  • Скачайте и создайте образы Docker.

    • Создайте образы в среде разработки.
    • Создание образов Docker в Azure без установки Docker в среде разработки. (Для PyCharm используйте Azure CLI для создания образов в Azure.)

  • Создайте и запустите контейнеры Docker из существующего образа, извлеченного образа или непосредственно из Dockerfile.

  • Запуск многоконтайнерных приложений с помощью Docker Compose.

  • Подключитесь к реестрам контейнеров, таким как Docker Hub, GitLab, JetBrains Space, Docker V2 и другие локальные реестры Docker.

  • (только VS Code) Добавьте файлы Dockerfile и Docker Compose, адаптированные для проекта Python.

Чтобы настроить VS Code и PyCharm для запуска контейнеров Docker в среде разработки, выполните следующие действия.

Если вы еще не сделали этого, установите средства Azure для VS Code.

Инструкции Снимок экрана
Шаг 1. Используйте SHIFT + ALT + A , чтобы открыть расширение Azure и подтвердить подключение к Azure.

Вы также можете выбрать значок Azure на панели расширений VS Code.

Если вы не вошли, выберите вход в Azure и следуйте инструкциям.

Если у вас возникли проблемы с доступом к подписке Azure, это может быть связано с тем, что вы находитесь за прокси-сервером. Сведения об устранении проблем с подключением см. в разделе "Сетевые подключения" в Visual Studio Code.		 Снимок экрана, на котором показано, как средства Azure выглядят после входа. Снимок экрана, на котором показано, как средства Azure выглядят, если вы не вошли в систему.
Шаг 2. Используйте CTRL + SHIFT + X для открытия расширений, поиска расширения Docker и установки расширения.

Вы также можете выбрать значок расширений на панели расширений VS Code.		 Снимок экрана: добавление расширения Docker в VS Code.
Шаг 3. Выберите значок Docker на панели расширения, разверните изображения и щелкните правой кнопкой мыши образ Docker, чтобы запустить его в качестве контейнера. Снимок экрана: использование расширения Docker в VS Code для запуска контейнера из образа Docker.
Шаг 4: Следите за выводом команды docker run в окне терминала. Снимок экрана: пример запуска контейнера в VS Code.

Azure CLI и Интерфейс командной строки Docker

Вы также можете работать с образами и контейнерами Docker Python с помощью Azure CLI и Docker CLI. В VS Code и PyCharm есть терминалы для запуска этих CLI.

Используйте интерфейс командной строки, если требуется более подробный контроль над аргументами сборки и выполнения, а также для автоматизации. Например, следующая команда показывает, как использовать Azure CLI az acr build , чтобы указать имя образа Docker.

az acr build --registry <registry-name> \
  --resource-group <resource-group> \
  --image pythoncontainerwebapp:latest .

В другом примере рассмотрим следующую команду, в которой показано, как использовать команду запуска Интерфейса командной строки Docker. В примере показано, как запустить контейнер Docker, который взаимодействует с экземпляром MongoDB в среде разработки за пределами контейнера. Различные значения для выполнения команды проще автоматизировать при указании в командной строке.

docker run --rm -it \
  --publish <port>:<port> --publish 27017:27017 \
  --add-host mongoservice:<your-server-IP-address> \
  --env CONNECTION_STRING=mongodb://mongoservice:27017 \
  --env DB_NAME=<database-name> \
  --env COLLECTION_NAME=<collection-name> \
  containermongo:latest

Дополнительные сведения об этом сценарии см. в статье о сборке и тестировании контейнерного веб-приложения Python локально.

Переменные среды в контейнерах

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

Используйте пакеты, такие как python-dotenv, для считывания пар «ключ-значение» из файла .env и установки их в качестве переменных среды. Env-файл полезен при запуске в виртуальной среде, но не рекомендуется при работе с контейнерами. Не копируйте env-файл в образ Docker, особенно если он содержит конфиденциальную информацию и контейнер является общедоступным. Используйте файл dockerignore , чтобы исключить копирование файлов в образ Docker. Дополнительные сведения см. в разделе "Виртуальные среды и контейнеры " в этой статье.

Переменные среды можно передать контейнерам несколькими способами:

  1. Определите их в Dockerfile в виде инструкций ENV .
  2. Передайте их как --build-arg аргументы команды Docker build.
  3. Передайте их как аргументы --secret с помощью команды Docker build и бэкенда BuildKit.
  4. Передайте их в качестве аргументов --env или --env-file с помощью команды Docker run.

Первые два варианта имеют тот же недостаток, что и в env-файлах : вы жестко закодировали потенциально конфиденциальную информацию в образ Docker. Можно проверить образ Docker и просмотреть переменные среды, например с помощью проверки образа docker команды.

Третий вариант с BuildKit позволяет передавать секретные сведения для использования в Dockerfile для создания образов Docker безопасным способом, который в конечном итоге не хранится в окончательном образе.

Четвертый вариант передачи переменных среды с помощью команды запуска Docker означает, что образ Docker не содержит переменные. Однако переменные по-прежнему видны при проверке экземпляра контейнера (например, с помощью проверки контейнера Docker). Этот параметр может быть приемлемым при управлении доступом к экземпляру контейнера или в сценариях тестирования или разработки.

Ниже приведен пример передачи переменных среды с помощью команды выполнения интерфейса командной строки Docker и использования аргумента --env .

# PORT=8000 for Django and 5000 for Flask
export PORT=<port-number>

docker run --rm -it \
  --publish $PORT:$PORT \
  --env CONNECTION_STRING=<connection-info> \
  --env DB_NAME=<database-name> \
  <dockerimagename:tag>

В VS Code (расширение Docker) или PyCharm (подключаемый модуль Docker) инструменты пользовательского интерфейса упрощают управление образами и контейнерами Docker путем выполнения стандартных команд командной строки Docker (например, сборки docker и запуска Docker) в фоновом режиме.

Наконец, указание переменных среды при развертывании контейнера в Azure отличается от использования переменных среды в среде разработки. Рассмотрим пример.

  • Для веб-приложения для контейнеров вы настраиваете параметры приложения во время настройки службы приложений. Код приложения может получить доступ к этим параметрам в качестве переменных среды с помощью стандартного шаблона os.environ . При необходимости можно изменить значения после первоначального развертывания. Дополнительные сведения см. в разделе "Параметры приложения Access" в качестве переменных среды.

  • Для приложений контейнеров Azure вы настраиваете переменные среды во время начальной настройки приложения-контейнера. Последующее изменение переменных среды создает редакцию контейнера. Кроме того, приложения контейнеров Azure позволяют определять секреты на уровне приложения, а затем ссылаться на них в переменных среды. Дополнительные сведения см. в статье "Управление секретами в приложениях контейнеров Azure".

В качестве другого варианта можно использовать соединитель служб для подключения вычислительных служб Azure к другим службам резервного копирования. Эта служба настраивает параметры сети и сведения о подключении (например, создание переменных среды) между вычислительными службами и целевыми службами резервного копирования в плоскости управления.

Просмотр журналов контейнеров

Просмотрите журналы экземпляров контейнера, чтобы увидеть диагностические сообщения из кода и для устранения неполадок в коде контейнера. Ниже приведено несколько способов просмотра журналов при запуске контейнера в среде разработки:

  • Запуская контейнер с помощью VS Code или PyCharm, как показано в разделе VS Code и PyCharm, вы можете увидеть журналы в окнах терминала, которые открываются при выполнении команды docker run.

  • Если вы используете команду запуска Интерфейса командной строки Docker с интерактивным флагом -it, вы увидите выходные данные после команды.

  • В Docker Desktop можно также просматривать журналы для запущенного контейнера.

При развертывании контейнера в Azure также есть доступ к журналам контейнеров. Ниже приведены несколько служб Azure и как получить доступ к журналам контейнеров на портале Azure.

Служба Azure Доступ к журналам на портале Azure
Веб-приложение для контейнеров Перейдите к ресурсу диагностики и решения проблем , чтобы просмотреть журналы. Диагностика — это интеллектуальный и интерактивный интерфейс, помогающий устранять неполадки с приложением без требуемой конфигурации. Для просмотра журналов в режиме реального времени перейдите в мониторинг - поток журналов. Дополнительные сведения о запросах и конфигурации журналов см. в разделе "Мониторинг" других ресурсов.
Приложения контейнеров Azure Перейдите к ресурсу управления средой Диагностика и устранение проблем для устранения проблем с со средой. Чаще всего вы хотите просмотреть логи контейнеров. В ресурсе контейнера, в разделе Приложение - Управление версиями, выберите версию, и там можно просмотреть журналы системы и консоли. Дополнительные сведения о запросах и конфигурации журналов см. в разделе "Мониторинг".
Инстанции контейнеров Azure Перейдите к ресурсу Контейнеры и выберите Журналы.

Для этих служб приведены команды Azure CLI для доступа к журналам.

Служба Azure Команда Azure CLI для доступа к журналам
Веб-приложение для контейнеров az webapp log
Приложения контейнеров Azure az containerapps logs
Инстанции контейнеров Azure az container logs

Также поддерживается просмотр журналов в VS Code. Необходимо установить средства Azure для VS Code . Ниже приведен пример просмотра журналов веб-приложений для контейнеров (службы приложений) в VS Code.

Снимок экрана: просмотр журналов в VS Code для веб-приложений для контейнеров.

Дальнейшие шаги

  • Last updated on