Delen via

DevOps-patroon

  • Artikel

Code van één locatie en implementeer naar meerdere doelen in ontwikkel-, test- en productieomgevingen die zich mogelijk in uw lokale datacenter, privéclouds of de openbare cloud bevinden.

Context en probleem

De continuïteit, beveiliging en betrouwbaarheid van toepassingen zijn essentieel voor organisaties en essentieel voor ontwikkelteams.

Voor apps is vaak geherstructureerde code vereist om in elke doelomgeving te worden uitgevoerd. Dit betekent dat een app niet volledig draagbaar is. Het moet worden bijgewerkt, getest en gevalideerd terwijl het door elke omgeving wordt verplaatst. Code die in een ontwikkelomgeving is geschreven, moet bijvoorbeeld opnieuw worden geschreven om in een testomgeving te werken en opnieuw te worden geschreven wanneer deze uiteindelijk in een productieomgeving terechtkomt. Bovendien is deze code specifiek gekoppeld aan de host. Dit verhoogt de kosten en complexiteit van het onderhouden van uw app. Elke versie van de app is gekoppeld aan elke omgeving. De toegenomen complexiteit en duplicatie verhogen het risico op beveiliging en codekwaliteit. Bovendien kan de code niet direct opnieuw worden geïmplementeerd wanneer u mislukte herstelhosts verwijdert of extra hosts implementeert om de vraag te kunnen verhogen.

Oplossing

Met het DevOps-patroon kunt u een app bouwen, testen en implementeren die in meerdere clouds wordt uitgevoerd. Dit patroon combineert de praktijk van continue integratie en continue levering. Met continue integratie wordt code gebouwd en getest telkens wanneer een teamlid een wijziging doorvoert in versiebeheer. Continue levering automatiseert elke stap van een build naar een productieomgeving. Samen maken deze processen een releaseproces dat ondersteuning biedt voor implementatie in verschillende omgevingen. Met dit patroon kunt u uw code ontwerpen en vervolgens dezelfde code implementeren in een lokale omgeving, verschillende privéclouds en de openbare clouds. Verschillen in de omgeving vereisen een wijziging in een configuratiebestand in plaats van wijzigingen in de code.

DevOps-patroon

Met een consistente set ontwikkelhulpprogramma's in on-premises, privéclouds en openbare cloudomgevingen kunt u een praktijk van continue integratie en continue levering implementeren. Apps en services die zijn geïmplementeerd met behulp van het DevOps-patroon zijn uitwisselbaar en kunnen worden uitgevoerd op een van deze locaties, waarbij gebruik wordt gemaakt van on-premises en openbare cloudfuncties en -mogelijkheden.

Met behulp van een DevOps-releasepijplijn kunt u het volgende doen:

  • Start een nieuwe build op basis van codedoorvoeringen naar één opslagplaats.
  • Implementeer automatisch uw zojuist gebouwde code in de openbare cloud voor het testen van gebruikersacceptatie.
  • Automatisch implementeren in een privécloud zodra uw code is getest.

Problemen en overwegingen

Het DevOps-patroon is bedoeld om consistentie tussen implementaties te garanderen, ongeacht de doelomgeving. De mogelijkheden verschillen echter per cloud- en on-premises omgeving. Houd rekening met de volgende punten:

  • Zijn de functies, eindpunten, services en andere resources in uw implementatie beschikbaar op de doelimplementatielocaties?
  • Worden configuratieartefacten opgeslagen op locaties die toegankelijk zijn in clouds?
  • Werken implementatieparameters in alle doelomgevingen?
  • Zijn resourcespecifieke eigenschappen beschikbaar in alle doelclouds?

Zie Azure Resource Manager-sjablonen ontwikkelen voor cloudconsistentievoor meer informatie.

Houd bovendien rekening met de volgende punten bij het bepalen hoe u dit patroon implementeert:

Schaalbaarheid

Automatiseringssystemen voor implementaties vormen het belangrijkste controlepunt in de DevOps-patronen. Implementaties kunnen variëren. De selectie van de juiste servergrootte is afhankelijk van de grootte van de verwachte werkbelasting. Virtuele machines kosten meer om te schalen dan containers. Als u containers wilt gebruiken voor schalen, moet uw buildproces echter worden uitgevoerd met containers.

Beschikbaarheid

Beschikbaarheid in de context van devPattern betekent dat alle statusinformatie kan worden hersteld die is gekoppeld aan uw werkstroom, zoals testresultaten, codeafhankelijkheden of andere artefacten. Als u uw beschikbaarheidsvereisten wilt beoordelen, moet u rekening houden met twee algemene metrische gegevens:

  • Recovery Time Objective (RTO) geeft aan hoe lang u zonder systeem kunt gaan.

  • Recovery Point Objective (RPO) geeft aan hoeveel gegevens u kunt verliezen als een onderbreking van de service van invloed is op het systeem.

In de praktijk impliceren RTO en RPO redundantie en back-up. In de wereldwijde Azure-cloud is beschikbaarheid geen kwestie van hardwareherstel, dat deel uitmaakt van Azure, maar in plaats daarvan ervoor zorgen dat u de status van uw DevOps-systemen behoudt. In Azure Stack Hub kan hardwareherstel een overweging zijn.

Een andere belangrijke overweging bij het ontwerpen van het systeem dat wordt gebruikt voor implementatieautomatisering, is toegangsbeheer en het juiste beheer van de rechten die nodig zijn voor het implementeren van services in cloudomgevingen. Welke rechten zijn nodig om implementaties te maken, te verwijderen of te wijzigen? Een set rechten is bijvoorbeeld doorgaans vereist voor het maken van een resourcegroep in Azure en een andere om services in de resourcegroep te implementeren.

Meegaandheid

Het ontwerp van elk systeem op basis van het DevOps-patroon moet rekening houden met automatisering, logboekregistratie en waarschuwingen voor elke service in de hele portfolio. Gebruik gedeelde services, een toepassingsteam of beide, en houd ook beveiligingsbeleid en governance bij.

Implementeer productieomgevingen en ontwikkel-/testomgevingen in afzonderlijke resourcegroepen in Azure of Azure Stack Hub. Vervolgens kunt u de resources van elke omgeving bewaken en de factureringskosten per resourcegroep samenvouwen. U kunt resources ook verwijderen als een set, wat handig is voor testimplementaties.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon als:

  • U kunt code ontwikkelen in één omgeving die voldoet aan de behoeften van uw ontwikkelaars en implementeren in een omgeving die specifiek is voor uw oplossing, waar het mogelijk lastig is om nieuwe code te ontwikkelen.
  • U kunt de code en hulpprogramma's gebruiken die uw ontwikkelaars willen, zolang ze het continue integratie- en continue leveringsproces in het DevOps-patroon kunnen volgen.

Dit patroon wordt niet aanbevolen:

  • Als u de infrastructuur, het inrichten van resources, configuratie, identiteit en beveiligingstaken niet kunt automatiseren.
  • Als teams geen toegang hebben tot hybride cloudresources om een CI/CD-benadering (Continuous Integration/Continuous Development) te implementeren.

Volgende stappen

Voor meer informatie over onderwerpen die in dit artikel zijn geïntroduceerd:

Wanneer u klaar bent om het voorbeeld van de oplossing te testen, gaat u verder met de implementatiehandleiding voor hybride CI/CD-oplossingen van DevOps. De implementatiehandleiding bevat stapsgewijze instructies voor het implementeren en testen van de onderdelen. U leert hoe u een app implementeert in Azure en Azure Stack Hub met behulp van een hybride CI/CD-pijplijn (continuous integration/continuous delivery).