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.
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.
Čá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.
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.
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.