Microservices implementeren in Azure Container Apps

In dit scenario ziet u een bestaande workload die oorspronkelijk is ontworpen voor Kubernetes, die opnieuw is geplatformd voor uitvoering in Azure Container Apps. Container Apps ondersteunt brownfield-workloads waar teams infrastructuur en containerindeling willen vereenvoudigen.

De voorbeeldworkload is een containertoepassing voor microservices. Er wordt dezelfde werkbelasting hergebruikt die is gedefinieerd in de Microservices-architectuur in Azure Kubernetes Service (AKS). Deze architectuur host de workload in Container Apps opnieuw als toepassingsplatform.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Services die op de volgende manieren hetzelfde omgevingsvoordeel delen:

• Interne toegangsbeheerobjecten en servicedetectie
• Eén Log Analytics-werkruimte voor runtimelogboekregistratie
• Een veilige beheermethode voor geheimen en certificaten

Gegevensstroom

1. Opnameservice: Ontvangt clientaanvragen, buffert ze en publiceert deze vervolgens naar Azure Service Bus. Dit is het enige ingangspunt in de workload.

2. Werkstroomservice: Verbruikt berichten van Service Bus en verzendt ze naar onderliggende microservices.

3. Pakketservice: beheert pakketten. De service onderhoudt een eigen status in Azure Cosmos DB.

4. Drone scheduler service: plant drones en bewaakt drones tijdens de vlucht. De service onderhoudt een eigen status in Azure Cosmos DB.

5. Leveringsservice: Beheert geplande of in-transit zijnde leveringen. De service onderhoudt een eigen status in Azure Managed Redis.

6. Geheimen ophalen: Omdat het een bestaande workload is, hebben slechts enkele onderdelen toegang tot Azure Key Vault om runtimegeheimen op te halen. De andere services ontvangen deze geheimen uit de Container Apps-omgeving.

7. Logboeken en metrische gegevens: De omgeving en alle container-apps verzenden logboeken en metrische gegevens die door Azure Monitor worden gebruikt en verzamelen en visualiseren.

8. Containerafbeeldingen: Containerafbeeldingen worden gedownload van de bestaande Azure Container Registry die voorheen voor AKS is gebruikt en geïmplementeerd in de Container Apps-omgeving.

Onderdelen

De workload maakt gebruik van de volgende Azure-services in coördinatie met elkaar:

• Container Apps is een serverloos containerplatform dat containerindeling en -beheer vereenvoudigt. In deze architectuur fungeert Container Apps als het primaire hostingplatform voor alle microservices.

  De volgende functies vervangen veel van de mogelijkheden van de vorige AKS-architectuur:

  • Ingebouwde servicedetectie
  • Beheerde HTTP- en HTTP/2-eindpunten
  • Geïntegreerde taakverdeling
  • Logboekregistratie en controle
  • Automatisch schalen op basis van HTTP-verkeer of gebeurtenissen mogelijk gemaakt door op Kubernetes gebaseerde gebeurtenisgestuurde automatische schaalaanpassing (KEDA)
  • Toepassingsupgrades en versiebeheer

• Container Registry is een beheerde registerservice voor het opslaan en beheren van privécontainerinstallatiekopieën. In deze architectuur is het de bron van alle containerafbeeldingen die worden ingezet in de Container Apps omgeving. Het register is hetzelfde dat wordt gebruikt in de AKS-implementatie.

• Azure Cosmos DB is een wereldwijd gedistribueerde databaseservice met meerdere modellen. In deze architectuur maakt de drone scheduler-service gebruik van Azure Cosmos DB als gegevensopslag.

• Azure DocumentDB is een volledig beheerde mongoDB-compatibele databaseservice voor het bouwen van moderne toepassingen. In deze architectuur gebruikt de pakketservice Azure DocumentDB als gegevensarchief.

• Service Bus is een cloudberichtenservice die asynchrone communicatiemogelijkheden en hybride integratie biedt. In deze architectuur wordt asynchrone berichtenverwerking afgehandeld tussen de inname-service en de taakgebaseerde, werkstroommicroservice. De rest van de services in de bestaande toepassing zijn ontworpen zodat andere services deze kunnen aanroepen met HTTP-aanvragen.

• Azure Managed Redis is een cacheservice in het geheugen. In deze architectuur vermindert het de latentie en verbetert de doorvoer voor vaak gebruikte droneleveringsgegevens.

• Key Vault is een cloudservice voor het veilig opslaan en openen van geheimen, zoals API-sleutels, wachtwoorden en certificaten. In deze architectuur gebruiken de droneplanner en leveringsservices door de gebruiker toegewezen beheerde identiteiten om te authenticeren bij Key Vault en geheimen op te halen die nodig zijn voor hun vereisten voor uitvoering.

• Azure Monitor is een uitgebreide bewakingsoplossing waarmee telemetriegegevens worden verzameld en geanalyseerd. In deze architectuur worden metrische gegevens en logboeken van alle toepassingsonderdelen verzameld en opgeslagen via een Log Analytics-werkruimte. U gebruikt deze gegevens om de toepassing te bewaken, waarschuwingen en dashboards in te stellen en hoofdoorzaakanalyse van fouten uit te voeren.

  • Application Insights is een service voor het beheer van toepassingsprestaties die uitbreidbare bewakingsmogelijkheden biedt. In deze architectuur wordt elke service geïnstrueerd met de Application Insights SDK om de prestaties van toepassingen te bewaken.

Alternatieven

De geavanceerde AKS-microservicesarchitectuur beschrijft een alternatief scenario van dit voorbeeld dat gebruikmaakt van Kubernetes.

Scenariodetails

U kunt de implementatie en het beheer van microservicecontainers vereenvoudigen met behulp van Container Apps, een serverloze omgeving voor het hosten van toepassingen in containers.

Fabrikam, Inc., een fictief bedrijf, implementeert een workload voor het bezorgen van drones waarbij gebruikers een drone aanvragen om goederen op te halen voor levering. Wanneer een klant een ophaalbewerking plant, wijst een back-endsysteem een drone toe en meldt de gebruiker een geschatte ophaaltijd.

De microservicestoepassing is geïmplementeerd in een AKS-cluster. Maar het Fabrikam-team profiteerde niet van de geavanceerde of platformspecifieke AKS-functies. Ze hebben de toepassing gemigreerd naar Container Apps, waardoor ze de volgende acties konden uitvoeren:

• Gebruik minimale codewijzigingen wanneer u de toepassing verplaatst van AKS naar Container Apps. De codewijzigingen waren gerelateerd aan waarneembaarheidsbibliotheken die uitgebreide logboeken en metrische gegevens bevatten met Kubernetes-knooppuntinformatie, die niet relevant zijn in de nieuwe omgeving.

• Implementeer zowel infrastructuur als de workload met Bicep-sjablonen: er waren geen Kubernetes YAML-manifesten nodig om hun toepassingscontainers te implementeren.

• De toepassing beschikbaar maken via beheerde toegangspoort. Ingebouwde ondersteuning voor externe, op HTTPS gebaseerde ingress om de opnameservice beschikbaar te maken, verwijdert de noodzaak om hun eigen ingangen te configureren.

• Containerafbeeldingen ophalen uit Container Registry. Container Apps is compatibel met alle Linux-basisinstallatiekopieën die zijn opgeslagen in elke beschikbare opslagplaats.

• Gebruik de revisiefunctie ter ondersteuning van de levenscyclusbehoeften van toepassingen. Ze kunnen meerdere revisies van een bepaalde container-app uitvoeren en het verkeer verdelen over deze revisies om A/B-tests of scenario's voor blauw-groene implementatie mogelijk te maken.

• Gebruik een beheerde identiteit om te verifiëren met Key Vault en Container Registry.

Potentiële gebruikscases

Implementeer een op brownfield microservice gebaseerde toepassing in een PaaS (Platform as a Service) om het beheer te vereenvoudigen en de complexiteit van het uitvoeren van een containerorchestrator te voorkomen. De brownfield-werklast heeft om de volgende redenen geld bespaard door gebruik te maken van deze architectuur in plaats van de Kubernetes-implementatie:

• De keuze van workloadprofielen
• Minder tijd besteed aan operationele taken van dag 2 voor het operationele team
• De mogelijkheid om overprovisionering te voorkomen

Overweeg andere veelgebruikte toepassingen van Container Apps:

• Voer workloads in containers uit op een serverloos platform op basis van verbruik.
• Toepassingen automatisch schalen op basis van HTTP- of HTTPS-verkeer en gebeurtenisgestuurde triggers die worden ondersteund door KEDA.
• Minimaliseer de onderhoudsoverhead voor toepassingen in containers.
• API-eindpunten implementeren.
• Achtergrondverwerkingstoepassingen hosten.
• Afhandelen van gebeurtenisgestuurde verwerking.

Optimizations

Het doel van het workloadteam is het migreren van de bestaande workload naar Container Apps met minimale codewijzigingen. Maar u moet verschillende optimalisaties maken om de architectuur en workload-implementatie na de migratie te verbeteren.

Geheimbeheer verbeteren

De workload maakt gebruik van een hybride benadering voor het beheren van geheimen. Beheerde identiteiten zijn alleen van toepassing op services waarbij het overschakelen naar beheerde identiteiten geen codewijzigingen vereist. De droneplanner en leveringsservices maken gebruik van door de gebruiker toegewezen beheerde identiteiten met Key Vault voor toegang tot opgeslagen geheimen. Voor de overige services zijn codewijzigingen vereist om beheerde identiteiten te gebruiken, zodat deze services geheimen gebruiken die de Container Apps-omgeving biedt.

Een betere aanpak is het bijwerken van alle code ter ondersteuning van beheerde identiteiten met behulp van de app- of taakidentiteit in plaats van door de omgeving verstrekte geheimen. Voor meer informatie over workloadidentiteiten, zie Beheerde identiteiten in Container Apps.

Vermijd ontwerpen waarvoor één revisiemodus is vereist

De container-app van de werkstroomservice draait in enkelvoudige revisiemodus. In de modus voor één revisie heeft de app één revisie die wordt ondersteund door nul of meer replica's. Een replica bestaat uit de toepassingscontainer en eventuele vereiste sidecars. In dit voorbeeld worden geen sidecars gebruikt, dus elke replica is één container. De werkstroomservice is niet ontworpen voor doorstuurcompatibiliteit met berichtschema's. Twee verschillende versies van de service mogen nooit gelijktijdig worden uitgevoerd.

Als het Service Bus-berichtschema moet worden gewijzigd, moet u de bus leegmaken voordat u de nieuwe versie van de werkstroomservice implementeert. Een betere aanpak is het bijwerken van de servicecode voor forward compatibility en het gebruik van de modus voor meerdere revisies om downtime te verminderen die samenhangt met het leegmaken van wachtrijen.

Werk op basis van taken overwegen

De werkstroomservice wordt geïmplementeerd als een langlopende container-app. Maar het kan ook worden uitgevoerd als een taak in Container Apps. Een taak is een in een container geplaatste toepassing die op aanvraag wordt gestart, wordt uitgevoerd tot voltooiing op basis van beschikbaar werk, en vervolgens resources afsluit en vrij maakt. Taken kunnen economischer zijn dan continu draaiende replicaties. Het migreren van de service voor uitvoering als een Container Apps-taak op basis van werk dat beschikbaar is in de wachtrij, kan een praktische optie zijn. Dit hangt af van een typisch wachtrijvolume en hoe eindig, paralleliseerbaar en geoptimaliseerd voor resources de werkstroomdienst wordt geschreven. Experimenteer en verifieer om de beste aanpak te bepalen.

Toegangsbeheer implementeren

De workload maakt gebruik van de ingebouwde externe toegangsfunctie van Container Apps om de invoerservice te exposeren. De benadering voor inkomend beheer biedt niet de mogelijkheid om uw ingangspunt volledig te positioneren achter een Web Application Firewall (WAF) of om deze op te nemen in Azure DDoS Protection-plannen. U moet alle webgerichte workloads fronteren met een WAF. Als u deze configuratie in de Container Apps-omgeving wilt bereiken, moet u het ingebouwde openbare toegangsbeheerobject uitschakelen en Application Gateway of Azure Front Door toevoegen.

Moderniseren met Dapr

U kunt de workload verder moderniseren door de integratie met Distributed Application Runtime (Dapr) uit te voeren. Het voegt abstractie toe tussen workloadcode en statusarchieven, berichtensystemen en servicedetectiemechanismen. Zie Microservices implementeren met Container Apps en Dapr voor meer informatie. Als uw workload in Kubernetes al gebruikmaakt van Dapr of algemene KEDA-schaalders, is migratie naar Container Apps vaak eenvoudig en behoudt u die mogelijkheid.

Migreren naar gebruikersverificatie en autorisatie

De workload delegeert geen autorisatie naar een gateway. De ingestiedienst verwerkt de autorisatie van zijn klanten. Een betere benadering is om deze verantwoordelijkheid te offloaden naar de ingebouwde verificatie- en autorisatiefunctie, ook wel Easy Auth genoemd. Deze wijziging maakt gebruik van platformmogelijkheden en vermindert aangepaste code in de opnamemicroservice.

Overwegingen

Met de volgende overwegingen worden de pijlers van het Microsoft Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid helpt ervoor te zorgen dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Controlelijst ontwerpbeoordeling voor betrouwbaarheidvoor meer informatie.

Container Apps helpt u bij het implementeren, beheren, onderhouden en bewaken van de toepassingen in de workload. U kunt de betrouwbaarheid verbeteren door de belangrijkste aanbevelingen te volgen. Sommige aanbevelingen worden geïmplementeerd tijdens de migratie vanuit Kubernetes.

• Met revisies kunt u toepassingsupdates implementeren zonder uitvaltijd. U kunt revisies gebruiken om de implementatie van toepassingsupdates te beheren en verkeer te splitsen tussen de revisies ter ondersteuning van blauw-groene implementaties en A/B-tests.

• Met de waarneembaarheidsfuncties van Container Apps hebt u inzicht in onderdelen die in de omgeving worden uitgevoerd. Container Apps kan worden geïntegreerd met Application Insights en Log Analytics. U gebruikt deze gegevens om bewerkingen bij te houden en waarschuwingen in te stellen op basis van metrische gegevens en gebeurtenissen als onderdeel van uw waarneembaarheidssysteem.

  Prestatiebewaking helpt u bij het evalueren van de toepassing onder belasting. Metrische gegevens en logboeken bieden gegevens voor het herkennen van trends, het onderzoeken van fouten en het uitvoeren van hoofdoorzaakanalyses.

• Gebruik status- en gereedheidstests om langzaam startende containers te verwerken en te voorkomen dat er verkeer wordt verzonden voordat ze gereed zijn. De Kubernetes-implementatie bevat deze eindpunten. Blijf ze gebruiken als ze effectieve signalen bieden.

• Wanneer een service onverwacht wordt beëindigd, start Container Apps deze automatisch opnieuw op. Servicedetectie is ingeschakeld, zodat de werkstroomservice de downstream microservices kan detecteren. Gebruik tolerantiebeleid om time-outs af te handelen en circuitonderbrekerlogica te introduceren zonder dat u de code verder hoeft aan te passen.

• Schakel automatisch schaalregels in om te voldoen aan het vraagniveau naarmate verkeer en workloads toenemen.

• Gebruik de dynamische taakverdelings- en schaalfuncties van Container Apps om de beschikbaarheid te verbeteren. Overdimensioneer het subnet van uw omgeving zodat het altijd voldoende beschikbare IP-adressen heeft voor toekomstige replica's of taken.

• Sla de status niet rechtstreeks op in de Container Apps-omgeving, omdat alle status verloren gaat wanneer de replica wordt afgesloten. Externaliseer de status naar een toegewezen statusopslag voor elke microservice. Deze architectuur verdeelt de status over drie afzonderlijke opslagplaatsen: Azure Managed Redis, Azure Cosmos DB for NoSQL en Azure DocumentDB.

• Implementeer alle resources, inclusief Container Apps, met behulp van een topologie met meerdere zones. Zie Ondersteuning voor beschikbaarheidszones in Container Apps voor meer informatie.

  Stel het minimale aantal replica's voor niet-tijdelijke toepassingen in op ten minste één replica voor elke beschikbaarheidszone. Tijdens gebruikelijke operationele omstandigheden worden replica's betrouwbaar verdeeld en gebalanceerd over beschikbaarheidszones in de regio.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie voor meer informatie controlelijst ontwerpbeoordeling voor Security.

Geheimen

• Uw container-app kan gevoelige waarden opslaan en ophalen als geheimen. Nadat u een geheim voor de container-app hebt gedefinieerd, is het beschikbaar voor gebruik door de toepassing en eventuele bijbehorende schaalregels. Als u in de modus voor meerdere revisies werkt, delen alle revisies dezelfde geheimen. Omdat geheimen worden beschouwd als wijzigingen in het toepassingsbereik, wordt er geen nieuwe revisie gemaakt als u de waarde van een geheim wijzigt. Maar voor alle actieve revisies om de nieuwe geheime waarde te laden, moet u deze opnieuw opstarten. In dit scenario worden waarden voor toepassings- en omgevingsvariabelen gebruikt.

• Herschrijf de servicecode om de eigen beheerde identiteit van de app te gebruiken voor verificatie bij afhankelijkheden in plaats van vooraf gedeelde geheimen. Alle afhankelijkheden hebben SDK's die ondersteuning bieden voor verificatie van beheerde identiteiten.

• U kunt veilig gevoelige waarden opslaan in omgevingsvariabelen op toepassingsniveau. Wanneer omgevingsvariabelen worden gewijzigd, maakt de container-app een nieuwe revisie.

Netwerkbeveiliging

• Als u externe toegang wilt beperken, wordt alleen de opnameservice geconfigureerd voor extern inkomend verkeer. De back-endservices kunnen alleen worden geopend via het interne virtuele netwerk in de Container Apps-omgeving en worden geconfigureerd als interne modus. Maak waar nodig alleen services beschikbaar op internet.

  Omdat deze architectuur gebruikmaakt van de ingebouwde functie voor inkomend verkeer, biedt deze oplossing niet de mogelijkheid om uw inkomend punt achter een WAF volledig te positioneren of op te nemen in DDoS Protection-plannen. Zet al je web-gerelateerde workloads achter een webapplicatiefirewall. Zie Toegangsbeheer voor inkomend verkeer implementeren voor meer informatie over verbeteringen in inkomend verkeer.

• Wanneer u een omgeving maakt, kunt u een aangepast virtueel netwerk opgeven. Anders genereert en beheert Microsoft automatisch een virtueel netwerk. U kunt dit door Microsoft beheerde virtuele netwerk niet manipuleren, bijvoorbeeld door netwerkbeveiligingsgroepen (NSG's) toe te voegen of tunneling van verkeer naar een uitgaande firewall af te dwingen. In het voorbeeld wordt een automatisch gegenereerd virtueel netwerk gebruikt, maar een aangepast virtueel netwerk verbetert de beveiliging. Met een aangepast netwerk kunt u NSG's en door de gebruiker gedefinieerde route (UDR)-routering toepassen via Azure Firewall.

Zie Netwerkarchitectuur in Container Apps voor meer informatie over netwerktopologieopties, waaronder ondersteuning voor privé-eindpunten voor inkomend verkeer.

Workloadidentiteiten

• Container Apps ondersteunt door Microsoft Entra beheerde identiteiten waarmee uw app zichzelf kan verifiëren bij andere resources die worden beveiligd door Microsoft Entra-id, zoals Key Vault, zonder referenties in uw container-app te beheren. Een container-app kan door het systeem toegewezen identiteiten, door de gebruiker toegewezen identiteiten of beide gebruiken. Voor services die geen ondersteuning bieden voor Microsoft Entra ID-verificatie, slaat u geheimen op in Key Vault en gebruikt u een beheerde identiteit voor toegang tot de geheimen.

• Gebruik één toegewezen, door de gebruiker toegewezen beheerde identiteit voor toegang tot Container Registry. Container Apps ondersteunt het gebruik van een andere beheerde identiteit voor workloadbewerking dan voor toegang tot containerregisters. Deze benadering biedt gedetailleerd toegangsbeheer. Als uw workload meerdere Container Apps-omgevingen heeft, deel uw identiteit niet tussen gevallen.

• Gebruik door het systeem toegewezen beheerde identiteiten voor workloadidentiteiten om de levenscyclus van de identiteit te koppelen aan de levenscyclus van het workloadonderdeel.

Meer aanbevelingen voor beveiliging

• De Kubernetes-implementatie van deze workload biedt beveiliging met behulp van de mogelijkheden van Microsoft Defender for Containers. In deze architectuur beoordeelt Defender for Containers alleen het beveiligingsprobleem van de containers in uw Container Registry. Defender for Containers biedt geen runtimebeveiliging voor Container Apps. Evalueer aanvulling op niet-Microsoft-beveiligingsoplossingen als runtimebeveiliging een vereiste is.

• Voer de workload niet uit in een gedeelde Container Apps-omgeving. Segmenteer deze vanuit andere workloads of onderdelen die geen toegang nodig hebben tot deze microservices. Maak afzonderlijke Container Apps-omgevingen. Apps en taken die worden uitgevoerd in een Container Apps-omgeving kunnen elke service detecteren en bereiken die in de omgeving wordt uitgevoerd met interne ingress ingeschakeld.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

• Bekijk een voorbeeld van een prijsraming voor de workload. Gebruik de Azure-prijscalculator. Configuraties variëren, dus pas deze aan zodat deze overeenkomt met uw scenario.

• In dit scenario zijn Azure Cosmos DB, Azure Managed Redis en Service Bus Premium de belangrijkste kostenfactoren.

• Voor containers die doorgaans een lage CPU- en geheugenhoeveelheid verbruiken, evalueert u eerst het workloadprofiel van het verbruik. Maak een schatting van de kosten van het verbruiksprofiel op basis van uw gebruik om basislijnkostengegevens te verzamelen en andere profielen te evalueren. U kunt bijvoorbeeld een toegewezen workloadprofiel gebruiken voor onderdelen die zeer voorspelbaar en stabiel gebruik hebben en toegewezen knooppunten kunnen delen. Voor kostenoptimalisatie onderhoudt u een veelvoud van drie knooppunten voor elk toegewezen profiel om ervoor te zorgen dat er voldoende rekenhosts en replicadistributie in beschikbaarheidszones zijn.

• Elimineer rekenkosten tijdens perioden van inactiviteit door ervoor te zorgen dat onderdelen naar nul kunnen worden geschaald, zodat u alleen betaalt wanneer dat nodig is. Deze aanpak vermindert de kosten voor apps met variabel of onregelmatig gebruik. Statuscontroles verhinderen meestal dat volledige schaal naar nul wordt gereduceerd. In de architectuur kunt u de workflowservice herimplementeren als een taak om te profiteren van schaal-naar-nul tijdens niet-actieve perioden. Deze benadering koppelt goed aan workloads die een verbruiksabonnement kunnen gebruiken.

• Als u netwerkkosten tussen regio's wilt voorkomen, implementeert u alle onderdelen, zoals statusarchieven en het containerregister, in dezelfde regio.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie controlelijst ontwerpbeoordeling voor Operational Excellencevoor meer informatie.

• Gebruik GitHub Actions- of Azure Pipelines-integratie om geautomatiseerde CI/CD-pijplijnen (continue integratie en continue implementatie) in te stellen.

• Gebruik de multi-revisiemodus met verkeersverdeling om wijzigingen in uw workloadcode en toepassing van schaalregels te testen.

• Integreer met Application Insights en Log Analytics om inzicht te bieden in uw workload. Gebruik dezelfde Log Analytics-werkruimte als de rest van de onderdelen van uw workload om alle inzichten in workloads bij elkaar te houden.

• Gebruik infrastructuur als code (IaC), zoals Bicep of Terraform, om alle infrastructuurimplementaties te beheren. Implementaties zijn onder andere de Container Apps-omgeving, het containerregister en de microservicestatusarchieven. Scheid de microservice-implementatiepijplijnen van de infrastructuurpijplijnen, omdat ze vaak geen vergelijkbare levenscyclus delen. Uw declaratieve pijplijn voor de Azure-infrastructuur moet alle resources behalve de container-app-resources implementeren.

• Gebruik een imperatieve benadering voor het maken, bijwerken en verwijderen van container-apps uit de omgeving. Het is vooral belangrijk als u de logica voor het verplaatsen van verkeer dynamisch tussen revisies aanpast. Gebruik een GitHub-actie of Azure Pipelines-taak in uw implementatiewerkstromen. Deze imperatieve benadering kan worden gebaseerd op YAML-app-definities. Om gezondheidscontrolefouten te minimaliseren, zorg er altijd voor dat uw pipeline uw containerregister vult met het nieuwe containerbeeld voordat u de container-app implementeert.

  Een belangrijke wijziging van de Kubernetes-implementatie is de verschuiving van het beheren van Kubernetes-manifestbestanden, zoals het definiëren van Deployment Kubernetes-objecten. Kubernetes biedt een atomische samen succes of samen falen benadering van microservice-implementatie via dit manifestobject. In Container Apps wordt elke microservice onafhankelijk geïmplementeerd. Uw implementatiepijplijnen worden verantwoordelijk voor het organiseren van elke sequentiërings- en terugdraaistrategie die nodig is voor een veilige implementatie.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

• De workload wordt verdeeld over meerdere microservicetoepassingen.

• Elke microservice is onafhankelijk en deelt geen status met andere microservices, waardoor onafhankelijk schalen mogelijk is.

• Gebruik Container Apps-taken voor eindige procesuitvoeringen om tijdelijke runtimes te implementeren en het resourceverbruik voor niet-actieve services te verminderen. Evalueer de gevolgen voor de prestaties van het activeren en deactiveren van taken versus het houden van componenten operationeel en gereed.

• Autoscaling is ingeschakeld. Geef waar mogelijk de voorkeur aan schalen op basis van gebeurtenissen ten opzichte van schaalaanpassing op basis van metrische gegevens. De werkstroomservice, indien ontworpen om deze te ondersteunen, kan bijvoorbeeld worden geschaald op basis van de diepte van de Service Bus-wachtrij. De standaard automatische schaalaanpassing is gebaseerd op HTTP-aanvragen. Tijdens een herplatforming is het belangrijk om te beginnen met dezelfde schaalbenadering en vervolgens later schaaloptimalisaties te evalueren.

• Aanvragen worden dynamisch verdeeld over beschikbare replica's van een revisie.

• Metrische gegevens, waaronder het gebruik van CPU, geheugen, bandbreedtegegevens en opslag, zijn beschikbaar via Azure Monitor.

Dit scenario implementeren

Volg de stappen in de README.md in de voorbeeldopslagplaats van Container Apps.

Medewerkers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Medewerkers:

• Julien Strebler | Cloud Solution Architect
• Steve Caravajal | Cloud Solution Architect
• Simon Kurtz | Cloud Solution Architect

Volgende stappen

• documentatie voor Container Apps

Verwante resources

• Architectuurstijl voor microservices
• Een microservicearchitectuur ontwerpen
• Een CI/CD-pijplijn bouwen voor AKS-apps met behulp van Azure Pipelines
• Geavanceerde AKS-microservicesarchitectuur