Udostępnij za pośrednictwem

Anatomia zasobu DSC opartego na poleceniach

  • Artykuł

Zasoby DSC zapewniają standardowy interfejs do zarządzania ustawieniami systemu. Zasób definiuje właściwości, którymi można zarządzać i implementować kod potrzebny do uzyskania wystąpienia zasobu.

Zasoby DSC oparte na poleceniach są definiowane z co najmniej dwoma plikami:

  1. Manifest zasobu DSC, który informuje DSC, jak korzystać z zasobu.
  2. Co najmniej jeden plik wykonywalny i ich zależności do zarządzania wystąpieniami zasobu.

Manifesty zasobów DSC

Manifesty zasobów DSC są definiowane jako pliki JSON. Aby rozszerzenie DSC rozpoznawało plik JSON jako manifest, plik musi spełniać następujące kryteria:

  1. Plik musi być wykrywalny w zmiennej środowiskowej PATH .
  2. Nazwa pliku musi kończyć się ciągiem .dsc.resource.json.

Gdy DSC przeszukuje system lokalny pod kątem dostępnych zasobów DSC opartych na poleceniach, wyszukuje każdy folder w PATH folderze dla plików korzystających z konwencji nazewnictwa manifestu zasobu DSC. Następnie dsC analizuje każdy z odnalezionych plików i weryfikuje je względem schematu JSON manifestu zasobu DSC.

Jeśli plik JSON sprawdza poprawność względem schematu, dsC może użyć zasobu DSC.

Co najmniej manifest musi definiować:

  • Wersja schematu JSON manifestu zasobu DSC, z nim jest zgodna.
  • W pełni kwalifikowana nazwa zasobu, na przykład Microsoft.Windows/Registry. W pełni kwalifikowana składnia nazwy to <owner>[.<group>][.<area>]/<name>. Składniki grupy i obszaru w pełni kwalifikowanej nazwy umożliwiają organizowanie zasobów w przestrzeniach nazw.
  • Jak dsC może wywołać polecenie , aby uzyskać bieżący stan wystąpienia zasobu.
  • Sposób weryfikacji wystąpienia. Może to być jeden z następujących elementów:
    • Schemat JSON opisujący wystąpienie
    • Polecenie DSC musi wywołać polecenie w celu pobrania schematu w czasie wykonywania
    • Polecenie sprawdzania poprawności zagnieżdżonych zasobów DSC. Ta ostatnia opcja dotyczy tylko zasobów grupy DSC i zasobów dostawcy DSC.

Manifest może opcjonalnie definiować:

  • Jak dsC może wywołać polecenie, aby sprawdzić, czy wystąpienie jest w żądanym stanie.
  • Jak dsC może wywołać polecenie, aby ustawić wystąpienie na żądany stan.
  • Znaczenie kodów zakończenia niezerowych zwracanych przez polecenie .
  • Jak dsC może wywołać polecenie do zarządzania innymi zasobami DSC, gdy zasób jest zasobem grupy DSC lub zasobem dostawcy DSC.
  • Metadane dotyczące zasobu, takie jak jego autor i krótki opis.

Jeśli manifest nie definiuje sposobu testowania wystąpienia zasobu, dsC wykonuje syntetyczny test dla wystąpień zasobów. Test syntetyczny DSC zawsze pobiera rzeczywisty stan wystąpienia i wykonuje ścisłe porównanie właściwości wystąpienia z żądanym stanem. Test syntetyczny ignoruje wszelkie właściwości poprzedzone znakiem podkreślenia (_) lub dolara ($). Jeśli którakolwiek z właściwości nie jest dokładnie taka sama jak zdefiniowany żądany stan, dsC zgłasza wystąpienie jako niezgodne.

Jeśli manifest nie definiuje sposobu ustawiania wystąpienia zasobu DSC, dsC nie może użyć zasobu w celu wymuszenia żądanego stanu.

Manifest nie musi określać tego samego pliku wykonywalnego dla każdej operacji. Definicja każdej operacji jest niezależna.

Pliki wykonywalne zasobów DSC

Zasoby DSC oparte na poleceniach zawsze wymagają pliku wykonywalnego, aby dsC było uruchamiane. Manifest zasobu DSC nie musi być dołączony do pliku wykonywalnego. Plik wykonywalny może być dowolnym plikiem wykonywalnym, takim jak aplikacja binarna lub skrypt powłoki. Zasób może używać różnych plików wykonywalnych dla różnych operacji.

Aby platforma DSC korzystała z pliku wykonywalnego, musi być odnajdywalna w zmiennej środowiskowej PATH . DSC wywołuje plik wykonywalny raz na operację, używając kodu zakończenia zwróconego przez plik wykonywalny, aby określić, czy polecenie zakończyło się pomyślnie. DSC traktuje kod 0 zakończenia jako powodzenie i wszystkie inne kody zakończenia jako błąd.

Dane wejściowe

DsC wysyła dane wejściowe do opartych na poleceniach zasobów DSC jako obiektu blob danych JSON za pomocą stdin lub jako zestawu flag argumentów i wartości. Obsługa danych wejściowych jest definiowana na operację w manifeście zasobu DSC.

Gdy dsC wysyła dane wejściowe jako dane JSON za pośrednictwem stdin, obiekt blob danych jest reprezentacją żądanego stanu wystąpienia w formacie JSON. Jest to najbardziej niezawodna opcja zasobu, ponieważ umożliwia zasobowi obsługę złożonych właściwości z obiektami zagnieżdżonym.

Gdy dsC wysyła dane wejściowe jako argumenty, generuje parę argumentów dla każdej z określonych właściwości. Pierwszy argument to nazwa właściwości poprzedzona prefiksem --, na przykład --duration. Drugim argumentem jest wartość właściwości. Kolejność par argumentów nie jest gwarantowana. Ta metoda wejściowa nie obsługuje złożonych właściwości.

Dane wyjściowe

Plik wykonywalny dla opartego na poleceniach zasobu DSC musi zwracać dane JSON do stdout po wywołaniu przez DSC. Kodowanie wyjściowe musi mieć wartość UTF-8. Gdy zasób zwraca stan wystąpienia, dsC weryfikuje dane JSON względem schematu wystąpienia zasobu.

W przypadku zasobów dostawcy DSC rozszerzenie DSC oczekuje, że plik wykonywalny przejdzie przez stany wystąpienia dla zasobów zarządzanych jako pojedyncza tablica JSON lub jako seria wierszy JSON.

Zasoby DSC oparte na poleceniach mogą zgłaszać informacje rejestrowania do DSC przez emitowanie wierszy JSON do stderr. Każdy wpis dziennika musi być obiektem JSON zawierającym dwa klucze:

  1. Klucz message definiuje ciąg czytelny dla człowieka dla wpisu dziennika.
  2. Klucz level określa, czy komunikat reprezentuje Errorelement , a Warninglub Information.

DsC zbiera komunikaty z zasobów i wyświetla je w wynikach operacji konfiguracji. Gdy usługa DSC wywołuje zasób bezpośrednio poza konfiguracją, nie zbiera komunikatów. Zamiast tego są one po prostu emitowane do stderr.

Powiązana zawartość