Инфраструктура как код

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Инфраструктура как код (англ. Infrastructure-as-Code; Iac) Это подход для управления и описания инфраструктуры ЦОД через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие. Этот подход может включать в себя как декларативный способ описания инфраструктуры, так и через скрипты. Но декларативный подход встречается чаще.

IaC популярен в cloud computing, который называется infrastructure as a service (IaaS). IaC поддерживается IaaS, но их не надо путать. Основная идея IaC подхода это — описывать инфраструктуру кодом, переиспользуя практики из разработки ПО[1].

Обзор[править | править код]

История IaC является симбиозом из двух вещей: простота создания виртуальной инфраструктуры и новой эпохи построения web сайтов. В 2006 был запущен Amazon Web Services Elastic Compute Cloud и Ruby on Rails версии 1.0[2], которые позволили поднять вопрос масштабирования, с которой ранее сталкивались только огромные компании.[3] С новыми инструментами для решения этой проблемы и появился подход IaC. Идея описания инфраструктуры через код, с последующей возможностью применения практик из разработки программного обеспечения появилась в головах разработчиков и системных администраторов. Идея обходиться с инфраструктурой как с кодом позволила разработчикам молниеносно разворачивать приложения.[4]

Преимущества[править | править код]

Ценность IaC стоит на 3 китах: цена, скорость и уменьшение рисков. Уменьшение расходов относится не только к финансовой составляющей, но и к количеству времени, затрачиваемого на рутинные операции. Принципы IaC позволяют не фокусироваться на рутине, а заниматься более важными задачами. Автоматизация инфраструктуры позволяет эффективнее использовать существующие ресурсы. Также автоматизация позволяет минимизировать риск возникновения человеческой ошибки. Всё это является частью культуры DevOps, которая является миксом из development и operations.[5]

Виды подходов[править | править код]

Существует три подхода декларативный (функциональный), императивный (процедурный) и интеллектуальный. Разница между ними выглядит как 'что' / 'как' / 'почему' . Декларативный подход нацелен на то, чтобы описать, как должна выглядеть целевая конфигурация; императивный сфокусирован на том, какие внести изменения; интеллектуальный описывает, почему инфраструктура должна быть так сконфигурирована.[6].

Методы[править | править код]

Существует два метода применения IaC: 'push' и 'pull' . Основная разница в том, кто инициирует изменение в конфигурации целевого хоста. В pull режиме целевой хост сам инициирует получение своей конфигурации. В push режиме конфигурацию ему присылает управляющий сервер.[7]

Инструменты[править | править код]

Tool Released by Method Approach Written in
Pulumi Pulumi Push Declarative Typescript, Python, Go
Chef Chef (2009) Pull Declarative and imperative Ruby
Otter Inedo Push Declarative and imperative -
Puppet Puppet (2005) Pull Declarative Ruby
SaltStack SaltStack Push and Pull Declarative and imperative Python
CFEngine CFEngine Pull Declarative -
Terraform HashiCorp (2014) Push Declarative Go
DSC Microsoft Push/Pull Declarative/Imperative PowerShell
Ansible / Ansible Tower RedHat (2012) Push Declarative and imperative Python

См. также[править | править код]

Примечания[править | править код]

  1. Goncharov, Lev Что я узнал, протестировав 200 000 строк инфраструктурного кода (20 июня 2019).
  2. Bower, Joseph L.; Christensen, Claton M. Disruptive Technologies: Catching the Wave (англ.) // Harvard Business Review : magazine.
  3. Fletcher, Colin & Cosgrove, Terrence (26 August 2015), Innovation Insight for Continuous Configuration Automation Tools, <http://www.gartner.com/document/3119319?ref=unauthreader> 
  4. Riley, Chris. Version Your Infrastructure (неопр.) // DevOps.com. — 2015. — 12 November. Архивировано 22 марта 2016 года.
  5. Phillips, Andrew Moving from Infrastructure Automation to True DevOps (недоступная ссылка). DevOps.com (14 мая 2015). Дата обращения: 21 сентября 2019. Архивировано 17 октября 2016 года.
  6. Declarative v. Imperative Models for Configuration Management: Which Is Really Better?. Scriptrock.com. Дата обращения: 14 декабря 2015.
  7. Venezia, Paul Puppet vs. Chef vs. Ansible vs. Salt. networkworld.com. Network World (21 ноября 2013). Дата обращения: 14 декабря 2015.