Infrastructure as Code: Terraform + Atlantis + policy as code

Den första gången jag såg någon köra terraform apply rakt från sin laptop mot produktion utan att någon annan tittade, kände jag en stilla oro. Det är inte att verktyget är dåligt, tvärtom, utan att arbetsflödet saknade allt vi tar för givet när vi skriver applikationskod: granskning, spårbarhet och en grind innan förändringen når verkligheten. Infrastructure as Code blir riktigt värdefullt först när infrastrukturändringar går samma trygga väg som vilken annan kodändring som helst. Med Terraform, Atlantis och policy as code får du just det.

State är hjärtat och den vanligaste fällan

Terraform håller reda på vad det har skapat i en state-fil. Den filen är sanningen om din infrastruktur, och den är också den vanligaste källan till problem. Lokal state på en laptop betyder att bara en person kan ändra säkert, och att en kraschad disk kan ta din infrastrukturhistorik med sig. Det första jag gör i varje projekt är att flytta state till en delad backend med låsning, så att två personer inte kan applicera samtidigt och skriva över varandra.

Jag delar också upp state per miljö och gärna per domän. Att ha hela organisationens infrastruktur i en enda state är som att ha hela kodbasen i en enda fil: allt fungerar tills det inte gör det, och då är radien för ett misstag enorm. Mindre, väl avgränsade state-filer gör att en plan är snabb att läsa och att ett fel stannar lokalt.

Moduler som gör det rätta enkelt

Moduler är hur du paketerar återkommande mönster så att teamet gör rätt utan att kopiera. En väl skriven modul kapslar in besluten: rätt taggar, rätt kryptering, rätt nätverksregler, så att den som använder den inte behöver vara expert. Jag försöker hålla moduler små och sammansatta snarare än att bygga en gigantisk modul som försöker täcka alla fall med trettio variabler.

• Versionera dina moduler så att en ändring i en modul inte oväntat rullar ut överallt.
• Skriv exempel och en kort beskrivning, en modul ingen förstår används inte.
• Sätt vettiga standardvärden så att det säkra valet också är det enklaste.

Atlantis: pull requests för infrastruktur

Här kommer Atlantis in. Atlantis kopplar Terraform till dina pull requests. När någon öppnar en PR med en infrastrukturändring kör Atlantis automatiskt en plan och lägger resultatet som en kommentar, så att granskaren ser exakt vad som kommer att skapas, ändras eller tas bort. Först när PR:en är godkänd och någon kommenterar för att applicera, körs apply, och då från en central plats med rätt behörigheter, inte från någons laptop.

Det här löser flera problem på en gång. Ingen behöver längre ha produktionscredentials lokalt. Varje ändring har en granskare och en revisionslogg i git. Och planen i kommentaren blir en naturlig diskussionspunkt, det är förvånansvärt ofta en granskare fångar ett oavsiktligt destroy innan det händer. Hur Atlantis passar in i en större bygg- och deploykedja beskriver jag i min tjänst för DevOps-plattform.

Policy as code stänger den sista luckan

Granskning av människor är bra men inte felfritt. Klockan halv sex en fredag godkänns saker som inte borde godkännas. Policy as code lägger ett lager av automatiska regler som körs på varje plan, oberoende av vem som tittar. Med OPA, ofta via Conftest, skriver du regler som ren kod: inga publika lagringsbuckets, all lagring ska vara krypterad, instanser ovanför en viss storlek kräver särskilt godkännande.

Det fina är att reglerna körs som ett steg i Atlantis-flödet. En plan som bryter mot en regel blockeras innan den kan appliceras, och granskaren ser exakt vilken regel som tröts. Du flyttar säkerheten från en checklista i någons huvud till en testbar artefakt som lever i samma repo som infrastrukturen.

Drift och verkligheten

Även med ett disciplinerat flöde uppstår drift, alltså att verkligheten glider isär från koden. Någon ändrar något i konsolen under en incident, och plötsligt stämmer inte din state. Jag schemalägger därför regelbundna plan-körningar som larmar om det finns oväntade skillnader, så att drift fångas tidigt i stället för att upptäckas först nästa gång någon försöker applicera och möts av en förvirrande plan.

• Behandla manuella ändringar i konsolen som ett undantag, inte en vana.
• Importera befintliga resurser till state hellre än att bygga parallellt.
• Kör plan regelbundet så att drift blir ett larm, inte en överraskning.

Börja smått och växt inåt

Du behöver inte koda hela din infrastruktur på en gång. Jag brukar börja med en avgränsad del, ofta nätverket eller en enskild tjänst, få hela flödet med state, Atlantis och policy på plats där, och sedan utöka. Att försöka migrera allt i ett svep slutar nästan alltid i en gigantisk PR som ingen vågar godkänna. Stegvis migrering bygger förtroende för flödet samtidigt som det levererar värde.

Relaterat

• Trunk-based development på riktigt: Feature flags med PostHog/Unleash
• Observability-stack 2026: OpenTelemetry + Grafana + Tempo + Loki
• Incident response runbooks: Mallar och automatisering med PagerDuty

Vill du se ett IaC-flöde i ett skarpt projekt finns exempel i min casebook.

Vill du ta det vidare?

Om din infrastruktur i dag bor i någons laptop eller i konsolen hjälper jag dig att flytta den till ett tryggt, granskat flöde. Hör av dig via kontaktsidan.