Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье объясняется, как взять проект 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, как указано в следующем разделе.
Среда разработки может быть:
- Локальная рабочая станция с Visual Studio Code или PyCharm
- Пространства кода (среда разработки , размещенная в облаке)
- Контейнеры разработки Visual Studio (контейнер в качестве среды разработки)
Параметры контейнера развертывания в Azure
Приложения контейнеров Python поддерживаются в следующих службах.
Услуга | Описание |
---|---|
веб-приложение для контейнеров | Служба приложений Azure — это полностью управляемая платформа размещения для контейнерных веб-приложений, включая веб-сайты и веб-API. Он поддерживает масштабируемые развертывания и легко интегрируется с рабочими процессами CI/CD с помощью Docker Hub, реестра контейнеров Azure и GitHub. Эта служба идеально подходит для разработчиков, которые хотят простого и эффективного пути к развертыванию контейнерных приложений, а также преимущества всех возможностей платформы службы приложений Azure. Упаковав приложение и все его зависимости в один развернутый контейнер, вы получаете переносимость и простоту управления, не требуя управления инфраструктурой.
Пример. Развертывание веб-приложения Flask или FastPI в Службе приложений Azure. |
Приложения контейнеров Azure (ACA) | Приложения контейнеров Azure (ACA) — это полностью управляемая служба контейнеров с поддержкой Kubernetes и технологий с открытым кодом, таких как Dapr, KEDA и envoy. Его дизайн включает в себя отраслевые рекомендации и оптимизирован для выполнения контейнеров общего назначения. ACA абстрагирует сложность управления инфраструктурой Kubernetes— прямой доступ к API Kubernetes не требуется или не поддерживается. Вместо этого он предлагает конструкции приложений более высокого уровня, такие как редакции, масштабирование, сертификаты и среды для упрощения рабочих процессов разработки и развертывания. Эта служба идеально подходит для команд разработчиков, желающих создавать и развертывать контейнерные микрослужбы с минимальными эксплуатационными затратами, что позволяет им сосредоточиться на логике приложений вместо управления инфраструктурой. Пример. Развертывание веб-приложения Flask или FastPI в приложениях контейнеров Azure. |
экземпляры контейнеров Azure (ACI) | Экземпляры контейнеров Azure (ACI) — это бессерверное предложение, которое предоставляет один модуль pod Hyper-V изолированных контейнеров по запросу. Выставление счетов основано на фактическом использовании ресурсов, а не на предварительно выделенной инфраструктуре, что хорошо подходит для кратковременных или быстро изменяющихся рабочих нагрузок. В отличие от других служб контейнеров, ACI не включает встроенную поддержку таких концепций, как масштабирование, балансировка нагрузки или сертификаты TLS. Вместо этого он обычно функционирует как базовый строительный блок контейнера, часто интегрированный со службами Azure, такими как Служба Kubernetes Azure (AKS) для оркестрации. ACI является легким вариантом, если не нужны более высокий уровень абстракции и функции Azure Container Apps Пример: Создание образа контейнера для развертывания в экземпляры контейнеров Azure. (Учебник не относится к Python, но эти понятия применяются ко всем языкам.) |
Служба Azure Kubernetes (AKS) | Служба Azure Kubernetes (AKS) — это полностью управляемый параметр Kubernetes в Azure, который обеспечивает полный контроль над средой Kubernetes. Он поддерживает прямой доступ к API Kubernetes и может выполнять любую стандартную рабочую нагрузку Kubernetes. Весь кластер размещается в вашей подписке, включая конфигурации и операции кластера, находящиеся в пределах вашего контроля и ответственности. ACI идеально подходит для команд, ищущих полностью управляемое решение контейнера, а AKS обеспечивает полный контроль над кластером Kubernetes, требуя управления конфигурациями, сетями, масштабированием и операциями. Azure обрабатывает уровень управления и подготовку инфраструктуры, но повседневные операции и безопасность кластера находятся под контролем вашей команды. Эта служба идеально подходит для команд, которые хотят гибкости и мощности Kubernetes с дополнительным преимуществом управляемой инфраструктуры Azure, сохраняя полное владение средой кластера.
Пример. Развертывание кластера службы Azure Kubernetes с помощью Azure CLI. |
Функции Azure | Azure Функции предоставляют платформу бессерверных функций как услуги (FaaS), основанную на событиях, которая позволяет запускать небольшие фрагменты кода (функции) в ответ на события без необходимости управления инфраструктурой. Функции Azure используют множество характеристик с приложениями контейнеров Azure для масштабирования и интеграции с событиями, но оптимизированы для краткосрочных функций, развернутых как код или контейнеры. al для команд, желающих активировать выполнение функций на событиях; например, для привязки к другим источникам данных. Как и в приложениях контейнеров 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 поддерживает шаблоны исключений, аналогичные файлам gitignore . Дополнительные сведения см. в файле dockerignore. Исключение файлов помогает повысить производительность сборки изображений, но также следует использовать для предотвращения добавления конфиденциальной информации в образ, где его можно проверить. Например, dockerignore должен содержать строки, чтобы игнорировать .env и .venv (виртуальные среды). |
Параметры контейнера для веб-платформ
Веб-платформы обычно привязываются к портам по умолчанию (например, 5000 для Flask, 8000 для FastAPI). При развертывании контейнеров в службах Azure, таких как Azure Container Instances, Azure Kubernetes Service (AKS) или App Service для контейнеров, важно эксплицитно указать и настроить порт прослушивания контейнера, чтобы обеспечить правильную маршрутизацию входящего трафика. Настройка правильного порта гарантирует, что инфраструктура Azure может направлять запросы к правильной конечной точке в контейнере.
Веб-платформа | Порт |
---|---|
Django | 8 000 |
Фляга | 5000 или 5002 |
FastAPI (uvicorn) | 8000 или 80 |
В следующей таблице показано, как задать порт для различных решений контейнеров Azure.
Решение контейнера Azure | Настройка порта веб-приложения |
---|---|
Веб-приложение для контейнеров | По умолчанию служба приложений предполагает, что пользовательский контейнер прослушивается через порт 80 или порт 8080. Если контейнер прослушивает другой порт, настройте соответствующим образом параметр WEBSITES_PORT приложения в приложении Службы приложений. Дополнительные сведения см. в статье "Настройка пользовательского контейнера для службы приложений Azure". |
Приложения контейнеров Azure | Приложения контейнеров Azure позволяют предоставлять приложение-контейнер в общедоступном интернете, в виртуальной сети или другим приложениям-контейнерам в той же среде, включив входящий трафик. Настройте вход узла targetPort на порт, к которому контейнер ожидает входящие запросы. Входная точка приложения всегда открыта на порту 443. Дополнительные сведения см. в разделе "Настройка HTTPS или TCP-входа" в Azure Container Apps. |
Экземпляры контейнеров Azure, Azure Kubernetes | Вы задаёте порт, на котором ваше приложение прослушивает, при создании контейнера или пода. Образ контейнера должен содержать веб-платформу, сервер приложений (например, gunicorn, uvicorn), а также веб-сервер (например, nginx). В более сложных сценариях можно разделить обязанности между двумя контейнерами— один для сервера приложений и другой для веб-сервера. В этом случае контейнер веб-сервера обычно предоставляет порты 80 или 443 для внешнего трафика. |
Python Dockerfile
Dockerfile — это текстовый файл, содержащий инструкции по созданию образа Docker для приложения Python. Первая инструкция обычно указывает базовый образ для начала. Последующие инструкции затем подробно описывают такие действия, как установка необходимого программного обеспечения, копирование файлов приложений и настройка среды для создания запускаемого образа. В следующей таблице приведены примеры, характерные для Python, для часто используемых инструкций Dockerfile.
Инструкция | Цель | Пример |
---|---|---|
ОТ | Задает базовый образ для последующих инструкций. | FROM python:3.8-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.8-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 в рабочий процесс. С помощью расширений или подключаемых модулей эти среды разработки упрощают создание образов Docker, выполнение контейнеров и развертывание в сервисах Azure, таких как App Service или Container Instances. Ниже приведены некоторые действия, которые можно сделать с помощью 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. |
![]() ![]() |
Шаг 2. Используйте CTRL + SHIFT + X для открытия расширений, поиска расширения Docker и установки расширения. Вы также можете выбрать значок расширений на панели расширений VS Code. |
![]() |
Шаг 3: Выберите значок Docker на панели расширений, разверните образы и щелкните правой кнопкой мыши на образе Docker, чтобы запустить его как контейнер. |
![]() |
Шаг 4: Следите за выводом команды docker run в окне терминала. |
![]() |
Azure CLI и Интерфейс командной строки Docker
Вы также можете работать с образами и контейнерами Python Docker с помощью Azure CLI и Docker CLI. В VS Code и PyCharm есть терминалы для запуска этих CLI.
Используйте интерфейс командной строки, если требуется более подробный контроль над аргументами сборки и выполнения, а также для автоматизации. Например, следующая команда показывает, как использовать Azure CLI az acr build , чтобы указать имя образа Docker.
az acr build --registry <registry-name> \
--resource-group <resource-group> \
--target 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. Дополнительные сведения см. в разделе "Виртуальные среды и контейнеры " в этой статье.
Переменные среды можно передать контейнерам несколькими способами:
- Определяется в Dockerfile в виде инструкций ENV .
- Передаются как
--build-arg
аргументы с помощью команды Docker build. - Передан в виде
--secret
аргументов с помощью команды сборки Docker и бэкенда BuildKit. - Переданы как
--env
или--env-file
аргументы с помощью команды Docker run.
Первые два варианта имеют тот же недостаток, что и в env-файлах , а именно, что вы жестко закодировали потенциально конфиденциальную информацию в образ Docker. Вы можете просмотреть образ Docker и увидеть переменные среды, например, с помощью команды docker image inspect.
Третий вариант с 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 build, docker run) в фоновом режиме.
Наконец, указание переменных среды при развертывании контейнера в 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.