PowerShell: Mehr als nur Skripte

Woran denken Sie, wenn Sie PowerShell hören? Skripte? Wahrscheinlich. Das ist verständlich, denn eines der Hauptmerkmale von PowerShell ist Skripting.

Die meisten Entwickler nehmen Skripte nicht für voll. Skripte sind wie der nervige kleine Bruder von Software-Anwendungen. Skripte werden nur schnell zusammengeworfen, um eine einfache Aufgabe zu automatisieren, die Sie gestört hat. Natürlich ist diese Anwendung immer noch sehr nützlich, aber in dieser neuen DevOps Welt, in der wir leben, hat PowerShell hat sich in etwas viel Größeres gewandelt.

PowerShell hat sich von einer Skriptsprache auch in eine Automations-Sprache gewandelt. Merkmale wie Azure Shell, Azure-Funktionen und der Ausbau von einer ganzen DevOps Release-Pipeline sind drei sehr gute Beispiele dafür. PowerShell ist so nicht mehr nur eine Skriptsprache, wie es die Vorgänger VBscript und Batch-Dateien waren. Weil Microsoft so viele Resourcen in PowerShell investiert hat und fast jedes Team bei Microsoft für seine Produkte nun PowerShell hat, ist es zu dem Stoff geworden, der alles zusammenhält.

Neben der direkten Nutzung von PowerShell in der Cloud, wie bei Azure, gibt es eine Reihe von vorausdenkenden Organisationen, für die PowerShell ein wichtiges Werkzeug in ihren Produktionsprozessen geworden ist. Ein Hauptmerkmal bei der Nutzung von PowerShell als eine Automationssprache umfasst die Anwendung von Modulen. Module sind die Automationsbausteine in PowerShell. Module erlauben es Anbietern und Kunden eine “Paket”-Funktionalität um ein bestimmtes Produkt, eine Technologie herum oder für einen Zweck zu bilden. Module erlauben es, Funktionalitäten aufzuspalten und auf einfache Weise zu teilen.

Read: Don't Assume Anything In Code (PowerShell Coding Best Practices)

Leute, die PowerShell gerade erst kennenlernen, können einen Kurs über Modulerstellung (in Englisch) anschauen, ein einfaches Modul bauen und es nutzen. Aber sie verstehen damit noch nicht unbedingt, wie weitreichend dieses Modulkonzept benutzt werden kann!

Zum Beispiel arbeite ich in meiner jetzigen Position als Automationsingenieur. Ich bin in dieser Rolle zuständig für die Automatisierung von Testumgebungsbereitstellungen, Anwendungsbereitstellungen von Entwicklern und so weiter. Stellen Sie sich vor, wie so eine Testumgebung aussieht. Das ist eine fast eindeutige Kopie der Produktionsumgebung, bestehend aus Load Balancern, Web Servern, Datenbankservern, Dateiservern und so weiter. Jedes dieser Objekte braucht eine spezielle Konfiguration, die unter besonderen Bedingungen angewendet wird und das alles zu automatisieren ist eine gewaltige Arbeit. PowerShell alleine könnte das doch nicht bewerkstelligen, richtig? Verkehrt!

Man kann sehr wohl den Befehl New-Infrastructure laufen lassen und damit 10 Webserver, 2 geclusterte SQL-Server, vielleicht noch einen Webserver hier und da mit ein paar Websites, Applicationspools und anderen Kleinigkeiten hochbringen, und das wird auch in vielen Fällen gemacht, indem in PowerShell um die 100 verschiedene benutzerdefinierte Module eingesetzt werden. So kann PowerShell mit der Benutzung von Modulen auf einem höheren Niveau verwendet werden. Wenn Sie PowerShell in verschiedenen Niveaus sehen, dann kann man sich das so vorstellen: Shell --> Script --> Modul. Es gibt keine Kategorie für eine höhere Abstraktion. Ein Modul ist somit eigentlich die größte Kategorie, in die Code gehen kann. Aber nur weil eine Kategorie noch nicht existiert, heißt das nicht, dass es nicht möglich ist.

Indem man verschiedene PowerShell-Module wie ein einziges Produkt verwendet, kann man Tausende von verschiedenen Optionen ausführen und so ziemlich alles, was man möchte, in einer Organisation automatisieren.

Wenn Sie gerade erst anfangen PowerShell zu lernen, werden Sie nicht über Nacht dieses Niveau an Automation erreichen. Es bedarf Zeit und Mühe, Probleme in kleinere Komponenten zu zerlegen und zu verstehen, wie man die Prozesse strukturieren und schließlich den Code in den Modulen schreiben kann.

Mit der vollen Unterstützung von Microsoft, ist PowerShell zum Standard in Azure- und Windows-Umgebungen geworden und hat wesentlich größere Anwendungsmöglichkeiten gezeigt als VBScript und Batch-Dateien jemals hatten.

Tipp: Lesen Sie dazu auch das Whitepaper Automatisieren mit PowerShell oder laden Sie sich kostenfrei eine Testversion von MOVEit Automation, Software für die Automatisierung der Dateiübertragung, herunter.