Cloud beheer
Inleiding
Het dagelijkse beheer van de applicatie door de IT-infrastructuurbeheerder gebeurt binnen de AWS-cloudomgeving. De beheerder maakt gebruik van de verschillende AWS-tools en -diensten om de applicatie en infrastructuur efficiënt te monitoren, beheren en onderhouden. Voor gedetailleerde informatie hierover verwijzen we naar de documentatiesite van AWS Cloud Services.
Applicatie beheren
Upgraden
Upgraden van de applicatie naar een hogere Skryv platform versie gebeurt door het opnieuw bouwen en deployen van de applicatie. Dit gebeurt typisch via een CI/CD-tool zoals Jenkins.
Opstarten & stoppen
Het opstarten en stoppen van de applicatie gebeurt binnen de AWS-cloudomgeving. In het geval van een containerized Spring Boot-applicatie wordt deze verpakt als een Docker-container en uitgerold via Amazon ECS (Elastic Container Service). ECS is een beheerde container orchestratie-dienst van AWS die het mogelijk maakt om applicaties eenvoudig te starten, stoppen en automatisch te schalen.
De opstart van de applicatie wordt geautomatiseerd via ECS-taken (tasks) en services, waarbij configuratie zoals omgevingsvariabelen, secrets en netwerk-instellingen centraal worden beheerd.
Door gebruik te maken van ECS profiteert de applicatie van automatische schaalbaarheid, hoge beschikbaarheid en integratie met andere AWS-diensten zoals Elastic Load Balancing en CloudWatch voor monitoring. Het beheer en de lifecycle van de applicatiecontainers verlopen zo efficiënt en volgens best practices binnen de AWS-cloudomgeving.
Monitoren
AWS CloudWatch is de belangrijkste service voor het monitoren van de prestaties en gezondheid van de applicatie en infrastructuur in AWS. Het biedt inzicht in logboeken, prestaties van EC2-instanties, databasegebruik, network latency en error rates. CloudWatch kan worden geconfigureerd om alarms in te stellen die de IT-beheerder waarschuwen bij specifieke gebeurtenissen, zoals een verhoogd CPU-gebruik of netwerkfouten. Meer info over AWS CloudWatch vind je hier.
Dienstverlening beheren
Configureren
Het configureren van artefacten gebeurt hoofdzakelijk lokaal in Studio app en/of een IDE (zoals IntelliJ). Dit biedt het voordeel dat je een development omgeving kan opzetten op je eigen pc. Omdat dit een (complexe) lokale setup vergt, is er voor configuratoren het alternatief om te configureren via een online versie van Studio.
Meer info:
Aanpassingen beheren
Aanpassingen in de configuratie artefacten worden bijgehouden in de applicatie repository op GitHub. Dit maakt samenwerking tussen verschillende configuratoren en/of developers mogelijk.
Updaten
Bij configuratiewijzigingen is het in principe niet nodig om de volledige applicatie opnieuw te bouwen en te deployen. Het volstaat om de gewijzigde configuratie artefacten uit de applicatie repository in te laden (snapshot ‘on disk’ plaatsen) en de applicatie te herstarten. Ook dit gebeurt typisch via een CI/CD-tool zoals Jenkins. De configuratiebestanden worden na herstart automatisch overgenomen in de applicatie database vanwaaruit ze het gedrag van de dienstverlening zullen aansturen.
Configuratie via lokale Studio en IDE
Configuratie via online Studio
Voor applicaties die geconfigureerd worden vanuit online Studio bestaan er twee werkwijzes om de applicatie te updaten.
Werkwijze 1 (voor apps in productie)
Applicatie eigenschap skryv.autoloaders.enabled=true (zie overzicht applicatie eigenschappen).
De in Studio uitgevoerde configuraties worden stelselmatig via pull requests naar de applicatie repository gepusht. Zie online Studio actie ‘aanpassingen doorsturen met PR’ (meer info over opslaan naar git repository). Daarna wordt er gedeployed volgens de hierboven beschreven procedure. Dit is de geijkte manier van werken voor het updaten van applicaties die in een productieomgeving draaien.
Werkwijze 2 (voor apps in test)
Applicatie eigenschap skryv.autoloaders.enabled=false (zie overzicht applicatie eigenschappen).
De in Studio uitgevoerde configuraties worden rechtstreeks via de ‘update preview’ actie gepusht naar de applicatie database (meer info over update & test preview). Zelfs na het stoppen en terug opstarten van de applicatie blijft de laatste configuratie in de applicatie database gelden. Dit is een makkelijke manier van werken voor het updaten van applicaties in een testomgeving.
Aan de tweede werkwijze kleven heel wat risico’s. Daarom is het niet aan te raden deze toe te passen op apps in productie. Het grootste risico ontstaat wanneer de configuratie zoals gekend in online Studio meer en meer ‘out of sync’ geraakt met de configuratie zoals gekend in de applicatie repository. Vandaar dat het een goed idee is om van tijd tot tijd de online Studio configuratie op te slaan naar de applicatie repository. In noodgevallen kan je de configuratie zoals gekend in online Studio ‘geforceerd’ deployen via de ‘update preview na DB drop’ actie. Of je kan terugvallen op de laatste versie van de configuratiebestanden ‘on disk’ waarna je start met een nieuwe online Studio sessie.
Incidentbeheer
Incidenten die specifiek gerelateerd zijn aan de dienstverlening, kunnen opgevolgd worden via het ondersteuningsportaal en/of de Camunda cockpit. Meer info over incident management vind je hier.