In dit artikel wordt een blauw/groene implementatieoplossing met hoge beschikbaarheid beschreven voor toepassingen in Azure Spring Apps.
Het blauw/groene implementatiepatroon omvat het live houden van een bestaande versie van een toepassing (de blauwe versie genoemd) terwijl een nieuwe versie van de toepassing wordt geïmplementeerd (de groene versie genoemd). Met deze implementatie kunt u de nieuwe toepassingsversie onafhankelijk opnieuw opstarten, opwarmen en testen. Nadat de nieuwe versie van de toepassing wordt uitgevoerd, kunt u naar de toepassing overschakelen en elk nieuw binnenkomend verkeer naar de toepassing omleiden. Voor de gebruiker van de toepassing vindt de implementatie van de nieuwe versie plaats zonder zichtbare downtime. Met blauw/groen kunt u eenvoudig een nieuwe versie afbreken zonder dat dit van invloed is op de liveversie als een nieuwe implementatie niet werkt zoals verwacht.
Architectuur
In het volgende diagram ziet u de architectuur voor deze benadering:
Een Visio-bestand van deze architectuur downloaden.
Onderdelen
Deze oplossing maakt gebruik van de volgende onderdelen:
Azure Spring Apps is een modern microservicesplatform voor het uitvoeren van Java Spring Boot- en Steeltoe .NET Core-toepassingen . De service elimineert standaardcode voor het uitvoeren van microservices en helpt u snel robuuste apps te ontwikkelen in de cloud. U kunt Azure Spring Apps ook gebruiken om code per toepassing te implementeren.
GitHub is een platform voor codehosting dat versiebeheer en samenwerking biedt. GitHub biedt gedistribueerd versiebeheer voor Git, broncodebeheer en andere functies.
GitHub Actions helpt u bij het automatiseren van werkstromen voor softwareontwikkeling en -implementatie vanuit een opslagplaats. U kunt het platform gebruiken om een volledig geautomatiseerde CI/CD-installatie (Continuous Integration and Continuous Delivery) te maken. U kunt ook GitHub Actions gebruiken om omgevingen te maken waarvoor u regels kunt configureren, zoals revisoren vereisen.
Workflow
De oplossingsarchitectuur implementeert de volgende werkstroom:
Een ontwikkelaar brengt een wijziging aan in een toepassing. De GitHub-opslagplaats bevat de app-code die moet worden geïmplementeerd in Azure Spring Apps. Elke wijziging in de app-code vindt plaats onder broncodebeheer. GitHub voert de volgende taken uit:
Zorg ervoor dat wijzigingen worden gecontroleerd.
Onbedoelde of niet-geautoriseerde wijzigingen voorkomen.
Zorg ervoor dat de kwaliteitscontroles zijn voltooid.
De GitHub-opslagplaats bevat ook een GitHub Actions-werkstroom om de codewijzigingen te bouwen en de benodigde kwaliteitscontroles te voltooien. Nadat de code is gecompileerd, implementeert de GitHub Actions-werkstroom de nieuwste versie van de app-code in Azure Spring Apps. De GitHub Actions-werkstroom bevat de volgende stappen:
Bepaal de huidige actieve productieomgeving.
Implementeer de code in een niet-productieomgeving. Als er geen niet-productieomgeving bestaat, maakt u de omgeving.
Op dit moment in de implementatie blijft de oude (blauwe) versie van de app in de productie-implementatie al het productieverkeer ontvangen.
Wacht op implementatiebeoordeling en goedkeuring van nieuwe app.
Deze stap geeft de zojuist geïmplementeerde app (de groene versie) tijd om te starten en op te warmen.
Vóór goedkeuring kunt u de niet-productie-URL van de app gebruiken om de nieuwe versie te controleren en ervoor te zorgen dat deze gereed is.
Schakel na goedkeuring de productie-implementatie en de niet-productie-implementatie over.
Al het productieverkeer wordt nu gerouteerd naar de nieuwe versie van de app.
Notitie
Als u de nieuwe implementatie weigert, worden de omgevingen niet door GitHub overgeschakeld. De vorige versie blijft productieverkeer ontvangen.
Nadat goedkeuring en verkeer zijn overgeschakeld, verwijdert u de oude productie-implementatie.
Deze opschoningsstap produceert een rendabelere installatie.
Alternatieven
Deze oplossing maakt gebruik van GitHub Actions om de implementatie te automatiseren. U kunt ook Azure Pipelines of een ander CI/CD-automatiseringssysteem gebruiken als alternatief. Het voorbeeld in de sectie Scenario-implementatie maakt zoveel mogelijk gebruik van Azure CLI-instructies, zodat u deze installatie eenvoudig kunt vertalen naar een ander automatiseringsprogramma. Gebruik een CI/CD-hulpprogramma om een omgeving in te stellen en er een goedkeuringsstroom op te maken.
Deze architectuur maakt gebruik van Azure Spring Apps met implementaties als doelservice. U kunt Azure-app Service-faseringssites als alternatief gebruiken. Een site bevat de nieuwe versie van de toepassing, die opnieuw kan worden geladen, opgewarmd en getest voordat een sitewisseling wordt uitgevoerd. Met de sitewisseling wordt de nieuwe versie in productie genomen. Dit proces is ingebouwd in de service, dus de installatie is eenvoudig.
Als een ander alternatief kunt u elke Azure-service plaatsen die als host fungeert voor webeindpunten achter een oplossing voor taakverdeling. Als u deze benadering gebruikt, kunt u een tweede exemplaar van de Azure-service maken, waar u een nieuwe versie van uw toepassing kunt implementeren. Als volgende stap kunt u een implementatie zonder downtime maken door het verkeer bij de taakverdelingsoplossing over te schakelen naar de Azure-service die de nieuwe versie van de app bevat. Houd er rekening mee dat voor deze aanpak voor de blauw/groene implementatie aanzienlijke beheeroverhead is vereist.
Scenariodetails
Voor sommige cloudtoepassingen is het essentieel om de uptime zo hoog mogelijk te houden. Eén oplossing is het gebruik van een configuratie met hoge beschikbaarheid, die dubbele kosten kan kosten. Een andere oplossing is een plan voor herstel na noodgevallen, waarmee de toepassing na een storing opnieuw in een andere regio wordt weergegeven. De kosten voor de laatste kunnen lager zijn, maar het online brengen van de hele toepassing kost tijd.
In dit artikel wordt een proces beschreven voor hoge beschikbaarheid tijdens de implementatie van een nieuwe versie van een toepassing. In een traditionele configuratie worden de nieuwe bits van de toepassing geïmplementeerd in de service die als host fungeert voor de toepassing. Deze configuratie leidt vaak tot opnieuw laden en opnieuw opstarten van de toepassing. Tijdens dit proces is de toepassing niet beschikbaar.
Deze oplossing maakt gebruik van Azure Spring Apps voor het implementeren van blauw/groen implementatie en adressen voor het automatiseren van de implementatie van toepassingen.
Potentiële gebruikscases
Deze oplossing kan profiteren van elke organisatie waarvoor hoge beschikbaarheid is vereist. De oplossing is met name geschikt voor branches zoals e-commerce en gaming, waarbij downtime kan leiden tot verlies van bedrijfs- en omzet.
U kunt uw beschikbaarheid verder verbeteren door implementaties zonder downtime te implementeren. Zie de sectie Alternatieven van dit artikel voor meer informatie.
Overwegingen
Met de volgende oplossingsoverwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit framework is een reeks richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
Beschikbaarheid
Met deze oplossing kunt u de beschikbaarheid voor uw toepassing behouden tijdens de implementatie van een nieuwe versie. Het verhoogt niet de algehele SLA die Azure Spring Apps biedt. Servicefouten op het platform kunnen nog steeds van invloed zijn op uw app.
Als u een oplossing wilt om de algehele SLA van uw configuratie te verhogen, kijkt u naar het instellen van een Azure Spring Apps-service met hoge beschikbaarheid in meerdere regio's. In deze benadering voert u de configuratie uit met een globale taakverdelingsoplossing.
Schaalbaarheid
Deze oplossing werkt per toepassing, dus deze is zeer geschikt voor microservicestoepassingen. Hiermee kunnen toepassingsteams ook onafhankelijk van andere toepassingsteams werken zonder de uptime van de algehele oplossing te beïnvloeden.
Deze oplossing werkt ook het beste per toepassing, waarbij elke toepassing een eigen blauw/groene implementatiewerkstroom heeft. Als u toepassingen in dezelfde werkstroom combineert, wordt deze configuratie snel complex, dus we raden deze benadering niet aan.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
Afgezien van het instellen van opslagplaatsmachtigingen, kunt u overwegen de volgende beveiligingsmaatregelen te implementeren in Git-opslagplaatsen die code bevatten die u wilt implementeren in Azure Spring Apps:
Vertakkingsbeveiliging. Beveilig de vertakkingen die de productiestatus van uw toepassing vertegenwoordigen, zodat wijzigingen rechtstreeks naar deze vertakkingen worden gepusht. Vereisen dat elk wijzigingsvoorstel als pull-aanvraag (PR) wordt ingediend. Gebruik PULL's om automatische controles uit te voeren. Controles kunnen bestaan uit het compileren van alle code en het uitvoeren van eenheidstests op de code die een pull-aanvraag maakt of wijzigt.
Pr-beoordeling. Als u het principe van vier ogen wilt afdwingen, moet u ervoor zorgen dat pull-aanvragen ten minste één revisor hebben. U kunt ook de functie Voor eigenaren van GitHub-code gebruiken om personen of teams te definiëren die verantwoordelijk zijn voor het controleren van specifieke bestanden in een opslagplaats.
Onveranderbare geschiedenis. Sta alleen nieuwe doorvoeringen toe boven op bestaande wijzigingen. Onveranderbare geschiedenis is vooral belangrijk voor controledoeleinden.
Verdere beveiligingsmaatregelen. Vereisen dat uw GitHub-gebruikers meervoudige verificatie activeren. Sta ook alleen ondertekende doorvoeringen toe, die later niet kunnen worden gewijzigd.
We raden u ook aan om slechts één Azure Spring Apps-service te implementeren. In een productie-installatie moet u eerst uw code testen in andere omgevingen voordat u deze in productie implementeert. Uw productieomgeving moet zich bij voorkeur in een andere omgeving bevinden dan uw ontwikkel- en testomgeving.
Zie Azure Spring Apps implementeren in een virtueel netwerk voor meer informatie over extra beveiliging voor uw Azure Spring Apps-service. Als u de aanbevolen implementatie implementeert, kunt u geen door GitHub gehoste runners gebruiken. U moet uw eigen runner gebruiken voor de implementatiewerkstroom.
DevOps
Automatisering van deze installatie via GitHub Actions-werkstromen verhoogt de DevOps-productiviteit. Een van de handigste functies is de mogelijkheid om snel wijzigingen te herstellen die onverwacht werken. Negeer de nieuwe implementatie.
Teams beheert vaak meerdere omgevingen voor dezelfde toepassing. Het is gebruikelijk dat er verschillende versies van een toepassing zijn geïmplementeerd in verschillende Azure Spring Apps-services. De Git-opslagplaats, die de enige bron van waarheid is, laat zien welke versies van toepassingen momenteel in een cluster worden geïmplementeerd.
Kostenoptimalisatie
Kostenoptimalisatie omvat het zoeken naar manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
Gebruik de Azure-prijscalculator om een schatting van de kosten te maken.
Azure Spring Apps heeft een Basic-laag en een Standard-laag. Zie prijzen voor Azure Spring Apps voor meer informatie. Wanneer u de blauw/groene implementatiestrategie gebruikt, betaalt u voor slechts een korte tijd extra virtuele SPU, terwijl uw implementatie wordt uitgevoerd.
GitHub biedt een gratis service. Als u echter geavanceerde beveiligingsfuncties wilt gebruiken, zoals code-eigenaren of vereiste revisoren, hebt u het teamplan nodig. Zie de gitHub-pagina met prijzen voor meer informatie.
Scenario-implementatie
Zie de Geautomatiseerde blauw/groene implementatie voor GitHub-toepassingen in Azure Spring Apps-toepassingen voor een voorbeeld van deze configuratie. De opslagplaats bevat ook de stappen voor het instellen van uw Azure Spring Apps-service met behulp van een Bicep-sjabloon.
Medewerkers
Microsoft onderhoudt deze inhoud. De volgende inzender heeft de oorspronkelijke inhoud ontwikkeld.
Hoofdauteur:
- Gitte Vermeiren | FastTrack voor Azure Engineer
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- Deze architectuur implementeren met een stapsgewijze handleiding
- Blauw/groen implementatiestrategieën in Azure Spring Apps
- Quickstart: Apps bouwen en implementeren in Azure Spring Apps
- Een faseringsomgeving instellen in Azure Spring Apps
- GitHub: Informatie over GitHub Actions
- GitHub: Omgevingen gebruiken voor implementatie
- GitHub: Werkstromen opnieuw gebruiken