В этом посте мы собираемся погрузиться в концепцию инфраструктуры как кода или IaC и как ее можно применить в вашей сети.
Инфраструктура как код — это широко используемый термин DevOps для управления или предоставления оборудования в вашей инфраструктуре с помощью автоматизированного и повторяемого процесса. Это означает, что ваша инфраструктура всегда поддерживается в известном и заранее определенном состоянии, что позволяет с легкостью использовать и применять передовые методы во всей вашей инфраструктуре.
Кроме того, соблюдение принципов «Инфраструктура как код» гарантирует, что ваша инфраструктура будет менее подвержена неожиданным или незапланированным изменениям. Даже если кто-то изменил инфраструктуру вручную и вызвал негативное воздействие, вы можете легко и немедленно повторно применить известное / хорошее состояние для восстановления службы.
Ваша группа безопасности тоже будет вам благодарна, потому что возможность единообразно гарантировать, что на вашем оборудовании есть хорошие, безопасные конфигурации, значительно упрощает их работу.
Основы инфраструктуры как код
Чтобы построить решение NetDevOps на основе «Инфраструктура как код» в вашей собственной сети, важно понимать ключевые базовые компоненты, или столпы, «Инфраструктура как код». Твердое понимание основных компонентов, их взаимодействия и того, какие инструменты и какие компоненты принадлежат, позволит вам создать мощное и надежное решение IaC в вашей среде.
Инфраструктура как код обычно строится на четырех основных столпах.
- Источник истины (SoT) — SoT часто представляет собой комбинацию следующих компонентов:
- Системы контроля версий, иногда также называемые системой контроля версий, для поддержки текстовых файлов, представляющих конфигурацию элементов вашей инфраструктуры.
- Системы записи , которые могут быть инструментами базы данных управления конфигурацией (CMDB) или управления инвентаризацией центра обработки данных (DCIM), например ServiceNow CMDB или NetBox.
- CI / CD — CI / CD означает непрерывную интеграцию и непрерывное развертывание или доставку и описывает системы, используемые для управления и выполнения изменений или развертывания вашей инфраструктуры.
- Тесты — тесты позволяют вам двигаться вперед с уверенностью, что изменения, выполненные в этом процессе, будут успешными и не вызовут нежелательных или непреднамеренных изменений в вашей инфраструктуре.
- Инструменты развертывания и настройки — эти инструменты разнообразны и могут принимать разные формы в зависимости от создаваемой системы IaC. Для NetDevOps это часто будут инструменты или системы, которые могут взаимодействовать с уровнем управления сетью (через SSH или HTTPS) для внесения изменений.
Если бы мы строили Инфраструктуру как «дом» Кодекса, считайте Источник Истины чертежами. Система CI / CD — это прораб или генеральный подрядчик, наблюдающий за строительством, а тестеры — это строительный инспектор. Вашими инструментами развертывания и настройки являются электрик, сантехник и плотник, которые строят дом!
Существует множество потенциальных комбинаций инструментов Source of Truth, CI / CD, тестирования и развертывания, поэтому не беспокойтесь, если возможности поначалу кажутся ошеломляющими. Например, Source of Truth и CI / CD будут иметь целые статьи в этой серии. Чтобы лучше познакомиться с доступными вам инструментами, в конце этого поста мы собрали приложение под названием «Lay of the Land» с инструментами в каждом из этих столпов и ссылками для дальнейшего исследования.
Пример действия столпов
Если мы подумаем о столпах IaC, мы можем построить примерный сценарий, используя их, чтобы проиллюстрировать назначение каждого столпа в общем развертывании инфраструктуры как кода.
Система, построенная на этих основах, часто использует файлы конфигурации и метаданных, хранящиеся в системе контроля версий, такой как Git, для генерации конфигураций устройств на основе фактов, хранящихся в системе записи / DCIM, такой как NetBox. Вместе эти элементы образуют Источник истины для части инфраструктуры. Инженеры вносили изменения в файл или файлы в Git, чтобы описать желаемые изменения состояния инфраструктуры. Прежде чем эти изменения будут внесены в инфраструктуру, они потребуют экспертной оценки и прохождения любых тестов, запускаемых системой CI / CD.
Когда эти предлагаемые изменения вносятся в соответствующую область вашего Источника истины, инструмент CI / CD, такой как Jenkins, обнаружит изменения или получит уведомление об этих изменениях. Затем инструмент CI / CD выполнит серию шагов (часто называемых «конвейером»), чтобы должным образом протестировать эти предлагаемые изменения в инфраструктуре.
Внутри конвейера тесты выполняются до того, как будут внесены какие-либо изменения в инфраструктуру, чтобы проверить их потенциал для успеха и любое влияние, которое они могут вызвать. Простые тесты обычно используются для проверки (или « lint ») того, что сами измененные файлы синтаксически и логически действительны. Кроме того, в конвейере Network IaC тесты часто запускаются с помощью такого инструмента, как Batfish.который может анализировать и понимать конфигурацию сетевого устройства. Эти расширенные тесты позволяют убедиться, что потенциальные изменения не повлияют на неожиданный элемент вашей сети. Они позволяют вам, прежде чем касаться самой сети, быть уверенным, что эти изменения не вызовут неблагоприятного воздействия или непреднамеренных изменений политики безопасности. Пройден или не пройден, статус этих тестов возвращается в Git для отображения или может быть передан на платформу чата, такую как Slack.
Если тесты прошли успешно, и в этом примере изменения утверждены и объединены в Git, изменения можно будет реализовать с помощью инструмента развертывания, такого как Terraform или Ansible (или оба), или даже простой Python. Этот шаг не обязательно должен происходить немедленно, и конвейер в вашем инструменте CI / CD можно легко заставить ждать, пока не появится заранее определенное окно изменений, чтобы выполнить отложенные изменения. Как только конвейер будет готов к развертыванию изменений или самой инфраструктуры, средство развертывания развернет или настроит элементы вашей инфраструктуры на основе изменений, записанных, утвержденных и протестированных из Источника истины.
И, наконец, снова выполняются тесты, чтобы определить успешность действий по развертыванию. Если эти тесты терпят неудачу, они могут либо откатить выполненные изменения, либо предупредить инженера о необходимости какого-либо вмешательства через сообщение в Slack.
Сетевая инфраструктура как код
Если говорить конкретно о внедрении инфраструктуры как кода в мир NetDevOps, можно выделить два общих типа сценариев использования.
Первый тип использует IaC для развертывания самой виртуальной сетевой инфраструктуры. Это может включать, например, автоматическое выделение ресурсов AWS VPC для завершения работы VPN в вашей организации или запуск виртуального брандмауэра в ESX.
Второй тип — использование IaC для развертывания конфигураций в существующей сетевой инфраструктуре (включая физическое оборудование). Это может быть сохранение списка ваших одноранговых узлов BGP в файле в системе управления версиями, а затем применение соответствующей конфигурации к маршрутизаторам в вашей сети при внесении изменений в этот файл.
Выбор того, над какой из этих двух областей вы хотите работать в первую очередь, будет зависеть от вас, хотя чаще всего в корпоративных сетях мы видим, что предпринимается позднее (настройка физического оборудования), поскольку это самая большая возможность повлиять на повседневную дневные операции. Устранение необходимости вручную настраивать VLAN и простое внесение изменений в файл в системе управления версиями с помощью инструмента CI / CD, выполняющего все остальное, является чрезвычайно привлекательным для многих организаций.
Приложение: Lay of the Land
Это список (в произвольном порядке) часто используемых инструментов в каждом из столпов, который поможет вам начать систематизировать их в уме. В приведенном ниже списке стоит отметить две вещи. Во-первых, это ни в коем случае не является исчерпывающим и предназначено просто для того, чтобы помочь вам сориентироваться среди множества инструментов, имеющихся в каждой из опор.
Во-вторых, некоторые инструменты (такие как Github или GitLab) представлены в нескольких столбцах ниже, поскольку они предоставляют несколько областей функциональности. Это происходило чаще в последние несколько лет, поскольку, например, более тесная интеграция Source Control и CI / CD стала стандартными функциями. Ничего не написано на камне, что просто потому, что вы используете GitHub для управления версиями, вы также должны использовать его для CI / CD. Оценивайте каждый инструмент, основываясь на его сильных сторонах, а также на вашем опыте / знакомстве с ним.
Источник Истины
Учитывая, что на практике Источник истины обычно собирают из нескольких мест, я разбил его ниже на разделы для управления версиями и для систем записи. Соответствующими системами записи в корпоративной среде часто являются инструменты CMDB / DCIM (база данных управления конфигурацией / управление инфраструктурой центра обработки данных), поэтому они описаны ниже.
Управления источником
Хотя Git, безусловно, является наиболее часто используемой системой управления версиями (с множеством различных служб и реализаций, как показано ниже), полезно также понимать некоторые другие доступные инструменты управления версиями.
Система записи
Часто в категории «Система записи» их может быть несколько внутри крупной организации. Не все элементы сетевой инфраструктуры представлены в каждой системе, и некоторые из них могут синхронизировать данные между собой. Кроме того, хотя CMDB или DCIM служат разным целям в среде, данные, которые они могут иметь, частично совпадают, и, таким образом, они могут выполнять часть той же роли в инфраструктуре, что и развертывание кода. Некоторые крупные предприятия даже создали свои собственные инструменты DCIM или CMDB, и степень интеграции с этими инструментами будет широко варьироваться.
CI / CD
В компоненте CI / CD нет явного победителя, поэтому мы рекомендуем узнать, используется ли что-либо из перечисленного ниже в вашей организации, и попытаться использовать его для своих целей.
Инструменты развертывания и настройки
Этот компонент очень разнообразен, так как выбранный вами инструмент развертывания и настройки во многом зависит от ваших сценариев использования. Это может зависеть от того, какой тип инфраструктуры вы хотите развернуть / настроить, как вы хотите ее настроить, или даже от того, насколько хорошо вы знакомы с тем или иным инструментом.
Стоит отметить, что существует ряд инструментов / библиотек Python, которые обычно используются (часто в комбинации) для создания собственных инструментов конфигурации для сетевого оборудования:
Инструменты и фреймворки для тестирования
Тестирование может иметь множество разновидностей и разновидностей, но для «Сетевая инфраструктура как код» инструменты, которые вы используете, в основном делятся на три лагеря.
Во-первых, это инструменты, которые статически проверяют / проверяют сами файлы конфигурации или кода. Это означает, что инструменты, которые проверяют содержимое каждого файла и гарантируют, например, что файл, заявленный как формат YAML, действительно является действительным YAML.
Во-вторых, это инструменты, которые разворачивают инфраструктуру, чтобы вы могли протестировать симулякр вашей сети. Эти инструменты, обычно используемые для обучения и получения образования, традиционно были основным способом проверки сетевых изменений до появления третьей категории.
В-третьих, и это наиболее интересно, это инструменты, которые проверяют логику изменений конфигурации, которые вы пытаетесь внести. Эти инструменты фактически проанализируют вносимые вами изменения и их потенциальное влияние на другие элементы вашей инфраструктуры.