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

Указанные модули не корневые и не предназначены для развертывания напрямую. Чтобы их развернуть, нужно написать какой-то код Terraform, подключить нужные вам аргументы, сконфигурировать поля provider и backend и т. д. Для этого можно создать папку examples, которая будет содержать примеры использования ваших модулей. Попробуем это сделать.

Создайте файл examples/asg/main.tf следующего содержания:

provider "aws" {

  region = "us-east-2"

}

module "asg" {

  source = "../../modules/cluster/asg-rolling-deploy"

  cluster_name  = var.cluster_name

  ami           = "ami-0c55b159cbfafe1f0"

  instance_type = "t2.micro"

  min_size           = 1

  max_size           = 1

  enable_autoscaling = false

  subnet_ids = data.aws_subnet_ids.default.ids

}

data "aws_vpc" "default" {

  default = true

}

data "aws_subnet_ids" "default" {

  vpc_id = data.aws_vpc.default.id

}

Этот фрагмент кода развертывает группу ASG с одним сервером, применяя модуль asg-rolling-deploy. Попробуйте выполнить команды terraforminit и terraformapply и убедитесь, что все работает без ошибок и ASG действительно создается. Теперь добавьте файл README.md с данными инструкциями, после чего этот крошечный пример станет куда более мощным. С помощью всего нескольких файлов и строк кода вы получаете следующее.

•Механизм ручных тестов. Этот демонстрационный код можно использовать при работе над модулем asg-rolling-deploy, развертывая и удаляя его по много раз путем ручного выполнения команд terraformapply и terraformdestroy. Это позволит убедиться в его предсказуемом поведении.

• Механизм автоматических тестов. Как вы увидите в главе 7, с помощью этого демонстрационного кода можно также создавать автоматические тесты для ваших модулей. Советую размещать тесты в папке test.

• Исполняемая документация. Если сохранить этот пример (вместе с файлом README.md) в системе управления версиями, каждый член вашей команды сможет его найти и понять с его помощью, как работает ваш модуль. Это также позволит запускать модуль без написания какого-либо кода. Таким образом, вы предоставляете своей команде обучающий материал и вместе с тем можете подтвердить его корректность автоматическими тестами.

У каждого модуля Terraform, который находится в папке modules, должна быть папка examples с соответствующим примером. А у последнего в этой папке должен быть подходящий тест в папке test. У каждого модуля, скорее всего, будет ряд примеров (и, следовательно, несколько тестов), которые иллюстрируют разные конфигурации и сценарии использования. Скажем, для модуля asg-rolling-deploy можно придумать другие примеры, чтобы показать, как он работает с правилами автомасштабирования, как к нему подключать балансировщики нагрузки, как ему назначить пользовательские теги и т. д.

Если все это объединить, структура каталогов типичного репозитория modules будет выглядеть так:

modules

└ examples

   └ alb

   └ asg-rolling-deploy

     └ one-instance

     └ auto-scaling

     └ with-load-balancer

     └ custom-tags

   └ hello-world-app

   └ mysql

└ modules

   └ alb

   └ asg-rolling-deploy

   └ hello-world-app

   └ mysql

└ test

   └ alb

   └ asg-rolling-deploy

   └ hello-world-app

   └ mysql

В качестве упражнения предлагаю вам превратить код RDS, который вы написали, в модуль MySQL и добавить к модулям alb, asg-rollingdeploy, mysql и hello-world-app множество разных примеров.

Разработку нового модуля крайне полезно начинать с написания демонстрационного кода. Если сразу заняться реализацией, можно легко погрязнуть в деталях, и к моменту, когда вы вернетесь к API, ваш модуль будет малопонятным и сложным в применении. Если же вы начнете с кода примера, у вас будет возможность подумать об опыте использования, выработать для своего модуля аккуратный API и затем вернуться к реализации. Поскольку код примера и так служит основным способом тестирования модуля, такой подход является разновидностью разработки через тестирование (Test-Driven Development, TDD); подробнее о тестировании мы поговорим в главе 7.

Существует еще один подход, который вы сможете оценить по достоинству, как только начнете регулярно тестировать свои модули: закрепление версий. Вы должны закрепить все свои модули за определенной версией Terraform, используя аргумент required_version. Как минимум следует требовать конкретную мажорную версию Terraform:

terraform {

  # Требуем любую версию Terraform вида 0.12.x

  required_version = ">= 0.12, < 0.13"

}

Этот код позволит использовать для вашего модуля только версии Terraform ви­да 0.12.x, но не 0.11.x или 0.13.x. Это очень важно, потому что при каждом мажорном выпуске Terraform теряет обратную совместимость: например, переход с 0.11.x на 0.12.x требует существенного изменения кода, поэтому вам вряд ли понравится, если такой переход произойдет случайно. Если добавить параметр required_version и попытаться выполнить terraformapply, используя другую версию, сразу же появится ошибка:

$ terraform apply

Error: Unsupported Terraform Core version