Создание и удаление первого ресурса AWS

Введение

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

Вы уже должны понимать ресурсы Terraform, init, plan, apply, состояние и destroy, а также уверенно редактировать файлы и выполнять запросы к S3 через AWS CLI. Terraform, провайдер AWS и доступ через CLI уже подготовлены. Используйте Terminal для команд и AWS View для наблюдения за хранилищем; личная учётная запись AWS и ключи доступа не нужны. Каждая лабораторная работа начинается в независимой среде.

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

Создание бакета для отчётов

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

Сначала перейдите в подготовленный корневой каталог и запросите регион и сведения об идентичности вызывающего. Корневой каталог содержит одну независимую конфигурацию Terraform с собственным состоянием. Учётная запись вызывающего показывает, в какой учётной записи выполняются запросы провайдера; ARN определяет идентичность, от имени которой отправляется запрос.

cd /home/labex/project/first-aws-resource
aws configure get region
aws sts \
  get-caller-identity
terraform version

Регион — us-east-1. Terraform сообщает версию 1.17.2. Подготовленный доступ не связан с вашей личной учётной записью AWS.

Предоставленный файл provider.tf выбирает провайдер AWS версии 6.14.0, настраивает подготовленное подключение и фиксирует версию Terraform 1.17.2. Провайдер преобразует операции с ресурсами в запросы к AWS API. Его конфигурация уже предоставлена, чтобы вы могли сосредоточиться на управлении ресурсами.

Создайте main.tf со следующей конфигурацией. cat и <<'EOF' записывают всё до завершающего EOF в указанный файл. aws_s3_bucket — тип ресурса AWS, а reports — локальная метка Terraform. Вместе они образуют адрес aws_s3_bucket.reports. Атрибут bucket задаёт имя бакета в AWS, которое отличается от этого адреса. Теги отражают назначение ресурса.

cat > main.tf <<'EOF'
resource "aws_s3_bucket" "reports" {
  bucket = "terraform-first-reports"
  tags = {
    Project = "TerraformReports"
  }
}

output "report_bucket" {
  value = aws_s3_bucket.reports.id
}
EOF

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

terraform init
terraform validate

init устанавливает провайдер фиксированной версии из подготовленного кэша и записывает .terraform.lock.hcl. В реальном проекте храните этот файл фиксации зависимостей вместе с конфигурацией: в нём записаны выбранный провайдер и контрольные суммы пакетов. Он отличается от состояния Terraform, которое сопоставляет адреса ресурсов с идентификаторами развёрнутых ресурсов. Поскольку кэш подготовлен для этой среды Linux, init может предупредить, что контрольные суммы в файле фиксации охватывают только linux_amd64; инициализация всё равно завершится. Проекту, который используется и на других платформах, нужны контрольные суммы и для этих платформ.

Изучите план, прежде чем что-либо создавать:

terraform plan

Ожидайте Plan: 1 to add, 0 to change, 0 to destroy. У некоторых атрибутов указано (known after apply), потому что AWS назначает или возвращает их во время создания. Проверьте имя бакета и тег проекта. План показывает будущие действия; сам бакет он не создаёт.

Примените конфигурацию и введите yes в ответ на запрос подтверждения:

terraform apply

Ожидайте Apply complete! Resources: 1 added, 0 changed, 0 destroyed. Выходное значение report_bucket — terraform-first-reports. В AWS View новый пустой бакет появится рядом с team-reference-reports. Не изменяйте этот эталонный бакет и его объект keep.txt.

После выполнения команд нажмите Continue. Проверка независимо запрашивает AWS и сопоставление в состоянии; одного успешного выполнения команды недостаточно.

Сравнение конфигурации, состояния и AWS

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

Выходное значение получает идентификатор бакета через ссылку на ресурс. state list показывает управляемый адрес, а state show — записанные атрибуты. Эти команды проверяют сопоставление, не изменяя AWS.

terraform output report_bucket
terraform state list
terraform state show aws_s3_bucket.reports

Найдите aws_s3_bucket.reports и его идентификатор terraform-first-reports. Конфигурация описывает желаемый ресурс, в AWS находится сам ресурс, а состояние связывает их. Одна лишь запись в состоянии не доказывает, что ресурс всё ещё существует.

Выполните запросы непосредственно к AWS. get-bucket-location возвращает null для региона S3 us-east-1. ACL должен предоставлять доступ только каноническому пользователю — владельцу; разрешения для публичной группы быть не должно. В этой лабораторной работе создаётся закрытый бакет без добавления публичной политики бакета.

aws s3api \
  get-bucket-location \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-acl \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-tagging \
  --bucket terraform-first-reports

Убедитесь, что тег Project имеет значение TerraformReports. Проверьте, что посторонний отчёт по-прежнему доступен для чтения. Выражение --query выбирает только его длину в байтах, а команда не изменяет сохранённый объект.

aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength
terraform plan

План должен сообщить No changes. Это означает, что провайдер не видит изменений конфигурации для управляемых ресурсов. Это не доказывает соблюдение всех возможных требований безопасности и не проверяет данные отчёта; для этого нужны отдельные проверки. Подробнее можно прочитать о состоянии Terraform и управлении доступом в S3.

Удаление только управляемого ресурса

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

terraform plan -destroy показывает будущее удаление ресурсов из состояния этой корневой конфигурации. Это не означает «удалить все бакеты в учётной записи». Прежде чем продолжать, проверьте адрес и идентификатор бакета:

terraform plan -destroy

Ожидайте Plan: 0 to add, 0 to change, 1 to destroy. Эталонного бакета нет в плане, потому что эта корневая конфигурация им не управляет. Целевой бакет пуст; в следующих лабораторных работах объясняется, почему для хранимых данных и версий нужны отдельные решения о сохранении.

Удалите управляемый бакет и введите yes в ответ на запрос подтверждения:

terraform destroy

Ожидайте Destroy complete! Resources: 1 destroyed. Теперь проверьте состояние и запросите оставшиеся бакеты:

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Список ресурсов в состоянии пуст. В успешно полученном списке бакетов нет terraform-first-reports; team-reference-reports и его отчёт сохранены. Не отключайте настроенный доступ к AWS до завершения заключительной проверки, чтобы ошибку аутентификации нельзя было принять за успешное удаление. Конфигурация и файл фиксации зависимостей остаются доступными, если вы решите создать ресурс снова.

Резюме

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