Фраза «Инфраструктура как код» упоминалась несколько раз за последние две недели в разных контекстах. Что на самом деле означает в практическом смысле иметь инфраструктуру как код?
источник
Фраза «Инфраструктура как код» упоминалась несколько раз за последние две недели в разных контекстах. Что на самом деле означает в практическом смысле иметь инфраструктуру как код?
TL; DR : Инфраструктура как код - это способ автоматизации и резервного копирования вашей среды. В идеальном случае после аварии вы можете полностью и автоматически восстановить инфраструктуру , выделив новые ресурсы, восстановив конфигурацию из репозитория кода и восстановив данные из резервной копии.
Инфраструктура как код опирается на три основных понятия:
Автоматизация управления конфигурацией , называемая непрерывной конфигурацией автоматизации, область, впервые проф. Марк Берджесс
Репозиторий кода для изменений в инфраструктуре, где изменения сначала фиксируются, документируются, проверяются, тестируются, а затем внедряются с помощью автоматизации.
Обеспечение управляемой инфраструктуры . Инфраструктура как услуга (IaaS). Либо через облачные вычисления , частное или управляемое облако или управляемые службы центра обработки данных
Управление конфигурациями в своем 3-м поколении инструментов. Опираясь на CFEngine, в настоящее время широко используется новый набор инструментов для автоматизированного управления конфигурацией. Наиболее популярными в алфавитном порядке являются Ansible, CFEngine, Chef, Puppet, PowerShell DSC и SaltStack . Каждый из них будет иметь язык для описания состояния вашей инфраструктуры, модули кода для применения этих изменений и возможность расширения инструментов, некоторый агент для их выполнения на серверах и центральный репозиторий информации.
Как правило, они будут работать в режиме push или pull, либо подключаясь к серверам из центрального местоположения (-ей), и внося изменения удаленно, либо работая на каждом сервере, и извлекая информацию о состоянии из центрального местоположения, а также в модели клиент / сервер или в распределенной модели. путь.
Важное понятие для системного администратора или инженера надежности сайта , чтобы не вносить изменения непосредственно в инфраструктуру, но пусть автоматизация делать изменения. Все, что сделано человеком вручную, следует считать либо скоропортящимся, поскольку вскоре оно будет исправлено автоматически или в более строгой форме, что нарушит целостность инфраструктуры и приведет к разрушению и восстановлению затронутых компонентов.
Хранилище кода, в идеале отделенное от программного обеспечения, в котором хранится хранилище, будет использоваться для управления всеми изменениями в инфраструктуре и связанной с ней автоматизации. Он должен содержать конфигурационные файлы и шаблоны, Playbooks (Cookbooks), описывающие процесс проверок изменений, Код, расширяющий инструменты автоматизации CM, Предоставление конфигураций, Тесты и оповещения об инфраструктуре, Тесты промежуточного уровня / развертывания, Документация, Руководство (еще не автоматизированное) Описания процессов ,
Важной концепцией является организация экспертных проверок на предмет изменений, наличие записи обо всех изменениях и возможность автоматического возврата к предыдущему состоянию в случае непредсказуемых и / или непроверенных проблем, возможность развертывания в промежуточной среде и тестирования изменений конфигурации, а также возможность автоматического развертывания. изменения без изменений, вызванные человеческой ошибкой.
Управление физической инфраструктурой - это реальная задача, которая выходит за рамки программного обеспечения и требует совсем другого набора навыков. Имея возможность абстрагировать этот слой с помощью облачных вычислений или управляемого центра обработки данных, ваша команда сосредоточится на части управления инфраструктурой, которая повышает ценность для бизнеса.
В то время как облачные вычисления предлагают способ быстрого начала и масштабирования на более позднем этапе, компании часто осознают некоторые преимущества и даже значительную экономию в перемещении частей инфраструктуры в своих собственных центрах обработки данных для гибридной модели. Владение или аренда оборудования не означает, что вам также придется нанимать людей, которые занимаются этим. В таком масштабе вам нужны центры обработки данных, географически распределенные по всему миру, и иметь людей со всеми необходимыми навыками во всех местах будет очень дорого. Полет их по всему миру добавляет высокую задержку к любым изменениям и дополнительный уровень операционной неэффективности, что является еще одной причиной для аутсорсинга управления центром обработки данных.
Важным выводом является то, что управляемая физическая инфраструктура часто забывается или упускается из виду , но не менее важна. Даже если у вас все автоматизировано, вся конфигурация хранится в резервном хранилище кода, если у вас нет способа быстрого предоставления ресурсов , у вас есть огромное узкое место , которое может легко стереть все преимущества, которые вы получили за два других шага. ,
Прежде чем объяснить, что это такое, позвольте мне процитировать действительно хорошее определение прямо из Википедии :
Инфраструктура как код (IaC) - это процесс управления и предоставления вычислительной инфраструктуры (процессы, серверы без поддержки, виртуальные серверы и т. Д.) И их конфигурирование с помощью машинно-обрабатываемых файлов определений, а не физической конфигурации оборудования или использования интерактивной конфигурации. инструменты.
Хорошо, теперь давайте рассмотрим один из таких инструментов IaC, Terraform, чтобы лучше понять концепцию: https://www.terraform.io/
Кроме того, вот что Terraform говорит о себе:
Terraform позволяет безопасно и предсказуемо создавать, изменять и улучшать производственную инфраструктуру. Это инструмент с открытым исходным кодом, который кодирует API-интерфейсы в декларативные файлы конфигурации, которые могут совместно использоваться членами команды, рассматриваться как код, редактироваться, проверяться и корректироваться.
Это означает, что можно кодировать всю инфраструктуру ниже. который включает в себя создание облачных (/ infra) ресурсов, таких как экземпляры сервера, балансировщики нагрузки и т. д., а также полные конфигурации (которые включают основные настройки параметров, параметры безопасности, регионы и т. д.) в виде кода, который может быть редактируемым, версионным и конечно, рецензируемый.
Это пример примера кода Terraform для предоставления ресурсов AWS:
resource "aws_elb" "frontend" {
name = "frontend-load-balancer"
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
instances = ["${aws_instance.app.*.id}"]
}
resource "aws_instance" "app" {
count = 5
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
Бонус PS : Кроме того, необходимо понимать различия между инструментами обеспечения и оркестровки . Разработчики очень часто путают одно с другим и делают ошибку, пытаясь настроить и использовать инструмент, для которого он не предназначен.