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



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

Optymalizacja zużycia chmury

HPE GreenLake Hybrid Cloud
23.04.2019

Zarządzanie wydajnością

VMware vRealize Operations 7.5
19.04.2019

Technologie open source

SUSECON 2019
19.04.2019

Wyjątkowo małe

OKI seria C800
19.04.2019

Łatwy montaż

Rittal AX i KX

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"