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


24.05.2019

Konferencja IT Manager of...

W dniach 12–14 czerwca w Sopocie odbędzie się konferencja IT Manager of Tomorrow 2019. To...
24.05.2019

Ochrona sieci

Fortinet FortiOS 6.2
24.05.2019

Mniejsza złożoność

Rittal VX25 Ri4Power
24.05.2019

All-in-one NAS

QNAP TDS-16489U R2
24.05.2019

Układy SoC

AMD Ryzen Embedded R1000
23.05.2019

Wzmocniony model

Panasonic Toughbook FZ-N1
23.05.2019

Szybsze sieci

D-Link Smart Mesh Wi-Fi AC1900/AC2600/AC3000
23.05.2019

Curved 4K

Samsung LU32R590
14.05.2019

Bezpłatna konferencja OSEC...

Jako patron medialny serdecznie zapraszamy na bezpłatną konferencję OSEC Forum 2019, któa...

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”. 

Artykuł pochodzi z miesięcznika: IT Professional

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"