Vor wenigen Tagen hat Steve Lee, Principal Software Engineer Manager für PowerShell, in einem umfangreichen Blog-Post dargestellt, wie es mit PowerShell weitergeht, und warum das nächste Release PowerShell 7 und nicht PowerShell 6.3 heißen wird. Die neue PowerShell Version wird dann auf .NET Core 3.0 basieren.
Im Post ist zu lesen, das abhängig von der Integration von PowerShell und .NET Core 3, eine erste Version von PowerShell 7 im Mai zu erwarten ist. Wir dürfen also gespannt sein!
Seit heute ist die neueste Version von PowerShell, PowerShell Core 6.2, allgemein verfügbar.
Zur Installation, siehe hier: https://aka.ms/install-powershell
Neben Bugfixes, Performanceoptimierung und co. gibt es auch ein paar kleine Features, einige davon experimentell, z.B. die automatischen Empfehlungen für Cmdlets, falls die Eingabe falsch/unvollständig ist.
Mehr zu den Features findet ihr auf dem offizielen Microsoft Blog:
In letzter Zeit beschäftige ich mich immer mal wieder mit DevOps-Themen. Eines davon ist Continuous Integration und das dafür gemachte Jenkins. Einige meiner Erfahrungen hierzu möchte ich gerne teilen.
Dieser Artikel beschäftigt sich mit PowerShell Core und Jenkins. In einem vorherigen Artikel habe ich in Kurzform erläutert, wie man Jenkins unter Debian Linux installiert. Das ist für diesen Artikel eine Art Voraussetzung.
Auch ohne PS Core kann Jenkins PowerShell-Code und –Skripte ausführen – allerdings braucht es dazu immer einen sogenannten “Build Slave” (also einen weiteren Jenkins-Knoten) mit Windows als Betriebssystem,
Mit der Verfügbarkeit von PowerShell Core für Linux ist es künftig nicht mehr zwingend nötig, einen Windows Buildslave zu verwenden, wenn man PowerShell benutzen möchte. Was leider NICHT funktioniert (zumindest mit Stand Heute), ist das PowerShell-Plugin für Jenkins. Dieses ruft den Code in einer Art und Weise auf, wie es nur unter Windows funktioniert. Selbst wenn man den dort verwendeten Aufruf “powershell.exe” mittels symbolic Link oder Alias auf pwsh mappt, wird es nicht funktionieren.
Ein möglicher Weg führt aber über den Einsatz eines Batch-Skriptes. Und das könnte so aussehen:
Mit Hilfe von Parametern kann später flexibler mit dem Build Job umgegangen werden (siehe weiter unten):
Der Einfachheit halber sollte der Parametername keine Leer- oder Sonderzeichen enthalten.
Für den eigentlichen Build (also die Aktionen, die durch den Job auszuführen sind), muss man hier nun auf “Shell ausführen” zurückgreifen. Der Menüpunkt “Windows PowerShell” wird nicht funktionieren (er steht auch nur zur Verfügung, wenn das Plugin bereits installiert ist).
Mein Aufruf für die Shell lautet hier beispielhaft:
Mit ${PARAMETER} kann man auf den oben definierten Parameter zurückgreifen.
Anschließend kann man den Buildjob über “Bauen mit Parametern” aufrufen. Dabei kann man dann den Wert des/der Parameter definieren (oder, falls man Defaultwerte definiert hat, diese einfach beibehalten):
Anschließend kann man mit einem Klick auf den kleinen Pfeil neben dem Buildjob unten bei “Build-Verlauf” die “Konsolenausgabe” aufrufen:
Dort sieht man dann entweder den/die Fehler, falls welche aufgetreten sind, oder eben die Ausgabe des Jobs:
Im Zuge der Weiterentwicklung von PowerShell Core und der Ausrichtung auf Linux-Systeme hat Microsoft eine neue Strategie für die Remote-Verwaltung von Systemen entwickelt. Diese beinhaltet u.a. die Verwendung von OpenSSH unter Windows. Das an sich ist nicht wirklich neu – zumindest etwas neuer ist aber die Tatsache, dass diese Technologie jetzt seit dem 1709 Build (“Fall Creators Update”) als Beta im System integriert ist. Allerdings müssen die Komponenten bei Bedarf noch aktiviert / installiert werden. Und das geht so:
Startmenü / Einstellungen (Zahnrad) / Apps / Optionale Features verwalten / Feature hinzufügen:
Dort finden sich dann die beiden OpenSSH Optionen:
Beide Optionen sollten eigentlich selbst-erklärend sein…
Alternativ kann die Installation auch über PowerShell erfolgen:
# Installieren von Server und Client Add-WindowsCapability -Online -Name OpenSSH* # Nur Server Add-WindowsCapability -Online -Name OpenSSH.Server* # Nur Client Add-WindowsCapability -Online -Name OpenSSH.Client*
Der SSH Client läuft jetzt völlig problemlos von der Kommandozeile – wenn man den vollen Pfad benutzt:
C:\Windows\System32\OpenSSH\ssh.exe
Spätestens nach dem nächsten Neustart ist dann der Pfad auch in PATH und damit von überall aus aufzurufen.
Die Konfiguration des OpenSSH-Servers ist ein kleines bisschen aufwändiger. Diesem Thema werde ich demnächst einen weiteren Blogartikel widmen. Stay tuned!
Wie Microsoft vor wenigen Tagen berichtet hat (siehe Blogartikel), ist PowerShell Core 6.0 seit dem 10.01.2018 GA und wird von Microsoft voll supported!
Den Download für PowerShell Core 6.0 findet man hier:
Die Liste der unterstützen Betriebssysteme ist lang:
Windows 7, 8.1, and 10
Windows Server 2008 R2, 2012 R2, 2016
Windows Server Semi-Annual Channel
Ubuntu 14.04, 16.04, and 17.04
Debian 8.7+, and 9
CentOS 7
Red Hat Enterprise Linux 7
OpenSUSE 42.2
Fedora 25, 26
macOS 10.12+
Wichtig ist ein Hinweise am Ende des Artikels:
Windows PowerShell 3.0, 4.0, and 5.1 will continue to be supported on supported versions of Windows and Windows Server. (Note: While Windows PowerShell 2.0 is still in support, it has been deprecated, and it’s recommend that workloads be migrated to newer versions of PowerShell.)
Für Windows PowerShell ab Version 3.0 gibt es also weiterhin Support – aber Neuerungen/Verbesserungen darf man hier wohl nicht mehr erwarten.
In nächster Zeit möchte ich mich mehr mit dem Thema “PowerShell Core” (also PowerShell 6.0, der Version auf Grundlage von .NET Core, die auf Linux, Unix und MacOS läuft) beschäftigen. Den Einstieg soll die Installation der PowerShell Core unter Debian Linux machen.
Zunächst brauch man eine unterstütze Linux-Version. Aktuell sind das:
Ubuntu 14.04
Ubuntu 16.04
CentOS 7
OpenSUSE 42.1
Arch Linux
RHEL 7.2/7.3
Debian 8
MacOS 10
Konkret für Debian bedeutet das, dass man “old stable” (Jessie) benutzen muss, weil Debian 9 “Stretch” noch nicht unterstützt wird.
Nach der frischen Installation von Debian 8 braucht man sinnvollerweise noch folgende Pakete:
sudo (Dazu muss man sich ggf. als root einloggen!)
SSH (damit der Zugang und das Übertragen der URLs einfacher wird)
Nun können die Vorbereitungen und die eigentliche PowerShell-Installation durchgeführt werden:
# Import der GPG Schlüssel für das MS Repository
curl https://packages.microsoft.com/keys/microsoft.asc |sudoapt-key add -
# Registrierung des Microsoft Repositories
curl https://packages.microsoft.com/config/debian/8/prod.list |sudotee/etc/apt/sources.list.d/microsoft.list
# Oder alternativ:# curl https://packages.microsoft.com/config/ubuntu/14.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list# Update mit apt-getsudoapt-get update# Installation von PowerShellsudoapt-get install-y powershell
# Start der PowerShell Core
powershell
# Import der GPG Schlüssel für das MS Repository
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
# Registrierung des Microsoft Repositories
curl https://packages.microsoft.com/config/debian/8/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list
# Oder alternativ:
# curl https://packages.microsoft.com/config/ubuntu/14.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list
# Update mit apt-get
sudo apt-get update
# Installation von PowerShell
sudo apt-get install -y powershell
# Start der PowerShell Core
powershell
