Базовое веб-приложение

Служба приложений Azure
Azure Monitor
База данных SQL Azure

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

Внимание

Эта архитектура не предназначена для рабочих приложений. Она предназначена для внедрения архитектуры, которую можно использовать для обучения и подтверждения концепции (POC). При разработке рабочего приложения службы приложение Azure ознакомьтесь с веб-приложением с высоким уровнем доступности, избыточным между зонами.

Внимание

Логотип GitHubРуководство поддерживается примером реализации, демонстрирующей базовую реализацию Служба приложений в Azure. Эту реализацию можно использовать в качестве основы для взаимодействия с приложение Azure службой.

Архитектура

Схема с базовой архитектурой Служба приложений.

Рис. 1. Базовая архитектура службы приложение Azure

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

  1. Пользователь выдает запрос HTTPS к домену по умолчанию Служба приложений в azurewebsites.net. Этот домен автоматически указывает на встроенный общедоступный IP-адрес Служба приложений. Подключение TLS устанавливается из клиента непосредственно к службе приложений. Сертификат полностью управляется Azure.
  2. Простая проверка подлинности, компонент службы приложение Azure, гарантирует, что пользователь, обращаюющийся к сайту, проходит проверку подлинности с помощью идентификатора Microsoft Entra.
  3. Код приложения, развернутый для Служба приложений обрабатывает запрос. Например, этот код может подключаться к экземпляру База данных SQL Azure, используя строка подключения, настроенный в Служба приложений настроенный в качестве параметра приложения.
  4. Сведения о исходном запросе для Служба приложений и вызове База данных SQL Azure регистрируются в Application Insights.

Компоненты

  • Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом. Он предоставляет единый уровень управления удостоверениями для управления разрешениями и ролями для пользователей, обращаюющихся к веб-приложению. Он интегрируется с Служба приложений и упрощает проверку подлинности и авторизацию для веб-приложений.
  • Служба приложений — это полностью управляемая платформа для создания, развертывания и масштабирования веб-приложений.
  • Azure Monitor — это служба мониторинга, которая собирает, анализирует и действует на данные телеметрии в развертывании.
  • База данных SQL Azure — это служба управляемой реляционной базы данных для реляционных данных.

Рекомендации и рекомендации

Компоненты , перечисленные в этой архитектуре, ссылаются на руководства по службе Azure Well-Architected. Руководства по службам содержат подробные рекомендации и рекомендации по конкретным службам. В этом разделе описано, как выделить ключевые рекомендации и рекомендации Azure Well-Architected Framework, которые применяются к этой архитектуре. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Эта базовая архитектура не предназначена для рабочих развертываний. Архитектура способствует простоте и экономичности по сравнению с функциональными возможностями, чтобы вы могли оценивать и учиться приложение Azure службе. В следующих разделах описаны некоторые недостатки этой базовой архитектуры, а также рекомендации и рекомендации.

Надежность

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

Так как эта архитектура не предназначена для рабочих развертываний, в следующих статьях описаны некоторые критически важные функции надежности, которые опущены в этой архитектуре:

  • План Служба приложений настроен для Standard уровня, который не поддерживает зону доступности Azure. Служба приложений становится недоступным в случае любой проблемы с экземпляром, стойкой или центром обработки данных, на котором размещен экземпляр.
  • База данных SQL Azure настроен для Basic уровня, который не поддерживает избыточность зоны. Это означает, что данные не реплицируются в зонах доступности Azure, рискуя потерей зафиксированных данных в случае сбоя.
  • Развертывания в этой архитектуре могут привести к простою при развертывании приложений, так как большинство методов развертывания требуют перезапуска всех запущенных экземпляров. Во время этого процесса пользователи могут столкнуться с ошибками 503. Это рассматривается в базовой архитектуре с помощью слотов развертывания. Тщательное проектирование приложений, управление схемами и обработка конфигурации приложений необходимы для поддержки параллельного развертывания слотов. Используйте этот POC для разработки и проверки подхода к развертыванию на основе слотов.
  • Автомасштабирование не включено в этой базовой архитектуре. Чтобы предотвратить проблемы с надежностью из-за нехватки доступных вычислительных ресурсов, вам потребуется перепроизвести, чтобы всегда выполняться с достаточным объемом вычислительных ресурсов для обработки максимальной параллельной емкости.

Узнайте, как преодолеть эти проблемы надежности в разделе надежности в веб-приложении базового уровня высокой доступности.

Если в конечном итоге для этой рабочей нагрузки потребуется архитектура с несколькими регионами active-active или active-пассивной, см. следующие ресурсы:

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в контрольном списке проверки конструктора для безопасности.

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

  • Эта базовая архитектура не реализует конфиденциальность сети. Плоскости данных и управления для ресурсов, таких как служба приложение Azure и Azure SQL Server, доступны через общедоступный Интернет. Пропускание частной сети значительно увеличивает область атаки вашей архитектуры. Чтобы узнать, как реализация частных сетей гарантирует следующие функции безопасности, см . в разделе "Сеть" веб-приложения с высоким уровнем доступности, избыточного между зонами:

    • Единая безопасная точка входа для трафика клиента
    • Сетевой трафик фильтруется как на уровне пакета, так и на уровне DDoS.
    • Утечка данных сведена к минимуму путем сохранения трафика в Azure с помощью Приватный канал
    • Сетевые ресурсы логически группируются и изолированы друг от друга через сегментацию сети.
  • Эта базовая архитектура не включает развертывание Брандмауэр веб-приложений Azure. Веб-приложение не защищается от распространенных эксплойтов и уязвимостей. Ознакомьтесь с базовой реализацией, чтобы узнать, как Брандмауэр веб-приложений можно реализовать с помощью Шлюз приложений Azure в архитектуре служб приложение Azure.

  • Эта базовая архитектура хранит секреты, такие как строка подключения SQL Server Azure в параметрах приложения. Хотя параметры приложения шифруются, при переходе в рабочую среду рекомендуется хранить секреты в Azure Key Vault для повышения управления. Еще лучшее решение — использовать управляемое удостоверение для проверки подлинности и не хранить секреты в строка подключения.

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

  • После включения локальных методов проверки подлинности для развертываний сайтов FTP и SCM в процессе разработки или подтверждения концепции. При переходе в рабочую среду необходимо отключить локальную проверку подлинности на эти конечные точки.

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

  • приложение Azure служба включает конечную точку SSL в поддомене azurewebsites.net без дополнительных затрат. HTTP-запросы перенаправляются в конечную точку HTTPS по умолчанию. Для рабочих развертываний обычно используется личный домен, связанный с шлюзом приложений или управлением API перед развертыванием Служба приложений.

  • Используйте интегрированный механизм проверки подлинности для Служба приложений ("EasyAuth"). EasyAuth упрощает процесс интеграции поставщиков удостоверений в веб-приложение. Он обрабатывает проверку подлинности за пределами веб-приложения, поэтому вам не нужно вносить существенные изменения кода.

  • Используйте управляемое удостоверение для удостоверений рабочей нагрузки. Управляемое удостоверение устраняет необходимость для разработчиков управлять учетными данными проверки подлинности. Базовая архитектура проходит проверку подлинности в SQL Server с помощью пароля в строка подключения. Рекомендуется использовать управляемое удостоверение для проверки подлинности в SQL Server Azure.

Дополнительные сведения о безопасности см. в статье "Защита приложения в службе приложение Azure".

Эффективность работы

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

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

Конфигурации приложений

Так как базовая архитектура не предназначена для рабочей среды, она использует Служба приложений конфигурацию для хранения значений и секретов конфигурации. Хранение секретов в конфигурации Служба приложений хорошо подходит для этапа PoC. Вы не используете реальные секреты и не требует управления секретами, которым требуются рабочие нагрузки.

Ниже приведены рекомендации по настройке и рекомендации.

  • Начните с Служба приложений конфигурации для хранения значений конфигурации и строка подключения в подтверждение основных развертываний. Параметры приложения и строка подключения шифруются и расшифровываются непосредственно перед внедрением в приложение при запуске.
  • При переходе на рабочий этап сохраните секреты в Azure Key Vault. Использование Azure Key Vault улучшает управление секретами двумя способами.
    • Внешний доступ к хранилищу секретов в Azure Key Vault позволяет централизировать хранилище секретов. У вас есть одно место для управления секретами.
    • С помощью Azure Key Vault вы можете регистрировать каждое взаимодействие с секретами, включая каждый раз, когда доступ к секрету осуществляется.
  • При переходе в рабочую среду можно поддерживать использование Azure Key Vault и конфигурации Служба приложений с помощью ссылок Key Vault.

Диагностика и мониторинг

На этапе подтверждения концепции важно понять, какие журналы и метрики доступны для записи. Ниже приведены рекомендации и рекомендации по мониторингу на этапе подтверждения концепции:

  • Включите диагностика ведение журнала для всех источников журналов элементов. Настройка использования всех параметров диагностики помогает понять, какие журналы и метрики предоставляются для вас из поля, и все пробелы, которые необходимо закрыть с помощью платформы ведения журнала в коде приложения. При переходе к рабочей среде следует исключить источники журналов, которые не добавляют значение и добавляют шум и затраты в приемник журнала рабочей нагрузки.
  • Настройте ведение журнала для использования Azure Log Analytics. Azure Log Analytics предоставляет масштабируемую платформу для централизованного ведения журнала, который легко запрашивать.
  • Используйте Application Insights или другое средство управления производительностью приложений (APM), чтобы получать данные телеметрии и журналы для мониторинга производительности приложений.

Развертывание

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

  • Следуйте инструкциям в ci/CD для Azure веб-приложения с помощью Azure Pipelines, чтобы автоматизировать развертывание приложения. Начните создавать логику развертывания на этапе PoC. Реализация CI/CD в начале процесса разработки позволяет быстро и безопасно выполнять итерацию в приложении при переходе к рабочей среде.
  • Используйте шаблоны ARM для развертывания ресурсов Azure и их зависимостей. Важно начать этот процесс на этапе PoC. При переходе к рабочей среде вы хотите, чтобы возможность автоматического развертывания инфраструктуры.
  • Используйте различные шаблоны ARM и интегрируйте их со службами Azure DevOps. Эта настройка позволяет создавать разные среды. Например, можно реплицировать рабочие сценарии или среды нагрузочного тестирования только при необходимости и экономии затрат.

Дополнительные сведения см. в разделе DevOps в Azure Well-Architected Framework.

Контейнеры

Базовая архитектура может использоваться для развертывания поддерживаемого кода непосредственно в экземплярах Windows или Linux. Кроме того, Служба приложений также является платформой размещения контейнеров для запуска контейнерного веб-приложения. Служба приложений предлагает различные встроенные контейнеры. Если вы используете пользовательские или многоконтейнерные приложения для дальнейшей настройки среды выполнения или для поддержки языка кода, который не поддерживается в собственном коде, вам потребуется ввести реестр контейнеров.

Уровень управления

На этапе POC удобно работать с плоскостью управления службы приложение Azure, как предоставляется через службу Kudu. Эта служба предоставляет общие API развертывания, такие как развертывания ZIP, предоставляет необработанные журналы и переменные среды.

Если вы используете контейнеры, обязательно изучите возможность Kudu открыть сеанс SSH для контейнера для поддержки расширенных возможностей отладки.

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см . в контрольном списке проверки конструктора для повышения эффективности.

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

Результатом проверки концепции должно быть выбор номера SKU, который вы оцениваете для рабочей нагрузки. Рабочая нагрузка должна быть разработана для эффективного удовлетворения спроса с помощью горизонтального масштабирования, изменив количество вычислительных экземпляров, развернутых в плане Служба приложений. Не разрабатывайте систему, чтобы зависеть от изменения номера SKU вычислений в соответствии с требованиями.

Развертывание этого сценария

Руководство поддерживается примером реализации, демонстрирующей базовую реализацию Служба приложений в Azure.

Следующие шаги

Документация по продукту:

Модули Microsoft Learn.