In der lokalen Installation eines Container-Hosts steuern Administratoren die Container in der PowerShell (Screenshot: Thomas Joos).
Für die Inbetriebnahme und Verwaltung von Windows Server Container nutzt man am besten die PowerShell. Dadurch besteht die Möglichkeit, in mehreren Fenstern parallel mit Containern arbeiten zu können. So lassen sich in einem Fenster beispielsweise die Hosts verwalten, während in einem anderen neue Images erstellt werden. Innerhalb der Container lassen sich auch komplexe Aufgaben durchführen, Serverdienste betreiben und mehr.
In den meisten Umgebungen wird auf Core-Servern gearbeitet, um einen Windows Server Container-Host zu erstellen. In zukünftigen Versionen von Windows Server 2016 soll auch die Integration von Windows Server Containern auf Nano-Servern möglich sein. Mit dem Befehl powershell wird in der Befehlszeile direkt in die PowerShell gewechselt. Umgekehrt können Administratoren mit cmd wieder in die Befehlszeile zurück wechseln. Das funktioniert auch innerhalb von Windows Server Containern. Auch hier steht die PowerShell zur Verfügung, aber auch die Eingabeaufforderung.
Alle Befehle für Verwaltung von Containern zeigen Administratoren mit dem Befehl get-command -Module Containers an.
Die CMDlets in diesem Modul bilden also den Einstieg in die Verwaltung des Container-Hosts. Hier werden die Images und die erstellten Container verwaltet. Auf den Container-Hosts stehen aber auch die herkömmlichen Befehle zur Verfügung, um mit der PowerShell zu arbeiten.
Grundlage von Container sind Container-Images. Diese werden auf dem Container-Host mit get-containerimage angezeigt. Auf jedem Container-Host musst es mindestens ein Image geben, auf dessen Basis Container erstellt werden können.
Mit dem CMDlet get-containerhost werden wichtige Informationen zum Container-Host angezeigt. Hier ist der Speicherort des Containerimage-Repository zu sehen, also der Speicherort der Imagedateien. Aus Leistungsgründen macht es natürlich Sinn, die Daten am besten auf einem schnellen Datenspeicher abzulegen. Dabei kann es sich um einen Speicherpool handeln, eine SSD oder ein Volume auf einem SAN.
Die bereits vorhandenen Images werden mit get-containerimage angezeigt. Es ist natürlich sinnvoll, das Repository am besten dann zu verschieben, wenn noch nicht zu viele Images erstellt und zu viele Container gestartet sind. Windows Server 2016 bietet dazu das CMDlet Move-ContainerImageRepository <Neuer Pfad zum Repository>. Der Vorgang kann einige Zeit dauern.
Wurden auf einem Host bereits Containerimages erstellt, ist es sinnvoll, diese vor dem Verschieben des Repositories zu exportieren. Die exportierten Images lassen sich darüber hinaus auch auf anderen Container-Hosts weiterverwenden und importieren. Zum Exportieren wird das CMDlet Export-ContainerImage verwendet. Die Syntax sieht folgendermaßen aus:
Export-ContainerImage -Image <Name des Images> -Path <Export-Pfad>
Natürlich lassen sich auch hier alle Images auf einmal exportieren, indem diese mit get-containerimage abgefragt, und das Ergebnis an das CMDlet Export-ContainerImage weitergebenen wird:
get-containerimage |Export-ContainerImage -Path <Export-Pfad>
Der Vorgang kann einige Zeit dauern. Mit diesen CMDlets lassen sich auch Probleme mit Images beheben. Administratoren können die Images exportieren, danach mit dem CMDlet Remove-ContainerImage löschen, und danach wieder mit Import-Containerimage importieren.
Hilfreich ist das zum Beispiel, wenn das Repository der Container-Images verschoben werden soll. Der Import erfolgt über eine APPX-Datei, die sich auf dem Server befinden muss, auf dem Administratoren das Image importieren wollen.
Windows Server Container werden über virtuelle Switches mit dem Netzwerk verbunden. Mit dem CMDlet get-vmswitch lassen sich die virtuellen Switches eines Container-Hosts anzeigen. Beim Erstellen eines neuen Containers lässt sich die virtuelle Switch dem ersten Netzwerk-Adapter des Containers zuweisen:
New-Container -Name „Cont01“ -ContainerImageName WindowsServerCore -SwitchName „Virtual Switch“
Innerhalb von Containern werden Programme installiert und Änderungen vorgenommen. Soll auf Basis eines Containers ein weiterer Container bereitgestellt werden, oder im produktiven Umfeld eine ganze Reihe weiterer Container, ist der einfachste Weg dazu ein neues Image. Dazu verwenden Administratoren das CMDlet New-ContainerImage. Dieses kann auf Grundlage eines vorhandenen Containers problemlos ein Image erstellen, auf dessen Basis sich weitere Container erstellen lassen. Beim Erstellen lässt sich sogar der Publisher festlegen und auch Versionen werden unterstützt:
New-ContainerImage cont01 -Name „webimage“ -Publisher Contoso -Version 1.0.0.0
Um ein Container-Image zu erstellen, muss der Container ausgeschaltet sein. Dazu wird das CMDlet Stop-Container verwendet. Danach steht das Image zur Verfügung, und lässt sich mit dem CMDlet New-Container zum Erstellen weiterer Container verwenden.
Bevor Administratoren Images produktiv einsetzen, sollten sie zuerst überprüfen, ob das entsprechende Image funktioniert. Dazu wird das CMDlet Test-ContainerImage verwendet. Auch hier besteht die Möglichkeit die Ausgabe von Get-ContainerImage zu verwenden, und an Test-ContainerImage weiterzugeben, um alle Images auf einem Container-Host zu testen:
Get-ContainerImage | Test-ContainerImage
Neu erstellte Container sind generell ausgeschaltet. Das ist auch am Status „Off“ zu sehen, wenn mit Get-Container der Status aller Container auf einem Host angezeigt wird. Wenn ein Container erstellt, und die Netzwerkverbindung generell hergestellt werden kann, lässt er sich mit start-container <Name des Containers> starten. Danach wird das Betriebssystem im Container gebootet, und er ist einsatzbereit. Um den Container herunterzufahren wird stop-container verwendet.
Da die virtuellen Switches und die Netzwerkadapter der Container zentraler Bestandteil eines Containers sind, lassen sich diese direkt aus der PowerShell heraus anzeigen:
get-containernetworkadapter <Name des Container>
Dadurch lässt sich sofort erkennen, ob ein Container eine Verbindung mit dem Netzwerk aufbauen kann. Administratoren können mit dem CMDlet Add-ContainerNetworkAdapter <Name des Containers> jedem Container weitere Adapter zuweisen und den Adaptern wiederum verschiedene Netzwerk-Switches.
Standardmäßig werden hinzugefügte Netzwerkadapter aber noch nicht mit dem Netzwerk verbunden. Um eine Verbindung zwischen virtuellen Netzwerkadaptern in Containern und virtuellen Switches herzustellen, muss mit dem CMDlet Connect-Networkadapter <Name des Containers> erst eine Verbindung hergestellt werden.
Mit dem CMDlet werden generell alle virtuellen Netzwerkadapter eines Containers mit der virtuellen Switch auf dem Container-Host verbunden. Soll ein Container wieder vom Netzwerk getrennt werden, wird das CMDlet Connect-Networkadapter <Name des Containers> verwendet.
Natürlich besteht auch die Möglichkeit, die Bezeichnung des neuen virtuellen Netzwerkadapters im Container zu steuern, und auch gleich eine Zuweisung an eine passende virtuelle Switch vorzunehmen:
Add-ContainerNetworkAdapter -ContainerName „Cont01“ -Name „Nic03“ -SwitchName „Virtual Switch“
Interessant sind diese CMDlets also auch dann, wenn mehreren Containern ein neuer virtueller Netzwerkadapter mit einer bestimmten Bezeichnung hinzugefügt werden soll, der auch gleich automatisch mit einer bestimmten virtuellen Switch verbunden wird. Dadurch lassen sich VLANs erstellen, oder eigene Netzwerke in der DMZ. Ein Beispiel für einen solchen Vorgang ist:
Add-ContainerNetworkAdapter -ContainerName „Cont01“, „cont02“ -Name „DMZ“ -SwitchName „intern“
Connect-ContainerNetworkAdapter -ContainerName cont01, cont02 -Name „DMZ“ -SwitchName „Intern“
Auch die CMDlets für Container lassen sich miteinander verbinden. Administratoren können zum Beispiel die virtuellen Adapter eines Containers auslesen und das Ergebnis sofort dem CMDlet zum Zuweisen von virtuellen Container-Netzwerkadaptern übergeben:
Get-ContainerNetworkAdapter -ContainerName „Cont01“ | Connect-ContainerNetworkAdapter -SwitchName „VirtualSwitch“
Anschließend kann eine PowerShell-Sitzung in diesem Container eröffnet werden, um Serverdienste im Container zu verwalten. Dazu wird die ID des Containers benötigt. Diese wird mit get-container |fl ContainerID angezeigt.
Um eine PowerShell-Sitzung in einem Container zu starten, verwenden Administratoren das CMDlet Enter-PSSession. Idealerweise sollte hier ein neues PowerShell-Fenster für jeden Container geöffnet werden, da dadurch der Host und die Container besser verwaltet werden können. Um einen Verbindungsaufbau vorzunehmen wird zusätzlich noch die Option RunAsAdministrator verwendet. Diese sorgt dafür, dass im Container mit Administratorrechten gearbeitet wird. Die Syntax des Befehls ist:
Enter-PSSession -ContainerId <ID> -RunAsAdministrator
Die ID eines Containers wird am schnellsten mit dem Befehl get-container cont01 |fl *id*angezeigt.
Administratoren können aber auch mit dem CMDlet Invoke-Command arbeiten, um auf Containern über das Netzwerk Befehle auszuführen. Um die Sitzung eines Containers zu verlassen verwenden Administratoren das CMDlet Disconnect-PSSession. Alle aktuell gestarteten Skripte bleiben dabei aber aktiviert. Um eine Sitzung wieder zu öffnen, nutzen Administratoren das CMDlets Connect-PSSession.
Betreiben Administratoren einen Web-Server innerhalb eines Containers, kann es Sinn machen, diesen an ein E-Mail-System anzubinden. Auch zur Überwachung von Containern kann die Verwendung der PowerShell sinnvoll sein. Alle notwendigen Objekte stehen in der PowerShell zur Verfügung. Um E-Mails zu versenden, können Administratoren das CMDlet New-Object nutzen. Dieses kann E-Mails erstellen und sich an E-Mail-Servern anmelden, wenn diese eine Authentifizierung benötigen.
Im folgenden Beispiel ist zu sehen, welche weitreichenden Möglichkeiten es in der PowerShell von Windows Server Containern gibt. Aus Containern heraus lassen sich problemlos Serverdienste und Verbindungen zu anderen Servern aufbauen und produktiv nutzen, auch in die Cloud
Um eine einfache E-Mail zu versenden, schreiben Administratoren ein Skript oder speichern die einzelnen Daten in Variablen. Zunächst speichern werden Absender und Empfänger der E-Mail in der PowerShell als Variable gespeichert. Im folgenden Beispiel werden die E-Mail-Adressen thomas.joos@live.de als Absenderadresse und thomas.joos@outlook.com als Empfänger verwendet.
$from = „thomas.joos@live.de“
$to = „thomas.joos@outlook.com“
Danach lässt sich auch der Betreff in einer Variablen speichern:
$Subject = „PowerShell-E-Mail aus Windows Server Container“
Den Text der E-Mail können Administratoren ebenfalls als Variable speichern:
$text = „Dies ist eine E-Mail aus der PowerShell in einem Windows Server Container aus Windows Server 2016 TP3“
In den nächsten Schritten legen Administratoren den SMTP-Server fest, über den sie die E-Mails senden wollen. Dazu wird der Server in der Variable $server gespeichert, danach der Benutzernamen für die Anmeldung mit der Variable $user, und das Kennwort zur Anmeldung mit der Variable $pass:
$server = „smtp.live.com“
$user = „thomas.joos@live.de“
$pass = „<Kennwort in Klartext>“
Anschließend wird der Befehl erstellt, um eine E-Mail zu versenden. Der Befehl nutzt dazu die erstellten Variablen:
$SMTPClient = New-Object System.Net.Mail.SmtpClient($server, 25)
Auch diese Konfiguration lässt sich in einer Variablen speichern. Im Anschluss müssen auch noch die Anmeldedaten festgelegt werden. Danach wird die E-Mail versendet:
$mail.Credentials = New-Object System.Net.NetworkCredential($User, $Pass); $mail.Send($From, $To, $Subject, $text)
Wenn der Server TLS oder eine andere Sicherheitsverbindung nutzt, müssen die Befehle etwas anders aufgebaut werden:
$Server = „smtp.live.com“
$Port = „587“
$User = „thomas.joos@live.de“
$Pass = „<Kennwort in Klartext>“
$email = New-Object System.Net.Mail.MailMessage
$email.From = „thomas.joos@live.de“
$email.To.Add( „thomas.joos@outlook.com“ )
$email.Subject = „Power-Shell-Test-E-Mail aus Windows Container“
$email.IsBodyHtml = $false
$email.Body = „Test-Text“
$SMTPClient = New-Object System.Net.Mail.SmtpClient( $Server , $Port )
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($User , $Pass );
$SMTPClient.Send( $email )
An diesem Beispiel ist schnell zu erkennen, dass Container trotz aller Absicherung durchaus einiges leisten und problemlos mit Diensten in Netzwerk und Cloud kommunizieren können.
In Containern laufen genauso Prozesse und Systemdienste, wie auch bei vollständig installierten Servern. Administratoren können die Prozesse in der PowerShell überwachen und steuern. Über den Befehl Get-Process erhält man den Status über alle laufenden Prozesse eines Systems.
Sollen zum Beispiel alle Prozesse mit dem Anfangsbuchstaben „S“ angezeigt werden, geben Administratoren den Befehl Get-Process s* ein. Sollen die Prozesse zusätzlich noch sortiert werden, zum Beispiel absteigend nach der CPU-Zeit, wird Get-Process s* gefolgt von der Pipe-Option |Sort-Object cpu -Descending eingegeben.
Dienste können in der PowerShell mit Start-Service, Stop-Service, Get-Service und Set-Service gestartet werden. Außerdem lassen sich damit Dienste beenden und Informationen abrufen. Die CMDlets lassen sich problemlos auch in Windows Server Containern nutzen. Auch die Befehlszeilentools net start und net stop helfen bei der Verwaltung der Systemdienste und funktionieren auch in der PowerShell von Windows Server Containern.
Administratoren können mit der PowerShell die Ereignisanzeige auf Windows Server Containern lesen. Dazu wird das CMDlet Get-Eventlog verwendet. Mit den Optionen system, application und security lassen sich die einzelnen Ereignisanzeigen öffnen.
Administratoren können aber auch nur die aktuellsten Meldungen anzeigen, zum Beispiel mit folgendem Befehl: Get-Eventlog system -Newest 100. Interessant in diesem Zusammenhang ist auch die Möglichkeit nach bestimmten Quellen filtern zu lassen:
Get-EventLog System -Newest 10 -Source „Service*“ | Format-Table TimeWritten, Source, EventID, Message -auto
Auch nach der ID lässt sich filtern:
Get-EventLog -Logname system -InstanceId 7040 -Newest 10
Unternehmen räumen der Entwicklung technischer und digitaler Führungskompetenzen ein zu geringe Priorität ein. Gartner fordert…
Betroffen sind Android 12, 13, 14 und 15. Google sind zielgerichtete Angriffe auf die beiden…
Schadprogramm der pakistanischen Hackergruppe APT36 weitet seine Aktivitäten aus und verbessert seine Techniken.
Tenable vergibt für beide Schwachstellen einen CVSS-Basis-Score von 9,8. Zwei Use-after-free-Bugs erlauben möglicherweise das Einschleusen…
Erstmals liegen Preise für Verbraucher vor. Sie zahlen weniger als Geschäftskunden. Dafür beschränkt Microsoft den…
Die Entwickler arbeiten noch an weiteren „Verfeinerungen“. Windows Insider erhalten nun wohl eine erste Vorschau…
