Aanbevelingen voor het ontwerpen van een supply chain voor workloadontwikkeling

  • Artikel

Van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

OE:06 Bouw een toeleveringsketen voor workloads die voorgestelde wijzigingen aanstuurt via voorspelbare, geautomatiseerde pijplijnen. De pijplijnen testen en promoten deze wijzigingen in omgevingen. Optimaliseer een toeleveringsketen om uw workload betrouwbaar, veilig, rendabel en performant te maken.

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een supply chain voor workloadontwikkeling die is gebaseerd op CI/CD-pijplijnen (continue integratie en continue levering). Ontwikkel een toeleveringsketen om ervoor te zorgen dat u beschikt over een voorspelbare, gestandaardiseerde methode voor het onderhouden van uw workload. CI/CD-pijplijnen zijn de manifestatie van de toeleveringsketen, maar u moet één toeleveringsketen hebben. En mogelijk hebt u verschillende pijplijnen die dezelfde processen volgen en dezelfde hulpprogramma's gebruiken.

Neem een toeleveringsketen op om uw workload te beschermen tegen schade die kan optreden wanneer u wijzigingen in workloads niet goed beheert. Houd altijd rekening met de status van uw workload, zodat u geen risico loopt op onvoorspelbaar gedrag. Dit risico leidt tot als u kritieke tijd moet besteden aan het niet-verantwoorden van wijzigingen wanneer zich problemen voordoen. Om deze risico's te minimaliseren, standaardiseert u de processen en hulpprogramma's die uw toeleveringsketen definiëren en zorgt u ervoor dat uw workloadteam zich volledig inzet voor het gebruik ervan.

Definition

Termijn Definitie
Toeleveringsketen In cloudworkloads is een toeleveringsketen een gestandaardiseerde suite met hulpprogramma's en processen die u gebruikt om wijzigingen in de infrastructuur en toepassingen in verschillende omgevingen te beïnvloeden.

Belangrijke ontwerpstrategieën

Notitie

De aanbevelingen in deze handleiding hebben betrekking op workloadomgevingen in een codepromotieketen. Sandbox- of andere experimentele en proof-of-concept-omgevingen vereisen minder striktheid en structuur.

Kernbeginselen

De volgende aanbevelingen kunnen u helpen bij het definiëren van de kernbeginselen van uw toeleveringsketen.

Breng voorgestelde workloadwijzigingen aan via processen en hulpprogramma's voor de toeleveringsketen. Dwing een strikt beleid af van geautomatiseerde implementaties op basis van sjablonen. Deze methode zorgt ervoor dat de configuratie van uw workload in alle omgevingen gestandaardiseerd, goed gedefinieerd en nauwkeurig wordt beheerd. Voer voor omgevingen in een codepromotieketen geen updates uit met behulp van handmatige processen of menselijke interactie met het besturingsvlak van het cloudplatform, bijvoorbeeld de portal of een API. Neem alle wijzigingen in de omgeving op via een pijplijn door de implementatieprocedures te volgen die u definieert. Als u dit beleid wilt afdwingen, kunt u overwegen de toegang tot alleen-lezen als standaard te beperken en een toegangsautorisatiepoort te gebruiken om schrijftoegang toe te staan.

Een belangrijk aspect van dit tenet is dat alle wijzigingen worden voorgesteldtotdat ze in productie worden geïmplementeerd. Door middel van geautomatiseerde tests, zoals integratie en betrouwbaarheidstests, stelt u uw toeleveringsketen in staat om wijzigingen automatisch te negeren.

Implementeer herhaalbare en onveranderbare infrastructuur als code (IaC). IaC is het beheer van infrastructuur in een beschrijvend model dat gebruikmaakt van een versiebeheersysteem dat de broncode weerspiegelt. Wanneer u een toepassing maakt, moet dezelfde broncode hetzelfde binaire bestand genereren wanneer deze wordt gecompileerd. Op een vergelijkbare manier genereert een IaC-model steeds dezelfde omgeving wanneer het wordt toegepast.

Neem IaC op om ervoor te zorgen dat uw team een standaard, goed opgezet proces volgt. Sommige organisaties wijzen één persoon of een kleine groep personen aan om de infrastructuur te implementeren en te configureren. Wanneer u een volledig geautomatiseerd proces implementeert, vereisen infrastructuurimplementaties minder beheer van personen. De verantwoordelijkheid wordt overgedragen naar het automatiseringsproces en de hulpprogramma's. Teamleden kunnen infrastructuurimplementaties initiëren om consistentie en kwaliteit te behouden.

Ontwerp uw workload als een logische groep onderdelen die u in één sjabloon kunt bundelen om implementaties eenvoudig en herhaalbaar te maken. U kunt deze bundels zien als stempels of schaaleenheden. Zie Patroon implementatiestempels voor meer informatie. Wanneer u uw workload moet implementeren om uit te schalen naar een andere regio of zone binnen dezelfde regio, implementeert u een stempel met behulp van een pijplijn. Afhankelijk van hoe u uw stempels ontwerpt, kunt u een subset van uw workload implementeren in plaats van de hele workload. Neem netwerkonderdelen op in uw IaC-pijplijnen om ervoor te zorgen dat uw implementatiestempels automatisch verbinding maken met bestaande resources.

Als u uw IaC-pijplijn wilt optimaliseren voor consistentie en efficiëntie, ontwerpt u een onveranderbare infrastructuur in plaats van een veranderlijke infrastructuur. Implementeer een onveranderbare infrastructuur om ervoor te zorgen dat alle systemen binnen het bereik gelijktijdig en identiek met elke implementatie worden vervangen door de bijgewerkte configuratie.

Gebruik één set codeassets en artefacten in alle omgevingen en pijplijnen. Een veelvoorkomend pijnpunt voor organisaties is wanneer niet-productieomgevingen verschillen van productieomgevingen. Het handmatig bouwen van productie- en niet-productieomgevingen kan leiden tot niet-overeenkomende configuraties tussen de omgevingen. Deze afwijking vertraagt het testen en maakt het waarschijnlijker dat wijzigingen schadelijk zijn voor een productiesysteem. Een IaC-benadering minimaliseert deze problemen. Wanneer u IaC-automatisering gebruikt, kunt u dezelfde infrastructuurconfiguratiebestanden voor alle omgevingen gebruiken om bijna identieke omgevingen te produceren. U kunt parameters toevoegen aan de infrastructuurconfiguratiebestanden en deze aanpassen om te voldoen aan de vereisten voor elke omgeving.

Om de kosten onder controle te houden, is er meestal een variantie tussen productie- en niet-productieomgevingen. In niet-productieomgevingen hebt u vaak niet dezelfde mate van redundantie en prestaties nodig als in productieomgevingen. Het aantal en de SKU van uw resources kunnen per omgeving verschillen. Zorg ervoor dat u de variantie beheert en begrijpt met behulp van gestandaardiseerde parameters om de voorspelbaarheid te behouden wanneer u wijzigingen aanbrengt.

Weerspiegel uw organisatiestructuur in uw toeleveringsketen- en pijplijnontwerpen. Uw organisatie is mogelijk verdeeld over teams. Elk team kan een deel van de toeleveringsketen beheren. Veel organisaties hebben bijvoorbeeld teams die infrastructuurdomeinen beheren, zoals netwerken, gegevens en rekenresources. Deze teams staan los van ontwikkelteams die toepassingsontwikkeling, -tests en -implementaties beheren. In sommige organisaties worden ontwikkel- en infrastructuurteams opgenomen in DevOps-teams die gezamenlijk alle infrastructuur- en toepassingsimplementaties beheren. Er zijn veel manieren om de teams te organiseren die betrokken zijn bij een toeleveringsketen. Uw toeleveringsketen is afhankelijk van de naadloze samenwerking tussen alle teams. Zorg ervoor dat alle teams standaardprocessen volgen en standaardtools gebruiken om de supply chain zo efficiënt mogelijk te maken.

Uw toeleveringsketen kan afhankelijk zijn van externe leveranciers als u delen van de levenscyclus van de workload uitbesteedt. Deze leveranciers zijn net zo essentieel voor het succes van uw toeleveringsketen als interne resources. Zorg ervoor dat alle teams het onderling eens zijn over de processen en hulpprogramma's die u gebruikt.

Uw implementatiemethode standaardiseren. Praat met de producteigenaar over de acceptabele hoeveelheid downtime van de productie voor uw workload. Afhankelijk van hoeveel downtime acceptabel is, kunt u de implementatiemethode kiezen die geschikt is voor uw vereisten. In het ideale geval moet u implementaties uitvoeren tijdens een onderhoudsvenster om complexiteit en risico's te verminderen. Als geen downtime acceptabel is, gebruikt u een blauw-groene implementatiemethode.

Gebruik een progressieve blootstellingsbenadering om het risico te verminderen dat niet-gedetecteerde bugs bij uw klanten in het algemeen worden geïntroduceerd. Deze methode, ook wel canary-implementaties genoemd, wordt in een geleidelijke volgorde geïmplementeerd in beheerde groepen gebruikers. Het vangt problemen op voordat ze van invloed zijn op meer gebruikers. De eerste implementatiegroep kan een subsectie zijn van uw klanten die op de hoogte zijn van de implementatiestrategie. Deze subsectie van klanten kan een bepaalde hoeveelheid onverwacht gedrag tolereren en feedback geven. Of het kan een groep interne gebruikers zijn, die de straal van fouten tijdens de implementatie helpen onder controle te houden.

Wanneer u uw implementatiemethode definieert, moet u een standaardbeleid hanteren waarbij alleen de kleinste levensvatbare wijziging in elke implementatie wordt geïmplementeerd. Afhankelijk van factoren zoals de ernst van de workload en de complexiteit van de onderdelen, bepaalt u de kleinste levensvatbare wijziging. Als u een onveranderbare infrastructuur gebruikt, is de kleinste haalbare wijziging doorgaans de implementatie van resources met de nieuwste configuratie om resources met de vorige versie te vervangen. Als u een veranderlijke infrastructuur gebruikt, kunt u besluiten dat de kleinste haalbare wijziging slechts één update is voor de groep resources binnen het bereik.

Volg een gelaagde benadering om verschillende levenscyclussen weer te geven. Basislagen moeten gedurende het grootste deel van de levenscyclus van de workload statisch blijven en toepassingslagen veranderen regelmatig. Als u rekening wilt houden met deze verschillen, moet u verschillende pijplijnen hebben om wijzigingen in elke laag door te voeren.

Een landingszone bevindt zich op de laagste laag. Een landingszone is een logische groepering van basiselementen, zoals abonnementen, beheergroepen, resourcegroepen, governancefuncties en netwerktopologie. Met een landingszone kunt u eenvoudig uw workload implementeren en beheren en biedt centrale operationele teams of platformteams een herhaalbare benadering van een omgevingsconfiguratie. Voor consistente omgevingen bieden alle Azure-landingszones een set gemeenschappelijke ontwerpgebieden, een referentiearchitectuur, een referentie-implementatie en een proces voor het aanpassen van een implementatie aan uw ontwerpvereisten. De ontwerpprincipes voor Azure-landingszones bieden aanbevolen procedures op basis van beleidgestuurd beheer, naast democratisering van abonnementen. Een landingszone moet minimale wijzigingen vereisen in de loop van de levenscyclus van uw workload. Zie Wat is een Azure-landingszone voor een voorbeeld van een landingszone. Deze conceptuele architectuur biedt een set adviezen die worden aanbevolen voor Azure.

Uw kerninfrastructuur en -functies, zoals netwerkcontrollers voor inkomend en uitgaand verkeer, taakverdeling, oplossingen voor netwerkroutering, DNS-beheer en kernservers, moeten ook af en toe grote wijzigingen vereisen. Het is echter mogelijk dat de configuratie regelmatig moet worden bijgewerkt.

Voor uw toepassing en gegevenslaag zijn regelmatige configuratie-updates en frequente wijzigingen in de infrastructuur vereist. Deze onderdelen moeten de meest dynamische pijplijnen hebben.

Plan een holistische teststrategie. Een kernprincipe van systeem betrouwbaarheid is het principe van verschuiving naar links . Het ontwikkelen en implementeren van een toepassing is een proces dat wordt weergegeven als een reeks stappen van links naar rechts. U moet het testen niet beperken tot het einde van het proces. Verschuif het testen zoveel mogelijk naar het begin of naar links. Fouten zijn goedkoper om te herstellen wanneer u ze vroeg ondervangt. Ze kunnen duur of onmogelijk zijn om later in de levenscyclus van de toepassing op te lossen.

Test alle code, inclusief toepassingscode, infrastructuursjablonen en configuratiescripts. De omgeving die toepassingen uitvoert, moet versiebeheer en worden geïmplementeerd via dezelfde mechanismen als toepassingscode. U kunt de omgeving testen en valideren met behulp van dezelfde testparadigma's die uw teams al gebruiken voor toepassingscode.

Gebruik indien mogelijk geautomatiseerd testen om consistentie te garanderen. Neem de volgende typen tests op in uw toeleveringsketenontwerp.

  • Eenheidstests: Eenheidstests worden doorgaans uitgevoerd als onderdeel van een continue integratieroutine. Eenheidstests moeten uitgebreid en snel zijn. Ze moeten in het ideale geval 100 procent van de code dekken en binnen 30 seconden worden uitgevoerd.

    Implementeer eenheidstests om te controleren of de syntaxis en functionaliteit van afzonderlijke codemodules op de juiste manier werken, bijvoorbeeld het produceren van een gedefinieerde uitvoer voor een bekende invoer. U kunt ook eenheidstests gebruiken om te controleren of IaC-assets geldig zijn.

    Moduletests toepassen op alle codeassets, inclusief sjablonen en scripts.

  • Betrouwbaarheidstests: Betrouwbaarheidstests controleren of een werkbelasting kan worden uitgevoerd in een testomgeving en wordt uitgevoerd zoals verwacht. Betrouwbaarheidstests verifiëren de interoperabiliteit van onderdelen niet.

    Betrouwbaarheidstests controleren of de implementatiemethodologie voor de infrastructuur en de toepassing werkt en of het systeem reageert zoals bedoeld nadat het proces is voltooid.

  • Integratietests: Integratietests zorgen ervoor dat de toepassingsonderdelen afzonderlijk werken en bepalen vervolgens of onderdelen op de gewenste manier met elkaar kunnen communiceren.

    Het kan veel tijd duren om een groot integratietestpakket uit te voeren. Daarom is het het beste om het shift left-principe op te nemen en vroeg in de levenscyclus van softwareontwikkeling tests uit te voeren. Reserveer integratietests voor scenario's die u niet kunt testen met een betrouwbaarheidstest of eenheidstest.

    U kunt indien nodig langlopende testprocessen met een regelmatig interval uitvoeren. Een regelmatig interval biedt een goede inbreuk en detecteert interoperabiliteitsproblemen tussen toepassingsonderdelen uiterlijk één dag nadat ze zijn geïntroduceerd.

    Sommige testscenario's profiteren van handmatige uitvoeringen. Gebruik handmatige tests wanneer u menselijke interactiviteitselementen in tests moet introduceren.

  • Acceptatietests: afhankelijk van de context kunt u handmatig acceptatietests uitvoeren. Het kan gedeeltelijk of volledig geautomatiseerd zijn. Acceptatietests bepalen of het softwaresysteem voldoet aan de vereiste specificaties.

    Het belangrijkste doel van deze test is om te evalueren of het systeem voldoet aan de bedrijfsvereisten en te bepalen of het systeem voldoet aan de vereiste criteria voor levering aan eindgebruikers.

Implementeer kwaliteitspoorten tijdens uw codepromotieproces via testen. Implementeer uw code in lagere omgevingen, zoals ontwikkeling en testen, en hoger via hogere omgevingen, zoals fasering en productie. Wanneer uw implementatie door de kwaliteitspoorten gaat, moet u ervoor zorgen dat deze voldoet aan uw kwaliteitsdoelen voordat de wijzigingen naar productie gaan. Uw zakelijke vereisten bepalen waar uw kwaliteitspoorten op gericht zijn. Houd ook rekening met de fundamentele principes van Well-Architected Framework: beveiliging, betrouwbaarheid en prestatie-efficiëntie.

Integreer ook goedkeuringswerkstromen in uw kwaliteitspoorten. Definieer en automatiseer zo nodig duidelijk goedkeuringswerkstromen. Definieer kwaliteitsacceptatiecriteria in uw automatisering, zodat u efficiënt en veilig door uw poorten kunt navigeren.

Azure-facilitering

Azure DevOps is een verzameling services waarmee u een gezamenlijke, efficiënte en consistente ontwikkelpraktijk kunt bouwen.

Azure Pipelines biedt build- en releaseservices ter ondersteuning van CI/CD in uw toepassingen.

GitHub Actions voor Azure kan worden geïntegreerd met Azure om implementaties te vereenvoudigen. Gebruik GitHub Actions om CI/CD-processen te automatiseren. U kunt werkstromen maken die elke pull-aanvraag naar uw opslagplaats bouwen en testen, of samengevoegde pull-aanvragen implementeren in productie.

U kunt Terraform, Bicep en Azure Resource Manager gebruiken voor IaC-implementaties. Afhankelijk van uw vereisten en de bekendheid van uw team met de hulpprogramma's, kunt u een of meer van deze hulpprogramma's gebruiken voor uw implementaties en het beheer van de resources.

Voorbeeld

Zie Azure Pipelines-basislijnarchitectuur voor een voorbeeld dat laat zien hoe u Azure Pipelines gebruikt om een CI/CD-pijplijn te bouwen.

Controlelijst voor Operation Excellence

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid