Если установить пакет dotnetcore3 SDK и создать проект dotnetcore / реагировать, он компилируется и работает нормально. Модификации для использования внешних поставщиков идентификационных данных просты и работают в соответствии с документацией. Вам нужно будет добавить пакеты для провайдеров, которых вы поддерживаете sh, например Microsoft.AspNetCore.Authentication.MicrosoftAccount.
. В этот момент вы можете попробовать dotnet publish, но результирующий пакет выдает следующую (усеченную) трассировку стека :
info: IdentityServer4.Startup[0]
Starting IdentityServer4 version 3.0.0.0
crit: Microsoft.AspNetCore.Hosting.Diagnostics[6]
Application startup exception
System.InvalidOperationException: Key type not specified.
at Microsoft.AspNetCore.ApiAuthorization.IdentityServer.ConfigureSigningCredentials.LoadKey()
at Microsoft.AspNetCore.ApiAuthorization.IdentityServer.ConfigureSigningCredentials.Configure(ApiAuthorizationOptions options)
Сервисный работник
Шаблон настроен с сервисным работником. Это очень неприятно при отладке нашей конфигурации, поэтому отключите ее, закомментировав registerServiceWorker(); в ClientApp/src/index.js, и если вы уже запустили приложение, вам понадобится грипп sh в вашем кеше, чтобы сместить его.
Сертификат
Требуется сертификат. Шаблон проекта использует OID C, реализованный с помощью IdentityServer4, и, следовательно, требует PFX. На Windows вы можете создать один из них, используя CertReq. Было бы плохой практикой безопасности добавлять это в проект, поэтому я поместил файл PFX в папку проекта. Регистрация в appSettings.json выглядит следующим образом:
"IdentityServer": {
"Key": {
"Type": "File",
"FilePath": "../cert-name.pfx",
"Password": "cert-password"
}
},
Secrets
dotnet add secret строго относится к режиму разработки. Ожидается, что мы вручную расшифруем все секреты переменных среды Azure и изменим программу, чтобы включить их в процесс загрузки конфигурации.
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.AddEnvironmentVariables();
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
Имена в секретах do tnet полны двоеточий. Вам также нужно будет избегать этих двоеточий в качестве двойных подчеркиваний для кросс-платформенной совместимости.
Поскольку dotnet add secret - не самый удобный инструмент, мне кажется, что может быть проще использовать среду переменные на всем протяжении.
Базовая версия безумия
Глупая попытка использовать LTS-версию (3.1).
При создании конвейера CI Classi c из портала Azure невозможно выбрать do tnet core 3.1, поскольку его нет в списке. Список содержит , содержит LTS и Latest, но оба этих выбора приводят к ошибкам проверки при попытке завершить развертывание. Выбор 3.0 позволяет завершить работу, что приводит к запуску развертывания, но, хотя ему удается опубликовать sh в веб-приложении на Azure, веб-приложение настроено на tnet core 3.0, и, поскольку в проекте указано 3.1, оно выиграло не запускается.
Вы можете вручную изменить это значение в колонке Конфигурация веб-приложения на портале Azure, но при каждом развертывании оно будет повреждено. Изменение проекта для использования 3.0 и совместимых пакетов, похоже, работает.
Я неправильно использую инструменты или Azure CICD настроен действительно дерьмо?
npm
И теперь он запускается, но не может найти 'npm'. Установка npm с использованием s sh выглядит следующим образом (это уже root, поэтому sudo не задействован)
curl -sL https://deb.nodesource.com/setup_13.x | bash
apt-get install -y nodejs
, и это, похоже, работает, но не переживает перезапуск веб-приложения (предположительно он установлен за пределами /home)
Все работает без аутентификации
Если я разверну проект, созданный с помощью dotnet new react без квалификатора -au Individual, он будет работать отлично. Сайт загружается, веб-API вызываются, данные возвращаются и т. Д. c.
Какая разница? Есть пара.
- IdentityServer4
- SQLite
- Генерация базы данных SQLite
Порывшись в .csproj Нахожу это
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="3.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="3.0.0">
и это первое, что используется в ConfigureServices
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlite(Configuration.GetConnectionString("DefaultConnection")));
, но это не вызывает исключения. Это происходит позже, когда создается IdentityServer. Далее по трассировке стека мы находим следующее:
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
.MigrationsEndPointMiddleware.Invoke(HttpContext context)
, из которого я заключаю, что EF использует Node для выполнения миграции, по крайней мере, для SQLite.
Не думаю, что это поможет добавьте npm к package.json, потому что это просто связало бы его для доставки в браузер. Похоже, что npm требуется на сервере для процесса миграции.
Но Node и npm просто не являются частью основного стека веб-приложений do tnet.
Одно из предложений (через Reddit) - использовать веб-приложение стека Node и развернуть автономную сборку кода основного сервера do tnet. Это мой следующий порт захода. В духе решения одной проблемы за раз я сначала научусь делать самостоятельное развертывание сборки с минимальным проектом Core / React (без аутентификации).
Это почти работает. Используя S SH, я смог запустить приложение, и оно началось без каких-либо ошибок, но прослушивал порт 5000, а не 8080, где он и должен быть, если вы хотите, чтобы оно появлялось на порту 80 на интерфейсе publi c.
В стеке Node неудивительно, что сценарий запуска настроен на запуск приложения Node и прерывается до того, как он попадает в указанную вами команду запуска. Поскольку это скрипт запуска Node, он также не устанавливает ASPNETCORE_URLS=http://*:$PORT, который необходим для работы основного проекта на порте 8080.