Terraform-moduler vi använder för varje kundsetup (open source)

Efter ett antal molnuppdrag märker man att samma byggstenar dyker upp om och om igen. Varje kund behöver ett nätverk, en identitetsmodell, central loggning och en taggstrategi. Att bygga det från scratch varje gång är slöseri, och att kopiera från förra kunden sprider snabbt fel. Lösningen är en uppsättning väldesignade, gärna öppna Terraform-moduler. Här går jag igenom de moduler jag återanvänder och, viktigare, hur jag designar dem så att de faktiskt håller.

En modul är ett kontrakt, inte en mapp

Det viktigaste skiftet är att se modulen som ett gränssnitt. Den har indata, utdata och ett tydligt ansvar, och den som använder den ska inte behöva veta hur den fungerar inuti. Det betyder omsorg om variabelnamn, beskrivningar och förnuftiga standardvärden. En modul med ett rörigt gränssnitt blir kopierad och förgrenad i stället för återanvänd, och då har du förlorat hela poängen.

Det här är samma synsätt som på vilket bibliotek som helst. Du bryr dig om vad en funktion tar in och ger ut, inte om dess inre. En väl utformad modul exponerar precis de utdata som behövs för att koppla ihop den med andra - ett nätverks identifierare, en databas anslutningsuppgifter - och döljer resten. Den disciplinen är vad som skiljer en modul som teamet gladeligen återanvänder från en som alla tyst kopierar för att slippa förstå den.

Byggstenarna jag återkommer till

Modulerna som dyker upp i nästan varje uppdrag är förvånansvärt få och stabila:

• Nätverk - ett hubb-och-eker-mönster med planerad adressrymd och segmentering.
• Identitet och behörighet - roller kopplade till grupper enligt least privilege.
• Loggning - central, låst loggning skild från arbetsbelastningarna.
• Taggning - en enhetlig taggstrategi som tvingas fram i koden.
• Baslinjeskydd - kryptering som standard och tvingande policy.

Eftersom de är gemensamma mellan kunder lönar det sig att lägga omsorg på dem en gång. Vill du ha hjälp att etablera en sådan grund kan du läsa om min molninfrastruktur.

Lagom stora moduler

Den vanligaste fällan är moduler som är för stora eller för små. En modul som försöker beskriva en hel plattform går inte att återanvända. En modul som bara wrappar en enda resurs tillför inget. Jag siktar på byggstenar som motsvarar ett begripligt problem helt: ett nätverk, en databas med sin backup, ett behörighetsmönster. Den storleken är både testbar och förståelig.

Versionering är inte valfritt

En modul som ändras under fötterna på den som använder den är farlig. Jag versionerar moduler och låser konsumenterna till en version, med taggar i ett eget repo. Ändringar som bryter gränssnittet höjer huvudversionen så att ingen kundmiljö uppdateras av misstag. Det är samma disciplin som för vilket bibliotek som helst, och den är avgörande just för att modulerna delas mellan flera kunder.

Testa och dokumentera

Moduler som inte testas ruttnar. Jag använder Terraforms testramverk och statisk analys för att verifiera att en modul går att planera och applicera och att utdata blir rätt. För moduler som rör säkerhet kör jag policy-as-code så att en modul inte kan släppa igenom en felkonfiguration. Dokumentationen av variabler och utdata genereras automatiskt så att den aldrig hamnar i otakt med koden, kompletterad med ett kort körbart exempel.

Varför öppna moduler ofta vinner

För många vanliga byggstenar finns redan väletablerade öppna moduler som underhålls av en bred community. Att använda dem i stället för att bygga eget sparar både tid och underhåll, och de är ofta bättre testade än något jag hinner skriva själv. Jag bygger eget först där kunden har specifika krav som de öppna modulerna inte täcker. Den avvägningen - återanvänd det generiska, bygg det specifika - är kärnan i en hållbar modulstrategi.

Skilj byggstenar från sammansättning

En sista princip som gör hela skillnaden över tid: håll isär de återanvändbara modulerna och den kod som beskriver en specifik miljö. Modulerna lever i ett eget register eller repo och är en intern produkt med egna konsumenter. Rotmodulerna, som sätter ihop dem för en viss kund eller miljö, lever för sig och anropar de versionerade byggstenarna. Den separationen gör det tydligt vad som är delat och vad som är specifikt, och den hindrar att en kundspecifik justering smyger in i en modul som många andra förlitar sig på.

När den här strukturen väl sitter blir nästa kundsetup förvånansvärt snabb. I stället för att börja från ett tomt blad sätter jag ihop beprövade moduler, fyller i de variabler som skiljer kunden från de andra, och låter pipelinen rulla ut grunden. Det är så en konsultverksamhet skalar utan att kvaliteten urholkas - varje kund får en grund som redan slipats hos de föregående, inte en ny variant byggd från minnet.

Relaterat

• Serverless i 2026: Cloudflare Workers, Vercel Functions, AWS Lambda
• Multi-region failover i GCP: Praktisk arkitektur för svenska e-handlare
• Container security: Snyk, Trivy och Falco för runtime-säkerhet i K8s

Vill du ta det vidare?

Vill ni få ordning på era Terraform-moduler och göra dem till en delad, versionerad tillgång hjälper jag er. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.