Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Замечание
Сведения о ASP.NET в .NET Framework см. в разделе "Настройка приложения ASP.NET для службы приложений Azure". Если приложение ASP.NET Core выполняется в пользовательском контейнере Windows или Linux, см. статью "Настройка пользовательского контейнера для службы приложений Azure".
Приложения ASP.NET Core должны быть опубликованы в Azure App Service в виде скомпилированных бинарных файлов. Средство публикации Visual Studio создает решение, а затем развертывает скомпилированные двоичные файлы напрямую. Модуль развертывания Службы приложений развертывает репозиторий кода сначала, а затем компилирует двоичные файлы.
В этом руководстве содержатся основные понятия и инструкции для разработчиков ASP.NET Core. Если эта статья впервые использует службу приложений Azure, сначала следуйте инструкциям по развертыванию веб-приложения ASP.NETи развертыванию приложения ASP.NET Core и Базы данных SQL Azure в Службе приложений Azure.
Показать поддерживаемые версии среды выполнения .NET Core
В App Service в Windows экземпляры уже установлены все поддерживаемые версии .NET Core. Чтобы просмотреть доступные для вас версии среды выполнения и пакета SDK для .NET Core, перейдите на сайт Kudu.
Перейдите к вашему приложению на портале Azure и выберите Средства разработки>Дополнительные средства. Нажмите кнопку "Перейти". В Kudu выберите консоль отладки для CMD или PowerShell.
Выполните следующую команду в консоли на основе браузера:
dotnet --info
Показать версию .NET Core
Чтобы отобразить текущую версию .NET Core, выполните следующую команду в Azure Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Чтобы отобразить все поддерживаемые версии .NET Core, выполните следующую команду в Cloud Shell:
az webapp list-runtimes --os linux | grep DOTNET
Установка версии .NET Core
Установите целевую платформу в файл проекта для вашего проекта ASP.NET Core. Дополнительные сведения см. в разделе "Выбор используемой версии .NET Core".
Чтобы задать версию .NET Core 8.0, выполните следующую команду в Cloud Shell:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
Что происходит с устаревшими средами выполнения в сервисе приложений?
Устаревшие среды выполнения не рекомендуется поддерживать организацию или имеют значительные уязвимости. Соответственно, они удаляются из страниц создания и настройки на портале. Если устаревшая среда выполнения скрыта на портале, любое приложение, которое по-прежнему используется этой средой выполнения, продолжает выполняться.
Если вы хотите создать приложение с устаревшей версией среды выполнения, которая больше не отображается на портале, используйте Azure CLI, шаблон ARM или Bicep. Эти варианты развертывания позволяют создавать устаревшие среды выполнения, удаленные с портала, но по-прежнему поддерживаются.
Если среда выполнения полностью удалена из платформы службы приложений, владелец подписки Azure получает уведомление по электронной почте перед удалением.
Настройка автоматизации сборки
При развертывании приложения с помощью пакетов Git или ZIP с включенной автоматизацией сборки служба приложений следует следующей последовательности:
- Выполнить пользовательский скрипт, если это указано
PRE_BUILD_SCRIPT_PATH. - Чтобы восстановить зависимости NuGet, выполните команду
dotnet restore. - Чтобы создать двоичный файл для рабочей среды, выполните команду
dotnet publish. - Выполнить пользовательский скрипт, если это указано
POST_BUILD_SCRIPT_PATH.
PRE_BUILD_COMMAND и POST_BUILD_COMMAND — это системные переменные, которые по умолчанию пусты. Для выполнения команд предварительной сборки определите PRE_BUILD_COMMAND. Чтобы выполнить команды после сборки, определите POST_BUILD_COMMAND.
В следующем примере указываются две переменные в ряд команд, разделенных запятыми.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"
Другие переменные среды, которые можно использовать для настройки автоматизации сборки, см. в разделе "Конфигурация Oryx".
Дополнительные сведения о том, как служба приложений выполняет и создает ASP.NET приложения Core в Linux, см. в документации по Oryx: обнаружение и сборка приложений .NET Core.
Доступ к переменным среды
В службе приложений можно задать параметры приложения за пределами кода приложения. Затем вы можете получить доступ к ним в любом классе с помощью стандартного шаблона внедрения зависимостей core ASP.NET:
using Microsoft.Extensions.Configuration;
namespace SomeNamespace
{
public class SomeClass
{
private IConfiguration _configuration;
public SomeClass(IConfiguration configuration)
{
_configuration = configuration;
}
public SomeMethod()
{
// retrieve nested App Service app setting
var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
// retrieve App Service connection string
var myConnString = _configuration.GetConnectionString("MyDbConnection");
}
}
}
Если вы настраиваете параметр приложения с тем же именем в Службе приложений и в appsettings.json, значение службы приложений имеет приоритет над значением appsettings.json . Используя локальное appsettings.json значение, можно локально отлаживать приложение. Используя значение службы приложений, вы можете запустить приложение в рабочей среде с параметрами рабочей среды. Строки подключения работают так же. Используя этот метод, вы можете хранить секреты приложения за пределами репозитория кода и получать доступ к соответствующим значениям, не изменяя код.
Замечание
Кроме того, можно рассмотреть более безопасные параметры подключения, которые не требуют секретов подключения. Дополнительные сведения см. в статье "Безопасное подключение к службам и базам данных Azure из приложения Azure App Service".
Доступ к данным иерархической конфигурации в appsettings.json осуществляется с использованием __ разделителя двойного подчеркивания, стандартного для Linux на .NET Core. Чтобы переопределить определенное иерархическое значение конфигурации в App Service, задайте имя параметра приложения с тем же разделённым форматом в ключе. В Cloud Shell можно выполнить следующий пример:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
Данные иерархической конфигурации в appsettings.json доступны с использованием разделителя :, стандартного для .NET Core. Чтобы переопределить определенное иерархическое значение конфигурации в App Service, задайте имя параметра приложения с тем же разделённым форматом в ключе. Вы можете выполнить следующий пример в Azure Cloud Shell:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"
Развертывать многопроектные решения
Если решение Visual Studio включает несколько проектов, процесс публикации Visual Studio выбирает проект для развертывания. При развертывании на механизм развертывания службы приложений, например с помощью Git или через ZIP-развертывание с включенной автоматизацией сборки, механизм развертывания службы приложений выбирает первый веб-сайт или проект веб-приложения, который он находит, в качестве приложения службы приложений. Вы можете указать, какой проект должен использовать App Service, задав настройку приложения PROJECT. Например, выполните следующую команду в Cloud Shell:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
Доступ к диагностическим журналам
ASP.NET Core предлагает встроенный поставщик ведения журнала для службы приложений. В файле проекта program.cs добавьте поставщика в приложение с помощью ConfigureLogging метода расширения, как показано в следующем примере:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.AddAzureWebAppDiagnostics();
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
Затем можно настроить и создать журналы с помощью стандартного шаблона .NET Core. Смотрите ведение журналов в .NET Core и ASP.NET Core.
Чтобы получить доступ к журналам консоли, созданным из кода приложения в Службе Приложений, включите ведение журнала диагностики, выполнив следующую команду в Cloud Shell:
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
Возможные значения для --level: Error, Warning, Info и Verbose. Каждый последующий уровень включает предыдущий уровень. Например, Error включает только сообщения об ошибках.
Verbose включает все сообщения.
После включения ведения журнала диагностики выполните следующую команду, чтобы просмотреть поток журналов:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Если журналы консоли не отображаются немедленно, повторите попытку через 30 секунд.
Чтобы прекратить потоковую передачу журнала в любое время, нажмите Ctrl+C.
Дополнительные сведения об устранении неполадок приложений ASP.NET Core в Службе приложений см. в статье Устранение неполадок ASP.NET Core в Службе приложений Azure и IIS.
Доступ к подробной странице исключений
Когда приложение ASP.NET Core создает исключение в отладчике Visual Studio, браузер отображает подробную страницу исключений. В службе приложений универсальное сообщение "HTTP 500" или "Ошибка при обработке запроса" заменяет страницу. Чтобы отобразить подробную страницу исключений в Службе приложений, добавьте ASPNETCORE_ENVIRONMENT параметр приложения в приложение, выполнив следующую команду в Cloud Shell.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"
Обнаружить HTTPS-сеанс
В службе приложений завершение TLS происходит в сетевых подсистемах балансировки нагрузки. Все HTTPS-запросы обращаются к приложению как незашифрованные HTTP-запросы. Если логика вашего приложения должна знать, зашифрованы ли запросы пользователей, настройте миддлвар перенаправленных заголовков в Startup.cs.
- Настройте промежуточное ПО с
ForwardedHeadersOptionsдля пересылки заголовковX-Forwarded-ForиX-Forwarded-ProtoвStartup.ConfigureServices. - Добавьте диапазоны частных IP-адресов в известные сети, чтобы серверное ПО могло доверять балансировщику нагрузки службы приложений.
- Вызовите метод
UseForwardedHeadersвStartup.Configureперед вызовом другого промежуточного ПО.
При сборке трех элементов код выглядит следующим образом:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
// These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseForwardedHeaders();
...
app.UseMvc();
}
Для получения дополнительной информации см. Настройка ASP.NET Core для работы с прокси-серверами и балансировщиками нагрузки.
Переписать или перенаправить URL
Чтобы перезаписать или перенаправить URL-адрес, используйте ПО промежуточного слоя перезаписи URL-адресов в ASP.NET Core.
Открыть SSH-сессию в браузере
Если вы хотите открыть прямой сеанс SSH с контейнером, приложение должно работать.
Используйте команду az webapp ssh .
Если вы не прошли проверку подлинности, необходимо выполнить проверку подлинности с помощью подписки Azure для подключения. При проверке подлинности отображается оболочка в браузере, где можно выполнять команды внутри контейнера.
Замечание
Все изменения, внесенные за пределами /home каталога, хранятся в самом контейнере и не сохраняются после перезапуска приложения.
Чтобы открыть удалённую SSH-сессию с вашей локальной машины, см. Открыть SSH-сессию из удалённой оболочки.
Игнорировать сообщение робота933456 в журналах
В журналах контейнеров может появиться следующее сообщение:
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
Вы можете спокойно игнорировать это сообщение.
/robots933456.txt является фиктивным путем URL, который служба приложений использует для проверки, способен ли контейнер обрабатывать запросы. Ответ 404 указывает, что путь не существует, и он сигнализирует службе приложений о том, что контейнер работоспособен и готов реагировать на запросы.