Terraform Azure: Best practices pro produkci

Po třech letech intenzivní práce s Terraformem v enterprise prostředích (od H&M Group po menší FinTech firmy) jsem si vytipoval pět klíčových pravidel, která oddělují amatérský IaC kód od produkčně-odolné infrastruktury.

1. Remote State s locking – žádné výjimky

Nikdy, opravdu nikdy, nepoužívejte lokální terraform.tfstate v týmu. Azure Storage Account s blob containerem a state locking je základ:

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "stterraformstprod"
    container_name       = "tfstate"
    key                  = "landing-zone/prod.tfstate"
    use_oidc             = true
  }
}

Proč use_oidc = true? Protože Managed Identity + OIDC federace eliminuje nutnost ukládat service principal secrets do pipeline proměnných. Bezpečnější, jednodušší.

2. Modularizace od prvního dne

Největší chyba, kterou vidím u klientů: obří monolitický main.tf s 2000+ řádky. Řešení? Terraform moduly:

infrastructure/
├── modules/
│   ├── networking/          # VNet, NSG, Route Tables
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── compute/             # VM, VMSS, AKS
│   ├── security/            # Key Vault, Defender
│   └── monitoring/          # Log Analytics, Alerts
├── environments/
│   ├── dev/
│   │   └── main.tf          # Volá moduly s dev parametry
│   ├── staging/
│   └── prod/
└── shared/
    └── backend.tf

Každý modul má jasnou odpovědnost. Změna v networking modulu neovlivní compute. Testujete izolovaně, nasazujete bezpečně.

3. Drift Detection v CI/CD pipeline

Infrastruktura se v čase mění – někdo klikne v portálu, někdo spustí skript. Drift je tichý zabiják IaC konzistence. Řešení:

# Azure DevOps pipeline - noční drift check
schedules:
  - cron: "0 3 * * *"
    displayName: "Noční drift detection"
 
steps:
  - task: TerraformCLI@2
    inputs:
      command: 'plan'
      workingDirectory: 'infrastructure/environments/prod'
      commandOptions: '-detailed-exitcode'
    continueOnError: true
 
  - script: |
      if [ $TERRAFORM_EXITCODE -eq 2 ]; then
        echo "##vso[task.logissue type=warning]DRIFT DETECTED!"
        # Pošli notifikaci do Teams/Slack
      fi
    displayName: 'Evaluate drift'

4. Pojmenování zdrojů pomocí naming convention modulu

Konzistentní pojmenování je SEO infrastruktury – bez něj se ztratíte:

module "naming" {
  source = "Azure/naming/azurerm"
  suffix = [var.environment, var.location_short]
}
 
resource "azurerm_resource_group" "main" {
  name     = module.naming.resource_group.name
  location = var.location
}
 
resource "azurerm_virtual_network" "hub" {
  name                = module.naming.virtual_network.name
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  address_space       = ["10.0.0.0/16"]
}

5. Testy infrastruktury – Terratest nebo terraform validate

Ano, infrastrukturu je potřeba testovat. Minimálně:

• terraform validate – syntaktická kontrola
• terraform plan v PR pipeline – review změn před merge
• tflint – statická analýza best practices
• Terratest (Go) – integrační testy pro kritické moduly

Závěr

Terraform je mocný nástroj, ale bez disciplíny se z něj stane noční můra. Začněte s remote state a modularizací, přidejte drift detection a naming conventions. Vaše budoucí já vám poděkuje. Pokud používáte Bicep místo Terraformu, podívejte se na náš průvodce Bicep CI/CD pipeline.

Zajímá vás jak nastavit kompletní Terraform CI/CD pipeline v Azure DevOps? Připravuji na to detailní návod. Zjistěte více o našem Infrastructure as Code poradenství.