Es gibt viele Vorlagen für den Containeraufbau. Ein Container ist nur eine ausführbare Version seines eigenen Images. Daher hängt die Art und Weise, wie ein Container erstellt wird, eng davon ab, wie er beginnt.
Einige Container-Images funktionieren ohne besondere Berechtigungen, andere erfordern Root-Berechtigungen. Darüber hinaus kann dasselbe Bild / Container mehrere Konstruktionsmuster und Verwendungsszenarien gleichzeitig kombinieren.
Im Folgenden werden die häufigsten Anwendungsfälle für Container betrachtet.
(Eine Einführung in die Containerterminologie finden Sie in
Teil 1 )
Container-Verwendungsszenarien
Anwendungsbehälter
Anwendungscontainer sind die am häufigsten verwendeten Containertypen. Entwickler und Anwendungsbesitzer kümmern sich um sie und sie selbst enthalten den Quellcode sowie Dinge wie MySQL, Apache, MongoDB und Node.js.
Es entsteht ein riesiges Ökosystem von Anwendungscontainern. Projekte wie Software Collections bieten sichere und unterstützte Anwendungscontainer-Images für Red Hat Enterprise Linux. Gleichzeitig entwickeln und unterstützen Mitglieder der Red Hat-Community innovative Anwendungscontainer.
Wir bei Red Hat glauben, dass Anwendungscontainer normalerweise keine besonderen Berechtigungen benötigen. Beim Erstellen von Containerproduktionsumgebungen sind jedoch andere Container erforderlich.
Betriebssystemcontainer
Der Container des Betriebssystems ist ein Container, der viel mehr einem vollwertigen virtuellen Betriebssystem ähnelt. Solche Container verwenden auch den Host-Kernel, führen jedoch das vollständige Init-System aus, wodurch sie problemlos mehrere Prozesse ausführen können. Beispiele für Betriebssystemcontainer sind LXC und LXD.
Die Container des Betriebssystems können im Prinzip mithilfe von Docker- / OCI-Containern emuliert werden, vorausgesetzt, Sie können das System in ihnen ausführen, sodass der Endbenutzer Software in solchen Containern auf die übliche Weise installieren und sie als vollwertiges virtuelles Betriebssystem wahrnehmen kann.
yum install mysql systemctl enable mysql
Dies vereinfacht die Containerisierung vorhandener Anwendungen erheblich. Red Hat arbeitet hart daran, Betriebssystemcontainer zu vereinfachen, indem systemd im Container ausgeführt und der bearbeitete Daemon verwendet wird. Obwohl viele Kunden noch nicht für die Microservice-Architektur bereit sind, kann der Übergang zu einem containerisierten Software-Bereitstellungsmodell, das auf Container-Images basiert, ihnen viele Vorteile bieten.
Haustierbehälter
Obwohl Red Hat die Verwendung von
Cloud-basierten Vorlagen bei der Entwicklung neuer Anwendungen nachdrücklich empfiehlt, fördert und unterstützt, sind wir uns bewusst, dass nicht alle vorhandenen Anwendungen auf diese Weise neu geschrieben werden. Insbesondere, weil viele von ihnen so einzigartig und unnachahmlich sind, dass sie im Vergleich zu Standardanwendungen wie Haustiere (
Haustiere ) gegen eine Herde Kühe aussehen. Für solche Anwendungen werden spezielle
Haustierbehälter entwickelt.
Haustiercontainer kombinieren die Portabilität und den Komfort einer Containerinfrastruktur, die auf Registrierungsservern, Containerbildern und Containerhosts basiert, mit der Flexibilität einer herkömmlichen IT-Umgebung, die in einem separaten Container implementiert ist. Hier geht es darum, die Containerisierung vorhandener Anwendungen zu vereinfachen
, da systemd im Container zur Verwendung vorhandener Automatisierungstools, Softwareinstallationen und anderer Tools verwendet werden kann, um auf einfache Weise containerfähige Images für den Start zu erstellen.
Super Privilege Container
Beim Aufbau einer Containerinfrastruktur auf der Basis dedizierter Containerhosts wie Red Hat Enterprise Linux Atomic Host müssen Systemadministratoren diese noch verwalten.
Super Privileged Containers (SPCs) erweisen sich in solchen verteilten Umgebungen als sehr nützlich, sei es Kubernetes, OpenShift oder sogar eigenständige Container. SPCs können sogar spezielle Kernelmodule wie systemtap laden.
In der Infrastruktur, die zum Ausführen von Containern erstellt wurde, benötigen Administratoren wahrscheinlich SPC-Container, um Aufgaben wie Überwachung, Sicherung usw. auszuführen. Es ist wichtig zu verstehen, dass Administratoren SPC-Container normalerweise viel stärker mit dem Host-Kern verbunden sind Achten Sie bei der Auswahl von Host-Betriebssystemen besonders auf Zuverlässigkeits- und Standardisierungsprobleme, insbesondere in großen Cluster- und verteilten Umgebungen, die die Fehlerbehebung erschweren. Darüber hinaus müssen Administratoren sicherstellen, dass der Benutzerbereich innerhalb der SPC mit dem Hostkern kompatibel ist.
Tools und Systemsoftware
Linux-Distributionen versorgten den Benutzer immer mit Systemsoftware wie Rsyslogd, SSSD, sadc usw. Traditionell wurde diese Software in Form von RPM- oder DEB-Paketen installiert, aber mit dem Aufkommen von Container-Verpackungsformaten wurde die Installation mit Container-Images einfacher und bequemer. Insbesondere bietet Red Hat Dinge wie vorgefertigte Container wie die Red Hat-Virtualisierungstools, rsyslog, sssd und sadc.
Containerarchitektur
Mit zunehmender Dynamik der Bereitstellung von containerisierter Software entstehen neue Muster für das Containerdesign. In diesem Abschnitt werden wir über einige von ihnen sprechen.
Die Art und Weise, wie der Container auf der Festplatte gespeichert wird (dh das Format des Bildes), kann sich stark auf den Start auswirken. Beispielsweise muss ein Container, der für die Ausführung von sssd ausgelegt ist, bei jedem Start über spezielle Berechtigungen verfügen, da er sonst seine Aufgabe nicht ausführen kann. Im Folgenden werden kurz die Hauptmuster betrachtet, die sich derzeit in der Phase der aktiven Bildung befinden.
Anwendungsbilder
Mit diesen Bildern beschäftigen sich Endbenutzer. Die Szenarien für die Verwendung solcher Images reichen von DBMS und Webservern bis hin zu einzelnen Anwendungen und Servicebussen. Diese Bilder können entweder intern von der Organisation erstellt oder von Softwareanbietern bereitgestellt werden. Daher beziehen sich Endbenutzer häufig mit Vorsicht und Sorgfalt auf den Inhalt solcher autonomen Container. Obwohl dies die einfachste Option für den Endbenutzer von Containern ist, sind eigenständige Images viel schwieriger zu entwerfen, zu erstellen und zu patchen.
Grundlegende Bilder
Ein Basisbild ist eine der einfachsten Arten von Bildern. Menschen können diesen Begriff jedoch mit einer Vielzahl von Dingen bezeichnen, z. B. einer Standard-Unternehmensversammlung oder sogar einem Anwendungsimage. Obwohl es sich streng genommen nicht um einfache, sondern um Zwischenbilder handelt.
Stellen Sie also einfach klar, dass das Basisbild ein Bild ist, das keine übergeordnete Ebene hat. Grundlegende Images enthalten normalerweise eine saubere Kopie des Betriebssystems sowie die Tools, die zum Installieren von Softwarepaketen oder zum späteren Aktualisieren des Images erforderlich sind (yum, rpm, apt-get, dnf, microdnf). Grundlegende Bilder können vom Endbenutzer manuell erfasst werden. In der Praxis werden sie jedoch normalerweise von Entwicklungsgemeinschaften (z. B. Debian, Fedora oder CentOS) oder Softwareanbietern (z. B. Red Hat) erstellt und freigegeben. Der Ursprung des Basisimages ist für die Sicherheit von entscheidender Bedeutung. Zusammenfassend ist der Haupt- und einzige Zweck des Grundbildes, eine Grundlage bereitzustellen, auf deren Grundlage Sie Ihre untergeordneten Bilder erstellen können. Bei Verwendung von Dockerfile erfolgt die Auswahl des zugrunde liegenden Basisimages explizit:
FROM registry.access.redhat.com/rhel7-atomic
Builder-Bilder
Dies ist ein spezieller Bildtyp, auf dessen Grundlage untergeordnete Bilder von Anwendungscontainern erstellt werden. Builder-Images enthalten alles außer dem von den Entwicklern geschriebenen Quellcode, nämlich Betriebssystembibliotheken, Sprachlaufzeiten, Middleware und
Source-to-Image- Tools.
Beim Start ruft das Builder-Image den von den Entwicklern geschriebenen Anwendungsquellcode auf und erstellt ein untergeordnetes Image des Anwendungscontainers, das zum Starten bereit ist und dann in einer Entwicklungs- oder Produktionsumgebung ausgeführt werden kann.
Angenommen, die Entwickler haben den PHP-Code für die Anwendung geschrieben und möchten ihn im Container ausführen. Dazu nehmen sie einfach das Builder-Image von PHP und übergeben ihm die URL auf der GitHub-Website, auf der ihr Code gespeichert ist. Als Ergebnis erhalten Entwickler ein Anwendungscontainer-Image zum Start bereit, das Red Hat Enterprise Linux, PHP aus den Software-Sammlungen und natürlich den PHP-Quellcode für die Anwendung enthält.
Builder-Images sind eine leistungsstarke, einfache und schnelle Möglichkeit, Quellcode in einen Container zu verwandeln, der auf vertrauenswürdigen Komponenten basiert.
Containerisierte Komponenten
Ein Container soll in erster Linie als Komponente eines größeren Softwaresystems und nicht als eigenständige Einheit bereitgestellt werden. Dafür gibt es zwei Hauptgründe.
Erstens erhöht die Microservice-Architektur die Wahlfreiheit der Komponenten und führt auch zu einer Erhöhung der Anzahl der Komponenten, aus denen Anwendungen und Softwaresysteme bestehen. Containerisierte Komponenten helfen dabei, solche Systeme schneller und einfacher bereitzustellen. Containerbilder erleichtern beispielsweise die Lösung des Problems der Koexistenz verschiedener Versionen derselben Komponente. Anwendungsdefinierende Tools wie
Bereitstellungen yaml / json in Kubernetes / OpenShift,
Open Service Broker ,
OpenShift-Vorlagen und
Helmdiagramme ermöglichen die Erstellung
allgemeiner Anwendungsbeschreibungen.
Zweitens können bei weitem nicht immer alle Teile eines Softwaresystems leicht containerisiert werden. Daher ist es sinnvoll, die Containerisierung nur für einzelne Komponenten durchzuführen, die dafür am besten geeignet oder hinsichtlich der Ergebnisse am vielversprechendsten sind. In Multiservice-Anwendungen kann ein Teil der Services als Container bereitgestellt werden, der andere Teil mit herkömmlichen Methoden wie RPM oder Installationsskripten (siehe Haustiercontainer). Darüber hinaus kann es schwierig sein, einige Komponenten zu containerisieren, da sie schlecht in Komponenten unterteilt sind oder an eine spezielle Hardware gebunden sind oder Kernel-API-Aufrufe auf niedriger Ebene usw. verwenden. Daher in einem großen Softwaresystem höchstwahrscheinlich Es wird Teile geben, die containerisiert werden können, und Teile, die nicht containerisiert werden können. Containerisierte Komponenten können containerisiert und bereits containerisiert werden. Containerisierte Komponenten können als Teil einer bestimmten Anwendung und nicht für sich selbst ausgeführt werden. Es ist wichtig zu verstehen, dass sie nicht für den autonomen Betrieb vorgesehen sind, da sie nur als Teil eines größeren Softwaresystems nützlich und isoliert davon praktisch unbrauchbar sind.
In OpenShift Enterprise 3.0 wurde beispielsweise der größte Teil des Hauptcodes mithilfe von RPM bereitgestellt. Nach der Installation stellten Administratoren den Router und die Registrierung als Container bereit. OpenShift 3.1 führte die containerisierte Bereitstellungsoption für Master, Node, openvswitch und etcd ein. Nach der Installation konnten Administratoren auch elasticsearch, fluentd und kibana als Container bereitstellen.
Obwohl das OpenShift-Installationsprogramm noch Änderungen am Server-Dateisystem vornimmt, können alle wichtigen Softwarekomponenten jetzt mithilfe von Container-Images installiert werden. Daher sollten diese containerisierten Komponenten, z. B. eine in OpenShift eingebettete Instanz des etcd-Images, niemals zum Speichern des Quellcodes der Anwendung verwendet werden, mit der Ihre Kunden arbeiten, nur weil diese containerisierten Komponenten als Teil ausgeführt werden sollen OpenShift Container Platform.
In neuen Versionen von OpenShift verstärkt sich der Trend zur Komponentencontainerisierung nur, und andere Softwareentwickler verwenden diesen Ansatz zunehmend.
Deployer-Images
Das Deployer-Image ist eine spezielle Art von Container, der beim Start andere Container bereitstellt oder verwaltet. Mit Deployer können Sie komplexe Bereitstellungsschemata implementieren, z. B. Container in einer bestimmten Reihenfolge starten oder beim ersten Start einige Aktionen ausführen, z. B. das Generieren eines Datenschemas oder das anfängliche Füllen der Datenbank.
In OpenShift wird beispielsweise die Vorlage "Bild- / Containertyp" zum Bereitstellen von Protokollen und Metriken verwendet. Durch die Bereitstellung dieser Komponenten mithilfe von Deployer-Images können OpenShift-Ingenieure die Reihenfolge steuern, in der die verschiedenen Komponenten ausgeführt werden, und überprüfen, ob sie ordnungsgemäß funktionieren.
Zwischenbilder
Ein Zwischenbild ist ein Bild eines Containers, das auf einem Basisbild basiert. Kernel-Assemblys, Middleware und Sprachlaufzeiten werden normalerweise als zusätzliche Ebenen über dem Basis-Image implementiert und dann in der FROM-Direktive mit diesem Basis-Image angegeben. Zwischenbilder werden normalerweise nicht alleine verwendet, sondern als Bausteine für die Erstellung eines autonomen Bildes.
Verschiedene Bildebenen sind in der Regel in verschiedenen Gruppen von Spezialisten beschäftigt. Beispielsweise sind Systemadministratoren für die Kernel-Assembly-Schicht und Entwickler für die Middleware-Schicht verantwortlich. Gleichzeitig fungieren die zugrunde liegenden Ebenen, die von einem Team erstellt wurden, als Zwischenbild für diejenigen, die für Ebenen höherer Ebene verantwortlich sind. Obwohl manchmal solche Zwischenbilder autonom verwendet werden können, insbesondere beim Testen.
Mehrzweckbilder (intermodal)
Mehrzweckcontainerbilder sind Bilder mit einer Hybridarchitektur. Beispielsweise können viele der Bilder in Red Hat Software Collections auf zwei Arten verwendet werden. Erstens als reguläre Anwendungscontainer mit vollem Ruby on Rails- und Apache-Server. Zweitens können Sie sie als Builder-Images für die OpenShift Container Platform verwenden und untergeordnete Images erstellen, die Ruby on Rails, Apache und den Anwendungscode enthalten, den Sie beim Erstellen eines solchen untergeordneten Images an den
Quell-Image- Prozess übergeben haben.
Beachten Sie, dass Mehrzweckbilder immer beliebter werden, da Sie damit zwei grundlegend unterschiedliche Aufgaben mit demselben Bild lösen können.
Systemcontainer
Bei der Bereitstellung von Systemsoftware in Form von Containern sind für letztere häufig Superuser-Berechtigungen erforderlich. Um diese Bereitstellungsoption zu vereinfachen und sicherzustellen, dass solche Container vor der Containerlaufzeit und dem Orchestrierungssystem gestartet werden, hat Red Hat eine spezielle Vorlage namens
Systemcontainer entwickelt . Diese Container werden während des Startvorgangs des Betriebssystems mit systemd und dem Befehl atomic gestartet, wodurch sie unabhängig von Laufzeit- oder Container-Orchestrierungssystemen sind. Heute bietet Red Hat Systemcontainer für rsyslog, cockpit, etcd und flanneld an und wird diese Liste in Zukunft erweitern.
Systemcontainer vereinfachen das selektive Hinzufügen dieser Dienste zu Red Hat Enterprise Linux und Atomic Host erheblich.
Fazit
Container scheinen für den Endverbraucher eine ziemlich einfache Sache zu sein, aber beim Aufbau einer Containerproduktionsumgebung stellen sich viele Fragen. Um die Architektur und Methoden zum Aufbau solcher Umgebungen fruchtbar zu diskutieren, ist für alle Teilnehmer eine einheitliche Terminologie erforderlich. Je mehr Sie sich mit dem Entwurf und der Konstruktion solcher Umgebungen befassen, desto mehr Fallstricke entstehen. Schließlich erinnern wir uns nur an einige von ihnen.
Der Unterschied zwischen den Begriffen "Container-Image" und "Repository" wird häufig nicht erkannt, insbesondere wenn sie in Docker-Befehlen verwendet werden. Wenn Sie die Befehle jedoch verwenden können, ohne die Unterschiede zu verstehen, müssen Sie bei der Arbeit an der Architektur von Containerumgebungen klar verstehen, dass das Repository tatsächlich die Hauptdatenstruktur ist.
Es ist auch ziemlich leicht, den Unterschied zwischen Namespaces, Repositorys, Bildebenen und Tags falsch zu verstehen. Jedes dieser Dinge hat seinen Zweck in der Containerarchitektur. Und obwohl Lieferanten und Anwender sie für eine Vielzahl von Zwecken verwenden, sind sie nur Werkzeuge.
Der Zweck dieses Artikels besteht darin, Ihnen das Verständnis der Terminologie zu erleichtern, damit Sie erweiterte Architekturen erstellen können. Stellen Sie sich zum Beispiel vor, Sie wurden gerade mit der Entwicklung einer Infrastruktur beauftragt, die die Verfügbarkeit von Namespaces, Repositorys und Tags und Layern je nach Rollen und Geschäftsregeln einschränken soll. Und das letzte - denken Sie daran, dass die Art und Weise, wie der Container zusammengesetzt wird, maßgeblich davon abhängt, wie er gestartet wird (Orchestrierung, Berechtigungen usw.).