© best_vector/Shutterstock.com
Windows Developer
Continuous Delivery mit PowerShell Desired State Configuration

Systemadministration für Developer

Continuous Delivery von Services und Webseiten steht und fällt mit dem Automatisierungsgrad der einzelnen Schritte. Auch in der .NET-Community werden automatische Configuration-Management-Werkzeuge wie Chef und Puppet immer beliebter. Wer auf eine komplett PowerShell-/.NET-basierte Lösung von Microsoft setzen will, sollte sich PowerShell Desired State Configuration (DSC) näher anschauen, das künftig auch Linux unterstützt.

Maximilian Knor


Continuous Delivery ist speziell für Cloud-basierte Anwendungen ein wichtiges Konzept. Große Webseiten und Services rollen mehrmals täglich Änderungen an ihrer Codebasis aus, egal ob Bugfixes oder neue Features. Bei einer solchen Frequenz bleibt man ohne gute Automatisierung auf der Strecke. Traditionelle PowerShell-, Bash- oder sonstige Skripte können da rasch Erleichterung schaffen. Zuerst soll zum Beispiel der IIS Webserver installiert und danach sollen einige Module heruntergeladen und konfiguriert werden. Als Nächstes vielleicht noch ein SQL Server installiert, die gewünschte Datenbank geladen und die Webseite mit entsprechenden Dateisystemberechtigungen in den IIS eingestellt werden. Solche Skripte können relativ schnell zur Unübersichtlichkeit heranwachsen. Denn in jedem der erwähnten Schritte gilt es, mehrere Aspekte zu berücksichtigen:

Istzustand: Wie sieht der derzeitige Istzustand aus: Sind die gewünschten Änderungen bereits ganz oder teilweise am System durchgeführt? Ist beispielsweise IIS installiert?Installation und Konfiguration: Die gesamten Änderungen oder Teile davon durchführen (z. B. fehlende IIS-Module, Dateien etc.)Fehlerbehandlung: Zurückrollen der Änderungen. Falls ein Fehler auftritt, Fehlermeldungen ausgeben.Restarts: Manche Skripte müssen die Maschine während der Ausführung mehrfach neu starten. Außerdem beachten: Setzt das Skript anschließend an der gewünschten Stelle fort bzw. ist es idempotent?Das Schreiben eines guten PowerShell-Skripts kann also relativ aufwändig werden.

Die Syntax: deklarativ statt imperativ

Ein Hauptgrund für die Popularität von PowerShell DSC, Chef und Puppet ist eine wesentliche Vereinfachung der Skripte. Denn diese sind deklarativ und beschreiben lediglich den gewünschten Endzustand der Konfiguration (den Desired State), nicht jedoch, wie man dorthin gelangt. Dadurch fallen die meisten der erwähnten Überprüfungen weg. Die Listings 1 und 2 zeigen den Vergleich zwischen traditionellem und imperativem PowerShell sowie deklarativen PowerShell-DSC-Skripten.

Listing 1: Traditionelles und imperatives PowerShell-Skript

Listing 2: Deklaratives PowerShell-DSC-Skript

Auffallend ist das Fehlen jeglicher Fehlerbehandlung und der Überprüfungen. Stattdessen erinnert die Syntax eher an einen JSON-Objektbaum. Die kleinste Einheit eines PowerShell-DSC-Skripts sind so genannte Ressourcen. Listing 2 zeigt das WindowsFeature sowie Service. Eine DSC-Ressource spiegelt eine virtuelle Ressource unseres Zielsystems wider, die zu ...

Windows Developer
Continuous Delivery mit PowerShell Desired State Configuration

Systemadministration für Developer

Continuous Delivery von Services und Webseiten steht und fällt mit dem Automatisierungsgrad der einzelnen Schritte. Auch in der .NET-Community werden automatische Configuration-Management-Werkzeuge wie Chef und Puppet immer beliebter. Wer auf eine komplett PowerShell-/.NET-basierte Lösung von Microsoft setzen will, sollte sich PowerShell Desired State Configuration (DSC) näher anschauen, das künftig auch Linux unterstützt.

Maximilian Knor


Continuous Delivery ist speziell für Cloud-basierte Anwendungen ein wichtiges Konzept. Große Webseiten und Services rollen mehrmals täglich Änderungen an ihrer Codebasis aus, egal ob Bugfixes oder neue Features. Bei einer solchen Frequenz bleibt man ohne gute Automatisierung auf der Strecke. Traditionelle PowerShell-, Bash- oder sonstige Skripte können da rasch Erleichterung schaffen. Zuerst soll zum Beispiel der IIS Webserver installiert und danach sollen einige Module heruntergeladen und konfiguriert werden. Als Nächstes vielleicht noch ein SQL Server installiert, die gewünschte Datenbank geladen und die Webseite mit entsprechenden Dateisystemberechtigungen in den IIS eingestellt werden. Solche Skripte können relativ schnell zur Unübersichtlichkeit heranwachsen. Denn in jedem der erwähnten Schritte gilt es, mehrere Aspekte zu berücksichtigen:

Istzustand: Wie sieht der derzeitige Istzustand aus: Sind die gewünschten Änderungen bereits ganz oder teilweise am System durchgeführt? Ist beispielsweise IIS installiert?Installation und Konfiguration: Die gesamten Änderungen oder Teile davon durchführen (z. B. fehlende IIS-Module, Dateien etc.)Fehlerbehandlung: Zurückrollen der Änderungen. Falls ein Fehler auftritt, Fehlermeldungen ausgeben.Restarts: Manche Skripte müssen die Maschine während der Ausführung mehrfach neu starten. Außerdem beachten: Setzt das Skript anschließend an der gewünschten Stelle fort bzw. ist es idempotent?Das Schreiben eines guten PowerShell-Skripts kann also relativ aufwändig werden.

Die Syntax: deklarativ statt imperativ

Ein Hauptgrund für die Popularität von PowerShell DSC, Chef und Puppet ist eine wesentliche Vereinfachung der Skripte. Denn diese sind deklarativ und beschreiben lediglich den gewünschten Endzustand der Konfiguration (den Desired State), nicht jedoch, wie man dorthin gelangt. Dadurch fallen die meisten der erwähnten Überprüfungen weg. Die Listings 1 und 2 zeigen den Vergleich zwischen traditionellem und imperativem PowerShell sowie deklarativen PowerShell-DSC-Skripten.

Listing 1: Traditionelles und imperatives PowerShell-Skript

Listing 2: Deklaratives PowerShell-DSC-Skript

Auffallend ist das Fehlen jeglicher Fehlerbehandlung und der Überprüfungen. Stattdessen erinnert die Syntax eher an einen JSON-Objektbaum. Die kleinste Einheit eines PowerShell-DSC-Skripts sind so genannte Ressourcen. Listing 2 zeigt das WindowsFeature sowie Service. Eine DSC-Ressource spiegelt eine virtuelle Ressource unseres Zielsystems wider, die zu ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang