😩 🧒🏽 👩🏽‍⚕️ Container für Erwachsene (Teil 01): Ein praktischer Leitfaden zur Terminologie 🙋 🥧 👩🏾‍🤝‍👨🏻

Sie fragen sich vielleicht, warum Sie sich mit Terminologie befassen sollten, wenn das Konzept der Container recht einfach und unkompliziert aussieht. Die falsche Verwendung von Begriffen behindert jedoch häufig die Entwicklung von Containern. Beispielsweise denken die Leute oft, dass die Begriffe „Container“ und „Bilder“ synonym verwendet werden, obwohl es tatsächlich wichtige konzeptionelle Unterschiede zwischen ihnen gibt. Ein weiteres Beispiel: In der Containerwelt bedeutet ein „Repository“ nicht, was Sie denken. Darüber hinaus ist die Containertechnologie viel mehr als nur ein Docker.

Ohne Kenntnis der Terminologie wird es schwierig sein zu verstehen, wie sich Docker von CRI-O, rkt oder lxc / lxd unterscheidet. oder bewerten Sie die Rolle der Open Container Initiative bei der Standardisierung von Containertechnologien.

Einführung

Der Einstieg in Linux-Container ist sehr einfach, aber es stellt sich bald heraus, dass diese Einfachheit irreführend ist. Dies geschieht normalerweise folgendermaßen: Nachdem Sie nur ein paar Minuten mit der Installation eines Dockers oder einer anderen Container-Engine verbracht haben, geben Sie bereits Ihre ersten Befehle ein. Nur ein paar Minuten - und Sie haben bereits Ihr erstes Bild des Containers erstellt und öffentlich zugänglich gemacht. Dann wechseln Sie gewöhnlich zur Architektur der Produktionsumgebung, und plötzlich wird Ihnen klar, dass Sie sich dafür zunächst mit der Masse der Begriffe und Technologien befassen müssen, die dahinter stehen. Schlimmer noch, viele der unten aufgeführten Begriffe werden synonym verwendet, was für Anfänger viel Verwirrung stiftet.

Behälter
Bild
Behälterbild
Bildebene
Registrierung
Repository
Tag
Basisbild
Plattformbild
Schicht

Wenn Sie die in diesem Dokument beschriebene Terminologie beherrschen, werden Sie die technologischen Grundlagen von Containern besser verstehen. Darüber hinaus können Sie und Ihre Kollegen dieselbe Sprache sprechen und die Architektur von Containerumgebungen bewusst und zielgerichtet gemäß den Besonderheiten der zu lösenden Aufgaben gestalten. Aus Sicht der IT-Community und der gesamten Branche trägt eine allgemeine Verbesserung des Verständnisses der Containertechnologien wiederum zur Entstehung neuer Architekturen und Lösungen bei. Beachten Sie, dass dieser Artikel für Leser gedacht ist, die bereits eine Vorstellung davon haben, wie Container ausgeführt werden.

Container: Grundlagen

Bevor wir mit der Terminologie von Containern fortfahren, werden wir bestimmen, was tatsächlich der Container selbst ist. Der Begriff "Container" bedeutet zwei Dinge gleichzeitig. Wie ein normales Linux-Programm kann sich ein Container in einem von zwei Zuständen befinden: funktionierend und nicht funktionierend. Im Ruhezustand ist der Container eine Datei oder eine Reihe von Dateien, die auf der Festplatte gespeichert sind. In diesem Zustand beziehen sich die Begriffe Container Image und Container Repository. Wenn Sie den Befehl zum Starten des Containers eingeben, entpackt die Container-Engine die erforderlichen Dateien und Metadaten und überträgt sie an den Linux-Kernel. Das Starten eines Containers ist dem Starten eines regulären Linux-Prozesses sehr ähnlich und erfordert einen API-Aufruf des Linux-Kernels. Dieser API-Aufruf initiiert normalerweise eine zusätzliche Isolation und stellt eine Kopie der Dateien bereit, die sich im Container-Image befinden. Nach dem Start des Containers handelt es sich nur um einen Linux-Prozess. Das Verfahren zum Starten von Containern sowie das Format der Bilder von Containern, die auf der Festplatte gespeichert sind, werden durch Standards definiert und geregelt.

Es gibt verschiedene Formate für Container-Images ( Docker , Appc , LXD ), aber die Branche bewegt sich allmählich in Richtung eines einzigen Open Container Initiative- Standards, der manchmal als Open Containers oder einfach als OCI bezeichnet wird. Dieser Standard definiert die Spezifikation des Container-Image-Formats , das das Festplattenformat zum Speichern von Container-Images definiert, sowie Metadaten, die wiederum Dinge wie die Hardwarearchitektur und das Betriebssystem (Linux, Windows usw.) definieren. Ein einziges branchenübliches Bildformat ist der Schlüssel zur Schaffung eines Software-Ökosystems, mit dem Entwickler, Open Source-Projekte und Softwareanbieter kompatible Bilder und verschiedene Tools wie elektronische Signatur, Scannen, Zusammenstellen, Starten, Verschieben und Verwalten von Container-Bildern erstellen können.

Darüber hinaus gibt es mehrere Containermotoren wie Docker , CRI-O , Railcar , RKT , LXC . Die Containermaschine nimmt ein Bild des Containers auf und verwandelt ihn in einen Container (d. H. Ein laufenden Prozess). Der Konvertierungsprozess wird auch durch den OCI-Standard definiert, der eine Container-Laufzeitspezifikation und eine Laufzeitreferenzimplementierung namens RunC enthält, ein Open-Source-Modell, das von der entsprechenden Entwicklergemeinschaft reguliert wird. Viele Container-Engines verwenden dieses Modell, um beim Erstellen von Containern mit dem Host-Kernel zu interagieren.

Tools, die die Spezifikationen des Container-Image-Formats und die Container-Ausführungsumgebung des OCI-Standards unterstützen, bieten Portabilität innerhalb des Ökosystems verschiedener Container-Plattformen, Container-Engines und unterstützender Tools auf verschiedenen Cloud-Plattformen und lokalen Architekturen. Wenn Sie die Terminologie, Standards und Architektur von Containersystemen kennen, können Sie fruchtbar mit anderen Spezialisten kommunizieren und skalierbare und unterstützte containerisierte Anwendungen und Umgebungen entwerfen, die die effiziente Nutzung von Containern über Jahre hinweg sicherstellen.

Grundwortschatz

Containerbild

In der einfachsten Definition ist ein Container-Image eine Datei, die vom Registrierungsserver heruntergeladen und beim Starten des Containers lokal als Einhängepunkt verwendet wird. Trotz der Tatsache, dass der Begriff „Container-Image“ häufig verwendet wird, kann er verschiedene Bedeutungen haben. Tatsache ist, dass Docker, RKT und sogar LXD zwar nach dem eben beschriebenen Prinzip arbeiten, dh gelöschte Dateien herunterladen und als Container ausführen. Jede dieser Technologien interpretiert das Container-Image auf ihre eigene Weise. LXD arbeitet mit monolithischen (einschichtigen) Bildern, während Docker und RKT OCI-Bilder verwenden, die mehrere Schichten enthalten können.

Genau genommen ist ein Container-Image auf einem Registrierungsserver weit von einer einzelnen Datei entfernt. Wenn Benutzer den Begriff „Container-Image“ verwenden, meinen sie häufig das Repository und eine Reihe mehrerer Ebenen des Container-Images sowie Metadaten, die zusätzliche Informationen zu diesen Ebenen enthalten.

Darüber hinaus impliziert das Konzept eines Containerbildes implizit die Existenz eines Formats für ein solches Bild.

Container-Bildformat

Anfänglich hatte jede Container-Engine, einschließlich LXD, RKT und Docker, ein eigenes Bildformat. Einige dieser Formate erlauben nur eine Ebene, während andere eine Baumstruktur aus mehreren Ebenen unterstützen. Heutzutage haben fast alle wichtigen Container-Tools und Engines auf das OCI- Format umgestellt, das festlegt, wie Ebenen und Metadaten im Container-Image angeordnet werden sollen. Im Wesentlichen definiert das OCI-Format ein Container-Image, das aus separaten TAR-Dateien für jede Ebene und einer gemeinsamen manifest.json-Datei mit Metadaten besteht.

Der Open Container Initiative (OCI) -Standard, der ursprünglich auf dem Docker V2-Bildformat basierte, hat ein großes Ökosystem von Container-Engines, Cloud-Plattformen und -Tools (Sicherheitsscanner, Signiertools, Erstellen und Verschieben von Containern) erfolgreich kombiniert und ermöglicht es Ihnen, Ihre Investitionen in Wissen und Wissen zu schützen Werkzeuge.

Containermotor

Die Container-Engine ist der Teil der Software, der Benutzeranforderungen einschließlich Befehlszeilenparametern akzeptiert, Bilder herunterlädt und aus Sicht des Endbenutzers Container startet. Es gibt viele Container-Engines, darunter Docker, RKT, CRI-O und LXD. Darüber hinaus verfügen viele Cloud-Plattformen, PaaS-Dienste und Container-Plattformen über eigene Engines, die Bilder im Docker- oder OCI-Format verstehen. Ein Industriestandard für das Bildformat gewährleistet die Interoperabilität all dieser Plattformen.

Wenn wir eine Ebene tiefer gehen, können wir sagen, dass die meisten Container-Engines Container nicht selbst starten, sondern über eine OCI-kompatible Laufzeit wie runc. In der Regel führt eine Container-Laufzeit die folgenden Aktionen aus:

Behandelt Parameter, Benutzereingaben
Behandelt die über die API übergebenen Parameter (meistens das Container-Orchestrierungssystem)
Laden Sie Container-Images vom Registrierungsserver herunter
Entpackt und speichert das Container-Image mithilfe des Grafiktreibers (Block oder Datei, je nach Treiber) auf der Festplatte.
Bereitet einen Einhängepunkt für den Container vor, normalerweise im Copy-on-Write-Speicher (wiederum Block oder Datei, je nach Treiber)
Bereitet Metadaten vor, die an die Laufzeit übergeben werden, um den Container korrekt auszuführen:
- Spezifische Standardeinstellungen, die für das Container-Image impliziert sind (z. B. ArchX86 )
- Benutzereingabe zum Überschreiben der im Container-Image enthaltenen Standardwerte (z. B. CMD, ENTRYPOINT)
- Vom Container-Image angegebene Standardparameter (z. B. SECCOM- Regeln)
Ruft die Container-Laufzeit auf

Behälter

Container gibt es in Betriebssystemen schon seit geraumer Zeit, da dies nur eine laufende Instanz eines Container-Images ist. Ein Container ist ein Standard-Linux-Prozess, der normalerweise mit dem Systemaufruf clone () anstelle von fork () oder exec () erstellt wird. Darüber hinaus werden häufig zusätzliche Isolierungsmaßnahmen auf Container angewendet, die cgroups , SELinux oder AppArmor verwenden .

Container-Host

Ein Container-Host ist ein System, auf dem containerisierte Prozesse ausgeführt werden, die der Einfachheit halber häufig als Container bezeichnet werden. Dies kann beispielsweise eine virtuelle RHEL Atomic Host- Maschine sein, die sich in einer öffentlichen Cloud befindet oder in einem Unternehmens-Rechenzentrum auf Bare-Metal-Basis ausgeführt wird. Wenn das Container-Image (mit anderen Worten das Repository) vom Registrierungsserver auf den lokalen Container-Host heruntergeladen wird, heißt es, dass es in den lokalen Cache fällt.

Mit dem folgenden Befehl können Sie bestimmen, welche Repositorys mit dem lokalen Cache synchronisiert werden:

  [root @ rhel7 ~] # Docker-Bilder -a

 REPOSITORY TAG IMAGE ID ERSTELLTE VIRTUELLE GRÖSSE
 registry.access.redhat.com/rhel7 aktuell 6883d5422f4e vor 3 Wochen 201.7 MB

Registrierungsserver

Ein Registrierungsserver ist im Wesentlichen ein Dateiserver, auf dem Docker-Repositorys gespeichert werden. In der Regel wird der Registrierungsserver durch den DNS-Namen und optional die Portnummer angegeben. Die meisten Vorteile des Docker-Ökosystems beruhen auf der Möglichkeit, Repositorys herunterzuladen und auf Registrierungsserver hochzuladen.

Wenn der Docker-Daemon keine Kopie des Repositorys im lokalen Cache findet, lädt er diese automatisch vom Registrierungsserver herunter. Bei den meisten Linux-Distributionen verwendet der Docker-Daemon die docker.io-Site dafür, bei einigen Distributionen kann sie jedoch auf eigene Weise konfiguriert werden. Beispielsweise versucht Red Hat Enterprise Linux zuerst, von registry.access.redhat.com und erst dann von docker.io (Docker Hub) herunterzuladen.

Hier muss betont werden, dass der Registrierungsserver implizit als vertrauenswürdig gilt. Daher müssen Sie entscheiden, wie sehr Sie dem Inhalt einer Registrierung vertrauen und ihn zulassen bzw. ablehnen. Neben der Sicherheit sollten noch weitere Aspekte im Voraus behandelt werden, z. B. Probleme mit der Softwarelizenzierung oder die Überwachung der Einhaltung von Vorschriften. Die Einfachheit, mit der Docker Benutzern das Herunterladen von Software ermöglicht, macht das Thema Vertrauen äußerst wichtig.

Mit Red Hat Enterprise Linux können Sie die Standard-Docker-Registrierung konfigurieren. Darüber hinaus können Sie mit RHEL7 und RHEL7 Atomic Registrierungsserver über die Konfigurationsdatei hinzufügen oder sperren:

  vi / etc / sysconfig / docker

RHEL7 und RHEL 7 Atomic verwenden standardmäßig den Red Hat-Registrierungsserver:

  ADD_REGISTRY = '- add-registry registry.access.redhat.com'

In einigen Fällen ist es aus Sicherheitsgründen sinnvoll, öffentliche Docker-Register wie DockerHub zu blockieren:

  # BLOCK_REGISTRY = '- Blockregistrierung'

Red Hat bietet auch seinen integrierten Registrierungsserver als Teil der OpenShift Container Platform sowie den eigenständigen Unternehmensregistrierungsserver Quay Enterprise und Cloud-, private und öffentliche Repositorys Quay.io an.

Container-Orchestrierung

Normalerweise installieren die Benutzer zunächst einen Container-Host und laden zunächst nur die benötigten Container-Images herunter. Anschließend erstellen sie ihre eigenen Bilder und laden sie auf den Registrierungsserver hoch, um sie dem Rest des Teams zur Verfügung zu stellen. Nach einiger Zeit müssen mehrere Container kombiniert werden, damit sie als eine Einheit bereitgestellt werden können. Und schließlich müssen diese Einheiten irgendwann Teil des Produktionsförderers sein (Entwicklungs-QS-Produktion). Auf diese Weise stellen die Menschen normalerweise fest, dass sie ein Orchestrierungssystem benötigen.

Das Container-Orchestrierungssystem implementiert nur zwei Dinge:

Containerladungen dynamisch über Clustercomputer verteilen (dies wird häufig als „verteiltes Computing“ bezeichnet)
Bietet eine Standard-Anwendungsbeschreibungsdatei (kube yaml, docker compose usw.)

Diese beiden Dinge bieten tatsächlich eine Reihe von Vorteilen:

Die Möglichkeit, die Container, aus denen die Anwendung besteht, unabhängig voneinander zu verwalten, sodass Sie die folgenden Aufgaben effektiv lösen können:
- Entsorgung großer Container-Host-Cluster
- Fehler auf der Ebene einzelner Container (nicht mehr reagierende Prozesse, Speicherauslastung)
- Failover auf Container-Host-Ebene (Laufwerke, Netzwerk, Neustart)
- Failover auf Containermotorebene (Beschädigung, Neustart)
- Individuelle Skalierung von Containern nach oben und unten
Einfache Bereitstellung neuer Instanzen derselben Anwendung in neuen Umgebungen, sowohl in der Cloud als auch in herkömmlichen Umgebungen, zum Beispiel:
- Auf Entwicklercomputern, die von einem Orchestrierungssystem gesteuert werden
- In einer gemeinsam genutzten Entwicklungsumgebung in einem privaten Namespace
- In einer gemeinsamen Entwicklungsumgebung in einem internen öffentlichen Namespace, um Transparenz und Testleistung sicherzustellen
- In der internen Umgebung der Qualitätssicherung
- In einer Testladeumgebung, die dynamisch in der Cloud bereitgestellt und widerrufen wird
- In einer Referenzumgebung, um die Kompatibilität mit der Produktionsumgebung zu überprüfen
- In der Produktionsumgebung
- In einer Disaster Recovery-Umgebung
- In einer neuen Produktionsumgebung mit aktualisierten Container-Hosts, Container-Engines oder Orchestrierungs-Tools
- In der neuen Produktionsumgebung, die sich nicht von der Hauptumgebung unterscheidet, sondern sich in einer anderen Region befindet

Open Source-Communities und Softwareanbieter bieten viele verschiedene Orchestrierungswerkzeuge an. Zu den drei großen dieser Tools gehörten ursprünglich Swarm , Mesos und Kubernetes . Heute ist Kubernetes jedoch zum Industriestandard geworden, da sogar Docker und Mesosphere ihre Unterstützung angekündigt haben, ganz zu schweigen von fast allen großen Dienstleistern. Wenn Sie jedoch nach einem Corporate Orchestration-System suchen, empfehlen wir Ihnen, sich Red Hat OpenShift genauer anzusehen.

Erweitertes Wörterbuch

Container-Laufzeit

Die Container-Laufzeit ist eine Low-Level-Komponente, die normalerweise als Teil einer Container-Engine verwendet wird, aber auch manuell zum Testen von Containern verwendet werden kann. Der OCI-Standard definiert eine Referenzimplementierung der als runc bezeichneten Laufzeit. Dies ist die am weitesten verbreitete Implementierung, es gibt jedoch auch andere OCI-kompatible Laufzeiten wie Crun , Triebwagen und Katacontainer . Docker, CRI-O und viele andere Container-Engines verwenden runc.

Die Container-Laufzeit ist für folgende Dinge verantwortlich:

Ruft den Einhängepunkt des Containers ab, der von der Container-Engine bereitgestellt wird (zum Testen kann es sich nur um ein Verzeichnis handeln).
Ruft die von der Container-Engine bereitgestellten Container-Metadaten ab (beim Testen kann es sich um eine manuell zusammengestellte Datei config.json handeln).
Kommuniziert mit dem Betriebssystemkern, um containerisierte Prozesse zu starten (über den Klonsystemaufruf).
Konfiguriert cgroups
Konfiguriert die SELinux-Richtlinie
Konfiguriert App-Rüstungsregeln

Ein kleiner historischer Exkurs: Als die Docker-Engine zum ersten Mal erschien, verwendete sie den LXC als Laufzeitumgebung. Docker-Entwickler haben dann ihre eigene Bibliothek zum Ausführen von Containern namens libcontainer geschrieben. Es wurde in der Golang-Sprache geschrieben und wurde Teil der Docker-Engine. Nach dem Aufbau der OCI-Organisation führte Docker den Quellcode libcontainer in dieses Projekt ein und veröffentlichte diese Bibliothek als separates Dienstprogramm namens runc, das dann zur Referenzimplementierung der Containerlaufzeit innerhalb des OCI-Standards wurde und in anderen Container-Engines wie CRI-O verwendet wird . Runc ist ein sehr einfaches Dienstprogramm, das nur darauf wartet, dass ein Mountpunkt (Verzeichnis) und Metadaten (config.json) an ihn übergeben werden. Weitere Informationen zu runc finden Sie hier .

Weitere Informationen finden Sie unter Grundlegendes zu Containerstandards und zur Container-Laufzeit .

Bildebenen

Repositorys werden häufig als Bilder oder Bilder von Containern bezeichnet, obwohl Repositorys tatsächlich aus einer oder mehreren Ebenen bestehen. Die Bildebenen im Repository sind durch die Eltern-Kind-Beziehungen miteinander verbunden, und jede Bildebene enthält Unterschiede zur übergeordneten Ebene.

Schauen wir uns die Repository-Ebenen auf dem lokalen Container-Host an. Da Docker ab Version 1.7 kein integriertes Tool zum Anzeigen von Bildebenen im lokalen Repository hat (es gibt jedoch Tools für Online-Registrierungen), verwenden wir das Dockviz- Dienstprogramm. Beachten Sie, dass jede Ebene ein Tag und eine universelle eindeutige Kennung (UUID) hat . Um abgekürzte UUIDs anzuzeigen, die normalerweise auf demselben Computer eindeutig sind, verwenden wir den folgenden Befehl (wenn Sie eine vollständige UUID benötigen, verwenden Sie denselben Befehl mit der Option -no-trunc):

docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock nate / dockviz images -t

  32─2332d8973c93 Virtuelle Größe: 187,7 MB
  │ └ea358092da77 Virtuelle Größe: 187,9 MB
  │ └ a467a7c6794f Virtuelle Größe: 187,9 MB
  │ └ca4d7b1b9a51 Virtuelle Größe: 187,9 MB
  │ └ 4084976dd96d Virtuelle Größe: 384,2 MB
  │ └943128b20e28 Virtuelle Größe: 386,7 MB
  │ └db20cc018f56 Virtuelle Größe: 386,7 MB
  │ └ 45b3c59b9130 Virtuelle Größe: 398,2 MB
  │ └ 91275de1a5d7 Virtuelle Größe: 422,8 MB
  │ └e7a97058d51f Virtuelle Größe: 422,8 MB
  │ └d5c963edfcb2 Virtuelle Größe: 422,8 MB
  │ └5cfc0ce98e02 Virtuelle Größe: 422,8 MB
  │ 777728f71a4bcd Virtuelle Größe: 422,8 MB
  │ └0542f67da01b Virtuelle Größe: 422,8 MB Tags: docker.io/registry:latest

Wie Sie sehen können, besteht das Repository docker.io/registry tatsächlich aus vielen Ebenen. Noch wichtiger ist jedoch, dass der Benutzer den Container im Prinzip von jedem Schritt in dieser Schrittleiter aus „starten“ kann, indem er beispielsweise den folgenden Befehl eingibt (er ist völlig korrekt, aber niemand kann garantieren, dass er getestet wurde oder überhaupt richtig funktioniert). In der Regel markiert der Bildersammler (erstellt Namen) die Ebenen, die als Ausgangspunkt verwendet werden sollen:

  Docker-Run -it 45b3c59b9130 Bash

Repositorys sind auf ähnliche Weise angeordnet, da die Unterschiede jedes Mal, wenn der Kollektor ein neues Bild erstellt, als weitere Ebene gespeichert werden. Es gibt zwei Möglichkeiten, neue Ebenen im Repository zu erstellen. Wenn Sie ein Bild manuell erstellen, erstellt jede Änderungsbestätigung zunächst eine neue Ebene. Wenn der Kollektor ein Bild mithilfe einer Docker-Datei erstellt, erstellt jede Anweisung in der Datei eine neue Ebene. Daher ist es immer nützlich zu sehen, was sich zwischen den Ebenen im Repository geändert hat.

Namespaces

– . DockerHub , , .

Red Hat , Red Hat Federated Registry . registry.access.redhat.com . , . , Red Hat , - :

 registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/openshift3/mongodb-24-rhel7
registry.access.redhat.com/rhscl/mongodb-26-rhel7
registry.access.redhat.com/rhscl_beta/mongodb-26-rhel7
registry-mariadbcorp.rhcloud.com/rhel7/mariadb-enterprise-server:10.0

, URL . . fedora, latest. :

 docker pull fedora
docker pull docker.io/fedora
docker pull docker.io/library/fedora:latest

, , . , , , , , . , , , . .

Bash Enter, Bash Linux- exec() . , , docker, docker , clone() . clone () , , , , , ..

, Linux - , clone ().

…

Container für Erwachsene (Teil 01): Ein praktischer Leitfaden zur Terminologie