Azure Spring Apps, интегрированный с целевыми зонами

Эта эталонная архитектура развертывает базовую архитектуру Azure Spring Apps в целевых зонах Azure.

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

Варианты проектирования, сделанные в этой архитектуре, рассматриваются в ключевых технических областях проектирования для этого акселератора. Дополнительные сведения см . в акселераторе целевой зоны Azure Spring Apps.

Архитектура

На следующей схеме показана архитектура для этого подхода:

Типичные способы использования этой архитектуры:

• Частные приложения: внутренние приложения, развернутые в гибридных облачных средах.
• Общедоступные приложения: внешние приложения.

Эти варианты использования аналогичны, за исключением конфигурации правил безопасности и сетевого трафика.

Компоненты

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

Ресурсы группы приложений

Ваша команда отвечает за создание и обслуживание следующих ресурсов.

• Azure Spring Apps Standard размещает приложения Java Spring Boot в Azure.

• Шлюз приложений Azure Standard_v2 — обратный прокси-сервер, который направляет входящий веб-трафик в Azure Spring Apps. Этот номер SKU интегрирован Брандмауэр веб-приложений Azure, который проверяет трафик для уязвимостей Open Web Application Security Project (OWASP).

• Azure Виртуальные машины выступает в качестве поля перехода для операций управления.

• База данных Azure для MySQL хранит данные приложения.

• Azure Key Vault хранит секреты и конфигурацию, например строка подключения в базу данных.

• Log Analytics — это функция Azure Monitor, которая также называется журналами Azure Monitor. Log Analytics — это приемник мониторинга, который хранит журналы и метрики из приложения и служб Azure.

• приложение Azure Аналитика используется в качестве средства управления производительностью приложений (APM) для сбора всех данных мониторинга приложений и хранения его непосредственно в Log Analytics.

Ресурсы, принадлежащие команде платформы

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

• Брандмауэр Azure проверяет и ограничивает исходящий трафик.

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

• Azure ExpressRoute обеспечивает частное подключение из локальной среды к инфраструктуре Azure.

• Azure DNS предоставляет разрешение локальных имен.

• Azure VPN-шлюз подключает приложение к удаленным командам в локальной сети.

Рекомендации по приложению

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

Обнаружение служб

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

Службы должны иметь возможность взаимодействовать с другими службами. При создании новых экземпляров они добавляются в реестр, чтобы их можно было динамически обнаруживать. В этой архитектуре реестр управляемых служб Spring Cloud (OSS) включен для Azure Spring Apps. Эта служба поддерживает реестр динамических экземпляров приложений, обеспечивает балансировку нагрузки на стороне клиента и отделяет поставщиков служб от клиентов без использования службы доменных имен (DNS).

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

Сервер конфигурации

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

Избыточность

При создании экземпляра Azure Spring Apps можно использовать зоны доступности.

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

Избыточность зоны гарантирует, что базовые узлы виртуальной машины распределяются равномерно по всем зонам доступности. Однако избыточность зоны не гарантирует даже распределение экземпляров приложений. Если экземпляр приложения завершается сбоем, так как его расположенная зона отключена, Azure Spring Apps создает новый экземпляр приложения для этого приложения на узле в другой зоне доступности.

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

Зоны доступности не поддерживаются во всех регионах. Сведения о том, какие регионы поддерживают зоны доступности, см. в регионах Azure с поддержкой зон доступности.

Масштабируемость

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

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

Рекомендации по работе с сетями

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

Топология сети

Команда платформы определяет топологию сети. В этой архитектуре предполагается звездообразная топология.

Центральная виртуальная сеть.

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

• Брандмауэр Azure управляет исходящим трафиком в Интернет.
• Бастион Azure защищает доступ к коробке перехода управления.

Периферийная виртуальная сеть

Целевая зона приложения имеет по крайней мере одну предварительно подготовленную виртуальную сеть, которая выполняет пиринг в центральной сети. Вы владеете ресурсами в этой сети, например подсистемой балансировки нагрузки, которая направляет и защищает входящий трафик HTTP/s к Azure Spring Apps из Интернета.

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

Внедрение и подсеть виртуальной сети

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

Изоляция достигается с помощью подсетей. Вы несете ответственность за выделение подсетей в периферийной виртуальной сети. Azure Spring Apps требует двух выделенных подсетей для среды выполнения службы и для приложений Java Spring Boot.

Подсети должны быть выделены для одного экземпляра Azure Spring Apps. Несколько экземпляров не могут совместно использовать одни и те же подсети.

Минимальный размер каждой подсети — /28. Фактический размер зависит от количества экземпляров приложений, которые может поддерживать Azure Spring Apps. Дополнительные сведения см. в разделе "Использование небольших диапазонов подсети".

Элементы управления сетью

Шлюз приложений Azure с Брандмауэр веб-приложений ограничивает входящий трафик к периферийной виртуальной сети из Интернета. Брандмауэр веб-приложений правила разрешают или запрещают подключения HTTP/s.

Трафик в сети управляется с помощью групп безопасности сети (NSG) в подсетях. Группы безопасности сети фильтруют трафик в соответствии с настроенными IP-адресами и портами. В этой структуре группы безопасности сети размещаются во всех подсетях. Подсеть Бастиона Azure разрешает трафик HTTPS из Интернета, служб шлюза, подсистем балансировки нагрузки и виртуальной сети. Из подсети разрешено только подключение RDP и SSH к виртуальным сетям.

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

Записи DNS узла приложения должны храниться в Azure Частная зона DNS, чтобы обеспечить постоянную доступность во время географического сбоя.

Хотя подписка на подключение имеет частные зоны DNS, создайте собственные зоны Azure Частная зона DNS для поддержки служб, к которым обращаются частные конечные точки.

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

Управление удостоверениями и доступом

Реализация удостоверений рабочей нагрузки должна соответствовать рекомендациям организации, чтобы гарантировать, что приложение не нарушает границы безопасности организации или управления. Дополнительные сведения см. в акселераторе целевой зоны Azure Spring Apps: управление удостоверениями и доступом.

Идентификатор Microsoft Entra рекомендуется для проверки подлинности пользователей и служб, взаимодействующих с экземпляром Azure Spring Apps.

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

Для авторизации используйте контроль доступа на основе ролей Azure (RBAC), применяя принцип наименьших привилегий при предоставлении разрешений.

Рекомендации по мониторингу

Платформа целевой зоны Azure предоставляет общие ресурсы наблюдения в рамках подписок управления. Однако подготовка собственных ресурсов мониторинга рекомендуется упростить общее управление рабочей нагрузкой. Дополнительные сведения см. в акселераторе целевой зоны Azure Spring Apps: мониторинг операций.

Эта архитектура создает следующие ресурсы:

• приложение Azure Аналитика — это решение Монитор производительности приложений (APM) и полностью интегрировано в службу через агент Java. Этот агент обеспечивает видимость всех развернутых приложений и зависимостей, не требуя дополнительного кода.
• Рабочая область Azure Log Analytics — это единый приемник для всех журналов и метрик, собранных из служб Azure и приложения.

Настройте экземпляр Azure Spring Apps для отправки диагностика журналов из приложения в подготовленную рабочую область Log Analytics. Дополнительные сведения см. в разделе "Мониторинг приложений" в комплексном режиме.

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

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

Корреляция данных из нескольких рабочих областей

Журналы и метрики, созданные рабочей нагрузкой и ее компонентами инфраструктуры, сохраняются в рабочей области Log Analytics рабочей нагрузки. Однако журналы и метрики, созданные централизованным службами, такими как Active Directory и Брандмауэр Azure, сохраняются в центральной рабочей области Log Analytics, управляемой командами платформ. Корреляция данных из разных приемников может привести к сложностям.

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

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

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

Зонды работоспособности

Шлюз приложений Azure использует пробы работоспособности, чтобы обеспечить маршрутизацию входящего трафика на адаптивные экземпляры серверной части. Рекомендуется использовать пробы готовности, liveness и запуска Azure Spring Apps. Если произошел сбой, эти пробы могут помочь в корректном завершении. Дополнительные сведения см. в разделе "Настройка проб работоспособности".

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

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

Неактивные данные

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

Передаваемые данные

Передаваемые данные тоже должны быть зашифрованы. Трафик между браузером пользователя и Шлюз приложений Azure должен быть зашифрован, чтобы гарантировать, что данные остаются неизменными во время передачи. В этой архитектуре Шлюз приложений Azure принимает только трафик HTTPS и согласовывает подтверждение TLS. Эта проверка применяется с помощью правил NSG в подсети Шлюз приложений. Сертификат TLS загружается непосредственно во время развертывания.

Трафик из Шлюз приложений в экземпляр Azure Spring Apps повторно шифруется, чтобы обеспечить доступ только к безопасному трафику приложения. Среда выполнения службы Azure Spring Apps получает этот трафик и выступает в качестве точки завершения TLS. С этого момента взаимодействие между службами в приложении не шифруется. Однако обмен данными с другими службами Azure PaaS и средой выполнения службы происходит по протоколу TLS.

Вы можете реализовать сквозное взаимодействие TLS через Azure Spring Apps. Рассмотрите возможные компромиссы. Может быть негативное влияние на задержку и операции.

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

Защита от атак DDoS

Распределенный отказ в обслуживании (DDoS) может отменить систему, перезагрузив ее запросами. Базовая защита от атак DDoS включена на уровне инфраструктуры для всех служб Azure для защиты от таких атак. Рассмотрите возможность обновления до службы защиты от атак DDoS Azure, чтобы воспользоваться такими функциями, как мониторинг, оповещения, возможность задать пороговые значения для приложения. Дополнительные сведения см. в статье "Служба защиты от атак DDoS Azure" с часто задаваемыми вопросами.

Управление секретами

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

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

• Сертификаты загружаются во время развертывания.
• Подключение к MySQL реализуется с помощью службы Подключение or.

Стратегии оптимизации затрат

Современные распределенные системы выстроены таким образом, что инфраструктура непрерывно растет. Это приводит к непредвиденным и неконтролируемым расходам. Azure Spring Apps создается с помощью компонентов, масштабируемых для удовлетворения спроса и оптимизации затрат. Основой этой архитектуры является Служба Azure Kubernetes (AKS). Служба предназначена для снижения сложности и эксплуатационных расходов на управление Kubernetes и включает эффективность в операционных затратах кластера.

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

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

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

Развертывание для этой эталонной архитектуры доступно в Акселераторе целевой зоны Azure Spring Apps на GitHub. В развертывании используются шаблоны Terraform.

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

Чтобы развернуть архитектуру, выполните пошаговые инструкции.

Поддержка VMware с уровнем Enterprise

Если требуется поддержка управляемого VMware Tanzu® для динамического развертывания, рассмотрите возможность обновления до уровня Azure Spring Apps Enterprise. Реестр служб VMware Tanzu® интегрирован для Azure Spring Apps, который позволяет обнаруживать службы и зарегистрировать их.

Для маршрутизации шлюза можно переключиться на VMware Spring Cloud Gateway. Он предлагает набор функций, включающий проверку подлинности и авторизацию, функции устойчивости и ограничение скорости.

На уровне Enterprise служба конфигурации приложений для Tanzu® позволяет управлять ресурсами ConfigMap на основе Kubernetes, которые заполняются свойствами, определенными в одном или нескольких репозиториях Git.

На этом уровне поддерживаются другие службы VMware. Дополнительные сведения см . на уровне Enterprise в Azure Marketplace.

Эталонная реализация поддерживает SKU Azure Spring Apps Enterprise в качестве варианта развертывания. В этом параметре существуют некоторые изменения архитектуры. Он использует экземпляр гибкого сервера База данных Azure для PostgreSQL, развернутого с помощью интеграции виртуальная сеть Azure и Кэш Azure для Redis с частной конечной точкой. Пример приложения — приложение Fitness Store.

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

• Просмотрите области проектирования акселератора целевой зоны Azure Spring Apps.

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

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

• Azure Spring Apps Enterprise
• Шлюз приложений Azure версии 2
• База данных Azure для MySQL
• Azure Key Vault
• Виртуальная сеть Azure
• Таблицы маршрутов

Другие сценарии реализации см. в следующих статьях:

• Развертывание Azure Spring Apps в нескольких регионах
• Предоставление доступа к Azure Spring Apps через обратный прокси-сервер