Ответ
Да, обязательно. Я считаю тестирование инфраструктурного кода таким же важным, как и тестирование прикладного кода. В моей практике это многоуровневый процесс, интегрированный в CI/CD пайплайн.
-
Статический анализ (linting): Перед любым применением код Terraform проходит проверку
terraform validateиtflint, а также security scanning с помощьюcheckovилиtfsec.# Пример шага в GitLab CI validate: stage: test script: - terraform init -backend=false - terraform validate - tflint --module - checkov --directory . -
Модульное тестирование: Для проверки логики модулей (например, расчета CIDR блоков в VPC модуле) использую Terratest на Go. Это позволяет проверить, что модуль создает ресурсы с ожидаемыми параметрами.
// Пример теста для Terraform модуля func TestVPCCreation(t *testing.T) { terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{ TerraformDir: "../modules/aws-vpc", Vars: map[string]interface{}{ "vpc_cidr": "10.0.0.0/16", }, }) defer terraform.Destroy(t, terraformOptions) // Гарантированное очищение terraform.InitAndApply(t, terraformOptions) vpcId := terraform.Output(t, terraformOptions, "vpc_id") assert.Regexp(t, regexp.MustCompile(`^vpc-`), vpcId) } -
Интеграционное тестирование: После успешного прогона модульных тестов в CI пайплайне разворачивается полноценная тестовая среда (в отдельном аккаунте AWS или проекте GCP). Я использую Kitchen-Terraform для организации таких тестов. После деплоя запускаются Inspec-тесты, которые проверяют, что инфраструктура соответствует спецификации (например, что security groups корректно сконфигурированы, а инстансы запущены).
-
Проверка дрейфа конфигурации (drift detection): В продакшене регулярно запускаю
terraform planв режиме read-only, чтобы выявить несанкционированные изменения вне кода, и получаю алерты, если обнаружен дрейф.
Такой подход позволяет с высокой уверенностью вносить изменения в инфраструктуру и автоматически разворачивать ее в новых окружениях.