PRZEJDŹ DO:
Czym właściwie jest DSC (Desired State Configuration)?
DSC (Desired State Configuration) jest to sformalizowany sposób, który pozwala skonfigurować środowisko tak, aby przybrało ono oczekiwany przez nas stan. Jeśli przykładowo chcemy, aby na danej maszynie znajdowała się aplikacja (np. jakiś program antywirusowy) w określonej wersji, to możemy to osiągnąć właśnie za pomocą DSC. Może to być jedna aplikacja, może być ich wiele, jesteśmy tutaj właściwie nieograniczeni. Może potrzebujemy odpowiednio skonfigurowanego serwera IIS? Nie ma problemu. A może chcemy mieć pewną strukturę katalogów na dysku z konkretnymi plikami? Z DSC wszystko jest możliwe, ale ktoś słusznie pewnie zauważy, że możemy to wszystko również osiągnąć za pomocą przygotowanego wcześniej obrazu do stworzenia maszyny wirtualnej. Co różni tę opcję od DSC? Sprawdźmy!
Desired State Configuration – zalety
- Łatwiejsza konfiguracja
Wyobraźmy sobie, że posiadamy maszynę wirtualną – serwer. Chcemy ten serwer skonfigurować: zainstalować różne aplikacje, zabezpieczenia, wprowadzić zmiany w rejestrze. W zależności od tego, jak duża jest to konfiguracja, musimy wykonać odpowiednio dużą liczbę kroków. Moglibyśmy to rozpisać w następujący sposób:
- Zainstaluj Firefox w wersji X
- Zainstaluj Dotnet Core w wersji X
- Dodaj regułę X w MS Defenderze
- Usuń wpis X w rejestrze
Aby wykonać każdy z tych kroków manualnie, będziemy się posiłkować różnymi narzędziami. Jeśli ta konfiguracja jest złożona, mogą pojawić się problemy z kompatybilnością. Jedno narzędzie może nie działać z innym w danej wersji albo mogą sobie wzajemnie nadpisywać pracę. Tu z pomocą przychodzi właśnie DSC. Zostało stworzone w tym celu, aby wziąwszy rozwiązania kilku dostawców, można było używać ich ze sobą bezkonfliktowo. Służy do tego sformalizowanie reguł, których powinni się trzymać dostawcy komponentów, jakich chcemy używać.
- Idempotentność
Inną zaletą takiego podejścia jest idempotentność, czyli możliwość wykonywania wielokrotnie tej samej operacji bez zmiany wyniku. Dzięki temu mamy pewność, że za każdym razem, gdy zastosujemy pewną konfigurację, stan systemu się nie zmieni i będzie taki, jakiego oczekujemy. Warto zauważyć, że stosowane jest tutaj podejście deklaratywne, co jest kolejną zaletą takiego rozwiązania. Definiujemy zatem stan, jaki chcemy zastać, zamiast zastanawiać się nad poszczególnymi etapami, które pozwolą nam do tego stanu dojść.
- Kompatybilność
Na początku wspomniałem o tym, że DSC pomaga w zarządzaniu komponentami tak, aby były one kompatybilne ze sobą. Oznacza to, że DSC jest pewnego rodzaju ustandaryzowaną metodą tworzenia tych komponentów. Jest to szereg reguł, które, stosowane podczas tworzenia komponentu, dają nam zapewnienie, że komponenty te będą mogły być wykorzystywane przez wielu odbiorców. Nie jest to jedynie zależność komponent – odbiorca. To również gwarancja, że komponenty te mogą być ze sobą łączone i nie oddziałują na siebie wzajemnie.
Desired State Configuration – zastosowanie w praktyce
Kompatybilność komponentów i ich idempotentność to niejedyne zalety DSC. Daje nam on również pewność, że cokolwiek by się działo, nasza maszyna wróci do stanu określonego w początkowej konfiguracji. W wyjątkowej sytuacji (np. gdy nastąpiły jakieś nieodwracalne zmiany) takiego stanu nie uda się odtworzyć, ale zostaniemy o tym fakcie poinformowani i będziemy mogli odpowiednio zareagować. O możliwościach reagowania szerzej napiszę w moim kolejnym artykule, w którym skupię się na Azure AA DSC.
Tymczasem wyobraźmy sobie, że serwer został przez nas skonfigurowany i pozostawiony w pewnym stanie. Pod naszą nieobecność ktoś, kto być może nie znał trybu pracy zespołu, albo ten tryb nie był odpowiednio określony, dokonał pewnej zmiany, która wpłynęła na serwer w taki sposób, że stan przestał być poprawny. Bez DSC po powrocie do pracy moglibyśmy być zaskoczeni, że wystąpiły jakieś nieoczekiwane zmiany. DSC dba o to, aby w takiej sytuacji środowisko cały czas było przywracane do stanu, w jakim je pozostawiliśmy i opisaliśmy. Jeśli skonfigurowałem serwer do konkretnego stanu, to ten stan ma być utrzymany.
Żeby lepiej to zobrazować – załóżmy, że na serwerze trzymamy jakieś pliki konfiguracyjne w katalogu X, co zostało zdefiniowane w konfiguracji DSC. Tworzy ona odpowiedni katalog i przenosi do niego poszczególne pliki z wybranego źródła zewnętrznego. Ktoś zalogował się na nasz serwer i nieumyślnie ten katalog usunął. DSC szybko wychwyci, że tego katalogu nie ma, i na nowo go odtworzy bez zakłócania pracy serwera.
W jakich sytuacjach DSC nie zadziała?
Wyżej wspomniałem, że DSC nie zawsze pozwoli przywrócić odpowiedni stan. Podam prosty przykład. Powiedzmy, że w ramach działania DSC chcemy zainstalować aplikację. Aplikacja ta musi być najpierw pobrana, ale ktoś na serwerze w firewallu zablokował ruch wychodzący. W takiej sytuacji DSC nie poradzi sobie z tym zadaniem, bo „nie wie”, że taka blokada powstała. My otrzymamy informację, że ten krok nie został wykonany, co prawdopodobnie sprowokuje nas do przejrzenia logów i trafienia na informację, że nie udało się połączyć z danym adresem do pobrania pliku. Ostatecznie po głębszej analizie zorientujemy się, że ruch ten jest zablokowany, ale będzie to wymagało naszego zaangażowania. Jedyne, co DSC będzie próbować robić, to pobrać plik z podanego adresu.
Desired State Configuration – architektura
Powyższe przykłady w pewien sposób obrazują już, jak wygląda architektura DSC. Możemy tu wyróżnić następujące elementy:
- Usługa Desired State Configuration
- Zasoby (Powershell Gallery)
- Konfiguracja
- Nody (instancje wirtualnych maszyn – serwerów)
Wszystkie one współpracują ze sobą, tworząc spójną całość – architekturę DSC. Jeżeli chcielibyśmy szczegółowo omówić ten wątek, to należy skupić się na dwóch najważniejszych modelach, które spajają powyższe, czyli Push oraz Pull.
Model Push
Jak sama nazwa wskazuje, model Push polega na „wypychaniu” – w tym przypadku wypychamy konfiguracje na nody. Model push jest to aktywna działalność użytkownika w celu dodania konfiguracji na jednym lub wielu node’ach / serwerach. W modelu tym nasze działanie skupia się na skompilowaniu oraz wypchnięciu konfiguracji za pomocą komend PowerShell. Ten model stosowany jest, gdy zależy nam na tym, żeby wszystkie maszyny otrzymały taką samą konfigurację w możliwie jak najbardziej zbliżonym czasie. Wymaga on zatem odpowiedniego zaplanowania i wdrożenia.
Model Pull
Model Pull polega natomiast na połączeniu maszyn z zewnętrzną usługą, gdzie zostaje im przypisana konfiguracja. Serwer Pull zawiera w tym przypadku wszystkie niezbędne konfiguracje oraz zasoby, wymagane do poprawnego rozmieszczenia konfiguracji na poszczególnych node’ach. Taka konfiguracja na serwerze Pull zostaje zaciągnięta wraz ze wszystkimi niezbędnymi zależnościami, a stan node’a jest monitorowany z poziomu usługi serwera Pull. Każdy z node’ów, który jest wpięty do takiej usługi, co pewien czas odpytuje serwer zgodnie z lokalną konfiguracją.
Służy do tego LCM (local configuration manager), który dba o to, aby odpytać serwer Pull, pobrać konfigurację i ją wykonać. Dodatkowo, oprócz samego odpytywania serwera Pull w interwałach czasowych, LCM dba również o to, aby monitorować stan konfiguracji na bieżącej maszynie (compliance check). Informuje nas o tym, czy wszystkie nasze maszyny poprawnie pobrały najnowszą konfigurację i prawidłowo ją wykonały. Stosowanie tego modelu jest szczególnie przydatne, gdy część maszyn jest czasowo offline. Gdy tylko przejdą w tryb online, automatycznie pobiorą i wykonają najnowszą konfigurację.
Jakie są znane rodzaje usług obsługujących metodę Pull? Na chwilę obecną są to:
- Azure Automation Desired State Configuration
- Usługa Pull w systemie Windows Server
- DSC SMB Pull server
Microsoft Azure Automation Desired State Configuration
W czasach, gdy chmura jeszcze raczkowała, implementacja polegała na pisaniu odpowiednich skryptów i konfigurowaniu własnego serwera do zarządzania nimi. Dziś Microsoft w pełni już wspiera to rozwiązanie i zintegrował je ze swoją chmurą, co jest wygodne i przekłada się na opisane przeze mnie korzyści. Niedawno podjęta została decyzja, że usługa DSC Pull servera w systemach Windows Server przestanie być rozwijana, a wszelkie prace zostaną przekierowane na usługę na platformie Azure.
Azure Automation Desired State Configuration jest dedykowaną usługą oferowaną i zalecaną przez Microsoft w większości scenariuszy. Dzięki niej jesteśmy w stanie wdrożyć automatyzację konfiguracji i zarządzania serwerami Windows i Linux. DSC umożliwia użytkownikom definiowanie ustawień, tzw. konfiguracji, w skrypcie PowerShell lub innych językach, takich jak JSON lub MOF, które reprezentują wymagany stan zasobów w sposób deklaratywny. Po zdefiniowaniu tych konfiguracji mogą być one przypisane do node’ów.
Azure Automation DSC oferuje wiele funkcji ułatwiających zarządzanie konfiguracją, w tym:
- Zarządzanie konfiguracją
- Raportowanie stanu oraz poprawności na poszczególnych instancjach (node’ach)
- Raporty, które umożliwiają użytkownikom śledzenie konfiguracji swoich zasobów
Podsumowanie
Desired State Configuration jest potężnym narzędziem, które daje nam możliwość zarządzania konfiguracjami (Configuration Management) na serwerach. Pozwala zminimalizować złożoność zadań związanych z zarządzaniem konfiguracją, zwiększyć niezawodność i zapewnić zgodność z zasadami bezpieczeństwa wedle potrzeb.
Zawodowo zaczynał od tworzenia platform internetowych z wykorzystaniem PHP oraz frameworka Symfony. Następnie programował aplikacje mobilne iOS / Android przy użyciu technologii Xamarin rozwijanej przez Microsoft. Kamil pełnił również funkcję Product Managera, co pozwoliło mu poznać procesy budowania relacji z klientem. Aktualnie, od ponad 3 lat, jest konsultantem w Inetum, gdzie rozwija się jako Azure DevOps. Chciałby dalej poszerzać swoją wiedzę i doświadczenie z tego zakresu, a w szczególności propagować odpowiednią kulturę pracy korzystną dla inżynierów i zrozumiałą dla biznesu.