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

Чтобы развернуть приложение .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-интерфейс, который можно использовать для обеспечения доступа к вашим приложениям трафика извне контейнера. Входящий трафик приложений контейнеров находится между приложением и конечным пользователем. Поскольку входящий трафик действует как посредник, всё, что видит конечный пользователь, заканчивается на уровне входа, а всё, что видит ваше приложение, начинается с уровня входа.

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

Если приложению требуются метаданные об исходном запросе, оно может использовать заголовки 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 Container Apps используйте переменные среды для хранения сведений о конфигурации вместо appsettings.json. Эта практика позволяет настроить приложение различными способами в разных средах. Кроме того, использование переменных среды упрощает управление значениями конфигурации без необходимости перестроить и повторно развернуть образ контейнера.

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

Манажируемая идентичность

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

Логирование

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

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

Проверки состояния здоровья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on