Параметризация закрытого хранилища отчётов

Введение

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

Опирайтесь на первую лабораторную работу по Terraform в AWS и имеющиеся знания о переменных и выходных значениях. Инструменты, доступ и подключение провайдера уже подготовлены; ресурсы из предыдущей VM не используются.

Связь с сертификацией

Развёртывание хранилища среды разработки

На этом шаге вы используете входные переменные и ссылку на ресурс, чтобы создать хранилище отчётов среды разработки из одной конфигурации.

Два подготовленных корневых каталога, report-dev и report-preview, изначально пусты, за исключением файла подключения провайдера. Каждая корневая конфигурация будет хранить собственное локальное состояние. Это отличается от изменения входных значений в одной корневой конфигурации: она по-прежнему управляет ресурсами, уже записанными в её состоянии.

Перейдите в корневой каталог среды разработки и создайте шаблон ресурсов. Переменные environment и report — строковые входные параметры. ${var.environment} вставляет имя среды в имя бакета. Аргумент объекта bucket ссылается на идентификатор ресурса бакета, поэтому Terraform может определить зависимость и сначала создать бакет. content_type сообщает читателям, как интерпретировать байты.

cd /home/labex/project/report-dev
cat > main.tf <<'EOF'
variable "environment" { type = string }
variable "report" { type = string }

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-reports-${var.environment}"
  tags = {
    Project     = "TerraformReports"
    Environment = var.environment
  }
}

resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = var.report
  content_type = "text/csv"
}

output "bucket_name" { value = aws_s3_bucket.reports.id }
output "report_key" { value = aws_s3_object.report.key }
EOF

Создайте файл переменных для этой среды. Escape-последовательность \n обозначает перевод строки в строке отчёта. Отдельное хранение значений позволяет повторно использовать тот же шаблон ресурсов.

cat > dev.tfvars <<'EOF'
environment = "dev"
report      = "orders,12\n"
EOF

Инициализируйте и проверьте эту корневую конфигурацию, затем изучите план. -var-file выбирает файл значений; другое состояние этот параметр не выбирает.

terraform init
terraform validate
terraform plan -var-file=dev.tfvars

Ожидайте добавление двух ресурсов: бакета и его объекта с отчётом. Примените те же входные значения и введите yes в ответ на запрос:

terraform apply -var-file=dev.tfvars

Выходные значения определяют бакет и ключ объекта. Сохраните и выведите эти значения с помощью $(...), которое захватывает вывод команды. -raw выводит строковое значение без кавычек Terraform.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
KEY=$(terraform output -raw report_key)
echo "$KEY"

Прочитайте фактически сохранённый отчёт через AWS, не принимая выходное значение или запись в состоянии за доказательство наличия данных. Ответ содержит ContentType: text/csv; файл назначения содержит сами байты.

aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key "$KEY" \
  dev-downloaded.csv
cat dev-downloaded.csv

Ожидайте orders,12. AWS View также позволяет развернуть reports/current.csv внутри terraform-reports-dev. Оставьте отдельный эталонный отчёт команды без изменений.

Повторное использование шаблона с отдельным состоянием

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

Скопируйте только шаблон ресурсов в подготовленный корневой каталог среды предварительного просмотра. В этом упражнении копируйте только main.tf, потому что каждый подготовленный корневой каталог будет инициализироваться отдельно. Не клонируйте terraform.tfstate или инициализированный каталог .terraform/ для создания другой среды: они могут переносить исходное сопоставление ресурсов и настройки backend. Файл фиксации зависимостей .terraform.lock.hcl отличается: он записывает версии провайдеров и контрольные суммы, может совместно использоваться или храниться в коммитах вместе с конфигурацией и не содержит сопоставления ресурсов среды. В корневом каталоге среды предварительного просмотра уже есть собственный файл подключения провайдера.

cp /home/labex/project/report-dev/main.tf /home/labex/project/report-preview/main.tf
cd /home/labex/project/report-preview
cat > preview.tfvars <<'EOF'
environment = "preview"
report      = "orders,25\n"
EOF

Инициализируйте эту корневую конфигурацию и изучите план среды предварительного просмотра:

terraform init
terraform plan -var-file=preview.tfvars

Снова ожидайте два добавления с именем бакета terraform-reports-preview. Неожиданное удаление бакета среды разработки указывало бы на повторное использование неверного состояния. Примените изменения и введите yes:

terraform apply -var-file=preview.tfvars

Прочитайте выходное значение и отчёт среды предварительного просмотра. Входной параметр среды меняет имя и тег; входной параметр отчёта меняет фактически сохранённые байты.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key reports/current.csv \
  preview-downloaded.csv
cat preview-downloaded.csv

Ожидайте orders,25. Сравните выходные значения и списки ресурсов в состоянии обеих корневых конфигураций с помощью глобального параметра Terraform -chdir, который запускает команду в указанном корневом каталоге, не меняя каталог вашей оболочки:

terraform -chdir=/home/labex/project/report-dev output bucket_name
terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview output bucket_name
terraform -chdir=/home/labex/project/report-preview state list

В обеих корневых конфигурациях есть адреса вроде aws_s3_bucket.reports, но каждый из них сопоставлен с разным бакетом AWS. Убедитесь, что данные среды разработки остались нетронутыми:

aws s3api \
  get-object \
  --bucket terraform-reports-dev \
  --key reports/current.csv \
  dev-retained.csv
cat dev-retained.csv

Ожидайте orders,12. Это независимые локальные состояния, а не рабочие пространства или общий backend. В документации Terraform по входным переменным подробнее объясняется выбор файла переменных.

Удаление обоих собственных хранилищ

На этом шаге вы удалите ресурсы каждой корневой конфигурации, не удаляя эталонный отчёт команды.

При удалении каждой корневой конфигурации нужны её собственные входные значения. Изучите план удаления среды разработки, затем выполните удаление и введите yes. Объект удаляется раньше своего бакета, потому что Terraform знает об их зависимости.

terraform -chdir=/home/labex/project/report-dev plan -destroy -var-file=dev.tfvars
terraform -chdir=/home/labex/project/report-dev destroy -var-file=dev.tfvars

Теперь удалите только ресурсы корневой конфигурации среды предварительного просмотра, снова подтвердив yes:

terraform -chdir=/home/labex/project/report-preview destroy -var-file=preview.tfvars

Каждая операция destroy сообщает об удалении двух ресурсов. Проверьте, что оба сопоставления пусты, а посторонний эталонный отчёт по-прежнему существует:

terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Остаётся только эталонный бакет. Успешное получение списка с аутентификацией доказывает отсутствие удалённых бакетов; ошибка доступа или сети этого не доказывает. Сохраните подготовленные учётные данные до завершения заключительной проверки.

Резюме

Вы повторно использовали шаблон бакета и объекта с двумя файлами переменных, прочитали фактические байты отчётов и Content-Type, сохранили независимость состояния каждой корневой конфигурации и удалили только свои две среды.