Terraform: инфраструктура на уровне кода

•Стандартизированное оформление кода. Ansible требует, чтобы код имел предсказуемую структуру. Это касается документации, структуры файлов и каталогов, параметров с понятными именами, управления конфиденциальными данными и т. д. Если каждый разработчик организует свои специализированные скрипты по-разному, то большинство средств управления конфигурацией имеют набор правил и соглашений, которые упрощают навигацию по коду.

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

Код, который работает корректно независимо от того, сколько раз вы его запускаете, называется идемпотентным. Чтобы сделать идемпотентным bash-скрипт из предыдущего раздела, придется добавить много строчек кода, включая уйму условных выражений. Для сравнения: большинство функций Ansible идемпотентно по умолчанию. Например, роль Ansible web-server.yaml установит сервер Apache только в случае, если он еще не установлен, и попытается его запустить лишь при условии, что он еще не выполняется.

• Распределенность. Специализированные скрипты предназначены для выполнения на одном локальном компьютере. Ansible и другие средства управления конфигурацией специально «заточены» под работу с большим количеством удаленных серверов, как показано на рис. 1.2.

Рис. 1.2. Такие средства управления конфигурацией, как Ansible, способны выполнять ваш код на большом количестве серверов

Например, чтобы применить роль web-server.yml к пяти серверам, нужно сначала создать файл под названием hosts, который содержит IP-адреса этих серверов:

[webservers]

11.11.11.11

11.11.11.12

11.11.11.13

11.11.11.14

11.11.11.15

Далее следует определить такой плейбук (playbook) Ansible:

- hosts: webservers

  roles:

  - webserver

И в конце этот плейбук выполняется:

ansible-playbook playbook.yml

Это заставит Ansible параллельно сконфигурировать все пять серверов. В качестве альтернативы в плейбуке можно указать параметр под названием serial. Это позволит выполнить скользящее развертывание, которое обновит серверы пакетным образом. На­пример, если присвоить serial значение 2, Ansible будет обновлять сразу по два сервера, пока не будут обновлены все пять. Дублирование любой части этой логики в специализированных скриптах потребовало бы написания десятков или даже сотен строчек кода.

Средства шаблонизации серверов

Альтернативой управлению конфигурацией, набира­ющей популярность в последнее время, являются средства шаблонизации серверов, такие как Docker, Packer и Vagrant. Вместо того чтобы вводить кучу серверов и настраивать их, запуская на каждом один и тот же код, средства шаблонизации создают образ сервера, содержащий полностью самодостаточный «снимок» операционной системы (ОС), программного обеспечения, файлов и любых других важных деталей. Затем, как показано на рис. 1.3, этот образ можно будет установить на все ваши серверы, используя другие инструменты IaC.

Рис. 1.3.

С помощью таких средств шаблонизации, как Packer, можно создавать самодостаточные образы серверов. Затем, используя другие инструменты, такие как Ansible, эти образы можно установить на все ваши серверы

 

Рис. 1.4. Существует два вида образов: ВМ (слева) и контейнеры (справа). ВМ виртуализируют оборудование, тогда как контейнеры — только пользовательское пространство

Как видно на рис. 1.4, средства для работы с образами можно разделить на две общие категории.

•Виртуальные машины эмулируют весь компьютер, включая аппаратное обеспечение. Для виртуализации (то есть симуляции) процессора, памяти, жесткого диска и сети запускается гипервизор, такой как VMWare, VirtualBox или Parallels. Преимущество подхода — любой образ ВМ, который работает поверх гипервизора, может видеть только виртуальное оборудование, поэтому он полностью изолирован от физического компьютера и любых других образов ВМ. И он выполняется аналогично во всех средах (например, на вашем компьютере, сервере проверки качества и боевом сервере). Недостаток в том, что виртуализация всего этого оборудования и запуск совершенно отдельной ОС для каждой ВМ требует большого количества ресурсов процессора и памяти, что влияет на время запуска. Образы ВМ можно описывать в виде кода, применяя такие инструменты, как Packer и Vagrant.