Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Теперь, когда у вас есть лучшее представление о различиях платформ между AWS и Azure, давайте рассмотрим архитектуру веб-приложений в AWS и изменения, необходимые для обеспечения его совместимости со службой Azure Kubernetes (AKS).
Архитектура приложения Yelb
Пример веб-приложения Yelb состоит из фронтэнд-компонента, именуемого yelb-ui
, и компонента приложения, именуемого yelb-appserver
.
yelb-ui
передает JavaScript-код браузеру. Этот код компилируется из приложения Angular . Компонент yelb-ui
также может включать nginx
прокси-сервер в зависимости от модели развертывания. Это yelb-appserver
приложение Sinatra , взаимодействующее с сервером кэша (redis-server
) и серверной базой данных Postgres (yelb-db
).
Кэш Redis хранит количество просмотров страниц, а PostgreSQL сохраняет голоса. Обе службы развертываются в Kubernetes без использования управляемой службы для хранения данных в AWS или Azure.
Исходное приложение Yelb является автономным и не зависит от внешних служб, поэтому его можно перенести из AWS в Azure без каких-либо изменений кода. В Azure можно использовать кэш Azure для Redis и Базу данных Azure для PostgreSQL в качестве замены для служб Кэша Redis и PostgreSQL, развернутых в AKS.
Пример приложения Yelb позволяет пользователям голосовать по набору альтернативных вариантов (ресторанов) и динамически обновляет круговые диаграммы на основе количества полученных голосов. Приложение также отслеживает число просмотров страниц и отображает имя хоста экземпляра yelb-appserver
, который обрабатывает запрос API при голосовании или обновлении страницы. Эта функция позволяет демонстрировать приложение самостоятельно или вместе с другими.
Архитектура в AWS
Чтобы защитить веб-приложения и API от распространенных веб-эксплойтов, AWS предлагает брандмауэр веб-приложений AWS (WAF) и диспетчер брандмауэра AWS.
Сопоставление служб AWS со службами Azure
Чтобы повторно создать рабочую нагрузку AWS в Azure с минимальными изменениями, используйте эквивалент Azure для каждой службы AWS. В следующей таблице приведены сопоставления служб.
Сопоставление служб | Служба AWS | Служба Azure |
---|---|---|
Брандмауэр веб-доступа | Брандмауэр веб-приложений AWS (WAF) | Azure Брандмауэр веб-приложений (WAF) |
Балансировка нагрузки приложений | Подсистема балансировки нагрузки приложения (ALB) | Шлюз приложений AzureШлюз приложений для контейнеров (AGC) |
Сеть доставки содержимого | Amazon CloudFront | Azure Front Door (AFD) |
Оркестрация | Служба Elastic Kubernetes (EKS) | Служба Azure Kubernetes (AKS) |
Хранилище секретов | Служба управления ключами AWS (KMS) | Azure Key Vault |
Реестр контейнеров | Реестр эластичных контейнеров Amazon (ECR) | Реестр контейнеров Azure (ACR) |
Система доменных имен (DNS) | Amazon Route 53 | Azure DNS |
Кэширование | Amazon ElastiCache | Кэш Azure для Redis |
NoSQL | Amazon DynamoDB | База данных Azure для PostgreSQL |
Полное сравнение служб Azure и AWS см. в сравнении aws с службами Azure.
Архитектура в Azure
В этом решении приложение Yelb развертывается в кластере AKS и предоставляется через контроллер входящего трафика, например контроллер входящего трафика NGINX. Служба контроллера входящего трафика предоставляется через внутреннюю (или частную) подсистему балансировки нагрузки. Дополнительные сведения о том, как использовать внутреннюю подсистему балансировки нагрузки для ограничения доступа к приложениям в AKS, см. в статье Использование внутренней подсистемы балансировки нагрузки с помощью службы Azure Kubernetes (AKS).
Этот пример поддерживает установку управляемого контроллера входящего трафика NGINX с надстройкой маршрутизации приложений или неуправляемым контроллером входящего трафика NGINX с помощью диаграммы Helm. Надстройка маршрутизации приложений с контроллером входящего трафика NGINX предоставляет следующие функции:
- Простая настройка управляемых контроллеров входящего трафика NGINX на основе контроллера входящего трафика Kubernetes NGINX.
- Интеграция с Azure DNS для управления общедоступными и частными зонами.
- Завершение SSL с сертификатами, хранящимися в Azure Key Vault.
Сведения о других конфигурациях см. в следующих статьях:
- Конфигурация DNS и SSL
- Конфигурация надстройки маршрутизации приложений
- Настройка внутреннего контроллера входящего трафика NGINX для частной зоны DNS Azure
Приложение Yelb защищено с помощью ресурса Шлюза приложений Azure , развернутого в выделенной подсети в той же виртуальной сети, что и кластер AKS или в одноранговой виртуальной сети. Вы можете защитить доступ к приложению Yelb с помощью брандмауэра веб-приложений Azure (WAF), который обеспечивает централизованную защиту веб-приложений от распространенных эксплойтов и уязвимостей.
Проектирование архитектуры решения
На следующей схеме показана рекомендуемая архитектура в Azure:
Архитектура решения состоит из следующих элементов:
- Шлюз приложений обрабатывает завершение TLS и взаимодействует с серверным приложением по протоколу HTTPS.
- Прослушиватель шлюза приложений использует SSL-сертификат, полученный из Azure Key Vault.
- Политика WAF Azure, связанная с прослушивателем, запускает правила OWASP и настраиваемые правила для входящих запросов и блокирует вредоносные атаки.
- Параметры HTTP серверной части шлюза приложений вызывают приложение Yelb через HTTPS через порт 443.
- Серверный пул шлюза приложений и проба работоспособности вызывают контроллер входящего трафика NGINX через внутреннюю подсистему балансировки нагрузки AKS с помощью HTTPS.
- Контроллер входящего трафика NGINX использует внутреннюю подсистему балансировки нагрузки AKS.
- Кластер AKS настроен с использованием поставщика Azure Key Vault, предназначенного для надстройки Secrets Store CSI Driver, чтобы получать секреты, сертификаты и ключи из Azure Key Vault через том CSI.
- SecretProviderClass получает тот же сертификат, который используется шлюзом приложений из Azure Key Vault.
- Объект Ingress Kubernetes использует контроллер NGINX Ingress для открытия доступа к приложению через HTTPS через внутренний балансировщик нагрузки AKS.
- Служба Yelb имеет тип
ClusterIP
и предоставляется через контроллер входящего трафика NGINX.
Подробные инструкции по развертыванию приложения Yelb в AKS с помощью этой архитектуры см. в сопровождающем примере.
Альтернативные решения
Azure предлагает несколько вариантов развертывания веб-приложения в кластере AKS и защиты его с помощью брандмауэра веб-приложения:
- Контроллер входящего трафика шлюза приложений
- Шлюз приложений Azure для контейнеров
- Azure Front Door
- Контроллер входящего трафика NGINX
Контроллер входящего трафика шлюза приложений (AGIC) — это приложение Kubernetes, поэтому вы можете использовать собственный балансировщик нагрузки шлюза приложений Azure L7 для предоставления облачного программного обеспечения в Интернете для рабочих нагрузок Службы Azure Kubernetes (AKS). AGIC отслеживает кластер Kubernetes, в котором он размещен, и постоянно обновляет шлюз приложений, чтобы выбранные службы предоставлялись в Интернете.
Контроллер входящего трафика выполняется в собственном модуле pod в кластере AKS. AGIC отслеживает подмножество ресурсов Kubernetes для изменений, преобразует состояние кластера в определенную конфигурацию шлюза приложений и применяет его к Azure Resource Manager (ARM). Дополнительные сведения см. в разделе "Что такое контроллер входящего трафика шлюза приложений?".
В следующей таблице описаны преимущества и недостатки контроллера входящего трафика шлюза приложений (AGIC):
Преимущества | Недостатки |
---|---|
*
Встроенная интеграция: AGIC обеспечивает встроенную интеграцию со службами Azure, в частности с Шлюзом приложений Azure, что позволяет легко и эффективно маршрутизации трафика в службы, работающие в AKS. * Упрощенное развертывание: Развертывание AGIC как надстройки для AKS отличается простотой и легкостью по сравнению с другими методами. Она обеспечивает быструю и простую настройку шлюза приложений и кластера AKS с поддержкой AGIC. * Полностью управляемая служба: AGIC как надстройка является полностью управляемой службой, предоставляя такие преимущества, как автоматические обновления и повышенная поддержка от Майкрософт. Он гарантирует, что контроллер входящего трафика остается up-to-date и добавляет дополнительный уровень поддержки. |
* Единый облачный подход: AGIC в основном используется клиентами, которые принимают единый облачный подход. Это может быть не лучший выбор, если требуется многооблачная архитектура, где развертывание на разных облачных платформах является обязательным. В этом случае может потребоваться использовать облаконезависимый контроллер входящего трафика, например NGINX, Traefik или HAProxy, чтобы избежать проблем с зависимостью от одного поставщика. |
Дополнительные сведения см. в следующих ресурсах:
Azure Kubernetes Service