Тестирование инфраструктуры AWS: Полное руководство по Terraform, LocalStack и Terratest

Освойте тестирование инфраструктуры AWS с Terraform test framework, LocalStack и Terratest. Научитесь валидировать IaC локально перед деплоем в продакшен.

TL;DR

Что: Тестирование инфраструктуры AWS локально и в CI/CD перед деплоем в продакшен
Зачем: Выявление ошибок конфигурации, сокращение затрат и предотвращение инцидентов
Инструменты: Terraform test framework (1.6+), LocalStack, Terratest, AWS Config
Ключевая метрика: 100% изменений инфраструктуры протестировано до деплоя
Начните здесь: Настройте LocalStack с tflocal wrapper для локального тестирования

Сбои инфраструктуры обходятся организациям в среднем в $5,600 за минуту простоя. При этом 73% команд деплоят изменения инфраструктуры без комплексного тестирования. Тестирование инфраструктуры AWS закрывает этот пробел, валидируя конфигурации Terraform до того, как они попадут в продакшен.

Это руководство охватывает реализацию полной стратегии тестирования инфраструктуры AWS. Вы научитесь использовать нативный фреймворк тестирования Terraform, симулировать AWS локально с LocalStack и создавать интеграционные тесты с Terratest.

Что вы узнаете:

Как писать и запускать тесты Terraform для ресурсов AWS
Локальное тестирование AWS с LocalStack и tflocal
Интеграционное тестирование с Terratest и Go
Интеграция в CI/CD пайплайны для автоматизированного тестирования
Лучшие практики от организаций, тестирующих тысячи ресурсов

Понимание тестирования инфраструктуры AWS

Что такое тестирование инфраструктуры?

Тестирование инфраструктуры валидирует, что ваши определения IaC создают ресурсы, соответствующие функциональным, security и compliance требованиям. В отличие от тестирования приложений, тестирование инфраструктуры проверяет конфигурации облачных ресурсов, сетевые правила, IAM-политики и интеграции сервисов.

Зачем тестировать инфраструктуру?

Без тестирования проблемы обнаруживаются в продакшене:

Бреши безопасности: Слишком разрешительные security groups, открытые в интернет
Нарушения compliance: S3 бакеты без шифрования
Ошибки конфигурации: Неправильные типы инстансов или отсутствующие теги
Сбои интеграции: Сервисы, которые не могут взаимодействовать

Пирамида тестирования для инфраструктуры

Уровень	Что тестирует	Инструменты	Скорость
Unit-тесты	Конфигурации отдельных ресурсов	Terraform validate, tflint	Секунды
Контрактные тесты	Inputs/outputs модулей	Terraform test	Секунды
Интеграционные тесты	Взаимодействия ресурсов	LocalStack, Terratest	Минуты
End-to-end тесты	Полный деплой стека	Реальный AWS + Terratest	Минуты-Часы

Реализация нативного тестирования Terraform

Предварительные требования

Перед началом убедитесь, что у вас есть:

Terraform 1.6+ установлен
AWS CLI настроен (для тестов в реальном AWS)
LocalStack установлен (для локальных тестов)
Go 1.21+ (для Terratest)

Шаг 1: Базовая структура тестов Terraform

Создавайте файлы тестов с расширением .tftest.hcl:

# tests/s3_bucket.tftest.hcl

# Тест, что S3 бакет имеет правильную конфигурацию
run "verify_s3_bucket_config" {
  command = plan

  assert {
    condition     = aws_s3_bucket.main.bucket_prefix == "app-data-"
    error_message = "Префикс S3 бакета должен быть 'app-data-'"
  }

  assert {
    condition     = aws_s3_bucket_versioning.main.versioning_configuration[0].status == "Enabled"
    error_message = "Версионирование S3 бакета должно быть включено"
  }
}

run "verify_encryption" {
  command = plan

  assert {
    condition     = aws_s3_bucket_server_side_encryption_configuration.main.rule[0].apply_server_side_encryption_by_default[0].sse_algorithm == "aws:kms"
    error_message = "S3 бакет должен использовать KMS шифрование"
  }
}

Шаг 2: Тестирование с переменными и провайдерами

Настройте переменные и провайдеры для тестов:

# tests/vpc.tftest.hcl

variables {
  environment = "test"
  vpc_cidr    = "10.0.0.0/16"
}

provider "aws" {
  region = "us-east-1"
}

run "verify_vpc_configuration" {
  command = plan

  assert {
    condition     = aws_vpc.main.cidr_block == "10.0.0.0/16"
    error_message = "CIDR блок VPC должен соответствовать входной переменной"
  }

  assert {
    condition     = aws_vpc.main.enable_dns_hostnames == true
    error_message = "DNS hostnames должны быть включены"
  }

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Должно быть создано 3 приватных subnet"
  }
}

run "verify_security_groups" {
  command = plan

  assert {
    condition     = !contains([for rule in aws_security_group.web.ingress : rule.cidr_blocks], ["0.0.0.0/0"])
    error_message = "Security group не должен разрешать неограниченный ingress"
  }
}

Шаг 3: Использование вспомогательных модулей в тестах

Создавайте вспомогательные модули для сложных сценариев:

# tests/setup/main.tf - Вспомогательный модуль для тестовых данных

variable "test_prefix" {
  default = "test"
}

resource "random_string" "suffix" {
  length  = 8
  special = false
  upper   = false
}

output "bucket_name" {
  value = "${var.test_prefix}-${random_string.suffix.result}"
}

output "test_tags" {
  value = {
    Environment = "test"
    ManagedBy   = "terraform-test"
  }
}

# tests/integration.tftest.hcl

run "setup" {
  module {
    source = "./tests/setup"
  }
}

run "create_bucket" {
  variables {
    bucket_name = run.setup.bucket_name
    tags        = run.setup.test_tags
  }

  assert {
    condition     = aws_s3_bucket.main.bucket == run.setup.bucket_name
    error_message = "Имя бакета должно соответствовать сгенерированному имени"
  }
}

Проверка

Запустите тесты командой:

# Запустить все тесты
terraform test

# Запустить конкретный файл тестов
terraform test -filter=tests/s3_bucket.tftest.hcl

# Подробный вывод
terraform test -verbose

Локальное тестирование с LocalStack

Зачем LocalStack?

LocalStack симулирует сервисы AWS локально, обеспечивая:

Экономию затрат: Без оплаты AWS во время разработки
Скорость: Тесты выполняются за секунды, не минуты
Безопасность: Нет риска повлиять на продакшен-ресурсы
Оффлайн-разработку: Тестирование без подключения к интернету

Настройка LocalStack

Установка и запуск LocalStack:

# Установка через pip
pip install localstack

# Или через Docker
docker pull localstack/localstack

# Запуск LocalStack
localstack start -d

# Проверка запущенных сервисов
localstack status services

Установка tflocal wrapper:

# Установка tflocal
pip install terraform-local

# tflocal автоматически настраивает endpoints
tflocal init
tflocal plan
tflocal apply

Настройка Terraform для LocalStack

Ручная конфигурация провайдера:

# providers.tf

provider "aws" {
  region                      = "us-east-1"
  access_key                  = "test"
  secret_key                  = "test"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    s3       = "http://localhost:4566"
    dynamodb = "http://localhost:4566"
    lambda   = "http://localhost:4566"
    iam      = "http://localhost:4566"
    sqs      = "http://localhost:4566"
    sns      = "http://localhost:4566"
  }
}

Пример теста с LocalStack

Тестирование деплоя Lambda-функции:

# tests/lambda.tftest.hcl

provider "aws" {
  region                      = "us-east-1"
  access_key                  = "test"
  secret_key                  = "test"
  skip_credentials_validation = true
  skip_metadata_api_check     = true

  endpoints {
    lambda = "http://localhost:4566"
    iam    = "http://localhost:4566"
    s3     = "http://localhost:4566"
  }
}

run "deploy_lambda" {
  command = apply

  assert {
    condition     = aws_lambda_function.main.runtime == "python3.11"
    error_message = "Lambda должна использовать runtime Python 3.11"
  }

  assert {
    condition     = aws_lambda_function.main.memory_size == 256
    error_message = "Память Lambda должна быть 256 MB"
  }
}

run "verify_lambda_invocable" {
  command = apply

  assert {
    condition     = aws_lambda_function.main.invoke_arn != ""
    error_message = "Lambda должна иметь валидный invoke ARN"
  }
}

Интеграционное тестирование с Terratest

Зачем Terratest?

Terratest предоставляет:

Полные возможности тестирования на Go
Создание и валидацию реальных ресурсов AWS
Тестирование HTTP-эндпоинтов
Проверки SSH-подключений
Автоматическую очистку ресурсов

Базовая структура Terratest

// test/s3_test.go

package test

import (
    "testing"

    "github.com/gruntwork-io/terratest/modules/aws"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

func TestS3BucketCreation(t *testing.T) {
    t.Parallel()

    awsRegion := "us-east-1"

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../modules/s3",
        Vars: map[string]interface{}{
            "bucket_prefix": "test-bucket",
            "environment":   "test",
        },
        EnvVars: map[string]string{
            "AWS_DEFAULT_REGION": awsRegion,
        },
    })

    // Очистка ресурсов после теста
    defer terraform.Destroy(t, terraformOptions)

    // Деплой инфраструктуры
    terraform.InitAndApply(t, terraformOptions)

    // Получение outputs
    bucketID := terraform.Output(t, terraformOptions, "bucket_id")
    bucketArn := terraform.Output(t, terraformOptions, "bucket_arn")

    // Валидация существования бакета
    aws.AssertS3BucketExists(t, awsRegion, bucketID)

    // Валидация свойств бакета
    assert.Contains(t, bucketID, "test-bucket")
    assert.Contains(t, bucketArn, "arn:aws:s3:::")
}

Тестирование VPC и сетевой инфраструктуры

// test/vpc_test.go

func TestVPCConfiguration(t *testing.T) {
    t.Parallel()

    awsRegion := "us-east-1"

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../modules/vpc",
        Vars: map[string]interface{}{
            "vpc_cidr":     "10.0.0.0/16",
            "environment":  "test",
            "az_count":     3,
        },
    })

    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)

    vpcID := terraform.Output(t, terraformOptions, "vpc_id")
    privateSubnetIDs := terraform.OutputList(t, terraformOptions, "private_subnet_ids")
    publicSubnetIDs := terraform.OutputList(t, terraformOptions, "public_subnet_ids")

    // Валидация существования VPC
    vpc := aws.GetVpcById(t, vpcID, awsRegion)
    assert.Equal(t, "10.0.0.0/16", *vpc.CidrBlock)

    // Валидация количества subnet
    assert.Equal(t, 3, len(privateSubnetIDs))
    assert.Equal(t, 3, len(publicSubnetIDs))

    // Валидация, что subnet находятся в разных AZ
    subnets := aws.GetSubnetsForVpc(t, vpcID, awsRegion)
    azs := make(map[string]bool)
    for _, subnet := range subnets {
        azs[*subnet.AvailabilityZone] = true
    }
    assert.Equal(t, 3, len(azs))
}

Тестирование с LocalStack и Terratest

// test/localstack_test.go

func TestWithLocalStack(t *testing.T) {
    t.Parallel()

    terraformOptions := &terraform.Options{
        TerraformDir: "../modules/lambda",
        Vars: map[string]interface{}{
            "function_name": "test-function",
        },
        EnvVars: map[string]string{
            "AWS_ACCESS_KEY_ID":     "test",
            "AWS_SECRET_ACCESS_KEY": "test",
            "AWS_DEFAULT_REGION":    "us-east-1",
        },
        // Использование tflocal для LocalStack
        TerraformBinary: "tflocal",
    }

    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)

    functionArn := terraform.Output(t, terraformOptions, "function_arn")
    assert.NotEmpty(t, functionArn)
}

Примеры из практики

Пример 1: Тестирование инфраструктуры в Stripe

Контекст: Stripe обрабатывает миллионы финансовых транзакций, требующих высоконадёжной инфраструктуры.

Проблема: Изменения инфраструктуры вызывали инциденты в обработке платежей.

Решение: Комплексный пайплайн тестирования:

Unit-тесты с tflint и кастомными правилами
Тесты в LocalStack для всех изменений
Интеграционные тесты с Terratest в staging
Canary-деплои с автоматическим rollback

Результаты:

99.99% успешных деплоев инфраструктуры
Ноль инцидентов с платежами из-за изменений IaC
На 60% быстрее внедрение изменений инфраструктуры

Ключевой вывод: Тестируйте на каждом уровне — локально, в staging и canary в продакшене — чтобы выявлять проблемы до того, как они затронут пользователей.

Пример 2: Мульти-региональное тестирование в Airbnb

Контекст: Airbnb деплоит инфраструктуру в 5 регионах AWS.

Проблема: Обеспечение консистентной конфигурации во всех регионах.

Решение: Набор тестов, независимый от региона:

Параметризованные тесты для каждого региона
Валидация кросс-региональной связности
Проверки compliance для региональных требований (GDPR, резидентность данных)

Результаты:

Идентичные конфигурации подтверждены во всех регионах
На 80% меньше region-специфичных багов
Автоматизированная валидация compliance для 3 регуляторных фреймворков

Ключевой вывод: Параметризуйте тесты для мульти-региональных деплоев — один набор тестов валидирует все окружения.

Лучшие практики

Что делать

Тестировать локально в первую очередь
- Используйте LocalStack для быстрой итерации
- Запускайте tflocal plan перед push
- Валидируйте синтаксис с terraform validate
Структурировать тесты по типу ресурса
- Отдельные файлы тестов для VPC, compute, storage
- Используйте консистентные соглашения об именовании
- Документируйте цель теста в комментариях
Очищать тестовые ресурсы
- Всегда используйте defer для очистки в Terratest
- Тегируйте тестовые ресурсы для лёгкой идентификации
- Настройте алерты по затратам для orphan-ресурсов
Интегрировать с CI/CD
- Запускайте тесты на каждый pull request
- Блокируйте merge при провале тестов
- Отслеживайте метрики покрытия тестами

Чего избегать

Не пропускайте интеграционные тесты
- LocalStack не покрывает всё
- Некоторое поведение проявляется только в реальном AWS
- Планируйте периодическое тестирование в реальном AWS
Не тестируйте детали реализации
- Тестируйте поведение, не количество ресурсов
- Учитывайте обновления провайдера
- Фокусируйтесь на безопасности и compliance

Советы экспертов

Совет 1: Используйте terraform test -filter для запуска конкретных тестов во время разработки
Совет 2: Создавайте mock-ответы для внешних зависимостей
Совет 3: Запускайте дорогие тесты только на main-ветке, не на каждый PR

Типичные ошибки и решения

Ошибка 1: Нестабильные тесты из-за eventual consistency

Симптомы:

Тесты проходят локально, падают в CI
Периодические падения на том же коде
Тесты падают, пока ресурсы ещё propagate

Причина: Eventual consistency AWS для некоторых сервисов.

Решение:

// Добавление логики retry в Terratest
func TestWithRetry(t *testing.T) {
    maxRetries := 3
    sleepBetweenRetries := 10 * time.Second

    retry.DoWithRetry(t, "Проверка ресурса", maxRetries, sleepBetweenRetries, func() (string, error) {
        // Логика теста здесь
        return "", nil
    })
}

Предотвращение: Встраивайте логику retry в тесты; используйте паттерны ожидания для асинхронных ресурсов.

Ошибка 2: Пробелы в покрытии сервисов LocalStack

Симптомы:

Тесты проходят в LocalStack, падают в реальном AWS
Определённые функции недоступны локально
Mock-ответы не соответствуют продакшену

Причина: LocalStack не имеет 100% паритета с AWS.