De rol van DSC in een CI/CD-pijplijn begrijpen

In dit artikel worden de typen benaderingen beschreven die beschikbaar zijn voor het combineren van configuraties en resources. Het doel voor elk scenario is hetzelfde, om de complexiteit te verminderen wanneer meerdere configuraties de voorkeur hebben om een serverimplementatie-eindstatus te bereiken. Een voorbeeld hiervan zijn meerdere teams die bijdragen aan het resultaat van een serverimplementatie, zoals een toepassingseigenaar die de toepassingsstatus onderhoudt en een centraal team dat wijzigingen in beveiligingsbasislijnen vrijgeeft. De nuances van elke benadering, inclusief de voordelen en risico's, worden hier beschreven.

Typen samenwerkingsbewerkingstechnieken

Er zijn twee oplossingen ingebouwd in Local Configuration Manager om dit concept in te schakelen:

Concept	Gedetailleerde informatie
Gedeeltelijke configuraties	Documentatie
Samengestelde resources	Documentatie

Inzicht in de impact van elke benadering

Een van deze oplossingen kan worden gebruikt om het resultaat van een serverimplementatie te beheren. Er is echter een aanzienlijk verschil in de impact van het gebruik van elke benadering.

Gedeeltelijke configuraties

Wanneer u gedeeltelijke configuraties gebruikt, wordt lokale Configuration Manager geconfigureerd om meerdere configuraties onafhankelijk te beheren. Configuraties worden onafhankelijk gecompileerd en vervolgens toegewezen aan het knooppunt. Hiervoor moet LCM vooraf worden geconfigureerd met de naam van elke configuratie.

Gedeeltelijke configuraties bieden twee of meer teams volledige controle over de configuratie van een server, vaak zonder het voordeel van communicatie of samenwerking.

Klanten hebben in feedback gemeld dat dit kan leiden tot resourceconflicten, onbedoelde onderdrukkingen en uiteindelijk verlies van echt configuratiebeheer van de asset.

Daarnaast hebben klanten feedback gegeven dat bij het gebruik van dit model, het onwaarschijnlijk is dat elke controlerende teams-configuratiewijzigingen volledig worden getest via een release-pijplijn, wat leidt tot onverwachte resultaten in de productie.

Het is essentieel dat één pijplijn wordt gebruikt om alle wijzigingen te evalueren die zijn vrijgegeven aan servers.

In de onderstaande afbeelding geeft Team B hun gedeeltelijke configuratie uit aan Team A. Team A voert vervolgens de tests uit op een server waarop beide configuraties zijn toegepast. In dit model is slechts één instantie gemachtigd om wijzigingen aan te brengen in de productie.

Wanneer er wijzigingen van Team B vereist zijn, moeten ze een pull-aanvraag indienen op basis van de broncodebeheeromgeving van Team A. Team A controleert vervolgens de wijzigingen met behulp van testautomatisering en geeft ze vrij aan productie wanneer er zeker van is dat de wijzigingen geen fouten veroorzaken in de toepassingen of services die door de server worden gehost.

Samengestelde resources

Een samengestelde resource is gewoon een DSC-configuratie die is verpakt als een resource. Er zijn geen speciale vereisten voor het configureren van LCM om samengestelde resources te accepteren. De resources worden gebruikt in een nieuwe configuratie en één compilatie resulteert in één MOF-bestand.

Er zijn twee veelvoorkomende scenario's voor samengestelde resources. De eerste is het verminderen van complexiteit en het abstract maken van unieke concepten. De tweede is dat basislijnen kunnen worden verpakt voor een toepassingsteam om veilig te implementeren via hun release-pijplijn naar productie nadat alle tests zijn geslaagd.

Configuration Name
{
  File 1
  {
    Ensure = "Present"
    Path = "c:\inetpub\file1.zip"
    Source = "http://uri/file1.zip"
  }
  Service A
  {
    Ensure = "Present"
    Name = "ServiceA"
    Status = "Running"
  }
  SecurityBaseline Settings
  {
    Ensure = "Present"
    Datacenter = "NorthAmerica"
  }
}

Samengestelde resources bevorderen zowel de samenstelling als de samenwerking met behulp van een pijplijn tijdens het opbouwen van operationele volwassenheid.

Mogelijk gebruikt u samengestelde resources al zonder dat u dit doorhebt. Een voorbeeld is ServiceSet. Deze resource beheert de status van meerdere Windows-services zonder deze afzonderlijk weer te geven. De eigenschap Name accepteert een matrix met tekenreeksen om de naam van elke service op te geven. Wanneer de configuratie is gecompileerd, bevat het MOF een unieke servicesectie voor elk van de namen die worden doorgegeven aan ServiceSet.

Organisaties hebben mogelijk 'agents' of 'middleware' die op elke server moeten worden geïnstalleerd. Een samengestelde resource is het beste antwoord op het beheren van de afhankelijkheden, installatie en configuratie van dergelijke hulpprogramma's en hulpprogramma's.

De persoon of het team dat verantwoordelijk is voor oplossingen die meerdere servers omvatten, ontwerpt een configuratie met hun vereisten. Vervolgens wordt de configuratie verpakt als een samengestelde resource met behulp van de instructies in de documentatie van de samengestelde resource. Ten slotte moet de nieuwe samengestelde resource worden gepubliceerd naar een locatie zoals een bestandsshare of NuGet-feed, waar toepassingsteams deze in hun configuraties kunnen gebruiken.

Telkens wanneer het team een nieuwe versie uitbrengt, verhogen ze het versienummer in het modulemanifest voor hun samengestelde resource. De toepassingsteams nemen de samengestelde resource op in de configuratie die ze maken voor het beheren van toepassingsafhankelijkheden. Wanneer de operations-/beveiligingsteams een nieuwe versie van hun resource uitbrengen, brengen ze de toepassingsteams op de hoogte van een nieuwe wijziging.

De toepassingsteams kunnen een release naar productie activeren, waarbij de enige wijziging is in basislijnen. Dit biedt echter de mogelijkheid om de impact op toepassingen te evalueren vóór het risico van een servicestoring.

Notitie

Feedback over het gebruik van samengestelde resources bevat kritiek dat het aanbrengen van wijzigingen het compileren en vrijgeven van een nieuwe MOF vereist. Dit is standaard. Elke nieuwe configuratierelease moet een statische verwijzing bevatten naar een specifieke versie van elke resource en moet worden gevalideerd door tests voordat de productieserverknooppunten worden bereikt. Het proces van het testen en vrijgeven van wijzigingen van broncodebeheer creëert een veilige omgeving voor het vrijgeven van wijzigingen in kleine, maar frequente batches.