Kritik: Red Hat macht Docker auf die harte Tour

Red Hats Project Atomic ist eine bewährte Methode zum Ausführen von Linux-Containern. Auf dem Atomic Host-Betriebssystem sind Docker (Container), Flannel (Netzwerk), OSTree (Hostverwaltung), Etcd (verteilter Schlüsselwertspeicher) und Kubernetes (Orchestrierung) bereits installiert. 

Kubernetes ist eines der beiden beliebten Container-Orchestrierungssysteme, das andere ist Docker Swarm. Man könnte es als "volle Stärke" bezeichnen, aber das bringt zusätzliche Komplexität und zusätzlichen Verwaltungsaufwand mit sich.

Kubernetes koordiniert die Erstellung von "Pods" über mehrere Atomic-Hosts hinweg. Pods sind Gruppen von Docker-Containern, die Dienste in einer Anwendung logisch trennen. Die Container in einem Pod teilen sich eine IP-Adresse und kommunizieren über localhost.

Flannel bietet ein Overlay-Netzwerk für Atomic-Hosts, sodass jeder Pod im Cluster mit jedem anderen Pod oder Dienst im Cluster kommunizieren kann. Dieses Overlay-Netzwerk wird nur für das Containernetzwerk verwendet. Ein Kubernetes-Proxy-Dienst bietet Zugriff auf den Host-IP-Bereich.

Etcd wird verwendet, um Konfigurationen für Kubernetes und Flannel auf allen Hosts im Cluster zu speichern.

Atomcontainer-Cluster treffen aufgrund von Kubernetes bestimmte Annahmen. Administratoren haben mit Atomic wirklich keine Wahl: Verwenden Sie entweder Kubernetes oder suchen Sie ein anderes Container-Betriebssystem. 

Wenn Sie sich an „Design by Convention“ scheuern und mehr Freiheit und Flexibilität in einem Container-Host wünschen, sollten Sie RancherOS oder VMware Photon in Betracht ziehen. Wenn Ihr ultimatives Ziel darin besteht, viele Container auf vielen Hosts auszuführen, sind Atomic Host, Kubernetes und Freunde möglicherweise genau das Richtige für Sie.  

Atomic Host Systemadministration

Atomic Host verwendet eine eigene Version des dockerBefehls, atomicobwohl der eigentliche  dockerBefehl in / bin / docker verfügbar ist. Die Position in / bin weist auf einige der Überarbeitungen hin, die RHEL / CentOS / Fedora vorgenommen haben, um das Atomic OS speziell für Container zu entwickeln. Normalerweise befinden sich nur wichtige System-Binärdateien in / bin.

Sie verwalten Atomic Host über zwei Subsysteme. RPM-OSTree übernimmt die Bereitstellung und Aktualisierung des Hostsystems, während Docker die Bereitstellung von Containern für die Ausführung von Diensten und Anwendungen übernimmt. Beide Subsysteme werden mit dem atomicBefehl in / usr / bin / verwaltet.

RPM-OSTree macht das Atomic-Dateisystem unveränderlich. Das heißt, das Dateisystem ist schreibgeschützt, mit Ausnahme von / var und / etc. Im Verzeichnis / var / lib / docker werden alle Docker-bezogenen Dateien und Bilder gespeichert, während / etc alle Konfigurationsdateien enthält. Wie wir später sehen werden, ermöglicht dies einfachere und sicherere Upgrades und Downgrades des Hosts. Dies ist eine wesentliche Voraussetzung für die Verwaltung von möglicherweise Tausenden von Container-Hosts in einem Cluster.

Der atomicBefehl soll ein einzelner Einstiegspunkt in das Containersubsystem sein - ein Umbrella-Befehl für alle Container, einschließlich Host-Operationen. Der atomicBefehl ähnelt dem Befehl und fühlt sich ähnlich an docker, behebt jedoch ein grundlegendes Problem, das von allen Container-Host-Betriebssystemen gemeinsam genutzt wird: Starten eines Dienstes auf Systemebene in einem Container beim Booten auf zuverlässige und transparente Weise mithilfe von Systemd-Einheitendateien.

In Atomic erfolgt dies mit einem so genannten Superprivilegierten Container, der den Host selbst sehen und bearbeiten kann. Obwohl dies atomicwie ein Standard-Docker-Befehl aussieht, füllt er die Lücken zwischen Docker und RPM-OSTree - Konfigurieren von Installationsskripten, Einrichten von Diensten, Zuweisen geeigneter Berechtigungen usw. -, um die zuverlässige Bereitstellung einer container-basierten Anwendung zu ermöglichen .

Mit dem atomic Befehl können Sie einfach  die zugrunde liegende Host-Infrastruktur (cgroups, Namespaces, SELinux usw.) bearbeiten, um Ihre Anwendungen auszuführen. Angenommen, Sie haben eine ntpd-Containeranwendung (Network Time Protocol) erstellt, für die die SYS_TIME-Funktion erforderlich ist, um die Systemzeit des Hosts zu ändern. Sie können dies konfigurieren, indem Sie Ihrem Container-Image Metadaten mit dem folgenden Befehl hinzufügen:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

Wenn Sie dann container ( atomic run ntpd) ausführen , liest das System diese Metadaten und konfiguriert die SYS_TIME-Funktion und andere Ressourcen für den Container. 

Installation und Konfiguration von Atomic Host

Die Installation war ein Kampf, vor allem, weil ich die Dokumentation unorganisiert und verwirrend fand. Die Dokumente setzen ein hohes Maß an Wissen über das Red Hat-Ökosystem voraus, das nicht jeder Leser haben wird. Nach ein paar Fehlstarts gelang es mir schließlich, von einer Bare-Metal-ISO zu installieren. Die Unterstützung für die Installation virtueller Maschinen mit etwas anderem als virt-manager ist schmerzhaft. Atomic Host ist in dieser Hinsicht definitiv nicht Windows- oder Mac-freundlich.

Für alle, die mit einer CentOS-Installation vertraut sind, ist das Bare-Metal-Verfahren einfach. Die einzigen erkennbaren Unterschiede bestehen im Festplattenlayout, wobei automatisch Speicherplatz für Docker und Container reserviert wird, sowie in der Vielzahl von Bereitstellungen für SELinux, Gruppen usw., die mit der Installation eines Container-Betriebssystems einhergehen.

Die Verwendung von Kubernetes zum Verwalten von Containern in einem Cluster ist erheblich komplizierter als das Ausführen von Docker auf einem einzelnen Host. Mit zunehmender Komplexität steigt jedoch die Zuverlässigkeit und Leistungsfähigkeit. Mit Kubernetes können Sie auch sicher sein, dass das System in großen Produktionsumgebungen (bei Google) kampferprobt wurde.

Es gibt keine einfache Möglichkeit, einen Kubernetes-Master einzurichten. Die Dokumentation ist auf verschiedene Projektwebsites verteilt, und häufig werden die Dokumente auf anderen Websites nach Details durchsucht. Seien Sie also darauf vorbereitet, viel Zeit mit Lesen, Jagen von Dokumenten und Experimentieren zu verbringen. Der Gesamtaufwand umfasst das Ändern von etwa einem Dutzend Dateien, die auf einige / etc-Verzeichnisse verteilt sind. Der Trick besteht natürlich darin, zu wissen, was diese Modifikationen sind. Kubernetes ist nicht wirklich für gelegentliches Experimentieren mit Containern gemacht. Das ist Hochleistungsproduktion.

Nachdem ich den Master mit Kubernetes, Zertifikaten, Diensten und einem Flannel-Overlay-Netzwerk konfiguriert und dann Flannel (Flanneld), Kubernetes (Kubelet) und Etcd auf jedem Knoten installiert hatte, lief schließlich ein Container-Cluster mit fünf Knoten. Leider hat dies ziemlich viel Speicher verbraucht, und ich konnte keine Möglichkeit finden, mit einem einzelnen Knoten zu testen, wie ich es beim Testen von RancherOS und VMware Photon getan habe.

Zu diesem Zeitpunkt können Kubernetes zum Starten und Verwalten von Pods verwendet werden, also von Containergruppen, die Dienste und Anwendungen kapseln.

Atomic Host Speicher und Netzwerk

Wie die meisten Container-Host-Betriebssysteme verfolgt Atomic Host einen minimalistischen Ansatz, wobei gerade genug Speicherplatz zum Ausführen des Hosts enthalten ist. Für die vielen Docker-Container, die ein typischer Cluster ausführen wird, bleibt nicht viel übrig. Daher müssen Sie dafür externen Speicher an den Host anschließen.

In Docker werden Bilder und zugehörige Dateien normalerweise in / var / lib / docker gespeichert. Unter den meisten Standardbetriebssystemen würden Sie einfach ein Gerät an dieser Stelle im Dateisystem bereitstellen, um Speicher hinzuzufügen. Atomic verwendet jedoch direkte LVM-Volumes (Linux Volume Manager) über das Device Mapper-Backend, um Docker-Images und -Metadaten zu speichern: / dev / atomicos / docker-data und / dev / atomicos / docker-meta. Das bedeutet, dass Sie etwas über LVM und Volumes lernen müssen, um einem Atomic-Host Speicherplatz hinzuzufügen.

Der Ausgangspunkt für die Speicherverwaltung in Atomic ist das Setup-Skript / etc / sysconfig / docker-storage-setup. Atomic Host verfügt über einen Speicherpool für Docker- (und Host-) Speicher. Der Trick besteht darin, diesem Pool ein neues Gerät hinzuzufügen. Sie tun dies, indem Sie der Liste der Geräte in der Datei Folgendes hinzufügen:

DEVS="/dev/vdb /dev/vdc"

Anschließend führen Sie das Hilfsskript / usr / bin / docker-storage-setup aus. Wenn alles gut geht, wurden Ihre Festplatten zum Pool hinzugefügt, und Ihr Atomic-Host bietet Platz für Docker. Ich nehme an, dass LVM in der Produktion mit vorhandenen Verwaltungstools oder mit Ansible / Salt / Chef / Puppet-Skripten verwaltet wird, sodass Administratoren, die in großen Rechenzentrumsumgebungen arbeiten, wahrscheinlich standardisierter erscheinen.

Project Atomic verwendet Flannel, um ein Container-Overlay-Netzwerk über Etcd bereitzustellen. Sie konfigurieren dies, indem Sie eine JSON-Konfigurationsdatei mit Tools wie Curl in den Etcd-Schlüsselwertspeicher verschieben. Um ein Subnetz für die Container zu konfigurieren, erstellen wir möglicherweise eine JSON-Datei, die folgendermaßen aussieht:

   "Netzwerk": "172.16.0.0/12",

   "SubnetLen": 24,

   "Backend": {

      "Typ": "vxlan"

   }}

}}

Und um dies in den Etcd-Master zu übertragen, drücken wir es in den Netzwerkkonfigurationsschlüssel:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Es ist zwar etwas umständlich, aber überschaubar. Ich würde gerne einen Wrapper für diese Konfigurationsbefehle , um zu sehen , dass es mehr intuitiv für das Unix - Administrator zu machen, vielleicht so etwas wie atomic ifconfig…, atomic route…etc.

Es gibt noch einen weiteren Unterschied, der hervorgehoben werden sollte: die Kubernetes-Konzepte für Pods und Services. Ein Pod ist eine Gruppe von Behältern, die relativ eng miteinander verbunden sind. Alle Container in einem Pod haben denselben Host und dieselbe IP-Adresse und leben oder sterben zusammen. Sie geben an, wie viele Instanzen eines Pods ausgeführt werden sollen, und Kubernetes führt die Bestellung aus. Wenn eine Instanz stoppt oder fehlschlägt, dreht Kubernetes eine andere, um dem gewünschten Status zu entsprechen.

Ein Kubernetes-Dienst ist eine Abstraktion, die einen logischen Satz von Pods und eine Richtlinie für den Zugriff auf diese definiert. Dies gibt einem (Mikro-) Dienst einen einzigen, stabilen Namen und eine Adresse über den gesamten Pod-Lebenszyklus hinweg. Das ist viel mehr, aber das sollte Ihnen helfen zu verstehen, warum Sie eine separate Komponente zur Verwaltung des Netzwerks benötigen. In Atomic Host ist diese Komponente Flanell.

Atomic Host Upgrades und Downgrades

Atomic Host verwendet einen Paketmanager namens RPM-OSTree, der die Funktionen des herkömmlichen RPM und OSTree kombiniert. RPM-OSTree gibt uns die Möglichkeit, zuverlässig vorwärts und rückwärts zu rollen, da der Prozess „atomar“ ist (im Sinne der Datenbank). RPM-OSTree bietet zuverlässige Transaktionen für Updates, sodass es unwahrscheinlich ist, dass das Betriebssystem beschädigt wird. Wie die Befehle für Container werden Host-Upgrades und Rollbacks vom atomicManagementsystem bereitgestellt:

atomic host upgrade

atomic host rollback

Beachten Sie, dass ich kein Rollback getestet habe, da ich nichts hatte, auf das ich zurücksetzen konnte.

Red Hat Atomic Host eignet sich am besten für Unternehmen mit hohen Investitionen in Red Hat-Kenntnisse und -Infrastruktur. Unternehmen, die aus einem anderen Blickwinkel beginnen, möchten möglicherweise andere Optionen in Betracht ziehen. Durch die Einbeziehung von Kubernetes und die Geschichte von Red Hat in großen Produktionsumgebungen wird Atomic Host fast zu einem „Drop-In“ für die Ausführung von containerisierten Workloads in Unternehmen. Aber ich sehe Entwickler nicht als Docker-Plattform ihrer Wahl.