Met Terraform richt je de beste infrastructuur in voor Kubernetes, die je vervolgens met Application Insights monitort. Die automatisering biedt veel voordelen.

Voordelen van het automatiseren van Kubernetes

Bij Open Circle Solutions gebruiken we de open source-tool Terraform om het configureren van Kubernetes zoveel mogelijk te automatiseren. Dat heeft grote voordelen:

• korte ontwikkeltijd
• makkelijk aanpassingen doen (na oplevering)
• provider-onafhankelijke oplossing
• automatische naamconventie
• uniformiteit (makkelijk in beheer en monitoring)
• reproduceerbaarheid (clusters en omgeving)
• minder foutgevoelig
• meer inzicht in kosten en performance

Automatiseren is dus de moeite waard. Om uit te leggen wat je kunt automatiseren, doorlopen we het hele transitieproces stap voor stap. Je krijgt hierbij bovendien een goed beeld van wat je mag verwachten van een dergelijk traject. De eerste stap is zoals altijd het architectuurontwerp, dan volgt de configuratie met Terraform, deployment van de app en uiteindelijk de feitelijke transitie.

Stap 1

Architectuurontwerp

Om de architectuur van een Kubernetes-platform te ontwerpen, wordt eerst bepaald:

• Welke services zijn er nodig?
• Hoe groot moeten de nodes (machines) zijn waar Kubernetes op draait?
• Hoeveel verwachten we dat deze gaat op- en afschalen?
• Willen we dat het cluster opschaalt zonder begrenzingen of stellen we een grens aan het maximum aantal servers?
• De netwerkconnectiviteit, zoals toegang tot de database en toegang van buitenaf.
• Opbouw van het databasecluster en het Kubernetes-cluster.
• Inrichting van de beveiliging:
  • identificatie van gebruikers en SSO
  • applicatie firewall en reverse proxy.

Met deze input wordt de architectuurplaat ontworpen.

Wat is een reverse proxy?

De reverse proxy – bijvoorbeeld Front Door van Microsoft – zorgt voor veilige toegang overal vandaan. Het werkt zo: wanneer een gebruiker een aanvraag doet, verwijst de DNS-server naar een lokaal IP-adres van Front Door. In Duitsland krijgt de gebruiker dus een ander IP-adres dan in Japan. Dit IP-adres is altijd binnen het MS-netwerk en gegarandeerd snel. Deze tussenliggende proxyserver haalt namens de client gegevens op bij de bron (het Kubernetes-cluster) en stuurt het antwoord terug. Voor de client lijkt het alsof hij direct met de applicatie communiceert, maar door de tussenkomst van de proxy server is er nooit een directe link naar het Kubernetes-cluster. Dit draagt bij aan de veiligheid van de oplossing.

Stap 2

Configuratie van de infrastructuur met behulp van Terraform

De omgevingen worden volgens het ontwerp aangemaakt in een Managed Kubernetes Cluster dienst, zoals Microsoft Azure Kubernetes Services (AKS). Je kunt in Azure de verschillende componenten stuk voor stuk aanklikken, maar wanneer je meerdere omgevingen aanmaakt met meerdere componenten, is dat niet efficiënt. Daarom maken wij gebruik van Terraform. Dit is een open source software tool waarbij de infrastructuur in code wordt vastgelegd. De definitie van de infrastructuur wordt ingevoerd: “een Kubernetes-cluster met zoveel nodes, gekoppeld aan die database, op dat netwerk en die naamgevingsconventie” etcetera. Vervolgens gaat Terraform een plan maken. Na akkoord gaat hij de omgeving configureren.

Wil je op een later moment iets wijzigen, dan voer je de nieuwe gegevens in de configuratie in; Terraform berekent of dat in de huidige opzet kan of dat hij een nieuw cluster moet aanmaken. Dit doet hij naast het bestaande cluster, tot je akkoord geeft om over te stappen.

Zo bouw je eerst een testomgeving, die je eenvoudig kopieert naar een acceptatie- en productieomgeving. Omdat Terraform als code objectgeoriënteerd is, kun je eenvoudig clusters kopiëren. Wij kiezen ervoor om cluster voor cluster alles iteratief op te bouwen. Dat zorgt voor goed overzicht. De naamgeving past zich automatisch aan naar de betreffende omgeving, wanneer je naamconventie toevoegt in je configuratiebestand.

Op deze manier kun je met Terraform heel snel en tegelijkertijd veilig en stabiel je infrastructuur creëren, wijzigen en verbeteren.

Stap 3

Applicatie deployen

Als de infrastructuur staat, wordt het tijd om de applicatie te deployen. Hiervoor maken we bij OCS gebruik van Continuous Integration/Continous Development (CI/CD) waarbij ontwikkelaars samenwerken in één centrale repository. Dat maakt het mogelijk om sneller en continu, maar toch veilig, te ontwikkelen en op te leveren. Van hieruit leveren we de applicatie op naar het betreffende Kubernetes-cluster, die vervolgens overgaat naar de opgebouwde infrastructuur.

Stap 4

Transitie van oude naar nieuwe omgeving

Als de applicatie in de infrastructuur staat, wordt het tijd om de data en gebruikersgegevens over te zetten. Eenmaal zover, verifiëren we uitgebreid de data, werking en veiligheid. Dit overzetten van de applicatie en bijbehorende data doen we, als het kan, buiten kantooruren, zodat gebruikers zo min mogelijk gehinderd worden. Als alles goed loopt in de nieuwe omgeving wordt de oude omgeving uitgefaseerd.

Opvolging: inzicht in performance dankzij continue monitoring (met Application Insights)

De applicatie is na oplevering direct te gebruiken voor medewerkers. Wel monitoren we deze vanaf het begin met behulp van Azure Application Insights. Hiermee meet je de real-time performance van de app. Als er knelpunten zijn, kun je dat direct zien.