Monolithische toepassingen in containers plaatsen
Tip
Deze inhoud is een fragment uit het eBook, .NET Microservices Architecture for Containerized .NET Applications, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.
Mogelijk wilt u één monolithisch geïmplementeerde webtoepassing of -service bouwen en deze implementeren als een container. De toepassing zelf is mogelijk niet intern monolithisch, maar gestructureerd als verschillende bibliotheken, onderdelen of zelfs lagen (toepassingslaag, domeinlaag, gegevenstoegangslaag, enzovoort). Extern is het echter één container: één proces, één webtoepassing of één service.
Als u dit model wilt beheren, implementeert u één container die de toepassing vertegenwoordigt. Als u de capaciteit wilt vergroten, schaalt u uit, dat wil gezegd, voegt u meer exemplaren toe met een load balancer vooraan. De eenvoud is het beheren van één implementatie in één container of VM.
Afbeelding 4-1. Voorbeeld van de architectuur van een in een container geplaatste monolithische toepassing
U kunt meerdere onderdelen, bibliotheken of interne lagen in elke container opnemen, zoals geïllustreerd in afbeelding 4-1. Een monolithische containertoepassing heeft de meeste functionaliteit binnen één container, met interne lagen of bibliotheken, en schaalt uit door de container op meerdere servers/VM's te klonen. Dit monolithische patroon kan echter conflicteren met het containerprincipe 'een container doet één ding en doet het in één proces', maar kan in sommige gevallen in orde zijn.
Het nadeel van deze benadering wordt duidelijk als de toepassing groeit, waardoor deze moet worden geschaald. Als de hele toepassing kan worden geschaald, is dit geen probleem. In de meeste gevallen zijn echter slechts enkele delen van de toepassing de chokepunten waarvoor schaalaanpassing is vereist, terwijl andere onderdelen minder worden gebruikt.
In een typische e-commercetoepassing moet u bijvoorbeeld waarschijnlijk het subsysteem voor productinformatie schalen, omdat veel meer klanten door producten bladeren dan ze kopen. Meer klanten gebruiken hun winkelwagen dan de betalingspijplijn. Minder klanten voegen opmerkingen toe of bekijken hun aankoopgeschiedenis. En misschien hebt u slechts een handvol werknemers die de inhoud en marketingcampagnes moeten beheren. Als u het monolithische ontwerp schaalt, wordt alle code voor deze verschillende taken meerdere keren geïmplementeerd en geschaald op hetzelfde niveau.
Er zijn meerdere manieren om een toepassings horizontaal duplicatie te schalen, verschillende gebieden van de toepassing te splitsen en vergelijkbare bedrijfsconcepten of -gegevens te partitioneren. Maar naast het probleem van het schalen van alle onderdelen, moeten wijzigingen in één onderdeel volledig opnieuw worden getest van de hele toepassing en moet alle exemplaren volledig opnieuw worden geïmplementeerd.
De monolithische benadering is echter gebruikelijk, omdat de ontwikkeling van de toepassing in eerste instantie eenvoudiger is dan voor microservicesbenaderingen. Daarom ontwikkelen veel organisaties zich met behulp van deze architectuurbenadering. Hoewel sommige organisaties goed genoeg resultaten hebben gehad, hebben anderen limieten bereikt. Veel organisaties hebben hun toepassingen ontworpen met behulp van dit model omdat hulpprogramma's en infrastructuur het te moeilijk maakten om servicegeoriënteerde architecturen (SOA) jaren geleden te bouwen, en ze hebben de noodzaak pas gezien als de toepassing is gegroeid.
Vanuit het oogpunt van de infrastructuur kan elke server veel toepassingen binnen dezelfde host uitvoeren en een acceptabele verhouding hebben van efficiëntie in het gebruik van resources, zoals wordt weergegeven in afbeelding 4-2.
Afbeelding 4-2. Monolithische benadering: Host meerdere apps, elke app die als een container wordt uitgevoerd
Monolithische toepassingen in Microsoft Azure kunnen worden geïmplementeerd met behulp van toegewezen VM's voor elk exemplaar. Daarnaast kunt u de virtuele-machineschaalsets van Azure eenvoudig schalen. Azure-app Service kan ook monolithische toepassingen uitvoeren en eenvoudig exemplaren schalen zonder dat u de VM's hoeft te beheren. Sinds 2016 kunnen Azure-app Services ook enkele exemplaren van Docker-containers uitvoeren, waardoor de implementatie wordt vereenvoudigd.
Als QA-omgeving of een beperkte productieomgeving kunt u meerdere Docker-host-VM's implementeren en deze verdelen met behulp van de Azure Balancer, zoals wordt weergegeven in afbeelding 4-3. Hiermee kunt u schalen beheren met een grofkorrelige benadering, omdat de hele toepassing zich binnen één container bevindt.
Afbeelding 4-3. Voorbeeld van meerdere hosts die één containertoepassing omhoog schalen
Implementatie naar de verschillende hosts kan worden beheerd met traditionele implementatietechnieken. Docker-hosts kunnen worden beheerd met opdrachten zoals docker run of docker-compose handmatig, of via automatisering, zoals CD-pijplijnen (continuous delivery).
Een monolithische toepassing implementeren als een container
Er zijn voordelen voor het gebruik van containers voor het beheren van monolithische toepassingsimplementaties. Het schalen van containerinstanties is veel sneller en eenvoudiger dan het implementeren van extra VM's. Zelfs als u virtuele-machineschaalsets gebruikt, duurt het even voordat vm's worden gestart. Wanneer deze wordt geïmplementeerd als traditionele toepassingsexemplaren in plaats van containers, wordt de configuratie van de toepassing beheerd als onderdeel van de VIRTUELE machine, wat niet ideaal is.
Het implementeren van updates als Docker-installatiekopieën is veel sneller en netwerkefficiënt. Docker-installatiekopieën beginnen meestal in seconden, waardoor implementaties snel worden uitgevoerd. Het verwijderen van een Docker-installatiekopieënexemplaren is net zo eenvoudig als het uitgeven van een docker stop opdracht en wordt doorgaans in minder dan een seconde voltooid.
Omdat containers standaard onveranderbaar zijn, hoeft u zich geen zorgen te maken over beschadigde VM's. Bijwerken van scripts voor een virtuele machine kan daarentegen vergeten om rekening te houden met een bepaalde configuratie of bestand dat nog op schijf is overgelaten.
Hoewel monolithische toepassingen kunnen profiteren van Docker, hebben we alleen betrekking op de voordelen. Extra voordelen van het beheren van containers zijn afkomstig van het implementeren met container-orchestrators, waarmee de verschillende exemplaren en levenscyclus van elke containerinstantie worden beheerd. Het opsplitsen van de monolithische toepassing in subsystemen die afzonderlijk kunnen worden geschaald, ontwikkeld en geïmplementeerd, is uw ingangspunt in het domein van microservices.
Een toepassing met één container publiceren naar Azure-app Service
Of u nu een container wilt valideren die is geïmplementeerd in Azure of wanneer een toepassing gewoon een toepassing met één container is, Azure-app Service biedt een uitstekende manier om schaalbare services op basis van één container te bieden. Het gebruik van Azure-app Service is eenvoudig. Het biedt een uitstekende integratie met Git om uw code eenvoudig te maken, deze te bouwen in Visual Studio en deze rechtstreeks in Azure te implementeren.
Afbeelding 4-4. Een toepassing met één container publiceren naar Azure-app Service vanuit Visual Studio 2022
Als u zonder Docker andere mogelijkheden, frameworks of afhankelijkheden nodig hebt die niet worden ondersteund in Azure-app Service, moest u wachten totdat het Azure-team deze afhankelijkheden in App Service heeft bijgewerkt. Of u moest overschakelen naar andere services, zoals Azure Cloud Services of VM's, waar u meer controle had en u een vereist onderdeel of framework voor uw toepassing kon installeren.
Containerondersteuning in Visual Studio 2017 en hoger biedt u de mogelijkheid om alles op te nemen wat u wilt in uw toepassingsomgeving, zoals wordt weergegeven in afbeelding 4-4. Omdat u deze in een container uitvoert, kunt u, als u een afhankelijkheid aan uw toepassing toevoegt, de afhankelijkheid opnemen in uw Dockerfile of Docker-installatiekopieën.
Zoals ook wordt weergegeven in afbeelding 4-4, pusht de publicatiestroom een installatiekopieën via een containerregister. Dit kan het Azure Container Registry zijn (een register dicht bij uw implementaties in Azure en beveiligd door Azure Active Directory-groepen en -accounts), of een ander Docker-register, zoals Docker Hub of een on-premises register.
