Opis roli DSC w potoku ciągłej integracji/ciągłego wdrażania

W tym artykule opisano typy dostępnych metod łączenia konfiguracji i zasobów. Celem każdego scenariusza jest to samo, aby zmniejszyć złożoność, gdy preferowane jest użycie wielu konfiguracji w celu osiągnięcia stanu końcowego wdrożenia serwera. Przykładem może być wiele zespołów przyczyniających się do wyniku wdrożenia serwera, takich jak właściciel aplikacji utrzymujący stan aplikacji i centralny zespół publikujący zmiany w punktach odniesienia zabezpieczeń. Szczegóły poszczególnych podejść, w tym korzyści i ryzyka, są tutaj szczegółowo opisane.

Typy technik wspólnego tworzenia

Istnieją dwa rozwiązania wbudowane w Configuration Manager lokalne w celu włączenia tej koncepcji:

Pojęcie	Szczegółowe informacje
Konfiguracje częściowe	Dokumentacja
Zasoby złożone	Dokumentacja

Zrozumienie wpływu poszczególnych podejść

Za pomocą jednego z tych rozwiązań można zarządzać wynikiem wdrożenia serwera. Istnieje jednak znacząca różnica w wpływie użycia poszczególnych metod.

Konfiguracje częściowe

W przypadku korzystania z konfiguracji częściowych Configuration Manager lokalne jest konfigurowane do niezależnego zarządzania wieloma konfiguracjami. Konfiguracje są kompilowane niezależnie, a następnie przypisywane do węzła. Wymaga to wcześniejszego skonfigurowania narzędzia LCM przy użyciu nazwy każdej konfiguracji.

Konfiguracje częściowe zapewniają co najmniej dwóm zespołom pełną kontrolę nad konfiguracją serwera, często bez korzyści z komunikacji lub współpracy.

Klienci przekazali opinię, że może to prowadzić do konfliktów zasobów, niezamierzonych przesłonięć i ostatecznie utraty rzeczywistej kontroli konfiguracji zasobu.

Ponadto klienci przekazali opinię, że w przypadku korzystania z tego modelu każda kontrola zmian konfiguracji zespołów prawdopodobnie nie zostanie w pełni przetestowana za pośrednictwem potoku wydania, co prowadzi do nieoczekiwanych wyników w środowisku produkcyjnym.

Ważne jest, aby pojedynczy potok był używany do oceny wszystkich zmian wydanych na serwerach.

Na poniższej ilustracji zespół B zwalnia ich częściową konfigurację do zespołu A. Zespół A następnie uruchamia testy na serwerze z zastosowanymi obie konfiguracje. W tym modelu tylko jeden urząd ma uprawnienia do wprowadzania zmian w środowisku produkcyjnym.

Jeśli zmiany są wymagane od zespołu B, należy przesłać żądanie ściągnięcia do środowiska kontroli źródła zespołu A. Zespół A następnie przejrze zmiany przy użyciu automatyzacji testów i wydania w środowisku produkcyjnym, gdy istnieje pewność, że zmiany nie spowodują błędów w aplikacjach lub usługach hostowanych przez serwer.

Zasoby złożone

Zasób złożony to po prostu konfiguracja DSC spakowana jako zasób. Nie ma specjalnych wymagań dotyczących konfigurowania programu LCM w celu akceptowania zasobów złożonych. Zasoby są używane w ramach nowej konfiguracji, a pojedyncza kompilacja powoduje utworzenie jednego pliku MOF.

Istnieją dwa typowe scenariusze dla zasobów złożonych. Pierwszym z nich jest zmniejszenie złożoności i abstrakcyjne unikatowe pojęcia. Drugi polega na umożliwieniu spakowania punktów odniesienia dla zespołu aplikacji w celu bezpiecznego wdrożenia za pośrednictwem potoku wydania do środowiska produkcyjnego po zakończeniu wszystkich testów.

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

Zasoby złożone promują zarówno kompozycję, jak i współpracę przy użyciu potoku podczas tworzenia dojrzałości operacyjnej.

Być może już używasz zasobów złożonych bez ich realizacji. Przykładem jest ServiceSet. Ten zasób zarządza stanem wielu usług systemu Windows bez wyświetlania ich pojedynczo. Właściwość Name akceptuje tablicę ciągów, aby podać nazwę każdej usługi. Po skompilowaniu konfiguracji moF będzie zawierać unikatową sekcję Usługi dla każdej z nazw przekazanych do zestawu usług.

Organizacje mogą mieć "agentów" lub "oprogramowanie pośredniczące", które należy zainstalować na każdym serwerze. Zasób złożony jest najlepszą odpowiedzią na zarządzanie zależnościami, konfiguracją i konfiguracją dowolnych takich narzędzi i narzędzi.

Osoba lub zespół odpowiedzialny za rozwiązania obejmujące wiele serwerów autorów konfiguracji zawierającej ich wymagania. Następnie konfiguracja zostanie spakowana jako zasób złożony, korzystając z instrukcji podanych w dokumentacji zasobów złożonych. Na koniec nowy zasób złożony powinien zostać opublikowany w lokalizacji, takiej jak udział plików lub źródło danych NuGet, w którym zespoły aplikacji mogą korzystać z niego w swoich konfiguracjach.

Za każdym razem, gdy zespół wyda nową wersję, zwiększa numer wersji w manifeście modułu dla swojego zasobu złożonego. Zespoły aplikacji zawierają zasób złożony w konfiguracji, którą tworzą na potrzeby zarządzania zależnościami aplikacji. Gdy zespoły ds. operacji/zabezpieczeń udostępniają nową wersję swojego zasobu, powiadamiają zespoły aplikacji o nowej zmianie.

Zespoły aplikacji mogą wyzwolić wydanie do środowiska produkcyjnego, w którym jedyną zmianą jest linia bazowa. Daje to jednak możliwość oceny wpływu na aplikacje przed ryzykiem awarii usługi.

Uwaga

Opinie dotyczące wykorzystania zasobów złożonych obejmowały krytykę, która wprowadzanie zmian wymaga kompilowania i wydawania nowego MOF. Jest to celowe. Każda nowa wersja konfiguracji powinna zawierać statyczne odwołanie do określonej wersji każdego zasobu i powinno zostać zweryfikowane przez testy przed dotarciem do węzłów serwera produkcyjnego. Proces testowania i wydawania zmian z kontroli źródła tworzy bezpieczne środowisko do wydawania zmian w małych, ale częstych partiach.