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

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

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

Эталонная архитектура для базового веб-приложения в Azure

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

Развертывание ссылок

эта архитектура включает в себя план службы приложений Azure и пустое приложение, База данных SQL Azure, Azure Key Vault для хранения строки подключения к базе данных, а также Azure Monitor для ведения журналов, мониторинга и оповещений.

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

az group create --name basic-web-app --location eastus

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

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

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

Architecture

Архитектура состоит из следующих компонентов:

План службыприложений. план службы приложений предоставляет управляемые виртуальные машины (ВМ), в которых размещается ваше приложение. Все приложения, связанные с одним планом, выполняются на одних тех же экземплярах виртуальной машины.

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

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

IP-адрес: приложение службы приложений имеет общедоступный IP-адрес и доменное имя. К доменному имени добавляется имя поддомена azurewebsites.net, например: contoso.azurewebsites.net.

Azure DNS: Azure DNS — это служба размещения для доменов DNS, предоставляющая разрешение имен с помощью инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure. Чтобы использовать пользовательское доменное имя, например contoso.com, создайте записи DNS, которые позволяют сопоставить это доменное имя с IP-адресом. Дополнительные сведения см. в статье Сопоставление существующего настраиваемого DNS-имени с веб-приложениями Azure.

База данных SQL Azure: База данных SQL — это реляционная база данных как услуга в облаке. База данных SQL использует свою базу кода совместно с ядром СУБД Microsoft SQL Server. В зависимости от требований приложения можно также использовать службу База данных Azure для MySQL или База данных Azure для PostgreSQL. Это полностью управляемые службы баз данных на основе сервера MySQL с открытым исходным кодом и ядра СУБД postgres.

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

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

План службы приложений

Используйте уровни Free и Shared (Предварительная версия) для целей тестирования, так как общие ресурсы не могут масштабироваться. Два уровня обеспечивают различные параметры в пределах бюджета. выполните рабочую рабочую нагрузку на уровнях " базовый", " стандартный" и " Premium ", так как приложение выполняется на выделенных экземплярах виртуальной машины и выделило ресурсы, которые могут масштабироваться. Счета за планы службы приложений выставляются за секунду.

Дополнительные сведения см. в разделе Какова стоимость плана службы приложений?

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

Плата взимается за все экземпляры в плане службы приложений, даже если приложение остановлено. Обязательно удаляйте планы, которые более не используются (например, тестовые развертывания).

База данных SQL

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

Используйте службу "База данных SQL" версии 12. Служба "База данных SQL" поддерживает уровни служб "Базовый", "Стандартный" или "Премиум", а также несколько уровней производительности для каждого из них, которые измеряются в единицах передачи данных (DTU). Оцените потребности в производительности и выберите подходящие уровни базы данных и производительности.

Регион

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

Группа ресурсов также привязана к региону, в котором хранятся метаданные развертывания. Поместите группу ресурсов и все ее ресурсы в один регион. Это повысит доступность во время развертывания.

Используйте Калькулятор цен для оценки затрат.

См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.

Вопросы масштабируемости

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

Масштабирование приложения в службе приложений

Есть два способа масштабировать приложение службы приложений:

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

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

Можно масштабировать вручную, изменив число экземпляров или используя Автомасштабирование , чтобы Azure автоматически добавили или удалил экземпляры на основе расписания и (или) метрик производительности. Каждая операция масштабирования выполняется быстро, обычно в течение нескольких секунд.

Чтобы включить функцию автомасштабирования, создайте профиль автомасштабирования, в котором указано минимальное и максимальное число экземпляров. Для профилей можно применить расписания. Например, вы можете создать отдельные профили для будних и выходных дней. Также профиль может содержать правила добавления или удаления экземпляров. (Например: добавлять два экземпляра, если в течение 5 минут загрузка ЦП превышает 70 %.)

Рекомендации по масштабированию веб-приложения:

  • По возможности Избегайте увеличения и уменьшения масштаба, так как это может вызвать перезапуск приложения. Вместо этого выберите уровень и размер экземпляров, которые соответствуют требованиям к производительности при типичной нагрузке, а затем используйте горизонтальное масштабирование, чтобы изменить число экземпляров в соответствии с объемом трафика.
  • Примените функцию автомасштабирования. Если объем рабочей нагрузки для вашего приложения стабилен и прогнозируем, создайте профили и расписание для своевременного добавления экземпляров. Если рабочая нагрузка плохо прогнозируется, используйте автомасштабирование на основе правил, чтобы оперативно реагировать на изменения нагрузки. Можно использовать оба подхода одновременно.
  • Обычно в качестве метрики для правил автомасштабирования хорошо подходит загрузка ЦП. Но мы рекомендуем провести нагрузочный тест для приложения, определить потенциальные узкие места и в соответствии с ними создать правила автомасштабирования.
  • Правила автомасштабирования включают в себя период отсрочки, который представляет собой интервал ожидания после завершения действия масштабирования перед запуском нового действия масштабирования. Период ожидания позволяет стабилизировать систему перед новым масштабированием. Задайте более короткий период охлаждения для добавления экземпляров и более длительный период охлаждения для удаления экземпляров. Например, 5 минут при добавлении экземпляра и 60 минут при его удалении. Лучше добавлять новые экземпляры быстро при высокой нагрузке, чтобы обрабатывался дополнительный трафик, а затем постепенно масштабироваться обратно.

База данных SQL Azure

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

Вопросы доступности

на момент написания статьи соглашение об уровне обслуживания (sla) для службы приложений составляет 99,95%, а соглашение об уровне обслуживания для База данных SQL — 99,99% для уровней Basic, Standard и Premium. Соглашения об уровне обслуживания в службе приложений действуют как для одного, так и для нескольких экземпляров.

Резервные копии

В случае потери данных служба "База данных SQL" обеспечивает восстановление до точки во времени и геовосстановление. Эти функции доступны на всех уровнях и включаются автоматически. Нет необходимости настраивать расписание или параметры резервного копирования.

Дополнительные сведения см. в статье Обзор обеспечения непрерывности бизнес-процессов с помощью базы данных SQL Azure.

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

Вопросы управляемости

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

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

  • Жизненный цикл. Обычно в группу ресурсов лучше объединять ресурсы с одинаковым жизненным циклом.
  • Доступ. Вы можете использовать Управление доступом на основе ролей Azure (Azure RBAC) для применения политик доступа к ресурсам в группе.
  • Выставление счетов. Вы сможете просматривать сведенные затраты для группы ресурсов.

Дополнительные сведения см. в обзоре Azure Resource Manager.

Рекомендации для DevOps

В этой архитектуре вы используете шаблон Azure Resource Manager для подготовки ресурсов Azure и их зависимостей. Поскольку это одно веб-приложение, все ресурсы изолированы в одной базовой рабочей нагрузке, что упрощает связывание ресурсов рабочей нагрузки с группой, чтобы группа могла независимо управлять всеми аспектами этих ресурсов. эта изоляция позволяет группе DevOps выполнять непрерывную интеграцию и непрерывную доставку (CI/CD). вы также можете использовать различные шаблоны ARM и интегрировать их с Azure DevOps Services для подготовки различных сред за несколько минут, например, для репликации сценариев в рабочем окружении или нагрузочных тестов только при необходимости, экономя затраты.

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

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

Развертывание состоит из двух этапов.

  1. Подготовка ресурсов Azure. Для выполнения этого шага мы рекомендуем использовать шаблоны Azure Resource Manager. Шаблоны упрощают автоматическое развертывание с помощью PowerShell или Azure CLI.
  2. Развертывание приложения (код, двоичные файлы и файлы содержимого). Здесь у вас есть несколько вариантов, в том числе: развертывание из локального репозитория Git, с помощью Visual Studio или непрерывное развертывание из системы управления версиями в облаке. Дополнительные сведения см. в статье о развертывании приложения в службе приложений Azure.

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

  • Вы можете проверить, успешно ли прошло развертывание, прежде чем переключиться на рабочую среду.
  • Развертывание в промежуточный слот гарантирует, что все экземпляры будут подготовлены перед перемещением в рабочую среду. Для многих приложений довольно долго выполняются начальная загрузка и "холодный" запуск.

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

Переключение слотов для рабочих и промежуточных развертываний

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

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

Параметр Configuration

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

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

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

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

Включите ведение журнала диагностики, включая ведение журнала приложений и ведение журнала веб-сервера. Настройте ведение журнала для использования Log Analytics Azure. Более подробные инструкции по ведению журналов см. в руководстве по мониторингу и диагностике.

Используйте службу New Relic или Application Insights, чтобы контролировать производительность и поведение загруженных приложений. Не забывайте об ограничениях на скорость передачи данных в Application Insights.

Выполните нагрузочное тестирование с использованием специального средства, например Azure DevOps или Visual Studio Team Foundation Server. Общее описание анализа производительности в облачных приложениях вы найдете в руководстве по анализу производительности для начинающих.

Советы по устранению неполадок в приложениях.

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

Вопросы безопасности

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

Аудит Баз данных SQL

Аудит поможет вам обеспечить соответствие нормативным требованиям и получать важные сведения об отклонениях и аномалиях, которые могут указывать на бизнес-проблемы или потенциальные нарушения безопасности. См. статью Приступая к работе с аудитом базы данных SQL.

Слоты развертывания

Каждый слот развертывания имеет общедоступный IP-адрес. Слоты, не используемые в рабочей среде, следует защитить с помощью входа в Azure Active Directory, чтобы доступ к этим конечным точкам могли получить только члены команд разработки и DevOps.

Ведение журнала

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

SSL

Приложение службы приложений бесплатно получает одну конечную точку SSL в поддомене azurewebsites.net. Конечная точка SSL содержит групповой сертификат для доменного имени *.azurewebsites.net. Чтобы применить пользовательское доменное имя, самостоятельно предоставьте для него сертификат. Для этого проще всего приобрести сертификат непосредственно на портале Azure. Также вы можете импортировать сертификаты других центров сертификации. Дополнительные сведения см. в статье Приобретение и настройка сертификата SSL для службы приложений Azure.

Из соображений безопасности следует принудительно применять в приложении протокол HTTPS, перенаправляя все HTTP-запросы. Такое перенаправление можно реализовать в самом приложении или с помощью правила подстановки URL-адресов, как описано в разделе Принудительное использование HTTPS.

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

Мы рекомендуем выполнять аутентификацию при помощи поставщика удостоверений, например Azure AD, Facebook, Google или Twitter. Используйте в потоке аутентификации маркеры OAuth 2 или OpenID Connect (OIDC). Azure AD предоставляет функциональные возможности для управления пользователями и группами, создания ролей приложений, интеграции локальных удостоверений и использования серверных служб, таких как Microsoft 365 и Skype для бизнеса.

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

Чтобы реализовать поток аутентификации с использованием OAuth или OIDC, рекомендуем применить аутентификацию службы приложений. Аутентификация службы приложений дает следующие преимущества:

  • Простота настройки.
  • Вам не нужно писать код для сценариев аутентификации.
  • Поддержка делегированной авторизации с помощью маркеров доступа OAuth для использования ресурсов от имени пользователя.
  • Встроенные кэши маркеров.

Аутентификация службы приложений имеет и ряд ограничений:

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