Hvad kan du bruge Infrastructure as code til?

09. januar 2023

Bliv klogere på, hvordan du kan bruge Bicep-filer til at oprette et helt miljø i Azure, som det er tænkt fra designet af infrastrukturen i din løsning.

Dette blogindlæg er en kort introduktion til emnet Infrastructure as Code (IaC), hvor målet er at oprette flere ressourcer i Azure på en nem og ensartet måde. IaC er et alternativ til at oprette ressourcer ved at ”klikke dem op”, hvor man i stedet beskriver alle sine dele i filer.

Af Robert Runge, Lead Software Engineer

Når vi skal oprette miljøer, er vi mange, der spørger os selv, "hvordan gør vi det?". Metoden skal passe til løsningen, så der ikke bliver lavet for meget, der har for lidt eller ingen værdi. For lidt kan give en hovedpine, når løsningen skal vedligeholdes.

For en kunde har vi for nylig leveret en Umbraco-løsning, som bliver hosted i Azure. Her valgte vi at oprette miljøer ud fra skabeloner modsat at "klikke ressourcer op" i Azure. Dette indlæg beskriver, "hvad" og "hvordan" vi gjorde det ved brug af "Bicep"-filer. Når Bicep-filer bliver anvendt, så er det helt kort: Skriv hvad du skal bruge og deploy til Azure. Er der ændringer, så handler det blot om at ændre filerne og deploye igen. Processen vendes lidt på hovedet ved, at det er ‘kode-filerne’, som indeholder sandheden omkring, hvilke ressourcer der er oprettet i Azure.

Bicep

Infrastructure as Code (IaC) er konceptet, vi bruger for at forberede og deploye Bicep-filer, som Azure modtager og opretter ressourcer ud fra.

Bicep er et domænespecifikt sprog, og man skriver Bicep-filer, som beskriver en eller flere ressourcer i Azure.

Ressourcen kan for eksempel være en database – og via kommandoer deployes Bicep-filerne, og Azure opretter ressourcer ud fra dem.

Her får du en kort gennemgang af, hvordan en Bicep-fil ser ud, og hvordan de ender ud i, at en ressource bliver oprettet i Azure. Desuden får du en gennemgang af, hvordan du samlet kan oprette flere ressourcer i Azure og få hele din infrastruktur opbygget ud fra deskriptive Bicep-filer. Det er for dig, som vil se et komplet eksempel på udrulning af infrastruktur for en løsning, der driver et website.

Det er ikke alle detaljer i alle trin jeg vil beskrive, men jeg linker senere til et eksempel, som du selv kan køre.

Oprettelse af hele miljøer med skabeloner bliver ofte brugt til microservice-udvikling for at spare tid og sikre konsistens. Her er det ofte de samme typer ressourcer, der oprettes igen og igen. Det giver også mening for et komplet miljø til et website i Azure nemlig ved at anvende skabeloner nemt og tydeligt, hvad der er blevet oprettet i Azure, og hvordan de enkelte ressourcer er konfigureret.

Du kan læse mere på Microsofts dokumentationssite.

Hvad kan vi bruge Infrastructure as Code til?

For den nævnte kunde har vi bygget en B2B-webshop på Umbraco CMS-platformen, som bliver hosted i egen Azure subscription (læs: uden for Umbracos egen cloud).

Beskrivelse af infrastruktur er lavet med Bicep-filer, og ressourcer i Azure blev ligeledes oprettet ud fra dem. Der er dog ændret lidt i skabelonerne for at lette læsbarheden af dem, og dele skal stadig bindes sammen i portalen.

Formålet er her at vise, at man kan deploye ressourcer, og så vil der være lidt arbejde i at binde det hele sammen i Azure Portal.

Tegningen herunder viser infrastrukturen, vi ønsker at ende ud med.

I hovedtræk består miljøet af:

App service 1: Anvendes af web app som redaktører arbejder i samt en function-app, hvis formål er at hente data periodisk ind i commerce-databasen.
App Service 2: Den web app som brugere vil tilgå.
Databaseserver: Opsat med elastic pool som fordeler serverens ressourcer mellem to databaser:
1) Content til f.eks. artikler
2) Katalog til commerce

Når vi ved, hvad vi skal bruge, er næste skridt at skrive Bicep-filer og deploye dem til en ressourcegruppe i Azure.

Forenklet er der kun følgende to trin, du skal udføre:

Skrive Bicep-filer der ligger til grund for infrastrukturen
Deploye Bicep-filer til Azure

Efter deploy opretter Azure ressourcerne, hvilket kan tage noget tid. Det er naturligvis forsimplet i forhold til virkeligheden, hvor der er flere processer involveret, som f.eks. at få koden pushed til source management.

Saml ressourcerne i én Bicep-fil

Et miljø består af flere ressourcer – alle ressourcer samles i en main.bicep-fil, som refererer andre Bicep-filer. De refererede Bicep-filer beskriver de enkelte ressourcers detaljer, som f.eks. kapacitet, processeringskraft og lignende. Når man deployer main, vil refererede ressourcer blive medtaget og blive oprettet.

En Bicep-fil kan indeholde en eller flere ressourcer, som bliver oprettet ved deploy, og Bicep-filer kan modtage input (param), som stammer fra en anden kaldende fil som f.eks. main.

En Bicep-fil kan også give et output, som kan anvendes af andre Bicep-filer i senere forløb. Et eksempel på dette kan være en database, som outputter en connection string, som bliver brugt som parameter ved oprettelse af web app-ressourcen.

Et konkret eksempel

Indtil nu er koncept omkring IaC og Bicep-filer beskrevet overordnet. IaC-området er større, end det kan dækkes af et blogindlæg, men for at vise, at det kan lade sig gøre, har jeg lavet et eksempel, som du kan hente og deploye til dit eget miljø. Det er her, det bliver virkeligt. Koden findes på GitHub, og der er en guide, som du kan følge.

Her ses et eksempel på en struktur, hvor create-storage.bicep har ansvaret for at oprette en storage account og et sted data kan placeres her. Indholdet i main.bicep, som beskrevet i eksemplet ovenfor - og create-storage.bicep kan ses herunder.

Bicep-fil: main.bicep

Her følger indholdet af main.bicep med forklaring af de enkelte linjer.

param deploymentEnvironment string
param applicationName string
param location string = resourceGroup().location

module stgModule './create-storage.bicep' = {
  name: 'storageWebShop'
  params: {
    applicationName: applicationName
    deploymentEnvironment: deploymentEnvironment
    location: location
  }
}

module appInsight 'create-application-insight.bicep' = {
  name: 'appInsight'
  params: {
    applicationName: applicationName
    deploymentEnvironment: deploymentEnvironment
    location: location
  }
}

Linje 1-3 beskriver parametre, der kommer udefra. De første to er obligatoriske, og den sidste er valgfri. Hvis en parameter ikke tildeles en værdi, som location, så er den obligatorisk og skal sættes udefra.

En ”location” (resourceGroup().location) hentes fra den kontekst, der bliver deployed i og er en information, der bliver sendt videre til de moduler, der indeholder information om, hvad der konkret bliver oprettet.

Den første ressource, der bliver oprettet, er storage (linje 5-12). Modulet kalder en anden Bicep-fil (create-storage.bicep), som indeholder detaljer om, hvordan dette storage er defineret. Alle moduler skal have et navn (name). Parametre til storage-modul indsættes i ”params”-blokken - her er det videresendelse af allerede eksisterende parametre.

Derefter bliver der hentet et modul ind til at oprette en application insight ressource (linje 14-21). Den er ikke nærmere beskrevet, da den følger præcis samme struktur som storage-modulet. Du kan se alle detaljer for den ved at følge link til GitHub i info-boksen "Konkret eksempel" ovenfor.

Bicep-fil: create-storage.bicep

Kode-snippet herunder er for storage-modul og indeholder detaljer omkring, hvordan det skal oprettes.

param applicationName string

@allowed([
  'dev'
  'test'
  'prod'
])
param deploymentEnvironment string
param location string = resourceGroup().location
var stName = 'st${applicationName}${deploymentEnvironment}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: stName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

resource blobServices 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' = {
  name: '${storageAccount.name}/default'
  properties: {
    changeFeed: {
      enabled: true
    }
    restorePolicy: {
      enabled: true
      days: 14
    }
    cors: {
      corsRules: []
    }
    deleteRetentionPolicy: {
      enabled: true
      days: 15
    }
    isVersioningEnabled: true
  }
}

output connectionString string = 'DefaultEndpointsProto-col=https;AccountName=${storageAccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageAccount.id, '2019-06-01').keys[0].value}'
output storageAccountName string = storageAccount.name
output resourceId string = storageAccount.id
output primaryEndpoints object = storageAccount.properties.primaryEndpoints

applicationname (linje 1) bliver brugt til at sikre en ensartet navngivning af ressourcer. Parameteren deploymentEnvironment (linje 3-10) bliver anvendt til navnet på storage-ressourcen. For at sikre ensartethed, kan parameteren antage værdi ud fra den tilladte liste (dev, test, prod). Værdierne angiver det miljø, der er mål for ressourcerne. Det lidt specielle her er, at en storage-ressource har mere restriktive regler omkring, hvilke karakterer navnet kan indeholde end andre ressourcer. Derfor er der ikke bindestreger og andre specialtegn i stName.

Storage-modulet opretter to ressourcer, og den første (linje 12-19) er en konto. Den anden ressource (linje 21-40) er en blob-service. Ressource-typerne 'Microsoft.Storage/storageAccounts@2021-09-01' og 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01’ er beskrevet hos Microsoft, hvor du også kan finde en liste over alle de ressourcer, der findes. For blob-servicen kan du læse mere her.

”connectionstring” (linje 42) er et eksempel på en output-parameter, som kan bruges af andre ressourcer, der skal kunne kalde dette storage. Vigtig note: Det anbefales ikke at outputte connectionstring som vist. But little did I know, da jeg lavede den. Problemet er, at der bliver udstillet en secret. Det, du i stedet skal gøre, er at oprette en secret i key-vault med informationer. Andre ressourcer som skal anvende storage, skal selv hente information fra keyvault. Den bedre måde er ikke vist.

Sådan deployer du til Azure

Deploy beskriver den handling, hvor man ”sender” sine klargjorte Bicep-filer til Azure, som opretter ressourcerne.

Der findes flere måder at deploye Bicep-filer til Azure på. Her vil jeg anvende Azure CLI. Altenativer er f.eks. VS Code, PowerShell og Cloud Shell.

I dette eksempel er det en forudsætning for at kunne deploye Bicep-filerne, at der findes en ressourcegruppe i Azure, der kan deployes til.

For at køre eksemplet skal du:

Installere Azure CLI.
Oprette en ressourcegruppe i Azure, som ressourcer oprettes under.
En ad-gruppe skal have adgang (en GUID) til ressourcegruppen (kræves for at oprette key vault og database-modul).
Have login-navn til SQL DB Server klar.

Før deploy forbinder man til Azure ved at anvende az login i terminal.

Deploy af Bicep-filer fra eksemplet ovenfor til ressourcegruppen, rg-umbbicepdemo-test-weu, vil se således ud:

az deployment group create \
  --resource-group rg-umbbicepdemo-test-weu \
  --template-file ./main.bicep \
  --parameters applicationName=rruweba

az: Azure CLI
deployment group create: Der bliver deployed til en ressourcegruppe
--resource-group rg-umbbicepdemo-test-weu: Ressourcegruppe der deployes til
--template-file: Peger på Bicep-filen, som her som er main.bicep

Resultatet af et deploy er, at ressourcer er oprettet i Azure i en bestemt ressourcegruppe.

13 ressourcer er blevet oprettet, som vi har beskrevet dem. Herunder kan du se resultatet i Azure:

Det har vi lært

Infrastructure as Code er en måde at få oprettet sin infrastruktur i et cloud-miljø. Det har vi løst i Azure ved at anvende Bicep-filer, som bliver deployed, og Azure sørger for at oprette ressourcerne. Det er ikke svært at foretage en ændring og få den deployed til miljøet.

Det er præcist og kan gentages.

Skal man tage den et skridt videre, som vi gør på flere andre projekter, så er det at få deployment af Bicep-filer ind som en del af Continuous Integration/Continuous Delivery og ikke køre det fra lokale maskiner.

Om Robert Runge

Robert er Lead Software Engineer og har været en del af Immeo siden 2015. Til daglig arbejder Robert primært med CMS og webshops og har været involveret i flere adskillige projekter for bl.a. Muuto, Nordlux og Kræftens Bekæmpelse.

Når Robert har lunet lokalet op med nyfortolkninger af gamle dad-jokes kan du måske fange ham i skoven enten i sine løbesko eller på sin mountainbike.

rru@immeo.dk | +45 6067 1975

Flere blogindlæg

Kan Azure Functions virkelig det?

Læs mere

It-sikkerhed: Har du husket at rulle dine nøgler?

Læs mere