„Kdo ten server vytvořil? Jaké má nastavení? Proč se liší od staging?” — otázky, které jsme si kladli příliš často. Terraform od HashiCorp nám dal odpověď: infrastruktura popsaná v kódu, verzovaná v Gitu.
Problém: snowflake servery¶
Každý server byl unikátní sněhová vločka. Admin A nastavil firewall jedním způsobem, admin B jiným. Dokumentace? Zastaralá nebo neexistující. Reprodukovat prostředí pro nového klienta znamenalo dny manuální práce.
Terraform základy¶
Terraform používá deklarativní jazyk HCL. Popíšete co chcete, ne jak to vytvořit. Terraform zjistí aktuální stav, porovná s požadovaným a provede potřebné změny.
resource "aws_instance" "api_server" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.medium"
vpc_security_group_ids = [aws_security_group.api.id]
subnet_id = aws_subnet.private.id
tags = {
Name = "api-server"
Environment = "production"
ManagedBy = "terraform"
}
}
State management¶
Terraform uchovává stav v state souboru. V týmu potřebujete remote state. Používáme S3 bucket s DynamoDB locking.
Moduly — DRY princip¶
Máme interní knihovnu modulů: VPC, ECS cluster, RDS instance, S3 buckety. Nové prostředí pro klienta: compose moduly dohromady, terraform apply, hotovo za 15 minut.
Plan before apply¶
terraform plan je váš bezpečnostní pás. Ukáže přesně, co se změní, co se vytvoří a hlavně co se zničí. Máme pravidlo: žádný apply bez review planu.
Co Terraform neumí dobře¶
- Konfigurace uvnitř VM — na to máme Ansible
- Drift detection — zjistí drift až při dalším plan
- Komplexní logika — HCL není programovací jazyk
- Secrets — state file obsahuje citlivá data
Infrastructure as Code není volba, je nutnost¶
Terraform změnil způsob, jakým přemýšlíme o infrastruktuře. Místo „kde je to tlačítko v konzoli” se ptáme „kde je ten .tf soubor v Gitu”.