Операции для критически важных рабочих нагрузок в Azure

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

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

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

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

Автоматизация приложений

Непрерывная интеграция и непрерывное развертывание (CI/CD) обеспечивает надлежащее развертывание и проверку критически важных рабочих нагрузок. CI/CD — это предпочтительный подход к развертыванию изменений в любой среде, разработке/тестировании, рабочей среде и других. Для критически важных рабочих нагрузок изменения, перечисленные в следующем разделе, должны привести к развертыванию совершенно новой метки. Новая метка должна тщательно тестироваться в рамках процесса выпуска, прежде чем трафик направляется на метку с помощью стратегии синего/зеленого развертывания.

В следующих разделах описываются изменения, которые должны быть реализованы по возможности с помощью CI/CD.

Изменения приложения

Все изменения в коде приложения следует развертывать через CI/CD. Код должен быть создан, выровнирован и проверен на регрессии. Зависимости приложений, такие как среда выполнения или пакеты, должны отслеживаться, и их обновления следует развертывать через CI/CD.

Изменения инфраструктуры

Инфраструктура должна быть моделирована и подготовлена в качестве кода. Эта практика обычно называется инфраструктурой как код (IaC). Все изменения в IaC должны быть развернуты через конвейеры CI/CD. Обновления инфраструктуры, такие как исправление операционной системы, также должны управляться с помощью конвейеров CI/CD.

Изменения конфигурации

Изменения конфигурации являются распространенными причинами сбоя приложений. Для борьбы с этими сбоями необходимо записать конфигурацию приложения или инфраструктуры в виде кода. Эта практика называется "Конфигурация как код" (CaC). Изменения ЦС должны быть развернуты с помощью конвейеров CI/CD.

Обновления библиотеки и пакета SDK

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

• Пакеты NuGet .NET
• Пакеты менеджера пакетов Node.js JavaScript
• Поставщик Terraform

Следующий сценарий является примером автоматизации обновлений библиотеки с помощью dependabot в репозитории GitHub.

1. Dependabot обнаруживает обновления библиотек и пакета SDK, используемые в коде приложения.

2. Dependabot обновляет код приложения в ветке с этими изменениями и создает pull request (PR) в главную ветку. PR содержит всю соответствующую информацию и готов к финальной проверке.

3. Когда проверка и тестирование кода завершены, можно слить PR с основной ветвью.

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

Смены ключей, секретов и сертификатов

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

Поскольку истекшие или недействительные секреты могут привести к сбоям приложения (см. анализ сбоев), важно иметь четко определенный и отлаженный процесс. Для Критически важных задач Azure метки, как ожидается, будут жить только в течение нескольких недель. Из-за этого смена секретов ресурсов меток не является проблемой. Если срок действия секретов в одной метке истекает, приложение по-прежнему будет работать.

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

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

1. Обновите метки с помощью дополнительного ключа. По умолчанию первичный ключ API для Azure Cosmos DB хранится в качестве секрета в Azure Key Vault в каждой метке. Создайте PR-запрос, который обновляет код шаблона IaC, использующий дополнительный ключ API Azure Cosmos DB. Запустите это изменение через обычную процедуру проверки и обновления PR, чтобы развернуть его как новый выпуск или как срочное исправление.

2. (необязательно) Если обновление было развернуто в качестве исправления в существующем выпуске, модули pod автоматически получат новый секрет из Azure Key Vault через несколько минут. Однако клиентский код Azure Cosmos DB в настоящее время не повторно инициализируется с измененным ключом. Чтобы устранить эту проблему, вручную перезапустите все модули (pod) с помощью следующих команд в кластерах.

   kubectl rollout restart deployment/CatalogService-deploy -n workload
   kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
   kubectl rollout restart deployment/healthservice-deploy -n workload
   

3. Недавно развернутые или перезапущенные pods теперь используют вторичный ключ API для подключения к Azure Cosmos DB.

4. После перезапуска всех модулей pod на всех метках или развертывания новой метки повторно создайте первичный ключ API для Azure Cosmos DB. Ниже приведен пример для команды:

   az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
   

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

Оповещения

Оповещения являются ключевыми для понимания того, есть ли проблемы с вашей средой. Изменения оповещений и /или групп действий должны быть реализованы с помощью конвейеров CI/CD. Дополнительные сведения об оповещениях см. в статье Моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure.

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

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

Масштабирование

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

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

• Недостаточное количество модулей pod, обрабатывающих сообщения из очереди или статьи или секции, приводит к растущему числу необработанных сообщений. Этот результат иногда называется растущей глубиной очереди.
• Недостаточно ресурсов на узле службы Azure Kubernetes может привести к тому, что модули pod не могут выполняться.
• Следующие результаты приводят к ограничению запросов:
  • Недостаточно единиц запросов (RUs) для Azure Cosmos DB
  • Недостаточно единиц обработки (PUS) для центров событий уровня "Премиум" или единиц пропускной способности (TUS) для стандартных
  • Недостаточно единиц обмена сообщениями (ЕОС) для премиального уровня Service Bus

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

• Горизонтальное автоматическое масштабирование Pod позволяет увеличивать или уменьшать количество pod, выполняющих рабочие нагрузки, в зависимости от спроса.
• автомасштабирования кластера AKS позволяет увеличивать или уменьшать количество узлов в кластере в зависимости от спроса.
• Вы можете автоматически масштабировать единицы пропускной способности Центров событий Azure (стандартный уровень)
• Вы можете автоматическое обновление единиц обмена сообщениями пространства имен служебной шины Azure

Управление ключами, секретами и сертификатами

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

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

• Azure Front Door имеет встроенные возможности для управления сертификатами TLS и продления.
• Azure Key Vault поддерживает автоматическую смену ключей.

Операции вручную

Существуют операционные действия, требующие вмешательства вручную. Эти процессы должны быть проверены.

Необрабатываемые сообщения

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

Восстановление Azure Cosmos DB

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

Увеличение квоты

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

Важный

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

Участники

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Роб Багби | Разработчик основного содержимого
• Аллен Субринг | Старший разработчик содержимого

Чтобы просмотреть закрытые профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

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

Реализация : Mission-Critical Online