Toepassingen implementeren in de cloud

Nadat een cloudtoepassing is ontworpen en ontwikkeld, kan deze worden overgebracht naar de implementatiefase voor vrijgave aan klanten. Implementatie kan een proces met meerdere stappen zijn, elk met een reeks controles om ervoor te zorgen dat aan de doelstellingen van de toepassing wordt voldaan.

Voordat u een cloudtoepassing in productie implementeert, is het handig om een checklist op te stellen om te controleren of de toepassing voldoet aan een lijst met essentiële en aanbevolen procedures. Voorbeelden hiervan zijn de controlelijst voor implementatie van AWS en Azure. Veel cloudproviders bieden een uitgebreide lijst met hulpprogramma's en services die helpen bij de implementatie, zoals dit document van Azure.

Implementatieproces

De implementatie van een cloudtoepassing is een iteratief proces dat begint aan het einde van de ontwikkelingsfase en dat doorloopt tot de release van de toepassing op de productieresources:

Afbeelding 1: Code-implementatieproces

Het is gebruikelijk dat cloudontwikkelaars meerdere gelijktijdig uitgevoerde versies van hun toepassingen onderhouden om de implementatie van hun toepassing via de pijplijn in verschillende fasen uit te voeren:

1. Testen
2. Opstelling
3. Productie

Elk van de drie fasen moet in het ideale geval identieke resources en configuratie-instellingen hebben, waardoor ontwikkelaars de toepassing kunnen testen en implementeren en de kans op inconsistenties als gevolg van wijzigingen van de omgeving en configuratie tot een minimum kunnen beperken.

Wijzigingen van toepassingen in pijplijn

In een typisch scenario voor het agile ontwikkelen van toepassingen (zoals weergegeven in de vorige afbeelding), worden toepassingen onderhouden door een groep technici en ontwikkelaars die werken aan problemen en bugs, waarbij ze gebruikmaken van een bepaald mechanisme voor het bijhouden van problemen. De wijzigingen van de code worden onderhouden via een speciale opslagplaats voor code (bijvoorbeeld svn, mercurialof git), waarbij afzonderlijke vertakkingen worden onderhouden voor het vrijgeven van code. Nadat code is gewijzigd, beoordeeld en goedgekeurd, kan de code via de pijplijn worden overgebracht naar de fasen testen, staging en productie. Dit kan op verschillende manieren:

Aangepaste scripts: ontwikkelaars kunnen aangepaste scripts gebruiken om de nieuwste versie van de code op te halen en specifieke opdrachten uit te voeren om de toepassing te bouwen en deze in een productiestatus te brengen.

Vooraf gebakken installatiekopieën van virtuele machines: ontwikkelaars kunnen ook een virtuele machine inrichten en configureren met alle vereiste omgevingen en software om hun toepassing te implementeren. Als de configuratie is voltooid, kan er een momentopname worden gemaakt van de virtuele machine en kan deze worden geëxporteerd naar een installatiekopie van een virtuele machine. Deze installatiekopie kan worden verstrekt aan verschillende cloudindelingssystemen om automatisch te worden geïmplementeerd en geconfigureerd voor een productie-implementatie.

Systemen voor continue integratie: om de verschillende taken die betrokken zijn bij de implementatie te vereenvoudigen, kunnen HULPPROGRAMMA's voor continue integratie (CI) worden gebruikt om taken te automatiseren (zoals het ophalen van de nieuwste versie vanuit een opslagplaats, het bouwen van binaire toepassingsbestanden en het uitvoeren van testcases) die moeten worden voltooid op de verschillende computers waaruit de productie-infrastructuur bestaat. Voorbeelden van populaire CI-hulpprogramma's zijn Jenkins, Bamboo en Travis. Azure Pipelines is een CI-hulpprogramma dat specifiek is ontworpen voor gebruik met Azure-implementaties.

Downtime beheren

Voor bepaalde wijzigingen van de toepassing kan het nodig zijn om de toepassingsservices geheel of gedeeltelijk te stoppen om een wijziging door te voeren in de back-end van de toepassing. Ontwikkelaars zullen meestal een bepaald moment van de dag moeten plannen om onderbrekingen voor klanten van de toepassing zo veel mogelijk te beperken. Toepassingen die zijn ontworpen voor continue integratie kunnen deze wijzigingen mogelijk live uitvoeren op productiesystemen met minimale of geen onderbreking voor de clients van de toepassing.

Redundantie en fouttolerantie

Bij best practices voor de implementatie van een toepassing wordt er meestal van uitgegaan dat de cloudinfrastructuur tijdelijk is en op ieder moment kan veranderen of mogelijk niet beschikbaar is. Virtuele machines die bijvoorbeeld zijn geïmplementeerd in een IaaS-service kunnen worden gepland voor beëindiging door de cloudprovider, afhankelijk van het type SLA.

Ontwikkelaars van toepassingen moeten daarom geen hard-coding gebruiken om statische eindpunten vast te leggen voor verschillende onderdelen, zoals databases en opslageindpunten. In de toepassingscode moet ook niet worden aangenomen dat dergelijke eindpunten in gebruik zijn. Goed ontworpen toepassingen gebruiken in het ideale geval service-API's om resources op te vragen en er op een dynamische manier verbinding mee te maken.

Onherstelbare fouten in resources of connectiviteit kunnen zich op ieder moment voordoen. In het ontwerp van essentiële toepassingen moet rekening worden gehouden met dergelijke storingen en er moet dus sprake zijn van failover-redundantie.

Veel cloudproviders ontwerpen hun datacenters in regio's en zones. Een regio is een specifieke geografische locatie die een volledig datacenter omvat, terwijl zones afzonderlijke secties zijn binnen een datacenter die zijn geïsoleerd voor fouttolerantie. Twee of meer zones in een datacenter kunnen bijvoorbeeld een afzonderlijke infrastructuur hebben voor voeding, koeling en connectiviteit, zodat een storing in de ene zone geen gevolgen heeft voor de infrastructuur in de andere zone. Gegevens van regio's en zones worden doorgaans door cloudserviceproviders beschikbaar gesteld aan klanten en ontwikkelaars, zodat ze toepassingen kunnen ontwerpen en ontwikkelen die gebruikmaken van deze isolatiemogelijkheid.

Ontwikkelaars kunnen hun toepassing daarom configureren voor het gebruik van resources in meerdere regio's of zones om de beschikbaarheid van hun toepassing te verbeteren en fouten op te vangen die mogelijk optreden in een zone of regio. Ze moeten systemen configureren die verkeer kunnen routeren en balanceren tussen regio's en zones. Er kunnen ook DNS-servers worden geconfigureerd om te reageren op aanvragen voor het opzoeken van domeinen die horen bij bepaalde IP-adressen in elke zone, afhankelijk van waar de aanvraag vandaan komt. Op deze manier komt er een methode beschikbaar voor taakverdeling op basis van de geografische nabijheid van klanten.

Beveiliging en hardening in productie

Het uitvoeren van internettoepassingen in een openbare cloud vereist zorgvuldigheid. Omdat IP-adresbereiken in een cloud bekend staan als gewilde doelen voor aanvallen door kwaadwillende personen, is het belangrijk om ervoor te zorgen dat alle toepassingen die in de cloud worden geïmplementeerd zich houden aan best practices voor wat betreft het beveiligen en de hardening van eindpunten en interfaces. Dit zijn enkele voorbeelden van basisprincipes die absoluut moeten worden gevolgd:

• Alle software moet in de productiemodus worden geschakeld. De meeste software ondersteunt een 'foutopsporingsmodus' voor lokaal testen en een 'productiemodus' voor feitelijke implementaties. Toepassingen in de foutopsporingsmodus lekken doorgaans een grote hoeveelheid gegevens naar aanvallers die onjuist gevormde invoer verzenden en daardoor een eenvoudige bron van verkenning bieden voor hackers. Ongeacht of u een webframework gebruikt zoals Django en Rails of een database zoals Oracle, is het belangrijk om de relevante richtlijnen voor het implementeren van productietoepassingen te volgen.
• Toegang tot niet-open bare services moet worden beperkt tot bepaalde interne IP-adressen voor beheerderstoegang. Zorg ervoor dat beheerders zich niet rechtstreeks vanaf internet kunnen aanmelden bij een kritieke resource zonder een intern launchpad te bezoeken. Configureer firewalls met regels op basis van IP-adressen en poorten om de minimale set vereiste toegang te bieden, met name via SSH en andere hulpprogramma's voor externe verbinding.
• Volg het principe van minimale bevoegdheden. Voer alle services uit als de gebruiker met de minste bevoegdheden die nodig zijn om de vereiste rol uit te voeren. Beperk het gebruik van basisreferenties tot specifieke handmatige aanmeldingen door systeembeheerders die fouten moeten opsporen of een aantal kritieke problemen in het systeem moeten configureren. Dit geldt ook voor de toegang tot databases en beheervensters. De toegang moet over het algemeen worden beveiligd met een lang paar van willekeurige openbare en persoonlijke sleutels, en dit sleutelpaar moet veilig worden opgeslagen op een beperkt toegankelijke en versleutelde locatie. Alle wachtwoorden moeten eisen hebben ten aanzien van de sterkte van het wachtwoord.
• Gebruik gangbare verdedigingstechnieken en hulpprogramma's voor de detectie en preventie van indringers (IDS/IPS), SIEM (Security Information and Event Management), firewalls voor toepassingslagen en antimalwaresystemen.
• Stel een patch-schema op dat samenvalt met patch-releases door de leverancier van de systemen die u gebruikt. Leveranciers zoals Microsoft hanteren vaak een vaste releasecyclus voor patches.