Freigeben über

Werkzeuge für Containerplattformen unter Windows

Die Windows-Containerplattform wird erweitert! Docker war der erste Teil der Containerreise, jetzt erstellen wir andere Containerplattformtools.

In diesem Artikel werden die Windows- und Linux-Containerplattform sowie jedes Containerplattformtool behandelt.

Windows- und Linux-Containerplattform

In Linux-Umgebungen basieren Containerverwaltungstools wie Docker auf einer detaillierteren Gruppe von Containertools: runc und containerd.

Docker-Architektur unter Linux

runc ist ein Linux-Befehlszeilentool zum Erstellen und Ausführen von Containern gemäß der OCI-Containerlaufzeitspezifikation.

containerd ist ein Daemon, der den Lebenszyklus von Containern vom Herunterladen und Entpacken des Containerimages bis hin zur Containerausführung und -überwachung verwaltet.

Unter Windows haben wir einen anderen Ansatz verfolgt. Bei der Arbeit mit Docker zur Unterstützung von Windows-Containern haben wir direkt auf dem HCS (Host Compute Service) aufgebaut. Dieser Blogbeitrag enthält vollständige Informationen darüber, warum wir den HCS erstellt haben und warum wir diesen Ansatz zunächst für Container verwendet haben.

Anfängliche Docker-Modularchitektur unter Windows

Zu diesem Zeitpunkt ruft Docker weiterhin direkt in den HCS auf. In Zukunft könnten Containerverwaltungstools jedoch erweitert werden, um Windows-Container und den Windows-Containerhost einzuschließen und dabei ähnlich wie unter Linux containerd und runhcs aufzurufen.

runhcs

runhcs ist eine Verzweigung von runc. Wie runcist runhcs ein Befehlszeilenclient zum Ausführen von Anwendungen, die gemäß dem OCI-Format (Open Container Initiative) verpackt sind und eine kompatible Implementierung der Spezifikation der Open Container Initiative ist.

Zu den funktionalen Unterschieden zwischen Runc und Runhcs gehören:

  • runhcs wird unter Windows ausgeführt. Es kommuniziert mit HCS-, um Container zu erstellen und zu verwalten.

  • runhcs kann verschiedene Typen von Containern ausführen.

    • Hyper-V-Isolation unter Windows und Linux
    • Windows-Prozesscontainer (Containerimage muss mit dem Containerhost übereinstimmen)

Nutzung:

runhcs run [ -b bundle ] <container-id>

<container-id> ist Ihr Name für die Containerinstanz, die Sie starten. Der Name muss auf Ihrem Containerhost eindeutig sein.

Das Paketverzeichnis (mit -b bundle) ist optional. Wie bei Runc werden Container mit Bundles konfiguriert. Das Bündel eines Containers ist das Verzeichnis mit der OCI-Spezifikationsdatei des Containers, "config.json". Der Standardwert für "bundle" ist das aktuelle Verzeichnis.

Die OCI-Spezifikationsdatei "config.json" muss zwei Felder haben, um ordnungsgemäß ausgeführt zu werden:

  • Ein Pfad zum temporären Speicherbereich des Containers
  • Ein Pfad zum Layerverzeichnis des Containers

Containerbefehle, die in Runhcs verfügbar sind, umfassen:

  • Tools zum Erstellen und Ausführen eines Containers

    • run erstellt einen Container und führt ihn aus.
    • erstellen einen Container erstellen

  • Tools zum Verwalten von Prozessen, die in einem Container ausgeführt werden:

    • starten, den benutzerdefinierten Prozess in einem erstellten Container ausführt
    • exec führt einen neuen Prozess im Container aus.
    • pause hält alle Prozesse innerhalb des Containers an.
    • resume setzt alle Prozesse fort, die zuvor angehalten wurden.
    • ps ps zeigt die Prozesse an, die in einem Container ausgeführt werden

  • Tools zum Verwalten des Zustands eines Containers

    • Zustand gibt den Status eines Containers aus.
    • kill sendet das angegebene Signal (Standard: SIGTERM) an den Init-Prozess des Containers.
    • delete löscht alle im Container enthaltenen Ressourcen und wird häufig mit getrennten Containern verwendet.

Der einzige Befehl, der als Multicontainer betrachtet werden kann, ist Liste. Er listet ausgeführte oder angehaltene Container auf, die von runhcs mit dem angegebenen Stamm gestartet wurden.

HCS

Wir haben zwei Wrapper auf GitHub zur Schnittstelle mit dem HCS verfügbar. Da es sich bei dem HCS um eine C-API handelt, erleichtern Wrapper das Aufrufen des HCS aus Sprachen höherer Ebene.

  • hcsshim - HCSShim ist in Go geschrieben und es ist die Grundlage für Runhcs. Holen Sie sich die neuesten Von AppVeyor, oder erstellen Sie es selbst.
  • dotnet-computevirtualization - dotnet-computevirtualization ist ein C#-Wrapper für den HCS.

Wenn Sie den HCS (entweder direkt oder über einen Wrapper) verwenden oder einen Rust/Haskell/InsertYourLanguage Wrapper um den HCS erstellen möchten, hinterlassen Sie bitte einen Kommentar.

Für einen tieferen Einblick in das HCS sehen Sie sich die DockerCon-Präsentation von John Starkan.

containerd/cri

Wichtig

CRI-Unterstützung ist nur in Windows Server 2019/Windows 10 1809 und höher verfügbar.

Während OCI-Spezifikationen einen einzelnen Container definieren, beschreibt CRI- (Containerlaufzeitschnittstelle) Container als Arbeitslasten in einer freigegebenen Sandkastenumgebung, die als Pod bezeichnet wird. Pods können eine oder mehrere Containerworkloads enthalten. Pods sind eine Funktion von Container-Orchestratoren wie Kubernetes und Service Fabric Mesh und ermöglichen das Management von gruppierten Workloads, die sich auf demselben Host mit gemeinsam genutzten Ressourcen wie Arbeitsspeicher und vNETs befinden sollten.

RunHCS und containerd können beide auf jedem Windows-System ab Server 2016 laufen, aber die Unterstützung von Pods (Gruppen von Containern) erforderte grundlegende Änderungen an den Container-Tools in Windows. CRI-Unterstützung ist unter Windows Server 2019/Windows 10 1809 und höher verfügbar.