Зачем появляются такие инструменты, как Ansible? Почему возникают такие направления, как IaC? Ответы на эти вопросы кроются в ряде проблем: большой «зоопарк» серверов, серверы-снежинки, которыми тяжело управлять — как итог, админы постепенно начинают не справляться с ручным управлением.

Infrastructure as Code или инфраструктура как код (IaC) — это подход для управления и описания инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах. IaC обращается со скриптами / конфигурационными файлами / плейбуками Ansible точно так же, как разработчики обращаются с кодовой базой проекта. 

Инфраструктурный код должен проходить коммиты, CI/CD, merge requests, code review. IaC использует высокоуровневый язык описания кода для автоматизации предоставления ИТ-инфраструктуры. Эта автоматизация избавляет разработчиков от необходимости вручную выделять и управлять операционными системами, серверами, подключениями к хранилищам, базам данных и другим элементам инфраструктуры каждый раз, когда нужно написать, протестировать или развернуть программное приложение.

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

Плюсы IaC

Файлы инфраструктуры хранятся в системе контроля версий. Чтобы приносить пользу, инструменты IaC постоянно совершенствуются. Они помогают предприятиям осуществлять управление инфраструктурами.

Сам подход IaC состоит из декларативного или императивного описания инфраструктуры. Первое более распространено. IaC наиболее популярен в cloud computing и поддерживает IaaS (infrastructure as a service). 

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

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

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

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

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

Минусы подхода IaC

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

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

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

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

Ansible как инструмент для построения инфраструктуры

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

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

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

Принцип работы Ansible

Нам наиболее важно то, что Ansible осуществляет четыре правила IaC:

• Воспроизводимость всех элементов инфраструктуры.

• Возможность избавления от ненужного элемента.

• Согласованность данных  инфраструктуры.

• Отсутствие какого-то «финального» состояния у инфраструктуры.

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

Есть и другие системы управления конфигурациями серверов: Otter, DSC, SaltStack, Pulumi, Chef, Puppet, CFEngine и, конечно же, Terraform. Ansible и Terraform от всех остальных отличает безагентная модель работы. Проясним: Ansible подключается к серверам и работает на них по SSH.

Открытый порт SSH для Linux и Python 3+, Python 3+, Ansible Windows User и WinRM для Windows — все, что требуется для работы Ansible на удаленном сервере. Сам Ansible устанавливают на компьютер админа, который должен быть на Linux.

Прежде чем в двух предложениях рассказать о принципе работы Ansible, приведем три термина: 

• нода – это компьютер, где установлен Ansible, 

• хосты – это удаленные серверы, к которым подключается Ansible, 

• модули осуществляют все необходимые действия на удаленных серверах.

Теперь будет проще понять концепцию Ansible, которая заключается в следующем: хосты управляются по SSH контрольной нодой с Ansible. Вам не нужны агенты или какое-либо дополнительное ПО на удаленных серверах, если вы работаете на Linux. Для тех, кто предпочитает работать на Windows, есть WSL2.

Теперь об архитектуре. Она тоже достаточно проста и содержит всего четыре элемента.

• Modules — скрипты или программы, загружаемые и исполняемые на удаленных серверах.

• Inventory — файл, где хранятся данные и где нужно производить необходимые действия.

• API — интерфейс взаимодействия с Ansible.

• Plugins — расширяющие возможности Ansible сопрограммы.

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

На курсе «Ansible: Infrastructure as Code» от Слёрма вы разберете реальные кейсы, поймете, как Ansible встраивается в продакшен и как его правильно внедрить в команду. Автор курса – Всеволод Севостьянов, Lead Engineer в Vene. Вместе с Всеволодом вы погрузитесь в 8 тем, изучите 38 уроков, посмотрите 10 часов видеолекций, ознакомитесь с 78 тестовыми и 46 практическими занятиями. Кстати, там еще есть 36 часов стендов для выполнения практик и возможность задавать и обсуждать любые вопросы.

Узнать больше о курсе.