Обзор .NET в приложениях контейнеров Azure

Статья
06/26/2024

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

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

В этой статье описаны основные понятия и проблемы, важные для вас при развертывании приложения .NET в приложениях контейнеров Azure.

Выберите тип ресурсов

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

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

Вариант использования	Тип ресурса
Веб-API ASP.NET Core, который обслуживает HTTP-запросы	Приложение
Консольное приложение .NET Core, обрабатывающее некоторые данные, затем завершает работу.	Работа
Непрерывно выполняющаяся фоновая служба, обрабатывающая сообщения из очереди	Приложение
Служба оптимизации изображений, которая выполняется только при сохранении больших образов в учетной записи хранения.	Работа
Приложение, использующее платформу, например Hangfire, Quartz.NET или пакет SDK веб-заданий Azure	Приложение

Контейнеризация и развертывание приложения .NET

Для обоих приложений или заданий необходимо создать образ контейнера для упаковки приложения .NET. Дополнительные сведения о создании образа контейнера см. в разделе Образы Docker для ASP.NET Core.

После настройки вы можете развернуть приложение в приложениях контейнеров Azure, следуя приведенным ниже руководствам.

Использование входящего трафика HTTP

Приложения контейнеров Azure включают встроенный входящий трафик HTTP, который позволяет предоставлять приложениям трафик, поступающий из-за пределов контейнера. Входящий трафик приложений контейнеров находится между приложением и конечным пользователем. Так как входящий трафик выступает в качестве посредника, то, что конечный пользователь видит входящего трафика, и все, что ваше приложение видит, начинается с входящего трафика.

Входящий трафик управляет завершением TLS и пользовательскими доменами, устраняя необходимость вручную настроить их в приложении. Через входящий трафик предоставляется порт 443 для трафика HTTPS и при необходимости порт 80 для HTTP-трафика. Входящий трафик пересылает запросы в приложение на целевом порту.

Если приложению требуются метаданные о исходном запросе, он может использовать заголовки X-пересылки.

Дополнительные сведения см. в статье "Входящий трафик HTTP" в приложениях контейнеров Azure.

Определение целевого порта

Для получения трафика входящий трафик настраивается на целевом порту, в котором приложение прослушивает трафик.

При запуске ASP.NET Core в контейнере приложение прослушивает порты, настроенные на образе контейнера. При использовании официальных образов ASP.NET Core приложение настроено для прослушивания HTTP на порту по умолчанию. Порт по умолчанию зависит от версии ASP.NET Core.

Параметры выполнения	Целевой порт
ASP.NET Core 7 и более ранних версий	`80`
ASP.NET Core 8 и более поздних версий	`8080`

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

Определение заголовков X-пересылки

Когда входящий трафик обрабатывает исходный HTTP-запрос, приложение видит входящий трафик как клиент. В некоторых ситуациях приложение должно знать IP-адрес исходного клиента или исходный протокол (HTTP или HTTPS). Доступ к данным протокола и IP можно получить через заголовок запросаX-Forwarded-*.

Для чтения исходных значений из этих заголовков можно получить доступ к объекту ForwardedHeaders .

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

Дополнительные сведения о работе с заголовками запросов см. в статье Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

Создание облачных приложений .NET

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

Конфигурация приложений

При развертывании приложения .NET в приложениях контейнеров Azure используйте переменные среды для хранения сведений о конфигурации вместо appsettings.json. Эта практика позволяет настроить приложение различными способами в разных средах. Кроме того, использование переменных среды упрощает управление значениями конфигурации без необходимости перестроить и повторно развернуть образ контейнера.

В azure Container Apps вы задаете переменные среды при определении контейнера приложения или задания. Храните конфиденциальные значения в секретах и ссылайте их в качестве переменных среды. Дополнительные сведения об управлении секретами см. в статье "Управление секретами" в приложениях контейнеров Azure.

Управляемое удостоверение

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

Ведение журнала

В облачной среде ведение журнала имеет решающее значение для мониторинга и устранения неполадок приложений. По умолчанию приложения контейнеров Azure используют Azure Log Analytics для сбора журналов из контейнеров. Вы можете настроить других поставщиков ведения журнала. Дополнительные сведения о ведении журнала приложений см. в разделе "Параметры хранения журналов и мониторинга" в приложениях контейнеров Azure.

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

Зонды работоспособности

Приложения контейнеров Azure включают встроенную поддержку проб работоспособности, которая позволяет отслеживать работоспособность приложений. Если проба определяет, что приложение находится в неработоспособном состоянии, контейнер автоматически перезапускается. Дополнительные сведения о пробах работоспособности см. в статье "Пробы работоспособности" в приложениях контейнеров Azure.

Чтобы реализовать пользовательскую логику для определения работоспособности приложения, можно настроить конечную точку проверки работоспособности. Дополнительные сведения о конечных точках проверки работоспособности см. в разделе "Проверки работоспособности" в ASP.NET Core.

Вопросы автомасштабирования

По умолчанию приложения контейнеров Azure автоматически масштабируют приложения ASP.NET Core на основе количества входящих HTTP-запросов. Вы также можете настроить пользовательские правила автомасштабирования на основе других метрик, таких как использование ЦП или памяти. Дополнительные сведения о масштабировании см. в статье "Настройка правил масштабирования" в приложениях контейнеров Azure.

В .NET 8.0.4 и более поздних версиях приложения ASP.NET Core, использующие защиту данных, автоматически настраиваются для обеспечения доступности защищенных данных для всех реплик по мере масштабирования приложения. Когда приложение начинает масштабироваться, диспетчер ключей обрабатывает ключи записи и совместного использования в нескольких редакциях. По мере развертывания приложения переменная autoConfigureDataProtection среды автоматически устанавливается true для включения этой функции. Дополнительные сведения об этой автоматической конфигурации см . в этом запросе на вытягивание GitHub.

Автоматическое масштабирование изменяет количество реплик приложения на основе заданных правил. По умолчанию контейнерные приложения случайным образом направляет входящий трафик в реплики приложения ASP.NET Core. Так как трафик может разделиться между разными репликами, приложение должно быть без отслеживания состояния, чтобы приложение не сталкивалось с проблемами, связанными с состоянием.

Такие функции, как защита от подделки, проверка подлинности, SignalR, Blazor Server и Razor Pages, зависят от защиты данных, требуют правильной настройки при масштабировании до нескольких реплик.

Настройка защиты данных

ASP.NET Core имеет специальные функции защиты и отмены защиты данных, таких как данные сеанса и маркеры защиты от подделки. По умолчанию ключи защиты данных хранятся в файловой системе, которая не подходит для облачной среды.

Если вы развертываете приложение .NET Aspire, защита данных автоматически настраивается для вас. Во всех других ситуациях необходимо вручную настроить защиту данных.

Настройка ASP.NET Core SignalR

ASP.NET Core SignalR требуется серверная планка для распространения сообщений на несколько реплик сервера. При развертывании приложения ASP.NET Core с помощью SignalR в приложениях контейнеров Azure необходимо настроить один из поддерживаемых серверных планировок, таких как Служба Azure SignalR или Redis. Дополнительные сведения о серверных планах см. в разделе ASP.NET Размещение и масштабирование Core SignalR.

Настройка сервера Blazor

ASP.NET приложения Core Blazor Server хранят состояние на сервере, что означает, что каждый клиент должен быть подключен к одной реплике сервера во время сеанса. При развертывании приложения Blazor Server в приложениях контейнеров Azure необходимо включить липкие сеансы, чтобы обеспечить маршрутизацию клиентов в ту же реплику. Дополнительные сведения см. в статье "Сходство сеансов" в приложениях контейнеров Azure.

Поделиться через