Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



26.11.2019

Baza cyberzagrożeń otwarta

Kaspersky Threat Intelligence Portal
26.11.2019

Kopia zapasowa w chmurze

Veeam Backup dla Office’a i Azure
26.11.2019

Automatyzacja jako usługa

QNAP Qmiix
25.11.2019

Jeszcze szybciej

Trzeci generacja Ryzen Threadripper
25.11.2019

Wirtualizacja na...

QNAP QGD-1600P
25.11.2019

Laserowy projektor

Optoma UHZ65UST
25.10.2019

Skalowalna infrastruktura

Red Hat OpenStack Platform 15
25.10.2019

Cienki klient 2.0

Windows Virtual Desktop
25.10.2019

Nowy sprzęt Microsoftu

Rodzina Surface się powiększa

PowerShell Desired State Configuration

Data publikacji: 22-03-2019 Autor: Bartosz Bielawski
Tagi:    windows

Zarządzanie systemami Windows bardzo zmieniło się w ostatnich latach i wciąż ewoluuje. Dziś coraz rzadziej musimy się logować do serwerów i coraz częściej da się korzystać z rozwiązań takich jak Server Core. Stało się to możliwe głównie dzięki Windows PowerShell. Jednak zarządzanie przy użyciu skryptów czy interaktywnych poleceń zmienia perspektywę tylko nieznacznie. Z czasem pojawia się potrzeba pójścia krok dalej, w czym pomocny jest PowerShell Desired State Configuration.

 

 Zamiast uruchamiać skrypty czy pojedyncze polecenia, chcemy w prosty i przejrzysty sposób zdefiniować nasz serwer. Opisując go, zyskujemy nie tylko pewność, że będziemy mogli w każdej chwili zweryfikować jego konfigurację, ale również, że będziemy mogli powielić czy wręcz w prosty sposób zastąpić właś­nie zainstalowany serwer. Temu służy PowerShell Desired State Configuration (DSC).

W pierwszej części cyklu skupimy się na tym, jak skonstruowane są zasoby w ramach DSC. Pokrótce omówimy dwa typy tych zasobów. Przyjrzymy się też opcjom dystrybuowania zasobów i źródłom, gdzie możemy wyszukiwać gotowe zasoby. Na koniec omówimy sytuacje, w których może być zasadne tworzenie własnych zasobów, i na co zwrócić uwagę przy ich tworzeniu. Postaramy się więc przygotować grunt pod praktyczny przewodnik tworzenia tych zasobów: warto bowiem przed napisaniem pierwszej linijki kodu upewnić się, że nie poświęcimy czasu na ponowne odkrywanie koła, w dodatku tworząc przy tym koło sześcienne.

> CZYM JEST DSC?

DSC możemy postrzegać na dwa sposoby. Przede wszystkim stanowi ono platformę, dzięki której stan systemu Windows czy aplikacji na nim zainstalowanych możemy przedstawić za pomocą prostych deklaracji. Służyć do tego będą zasoby PowerShell DSC (DSC Resource), które będą tłumaczyć deklarację na kod wykonywany w ramach PowerShella. Właśnie na tym elemencie PowerShell DSC będzie skupiać się ten cykl artykułów.

Oprócz tego DSC (podobnie jak narzędzia firm trzecich, takich jak Ansible, Chef czy Puppet) umożliwia nam, wykorzystując wcześniej wspomniane zasoby, tworzenie konfiguracji całego serwera. W tym cyklu skupimy się raczej na tym, jak – stosując narzędzia firm trzecich – skorzystać z uprzednio utworzonych zasobów, dzięki czemu będziemy mogli użyć PowerShell DSC również tam, gdzie właśnie rozwiązania działające na różnych platformach są stosowane i nie ma wyraźnej potrzeby, by do zarządzania systemem Windows wykorzystywać narzędzie wbudowane w system.

PowerShell DSC ujrzał światło dzienne wraz z premierą systemu Windows 2012 R2 i PowerShellem w wersji 4. W wersji tej istniały jedynie dwa typy zasobów: binarne (czyli opierające się na kompilowanym kodzie) oraz skryptowe. Z punktu widzenia autora zasobów tylko zasoby skryptowe są interesujące. Ze względu na kompatybilność ze starszymi wersjami systemu i PowerShella większość dostępnych zasobów to właś­nie zasoby skryptowe.

W wersji 5 PowerShella pojawiły się zasoby oparte na klasach w PowerShellu. Powstały one głównie po to, by uprościć i ujednolicić proces tworzenia zasobów przez programistów, dla których pewne zachowania PowerShella były dalece nieintuicyjne. Oczywiście, korzystać z tego rozwiązania w równym stopniu mogą administratorzy chcący tworzyć zasoby na własne potrzeby. Oznacza to, że jeśli pracujemy z systemami pod kontrolą PowerShella w wersji 5 (bądź jeszcze korzystniej: w wersji 5.1), możemy wybierać między dwoma typami zasobów: zasobami skryptowymi i zasobami wykorzystującymi klasy w PowerShellu.

> ZASOBY SKRYPTOWE

Zasób skryptowy to – w największym skrócie – moduł, który definiuje trzy polecenia: Get-TargetResource, Test-TargetResource oraz Set-TargetResource. Każde z tych poleceń ma ściśle określone wymogi, które należy zweryfikować przed opublikowaniem zasobu.

Funkcja Get-TargetResource ma z założenia stanowić narzędzie do raportowania stanu danego zasobu. Powinna zwracać tablicę skrótów z właściwościami zasobu jako kluczami. Wykorzystywana jest najrzadziej i często można się spotkać (nawet w zasobach publikowanych przez Microsoft) z niedociągnięciami w tej części zasobu. Ważne, by funkcja informowała o stanie systemu niezależnie od okoliczności.

Polecenie Test-TargetResource wykorzystywane jest do sprawdzenia, czy stan systemu odpowiada założonemu stanowi. Ponieważ wywoływane jest najczęściej, warto zadbać o jego jakość i wydajność. Funkcja ta powinna zwracać wartość logiczną: prawda, jeśli system znajduje się w stanie oczekiwanym, bądź fałsz, gdy nie znajdują się w takim stanie. Wynik tego polecenia pozwala określić, czy konieczne jest wywołanie funkcji zmieniającej stan systemu (jeśli takie jest życzenie operatora), więc ważne jest, by system znajdujący się w oczekiwanym stanie zwracał prawidłowo wynik (w przeciwnym wypadku może się zdarzyć, że system będzie nieustannie „naprawiany” mimo pozostawania w oczekiwanym stanie).

Funkcja Set-TargetResource wykorzystywana jest do zmiany stanu. Ponieważ jednak na wejściu nie uzyskuje informacji, co w systemie nie działa prawidłowo, wymaga czasem określenia stanu aktualnego. Można jednak swobodnie założyć, że jeśli funkcja ta została wywołana, to system z pewnością znajdował się w stanie odmiennym od wymaganego. Z założenia funkcja ta nie powinna nic zwracać. Ważne, by wszelkie niepowodzenia (na przykład błąd uniemożliwiający zmianę stanu systemu) zwracać w formie niekrytycznego błędu: w przeciwnym razie system uzna, że problem został rozwiązany, i zasób będzie traktowany jako znajdujący się w oczekiwanym stanie (nie ma więc powtórzenia testu przy wykorzystaniu polecenia Test-TargetResource).

W zasobach skryptowych, oprócz definicji w PowerShellu, niezbędny jest też formalny „kontrakt” z użytkownikiem, przedstawiony w formie klasy opisanej z wykorzystaniem pliku schematu w języku MOF (Management Object Format). Definiowanie klas za pomocą tego języka wymaga nieco wprawy, więc by uprościć pracę z plikami tego typu, Microsoft oferuje narzędzie, przy użyciu którego możemy wygenerować ten plik, korzystając ze składni PowerShella. Służy do tego moduł xDscResourceDesigner. Jednak nawet wygenerowany kod dobrze jest zrozumieć, przyjrzymy się więc strukturze pliku schematu (schema.mof) w kolejnym artykule poświęconym tworzeniu zasobów tego typu. Tu wspomnimy jedynie, że definiowana klasa będzie zawierać właściwości, które następnie będziemy określać, tworząc konfigurację systemu, a które będą parametrami wejściowymi wspomnianych wcześ­niej funkcji w PowerShellu oraz będą świadczyć o możliwości rozróżniania nazwy pełnej od przyjaznej. Większość publikowanych przez Microsoft zasobów ma nazwy zaczynające się od przedrostka „MSFT_” i nazwy przyjazne pozbawione tego przedrostka, np. „MSFT_xSmbShare” będzie mieć nazwę przyjazną „xSmbShare”.

 

[...]
 

Autor zawodowo zajmuje się informatyką. Jest Microsoft MVP w dziedzinie PowerShella, blogerem oraz jednym z moderatorów forum dotyczącego skryptów w serwisie TechNet. Autor książki „Windows PowerShell 5.1 Biblia”. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"