Förstå DSC:s roll i en CI/CD-pipeline

I den här artikeln beskrivs de typer av metoder som är tillgängliga för att kombinera konfigurationer och resurser. Målet för varje scenario är detsamma för att minska komplexiteten när flera konfigurationer föredras för att nå sluttillståndet för serverdistributionen. Ett exempel på detta är flera team som bidrar till resultatet av en serverdistribution, till exempel en programägare som upprätthåller programtillståndet och ett centralt team som släpper ändringar i säkerhetsbaslinjer. Nyanserna i varje metod, inklusive fördelar och risker beskrivs här.

Typer av samarbetsredigeringstekniker

Det finns två inbyggda lösningar i Lokala Configuration Manager för att aktivera det här konceptet:

Koncept	Detaljerad information
Partiella konfigurationer	Dokumentation
Sammansatta resurser	Dokumentation

Förstå effekten av varje metod

Någon av dessa lösningar kan användas för att hantera resultatet av en serverdistribution. Det finns dock betydande skillnader i effekten av att använda varje metod.

Partiella konfigurationer

När du använder partiella konfigurationer konfigureras lokala Configuration Manager för att hantera flera konfigurationer oberoende av varandra. Konfigurationer kompileras oberoende av varandra och tilldelas sedan till noden. Detta kräver att LCM konfigureras i förväg med namnet på varje konfiguration.

Partiella konfigurationer ger två eller flera team fullständig kontroll över konfigurationen av en server, ofta utan nyttan av kommunikation eller samarbete.

Kunder har lämnat feedback om att detta kan leda till resurskonflikter, oavsiktliga åsidosättningar och slutligen förlust av verklig konfigurationskontroll av tillgången.

Dessutom har kunder gett feedback om att varje kontrollerande teamkonfigurationsändringar sannolikt inte kommer att testas fullständigt via en versionspipeline, vilket leder till oväntade resultat i produktionen.

Det är viktigt att en enda pipeline används för att utvärdera alla ändringar som släpps till servrar.

I bilden nedan släpper Team B sin partiella konfiguration till Team A. Team A kör sedan sina tester mot en server med båda konfigurationerna tillämpade. I den här modellen har endast en utfärdare behörighet att göra ändringar i produktion.

När ändringar krävs från team B bör de skicka en pull-begäran mot team A:s källkontrollmiljö. Team A skulle sedan granska ändringarna med hjälp av testautomatisering och lansering till produktion när det finns förtroende för att ändringarna inte kommer att orsaka fel i de program eller tjänster som hanteras av servern.

Sammansatta resurser

En sammansatt resurs är helt enkelt en DSC-konfiguration som paketeras som en resurs. Det finns inga särskilda krav för att konfigurera LCM för att acceptera sammansatta resurser. Resurserna används i en ny konfiguration och en enda kompilering resulterar i en MOF-fil.

Det finns två vanliga scenarier för sammansatta resurser. Det första är att minska komplexiteten och abstrakta unika begrepp. Det andra är att tillåta att baslinjer paketeras så att ett programteam på ett säkert sätt kan distribuera via sin versionspipeline till produktion när alla tester har godkänts.

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"
  }
}

Sammansatta resurser främjar både sammansättning och samarbete med hjälp av en pipeline samtidigt som den operativa mognaden skapas.

Du kanske redan använder sammansatta resurser utan att inse det. Ett exempel är ServiceSet. Den här resursen hanterar tillståndet för flera Windows-tjänster utan att lista dem individuellt. Egenskapen Namn accepterar en matris med strängar för att ange namnet på varje tjänst. När konfigurationen kompileras innehåller MOF ett unikt tjänstavsnitt för vart och ett av de namn som skickas till ServiceSet.

Organisationer kan ha "agenter" eller "mellanprogram" som ska installeras på varje server. En sammansatt resurs är det bästa svaret på hantering av beroenden, installation och konfiguration av sådana verktyg och verktyg.

Den person eller det team som ansvarar för lösningar som omfattar flera servrar skapar en konfiguration som innehåller deras krav. Därefter paketeras konfigurationen som en sammansatt resurs med hjälp av instruktionerna i den sammansatta resursdokumentationen. Slutligen bör den nya sammansatta resursen publiceras till en plats, till exempel en filresurs eller NuGet-feed där programteam kan använda den i sina konfigurationer.

Varje gång teamet släpper en ny version ökar de versionsnumret i modulmanifestet för sin sammansatta resurs. Programteamen innehåller den sammansatta resursen i konfigurationen som de skapar för att hantera programberoenden. När drift-/säkerhetsteamen släpper en ny version av sin resurs meddelar de programteamen om en ny ändring.

Programteamen kan utlösa en version till produktion där den enda ändringen är till baslinjer. Detta ger dock möjlighet att utvärdera påverkan på program före risken för ett tjänststopp.

Anteckning

Feedback om användningen av sammansatta resurser har inkluderat kritik om att det krävs kompilering och lansering av en ny MOF för att göra ändringar. Det här är avsiktligt. Varje ny konfigurationsversion bör innehålla en statisk referens till en specifik version av varje resurs och bör verifieras av tester innan den når produktionsservernoderna. Processen med att testa och släppa ändringar från källkontroll skapar en säker miljö för att släppa ändringar i små men frekventa batchar.