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

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

Apps vereisen vaak geherstructureerde code om in elke doelomgeving uit te voeren. Dit betekent dat een app niet volledig draagbaar is. Het moet worden bijgewerkt, getest en gevalideerd wanneer deze 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 schrijven 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 hosts verwijdert of extra hosts implementeert om de vraag naar toe te nemen.

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 pattern

Met een consistente set ontwikkelhulpprogramma's in on-premises, privécloud- 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-release-pijplijn 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 in cloud- en on-premises omgevingen. Overweeg het volgende:

  • 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 consistentie in de cloud voor meer informatie.

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

Schaalbaarheid

Automatiseringssystemen voor implementaties zijn 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 workload. VM's kosten meer om te schalen dan containers. Uw build-proces moet echter worden uitgevoerd met containers om containers te gebruiken voor schalen.

Beschikbaarheid

Beschikbaarheid in de context van DevPattern betekent dat alle statusinformatie die aan uw werkstroom is gekoppeld, kan worden hersteld, zoals testresultaten, codeafhankelijkheden of andere artefacten. Overweeg twee algemene metrische gegevens als u uw beschikbaarheidsvereisten wilt beoordelen:

  • 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 zorgt u ervoor 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.

Beheerbaarheid

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 dit patroon gebruiken

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 moeilijk 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 voor het volgende:

  • Als u de infrastructuur niet kunt automatiseren, resources kunt inrichten, configureren, identiteiten en beveiligingstaken uitvoeren.
  • 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 CI/CD-pijplijn (hybrid continuous integration/continuous delivery).