Desired State Configuration | Resources

Ressourcen

Wie in dem ersten Beitrag beschrieben, beinhaltet jede Konfiguration eine Ressourcendefinition. Diese Entitäten, welche durch Ressourcen bearbeitet werden, können einfache Dateien, Ordner, bis hin zu Windows Features oder komplexen Anwendungen wie SharePoint oder SQL Server sein. Im Grunde stellt eine Ressource Eigenschaften. Diese Eigenschaften müssen definiert werden. Wie diese Definitionen umgesetzt werden bleibt allein “Problem” der Ressource. Jede Ressource hat ein Ressourcenmodul. Das Modul umfasst mehrere Ressourcen und ist mit einem PowerShell Modul zu vergleichen. Das Ressourcenmodul hat nur spezielle Eigenschaften. Das DSC-Ressourcenmodul ist in einem imperativen Format geschrieben. Das bedeutet, ein Ressourcenmodul beinhaltet alle nötigen Details um jeden Eintrag in der Configuration zu behandeln und in ein imperativen Code umzuwandeln. Wie auch immer: es übersetzt am Ende die deklerative Konfiguration, die für den Nutzer wesentlich einfacher ist.

Eigenschaften

Wie eine Configuration aufgebaut ist, ist bereits bekannt. Eine Ressource braucht kein spezielles Keyword wie eine Funktion. In jedem Node Block können die auf dem System zu Verfügung stehenden Ressourcen eingesetzt werden. Das Keyword was hier benutzt werden muss, ist der Name der Ressource. Um herauszufinden, welche Eigenschaften einer Ressource definiert werden können, gibt es mehrere Wege. Ein Weg ist das Drücken der “strg+leer” Taste innerhalb des Code-Blocks. In diesem Fall öffnet sich ein Popupmenü mit den entsprechenden Eigenschaften


Eine andere Möglichkeit ist über die Shell.

PS C:UsersAndy> Get-DscResource -Name Archive -Syntax
Archive [String] #ResourceName
{
Destination = [string]
Path = [string]
[Checksum = [string]{ CreatedDate | ModifiedDate | SHA-1 | SHA-256 | SHA-512 }]
[Credential = [PSCredential]]
[DependsOn = [string[]]]
[Ensure = [string]{ Absent | Present }]
[Force = [bool]]
[PsDscRunAsCredential = [PSCredential]]
[Validate = [bool]]
}

Die Archive Ressource ist auch ein gutes Beispiel um die typischen Eigenschaften zu zeigen. Das wohl häufigste ist DependsOn. Durch diese kann definiert werden, welche Aktion abgeschlossen sein muss, bevor diese Aktion ausgeführt wird. Meistens wird diese genutzt, wenn zuvor Daten kopiert werden müssen. Ensure ist eine weitere Eigenschaft die fast immer vorhanden ist. Ensure kann zwei Werte beinhalten, Absent und Present, für nicht Vorhanden(entfernen ) und Vorhanden. Dies ist auch in der Shell-Abfrage zu sehen, genauso wie andere erwartete Werte. Die Eigenschaften sind eigentlich immer leicht zu interpretieren und verständlich.

Finden von Ressourcen

Der Pfad für die Ressourcen die Windows von Hause aus mitbringt ist der schon bekannte Modulpfad unter C:WindowsSystem32WindowsPowerShellv1.0Modules. In dem Modul PSDesiredStateConfiguration befindet sich ein Ordner DSCResources Alle MSFT_* Ordner beinhalten eine Mof Datei. In dieser Datei befindet sich auch der Code, welcher die deklarativen Befehle der Eigenschaften in Imperative umwandelt. Mof Dateien zu untersuchen würde hier aber zu weit führen.

Der Ordner C:Program FilesWindowsPowerShellModules beinhaltet alle heruntergeladenen oder kopierten Ressourcen. Alle nicht vom System bereitgestellten Module sollten dorthin kopiert werden. Über die Shell heruntergeladenen und installierten Module werden automatisch unter diesem Pfad gespeichert. Zu beachten ist, dass alle Nodes die eine Configuaration beinhalten auch Zugriff auf Ressourcen hat. Entweder durch kopieren in das Verzeichnis oder das Bereitstellen über ein Web- oder File- Server.

Module sind recht einfach zu finden und noch einfacher zu installieren. Mit dem CmdLet Find-Module wird das Online Repository durchsucht und alle zu Verfügung stehenden Module angezeigt. Bei dem Ersten Aufruf von Find-Module muss noch der NuGet Provider installiert werden um das Repository durchsuchen zu können. Ein Dialogfeld weist darauf hin, über dies es auch möglich ist den Provider zu installieren.



Mit Find-Module werden nicht nur DSCResourcen gefunden, sondern auch Module die CmdLets oder Funktionen enthalten. Beispielsweise ist PowerShellISE-preview so ein Modul. Mit Get-DSC Resource wird es nicht angezeigt, wenn aber Get-Module ausgeführt wird, sieht man einerseits, dass der Pfad “C:Program FilesWindowsPowerShellModules” mit durchsucht wird und auch, dass der das Modul PowerShellISE-preview enthält.


Verzeichnis: C:Program FilesWindowsPowerShellModules
ModuleType Version Name ExportedCommands
———- ——- —- —————-
Binary 1.0.0.1 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource…}
Binary 1.0.0.0 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource…}
Script 3.3.5 Pester {Describe, Context, It, Should…}
Script 1.0.0.1 PowerShellGet {Install-Module, Find-Module, Save-Module, Update-Module…}
Script 5.1.1 PowerShellISE-preview {Start-ISEPreview, Install-ISEPreviewShortcut, isep, Install-ISEPreviewShortcuts}
Script 1.1 PSReadline {Get-PSReadlineKeyHandler, Set-PSReadlineKeyHandler, Remove-PSReadlineKeyHandler, Get-PSReadlineOption…}

Jeder der sich die DSC Befehle schon etwas angeschaut hat stellt sich jetzt die Frage, wieso nicht das CmdLet Find-DscResource genommen wird. Die Ressourcen sind je nach Themen in Module Zusammengefasst. Ein gutes Beispiel um das zu verdeutlichen ist das xSharePoint Modul. Mit

Find-Module -Namexsharepoint


wird das gesamte Modul angezeigt mit seinen entsprechenden Eigenschaften wie Tags, Repository und Version. Um sich alles anzeigen zu lassen hängt man noch Format-List (fl) an den Befehl.

Find-Module -Name xsharepoint fl

Hier geht jedoch noch nicht hervor, welche Ressourcen dieses Modul enthält, diese kann man sich mit Find-DscResource anzeigen lassen.

Find-DscResource -moduleName xSharePoint

So wird jede Ressource angezeigt und kann weiter untersucht werden, z.B. mit dem schon genannten Syntax Schalter.

Installieren von Ressourcen

Wenn ein Modul mit den gewünschten Ressourcen mit Find-Module gefunden wurde, muss dieses noch installiert werden. Bei der Installation werden im Prinzip nur die Modul Dateien in den Modulpfad unter C:Program FilesWindowsPowerShellModules gespeichert. Der einfachste Weg ist es das gefundene Modul gleich an Install-Module zu Pipen. Die Meisten Module haben ein vorangestelltes x. Dieses x bedeutet, dass es sich um ein experimentelles Modul handelt. Weiterhin gibt es noch c, dieses sind Module aus der community. Weiterhin muss den Repositories noch vertraut werden, sonst wird bei jeder Installation diese Meldung angezeigt:


PS C:UsersAndy> Find-Module -Name xFirefox
Version Name Type Repository Description
——- —- —- ———- ———–
1.1.0.0 xFirefox Module PSGallery Firefox Main module
PS C:UsersAndy> Find-Module -Name xFirefox | Install-Module

Für das PSGallery Repository wäre das folgender Befehl:

Set-PSRepository -SourceLocation ‘https://www.powershellgallery.com/api/v2/’ –InstallationPolicy Trusted -Name PSGallery

Mit Get-PSRepository können alle Angezeigt werden und auch der Vertrauens Status überprüft werden.

Name PackageManagementProvider InstallationPolicy SourceLocation
—- ————————- —————— ————–
PSGallery NuGet Trusted https://www.powershellgallery.com/api/v2/

Um zu überprüfen ob das Modul erfolgreich installiert wurde, gibt es den Befehl Get-InstalledModule, welcher alle installierten Module anzeigt. Oder man schaut in den schon bekannten Installationsordner.

dir $env:ProgramFilesWindowsPowerShellModules


Wichtig ist, dass der Ordner mit den DSCResourcen vorhanden ist. In den meisten Fällen ist der Aufbau so: <Modulname><Versionsnummer>DSCResources. Bei Modulen wie xChrome oder xFirefox ist mir aufgefallen, dass die Resourcen mit Get-DscResource nicht angezeigt werden. Dadurch kann man nicht auf einen einfachen Weg die Syntax anschauen. In den Ressourcenordner befindet sich meistens auch ein Example Ordner, mit Hilfe der Beispiele kann man sich dann die Syntax erschließen. Alternativ kann man sich auch selber ein Beispiel schreiben. Hier mal ein Beispiel zu xChrome.


Das soll es auch erstmal zum Thema Ressourcen gewesen sein.

Im dritten Teil wird sich alles um das Thema Nodes drehen.

Über Andreas Bittner

MCSA Server 2016, MCSA Server 2012R2, Exchange 2010 & SharePoint Devop
Dieser Beitrag wurde unter Allgemein, Configuration, DevOps, DSC, Entwicklung, Grundlage, PowerShell, Resources veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.