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



07.08.2019

Kurzinformation it-sa, 8-10...

It-sa is one of the leading international trade fairs for IT security. With around 700...
08.07.2019

Narzędzie EDR

ESET Enterprise Inspector
08.07.2019

Usuwanie skutków awarii

Veeam Availability Orchestrator v2
08.07.2019

Indywidualna konfiguracja

baramundi Management Suite 2019
05.07.2019

Technologia Ceph

SUSE Enterprise Storage 6
05.07.2019

Szybkie i bezpieczne...

Konica Minolta bizhub i-Series
05.07.2019

Edge computing

Atos BullSequana Edge
04.07.2019

Terabitowa ochrona

Check Point 16000 i 26000
04.07.2019

Obsługa wideokonferencji

Poly G7500

PowerShell Desired State Configuration

Data publikacji: 18-04-2019 Autor: Bartosz Bielawski

DSC jako platforma opiera się głównie na kodzie napisanym w PowerShellu. Kod ten można tworzyć na dwa sposoby – używając zasobów skryptowych lub klas. Od początku swego istnienia DSC wspiera zasoby skryptowe, które są w gruncie rzeczy modułami PowerShella wzbogaconymi o plik opisujący schemat zasobu (wykorzystuje on język Management Object Format – MOF). Od wersji piątej PowerShella zasoby możemy definiować jako klasy z odpowiednim atrybutem, dzięki czemu można uzyskać taki sam poziom ustrukturyzowania zasobu, jaki gwarantuje schemat w pliku MOF.

 

W pierwszej części cyklu przypomnieliśmy, czym jest DSC i jak budowane są zasoby wykorzystywane w ramach tej platformy (patrz „IT Professional” 4/2019, s. 27). Przyjrzeliśmy się też procesowi, który powinien towarzyszyć decyzji o utworzeniu własnego zasobu, oraz opisaliśmy, jak wybrać typ tego zasobu. W niniejszym artykule pokażemy na praktycznym przykładzie, jak stworzyć zasób skryptowy – przyjrzymy się nie tylko jego strukturze, ale też modułowi, który można wykorzystać w trakcie tworzenia zasobu skryptowego. Opisane zostanie również, jak w takim zasobie dokonywać zmian i weryfikować, czy wprowadzone modyfikacje nie powodują problemów z jego działaniem. Na koniec przyjrzymy się też temu, jak za pomocą modułu Pester można przetestować utworzone zasoby. Przykładowy zasób, który zostanie utworzony, będzie implementacją zasobu opisanego w pierwszej części cyklu. Umieszczony zostanie w module DmzDSC i będzie mógł posłużyć do modyfikowania pliku hosts (HostsLine).

> STRUKTURA ZASOBU

Jak wspomniano w pierwszej części cyklu, tworząc zasoby skryptowe, musimy zadbać o ich odpowiednią strukturę. Należy najpierw utworzyć moduł będący zbiorem zasobów (na ogół poświęconych tej samej technologii lub powiązanych ze sobą w inny sposób), w którym umieścimy informacje przydatne w trakcie późniejszego korzystania z zasobów oraz ich dystrybuowania. W module tym znajdą się jedynie manifest oraz folder zawierający zasoby:

 

 

W folderze DSCResources umieszczamy wszystkie zasoby, tym razem w formie modułów zawierających dwa pliki: schemat klasy w pliku PelnaNazwaZasobu.mof oraz moduł skryptowy, zawierający definicje funkcji niezbędnych do utworzenia zasobu (plik PelnaNazwaZasobu.psm1). Oba pliki umieszczamy w folderze odpowiadającym pełnej nazwie zasobu, którą na ogół tworzymy, łącząc nazwę firmy (np. ITPro) z uproszczoną nazwą zasobu (HostsLine). Pełną listę plików niezbędnych do powstania modułu z pojedynczym zasobem skryptowym pokazano poniżej:

 

 

Oczywiście nasz moduł może zawierać również inne pliki, takie jak moduły pomocnicze, szczególnie przydatne podczas pracy z wybraną technologią, gdzie wielokrotnie natykamy się na podobne wymagania w ramach różnych zasobów. Jednak aby zasób zadziałał poprawnie, wystarczą nam te trzy pliki. Jak je utworzyć? Najprościej skorzystać w tym celu z narzędzia xDSCResourceDesigner – specjalnego modułu, dostępnego w ramach publicznej galerii PowerShella, przeznaczonego do tworzenia i testowania zasobów skryptowych.

> ZASADY TWORZENIA ZASOBU

Zanim utworzymy zasób, warto przypomnieć o kilku zasadach:

 

  • każdy zasób musi posiadać właściwość kluczową (Key) lub kilka takich właściwości, dzięki którym można będzie jednoznacznie zidentyfikować element w systemie,
  • właściwości kluczowe nie mogą stanowić kolekcji,
  • pozostałe właściwości muszą mieć jeden z wymienionych atrybutów: Required, Write lub Read,
  • właściwości wymagane (Required) użytkownik podać musi zawsze, należy więc ocenić, czy tworzony przez nas zasób jest technicznie poprawny bez danej właściwości,
  • właściwości do zapisu (Write) są opcjonalne, ale można je zmienić,
  • właściwości do odczytu (Read) służą jedynie do oceny stanu obiektu, nie możemy podać ich wartości.


W naszym wypadku za klucz można uznać opisywany adres IP. Właściwością wymaganą będzie lista nazw, które zostaną temu adresowi przypisane.

 

[...]

 

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"