Поделиться через

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

  • Статья

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

Рекомендации по автоматизации платформы

  • Реализация методологии "Все как код" (EaC) позволяет командам разблокировать ключевые преимущества, создавать сильные региональные параметры разработки и разрешать всем участникам каждой команды проверять, как и какие ресурсы развертываются. EaC также помогает командам платформы внедрять ключевые методики разработки, которые повышают гибкость и эффективность. Ваши команды могут отслеживать изменения и контролировать, какие из них перемещаются в рабочую среду по жилищному коду в репозиториях и с помощью систем управления версиями для управления им.
  • Teams могут следовать принципу 4-глаз и использовать одноранговое программирование или одноранговую проверку, чтобы гарантировать, что изменения кода никогда не вносятся в одиночку. Одноранговое программирование и пиринговая проверка повышают качество кода, позволяют командам делиться ответственностью за изменения и увеличивать знания команды о том, что согласовано и развернуто. Обзор кода — это фантастический способ для участников команды, чтобы узнать о новых методах и методах написания кода и автоматизации.
  • Teams должны использовать такие системы управления версиями, как Git, вместе с репозиториями Git, для применения одноранговой проверки. Репозитории Git позволяют командам определять важные ветви и защищать их с помощью политик ветвей. Вы можете использовать политику, чтобы требовать изменения кода в этих ветвях для удовлетворения определенных критериев, таких как минимальное количество утверждений участников группы, прежде чем они смогут объединиться в защищенная ветвь.
  • Teams должны подключать методологию EaC и процесс проверки изменений вместе с процессом непрерывной интеграции и непрерывной доставки (CI/CD). Каждое изменение кода должно автоматически активировать процесс CI, который выполняет статический анализ кода, проверку и тестовые развертывания. CI гарантирует, что разработчики проверка свой код рано (часто называются сбоем быстрого или сдвигового тестирования) для ошибок, которые могут вызвать будущие проблемы. В зависимости от того, какую стратегию ветвления использует ваша команда, изменения в любой важной ветви должны активировать развертывание в разных средах. После утверждения и объединения mainизменений процесс CD развертывает эти изменения в рабочей среде. Эта система управления кодом предоставляет команде один источник истины для того, что выполняется в каждой среде.
  • Чтобы гарантировать, что ваша платформа полностью самовосстановляется и обеспечивает самообслуживание для рабочих нагрузок, ваша команда платформы должна автоматизировать все (часто называемые крайней автоматизацией) от подготовки, настройки и управления платформой до подготовки подписки целевой зоны для рабочих нагрузок. Крайняя автоматизация позволяет вашей команде платформы сосредоточиться на предоставлении ценности, а не на развертывании, настройке и управлении платформой. Крайнее автоматизация также создает самоустраивающийся цикл, который дает вашей команде больше времени для создания большего уровня автоматизации.
  • По мере того как команды платформы автоматизируют операционные действия и сокращают вмешательство человека, они должны переключить свое внимание на важные задачи, которые позволяют и ускоряют инновации группы рабочей нагрузки в Azure. Чтобы достичь этого, ваша команда платформы должна выполнять итерацию нескольких циклов создания и разработки, так как они ввели средства, скрипты и улучшения возможностей платформы.
  • Существует несколько вариантов, которые помогут вашей команде приступить к развертыванию целевой зоны Azure. Эти параметры зависят от текущих возможностей команды и могут расти по мере развития вашей команды. В частности, для развертывания платформы можно выбрать варианты взаимодействия с порталом, Bicep или Terraform, в зависимости от соответствующих навыков и инструментов Teams.
    • Новые и новые команды платформы, которые по-прежнему получают сведения об инфраструктуре как код (IaC) и более знакомы с использованием портала для развертывания ресурсов и управления ими могут использовать акселератор целевой зоны Azure для запуска, который поддерживает команды по-прежнему с помощью подхода ClickOps . ClickOps — это процесс подготовки, настройки и управления ресурсами, щелкнув на порталах, консоль управления и мастерах. Этот акселератор позволяет вашей команде использовать портал в качестве начального средства развертывания и постепенно, по мере роста зрелости разработки платформы для дальнейшего использования Azure CLI, PowerShell или IaC.
    • Решение AzOps позволяет командам развивать свои методики автоматизации платформы и управления на основе ClickOps, управляемого devOps. Ваша команда может перейти от использования личная учетная запись доступа к использованию принципов и методик DevOps, основанных только на CI/CD с AzOps и IaC. AzOps позволяет вашей команде использовать собственную архитектуру, использовать архитектуру, развернутую акселератором портала целевой зоны Azure (после первоначального развертывания на основе портала, так как интеграция AzOps не является частью интерфейса портала ALZ), интегрироваться с развертыванием браунфилда или использовать пользовательские шаблоны (Bicep или ARM) для создания и эксплуатации платформы.
    • Группы платформ с установленными навыками и возможностями могут применять кодифицированный подход, который следует принципам и методикам DevOps. Ваша команда должна опираться на IaC и современные методики разработки, переходя от использования доступа Azure к своим личная учетная запись и к выполнению всех операций через конвейер CI/CD. Ваша команда должна использовать акселераторы на основе IaC, такие как ALZ-Bicep или модуль Terraform целевых зон Azure, чтобы ускорить этот переход.
  • Акселераторы на основе IaC имеют ограниченные область управления. Новые версии предоставляют дополнительные возможности и расширенные возможности управления ресурсами. При использовании акселератора ваша команда должна рассмотреть многоуровневый подход, который начинается с акселератора, а затем добавляет уровень автоматизации. Уровень автоматизации предоставляет возможности, необходимые команде для полной поддержки рабочих нагрузок с функциями платформы, такими как развертывание контроллера домена для устаревших приложений.
  • По мере перехода команды платформы на подход DevOps необходимо установить процесс обработки аварийных исправлений. Они могут использовать соответствующие разрешения управление привилегированными пользователями (PIM) для запроса доступа к исправлению и последующего возврата к коду, чтобы ограничить смещение конфигурации, или использовать код для реализации быстрого исправления. Ваша команда всегда должна регистрировать быстрые исправления в их невыполненной работе, чтобы они могли переработать каждое исправление в более позднюю точку и ограничить свой технический долг. Слишком много технического долга приводит к будущему замедлению, так как некоторый код платформы не полностью проверен и не соответствует рекомендациям и принципам программирования команды.
  • Политики Azure можно использовать для добавления некоторых автоматизации на платформу. Рекомендуется использовать IaC для развертывания политик Azure и управления ими, часто называемых политиками как код (PaC). Эти политики позволяют автоматизировать такие действия, как сбор журналов. Многие платформы PaC также реализуют процесс исключения, поэтому планируете для рабочих нагрузок запрашивать исключения из политик.
  • Используйте "Управление на основе политик", чтобы сообщить группам рабочих нагрузок при попытке развернуть ресурсы, которые не соответствуют контролю безопасности. Рассмотрите возможность развертывания политик с эффектом deny для этих ситуаций, что позволяет командам рабочей нагрузки также рассматривать все как код и избегать смещения конфигурации, когда код объявляет одну вещь и политику изменил параметр во время развертывания. Избегайте использования modify эффектов, например, если команда рабочей нагрузки развертывает учетную запись хранения, supportOnlyHttpsTraffic = false определенную в коде, true в которой modify политика изменяется во время развертывания, чтобы обеспечить соответствие требованиям. Это приводит к смещению кода от развернутого объекта.

Рекомендации по проектированию автоматизации платформы

  • Следуйте подходу "Все как код" для полной прозрачности и управления конфигурацией платформы Azure, документации, развертывания и тестирования.
  • Используйте управление версиями для управления всеми репозиториями кода, включая:
    • Инфраструктура как код
    • Политика как код
    • Настройка в качестве кода
    • Развертывание как код
    • Документация как код
  • Реализуйте принцип 4-глаз и процесс однорангового программирования или одноранговой проверки , чтобы убедиться, что все изменения кода проверяются командой перед развертыванием в рабочей среде.
  • Примите стратегию ветвления для команды и задайте политики ветви для ветвей, которые вы хотите защитить. С политиками ветви команды должны использовать запросы на вытягивание для внесения изменений в слияние.
  • Используйте непрерывную интеграцию и непрерывную доставку (CI/CD), чтобы автоматизировать тестирование кода и развертывание в разных средах.
  • Чтобы автоматизировать все, например подготовку, настройку и управление платформой, а также подготовку подписок целевой зоны для рабочих нагрузок.
  • Используйте один из доступных акселераторов, которые соответствуют возможностям вашей команды, чтобы приступить к развертыванию целевых зон Azure.
  • Планируйте использовать многоуровневый подход к развертыванию для добавления возможностей, которые не охватываются акселератором, но необходимы для полной поддержки команд рабочей нагрузки.
  • Создайте процесс использования кода для реализации быстрых исправлений. Всегда регистрируйте быстрые исправления в невыполненной работе вашей команды, чтобы каждое исправление можно было переработать позже, и вы можете ограничить технический долг.
  • Использование инфраструктуры в качестве кода для развертывания политик Azure и управления ими (часто называемых политиками как код)
  • Реализуйте процесс исключения для политик. Запланируйте для команд рабочей нагрузки запрос на освобождение от политик и подготовьтесь к разблокировкам команд по мере необходимости.
  • Используйте "Управление на основе политик", чтобы заблокировать группы рабочих нагрузок при попытке развернуть ресурсы, которые не соответствуют контролю безопасности. Это помогает уменьшить смещение конфигурации, где код объявляет другое состояние, чем то, что в конечном итоге развертывается.

Подробнее