Эта эталонная архитектура демонстрирует общую корпоративную рабочую нагрузку, которая использует Среда службы приложений версии 3. В нем также описываются рекомендации по укреплению безопасности рабочей нагрузки.
Примечание.
Среда службы приложений версии 3 является основным компонентом этой архитектуры. Теперь доступна версия 3. Версии 1 и 2 будут прекращены 31 августа 2024 г.
Эталонная реализация этой архитектуры доступна на сайте GitHub.
Архитектура
Скачайте файл Visio для этой архитектуры.
Workflow
Среда службы приложений версии 3 предоставляет различные функции, отличные от предыдущих версий, и преимущества по сравнению с этими версиями. Дополнительные сведения см. в разделе "Различия функций". Вы можете развернуть Среда службы приложений двумя способами:
- Как внешний Среда службы приложений с общедоступным IP-адресом
- Как внутренняя Среда службы приложений с внутренним IP-адресом, который принадлежит внутренней подсистеме балансировки нагрузки (ILB)
Эта эталонная архитектура развертывает корпоративное веб-приложение в внутренней Среда службы приложений, а также называется Среда службы приложений ILB. Используйте Среда службы приложений балансировки нагрузки, если вам потребуется выполнить следующие действия.
- Размещение приложений интрасети с повышенной безопасностью в облаке и доступ к ним через VPN типа "сеть — сеть" или Azure ExpressRoute.
- Предоставьте уровень защиты для приложений с помощью брандмауэра веб-приложения (WAF).
- Размещение в облаке приложений, которые не указаны на общедоступных DNS-серверах.
- Создайте приложения, изолированные от Интернета, которые интерфейсные приложения могут интегрироваться с высокобезопасным способом.
Среда службы приложений необходимо всегда развертывать в собственной подсети в корпоративной виртуальной сети, чтобы обеспечить жесткий контроль над входящим и исходящим трафиком. В этой подсети Служба приложений приложения развертываются в одном или нескольких планах Служба приложений, что является коллекцией физических ресурсов, необходимых для запуска приложения. В зависимости от сложности и требования к ресурсам Служба приложений план можно совместно использовать между несколькими приложениями. Эта эталонная реализация развертывает веб-приложение с именем Voting App, которое взаимодействует с частным веб-API и функцией. Он также развертывает фиктивное веб-приложение с именем Test App для демонстрации развертываний с несколькими приложениями. Каждое приложение Служба приложений размещается в собственном плане Служба приложений, что позволяет масштабировать каждый из них независимо при необходимости. Все ресурсы, необходимые для этих размещенных приложений, таких как хранилище и вычисления, а также потребности масштабирования полностью управляются инфраструктурой Среда службы приложений.
Простое приложение для голосования в этой реализации позволяет пользователям просматривать существующие записи, создавать новые записи и голосовать за существующие записи. Веб-API используется для создания и получения записей и голосов. Сами данные хранятся в базе данных SQL Server. Чтобы продемонстрировать асинхронные обновления данных, веб-приложение очереди вновь добавленных голосов в служебная шина экземпляре. Функция выбирает очереди голосов и обновляет базу данных SQL. Azure Cosmos DB используется для хранения макетной рекламы, которую веб-приложение извлекает для отображения в браузере. Приложение использует Кэш Azure для Redis для управления кэшем. Используется Кэш Azure для Redis уровня "Премиум", который позволяет настроить ту же виртуальную сеть, что и Среда службы приложений, в собственной подсети. Это обеспечивает повышенную безопасность и изоляцию к кэшу.
Веб-приложения являются единственными компонентами, доступными для Интернета через Шлюз приложений. API и функция недоступны из интернет-клиента. Входящий трафик защищен WAF, настроенным на Шлюз приложений.
Компоненты
Следующие службы являются ключевыми для блокировки Среда службы приложений в этой архитектуре:
Azure виртуальная сеть — это частная облачная сеть Azure, принадлежающая предприятиям. Она обеспечивает расширенную сетевую безопасность и изоляцию. Среда службы приложений — это развертывание Служба приложений в подсети корпоративной виртуальной сети. Он позволяет предприятиям жестко контролировать сетевое пространство и ресурсы, к которым он обращается, с помощью групп безопасности сети и частных конечных точек.
Шлюз приложений — это подсистема балансировки нагрузки веб-трафика на уровне приложения с разгрузкой TLS/SSL и WAF. Он прослушивает общедоступный IP-адрес и направляет трафик в конечную точку приложения в Среда службы приложений балансировки нагрузки. Так как это маршрутизация на уровне приложения, она может направлять трафик в несколько приложений в одном Среда службы приложений балансировки нагрузки. Дополнительные сведения см. в разделе Хостинг нескольких сайтов на шлюзе приложений.
Брандмауэр Azure используется для ограничения исходящего трафика из веб-приложения. Исходящий трафик, который не проходит через каналы частной конечной точки и таблицу маршрутов, необходимую Среда службы приложений, направляется в подсеть брандмауэра. Для простоты эта архитектура настраивает все частные конечные точки в подсети служб.
Идентификатор Microsoft Entra или Идентификатор Microsoft Entra предоставляет права доступа и разрешения для ресурсов и служб Azure. Управляемые удостоверения назначают удостоверения службам и приложениям, автоматически управляемым идентификатором Microsoft Entra. Эти удостоверения можно использовать для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra. Это удаляет необходимость явной настройки учетных данных для этих приложений. Эта архитектура назначает управляемое удостоверение веб-приложению.
Azure Key Vault хранит все секреты и учетные данные, необходимые приложениям. Используйте этот параметр для хранения секретов непосредственно в приложении.
GitHub Actions предоставляет возможности непрерывной интеграции и непрерывного развертывания в этой архитектуре. Так как Среда службы приложений находится в виртуальной сети, виртуальная машина используется в качестве прыжка в виртуальной сети для развертывания приложений в планах Служба приложений. Действие создает приложения за пределами виртуальной сети. Для повышения безопасности и простого подключения RDP/SSH рекомендуется использовать Бастион Azure для прыжков.
Конфигурация с несколькими сайтами
Скачайте файл Visio для этой архитектуры.
Внутренние Среда службы приложений могут размещать несколько веб-приложений и API с конечными точками HTTP. Эти приложения заблокированы из общедоступного Интернета, так как IP-адрес подсистемы балансировки нагрузки доступен только в виртуальная сеть. Шлюз приложений используется для выборочного предоставления этих приложений в Интернете. Среда службы приложений назначает URL-адрес по умолчанию каждому приложению Служба приложений как <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Создается частная зона DNS, которая сопоставляет доменное имя Среда службы приложений с IP-адресом Среда службы приложений ILB. Это позволяет избежать использования пользовательского DNS для доступа к приложениям в виртуальной сети.
Шлюз приложений настроен таким образом, чтобы прослушиватель прослушивал порт HTTPS для запросов к IP-адресу шлюза. Для простоты эта реализация не использует регистрацию общедоступного DNS-имени. Для этого необходимо изменить файл localhost на компьютере, чтобы указать произвольно выбранный URL-адрес на IP-адрес Шлюз приложений. Для простоты прослушиватель использует самозаверяющий сертификат для обработки этих запросов. Шлюз приложений имеет серверные пулы для каждого URL-адреса Служба приложений приложения по умолчанию. Правило маршрутизации настроено для подключения прослушивателя к внутреннему пулу. Параметры HTTP создаются, определяющие, будет ли зашифровано подключение между шлюзом и Среда службы приложений. Эти параметры также используются для переопределения входящего заголовка узла HTTP с именем узла, выбранным из внутреннего пула. Эта реализация использует сертификаты по умолчанию, созданные для URL-адресов приложений по умолчанию Среда службы приложений, доверенных шлюзом. Запрос перенаправляется по умолчанию на URL-адрес соответствующего приложения. Частный DNS, связанный с виртуальной сетью , перенаправит этот запрос на IP-адрес ILB. Среда службы приложений затем перенаправит это в запрошенную службу приложений. Любой http-обмен данными в Среда службы приложений приложениях проходит через частный DNS. Обратите внимание, что прослушиватель, серверный пул, правило маршрутизации и параметры HTTP должны быть настроены на шлюзе приложений для каждого приложения Среда службы приложений.
Просмотрите appgw.bicep и dns.bicep, чтобы узнать, как эти конфигурации создаются для разрешения нескольких сайтов. Имя веб-приложения — это пустое приложение testapp , созданное для демонстрации этой конфигурации. Доступ к этим файлам JSON выполняется из скрипта развертывания commands_std.azcli. К этим данным также обращается commands_ha.azcli, который используется для развертывания с высоким уровнем доступности Среда службы приложений.
Подробности сценария
служба приложение Azure — это служба PaaS, используемая для размещения различных приложений в Azure: веб-приложения, приложения API, функции и мобильные приложения. Среда службы приложений позволяет предприятиям развертывать свои приложения Служба приложений в подсети в собственной виртуальная сеть Azure, предоставляя изолированную, высокомасштабируемую и выделенную среду для облачных рабочих нагрузок.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
Среда службы приложений
Внутренняя Среда службы приложений развертывается в корпоративной виртуальной сети, скрытой из общедоступного Интернета. Он позволяет предприятиям блокировать внутренние службы, такие как веб-API и функции, на уровне сети. Доступ к любому Среда службы приложений приложению с конечной точкой HTTP можно получить через ILB из виртуальной сети. Шлюз приложений настроен для пересылки запросов в веб-приложение через ILB. Веб-приложение проходит через подсистему балансировки нагрузки для доступа к API. Критически важные внутренние компоненты, то есть API и функция, фактически недоступны из общедоступного Интернета.
Сертификаты по умолчанию создаются для каждой службы приложений для имени домена по умолчанию, назначенного Среда службы приложений. Этот сертификат может ужесточить безопасность трафика между шлюзом и приложением и может потребоваться в определенных сценариях. Эти сертификаты не отображаются через клиентский браузер. Он может реагировать только на сертификаты, настроенные на Шлюз приложений.
Шлюз приложений
Эталонная реализация настраивает Шлюз приложений программным способом в appgw.bicep. Файл commands_std.azcli использует эту конфигурацию при развертывании шлюза:
az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)
Шифрование
Как описано в обзоре завершения TLS и завершения tls с помощью Шлюз приложений, Шлюз приложений может использовать протокол TLS/SSL для шифрования и защиты всего трафика от веб-браузеров. Шифрование можно настроить следующим образом:
Шифрование завершается на шлюзе. Серверные пулы в этом случае настроены для HTTP. Шифрование останавливается на шлюзе, а трафик между шлюзом и службой приложений незашифровывается. Так как шифрование является интенсивным для ЦП, незашифрованный трафик на серверной части повышает производительность и позволяет упростить управление сертификатами. Это обеспечивает разумный уровень безопасности, так как серверная часть защищена в силу конфигурации сети.
Сквозное шифрование. В некоторых сценариях, таких как определенные требования к безопасности или соответствию, трафик может потребоваться для шифрования между шлюзом и приложением. Это достигается с помощью подключения HTTPS и настройки сертификатов во внутреннем пуле.
Эта эталонная реализация использует самозаверяемые сертификаты для Шлюз приложений. Для рабочего кода следует использовать сертификат, выданный центром сертификации. Список поддерживаемых типов сертификатов см. в разделе "Сертификаты", поддерживаемые для завершения TLS. Прочитайте статью "Настройка шлюза приложений с завершением TLS" с помощью портал Azure, чтобы узнать, как создать шифрование, завершающееся шлюзом. Следующие строки кода в appgw.bicep настраивают это программным образом:
httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
frontendIPConfiguration: {
id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
}
frontendPort: {
id: '${appgwId}/frontendPorts/port_443'
}
protocol: 'Https'
sslCertificate: {
id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
}
hostName: item.hostName
requireServerNameIndication: true
}
}]
Эталонная реализация демонстрирует сквозное шифрование трафика между Шлюз приложений и веб-приложениями в Среда службы приложений. Используются SSL-сертификаты по умолчанию. Серверные пулы в этой реализации настроены для перенаправления трафика HTTPS с переопределенным именем узла по умолчанию доменными именами, связанными с веб-приложениями. Шлюз приложений доверяет SSL-сертификатам по умолчанию, так как они выданы корпорацией Майкрософт. Сведения о том, как эти конфигурации создаются, см. в разделе "Настройка Служба приложений с помощью Шлюз приложений". Следующий код из appgw.bicep показывает, как это настроено в эталонной реализации:
backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
port: 443
protocol: 'Https'
cookieBasedAffinity: 'Disabled'
pickHostNameFromBackendAddress: true
requestTimeout: 20
probe: {
id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
}
}
}]
Брандмауэр веб-приложений
Брандмауэр веб-приложений (WAF) на Шлюз приложений защищает веб-приложения от вредоносных атак, таких как внедрение SQL. Он также интегрирован с Azure Monitor для мониторинга атак с помощью журнала в режиме реального времени. WaF необходимо включить в шлюзе, как описано в разделе "Создание шлюза приложений с Брандмауэр веб-приложений с помощью портал Azure". Эталонная реализация включает WAF программным способом в файле appgw.bicep со следующим фрагментом кода:
webApplicationFirewallConfiguration: {
enabled: true
firewallMode: 'Detection'
ruleSetType: 'OWASP'
ruleSetVersion: '3.0'
}
Виртуальная сеть
Группы безопасности сети могут быть связаны с одной или несколькими подсетями в виртуальной сети. Это правила безопасности, которые позволяют или запрещают поток трафика между различными ресурсами Azure. Эта архитектура связывает отдельную группу безопасности сети для каждой подсети. Это позволяет точно настроить эти правила для каждой подсети в зависимости от служб, содержащихся в этой подсети. Например, см. конфигурацию "type": "Microsoft.Network/networkSecurityGroups" в файле ase.bicep для группы безопасности сети для подсети Среда службы приложений и в файле appgw.bicep для группы безопасности сети для подсети Шлюз приложений.
Частные конечные точки обеспечивают расширенное частное подключение между клиентами и службами Azure через частную сеть. Они предоставляют частный IP-адрес службы Azure, что позволяет повысить безопасность трафика к ресурсу Приватный канал Azure. Платформа проверяет сетевые подключения, разрешая только те, которые подключаются к указанному ресурсу Приватный канал. Частные конечные точки поддерживают политики сети, такие как группы безопасности сети, определяемые пользователем маршруты и группы безопасности приложений. Чтобы повысить безопасность, следует включить частные конечные точки для любой службы Azure, поддерживающей их. Затем вы можете улучшить безопасность службы в виртуальной сети, отключив общедоступный доступ, эффективно блокируя доступ из общедоступного Интернета. Эта архитектура настраивает частные конечные точки для служб, поддерживающих ее: Служебная шина Azure, SQL Server, Key Vault и Azure Cosmos DB. Конфигурацию можно просмотреть в privatendpoints.bicep.
Чтобы включить частные конечные точки, необходимо также настроить частные зоны DNS. Дополнительные сведения см. в статье Конфигурация DNS для частной конечной точки Azure.
Брандмауэр
Брандмауэр Azure и частные конечные точки дополняют друг друга. Частные конечные точки помогают защитить ресурсы, разрешая только трафик, исходящий из виртуальной сети. Брандмауэр Azure позволяет ограничить исходящий трафик из приложений. Рекомендуется разрешить всем исходящим трафику передаваться через подсеть брандмауэра, включая трафик частной конечной точки. Это позволяет лучше отслеживать исходящий трафик. Для простоты эта эталонная архитектура настраивает все частные конечные точки в подсети служб вместо подсети брандмауэра.
Сведения о том, как Брандмауэр Azure интегрируются с Среда службы приложений, см. в статье "Настройка Брандмауэр Azure с Среда службы приложений". Любой трафик, который не проходит через частные конечные точки и таблицу маршрутов виртуальной сети, отслеживается и блокируется брандмауэром.
Microsoft Entra ID
Идентификатор Microsoft Entra предоставляет функции безопасности для проверки подлинности приложений и авторизации доступа к ресурсам. Эта эталонная архитектура использует два ключевых компонента идентификатора Microsoft Entra: управляемые удостоверения и управление доступом на основе ролей Azure.
В облачных приложениях учетные данные, необходимые для проверки подлинности в облачных службах, должны быть защищены. В идеале учетные данные никогда не должны отображаться на рабочих станциях разработчика или проверка в управление версиями. Azure Key Vault предоставляет способ безопасного хранения учетных данных и секретов, но приложению по-прежнему нужно пройти проверку подлинности в Key Vault, чтобы получить их. Управляемые удостоверения для ресурсов Azure предоставляют службы Azure с автоматически управляемым удостоверением в идентификаторе Microsoft Entra. Это удостоверение можно использовать для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra, включая Key Vault, без каких-либо учетных данных в приложении.
Управление доступом на основе ролей Azure (Azure RBAC) управляет доступом к ресурсам Azure. В том числе:
- Какая сущность имеет доступ: пользователь, управляемое удостоверение, субъект безопасности.
- Какой тип доступа у него есть: владелец, участник, читатель, администратор.
- Область доступа: ресурс, группа ресурсов, подписка или группа управления.
Вы можете заблокировать доступ к Среда службы приложений приложениям, строго контролируя необходимую роль и тип доступа для каждого приложения. Таким образом, несколько приложений можно развернуть в одной Среда службы приложений из разных команд разработки. Например, внешний интерфейс может обрабатываться одной командой, а серверная часть — другой. Azure RBAC можно использовать для ограничения доступа каждой команды к приложениям, над которыми он работает. Изучите настраиваемые роли Azure для создания ролей , подходящих для вашей организации.
Key Vault
Некоторые службы поддерживают управляемые удостоверения, но используйте Azure RBAC для настройки разрешений для приложения. Например, см. встроенные роли служебная шина и Azure RBAC в Azure Cosmos DB. Доступ владельца к подписке необходим для предоставления этих разрешений, даже если персонал с доступом участника может развернуть эти службы. Чтобы позволить более широкой группе разработчиков выполнять скрипты развертывания, следующим лучшим вариантом является использование собственных политик управления доступом службы:
- Для служебная шина это подписанные URL-адреса.
- Для Azure Cosmos DB это ключи.
Затем строка подключения для этих политик управления доступом хранятся в Key Vault. Доступ к хранилищу осуществляется с помощью управляемых удостоверений, для которых требуется Azure RBAC. Задайте политику доступа для этих строка подключения соответствующим образом. Например, только для чтения для серверной части, только для записи для внешнего интерфейса и т. д. вместо использования политики корневого доступа по умолчанию.
Следующий код в services.bicep показывает конфигурацию Key Vault для этих служб:
resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
parent: keyVaultName
name: 'CosmosKey'
properties: {
value: cosmosName.listKeys().primaryMasterKey
}
}
resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
parent: keyVaultName
name: 'ServiceBusListenerConnectionString'
properties: {
value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
}
}
resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
parent: keyVaultName
name: 'ServiceBusSenderConnectionString'
properties: {
value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
}
}
Эти строка подключения значения получают доступ к приложениям, которые ссылаются на пару ключей и значений Key Vault. Это делается в файле sites.bicep , как показано в следующем коде для приложения голосования:
properties: {
enabled: true
hostingEnvironmentProfile: {
id:aseId
}
serverFarmId: votingWebPlanName.id
siteConfig: {
appSettings: [
{
name: 'ConnectionStrings:sbConnectionString'
value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
}
{
name: 'ConnectionStrings:RedisConnectionString'
value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
}
{
name: 'ConnectionStrings:CosmosKey'
value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
}
]
}
}
Функция также обращается к служебная шина прослушивателю строка подключения аналогичным образом.
Масштабируемость
Разработка масштабируемых приложений
Приложение в этой эталонной архитектуре структурировано таким образом, чтобы отдельные компоненты можно масштабировать на основе использования. Каждое веб-приложение, API и функция развертываются в собственном Служба приложений плане. Вы можете отслеживать каждое приложение для любых узких мест производительности, а затем масштабировать его при необходимости.
Автомасштабирование Шлюз приложений
Автомасштабирование можно включить в Шлюз приложений Azure версии 2. Это позволяет Шлюз приложений увеличивать или уменьшать масштаб на основе шаблонов нагрузки трафика. Эта эталонная архитектура настраивает autoscaleConfiguration в файле appgw.bicep масштабирование между нулевым и 10 дополнительными экземплярами. Дополнительные сведения см. в статье о масштабировании Шлюз приложений и WAF версии 2.
Развертывание
Скрипты развертывания в этой эталонной архитектуре используются для развертывания Среда службы приложений, других служб и приложений в Среда службы приложений. После развертывания этих приложений предприятиям может потребоваться план непрерывной интеграции и развертывания для обслуживания и обновления приложений. В этом разделе показаны некоторые распространенные способы использования разработчиков для CI/CD Среда службы приложений приложений.
Приложения можно развертывать в внутренней Среда службы приложений только из виртуальной сети. Для развертывания Среда службы приложений приложений широко используются следующие три метода:
Вручную в виртуальная сеть. Создайте виртуальную машину внутри виртуальной сети Среда службы приложений с необходимыми средствами для развертывания. Откройте подключение RDP к виртуальной машине с помощью конфигурации NSG. Скопируйте артефакты кода на виртуальную машину, сборку и развертывание в подсети Среда службы приложений. Это простой способ настройки начальной среды разработки и тестирования. Однако не рекомендуется использовать рабочую среду, так как она не может масштабировать требуемую пропускную способность развертывания.
Подключение к сайту с локальной рабочей станции. Это позволяет расширить Среда службы приложений виртуальную сеть на компьютере разработки и развернуть его. Это еще один способ настройки начальной среды разработки и не рекомендуется для рабочей среды.
С помощью Azure Pipelines: это реализует полный конвейер CI/CD, заканчивающийся агентом, расположенным в виртуальной сети. Это идеально подходит для рабочих сред, требующих высокой пропускной способности развертывания. Конвейер сборки остается полностью вне виртуальной сети. Конвейер развертывания копирует встроенные объекты в агент сборки в виртуальной сети, а затем развертывается в подсети Среда службы приложений. Дополнительные сведения см. в этом обсуждении о локальном агенте сборки между конвейерами и виртуальной сетью Среда службы приложений.
Использование Azure Pipelines рекомендуется для рабочих сред. Скриптирование CI/CD с помощью схемы YAML Azure Pipelines помогает автоматизировать процессы сборки и развертывания. Azure-pipelines.yml реализует такой конвейер CI/CD для веб-приложения в этой эталонной реализации. Существуют аналогичные скрипты CI/CD для веб-API , а также функции. Ознакомьтесь с помощью Azure Pipelines , чтобы узнать, как они используются для автоматизации CI/CD для каждого приложения.
Некоторые предприятия могут не поддерживать агент постоянной сборки в виртуальной сети. В этом случае можно создать агент сборки в конвейере DevOps и разорвать его после завершения развертывания. Это добавляет еще один шаг в DevOps, однако снижает сложность обслуживания виртуальной машины. Вы даже можете использовать контейнеры в качестве агентов сборки вместо виртуальных машин. Агенты сборки также могут быть полностью избегаем, развертывая из zip-файла, размещенного за пределами виртуальной сети, как правило, в учетной записи хранения. Учетная запись хранения должна быть доступна из Среда службы приложений. Конвейер должен иметь доступ к хранилищу. В конце конвейера выпуска zippped-файл можно удалить в хранилище BLOB-объектов. Затем Среда службы приложений может забрать и развернуть его. Помните о следующих ограничениях этого подхода:
- Существует отключение между DevOps и фактическим процессом развертывания, что приводит к трудностям в мониторинге и трассировке любых проблем развертывания.
- В заблокированной среде с защищенным трафиком может потребоваться изменить правила для доступа к zippped-файлу в хранилище.
- Вам потребуется установить определенные расширения и средства на Среда службы приложений, чтобы иметь возможность развертывания из ZIP-файла.
Чтобы узнать больше способов развертывания приложений в планах Служба приложений, ознакомьтесь со статьями Служба приложений, посвященными стратегиям развертывания.
Оптимизация затрат
Для оценки затрат используйте калькулятор цен Azure. Другие рекомендации описаны в разделе "Затраты" в Microsoft Azure Well-Architected Framework. Резервирования Azure помогают сэкономить средства за счет приобретения планов сроком на один или три года для многих ресурсов Azure. Дополнительные сведения см. в статье "Покупка резервирования".
Ниже приведены некоторые моменты, которые следует учитывать для некоторых ключевых служб, используемых в этой архитектуре.
Среда службы приложений, версия 3
Доступны различные варианты ценообразования для Служба приложений. Среда службы приложений развертывается с помощью плана изолированной службы версии 2. В рамках этого плана существует несколько вариантов размера ЦП от I1v2 до I6v2. Эта эталонная реализация использует три I1v2s на экземпляр.
Шлюз приложений
Шлюз приложений цены предоставляют различные варианты ценообразования. Эта реализация использует номер SKU Шлюз приложений Standard версии 2 и WAF версии 2, который поддерживает автомасштабирование и избыточность зоны. Дополнительные сведения о модели ценообразования, используемой для этого номера SKU, см. в статье Масштабирование Шлюз приложений версии 2 и WAF версии 2.
Кэш Azure для Redis
Кэш Azure для Redis цены предоставляют различные варианты ценообразования для этой службы. Эта архитектура использует номер SKU класса Premium для поддержки виртуальной сети.
Ниже приведены страницы цен для других служб, которые используются для блокировки Среда службы приложений:
Развертывание этого сценария
Чтобы развернуть эталонную реализацию для этой архитектуры, ознакомьтесь с GitHub readme и следуйте скрипту стандартного развертывания.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Dhanashri Kshirsagar | Старший pm содержимого
Другие участник:
- Deep Bhattacharya | Архитектор облачных решений
- Сухас Рао | Архитектор облачных решений
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Запуск приложения в службе приложение Azure непосредственно из ZIP-пакета
- Схема YAML Azure Pipelines
- Получение адресов управления из API
- Azure Key Vault
- Azure Pipelines
Связанные ресурсы
Чтобы узнать, как расширить эту архитектуру для поддержки высокой доступности, ознакомьтесь с развертыванием приложений с высоким уровнем доступности с помощью среды Служба приложений s.