Руководство: Развертывание приложения ASP.NET Core и Azure SQL Database в Azure App Service

В этом руководстве вы узнаете, как развернуть приложение на основе данных ASP.NET Core для Azure App Service и подключиться к Azure SQL Database. Вы также развернете кэш Redis, чтобы включить код кэширования в приложении. Azure App Service — это высокомасштабируемая, самовосстанавливающаяся веб-хостинговая служба, которая может легко развертывать приложения на Windows или Linux. Хотя в этом руководстве используется приложение ASP.NET Core 8.0, процесс совпадает с другими версиями ASP.NET Core.

Important

Azure Cache for Redis объявил о плане по выводу из эксплуатации всех SKU. Мы рекомендуем переместить существующие экземпляры Azure Cache for Redis в Azure Managed Redis сразу же.

Руководство по миграции:

Дополнительные сведения о выходе на пенсию:

В этом руководстве описано следующее:

  • Создайте архитектуру, включающую по умолчанию безопасные Службу приложений, Базу данных SQL и кэш Redis.
  • Обеспечение безопасности секретов подключения с использованием управляемой идентичности и ссылок на Key Vault.
  • Разверните пример приложения ASP.NET Core в службе приложений из репозитория GitHub.
  • Доступ к Служба приложений строка подключения и параметрам приложения в коде приложения.
  • Создание обновлений и повторное развертывание кода приложения.
  • Создайте схему базы данных, загрузив пакет миграций.
  • Передача потоковых данных журналов диагностики из Azure.
  • Управление приложением на портале Azure.
  • Подготовьте ту же архитектуру и разверните с помощью Azure CLI разработчика.
  • Оптимизируйте рабочий процесс разработки с помощью GitHub пространства кода и GitHub Copilot.

Необходимые условия

  • Учетная запись Azure с активной подпиской. Если у вас нет учетной записи Azure, вы можете создать ее бесплатно.
  • Учетная запись GitHub. Вы также можете получить его бесплатно.
  • Знание разработки ASP.NET Core.
  • (необязательно) Чтобы попробовать GitHub Copilot, вам понадобится учетная запись GitHub Copilot. Доступна 30-дневная бесплатная пробная версия.
  • Учетная запись Azure с активной подпиской. Если у вас нет учетной записи Azure, вы можете создать ее бесплатно.
  • Azure Developer CLI установлен. Вы можете следовать указаниям с помощью Azure Cloud Shell, потому что в нем уже установлен инструментарий командной строки Azure для разработчиков.
  • Знание разработки ASP.NET Core.
  • (необязательно) Чтобы попробовать GitHub Copilot, вам понадобится учетная запись GitHub Copilot. Доступна 30-дневная бесплатная пробная версия.

Перейти к концу

Если вы просто хотите увидеть, как пример приложения из этого руководства работает в Azure, выполните следующие команды в Azure Cloud Shell и следуйте инструкциям:

dotnet tool install --global dotnet-ef
mkdir msdocs-app-service-sqldb-dotnetcore
cd msdocs-app-service-sqldb-dotnetcore
azd init --template msdocs-app-service-sqldb-dotnetcore
azd up

1. Запустите пример

Сначала вы настраиваете пример приложения на основе данных в качестве отправной точки. Для удобства sample repository включает конфигурацию dev контейнера. Контейнер разработки имеет все необходимое для разработки приложения, включая базу данных, кэш и все переменные среды, необходимые образцу приложения. Контейнер разработки может выполняться в пространстве кода GitHub, что означает, что вы можете запустить пример на любом компьютере с веб-браузером.

Шаг 1. В новом окне браузера:

  1. Войдите в учетную запись GitHub.
  2. Перейдите к https://github.com/Azure-Samples/msdocs-app-service-sqldb-dotnetcore/fork.
  3. Отмена выбора только для копирования основной ветви. Вы хотите все ветви.
  4. Выберите Создать ответвление.

Step 2: В форке на GitHub:

  1. Выберите основную>начальную-ветвь-без-инфраструктуры для стартовой ветви. Эта ветвь содержит только пример проекта и не содержит файлов или конфигурации, связанных с Azure.
  2. Выберите Code>Codespaces>Создать рабочее пространство на starter-no-infra. Настройка кодового пространства занимает несколько минут.

Шаг 3. В терминале кодового пространства:

  1. Выполните миграции базы данных с dotnet ef database update.
  2. Запустите приложение, выполнив команду dotnet run.
  3. Когда появится уведомление Your application running on port 5093 is available., нажмите кнопку "Открыть в браузере". Пример приложения должен отображаться на новой вкладке браузера. Чтобы остановить приложение, введите Ctrl+C.

Совет

Вы можете попросить GitHub Copilot об этом репозитории. Например:

  • @workspace Что делает этот проект?
  • @workspace Что делает папка devcontainer?

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

2. Создайте службу приложений, базу данных и кэш

На этом шаге вы создадите эти ресурсы Azure. Действия, используемые в этом руководстве, создают набор защищенных по умолчанию ресурсов, включающих службу приложений, Azure SQL Database и кэш Azure. В процессе создания вы укажете следующее:

  • Имя веб-приложения. Он используется в качестве части DNS-имени приложения.
  • Регион, в котором приложение будет физически запускаться в мире. Он также используется в качестве части DNS-имени приложения.
  • Стек среды выполнения для приложения. Здесь вы выбираете версию .NET, используемую для приложения.
  • План размещения для приложения. Это ценовая категория, которая включает набор функций и емкость масштабирования для вашего приложения.
  • Группа ресурсов для приложения. Группа ресурсов позволяет группировать (в логическом контейнере) все Azure ресурсы, необходимые для приложения.

Войдите на портал Azure и выполните следующие действия, чтобы создать ресурсы Azure App Service.

Step 1: На портале Azure:

  1. В верхней строке поиска введите службу приложений.
  2. Выберите элемент, помеченный службой приложений , под заголовком "Службы ".
  3. Выберите "Создать>веб-приложение". Вы также можете перейти к мастеру настройки напрямую.

Шаг 2. На странице "Создание веб-приложения" заполните форму следующим образом.

  1. Имя: msdocs-core-sql-XYZ. Для вас будет создана группа ресурсов с именем msdocs-core-sql-XYZ_group .
  2. стек выполнения: Runtime: .NET 8 (LTS).
  3. Операционная система: Linux.
  4. Регион: предпочитаемый регион.
  5. План Linux: Создайте новый и используйте имя msdocs-core-sql-XYZ.
  6. Тарифный план: Базовый B1. Когда вы будете готовы, вы можете увеличить масштаб до другой ценовой категории.

Шаг 3.

  1. Перейдите на вкладку "База данных ".
  2. Выберите "Создать базу данных".
  3. В обработчике выберите SQLAzure.
  4. Создайте кэш Redis.
  5. В поле "Имя " (в разделе "Кэш") введите имя кэша.
  6. В номере SKU выберите "Базовый".

Шаг 4.

  1. Перейдите на вкладку "Развертывание ".
  2. Включите непрерывное развертывание.
  3. В Organization выберите псевдоним GitHub.
  4. В репозитории выберите msdocs-app-service-sqldb-dotnetcore.
  5. В ветке выберите starter-no-infra.
  6. Убедитесь, что обычная проверка подлинности отключена.
  7. Выберите Просмотреть и создать.
  8. После завершения проверки щелкните Создать.

Шаг 5. Развертывание занимает несколько минут. После завершения развертывания нажмите кнопку Перейти к ресурсу. Вы перейдете непосредственно в приложение Службы приложений, но будут созданы следующие ресурсы:

  • Группа ресурсов: контейнер для всех созданных ресурсов.
  • План службы приложений: Определяет вычислительные ресурсы для службы приложений. Создается план Linux на уровне Базовый.
  • Служба приложений: Представляет ваше приложение и работает в плане Служба приложений.
  • Виртуальная сеть: интегрированная с приложением Служба приложений и изолирует внутренний сетевой трафик.
  • Частные конечные точки: доступ к конечным точкам для хранилища ключей, сервера базы данных и кэша Redis в виртуальной сети.
  • Сетевые интерфейсы: представляет частные IP-адреса, по одному для каждой из частных конечных точек.
  • сервер Azure SQL Database: доступен только из частной конечной точки.
  • Azure SQL Database: база данных и пользователь создаются на сервере.
  • Redis: доступен только из своей частной конечной точки.
  • Хранилище ключей: доступно только из своей частной конечной точки. Используется для управления секретами для приложения Служба приложений.
  • Частные DNS-зоны: включите разрешение DNS для хранилища ключей, для сервера базы данных и для кэша Redis в виртуальной сети.

3. Безопасные секреты подключения

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

Совет

Чтобы использовать проверку подлинности без пароля, обратитесь к разделу Как изменить подключение к SQL Database, чтобы использовать управляемое удостоверение?

Шаг 1: Получение существующей строки подключения

  1. В левом меню на странице службы приложений выберите Параметры > переменных среды, > строки подключения.
  2. Выберите AZURE_SQL_CONNECTIONSTRING.
  3. В поле Add/Edit connection string в поле Value найдите часть Password= в конце строки.
  4. Скопируйте строку пароля после password= для последующего использования. Это connection string позволяет подключаться к базе данных SQL, защищенной за частной конечной точкой. Однако секреты сохраняются непосредственно в приложении Служба приложений, что не является лучшим. Аналогичным образом, кэш Redis connection string на вкладке App settings содержит секрет. Вы измените это.

Шаг 2. Создание хранилища ключей для безопасного управления секретами

  1. В верхней строке поиска введите "key vault", а затем выберите Marketplace>Key Vault.
  2. В группе ресурсов выберите msdocs-core-sql-XYZ_group.
  3. В имени хранилища ключей введите имя, состоящее только из букв и чисел.
  4. В регионе задайте для него то же расположение, что и группа ресурсов.

Шаг 3. Защита хранилища ключей с помощью частной конечной точки

  1. Перейдите на вкладку Сеть.
  2. Отмена выбора включения общедоступного доступа.
  3. Выберите "Создать частную конечную точку".
  4. В группе ресурсов выберите msdocs-core-sql-XYZ_group.
  5. В диалоговом окне, в разделе Расположение, выберите то же местоположение, что и ваше приложение в Службе приложений.
  6. В поле Name введите msdocs-core-sql-XYZVvaultEndpoint.
  7. В виртуальной сети выберите виртуальную сеть в группе msdocs-core-sql-XYZ_group .
  8. В подсети выберите доступную совместимую подсеть. Мастер веб-приложений создал его для удобства.
  9. Нажмите ОК.
  10. Выберите Проверить и создать, а затем выберите Создать. Дождитесь завершения развертывания хранилища ключей. Должно появиться сообщение "Развертывание завершено".

Шаг 4.

  1. В верхней строке поиска введите msdocs-core-sql, затем найдите ресурс Службы приложений с именем msdocs-core-sql-XYZ.
  2. На странице Служба приложений в меню слева выберите Настройки Соединитель службы>. Уже существуют два соединителя, созданных мастером создания приложения.
  3. Отметьте флажок рядом с коннектором База данных SQL, а затем выберите "Изменить".
  4. Выберите вкладку Аутентификация.
  5. Вставьте пароль, скопированный ранее.
  6. Выберите Store Secret в Key Vault.
  7. В разделе Подключение Key Vault выберите Создать новое. Диалоговое окно создания подключения открывается поверх диалогового окна редактирования.

Шаг 5: Установите подключение к "Key Vault"

  1. В диалоговом окне Создание подключения, для подключения Key Vault, выберите хранилище ключей, которое вы создали ранее.
  2. Выберите Review + Create.
  3. После завершения проверки нажмите кнопку "Создать".

Скриншот, демонстрирующий процесс создания соединителя службы Key Vault.

Шаг 6. Завершение настройки соединителя База данных SQL

  1. Вы вернулись в диалоговом окне редактирования для defaultConnector. На вкладке Проверка подлинности дождитесь создания соединителя хранилища ключей. По завершении раскрывающийся список Key Vault Connection автоматически выберет его.
  2. Выберите Далее: сеть.
  3. Выберите " Настроить правила брандмауэра", чтобы включить доступ к целевой службе. Мастер создания приложения уже защитил базу данных SQL с помощью частной конечной точки.
  4. Выберите Сохранить. Подождите, пока появится уведомление об успешном обновлении.

Step 7. Настройте соединитель Redis для использования секретов Key Vault

  1. На странице соединителя службы установите флажок рядом с соединителем Cache for Redis, а затем нажмите кнопку "Изменить".
  2. Выберите вкладку Аутентификация.
  3. Выберите Store Secret в Key Vault.
  4. В секции "Key Vault Connection" выберите созданный "key vault".
  5. Выберите Далее: сеть.
  6. Выберите " Настроить правила брандмауэра", чтобы включить доступ к целевой службе.
  7. Выберите Сохранить. Подождите, пока появится уведомление об успешном обновлении.

Step 8. Проверка интеграции Key Vault

  1. В меню слева снова выберите Настройки> Переменные среды> Строки подключения.
  2. Рядом с AZURE_SQL_CONNECTIONSTRING выберите "Показать значение". Значение должно быть @Microsoft.KeyVault(...), то есть это ссылка на хранилище ключей key vault так как секрет теперь управляется в хранилище ключей.
  3. Чтобы проверить строку подключения Redis, перейдите на вкладку App settings. Рядом с AZURE_REDIS_CONNECTIONSTRING выберите Показать значение. Значение также должно быть @Microsoft.KeyVault(...).

Вкратце, процесс обеспечения безопасности данных доступа включал:

  • Извлечение секретов подключения из переменных среды приложения Служба приложений.
  • Создание хранилища ключей.
  • Создание подключения к Key Vault с использованием управляемой системой назначенной управляемой идентичности.
  • Обновление служебных соединителей для хранения секретов в хранилище ключей.

4. Развертывание примера кода

На этом шаге вы настроите развертывание GitHub с помощью GitHub Actions. Это всего лишь один из множества способов развертывания в Службе приложений, но это также отличный способ обеспечения непрерывной интеграции в процессе развертывания. По умолчанию каждое git push в вашем репозитории GitHub инициирует сборку и развертывание.

Step 1: Вернитесь в пространство кода GitHub вашей вилки примера и запустите git pull origin starter-no-infra. Это извлекает только что зафиксированный файл рабочего процесса в пространство кода.

Step 2 (вариант 1: с GitHub Copilot):

  1. Запустите новый сеанс чата, выбрав представление чата, а затем выберите +.
  2. Спросите: "@workspace Как приложение подключается к базе данных и кэшу?" Copilot может дать вам некоторое объяснение о классе MyDatabaseContext и его настройке в Program.cs.
  3. Спросите: "В режиме производства я хочу, чтобы приложение использовало строку подключения с именем AZURE_SQL_CONNECTIONSTRING для базы данных и настройку приложения с именем AZURE_REDIS_CONNECTIONSTRING". Copilot может предложить вам фрагмент кода, похожий на шаги в разделе Option 2: без GitHub Copilot, и даже посоветовать вам внести изменения в файл Program.cs.
  4. Откройте Program.cs в обозревателе и добавьте предложение кода. GitHub Copilot не дает вам одинаковый ответ каждый раз, и это не всегда правильно. Вам может потребоваться задать дополнительные вопросы, чтобы точно настроить ответ. Советы см. в разделе Что можно сделать с GitHub Copilot в моем пространстве кода?.

Step 2 (вариант 2: без GitHub Copilot):

  1. Откройте Program.cs в обозревателе.
  2. Найдите закомментируемый код (строки 12–21) и раскомментируйте его. Этот код подключается к базе данных с помощью AZURE_SQL_CONNECTIONSTRING и подключается к кэшу Redis с помощью параметра AZURE_REDIS_CONNECTIONSTRING приложения.

Step 3 (вариант 1: с GitHub Copilot):

  1. Откройте github/workflows/starter-no-infra_msdocs-core-sql-XYZ в обозревателе. Мастер создания службы приложений создал этот файл.
  2. Выделите шаг dotnet publish и выберите .
  3. Спросите Copilot: "Установите dotnet ef, а затем создайте пакет миграций в той же выходной папке."
  4. Если предложение приемлемо, нажмите кнопку "Принять". GitHub Copilot не дает вам одинаковый ответ каждый раз, и это не всегда правильно. Вам может потребоваться задать дополнительные вопросы, чтобы точно настроить ответ. Советы см. в разделе Что можно сделать с GitHub Copilot в моем пространстве кода?.

Снимок экрана: использование GitHub Copilot в рабочем файле процессов GitHub.

Step 3 (вариант 2: без GitHub Copilot):

  1. Откройте github/workflows/starter-no-infra_msdocs-core-sql-XYZ в обозревателе. Мастер создания службы приложений создал этот файл
  2. На шаге dotnet publish добавьте шаг для установки средства Entity Framework Core с помощью команды dotnet tool install -g dotnet-ef --version 8.*.
  3. На первом новом шаге добавьте еще один шаг, чтобы создать пакет миграции базы данных в пакете развертывания: dotnet ef migrations bundle --runtime linux-x64 -o ${{env.DOTNET_ROOT}}/myapp/migrationsbundle. Пакет миграции — это автономный исполняемый файл, который можно запустить в рабочей среде, не требуя пакета SDK для .NET. Контейнер Linux службы приложений имеет только среду выполнения .NET, а не пакет SDK .NET.

Снимок экрана, показывающий шаги, добавленные в файл рабочего процесса GitHub для набора миграции базы данных.

Шаг 4.

  1. Выберите расширение Исходный код.
  2. В текстовом поле введите сообщение коммита, например Configure Azure database and cache connections. Или выберите и позвольте GitHub Copilot создать комментарий к коммиту.
  3. Нажмите кнопку "Зафиксировать", а затем подтвердите значение "Да".
  4. Нажмите кнопку "Синхронизировать изменения 1", а затем нажмите кнопку "ОК".

Step 5: Назад на странице Центра развертывания на портале Azure:

  1. Перейдите на вкладку "Журналы", затем выберите "Обновить", чтобы увидеть новый запуск развертывания.
  2. В элементе журнала для запуска развертывания выберите запись "Журналы сборки/развертывания" с последней меткой времени.

Step 6: Вы перейдете в репозиторий GitHub и увидите, что выполняется действие GitHub. Файл рабочего процесса определяет два отдельных этапа: сборку и развертывание. Дождитесь, пока выполнение GitHub покажет статус Success. Это занимает около 5 минут.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

5. Создание схемы базы данных

В случае, если база данных SQL защищена виртуальной сетью, легче всего запустить миграции dotnet баз данных в SSH-сеансе с контейнером Linux в службе приложений.

Шаг 1. Назад на странице Служба приложений в меню слева

  1. Выберите Средства разработки>SSH.
  2. Выберите Перейти. (Запуск занимает несколько минут.)

Шаг 2. В сеансе SSH:

  1. Запустите cd /home/site/wwwroot. Вот все развернутые файлы.
  2. Запустите пакет миграции, созданный рабочим процессом GitHub, с помощью команды ./migrationsbundle -- --environment Production. При успешном завершении Служба приложений успешно подключается к База данных SQL. Помните, что --environment Production соответствует изменениям кода, внесенным в Program.cs.

В сеансе SSH только изменения в файлах внутри /home могут сохраняться после перезапуска приложения. Изменения за пределами /home не сохраняются.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

6. Перейдите к приложению

Шаг 1. На странице Служба приложений:

  1. В меню слева выберите Обзор.
  2. Выберите URL-адрес своего приложения.

Шаг 2. Добавление нескольких задач в список. Поздравляем, вы запускаете веб-приложение в Azure App Service с безопасным подключением к Azure SQL Database.

Совет

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

7. Потоковая передача журналов диагностики

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

Шаг 1. На странице Служба приложений:

  1. В меню слева выберите Мониторинг>журналы службы приложений.
  2. Под элементом Ведение журнала приложения выберите Файловая система.
  3. В меню сверху выберите Сохранить.

Шаг 2. В меню слева выберите поток журналов. Вы увидите логи для своего приложения, включая логи платформы и логи внутри контейнера.

8. Очистка ресурсов

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

Step 1: В строке поиска в верхней части портала Azure:

  1. Введите имя группы ресурсов.
  2. Выберите группу ресурсов.

Шаг 2. На странице группы ресурсов выберите "Удалить группу ресурсов".

Шаг 3.

  1. Введите имя группы ресурсов для подтверждения удаления.
  2. Выберите команду Удалить.

2. Создание ресурсов Azure и развертывание примера приложения

На этом шаге вы создадите ресурсы Azure и развернете пример приложения для App Service on Linux. Действия, используемые в этом руководстве, создают набор защищенных ресурсов по умолчанию, включая службу приложений, базу данных SQL Azure и кэш Redis.

В контейнере разработки уже установлен Интерфейс командной строки разработчика Azure (AZD).

  1. Выполните команду azd initиз корневого каталога репозитория.

    azd init --template dotnet-app-service-sqldb-infra
    
  2. При появлении запроса укажите следующие ответы:

    Вопрос Ответ
    Текущий каталог не пуст. Вы хотите инициализировать проект в каталоге '<your-directory>' здесь? Y
    Что вы хотите сделать с этими файлами? Сохранение существующих файлов без изменений
    Введите новое имя среды Введите уникальное имя. Шаблон AZD использует это имя как часть DNS-имени веб-приложения в Azure (<app-name>-<hash>.azurewebsites.net). Разрешены буквенно-цифровые символы и дефисы.
  3. Войдите в Azure, выполнив команду azd auth login и следуя инструкциям.

    azd auth login
    
  4. Создайте необходимые ресурсы Azure и разверните код приложения с помощью команды azd up. Следуйте предложению, чтобы выбрать нужную подписку и местоположение для ресурсов Azure.

    azd up
    

    Выполнение azd up команды занимает около 15 минут (кэш Redis занимает больше всего времени). Он также компилирует и развертывает код вашего приложения, но позже вы измените его, чтобы использовать Службы приложений. Во время выполнения команда предоставляет сообщения о процессе подготовки и развертывания, включая ссылку на развертывание в Azure. По завершении команда также отображает ссылку на приложение развертывания.

    Этот шаблон AZD содержит файлы (azure.yaml и каталог infra), создающие архитектуру, безопасную по умолчанию, со следующими ресурсами Azure:

    • Группа ресурсов: контейнер для всех созданных ресурсов.
    • План службы приложений: Определяет вычислительные ресурсы для службы приложений. Создается план Linux на уровне Базовый.
    • Служба приложений: Представляет ваше приложение и работает в плане Служба приложений.
    • Виртуальная сеть: интегрированная с приложением Служба приложений и изолирует внутренний сетевой трафик.
    • Частные конечные точки: доступ к конечным точкам для хранилища ключей, сервера базы данных и кэша Redis в виртуальной сети.
    • Сетевые интерфейсы: представляет частные IP-адреса, по одному для каждой из частных конечных точек.
    • сервер Azure SQL Database: доступен только из частной конечной точки.
    • Azure SQL Database: база данных и пользователь создаются на сервере.
    • Redis: доступен только из своей частной конечной точки.
    • Хранилище ключей: доступно только из своей частной конечной точки. Используется для управления секретами для приложения Служба приложений.
    • Частные DNS-зоны: включите разрешение DNS для хранилища ключей, для сервера базы данных и для кэша Redis в виртуальной сети.

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

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

3. Проверка строк подключения

Совет

SQL строка подключения базы данных по умолчанию использует аутентификацию SQL. Для более безопасной аутентификации без пароля, см. Как изменить подключение к базе данных SQL, чтобы использовать управляемое удостоверение.

Шаблон AZD, который вы используете, генерирует переменные подключения для вас уже в качестве настроек приложения и выводит их в терминал для вашего удобства. Параметры приложения — это один из способов хранения секретов подключения вне репозитория кода.

  1. В выходных данных AZD найдите параметры AZURE_SQL_CONNECTIONSTRING и AZURE_REDIS_CONNECTIONSTRING. Отображаются только имена параметров. Они выглядят следующим образом в выходных данных AZD:

     App Service app has the following connection strings:
         - AZURE_SQL_CONNECTIONSTRING
         - AZURE_REDIS_CONNECTIONSTRING
         - AZURE_KEYVAULT_RESOURCEENDPOINT
         - AZURE_KEYVAULT_SCOPE
     

    AZURE_SQL_CONNECTIONSTRING содержит строку подключения к базе данных Azure SQL, а AZURE_REDIS_CONNECTIONSTRING содержит строку подключения к кэшу Azure Redis. Позже их необходимо использовать в коде.

  2. Для удобства шаблон AZD отображает прямую ссылку на страницу параметров приложения. Найдите ссылку и откройте ее на новой вкладке браузера.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

4. Изменение примера кода и повторное развертывание

  1. В пространстве кода GitHub запустите новый сеанс чата, выбрав представление Chat, а затем выберите +.

  2. Спросите: "@workspace Как приложение подключается к базе данных и кэшу?" Copilot может дать вам некоторое объяснение о классе MyDatabaseContext и его настройке в Program.cs.

  3. Спросите: "В рабочем режиме я хочу, чтобы приложение использовало строку подключения с названием AZURE_SQL_CONNECTIONSTRING для базы данных и параметр настройки приложения с названием AZURE_REDIS_CONNECTIONSTRING*." Copilot может предложить вам код, аналогичный тому, который указан в шаге Option 2: без GitHub Copilot, и даже указать вам внести изменения в файл Program.cs.

  4. Откройте Program.cs в обозревателе и добавьте предложение кода.

    GitHub Copilot не дает вам одинаковый ответ каждый раз, и это не всегда правильно. Вам может потребоваться задать дополнительные вопросы, чтобы точно настроить ответ. Советы см. в разделе Что можно сделать с GitHub Copilot в моем пространстве кода?.

Перед развертыванием этих изменений необходимо создать пакет миграции.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

5. Создание схемы базы данных

С базой данных SQL, защищённой виртуальной сетью, проще всего запустить миграцию баз данных в сеансе SSH с контейнером службы приложений. Однако контейнеры Службы приложений Linux не имеют пакета SDK для .NET, поэтому самый простой способ выполнить миграцию базы данных — отправить автономный пакет миграций.

  1. Создайте пакет миграций для проекта с помощью следующей команды:

    dotnet ef migrations bundle --runtime linux-x64 -o migrationsbundle
    

    Совет

    Пример приложения (см. DotNetCoreSqlDb.csproj) настроен для включения этого файла migrationsbundle. azd package На этапе migrationsbundle будет добавлен в пакет развертывания.

  2. Разверните все изменения с помощью azd up.

    azd up
    
  3. В выходных данных AZD найдите URL-адрес сеанса SSH и перейдите к нему в браузере. Это выглядит следующим образом в выходных данных:

     Open SSH session to App Service container at: <URL>
     
  4. Выполните следующие команды в сеансе SSH:

    cd /home/site/wwwroot
    ./migrationsbundle -- --environment Production
    

    При успешном завершении Служба приложений успешно подключается к базе данных. Помните, что --environment Production соответствует изменениям кода, внесенным в Program.cs.

    Замечание

    После перезапуска приложения могут сохраняться только изменения в файлах в /home. Изменения за пределами /home не сохраняются.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

6. Перейдите к приложению

  1. В выходных данных AZD найдите URL-адрес приложения и перейдите к нему в браузере. URL-адрес выглядит следующим образом в выходных данных AZD:

     Deploying services (azd deploy)
    
       (✓) Done: Deploying service web
       - Endpoint: <URL>
     
  2. Добавьте несколько задач в список.

    Снимок экрана веб-приложения ASP.NET Core с базой данных SQL, запускаемых на платформе Azure, показывающий задачи.

    Поздравляем, вы запускаете веб-приложение в Azure App Service с безопасным подключением к Azure SQL Database.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

7. Потоковая передача журналов диагностики

Azure App Service могут записывать журналы консоли для диагностики проблем с приложением. Для удобства шаблон AZD уже включено ведение журнала в локальной файловой системе и отправка журналов в рабочую область Log Analytics.

Пример приложения включает стандартные инструкции ведения журнала для демонстрации этой возможности, как показано в следующем фрагменте кода:

public async Task<IActionResult> Index()
{
    var todoItems = await _cache.GetAsync(_TodoItemsCacheKey);
    if (todoItems != null)
    {
        _logger.LogInformation("Data from cache.");
        var todoList = JsonConvert.DeserializeObject<List<Todo>>(Encoding.UTF8.GetString(todoItems));
        return View(todoList);
    }
    else
    {
        _logger.LogInformation("Data from database.");
        var todoList = await _context.Todo.ToListAsync();
        var serializedTodoList = JsonConvert.SerializeObject(todoList);
        await _cache.SetAsync(_TodoItemsCacheKey, Encoding.UTF8.GetBytes(serializedTodoList));
        return View(todoList);
    }
}

В выходных данных AZD найдите ссылку для потоковой передачи журналов в Службе приложений и перейдите по ней в браузере. Ссылка выглядит следующим образом в выходных данных AZD:

Stream App Service logs at: <URL>

Дополнительные сведения о входе в приложения .NET в серии Enable Azure Monitor OpenTelemetry для .NET, Node.js, Python и Java приложений.

Возникли проблемы? Ознакомьтесь с разделом "Устранение неполадок".

8. Очистка ресурсов

Чтобы удалить все Azure ресурсы в текущей среде развертывания, запустите azd down и следуйте инструкциям.

azd down

Устранение неполадок

Представление развертывания портала для Azure SQL Database отображает состояние конфликта

В зависимости от выбранной подписки и выбранного региона может появиться состояние развертывания для Azure SQL Database Conflict со следующим сообщением в разделе "Сведения об операции".

Location '<region>' is not accepting creation of new Windows Azure SQL Database servers at this time.

Эта ошибка, скорее всего, вызвана ограничением подписки для выбранного региона. Попробуйте выбрать другой регион для развертывания.

На портале Azure пользовательский интерфейс потока журналов для веб-приложения отображает сетевые ошибки.

Вы можете увидеть эту ошибку:

Unable to open a connection to your app. This may be due to any network security groups or IP restriction rules that you have placed on your app. To use log streaming, please make sure you are able to access your app directly from your current network.

Обычно это временная ошибка при первом запуске приложения. Подождите несколько минут и проверьте еще раз.

Сеанс SSH в браузере отображается SSH CONN CLOSED

Для запуска контейнера Linux потребуется несколько минут. Подождите несколько минут и проверьте еще раз.

На странице потока журнала портала отображаются Connected! журналы, но журналы отсутствуют

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

Часто задаваемые вопросы

Сколько стоит такая конфигурация?

Цены на созданные ресурсы приведены следующим образом:

  • План службы приложений создается на уровне Базовый, и его можно масштабировать вверх или вниз. См. цены на Службу приложений.
  • Azure SQL Database создается в бессерверном слое общего назначения на оборудовании серии Standard с минимальными ядрами. Существует небольшая стоимость и может быть распределена по другим регионам. Вы можете свести к минимуму затраты еще больше, уменьшая максимальный размер или масштабируя его, изменяя уровень обслуживания, уровень вычислений, конфигурацию оборудования, количество ядер, размер базы данных и избыточность зоны. См. сведения о ценах Azure SQL Database.
  • Azure Cache for Redis создается на уровне Basic с минимальным размером кэша. Существует небольшая стоимость, связанная с этим уровнем. Его можно масштабировать до более высоких уровней производительности для повышения доступности, кластеризации и других функций. См. сведения о ценах Azure Cache for Redis. Дополнительные сведения см. в ценах на управляемый Redis в Azure.
  • Плата за виртуальную сеть не взимается, если только вы не настроите дополнительные функциональные возможности, такие как пиринг. См. сведения о ценах Azure Virtual Network.
  • За частную зону DNS взимается небольшая плата. См. сведения о ценах Azure DNS.

Как подключиться к серверу Azure SQL Database, защищённому внутри виртуальной сети, с использованием других инструментов?

  • Для базового доступа из программы командной строки можно запустить sqlcmd из терминала SSH приложения. Контейнер приложения не предоставляется вместе с sqlcmd, поэтому его необходимо установить вручную. Помните, что установленный клиент не сохраняется во время перезапуска приложения.
  • Чтобы подключиться из клиента SQL Server Management Studio или из Visual Studio, компьютер должен находиться в виртуальной сети. Например, это может быть Azure VM, подключенный к одной из подсетей, или компьютер в локальной сети, который имеет подключение по VPN межсайтовое подключение с виртуальной сетью Azure.

Как разработка локальных приложений работает с GitHub Actions?

Возьмем автоматически созданный файл рабочего процесса из Службы приложений в качестве примера, где каждый git push запускает новый прогон сборки и развертывания. После внесения необходимых обновлений в локальный клон репозитория GitHub, отправьте его на GitHub. Например:

git add .
git commit -m "<some-message>"
git push origin main

Как выполнить отладку ошибок во время развертывания GitHub Actions?

Если шаг завершается ошибкой в автогенерируемом в GitHub файле рабочего процесса, попробуйте изменить неудавшуюся команду, чтобы создать более подробный вывод. Например, можно получить больше выходных данных от любой команды dotnet, добавив этот параметр -v. Зафиксируйте и отправьте изменения, чтобы активировать дополнительное развертывание для Службы приложений.

У меня нет разрешений на создание идентичности, назначенной пользователем

См. раздел Настройка развертывания GitHub Actions из Центра развертывания.

Как изменить подключение к базе данных SQL, чтобы использовать управляемое удостоверение вместо этого?

Компонент Service Connector управляет строкой подключения по умолчанию к базе данных SQL с именем defaultConnector и использует SQL аутентификацию. Чтобы заменить его на подключение, использующее управляемое удостоверение, выполните следующие команды в облачной оболочке после замены заполнителей:

az extension add --name serviceconnector-passwordless --upgrade
az sql server update --enable-public-network true
az webapp connection delete sql --connection defaultConnector --resource-group <group-name> --name <app-name>
az webapp connection create sql --connection defaultConnector --resource-group <group-name> --name <app-name> --target-resource-group <group-name> --server <database-server-name> --database <database-name> --client-type dotnet --system-identity --config-connstr true
az sql server update --enable-public-network false

По умолчанию команда az webapp connection create sql --client-type dotnet --system-identity --config-connstr выполняет следующие действия:

  • Назначает вашего пользователя администратором Microsoft Entra ID на сервере SQL баз данных.
  • Создайте назначаемое системой управляемое удостоверение и предоставьте ему доступ к базе данных.
  • Создает строку подключения без пароля под названием AZURE_SQL_CONNECTIONGSTRING, которую приложение уже использует в конце руководства.

Теперь приложение должно иметь подключение к базе данных SQL. Дополнительные сведения см. в разделе Tutorial: подключение к базам данных Azure из службы приложений без секретов с помощью управляемого удостоверения.

Совет

Не хотите включить подключение к общедоступной сети? Вы можете пропустить az sql server update --enable-public-network true и выполнить команды из интегрированной с вашей виртуальной сетью облачной оболочки Azure, если у вас есть назначение роли владелец в вашей подписке.

Чтобы предоставить учетной записи необходимый доступ к базе данных, защищенной виртуальной сетью, az webapp connection create sql требует прямого подключения к серверу базы данных для аутентификации через Entra ID. По умолчанию Azure cloud shell не имеет этого доступа к защищенной сети базе данных.

Что можно сделать с GitHub Copilot в моем пространстве кода?

Возможно, вы заметили, что чат GitHub Copilot уже был доступен при создании кодового пространства. Для удобства мы добавим расширение чата GitHub Copilot в определение контейнера (см. раздел .devcontainer/devcontainer.json). Однако вам нужна учетная запись GitHub Copilot (доступна бесплатная пробная версия 30 дней).

Некоторые советы для вас при разговоре с GitHub Copilot:

  • В рамках одного сеанса общения вопросы и ответы развиваются друг из друга, и вы можете изменять свои вопросы, чтобы уточнить получаемый ответ.
  • По умолчанию GitHub Copilot не имеет доступа к файлу в репозитории. Чтобы задать вопросы о файле, сначала откройте файл в редакторе.
  • Для доступа GitHub Copilot ко всем файлам в репозитории при подготовке ответов начните вопрос с @workspace. Дополнительные сведения см. в разделе Use the @workspace agent.
  • В сеансе чата GitHub Copilot может предлагать изменения и (с @workspace) даже указывать, где их вносить, но самостоятельно изменения вносить нельзя. Вам нужно добавить предлагаемые изменения и проверить их.

Вот некоторые другие вещи, которые вы можете сказать, чтобы точно настроить ответ, который вы получаете:

  • Я хочу, чтобы этот код выполнялся только в рабочем режиме.
  • Я хочу, чтобы этот код выполнялся только в Azure App Service, а не локально.
  • Параметр --output-path, кажется, неподдерживаемый.

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

Также ознакомьтесь с другими ресурсами: