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

Apply complete! Resources: 0 added, 0 changed, 5 destroyed.

Иными словами, при работе с Terraform каждому разработчику нужны хорошие примеры кода для тестирования и настоящее окружение для разработки (вроде учетной записи AWS), которое служит эквивалентом локального компьютера и используется для выполнения тестов. В процессе ручного тестирования вам, скорее всего, придется создавать и удалять большое количество компонентов инфраструктуры, и это может привести к множеству ошибок. В связи с этим окружение должно быть полностью изолировано от более стабильных сред, предназначенных для финального тестирования и в особенности для промышленного применения.

Учитывая вышесказанное, настоятельно рекомендую каждой команде разработчиков подготовить изолированную среду, в которой вы сможете создавать и удалять любую инфраструктуру без последствий. Чтобы минимизировать вероятность конфликтов между разными разработчиками (представьте, что два разработчика пытаются создать балансировщик нагрузки с одним и тем же именем), идеальным решением будет выделить каждому члену команды отдельную, полностью изолированную среду. Например, если вы используете Terraform в сочетании с AWS, каждый разработчик в идеале должен иметь собственную учетную запись, в которой он сможет тестировать все, что ему захочется55.

Очистка ресурсов после тестов

Наличие множества изолированных окружений необходимо для высокой продуктивности разработчиков, но, если не проявлять осторожность, у вас может накопиться много лишних ресурсов, которые захламят все ваши среды и будут стоить вам круглую сумму.

Чтобы держать расходы под контролем, регулярно чистите свои изолированные среды. Это ключевой вывод о тестировании № 2.

Вам как минимум следует создать в команде такую культуру, когда после окончания тестирования разработчики удаляют все, что они развернули, с помощью команды terraformdestroy. Возможно, удастся найти инструменты для очистки лишних или старых ресурсов, которые можно запускать на регулярной основе (скажем, с помощью cron). Вот некоторые примеры для разных сред развертывания.

•cloud-nuke (http://bit.ly/2OIgM9r). Это инструмент с открытым исходным кодом, который может удалить все ресурсы в вашей облачной среде. Сейчас он поддерживает целый ряд сервисов в AWS (вроде Amazon EC2 Instances, ASG, ELB и т. д.). Поддержка других ресурсов и облаков (Google Cloud, Azure) ожидается в будущем. Его ключевая особенность — возможность удаления всех ресурсов, начиная с определенного возраста. Например, cloud-nuke часто запускают ежедневно с помощью cron, чтобы удалить в каждой изолированной среде все ресурсы старше двух дней. При этом предполагается, что любая инфраструктура, которую разработчик подготовил для ручного тестирования, становится ненужной по прошествии пары суток:

$ cloud-nuke aws --older-than 48h

• Janitor Monkey (http://bit.ly/2M4GoLB). Это инструмент с открытым исходным кодом, чистящий ресурсы AWS по графику, который можно настроить (по умолчанию — раз в неделю). Он поддерживает гибкие правила, которые определяют, подлежит ли ресурс удалению, и даже может отправить владельцу ресурса уведомление за несколько дней до очистки. Это часть проекта Netflix Simian Army, в который также входит инструмент Chaos Monkey для проверки устойчивости приложений. Имейте в виду, что у проекта Simian Army больше нет активной поддержки, но разные его части подхватываются другими командами: например, на смену Janitor Monkey пришел инструмент Swabbie (http://bit.ly/2OLrOLb).

• aws-nuke (http://bit.ly/2ZB8lOe). Это инструмент с открытым исходным кодом для удаления всего содержимого учетной записи AWS. Учетные записи и ресурсы, подлежащие удалению, указываются в конфигурационном файле в формате YAML:

# Регионы для удаления

regions:

- us-east-2

# Учетные записи для удаления

accounts:

  "111111111111": {}

# Удалять только эти ресурсы

resource-types:

  targets:

  - S3Object

  - S3Bucket

  - IAMRole

Запускается aws-nuke следующим образом:

$ aws-nuke -5c config.yml

Автоматические тесты

Осторожно: впереди много кода!

Написание автоматических тестов для инфраструктурного кода — занятие не для слабонервных. Этот раздел  — самая сложная часть книги и требует от читателя повышенного внимания. Если вы просто пролистываете, можете его пропустить. Но если вы действительно хотите научиться тестировать свой инфраструктурный код, закатывайте рукава и готовьтесь к настоящему программированию! Код на Ruby можно не запускать (он нужен лишь для того, чтобы у вас сформировалась общая картина происходящего), а вот код на Go следует записывать и выполнять как можно активней.