Standardisera din organisations infrastruktur med hjälp av Infrastruktur som kod (IaC)

Det kanske inte är ett problem om du är en tekniker som besitter den sortens kompetens (te x Molntekniker eller Operations inom Moln), men om du är en utvecklare kan detta vara lite utmanande eftersom ditt huvudsakliga expertområde är utveckling och inte konfiguration av plattformstjänster i molnet.

I det här inlägget kommer jag att gå igenom hur infrastruktur och utveckling enklare kan samarbeta för att lösa detta problem med verktyg som förhoppningsvis är någorlunda bekanta för båda sidor.

Infrastruktur som kod

Med Infrastructure as Code (IaC) kan du som tekniker fördefiniera en mall (modul) på en resurs i Azure med hjälp av kod, som sedan kan delas inom organisationen med inbyggd Azure Role Base Access Control (RBAC). På så vis kan en utvecklare enkelt referera till en redan existerande mall för till exempel ett nyckelvalv eller en databas som har skapats och underhålls av ett infrastruktur-team.

Tack vare det kan IT också säkerställa att mallarna för specifika resurser innehåller rätt konfiguration som lever upp till verksamhetens standard. Det kan till exempel vara att man vill påtvinga en högre krypteringsstandard, inaktivera lokala användarkonton eller inaktivera publik åtkomst.

Utvecklaren kan sedan referera till den önskade mallen för vilken resurs de vill skapa och svara på några tjänstespecifika parametrar (till exempel applikationsnamn, mängd lagringsutrymme och/eller storlek)

Exempel på hur innehållet i en mall (modul) kan se ut är följande:

(I detta exempel använder vi Bicep för Infrastruktur som kod)

Notera följande

- Vi skapar två resurser (storageaccount och privateEndpoint)

- Vissa parameter ger vi statiska värden (exempelvis minimalTlsVersion 'TLS1_2' & supportsHttpsTrafficOnly: true)

- Andra värden väljer vi att svara med en parameter (det som syns i ljusblått, exempelvis storageAccountName, location, kind)

Exempel på hur det kan se ut när man refererar till en existerande mall (modul):

Notera följande

-        Vi refererar till vår mall med hjälp av module <valfritt namn> länk till modulen

-        Antalet kodrader blev plötsligt betydligt färre (detta för att vi endast svarar på de parametrar som tidigare var angivna i ljusblått)

Om vi nu gör en deploy av denna mall till vår resursgrupp i azure, så kommer tre saker att skapas

-        Storage Account

-        Private Endpoint

-        Network Interface Card (tillhörande Private Endpoint)

Om jag nu klickar på Configuration på mitt Storage Account så ser jag även att vår statiska konfiguration från ursprungsmallen är applicerade.

För demomaterial hänvisar jag till min github

Andra fördelar med Infrastruktur som kod

1. Den här strategin säkerställer också att samma infrastruktur distribueras i alla utvecklingsmiljöer, vilket eliminerar risken för konfigurationsavvikelser och mänskliga fel.
2. Infrastruktur som kod är ett deklarativt språk vilket betyder att man inte behöver en utvecklingsbakgrund för att läsa och förstå sig på koden, det kan därför också fungera som en dokumentation av infrastrukturen.
3. Det är även ett sätt att säkerställa disaster recovery eftersom all infrastruktur och konfiguration både definieras och versionshanteras med hjälp av kod.
4. Sist, men inte minst, är detta ett mer effektivt och automatiserat sätt att tillhandahålla infrastruktur – automatiserat, repeterbart och tidseffektivt.

Det finns olika verktyg för Infrastruktur som kod, det mest populära verktyget är Terraform HCL som är öppen källkod och oberoende av vilket moln du jobbar mot.

Ett annat verktyg är Bicep som är ett DSL (domänspecifikt språk) som endast fungerar mot Azure. Folk som har arbetat med ARM tidigare kommer också att känna sig väldigt bekanta.

Vilka blir vinnare?

Utvecklarna blir vinnare då de slipper en stor overhead i form av infrastruktur & konfiguration och kan istället fokusera på utveckling av deras applikation. Med säkerhet i att infrastrukturen är skriven med hjälp av kod kan även utvecklarna använda det som dokumentation och backup av infrastrukturlagret i deras applikation.

Även IT-avdelningen blir vinnare eftersom det ger dem en chans att ha kontroll av vilken infrastruktur som delar av organisationen hanterar, försäkra sig om att nödvändig konfiguration används vid provisionering av exempelvis plattformstjänster och att infrastrukturen håller företagets standard för kostnadskontroll, governance, säkerhet & compliance.

Slutord

Sammanfattningsvis kan en bred implementation av IaC vara till stor nytta för flera olika grupper i en organisation, inklusive förvaltning, utveckling, säkerhet, organisationen som helhet och självklart slutanvändarna av systemen eftersom det är de som kommer ta del av fördelarna.