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

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

• Служба приложений в этой базовой архитектуре не реализовано автоматическое масштабирование. Служба не выполняет динамическое масштабирование или в соответствии с требованиями.
  • Уровень "Стандартный" поддерживает параметры автомасштабирования, чтобы настроить автомасштабирование на основе правил. Часть процесса POC должна быть направлена на получение эффективных параметров автомасштабирования на основе потребностей в ресурсе приложения и ожидаемых характеристик использования.
  • Для рабочих развертываний рассмотрите категории "Премиум", поддерживающие автоматическое масштабирование, где платформа автоматически обрабатывает решения по масштабированию .
• Следуйте инструкциям, чтобы увеличить масштаб отдельных баз данных без простоя приложения, если требуется более высокий уровень обслуживания или уровень производительности для База данных SQL.

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

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

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

Связанные ресурсы

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

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

• Обзор Службы приложений Azure
• Общие сведения о службе Azure Monitor
• Обзор планов службы приложений Azure
• Обзор Log Analytics в Azure Monitor
• Что такое идентификатор Microsoft Entra?
• Что такое База данных SQL Azure

Модули Microsoft Learn.

• Настройка Azure Monitor и управление ими
• Настройка идентификатора Microsoft Entra
• Настройка Azure Monitor
• Развертывание и настройка серверов, экземпляров и баз данных для SQL Azure
• Изучение службы приложение Azure
• Размещение веб-приложения с помощью службы приложение Azure
• Размещение домена в Azure DNS
• Реализация Azure Key Vault
• Управление пользователями и группами в идентификаторе Microsoft Entra