Sdílet prostřednictvím


Principy role DSC v kanálu CI/CD

Tento článek popisuje typy přístupů, které jsou k dispozici pro kombinování konfigurací a prostředků. Cíl pro každý scénář je stejný, aby se snížila složitost, pokud se dává přednost více konfiguracím, aby bylo možné dosáhnout koncového stavu nasazení serveru. Příkladem může být několik týmů, které přispívají k výsledku nasazení serveru, například vlastník aplikace, který udržuje stav aplikace, a centrální tým, který vydává změny standardních hodnot zabezpečení. Podrobnosti o jednotlivých přístupech, včetně výhod a rizik, najdete tady.

Tok procesu kanálu CI/CD

Typy technik pro spolupráci při vytváření

Pro místní Configuration Manager jsou integrovaná dvě řešení, která tento koncept umožňují:

Koncepce Podrobné informace
Částečné konfigurace Dokumentace
Složené prostředky Dokumentace

Pochopení dopadu jednotlivých přístupů

Ke správě výsledku nasazení serveru je možné použít některé z těchto řešení. V dopadu použití jednotlivých přístupů se však výrazně liší.

Částečné konfigurace

Při použití částečných konfigurací je místní Configuration Manager nakonfigurovaná tak, aby nezávisle na sobě spravovala více konfigurací. Konfigurace se kompilují nezávisle a pak se přiřadí uzlu. To vyžaduje, aby byl LCM předem nakonfigurovaný s názvem každé konfigurace.

Diagram částečných konfigurací

Částečné konfigurace poskytují dvěma nebo více týmům úplnou kontrolu nad konfigurací serveru, často bez výhod komunikace nebo spolupráce.

Zákazníci nám poskytli zpětnou vazbu, že to může vést ke konfliktům prostředků, neúmyslným přepsáním a nakonec ztrátě skutečné kontroly konfigurace prostředku.

Zákazníci navíc poskytli zpětnou vazbu, že při použití tohoto modelu je nepravděpodobné, že by se všechny změny konfigurace řídících týmů plně otestovaly prostřednictvím kanálu verze, což vede k neočekávaným výsledkům v produkčním prostředí.

Je důležité, aby se k vyhodnocení všech změn vydaných na serverech použil jeden kanál.

Na následujícím obrázku tým B uvolní částečnou konfiguraci týmu A. Tým A pak spustí testy na serveru s použitím obou konfigurací. V tomto modelu má oprávnění provádět změny v produkčním prostředí pouze jedna autorita.

Diagram částečného jednoho kanálu

Pokud tým B vyžaduje změny, měl by odeslat žádost o přijetí změn do prostředí správy zdrojového kódu týmu A. Tým A pak zkontroluje změny pomocí automatizace testů a vydání do produkčního prostředí, pokud je jistota, že změny nezpůsobí chyby v aplikacích nebo službách hostovaných serverem.

Složené prostředky

Složený prostředek je jednoduše konfigurace DSC zabalená jako prostředek. Neexistují žádné zvláštní požadavky na konfiguraci LCM pro příjem složených prostředků. Prostředky se používají v nové konfiguraci a výsledkem jedné kompilace je jeden soubor MOF.

Diagram složeného prostředku

Existují dva běžné scénáře pro složené prostředky. Prvním je snížení složitosti a abstrakce jedinečných konceptů. Druhým je umožnit zabalení směrných plánů pro aplikační tým, aby po dokončení všech testů bezpečně nasazoval svůj kanál verze do produkčního prostředí.

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

Složené prostředky podporují jak složení, tak spolupráci pomocí kanálu při vytváření provozní vyspělosti.

Možná už používáte složené prostředky, aniž byste si to uvědomovali. Příkladem je ServiceSet. Tento prostředek spravuje stav více služeb systému Windows, aniž by je vypisoval jednotlivě. Vlastnost Name přijímá pole řetězců, které poskytují název každé služby. Při kompilaci konfigurace bude MOF obsahovat jedinečný oddíl Service pro každý z názvů předaných do ServiceSet.

Organizace můžou mít agenty nebo middleware, které by se měly nainstalovat na každý server. Složený prostředek je nejlepší odpovědí na správu závislostí, nastavení a konfigurace takových nástrojů a nástrojů.

Osoba nebo tým zodpovědný za řešení, která zahrnují více serverů, autory konfigurace obsahující jejich požadavky. Dále se konfigurace zabalí jako složený prostředek podle pokynů uvedených v dokumentaci ke složeným prostředkům. Nakonec by se měl nový složený prostředek publikovat do umístění, jako je sdílená složka nebo informační kanál NuGet, kde ho můžou týmy aplikací využívat ve svých konfiguracích.

Pokaždé, když tým vydá novou verzi, zvýší číslo verze v manifestu modulu pro svůj složený prostředek. Týmy aplikací zahrnují složený prostředek do konfigurace, kterou vytvořily pro správu závislostí aplikací. Když provozní týmy a týmy zabezpečení vydávají novou verzi svého prostředku, upozorní týmy aplikací na novou změnu.

Týmy aplikací můžou aktivovat vydání do produkčního prostředí, kde jedinou změnou jsou směrné plány. To však poskytuje příležitost vyhodnotit dopad na aplikace před rizikem výpadku služby.

Poznámka

Zpětná vazba týkající se používání složených prostředků obsahovala kritiku, že provádění změn vyžaduje kompilaci a vydání nového MOF. Toto chování je úmyslné. Každá nová verze konfigurace by měla obsahovat statický odkaz na konkrétní verzi každého prostředku a před dosažením uzlů produkčního serveru by se měla ověřit testy. Proces testování a vydávání změn ze správy zdrojového kódu vytváří bezpečné prostředí pro uvolnění změn v malých, ale častých dávkách.