Xylos brands

Hoe definieer je de uitrol van apps met code?

Welke templates gebruik je voor de uitrol van apps en infra met code? Wel, we raden templates aan die een gewenste staat bevatten en die je idempotent kan uitrollen. Dat laatste betekent dat je de template meerder malen kan uitvoeren zonder een impact te creëren op de huidige staat. Voorbeelden van zulke templates zijn ARM-templates en Kubernetes- manifesten.

1. Aan de slag met ARM-templates

ARM staat voor Azure Resource Manager, de deployment- en managementdienst van Azure. Via een ARM-template beschrijf je de componenten die je uitrolt of wijzigt. Je kan bijvoorbeeld een ARM-template gebruiken om AKS (Azure Kubernetes Service) uit te rollen. In de ARM-template specifieer je:

  • de naam van de AKS-cluster
  • het aantal nodes
  • de netwerkintegratie

We gebruikten deze template voor onze OASE-toepassing. Je zal zien dat zulke ARM-templates vrij cryptisch zijn. Ze worden geschreven in Javascript Object Notation (JSON) en kunnen ook specifieke ARM-functies bevatten. Welkom in de wondere wereld van Infrastructure-as-Code (IaC).

De uitvoering van de template is idempotent. We kunnen de template meerdere keren uitvoeren zonder impact. Indien we op lijn 132 (zie code in bovenstaande link) het aantal servers aanpassen en de template opnieuw uitvoeren, zal Azure de nodige aanpassingen doen. Als engineer hoef je niet te weten hoe je de cluster aanpast. Je dient enkel de template te wijzigen en ARM doet de rest.

2. Aan de slag met Kubernetes-manifesten

ARM-templates zijn helemaal geschikt om Azure-componenten uit te rollen. Maar om in Kubernetes een toepassing uit te zetten, gebruiken we Kubernetes-manifesten. Die volgen dezelfde principes als ARM-templates: ze bevatten de gewenste staat en ze zijn idempotent.

Laten we een manifest maken om de webtoepassing uit de eerdere blogposts uit te rollen. Net zoals in de vorige blogpost, hebben we twee containers, een deployment, een service die beschikbaar is via een Azure Load Balancer en een publiek IP-adres nodig. Om ons doel te bereiken, maken we een YAML-file. In deze file maken we eerst de service:

Net zoals in de vorige blogpost maken we onze applicatie via een Azure Load Balancer beschikbaar op een extern IP-adres op poort 80. Via de definitie van de selector (app=nasnet) zal de service alle containers met het label “nasnet” beschikbaar maken. We moeten de containers dan wel een label geven en dat doen we via onderstaande deployment:

Deze definitie maakt een deployment met twee containers (replicas: 2). We gebruiken altijd de container image xylos/nasnet. Intern luisteren deze containers naar aanvragen op poort 9090.

Bekijk zeker ook de volledige YAML-file.

  • Om de uitrol te starten, gebruik je het volgende commando:

kubectl apply -f nasnet.yaml

  • Als je een fout hebt gemaakt, kan je alles eenvoudig verwijderen:

kubectl delete -f nasnet.yaml

3. Conclusie

ARM-templates en Kubernetes-manifesten hebben heel wat voordelen vergeleken met het ingeven van commando’s. Je kan ze eenvoudig inchecken in een codebibliotheek (bv.. git), je kan de versies bijhouden en vergelijken, je kan de correctheid testen en nog veel meer.

Met de definities in handen om zowel de Azure-infrastructuur als de applicatie uit te rollen, kunnen we in de volgende stap de uitrol automatiseren met Azure DevOps. Heb je deze blogs uit onze reeks “In 6 stappen naar de cloud” al gelezen?

Op onze reis doorheen het containerlandschap behandelden we al de volgende topics. Neem zeker een kijkje: 

Deel dit blogbericht

Laat een antwoord achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd.

Breng jouw kennis en skills naar een hoger niveau

Schrijf nu in voor onze nieuwsbrief en krijg maandelijks:

  • Uitnodigingen voor Xylos' events & webinars
  • De laatste blogposts en cases
  • Nieuwste IT-trends