Согласно докладу о состоянии DevOps за 2016 год (bit.ly/31kCUYX), организации, применяющие такие методики, как IaC, развертывают код в 200 раз чаще и восстанавливаются после сбоев в 24 раза быстрее, а на реализацию новых функций уходит в 2555 раз меньше времени.
Инструменты IaC можно разделить на пять общих категорий:
• специализированные скрипты;
• средства управления конфигурацией;
• средства шаблонизации серверов;
• средства оркестрации;
• средства инициализации ресурсов.
Наша задача — автоматизировать как можно больше аспектов процесса доставки программного обеспечения. Это означает, что вы будете управлять своей инфраструктурой через код, а не с помощью веб-страницы или путем ввода консольных команд. Такую концепцию обычно называют «инфраструктура как код» (infrastructure as code, или IaC).
Движение DevOps основано на четырех принципах: культуре, автоматизации, измерении и разделении (в англ. языке иногда используется аббревиатура CASM (http://bit.ly/2GS3CR3) — culture, automation, sharing, measurement). Эта книга не задумывалась как комплексный обзор DevOps (рекомендуемая литература приводится в приложении), поэтому сосредоточусь лишь на одном из указанных принципов: автоматизации.
Таким образом, вы докатились до того, что стрижете быка в зоопарке — и все для того, чтобы помыть свою машину.
Специализированные скрипты
Самый простой и понятный способ что-либо автоматизировать — написать для этого специальный скрипт. Вы берете задачу, которая выпол
В следующий раз, когда вы начнете работать над новым модулем, выполните такие действия.
1. Пройдитесь по списку задач для подготовки инфраструктуры промышленного уровня, представленному в табл. 6.2, и определите, какие пункты вы будете реализовывать, а какие нет. Сопоставьте полученный результат с табл. 6.1, чтобы озвучить начальству примерные сроки выполнения.
2. Создайте папку examples и сначала напишите демонстрационный код. Выработайте на его основе максимально удобный и аккуратный API для своих модулей. Создайте по одному примеру для каждого важного сценария применения вашего модуля. Добавьте документацию и предусмотрите разумные значения по умолчанию, чтобы ваш пример было как можно легче развертывать.
3. Создайте папку modules и реализуйте придуманный вами API в виде набора небольших, универсальных и компонуемых модулей. Используйте для этого Terraform в сочетании с другими инструментами, такими как Docker, Packer и bash. Не забудьте закрепить версии Terraform и провайдера.
4. Создайте папку test и напишите автоматические тесты для каждого примера.
Теперь пришло время обсудить написание автоматических тестов для инфраструктурного кода, чем мы и займемся в главе 7.
Как видите, data.external.<NAME>.result содержит ответ в формате JSON, возвращенный внешней программой, и вы можете перемещаться по нему с помощью синтаксиса вида data.external.<NAME>.result.<PATH> (например, data.external.echo.result.foo).
Источник данных external — прекрасный «аварийный люк» на случай, когда вам нужно обращаться к данным в своем коде Terraform и у вас нет такого источника, который бы умел извлекать эти данные. Но не переусердствуйте, используя его и другие «аварийные люки», так как они делают ваш код менее переносимым и более хрупким. Например, источник данных external, который вы только что видели, использует bash. Значит, вы не сможете развернуть этот модуль Terraform из Windows.
Иногда нужен скрипт для извлечения данных и предоставления доступа к ним прямо в коде Terraform. Для этого можно использовать источник данных external, который позволяет выполнить внешнюю команду, реализующую определенный протокол.
Этот протокол работает определенным образом.
• Вы можете передавать данные из Terraform во внешнюю программу, используя аргумент query источника данных external. Внешняя программа может читать эти аргументы из стандартного ввода в виде JSON.
• Внешняя программа может передавать данные обратно в Terraform, записывая JSON в стандартный вывод. Остальной код Terraform может извлекать эти данные из JSON с помощью выходного атрибута result, принадлежащего внешнему источнику данных.
Вот пример:
data "external" "echo" {
program = ["bash", "-c", "cat /dev/stdin"]
query = {
foo = "bar"
}
}
output "echo" {
value = data.external.echo.result
}
output "echo_foo" {
value = data.external.echo.result.foo
}
В этом примере источник данных external используется для выполнения bash-скрипта, который возвращает обратно в стандартный вывод любые данные, полученные из стандартного ввода. Таким образом, любое значение, которое мы передадим через аргумент query, должно вернуться без изменений в виде выходного атрибута result. Вот что получится, когда мы выполним terraformapply для этого кода:
$ terraform apply
(...)
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
echo = {
"foo" = "bar"
}
echo_foo = bar