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


Учебник. Развертывание приложения ASP.NET Core с подключением к Базе данных SQL Azure в Службе приложений Azure

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

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

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

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

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

Если вы хотите увидеть, как демонстрационное приложение из этого учебника работает в 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. Запустите пример

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

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

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

Шаг 2. В форке GitHub:

  1. Выберите основную>начальную-ветвь-без-инфраструктуры для стартовой ветви. Эта ветвь содержит только пример проекта и не содержит файлов или конфигурации, связанных с Azure.
  2. Выберите Code>Создать codespace на 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. Действия, используемые в этом руководстве, создают набор защищенных по умолчанию ресурсов, которые включают Служба приложений, База данных SQL Azure и кэш Azure. В процессе создания вы укажете следующее:

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

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

Шаг 1. В портал Azure:

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

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

  1. Группа ресурсов: выберите Создать новую и используйте имя msdocs-core-sql-tutorial.
  2. Регион: любой регион Azure рядом с вами.
  3. Имя: msdocs-core-sql-XYZ, где XYZ является любыми тремя случайными символами. Это имя должно быть уникальным в Azure.
  4. Стек среды выполнения: .NET 8 (LTS).
  5. Подсистема: SQLAzure. База данных SQL Azure — это полностью управляемая платформа как служба (PaaS), которая всегда работает в последней стабильной версии SQL Server.
  6. Добавьте Кэш Azure для Redis?: Да.
  7. План размещения: базовый. Когда вы будете готовы, вы можете перейти на промышленную ценовую категорию.
  8. Выберите Просмотреть и создать.
  9. После завершения проверки щелкните Создать.

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

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

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

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

Совет

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

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

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

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

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

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

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

Шаг 4.

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 1. В меню слева выберите центр>.

Шаг 2. На странице Центра развертывания:

  1. В поле Источник выберите GitHub. По умолчанию в качестве поставщика сборки выбрано GitHub Actions.
  2. Войдите в свою учетную запись GitHub и следуйте инструкциям по авторизации Azure.
  3. В поле Организация выберите свою учетную запись.
  4. В репозитории выберите msdocs-app-service-sqldb-dotnetcore.
  5. В ветке выберите starter-no-infra. Это та же ветвь, где вы работали с приложением-примером, без файлов или конфигурации, относящихся к Azure.
  6. Для типа проверки подлинности выберите идентичность, назначаемую пользователем.
  7. В меню сверху выберите Сохранить. Служба приложений фиксирует файл рабочего процесса в выбранном репозитории GitHub в каталоге .github/workflows. По умолчанию центр развертывания создает пользовательское удостоверение для аутентификации рабочего процесса с помощью Microsoft Entra (аутентификация OIDC). Дополнительные сведения о вариантах аутентификации см. в разделе Развертывание в службе приложений с помощью GitHub Actions.

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

Шаг 4 (вариант 1: с GitHub Copilot):

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

Шаг 4 (вариант 2: без GitHub Copilot):

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

Шаг 5 (вариант 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 в моем пространстве кода?".

Шаг 5 (вариант 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.

Шаг 6.

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

Шаг 7. Назад на странице Центра развертывания в портал Azure:

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

Шаг 8. Вы перейдете в репозиторий GitHub и увидите, что действие GitHub выполняется. Файл рабочего процесса определяет два отдельных этапа: сборку и развертывание. Дождитесь запуска GitHub, чтобы отобразить состояние успешности. Это занимает около 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 с безопасным подключением к База данных SQL Azure.

Совет

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

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

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

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

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

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

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

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

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

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

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

Шаг 3.

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

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

На этом шаге вы создадите ресурсы Azure и развернете пример приложения в Службе приложений на Linux. Действия, используемые в этом руководстве, создают набор защищенных ресурсов по умолчанию, включая Служба приложений, База данных SQL Azure и Кэш 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. Разверните код приложения с помощью команды azd up, создав необходимые ресурсы Azure. Следуйте запросу, чтобы выбрать нужную подписку и расположение для ресурсов Azure.

    azd up
    

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

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

    • Группа ресурсов: контейнер для всех созданных ресурсов.
    • План службы приложений: Определяет вычислительные ресурсы для службы приложений. Создается план Linux на уровне Базовый.
    • Служба приложений: Представляет ваше приложение и работает в плане службы приложений.
    • Виртуальная сеть: интегрированная с приложением Служба приложений и изолирует внутренний сетевой трафик.
    • Частные конечные точки: доступ к конечным точкам для хранилища ключей, сервера базы данных и кэша Redis в виртуальной сети.
    • Сетевые интерфейсы: представляет частные IP-адреса, по одному для каждой из частных конечных точек.
    • сервер База данных SQL Azure: доступен только за частной конечной точкой.
    • База данных SQL Azure: база данных и пользователь создаются на сервере.
    • Кэш Azure для 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 содержит строку подключения к базе данных SQL в Azure, а AZURE_REDIS_CONNECTIONSTRING содержит строку подключения к Azure Redis-кэшу. Позже их необходимо использовать в коде.

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

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

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

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

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

  3. Спросите: "В рабочем режиме я хочу, чтобы приложение использовало строку подключения под именем AZURE_SQL_CONNECTIONSTRING для базы данных и параметр приложения, называемый AZURE_REDIS_CONNECTIONSTRING*". Copilot может предложить вам код, аналогичный варианту 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: https://<app-name>.scm.azurewebsites.net/webssh/host
     
  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: https://<app-name>-<hash>.azurewebsites.net/
     
  2. Добавьте несколько задач в список.

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

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

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

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

Служба приложений Azure может записывать консольные логи для диагностики проблем с приложением. Для удобства шаблон 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: https://portal.azure.com/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream

Узнайте больше о ведении журнала в приложениях .NET в серии "Включение Azure Monitor OpenTelemetry для приложений .NET, Node.js, Python и Java".

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

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

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

azd down

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

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

В зависимости от вашей подписки и выбранного вами региона может быть видно состояние развертывания для базы данных Azure SQL 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 создается в общем назначении, в бессерверной конфигурации на оборудовании стандартной серии с минимальным количеством ядер. Существует небольшая стоимость и может быть распределена по другим регионам. Вы можете свести к минимуму затраты еще больше, уменьшая максимальный размер или масштабируя его, изменяя уровень обслуживания, уровень вычислений, конфигурацию оборудования, количество ядер, размер базы данных и избыточность зоны. См. страницу Цены на Базу данных SQL Azure.
  • Кэш Azure для Redis создается на уровне "Базовый" с минимальным размером кэша. Существует небольшая стоимость, связанная с этим уровнем. Его можно масштабировать до более высоких уровней производительности для повышения доступности, кластеризации и других функций. См. цены на Azure Cache для Redis.
  • Плата за виртуальную сеть не взимается, если только вы не настроите дополнительные функциональные возможности, такие как пиринг. См. цены на виртуальные сети Azure.
  • За частную зону DNS взимается небольшая плата. См. цены на Azure DNS.

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

  • Для базового доступа из программы командной строки можно запустить sqlcmd из терминала SSH приложения. Контейнер приложения не предоставляется вместе с sqlcmd, поэтому его необходимо установить вручную. Помните, что установленный клиент не сохраняется во время перезапуска приложения.
  • Чтобы подключиться из клиента SQL Server Management Studio или из Visual Studio, компьютер должен находиться в виртуальной сети. Например, это может быть виртуальная машина Azure, подключенная к одной из подсетей, или компьютер в локальной сети с 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, чтобы использовать управляемое удостоверение вместо этого?

Строка подключения по умолчанию для базы данных 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 на сервере базы данных SQL.
  • Создайте назначаемое системой управляемое удостоверение и предоставьте ему доступ к базе данных.
  • Создает строку подключения без пароля под названием AZURE_SQL_CONNECTIONGSTRING, которую ваше приложение уже использует в конце руководства.

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

Совет

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

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

Что можно сделать с помощью 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, а не локально.
  • Параметр --output-path, кажется, неподдерживаемый.

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

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