Стратегии архитектуры для использования инфраструктуры в качестве кода

Применяется к этой контрольной рекомендации по операционному превосходству в Azure Well-Architected Framework:

В этом руководстве описаны рекомендации по использованию IaC в качестве стандарта для развертываний инфраструктуры. Использование IaC позволяет интегрировать развертывания инфраструктуры и управление ими в существующие методики разработки программного обеспечения. Она предоставляет согласованную стандартную методологию разработки и развертывания для всех компонентов рабочей нагрузки. Использование развертываний вручную ставит рабочую нагрузку под угрозу несогласованных конфигураций и потенциально небезопасной разработки.

Определения

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

Предпочесть декларативный по сравнению с императивными инструментами

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

Использование собственных и отраслевых инструментов

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

Возможности ИИ: Разработка и проверка шаблонов IaC, основанных на стандартах, таких как Bicep и Terraform, часто требуют много времени и нередко приводят к ошибкам. ИИ упрощает создание и проверку шаблонов, чтобы ускорить усилия по модернизации. Просмотрите весь код, созданный ИИ, чтобы соответствовать требованиям к точности и соответствию требованиям.

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

Использование подходящего средства для задачи

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

Аналогичным образом применение требуемой конфигурации состояния (DSC) для различных типов инфраструктуры может потребовать различных средств. Например, существуют определенные инструменты, такие как Ansible для управления DSC для виртуальных машин, в то время как Flux — это хороший инструмент для управления DSC в кластерах Kubernetes. Службы "Платформа как услуга" (PaaS) могут предоставлять различные средства для управления конфигурацией (например, Конфигурация приложений Azure), которые можно обрабатывать с помощью IaC. Службы Программного обеспечения как услуги (SaaS) могут быть более ограниченными, так как они более жестко контролируются платформой.

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

Поддержка нескольких сред

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

Возможность ИИ: ИИ позволяет обеспечить согласованность среды и предотвратить проблемы конфигурации, влияющие на качество или стабильность. ИИ может просматривать код приложения в pull-запросах, чтобы определить необходимые обновления IaC и рекомендовать изменения заранее. GitHub Copilot может анализировать код, документы разработки и требования к предложениям обновлений или разрешать разработчикам запрашивать изменения инфраструктуры на естественном языке. Расширенные агентные решения могут выводить потребности в инфраструктуре из кода и других источников и создавать pull requests с рекомендованными изменениями в IaC и конфигурации.

Используйте правильный баланс при инкапсуляции функциональности

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

Документирование шагов вручную.

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

Документируйте стандарты для обработки потерянных ресурсов. В зависимости от инструментов, используемых для управления конфигурацией и их ограничений, может возникнуть время, когда определенный ресурс больше не требуется рабочей нагрузкой, и средства IaC не могут автоматически удалить ресурс. Например, предположим, что вы переходите из виртуальных машин в службу PaaS для некоторых функций, а средства IaC не имеют логики удаления устаревших ресурсов. Эти ресурсы могут стать потерянными, если команда рабочей нагрузки не забывает удалять их вручную. Чтобы справиться с этими сценариями, стандартизируйте стратегию для сканирования потерянных ресурсов и их удаления. Кроме того, необходимо рассмотреть вопрос о том, как обеспечить актуальность шаблонов. Изучите ограничения инструментов IaC, чтобы понять, что вам может потребоваться спланировать в этих ситуациях.

Рассмотрите следующие рекомендации по использованию IaC для ваших рабочих нагрузок.

Использование многоуровневого подхода для конвейеров IaC

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

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

Обрабатывать код IaC и приложения одинаково

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

Использование централизованных стандартов и ресурсов

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

Усиление безопасности в коде IaC

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

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

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

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

Внедрение неизменяемой модели развертывания

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

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

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

Увеличение усилий по обслуживанию: Для обеспечения актуальной и безопасной реализации IaC требуется обслуживание кодовой базы и инструментов. Правильно отслеживайте ваш технический долг и создайте культуру, где снижение долга вознаграждается.

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

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

Упрощение функций Azure

Шаблоны Azure Resource Manager (шаблоны ARM) и Bicep — это собственные средства Azure для развертывания инфраструктуры с помощью декларативного синтаксиса. Шаблоны ARM записываются в формате JSON, а Bicep — это язык, зависящий от домена. Их можно легко интегрировать в конвейеры CI/CD Azure Pipelines или GitHub Actions .

Terraform — это еще одно декларативное средство IaC, которое полностью поддерживается в Azure. Его можно использовать для развертывания и управления инфраструктурой, а также для интеграции в конвейер CI/CD.

Вы можете использовать Microsoft Defender для облака для обнаружения неправильных конфигураций в IaC.

Пример

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

Дополнительные ссылки

• Что такое инфраструктура как код (IaC)?
• Обнаружение неправильных конфигураций в IaC
• Рекомендации по проектированию цепочки поставок разработки рабочих процессов
• Рекомендации по стандартизации средств и процессов
• Рекомендации по защите жизненного цикла разработки
• Рекомендации по использованию методов безопасного развертывания
• Шаблон меток развертывания
• шаблоны Azure Resource Manager (шаблоны ARM);
• Bicep
• Azure Pipelines
• Действия GitHub
• Terraform

Контрольный список операционного превосходства

Ознакомьтесь с полным набором рекомендаций.