Автоматизация повторной настройки инфраструктуры с помощью Azure

Экземпляры контейнеров Azure
Шлюз приложений Azure
Функции Azure
Azure Monitor

Контейнеризация — это распространенный подход к модернизации приложений. Можно использовать Службу Azure Kubernetes для расширенных рабочих нагрузок или Экземпляры контейнеров Azure для простых рабочих нагрузок контейнеров, таких как простое веб-приложение. В этой статье основное внимание уделяется реализации бессерверной автоматизации на уровне инфраструктуры для Экземпляров контейнеров, когда Шлюз приложений используется в качестве брандмауэра.

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

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

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

Потенциальные варианты использования

Эта архитектура лучше всего подходит для следующих случаев:

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

Архитектура

Схема потока, на которой показан доступ к Azure Cosmos DB частной конечной точкой для Экземпляры контейнеров Azure. Это впереди Шлюз приложений Azure.

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

Поток данных

Часть 1. Типичный поток трафика веб-приложения

1a. У Шлюза приложений есть функция брандмауэра веб-приложения, которая идеально подходит для взаимодействия с общедоступным трафиком, прежде чем он достигнет серверной рабочей нагрузки. Шлюз приложений предоставляет общедоступный IP-адрес, поэтому Защита от атак DDoS Azure обеспечивает еще один уровень защиты.

1b. Серверный пул Шлюза приложений настраивается с использованием частного IP-адреса экземпляра контейнера Azure в группе контейнеров. Экземпляры контейнеров Azure в группах контейнеров не предоставляются с полными доменными именами (FQDN), поэтому необходимо использовать IP-адрес.

1в. Контейнеры в службе "Экземпляры контейнеров Azure" могут использовать частные ресурсы, например Azure Cosmos DB, с помощью приватных каналов.

Часть 2. Усовершенствования за счет автоматизации

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

2b. Приложение Аналитика используется в контейнерах для сбора других метрик, в том числе пульса, которые можно отправить в Приложение Аналитика для мониторинга через пользовательский поток.

2c. Вы можете настроить оповещения в соответствии с пороговыми уровнями, определенными в шагах 2a и 2b. Например, предположим, что в системе есть три экземпляра контейнеров, работающих в качестве серверного пула. Вы можете настроить срабатывание оповещения, если число работоспособных узлов меньше 3. В группе действий для правил оповещений можно использовать функцию Azure в качестве типа действия, чтобы запустить настраиваемое действие.

2d. В функции Azure используется пакет SDK для Azure для получения конфигурации существующих экземпляров контейнеров и повторного создания тех же экземпляров. Эту функцию активирует оповещение, заданное в шаге 2c. На выполнение этой функции может потребоваться много времени в зависимости от сложности установки. Время ожидания для функций Azure ограничено, поэтому вы можете использовать Устойчивые функции Azure для обработки длительных процессов и получения обновлений состояния.

Компоненты

Автоматизация

  • Устойчивые функции Azure. В отличие от Функций Azure, у Устойчивых функций есть отслеживание состояния. Они поддерживает несколько шаблонов рабочих процессов с отслеживанием состояния. В этом примере используется шаблон мониторинга.
  • Пакеты SDK для Azure — это коллекции библиотек, которые можно использовать для взаимодействия со службами Azure на предпочтительном языке программирования. Пакеты SDK обеспечивают больше гибкости при интеграции логики, которая выполняет автоматизацию.

Наблюдение

  • Метрики Azure Monitor. Эта функция Azure Monitor собирает предопределенные числовые данные от служб Azure.
  • Группа действий — это коллекция параметров уведомлений, которые определены владельцем ресурса. Вы можете задать каналы уведомлений и действия на основе активированных оповещений.

Сеть

  • Защита от атак DDoS Azure: защита от атак DDoS (базовая) Azure бесплатна и включена на всех общедоступных IP-адресах. Защита сети DDoS Azure обеспечивает больше возможностей, таких как прием журналов в другие расположения и возможность привлечения группы быстрого реагирования защиты от атак DDoS.
  • Шлюз приложений Azure. Брандмауэр веб-приложений Azure обеспечивает защиту общедоступных приложений от эксплойтов, таких как атаки путем внедрения кода SQL и атаки XSS.
  • Приватный канал Azure — предоставляет доступ к службам Azure PaaS через частную конечную точку в магистрали Майкрософт для еще более безопасного доступа к сети.

Приложение

  • Экземпляры контейнеров Azure: Экземпляры контейнеров Azure выполняет образы контейнеров без необходимости настраивать другую инфраструктуру. Для расширенной оркестрации контейнеров следует рассмотреть использование Службы Azure Kubernetes (AKS).
  • Azure Cosmos DB — это полностью управляемая база данных NoSQL, которая поддерживает несколько платформ, таких как SQL, Cassandra и MongoDB.
  • Azure Key Vault. Согласно рекомендациям по безопасности разработчики не хранят строки подключения в исходном коде приложения в виде открытого текста. Azure Key Vault выступает в качестве центрального расположения с усиленной защитой для хранения секретов. Приложения могут еще более безопасно извлекать необходимые ключи.

Альтернативные варианты

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

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

Служба Azure Kubernetes предоставляет расширенные функции оркестрации контейнеров и сетевые возможности, которые недоступны в экземплярах контейнеров (например, ресурс службы). Данная эталонная архитектура удовлетворяет эту потребность.

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

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

Availability

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

Операции

Устойчивые функции Azure используется для повторной настройки инфраструктуры в случае сбоя в Экземплярах контейнеров или при изменении частного IP-адреса группы контейнеров. Как указано в документации, процесс подготовки занимает немного больше времени. Если контейнеры не готовы к работе вовремя, у пользователей может возникнуть минимальный простой.

Эта архитектура добавляет уровень устойчивости. Но мы по-прежнему рекомендуем настроить мониторинг в приложении и отслеживать состояние Azure для сбоев платформы.

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

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

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

Безопасность

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

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

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

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

Пример исходного код, в котором для выполнения автоматизации используются функции Azure, доступен на GitHub.

Вам потребуется субъект-служба (идентификатор и секрета клиента). Она будет использоваться Функциями Azure для выполнения операций Azure Resource Manager. Этому субъекту-службе необходимы, как минимуму, права владельца в группе ресурсов, чтобы он мог обновлять Шлюз приложений и создавать экземпляры контейнеров Azure. В примере создается простое контейнерное приложение Python, хранящееся в реестре контейнеров. Внесите в реестр сведения о вашем собственном приложении.

Цены

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

См. этот пример предыдущей реализации.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

  • Маркус Те | Техническая стратегия и стратегия развития

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

Ознакомьтесь с нашими архитектурами.

Связанные руководства.