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

Вам также необходимо обновить кластер веб-серверов, чтобы он использовал S3 в качестве хранилища. Вы можете просто скопировать и вставить раздел backend из файла global/s3/main.tf без особых изменений, но не забудьте присвоить параметру key путь к папке, в которой находится код веб-сервера: stage/services/webserver-cluster/terraform.tfstate. Таким образом, код Terraform в системе управления версиями и структура ваших файлов состояния будут полностью совпадать и вам будет очевидно то, как они между собой связаны. Модуль s3 использует этот же принцип для установки параметра key.

Такая структура файлов и каталогов упрощает просмотр кода и помогает понять, какие именно компоненты развернуты в той или иной среде. Кроме того, она обес­печивает хорошую степень изоляции между окружениями и между компонентами внутри одного окружения. Благодаря этому, если что-то пойдет не так, это коснется лишь небольшой части вашей инфраструктуры.

Конечно, это свойство в каком-то смысле является и недостатком: разделение компонентов на отдельные папки не дает случайной оплошности нарушить работу всей инфраструктуры, но при этом лишает вас возможности развертывать всю инфраструктуру одной командой. Если бы все компоненты для одного окружения были описаны в одном конфигурационном файле Terraform, вы бы могли запустить все это окружение с помощью единого вызова terraformapply. Но если все компоненты находятся в отдельных папках, нужно выполнить terraformapply в каждой из них. Стоит отметить, что в случае применения Terragrunt вы можете автоматизировать этот процесс с помощью команды apply-all39.

У этой структуры файлов есть еще одна проблема: она усложняет использование зависимостей ресурсов. Приложение имеет прямой доступ к атрибутам базы данных (то есть может сослаться на адрес базы данных через aws_db_instan­ce.foo.address), если код этих двух компонентов находится в одних и тех же конфигурационных файлах Terraform. Но если код приложения и базы данных размещен в разных папках, как я советовал, эта возможность теряется. К счастью, Terraform предлагает решение этой проблемы: источник данных terraform_remote_state.

Источник данных terraform_remote_state

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

Рассмотрим пример. Представьте, что вашему кластеру веб-серверов необходимо взаимодействовать с базой данных MySQL. Обслуживание масштабируемой, безопасной, устойчивой и высокодоступной БД требует много усилий. Вы можете позволить Amazon позаботиться об этом с помощью сервиса RDS (Relational Database Service), как показано на рис. 3.9. RDS поддерживает разнообразные базы данных, включая MySQL, PostgreSQL, SQL Server и Oracle.

Рис. 3.9. Кластер веб-серверов взаимодействует с базой данных MySQL, развернутой поверх Amazon RDS

Базу данных MySQL лучше не объявлять в том же наборе конфигурационных файлов, что и кластер веб-серверов, потому что последний обновляется значительно чаще и вам вряд ли захочется рисковать при каждом таком обновлении. Первое, что вы должны сделать, — это создать новую папку stage/data-stores/mysql и поместить в нее три основных файла Terraform (main.tf, variables.tf, outputs.tf), как показано на рис. 3.10.

Рис. 3.10. Код базы данных в папке stage/data-stores

Вслед за этим создайте ресурс базы данных в файле stage/data-stores/mysql/main.tf:

provider "aws" {

  region = "us-east-2"

}

resource "aws_db_instance" "example" {

  identifier_prefix   = "terraform-up-and-running"

  engine              = "mysql"

  allocated_storage   = 10

  instance_class      = "db.t2.micro"

  name                = "example_database"

  username            = "admin"

  # Как нам задать пароль?

  password            = "???"

}

Сразу под стандартным ресурсом provider в верхней части файла находится новый: aws_db_instance. Он создает базу данных в RDS. Параметры в этом коде настраива­ют RDS для запуска MySQL с хранилищем размером 10 Гбайт на сервере db.t2.mi­­­cro, который имеет один виртуальный процессор, 1 Гбайт памяти и входит в бесплатный тариф AWS.

Обратите внимание, что одним из параметров, которые вы должны передать ресурсу aws_db_instance, является главный пароль к базе данных. Поскольку он конфиденциа­лен, его нельзя прописывать прямо в коде в виде обычного текста! Вместо этого можно воспользоваться одним из двух способов передачи конфиденциальных данных в ресурсы Terraform.