инфраструктура как код infrastructure as code iac
Infrastructure as Code: Плюсы, Минусы и Будущее
Infrastructure as Code — ключевой элемент наиболее эффективных инженерных сетапов. То, как сейчас DevOps-инженеры взаимодействуют со своей инфраструктурой — это несомненно большой скачок вперед. Но тем не менее спорные моменты с определением и лучшими практиками IaC до сих пор есть. Эта статья стремится четко описать IaC, его преимущества и важные ограничения.
Infrastructure as Code, или сокращенно IaC, — это фундаментальный сдвиг не только для Ops в том, как они подходят к провизионированию и обслуживанию инфраструктуры, но и в разработке программного обеспечения в целом. Несмотря на то, что за последние несколько лет IaC де-факто зарекомендовал себя как отраслевой стандарт, многие до сих пор спорят о его определении, лучших практиках и ограничениях.
В этой статье вы познакомитесь с эволюцией этого подхода к инфраструктуре рабочих процессов и связанных с ним технологий. Мы объясним, откуда появился IaC, перспективы его развития, его преимущества и его главные ограничения.
От железа к облаку
Еще помните железный век IT, когда вам нужно было покупать собственные серверы и компьютеры? И я уже не помню. Сейчас кажется совершенно безумным, что рост инфраструктуры мог быть ограничен циклом покупки оборудования. Поскольку доставка нового сервера занимала несколько недель, необходимость быстрой установки и настройки на нем операционной системы не стояла так остро. Люди просто вставляли диск в сервер и следовали по пунктам. Через несколько дней он становился доступен для разработчиков. Просто безумие.
С одновременным запуском и повсеместным внедрением AWS EC2 и Ruby on Rails 1.0 в 2006 году многие корпоративные группы столкнулись с проблемами масштабирования, которые ранее возникали только в крупных транснациональных организациях. Облачные вычисления и возможность без усилий запускать новые инстансы виртуальных машин принесли инженерам и предприятиям не только хорошую выгоду, но и дополнительные хлопоты. Теперь им приходилось следить за обслуживаемыми серверами, число которых постоянно росло.
Площадь инфраструктуры средней инженерной организации стала расти по мере того, как небольшое количество больших машин заменялось большим количеством меньших. В какой-то момент стало гораздо больше вещей, которые Ops требовалось провизионировать и поддерживать, и эта инфраструктура имела тенденцию быть циклической. Мы можем масштабироваться, чтобы справиться с пиковой нагрузкой днем, а ночью уменьшать масштаб, чтобы сэкономить на расходах, потому что они не фиксированы. В отличие от необходимости мириться с постоянным устареванием нашего оборудования, мы теперь платим за вычислительные ресурсы почасово. Таким образом, чтобы извлечь максимальную выгоду при использовании облачного сетапа, имеет смысл задействовать только ту инфраструктуру, которая вам необходима.
Чтобы максимально эффективно использовать эту гибкость, нам потребовалась новая парадигма. Создавать тысячу тикетов каждое утро, чтобы набрать максимальную мощность, и еще тысячу тикетов ночью, чтобы снова замедлиться, при этом вручную управлять всем этим, очевидно, становится довольно сложной задачей. Возникает вопрос, как начать операционализировать этот сетап, чтобы он был надежным, устойчивым и исключал ошибки, вызванные человеческим фактором?
Infrastructure as Code
Infrastructure as Code был рожден для решения этих задач максимально систематизированным образом. IaC — это процесс управления и провизионирования датацентров и серверов с помощью машиночитаемых файлов определений, созданный как альтернатива физическому конфигурированию оборудования и оперируемым человеком инструментам. Теперь, вместо того, чтобы запускать сотню различных файлов конфигурации, IaC позволяет нам просто запускать скрипт, который каждое утро поднимает тысячу дополнительных машин, а вечером автоматически сокращает инфраструктуру до приемлемого вечернего масштаба.
С момента запуска AWS Cloudformation в 2009 году IaC быстро стал неотъемлемой практикой DevOps, незаменимой в жизненном цикле конкурентоспособной доставки программного обеспечения. Он позволяет командам инженеров быстро создавать и версионировать инфраструктуру тем же способом, что и обычный код, и отслеживать эти версии во избежание несогласованности между средами. Обычно команды осуществляют это следующим образом:
Разработчики определяют и пишут инфраструктурные спецификации (infrastructure specs) на специфичном для предметной области языке
Созданные файлы отправляются в API управления, мастер-сервер или репозиторий кода
Затем инструмент IaC, такой как Pulumi, выполняет все действия, которые нужны для создания и настройки необходимых вычислительных ресурсов
И вуаля, ваша инфраструктура внезапно начинает работать на вас, а не наоборот.
Традиционно существует два подхода к IaC, декларативный или императивный, и два возможных метода, push и pull. Декларативный подход описывает конечную цель и определяет требуемое состояние ваших ресурсов. Этот подход отвечает на вопрос о том, что нужно создать, например, «Мне нужны две виртуальные машины». Императивный подход отвечает на вопрос о том, как нужно изменить инфраструктуру для достижения конкретной цели, обычно выдавая последовательность различных команд. Ansible playbooks — отличный пример императивного подхода. Разница между методом push и pull заключается в том, каким образом серверам сообщается информация о конфигурации. В pull режиме каждый сервер будет пулить свою конфигурацию из мастер-сервера, а в push режиме мастер-сервер сам распушивает конфигурацию по целевой системе.
В течение последних десяти лет набор инструментов IaC постоянно эволюционировал, и, вероятно, потребовалась бы целая статья, чтобы дать исчерпывающий обзор всех различных вариантов реализации этого подхода в ее конкретной инфраструктуре. Однако мы составили краткую хронологию основных инструментов, перечисленных по дате релиза:
Что такое «Инфраструктура как код»?
Инфраструктура как код (IaC) — это управление инфраструктурой (сетями, виртуальными машинами, подсистемами балансировки нагрузки и топологией подключения) в описательной модели с использованием той же версии, что и группа DevOps, используемая для исходного кода. Подобно принципу, согласно которому один и тот же исходный код создает один и тот же двоичный файл, модель IaC при каждом применении формирует одну и ту же среду. IaC является ключевым DevOps методикой и используется в сочетании с непрерывной поставкой.
IaC решает реальные проблемы
Инфраструктура по мере развития кода для решения проблемы с отклонением среды в конвейере выпуска. Без IaC команды должны поддерживать настройки отдельных сред развертывания. Со временем каждая среда становится « _снежинка_», то есть уникальной конфигурацией, которая не может быть воспроизведена автоматически. Несогласованность между средами приводит к проблемам во время развертывания. Администрирование и обслуживание инфраструктуры связано с выполняемыми вручную процессами, которые сложно отследить и которые приводят к возникновению ошибок.
Идемпотентность является принципом инфраструктуры в виде кода. Идемпотентность — это свойство, которое команда развертывания всегда задает целевую среду в той же конфигурации независимо от состояния запуска среды. Идемпотентности достигается либо автоматической настройкой существующего целевого объекта, либо путем удаления существующей цели и повторного создания новой среды.
Соответственно, при использовании IaC команда вносит изменения в описание среды и версию модели конфигурации, которая обычно находится в хорошо документированных форматах кода, таких как JSON. Конвейер выпуска выполняет модель для настройки целевых сред. Если группе необходимо внести изменения, они изменяют источник, а не целевой объект.
IaC предоставляет реальные преимущества
Инфраструктура как код позволяет командам DevOps тестировать приложения в рабочих средах на ранних этапах цикла разработки. Эти команды предполагают, что несколько тестовых сред надежно и по требованию. Инфраструктура, представленная в виде кода, также может быть проверена и протестирована для предотвращения распространенных проблем развертывания. В то же время облако динамически подготавливает и слезами среды на основе определений IaC.
Команды, реализующие IaC, могут быстро доставлять стабильные среды и масштабировать их. Команды избегают ручной настройки сред и обеспечивают согласованность, представляя требуемое состояние своих сред с помощью кода. Развертывания инфраструктуры с IaC являются повторяемыми и предотвращают проблемы во время выполнения, вызванные отклонением конфигурации или отсутствием зависимостей. Команды DevOps могут работать вместе с единым набором практических рекомендаций и средств, позволяющих быстро и надежно предоставлять приложения и их поддерживающую инфраструктуру.
Предпочитать декларативные определения
Предпочтительный подход к IaC — использование файлов декларативного определения, где это возможно. В файле определения указывается, что требует Среда, а не обязательно. Иными словами, он может определить конкретную версию и конфигурацию серверного компонента в качестве требования, но не указывает процесс установки и настройки. Эта абстракция обеспечивает большую гибкость в середине, например оптимизированные методы, которые может использовать поставщик инфраструктуры. Кроме того, это позволяет сократить технические обязательства по обслуживанию императивного кода, такого как сценарии развертывания, которые могут начисляться со временем.
Для декларативного IaC не существует единого стандартного синтаксиса. Различные платформы поддерживают разные и зачастую несколько форматов файлов, таких как YAML, JSON и XML. В результате решение о выборе синтаксиса для описания IaC обычно сводится к требованиям целевой платформы.
Использование IaC в Azure
Azure обеспечивает собственную поддержку IaC с помощью Azure Resource Manager. Команды могут определять декларативные шаблоны, указывающие инфраструктуру, необходимую для развертывания своих решений.
Инфраструктура как код
Облачные системы используют микрослужбы, контейнеры и современные архитектурные системы для достижения максимальной скорости и гибкости. Они предоставляют автоматизированные этапы сборки и выпуска для обеспечения единообразия и качества кода. Но это лишь часть истории. Как подготавливать облачные среды, в которых работают эти системы?
Такие средства, как Azure Resource Manager (ARM), terraform и интерфейс командной строки Azure (CLI), позволяют декларативно создать скрипт для требуемой облачной инфраструктуры.
Шаблоны Azure Resource Manager
ARM означает Azure Resource Manager. Это подсистема подготовки API, встроенная в Azure и предоставляемая в виде службы API. ARM позволяет развертывать, обновлять, удалять и администрировать ресурсы, содержащиеся в группе ресурсов Azure, в одной координированной операции. Вы предоставляете модулю шаблон на основе JSON, который указывает необходимые ресурсы и их конфигурацию. ARM автоматически управляет развертыванием в правильном порядке соблюдения зависимостей. Подсистема гарантирует идемпотентности. Если нужный ресурс уже существует в той же конфигурации, подготовка будет проигнорирована.
Шаблоны Azure Resource Manager — это язык на основе JSON для определения различных ресурсов в Azure. Основная схема выглядит примерно так, как показано на рис. 10-14.
В этом шаблоне можно определить контейнер хранилища в разделе ресурсов следующим образом:
Шаблон ARM может быть параметризован с помощью динамической среды и сведений о конфигурации. Это позволит использовать его повторно для определения различных сред, таких как разработка, контроль качества или рабочая среда. Как правило, шаблон создает все ресурсы в одной группе ресурсов Azure. При необходимости можно определить несколько групп ресурсов в одном шаблоне диспетчер ресурсов. Вы можете удалить все ресурсы в среде, удалив саму группу ресурсов. Анализ затрат также может выполняться на уровне группы ресурсов, что позволяет быстро учитывать объем данных каждой среды.
Существует множество примеров шаблонов ARM, доступных в проекте шаблонов быстрого запуска Azure на GitHub. Они могут помочь ускорить создание нового шаблона или изменение существующего.
Шаблоны диспетчер ресурсов могут выполняться множеством способов. Возможно, самый простой способ — просто вставить их в портал Azure. Для экспериментальных развертываний этот метод может быть быстрым. Они также могут выполняться как часть процесса сборки или выпуска в Azure DevOps. Существуют задачи, которые будут использовать подключения к Azure для запуска шаблонов. Изменения шаблонов диспетчер ресурсов применяются постепенно, то есть для добавления нового ресурса необходимо просто добавить его в шаблон. Средства будут согласовывать различия между текущими ресурсами и теми, которые определены в шаблоне. Ресурсы будут созданы или изменены так, чтобы они совпадали с тем, что определено в шаблоне.
Terraform
Terraform — это коммерческое средство создания шаблонов, которое позволяет подготавливать облачные приложения для всех основных облачных игроков: Azure, Google Cloud Platform, AWS и аликлауд. Вместо использования JSON в качестве языка определения шаблона он использует немного более сжатый HCL (Hashicorp Configuration Language).
Пример файла terraform, который делает то же, что и предыдущий шаблон диспетчер ресурсов (рис. 10-15), показан на рис. 10-16:
Terraform также предоставляет интуитивно понятные сообщения об ошибках для шаблонов проблем. Также есть удобная задача проверки, которую можно использовать на этапе сборки для перехвата ошибок шаблона на раннем этапе.
Как и в случае с шаблонами диспетчер ресурсов, средства командной строки можно использовать для развертывания шаблонов terraform. кроме того, в Azure Pipelines есть задачи, созданные сообществом, которые могут проверять и применять шаблоны Terraform.
Иногда terraform и шаблоны ARM выводят значимые значения, например строку подключения к вновь созданной базе данных. Эти сведения можно записать в конвейер сборки и использовать в последующих задачах.
Azure CLI сценарии и задачи
Azure CLI сценарии хорошо работают, когда необходимо удалить и повторно развернуть инфраструктуру. Обновление существующей среды может быть непростой задачей. Многие команды интерфейса командной строки не идемпотентными. Это означает, что они будут воссоздавать ресурс каждый раз при их запуске, даже если ресурс уже существует. Всегда можно добавить код, который проверяет существование каждого ресурса перед его созданием. Но при этом сценарий может стать чрезмерным и сложным в управлении.
На рис. 10-17 показан фрагмент кода YAML со списком версий Azure CLI и сведений о подписке. Обратите внимание, что команды Azure CLI включены во встроенный скрипт.
в статье понятие » инфраструктура как код», автор Sam гукенхаймера описывает, как «Teams, которые реализуют IaC, могут быстро доставлять стабильные среды и масштабировать их. Teams избежать ручной настройки сред и обеспечить согласованность, представляя требуемое состояние своих сред с помощью кода. Развертывания инфраструктуры с IaC являются повторяемыми и предотвращают проблемы во время выполнения, вызванные отклонением конфигурации или отсутствием зависимостей. DevOps команды могут работать вместе с единым набором практических рекомендаций и средств для быстрой и надежной доставки приложений и их поддерживающих инфраструктуры. «
Инфраструктура как код. Введение для начинающих
Согласно отчету «State of DevOps 2019», 80% респондентов сказали, что основное приложение или служба, которую они поддерживали, было размещено на какой-то облачной платформе. 50% респондентов заявили, что их основное приложение размещено в публичном облаке.
Что такое инфраструктура как код?
Идея состоит в том, что вы относитесь к своей инфраструктуре как к программному обеспечению, а затем пишете, тестируете и выполняете код для определения, развертывания, обновления и уничтожения своей инфраструктуры.
Вы пишете код для управления своими серверами, базами данных, сетями, журналами, развертыванием и настройкой приложений. Когда вы хотите внести изменения в свою инфраструктуру, вы вносите изменения в код, тестируете его, а затем применяете его в своих системах.
Льготы
Инфраструктура как код предоставляет значительные преимущества по сравнению с ручной подготовкой:
Самообслуживание
Поскольку инфраструктура определяется как код, весь процесс и развертывание могут быть автоматизированы и могут быть запущены любым пользователем в команде DevOps. Пользователи инфраструктуры получают ресурсы, которые им нужны, когда им это нужно.
Идемпотентность
Идемпотентность означает, что вы определяете желаемое состояние, и независимо от того, сколько раз вы запускаете скрипт, результат будет одинаковым. Он проверяет текущее и желаемое состояние и применяет только те изменения, которые необходимы. Этого может быть чрезвычайно трудно достичь с помощью скриптов bash.
Такие инструменты, как Ansible и Terraform, имеют встроенные функции, которые делают ваш код идемпотентным.
Снижение затрат
Сокращает время и усилия, необходимые для предоставления, намного меньше, чем подготовка вручную.
Более быстрая доставка программного обеспечения
Быстрое предоставление инфраструктуры для разработки, тестирования и производства позволяет значительно быстрее доставлять программное обеспечение. Поскольку процесс развертывания автоматизирован, он также последовательный и повторяемый.
Самодокументирование
Состояние инфраструктуры определяется в коде, который легко читается любым человеком.
Контролируемая версия
Традиционно изменения в производственных системах считаются рискованными. Но тогда изменения неизбежны. Вам может потребоваться добавить новую базу данных при добавлении новой функции. Вам может потребоваться добавить новые серверы или хранилище в кластер. Инфраструктура как код уменьшает усилия и риск внесения изменений в инфраструктуру.
Вы можете проверить свои исходные файлы в системе управления версиями, что означает, что вы можете отслеживать все изменения, внесенные в инфраструктуру, и быстро возвращаться к предыдущей версии, если что-то сломается.
Валидация и тестирование
Инфраструктура как код позволяет постоянно тестировать и применять небольшие изменения. Поскольку все является кодом, вы можете проверять ошибки, используя статический анализ и автоматические тесты.
Улучшенная безопасность
Переход к инфраструктуре в виде кода позволяет встроить систему безопасности с самого начала, а затем вы можете надежно и безопасно применять изменения.
Инфраструктура как инструменты кода
Несмотря на то, что доступно много инструментов, выбрать один из них для работы может быть нелегко. Ниже приведены некоторые соображения, которые могут оказаться полезными:
Управление конфигурацией и инструменты обеспечения
В целом доступные инструменты подпадают под две категории:
Инструменты управления конфигурацией
Вы можете использовать инструменты управления конфигурацией для установки и обновления программного обеспечения на серверах.
Инструменты обеспечения
Terraform, CloudFormatio, OpenStack Heat, с другой стороны, являются инструментами обеспечения, т.е. Используются для создания серверов, серверов баз данных, балансировщиков нагрузки, очередей, подсетей, брандмауэров и всех других компонентов вашей инфраструктуры. Эти инструменты делают API-вызовы к провайдерам для создания необходимой инфраструктуры.
Изменчивая и неизменная инфраструктура
После многих обновлений каждый сервер, вероятно, будет немного отличаться от других, что приведет к смещению конфигурации. Например, некоторые изменения, которые отлично работают на тестовых серверах, могут не работать на производственных серверах.
Такие инструменты, как Terraform и CloudFormation, предназначены для того, чтобы каждый раз создавать новый сервер из образа машины или образа контейнера. Если необходимо обновить серверы, вы замените их новыми серверами.
Когда новые серверы работают, вы можете отключить старые. Каждое развертывание использует неизменяемый образ для создания сервера, что позволяет избежать смещения конфигурации.
Императивные и декларативные инструменты
Обязательные инструменты похожи на скрипты. Вы перечисляете шаги, которые необходимо предпринять для достижения желаемого состояния. Декларативные инструменты позволяют вам указать конечное состояние, и инструмент разрабатывает шаги для достижения этого состояния.
В то время как Chef является в первую очередь императивным инструментом, Ansible использует гибридный подход и поддерживает как императивные, так и декларативные методы.
Terraform, CloudFormation, Puppet, OpenStack Heat и SaltStack принадлежат к категории декларативных инструментов, в которой вы объявляете желаемое конечное состояние.
Использование нескольких инструментов вместе
Хотя каждый из этих инструментов может использоваться самостоятельно, общий подход состоит в том, чтобы использовать их вместе. Например, вы можете использовать Terraform для создания VPC, подсетей, интернет-шлюзов, балансировщиков нагрузки и виртуальных машин, а затем использовать Ansible для настройки и развертывания служб в этих экземплярах.
Заключение
Инфраструктура как код, выигрываем на масштабе (Кирилл Ветчинкин, TYME)
Модель «Инфраструктура как код (IaC)», которую иногда называют «программируемой инфраструктурой», — это модель, по которой процесс настройки инфраструктуры аналогичен процессу программирования ПО. По сути, она положила начало устранению границ между написанием приложений и созданием сред для этих приложений. Приложения могут содержать скрипты, которые создают свои собственные виртуальные машины и управляют ими. Это основа облачных вычислений и неотъемлемая часть DevOps.
Инфраструктура как код позволяет управлять виртуальными машинами на программном уровне. Это исключает необходимость ручной настройки и обновлений для отдельных компонентов оборудования. Инфраструктура становится чрезвычайно «эластичной», то есть воспроизводимой и масштабируемой. Одни оператор может выполнять развертывание и управление как одной, так и 1000 машинами, используя один и тот же набор кода. Среди гарантированных преимуществ инфраструктуры как кода — скорость, экономичность и уменьшение риска.
Как раз об этом расшифровка доклада Кирилла Ветчинкина на DevOpsDays Moscow 2018. В докладе: переиспользование модулей Ansible, хранение в Git, ревью, пересборка, финансовые выгоды, горизонтальное масштабирование в 1 клик.
Кому интересно, прошу под кат.
Всем привет. Как уже говорили, я Ветчинкин Кирилл. Я работаю в компании TYME и сегодня мы с вами поговорим про инфраструктуру как код. Также поговорим о том, как мы научились экономить на этой практике, потому что она достаточно дорогая. Писать много кода, для настройки инфраструктуры достаточно затратно.
Вкратце расскажу о компании. Я работаю в компании TYME. У нас произошел ребрендинг. Сейчас мы называемся PaySystem — как видно из названия, мы занимаемся платежными системами. У нас есть как собственные решения — это процессинги, так и заказная разработка. Заказная разработка — это электронные банки, биллинги и тому подобные вещи. И как вы понимаете, если это заказная разработка, то это каждый год большое количество проектов. Проект идет за проектом. Чем больше проектов, тем больше однотипной инфраструктуры приходится поднимать. Поскольку проекты зачастую высоконагруженные, то мы применяем микросервисную архитектуру. Поэтому в одном проекте содержится еще много-много маленьких подпроектов.
Соответственно, всем этим зоопарком управлять без полноценного DevOps весьма сложно. Поэтому в нашей компании внедрили различные практики DevOps. Естественно, мы работаем по kanban, по SCRUM, все храним в git. После того, как закоммитили, идет непрерывная интеграция, прогоняются тесты. Тестировщики пишут на PyTest end-to-end тесты, которые каждую ночь стартуют. Unit-test стартуют после каждого коммита. Мы используем раздельный процесс сборки и деплоя: собрали, потом много раз деплоим на различные среды. Мы были на windows. На windows мы деплоили с помощью Octopus deploy, В этом году мы разрабатываем на DotNet Core. Поэтому мы имеем возможность теперь запускать ПО на Linux системах. Мы ушли от Octopus и пришли к Ansible. Сегодня мы поговорим об этой части, представляющей из себя новую практику, которую мы развили в этом году, то чего у нас раньше не было. Когда у вас есть тесты, когда вы умеете хорошо собирать приложение, деплоить его куда-то — все прекрасно. Но если у вас две среды настроены по-разному, то вы все равно упадете, причем упадете на production. Поэтому управлять конфигурациями это очень важная практика. Вот о ней мы сегодня будем говорить.
Вкратце расскажу как вообще строится экономика продукта по трудозатратам: 60 процентов у нас тратиться на разработку, аналитика занимает где-то 10 процентов, QA (тестирование) занимает около 20 процентов и все остальное как раз отводится на конфигурирование. Когда системы идут целым потоком, в них многие стороннее ПО, сами операционные системы настраиваются практически одинаково. Мы на это тратим лишнее время, делая по сути одно и тоже. Появилась идея это все автоматизировать и снизить издержки на конфигурирование инфраструктуры. Однотипные задачи автоматизированы, хорошо отлажены и не содержат ручных операций.
Каждое приложение работает в каком-то окружении. Давайте посмотрим, из чего это все состоит. У нас как минимум должна быть операционная система, ее нужно сконфигурировать, есть какие-то сторонние приложения, которые тоже нужно сконфигурировать, само приложение должно получить конфигурации, но чтобы весь продукт заработал, должно запуститься само приложение, которое во всей этой системе функционирует. Есть еще сеть, которую тоже нужно настраивать, но про сеть мы сегодня говорить не будем, потому что у нас разные заказчики, разные сетевые устройства. Мы пытались тоже автоматизировать конфигурирование сети, но поскольку устройства разные, никакого особо толку от этого не было, больше тратили ресурсов на это. Но операционные системы, сторонние приложения и передачу конфигурационных параметров в сами приложения мы автоматизировали.
Два подхода как вы можете конфигурировать сервера: руками — если вы конфигурируете их руками, у вас соответственно может получиться такая ситуация, что у вас production настроен одним образом, тест другим, на тесте все зеленое, тесты зеленые. Вы деплоите на production, а там не стоит какой-то фреймворк — у вас ничего не работает. Другой пример: три Application сервера настроены руками. Один Application сервер настроили одним образом, другой Application сервер другим образом. Сервера могут работать по-разному. Еще пример: была ситуация, когда у нас один Stage сервер полностью перестал работать. Запустили создание нового сервера используя и через 30 сервер был готов. Еще пример: сервер просто перестал работать. Если настраивали руками, то нужно искать человека, который знает как его настраивать, нужно поднимать документацию. Как мы знаем, документация вряд ли бывает актуальной. Это большие проблемы. И, самое главное, — это аудит, то есть грубо говоря, у вас есть десять администраторов, каждый из них что-то руками настраивает, то не особо понятно корректно они это настроили или некорректно, и как вообще понять, нужно ли делать какие-то настройки, могли что-то лишнее поставить, открыть какие-то ненужные порты.
Есть альтернативный вариант — это как раз то, про что мы сегодня говорим — это конфигурирование из кода. То есть у нас есть git репозиторий, в котором вся инфраструктура хранится. Там хранятся все скрипты, с помощью которых мы будем это настраивать. Поскольку это все в git, мы получаем все преимущества от управления кодом, как в разработке, то есть мы можем делать ревью, аудит, историю изменений, кто сделал, почему сделал, комментарии, можем откатываться. Чтобы работать с кодом нужно использовать конвейер непрерывной сборки — конвейер развертывания. Чтобы какая-то система именно вносила изменения в сервера, то есть не человек что-то руками делал, а исключительно делала это система.
В качестве системы, которая вносит изменения, мы используем Ansible. Поскольку у нас нет огромного количества серверов, он нам вполне подходит. Если у вас там 100-200 серверов, то у вас будут небольшие проблемы, потому что он (т.е. Ansible) все-таки соединяется с каждым и по очереди их настраивает — это проблема. Лучше другие средства использовать, которые не пушат (push), а пулят (pull). Но для нашей истории, когда у нас много проектов, но серверов не больше 20 — нам это вполне подходит. У Ansible большой плюс — это низкий порог вхождения. То есть буквально любой ИТ-специалист за три недели может его полностью освоить. У него много модулей. То есть вы можете управлять облаками, сетями, файлами, установкой программ, деплоем — абсолютно всем. Если нет модулей, вы можете написать свой собственный, вы можете в конце концов написать что-то используя модуль Ansible shell или command.
В общем, вкратце рассмотрим как он вообще выглядит, этот инструмент. У Ansible есть модули, про которые я уже говорил. То есть их можно доставлять, самим писать, которые что-то делают. Есть inventories — это куда мы будем накатывать наши изменения, то есть это хосты, их IP адреса, переменные, специфичные для этих хостов. И, соответственно, роли. Роли — это что мы будем накатывать на эти сервера. И также у нас хосты группируются по группам, то есть в данном случае мы видим, что у нас есть две группы: сервера баз данных и сервера приложений. В каждой группе у нас по три машины. Они по ssh соединяются. Таким образом, мы решаем те проблемы, про которые мы говорили раньше, что у нас во первых сервера настроены идентично, поскольку одна и та же роль накатывается на сервера. И точно так же, если эту роль запустим на нескольких машинах, то на каждый тоже она отработает аналогично.
Если мы более глубоко посмотрим на то, как устроен проект Ansible, то здесь мы видим, что вот inventories хосты допустим для production. Вот эта группа указана и в ней два сервера. Если мы зайдем в конкретный сервер, то видим что здесь указан IP адрес этой машины. Также там могут быть указаны другие параметры — переменные, специфичные для этой среды. Если мы посмотрим на роли. То роль содержит несколько задач (task), которые будут выполняться. В данном случае это роль для установки PostgreSQL. То есть мы устанавливаем необходимое приложение, создаем базы данных. Здесь мы используем цикл. Их (базы данных) несколько создастся. Затем мы устанавливаем необходимое соединение — IP адреса, которые могут в этой базе авторизоваться. И, соответственно, настраиваем в самом конце firewall. Настройки будут применены ко всем серверам в группе.
Как раз подходим к самой проблеме: мы отлично научились конфигурировать сервера с помощью Ansible и было все прекрасно. Но, как я уже говорил, у нас множество проектов. Они почти все одинаковы. В каждом проекте участвуют примерно вот такие системы (k8s, RabbitMQ, Vault, ELK, PostgreSQL, HAProxy). Для каждой мы написали свою роль. Мы ее можем накатывать с кнопки.
Но проектов то у нас много и в каждом они по сути пересекаются. То есть в одном такой набор, во втором такой, в третьем такой. У нас получаются точки пересечения, в которых одни и те же роли в разных проектах.
У нас есть репозиторий с приложением, есть репозиторий с инфраструктурой для проекта. У второго проекта точно также. Продолжение инфраструктуры. И у третьего. Если мы будем одно и то же реализовывать, то по сути получится copy-paste. На одну и ту же роль в 10 местах сделаем. Потом, если будет какая-то ошибка, мы будем в 10 местах править.
Что мы сделали: мы каждую роль, которая общая для всех проектов и все ее конфигурации, которые приходят извне, вынесли в отдельный репозиторий и положили их в гит в отдельную папочку — назвали TYME Infrastructure. Там у нас лежит роль для PostgreSQL, для ELK, для развертывания кластеров Kubernetes. Если нам в какой-то проект понадобится поставить допустим тот же PostgreSQL, то просто включаем его как submodule, переписываем inventories, то есть, грубо говоря, конфигурацию куда эту роль накатывать. Саму роль мы не переписываем: она уже есть. И у нас по клику кнопки во всех новых проектах появляется PostgreSQL. Если нужно поднять кластер Kubernetes — то же самое.
Таким образом, получилось снизить издержки на написание ролей. То есть один раз написали — 10 раз использовали. Когда проект идет за проектом — это очень удобно. Но поскольку мы теперь работаем с инфраструктурой как с кодом, нам, естественно, нужны конвейеры, про которые мы говорили. Люди коммитят в git, могут закоммитить какую-то некорректность — нам нужно это все отслеживать. Поэтому у нас построен вот такой pipeline. То есть разработчик коммитит в git скрипты Ansible. TeamСity их трекает и передает в Ansible. Teamcity здесь нужен только по одной причине: во первых, у него визуальный интерфейс (есть бесплатная версия Ansible Tower — AWX, которая решает эту же задачу — прим. ред.) в отличие от Ansible бесплатного и, в принципе, у нас Teamcity как единый CI. Так-то в принципе Ansible имеет модуль, который сам может git трекать. Но в данном случае сделали просто по образу и подобию. И как только он его трэкнул, он передает весь код в Ansible и Ansible соответственно запускает их на integration сервере и меняет конфигурацию. Если этот процесс нарушился, значит мы разбираем что не так, почему плохо написали скрипты.
Второй момент, что есть специфичная инфраструктура, то здесь у нас инфраструктура деплоится отдельно, приложение деплоится отдельно. Но есть специфичную инфраструктура для каждого приложения, то есть которую нужно деплоить перед тем, как мы будем его запускать. Здесь, соответственно, нельзя выносить это в разный pipeline. У вас должно это развертываться в том же контейнере, что и само приложение. То есть, допустим, фреймворки — популярная вещь, когда вам нужно для нового приложения один фреймворк поставить, для другого другой фреймворк поставить. Вот как с данной ситуацией. Либо кэши надо почистить. К примеру, Ansible может также залезть, кэш почистить.
Но здесь мы применяем докер в сочетании с Ansible. То есть специфичная инфраструктура нас находится в докере, неспецифичная в Ansible. И таким образом, мы как бы разделяем вот эту маленькую дельту в докере, все остальное, фундаментальное — в Ansible.
Очень важный момент — если вы катите инфраструктуру через какие-то скрипты, через код, то если у вас все же остаются ручные манипуляции серверами, то это потенциальная уязвимость. Потому что допустим, вы на тестовый сервер поставили java, написали роль ELK, накатили ее. Деплой в тест прошел успешно. Деплоите в production, а там java нет. А java в скрипте вы не указали — деплой в production упал. Поэтому нужно забрать права со всех серверов у администраторов, чтобы они руками туда не залезали и все изменения вносили через git. Весь этот конвейер мы сами проходили. Здесь есть одно но — не надо сильно закручивать гайки. То есть нужно внедрять такой процесс постепенно. Потому что он все еще необкатанный. В нашем случае мы оставили доступ до всех систем у самого главного руководителя администраторов на случай непредвиденных инцидентов. Доступ выдан с условием, что он не будет ничего руками настраивать.
Как происходит разработка? Выкатка в staging, production должна быть без ошибок. У нас что-то может сломаться. Если выкатка в integration окружение будет постоянно падать на ошибках — это будет плохо. Это похоже на отлаживать приложения на удаленной машине. Когда разработчик разрабатывает сначала все на машине, компилирует. Если все компилируется, потом отправляет в репозиторий. Здесь используется такой же подход. Разработчики используют Visual Studio Code с плагинами Ansible, Vagrant, Docker и т.д. Разработчики тестируют свой инфраструктурный код на локальном vagrant. Там поднимается чистая операционная система. Сами скрипты для поднятия этой машины тоже находятся в этом репозитории с инфраструктурой, про которую мы говорили. Разработчик начинает на ней устанавливать FTP-сервер. Если что-то пошло не так, он ее просто удаляет, заново загружает, и заново пытается на нее установить нужное ПО, используя скрипты развертывания. После отладки скриптов развертывания он делает Merge Request в основную ветку. После слияния Merge Request CI раскатывает эти изменения integration сервер.
Поскольку все скрипты это код, то можем писать тесты. Допустим, мы установили PostgreSQL. Хотим проверить работает он или нет. Для этого используем модуль Ansible assert. Сравниваем установленную версию PostgreSQL с версией в скриптах. Таким образом мы понимаем, что установлен, он вообще запущен, он той самой версии, которой мы ожидали.
Мы видим, что тест прошел. Значит наш playbook отработал корректно. Таких тестов можно писать сколько угодно. Они идемпотентные. Идемпотентность (операция, которая если применяется к любому значению несколько раз — всегда получается то же значение, как и при однократном применении). Если вы пишите свобственные скрипт по установке, настройке, то убедитесь что ваши скрипты всегда получает то же значение, если запускать их несколько раз.
Есть еще другой тип тестов, которые к тестированию инфраструктуры напрямую не относятся. Но они как бы косвенно затрагивают его. Это end-to-end тесты. У нас инфраструктура и сами приложения устанавливаются на один и тот же сервер, который тестировщики тестируют. Если мы накатили какую-то некорректную инфраструктуру, то у нас просто комплексные тесты не пройдут. То есть наше приложение будет работать как-то неправильно. В данном примере мы на production установили новую версию — приложение работает. Затем был сделан commit в git и end-to-end тесты, которые проходит по ночам, отследили, что вот здесь у нас отсутствует файл на ftp. Разбираем этот кейс и видим, что проблема именно в настройках ftp. Мы исправляем скрипты в коде, снова деплоим и все становится зеленым. Такая же история с кодом. Код инфраструктуры и инфраструктура так или иначе косвенно тестируется. Мы ее можем потом деплоить на production.
Когда мы этот подход внедрили, CI (Teamcity), который выкатывал изменения на integration сервер падал 8 раз из 10. Никто не обращал на это внимания, потому что не было обратной связи. У разработчиков эти процессы достаточно давно были внедрены, а до OPS (системных администраторов) сообщения не доходили. Поэтому мы добавили Dashboard со сборками данного проекта на большой монитор в самом видном месте в офисе. На нем различные проекты выделены зеленым — это значит, что с ним все в порядке. Если выделены красным значит, что с ним все плохо. Мы видим, что некоторые тесты не прошли. На презентации в левой стороне второй сверху видим результат инфраструктурых деплойных тасок. Инфраструктурные деплойные таски зеленые. Это значит, что все тесты пройдены, никаких дефектов не было, они успешно собрались. Оповещение: Допустим ИТ-специалист запустил скрипт и отошел. Если коммит все сломал. Ему в канал Slack приходит оповещение о том, что вот такой-то ИТ-специалист таким-то коммитом сломал наш проект.
Ok, мы сейчас говорили про то, как мы разрабатываем, как мы коммитим какие-то тестовые среды, как мы вообще выкатывает это дальше на другие среды. Мы используем trunk based подход. Поэтому здесь Master ветка — это основная ветка разработки. При коммите в Master ветку CI сервер (Teamcity) выкатывает изменения на integration сервер. Если таска в CI сервере зеленая, то тогда мы пишем тестировщикам что можно тестировать продукт на integration сервере. Формируем release candidate. На тестовом сервере эта конфигурация появляется. Ее тестировщики могут тестировать вместе с самими приложениями. Если все ок, если end-to-end тесты пройдены, мы уже можем саму конфигурацию и приложение выкатывать на staging окружение. Затем можем выкатывать на production. За счет таких вот разноуровневых барьеров мы достигаем того, что staging окружение у нас всегда зеленое.
Сравним управление инфраструктурой из кода и настройка инфраструктуры руками. Какая экономика? Данный график показывает, как мы устанавливали PostgreSQL. Управление инфраструктурой из кода получилось 5 раз дороже на раннем этапе. Все скрипты необходимо написать, оталадить руками. Этой займет 1-2 часа. Со временем появляется опыт написания этих скриптов. Сравним установку, настройку PostgreSQL час руками и используя скрипт развертывания. Поскольку скрипты разверывания и настройки PostgreSQL уже написаны, то деплоится на staging, production 4 минуты. Чем больше сред, чем больше машин, то вы начинаете выигрывать по трудозатратам в настройке инфраструктуре. И если у вас один проект и одна база данных, то вам дешевле это делать руками. То есть это интересно только когда у вас масштабные какие-то проекты.
Мы внедрили git submodule позволяем несколько раз использовать Ansible роль. Нам второй раз не писать не нужно, она уже есть. Добавляем git submodule с Ansible ролью добавляем в проект. Пишем в inventories сервера, куда эту роль деплоить. Это занимает 30 минут. В случае использования git submodule трудозатраты на написание скриптов развертывания сильно обогнал ручные операции.
Про идентичность сред: здесь я не готов сказать, сколько у нас было ошибок до этого и сколько стало потом. Но хочу сказать, что при соблюдении всех правил, про которые мы сегодня говорили, у нас staging настроен точно так же, как и тест. Поскольку, если тест разваливается, мы уничтожаем машину, заново пытаемся настроить, и только тогда, когда она становится зеленая, накатывается все дело на staging. Сколько руками ошибок делает ваша команда — вы можете сами подумать, посчитать, у каждого наверняка какой-то свой порог.
На графике видны итоги за 6 месяцев. Трудозатраты — сложность по 10 бальной шкале. Первые два месяца мы просто писали эти роли очень больно и долго. Потому что это была новая система. Когда мы их написали, график пошел вниз. Где-то в середине внедрили git submodule, когда мы уже написанные роли стали переиспользовать разных проектов. Это привело к резкому спаду трудозатрат. Если сравнивать с ручной настройкой проекта, по которому данная оценка делалась, то руками мы настраивали три дня, с помощью подхода инфраструктуры как код настраивал около месяца. В перспективе, использование подхода инфраструктура как код более эффективен, чем настройка серверов руками.
Выводы.
Во-первых, мы получили документацию, то есть когда приходит менеджер и меня спрашивает: на каком порту у нас слушает база данных, я открываю Ansible скрипт в git репозитории, говорю: “Вот смотри, вот на таком-то порту”. Какие у нас здесь настройки? Все это видно в git репозитории. Это можно аудировать, показывать менеджерам и так далее. Это 100% достоверная информация. Документация устаревает. А в данном случае ничего не устаревает.
Важный момент, про который мы не говорили. Про него косвенно скажу. Есть команды разработки, которым локально тоже нужно поднимать RabbitMQ, ELK, чтобы протестироварь различные идеи. Если они будут делать руками, то поднятие ELK может занять больше часа. При использовании подхода инфраструктура как код разработчик поднимает виртуалку, нажимает кнопку, и у него устанавливается ELK. Если разработчик сломал ELK, то он может удалиль, запустить снова установку ELK на виртуалку.
Как мы уже говорили, это все дешевле только, когда у вас либо много проектов, либо много сред, либо много машин. Если у вас такого нет, то, соответственно, это не дешевле, это дороже. В нашей перспективе в наших проектах это получилось так, что становится дешевле со временем. Поэтому здесь как плюсы так и минусы.
Быстрое восстановление после аварии. Если вы упали, вам нужно искать человека, который может эту машину настроить, который знает, как ее настроить, который помнит, как ее настроить. В данном случае все настройки и скрипты развертывания находятся в git. Даже если человек уволился, перешел в другой проект — все находится в git, все в комментариях, все видно: почему он открывал такой порт, почему ставил такие-то настройки и так далее. Вы все можете легко восстановить.
Количество ошибок снизилось, потому что у нас появились разные барьеры, локальные среды для отслеживания, для разработки и плюс code review. Это тоже немаловажно, потому что разработчики просматривают то, что они делают. Таким образом, они еще продолжают обучаться. Возросла сложность, потому что это, соответственно, новая система, это конвейеры, людям нужно обучаться. Это не то, что как обычно привыкли: прочитали статью и по статье сделали. Здесь немножко другое. Но тем не менее со временем это достаточно легко осваивается. Если полностью посмотреть на освоение, то это где-то три-четыре месяца.
Вопрос задается через приложение, но вопрос не слышно.
Ответ: Роли мы используем последнюю версию, то есть роль выделяем в отдельный git submodule, только когда она уникальна для абсолютно всех систем. Если по ней произошли какие-то коммиты, то мы переходим на latest комит. А вся конфигурация приходит из inventories. То есть роль — это просто то, что будет выполняться. Название базы данных, логин, пароль и т.д. приходит снаружи. Роль — это просто исполняемый алгоритм. Вся конфигурация приходит из самого проекта.
Вопрос: Если у вас какие-нибудь между ролями Ansible транзитивные зависимости и как вы вытягиваете при деплое приложения (роль A зависит от B, B от C и вы когда выкатываете роль A, чтобы она зависимость все сама тянула)? Посредством каких инструментов, если у вас такой есть?
Ответ: В данной парадигме зависимостей таких нет. У нас бывают зависимости от конфигурации. То есть, мы ставим какую-то систему и знаем IP адреса серверов, и в то же самое есть балансировщик, который теперь стал, должен себя как бы вогнать, чтобы балансировать на эти настроенную машину. Это за счет конфигов как бы разруливается. Но, если вы имеете зависимость от модулей, то здесь ничего нет, у нас один свободный, ни от чего не зависит, он самодостаточный. И мы не выносим в общие роли то, что имеет хоть какую-то не общую структуру, то есть, допустим, RabbitMQ могут и в африке RabbitMQ, он ни от чего не зависит. Какую-то специфику мы в докере как храним, те же фреймворки.