🥇Fällor med Terraform

Vi kommer att lyfta fram några fallgropar, inklusive de som rör cykler, if-uttalanden och distributionsmetoder, samt mer allmänna problem som rör Terraform i stort:

parametrarna count och for_each har begränsningar;
begränsningar för distributioner med noll avbrottstid;
även en bra plan kan misslyckas;
refactorering kan ha sina fällor;
fördröjd konsistens stämmer överens... med fördröjning.

Parametrarna count och for_each har begränsningar

I exemplen i detta kapitel tillämpas parametern count och uttrycket for_each aktivt i cykler och logik. De fungerar väl, men det finns två viktiga begränsningar som man måste vara medveten om.

I count och for_each kan man inte referera till några utdata från resursvariabler.
count och for_each kan inte användas i modulkonfigurationer.

I count och for_each kan man inte referera till några utdata från resursvariabler

Föreställ dig att du behöver distribuera flera EC2-servrar och av någon anledning inte vill använda ASG. Din kod kan se ut så här:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

Låt oss titta på dem ett och ett.

Eftersom parametern count har tilldelats ett statiskt värde kommer den här koden att fungera utan problem: när du kör kommandot apply kommer det att skapa tre EC2-servrar. Men om du vill distribuera en server i varje tillgänglighetszon (Availability Zone eller AZ) inom den aktuella AWS-regionen? Du kan göra så att din kod laddar listan över zoner från datakällan aws_availability_zones och sedan "cykliskt" går igenom var och en av dem och skapar en EC2-server i varje zon, genom att använda parametern count och åtkomst till arrayen via index:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

Den här koden kommer också att fungera perfekt, eftersom parametern count problemfritt kan referera till datakällor. Men vad händer om antalet servrar du behöver skapa beror på utdata från en viss resurs? För att demonstrera detta är det enklast att ta resursen random_integer, som, som namnet antyder, returnerar ett slumpmässigt heltal:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

Den här koden genererar ett slumpmässigt tal mellan 1 och 3. Låt oss se vad som händer om vi försöker använda utdata från result från den här resursen i parametern count för resursen aws_instance:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

Om du kör terraform plan för den här koden får du följande fel:

Error: Ogiltigt count-argument

   på main.tf rad 30, i resurs "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

Värdet för "count" beror på resursattribut som inte kan bestämmas förrän tillämpningen, så Terraform kan inte förutsäga hur många instanser som kommer att skapas. För att lösa detta, använd argumentet -target för att först tillämpa endast de resurser som count beror på.

Terraform kräver att count och for_each beräknas i planeringssteget, före skapandet eller ändringen av några resurser. Det innebär att count och for_each kan hänvisa till litteraler, variabler, datakällor och till och med resurslistor (förutsatt att deras längd kan fastställas under planeringen), men inte till beräknade utdataresursvariabler.

count och for_each kan inte användas i modulkonfigurationen

Du kan ibland frestas att lägga till parameter count i modulkonfigurationerna:

module "count_example" {
     source = "..\/..\/..\/..\/modules\/services\/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

Den här koden försöker använda count inne i modulen för att skapa tre kopior av resursen webserver-cluster. Eller så kanske du vill göra modulkopplingen valfri beroende på något boolean-villkor genom att tilldela parameter count värdet 0. Sådan kod kan verka rimlig, men som ett resultat av att köra terraform plan kommer du få följande fel:

Error: Reservat argumentnamn i modulblock

   på main.tf rad 13, i modul "count_example":
   13: count = 3

Namnet "count" är reserverat för användning i en framtida version av Terraform.

Tyvärr, vid lanseringen av Terraform 0.12.6 stöds inte användning av count eller for_each i resursmodulen. Enligt release-noterna för Terraform 0.12 (http://bit.ly/3257bv4) planerar HashiCorp att lägga till denna funktionalitet i framtiden, så beroende på när du läser den här boken kan den redan vara tillgänglig. För att veta säkert, kolla in Terraform:s changelog här.

Begränsningar för distributioner med noll nedtid

Användningen av create_before_destroy-blocket i kombination med ASG är en utmärkt lösning för att organisera distributioner med noll driftstopp, med ett undantag: autoskalningsregler stöds inte. Eller för att vara mer exakt, detta återställer storleken på ASG till min_size vid varje distribution, vilket kan bli ett problem om du har använt autoskalningsregler för att öka antalet aktiva servrar.

Till exempel innehåller modulen webserver-cluster ett par resurser aws_autoscaling_schedule som klockan 9 ökar antalet servrar i klustret från två till tio. Om du utför en distribution, säg klockan 11, kommer den nya ASG-gruppen att laddas med endast två servrar istället för tio och förbli i detta tillstånd till klockan 9 nästa dag.

Denna begränsning kan kringgås på flera sätt.

Ändra parametern recurrence i aws_autoscaling_schedule från 0 9 * * * ("körs klockan 9") till något som 0-59 9-17 * * * ("körs varje minut från klockan 9 till 17"). Om det redan finns tio servrar i ASG kommer att återutföra denna autoskalningsregel inte att ändra något, vilket är vad vi vill. Men om ASG-gruppen just har distribuerats garanterar denna regel att antalet servrar inom en minut når tio. Det är inte den mest eleganta metoden, och stora hopp från tio till två servrar och tillbaka kan också orsaka problem för användarna.
Skapa ett användarscript som använder AWS API för att bestämma antalet aktiva servrar i ASG, anropa det med en extern datakälla (se avsnitt "Extern datakälla" på s. 249) och tilldela parameter desired_capacity för ASG-gruppen det värde som returneras av detta script. På så sätt kommer varje ny ASG-instans alltid att starta med samma kapacitet, vilket gör vår Terraform-kod mer komplex att underhålla.

Självklart, i idealfallet borde Terraform ha inbyggt stöd för distributioner med noll driftstopp, men i maj 2019 planerade HashiCorp-teamet inte att lägga till denna funktionalitet (detaljer - här).

En korrekt plan kan misslyckas med att implementeras

Ibland, när du kör kommandot plan, får du en helt rimlig distributionsplan, men kommandot apply returnerar ett felmeddelande. Försök till exempel att lägga till resursen aws_iam_user med samma namn som du använde för IAM-användaren som du skapade tidigare i kapitel 2:

resource "aws_iam_user" "existing_user" {
   # Ange namnet på den redan existerande IAM-användaren här,
   # för att öva på att använda kommandot terraform import
   name = "yevgeniy.brikman"
}

Nu, om du kör kommandot plan, kommer Terraform att visa en till synes rimlig distributionsplan:

Terraform kommer att utföra följande åtgärder:

   # aws_iam_user.existing_user kommer att skapas
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (känt efter apply)
         + force_destroy   = false
         + id                    = (känt efter apply)
         + name               = "yevgeniy.brikman"
         + path                 = "\/"
         + unique_id         = (känt efter apply)
      }

Plan: 1 att lägga till, 0 att förändra, 0 att förstöra.

Om du kör kommandot apply får du följande fel:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   på main.tf rad 10, i resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

Problemet är uppenbarligen att en IAM-användare med det namnet redan finns. Och detta kan hända, inte bara med IAM-användare, utan också med nästan vilken resurs som helst. Kanske har någon skapat denna resurs manuellt eller med hjälp av kommandoraden, men hur som helst, en identitetskonflikt leder till problem. Det finns många varianter av detta fel som ofta överraskar nybörjare i Terraform.

Den avgörande punkten är att kommandot terraform plan endast tar hänsyn till de resurser som anges i Terraform-statusfilen. Om resurser skapats på något annat sätt (t.ex. manuellt, genom att klicka i AWS-konsolen) kommer de inte att hamna i statusfilen och därför kommer Terraform inte att ta hänsyn till dem vid körning av kommandot plan. Resultatet blir att en till synes korrekt plan visar sig vara felaktig.

Från detta kan man dra två lärdomar.

Om du redan har börjat arbeta med Terraform, använd inte något annat. Om en del av din infrastruktur hanteras med Terraform, får den inte längre ändras manuellt. Annars riskerar du inte bara att få konstiga felmeddelanden i Terraform, utan du underminerar också många av fördelarna med IaC, eftersom koden inte längre kommer att vara en exakt representation av din infrastruktur.
Om du redan har någon infrastruktur, använd kommandot import. Om du börjar använda Terraform med redan existerande infrastruktur kan den läggas till i tillståndsfilen med kommandot terraform import. Då kommer Terraform att veta vilken infrastruktur som ska hanteras. Kommandot import tar två argument. Den första är adressen till resursen i dina konfigurationsfiler. Här är samma syntax som i referenser till resurser: _. (som aws_iam_user.existing_user). Det andra argumentet är ID:t för den resurs som ska importeras. Låt oss säga att för resurser av typen aws_iam_user är användarnamnet (t.ex. yevgeniy.brikman) ID:t, medan för resurser av typen aws_instance är serverns identifierare EC2 (som i-190e22e5). Hur man importerar en resurs anges vanligtvis i dokumentationen längst ner på dess sida.
Nedanför visas kommandot import som möjliggör synkronisering av resursen aws_iam_user som du har lagt till i din Terraform-konfiguration tillsammans med IAM-användaren från kapitel 2 (naturigtvis behöver du ersätta yevgeniy.brikman med ditt namn):
```
$ terraform import aws_iam_user.existing_user yevgeniy.brikman
```
Terraform kommer att kontakta AWS API för att hitta din IAM-användare och skapa en koppling mellan den och resursen aws_iam_user.existing_user i din Terraform-konfiguration i tillståndsfilen. Från och med nu kommer Terraform att veta att IAM-användaren redan finns när kommandot plan körs, och kommer inte att försöka skapa den igen.
Det bör noteras att om du redan har många resurser som du vill importera till Terraform, så kan det bli en besvärlig uppgift att skriva koden manuellt och importera dem en och en. Därför bör du överväga att använda ett verktyg som Terraforming (http://terraforming.dtan4.net/), som kan automatiskt importera kod och tillstånd från ditt AWS-konto.
Refaktorering kan ha sina fällor.
Refaktorering är en vanlig praxis inom programmering där du ändrar den interna strukturen i koden utan att påverka det externa beteendet. Detta görs för att göra koden mer förståelig, ordnad och lättare att underhålla. Refaktorering är en oumbärlig metodik som bör tillämpas regelbundet. Men när det gäller Terraform eller något annat verktyg för IaC, är det viktigt att vara extremt försiktig med vad som menas med "externt beteende" hos en koddel, annars kan oförutsedda problem uppstå.
Till exempel är en vanlig typ av refaktorering att byta namn på variabler eller funktioner till mer begripliga namn. Många IDE:er har inbyggt stöd för refaktorering och kan automatiskt byta namn på variabler och funktioner inom hela projektet. I allmänna programmeringsspråk är detta en trivial procedur som man kan bortse ifrån, men i Terraform måste man vara extremt försiktig, annars kan det leda till driftstopp.
Till exempel har modulen webserver-cluster en ingångsvariabel cluster_name:
```
variable "cluster_name" {
   description = "Namnet som ska användas för alla klusterresurser"
   type          = string
}
```
Föreställ dig att du har börjat använda denna modul för att distribuera en mikrotjänst med namnet foo. Senare vill du döpa om din tjänst till bar. Denna ändring kan verka trivial, men i verkligheten kan det leda till driftstopp.
Det beror på att modulen webserver-cluster använder variabeln cluster_name i ett antal resurser, inklusive namnet på två säkerhetsgrupper och ALB:
```
resource "aws_lb" "example" {
   name                    = var.cluster_name
   load_balancer_type = "application"
   subnets = data.aws_subnet_ids.default.ids
   security_groups      = [aws_security_group.alb.id]
}
```
Om du ändrar namnet på en resurs, kommer Terraform att ta bort den gamla versionen av resursen och skapa en ny. Men om en sådan resurs är ALB, kommer du under tiden mellan borttagningen av den gamla och laddningen av den nya versionen inte att ha något sätt att omdirigera trafiken till din webbserver. På samma sätt, om en säkerhetsgrupp tas bort, kommer dina servrar att börja avvisa all nätverks trafik tills en ny grupp har skapats.
En annan typ av refaktorering som kan intressera dig är att ändra Terraform-ID:t. Låt oss ta resurserna aws_security_group i modulen webserver-cluster som exempel:
```
resource "aws_security_group" "instance" {
  # (...)
}
```
ID:t för den här resursen kallas instance. Föreställ dig att du under refaktoreringen bestämmer dig för att byta det till ett mer begripligt (enligt din åsikt) namn, cluster_instance:
```
resource "aws_security_group" "cluster_instance" {
   # (...)
}
```
Vad händer då? Rätt: driftstopp.
Terraform kopplar varje resurs ID med leverantörens ID. Till exempel kopplas iam_user till IAM-användarens ID i AWS, och aws_instance kopplas till ID för AWS EC2-servern. Om resursens ID ändras (säg från instance till cluster_instance, som i fallet med aws_security_group), kommer Terraform att se detta som om du har tagit bort den gamla resursen och lagt till en ny. Om dessa ändringar tillämpas kommer Terraform att ta bort den gamla säkerhetsgruppen och skapa en ny, vilket innebär att dina servrar börjar avvisa all nätverkstrafik.
Här är fyra viktiga lektioner du bör ta med dig från denna diskussion.
- Använd alltid kommandot plan. Det låter dig identifiera alla dessa problem. Gå noggrant igenom dess utdata och var uppmärksam på situationer där Terraform planerar att ta bort resurser som troligen inte bör tas bort.
- Skapa innan du tar bort. Om du vill ersätta en resurs, tänk noga på om det är nödvändigt att skapa en ersättning innan du tar bort originalet. Om svaret är ja kan create_before_destroy hjälpa till. Du kan uppnå samma resultat manuellt genom att utföra två steg: först lägga till den nya resursen i konfigurationen och köra kommandot apply, och sedan ta bort den gamla resursen från konfigurationen och köra kommandot apply igen.
- Ändring av ID:n kräver en ändring av tillståndet. Om du vill ändra ID:t relaterat till en resurs (till exempel byta namn på aws_security_group från instance till cluster_instance), utan att ta bort resursen och skapa en ny version av den, måste du uppdatera Terraform-tillståndsfilerna på rätt sätt. Gör detta aldrig manuellt — använd istället kommandot terraform state. Vid ombenämning av ID:n ska du köra kommandot terraform state mv, som har följande syntax:
```
terraform state mv
```
  ORIGINAL_REFERENCE är ett uttryck som refererar till resursen i dess nuvarande form, medan NEW_REFERENCE är platsen dit du vill flytta den. Till exempel, vid ombenämning av aws_security_group från instance till cluster_instance behöver du köra följande kommando:
```
$ terraform state mv 
   aws_security_group.instance 
   aws_security_group.cluster_instance
```
  Så kommer du att meddela Terraform att tillståndet som tidigare gällde aws_security_group.instance nu ska kopplas till aws_security_group.cluster_instance. Om terraform plan inte visar några ändringar efter att du har döpt om detta och kört kommandot, så har du gjort rätt.
- Vissa parametrar kan inte ändras. Många resursparametrar är oföränderliga. Om du försöker ändra dem kommer Terraform att ta bort den gamla resursen och skapa en ny istället. På varje resursens sida anges vanligtvis vad som händer om en viss parameter ändras, så glöm inte att kolla dokumentationen. Använd alltid kommandot plan och överväg om det är lämpligt att använda strategin create_before_destroy.
Fördröjd konsistens överensstämmer… med fördröjningen
API:er från vissa molnleverantörer, som AWS, är asynkrona och har fördröjd konsistens. Asynkronitet innebär att gränssnittet kan returnera ett svar omedelbart utan att vänta på att den begärda åtgärden ska slutföras. Fördröjd konsistens betyder att det kan ta tid att sprida ändringar i hela systemet; under tiden kan dina svar vara inkonsekventa och bero på vilken replik av datakällan som svarar på dina API-anrop.
Tänk dig till exempel att du gör ett API-anrop till AWS för att skapa en EC2-server. API:et kommer att returnera ett "lyckat" svar (201 Created) nästan omedelbart, utan att vänta på att själva servern ska skapats. Om du omedelbart försöker att ansluta till den kommer det nästan säkert att misslyckas, eftersom AWS fortfarande initierar resurserna eller alternativt att servern har ännu inte startat. Dessutom, om du gör ett annat anrop för att få information om denna server, kan det komma ett felmeddelande (404 Not Found). Anledningen är att informationen om denna EC2-server fortfarande kan spridas genom AWS, och det kan ta ett par sekunder innan den blir tillgänglig överallt.
Vid varje användning av asynkront API med fördröjd konsistens måste du regelbundet upprepa din begäran tills åtgärden är slutförd och har spridits i systemet. Tyvärr tillhandahåller AWS SDK inga bra verktyg för detta, och Terraform-projektet har tidigare lidit av många fel som exempelvis 6813 (https://github.com/hashicorp/terraform/issues/6813):
```
$ terraform apply
aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
Subnät-ID 'subnet-xxxxxxx' finns inte
```
Med andra ord skapar du en resurs (till exempel ett subnät) och försöker sedan hämta information om det (som ID för det nyligen skapade subnettet), men Terraform kan inte hitta den. De flesta av sådana fel (inklusive 6813) har redan åtgärdats, men de dyker fortfarande upp då och då, särskilt när Terraform får stöd för en ny typ av resurser. Det är frustrerande, men i de flesta fall är det ofarligt. Vid en ny körning av terraform apply bör allt fungera, eftersom informationen då redan har spridits i systemet.
Detta utdrag är hämtat från boken av Evgeny Birman «Terraform: Infrastruktur som kod».