Какой провайдер использовали с terraform?

Провайдеры Terraform в моей практике

За более чем 10 лет работы с инфраструктурой как код (IaC) на основе Terraform, я использовал широкий спектр провайдеров для построения комплексных, высокодоступных и отказоустойчивых систем. Мой выбор всегда определялся требованиями проекта, архитектурой и стратегией компании.

Основные облачные провайдеры

В облачных проектах я наиболее интенсивно работал со следующими провайдерами:

• HashiCorp/AWS (hashicorp/aws) — безусловно, самый часто используемый. Строил с его помощью всё: от простых VPC, EC2 и S3 до сложных распределённых систем с EKS, RDS, Lambda, сложными IAM-ролями и политиками, Transit Gateway и т.д.

  # Пример: Создание безопасной VPC с приватными и публичными подсетями
  resource "aws_vpc" "main" {
    cidr_block           = "10.0.0.0/16"
    enable_dns_hostnames = true
    tags = {
      Name = "production-vpc"
    }
  }
  

• HashiCorp/Google (hashicorp/google) — для проектов, завязанных на BigQuery, Dataflow, GKE и Cloud Run. Особое внимание уделял настройке Google Service Accounts и IAM bindings, которые имеют свою специфику.

  # Пример: Создание bucket в Google Cloud Storage с унифицированным доступом
  resource "google_storage_bucket" "data_lake" {
    name          = "my-company-data-lake"
    location      = "EU"
    force_destroy = false
    uniform_bucket_level_access = true
  }
  

• HashiCorp/AzureRM (hashicorp/azurerm) — при работе с Azure, особенно для интеграций с Active Directory, AKS и Azure DevOps. Resource Manager (ARM) требует тщательного планирования именования ресурсов из-за иерархической структуры.

Провайдеры для оркестрации и управления конфигурацией

• Kubernetes (hashicorp/kubernetes) и Helm (hashicorp/helm) — критически важны для GitOps-подходов. Использовал их для декларативного управления ресурсами внутри кластера (Deployments, Services, ConfigMaps, Ingress) непосредственно из Terraform, когда это было оправдано (например, для bootstrap-компонентов самого кластера).

  # Пример: Деплой приложения через провайдер Kubernetes
  resource "kubernetes_deployment" "nginx" {
    metadata {
      name = "nginx-deployment"
    }
    spec {
      replicas = 3
      selector {
        match_labels = {
          app = "nginx"
        }
      }
      template {
        metadata {
          labels = {
            app = "nginx"
          }
        }
        spec {
          container {
            image = "nginx:1.21"
            name  = "nginx"
          }
        }
      }
    }
  }
  

Провайдеры для мониторинга, секретов и CI/CD

• Datadog (datadog/datadog) — для автоматического создания мониторов, дашбордов и интеграций при развертывании новой среды.
• Vault (hashicorp/vault) — для динамического управления секретами (например, автоматическая генерация SSH- или БД-ключей для временного доступа).
• GitLab (gitlabhq/gitlab) / GitHub (integrations/github) — для автоматизации создания репозиториев, управлением группами, webhook-ами и настройки правил для веток (branch protection) непосредственно как код.

Провайдеры для утилит и специфичных задач

• External (hashicorp/external) — для интеграции со скриптами или API, которые ещё не охвачены существующими провайдерами.
• Random (hashicorp/random) — для генерации уникальных паролей или суффиксов имён ресурсов.
• Local (hashicorp/local) / Null (hashicorp/null) — для выполнения локальных действий и создания триггеров на основе depends_on.
• TLS (hashicorp/tls) — для генерации самоподписанных сертификатов на лету для внутренних сервисов в dev-средах.

Ключевые принципы работы с провайдерами

В своей практике я руководствуюсь несколькими важными правилами:

1. Версионирование и pinning: Всегда явно указываю версию провайдера в блоке required_providers для гарантии воспроизводимости и контроля за обновлениями.

   terraform {
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.0" # Использую приблизительное версионирование с минорными обновлениями
       }
     }
   }
   

2. Модульность: Создаю собственные модули Terraform, которые инкапсулируют использование конкретных провайдеров для типовых компонентов (например, модуль "балансировщик + ASG" для AWS).
3. Состояние (State) и Backend: Чётко разделяю конфигурацию провайдера (credentials, region) и сам ресурс. Секреты для аутентификации провайдера никогда не хардкожу, а использую переменные окружения или интеграцию с секрет-менеджером (например, AWS_ACCESS_KEY_ID, ARM_TENANT_ID). Состояние всегда храню в удалённом бэкенде (S3 + DynamoDB, Terraform Cloud).
4. Мульти-облачные стратегии: В сложных гибридных средах использовал комбинации провайдеров (например, AWS для основной инфраструктуры и Cloudflare для DNS и WAF), обеспечивая корректные depends_on для правильной последовательности развертывания.

Таким образом, выбор провайдера — это не просто ответ на вопрос "какое облако?", а целостная инженерная задача, включающая управление доступом, жизненным циклом, состоянием и интеграциями в рамках единого конвейера развертывания инфраструктуры.