Container-Images und Helm-Charts effektiv verwalten

Docker Hub, eine der populärsten öffentlichen Registries für containerisierte Anwendungen, bietet derzeit über fünf Millionen einzelne Container-Images an. Diese beeindruckende Zahl zeigt, wie wichtig Docker Hub für das Hosting von Container-Images ist, die Developer der Öffentlichkeit zur Verfügung stellen wollen.

Doch trotz der großen Popularität von Docker Hub und Docker Registries ist die Plattform nicht immer die beste Lösung für das Hosting von Container-Images. Denn manche Teams müssen Container-Images so hosten, dass sie privat bleiben oder (selbst wenn sie öffentlich sind) eine granulare Zugriffskontrolle haben, die von Docker Hub nicht unterstützt wird.

In anderen Fällen brauchen Organisationen vielleicht eine Lösung, die nicht nur Container-Images hosten kann, sondern auch Helm-Charts, die eine weitere Möglichkeit bieten, containerisierte Anwendungen an Benutzer zu distribuieren. Docker Hub unterstützt keine Helm-Charts.

Um Sie bei der Auswahl der besten Container-Registry– oder Helm-Chart-Repository-Lösung für Ihre Anforderungen zu unterstützen, geht dieser Artikel auf die wichtigsten Aspekte und Best Practices zur Verwaltung von Helm-Charts und Container-Images ein.

Was sind Container-Images?

Container-Images sind die Vorlagen, die zum Starten einer Anwendung verwendet werden, die in einem Container läuft. Wenn Sie eine Applikation haben, die Sie in einem Container ausführen möchten, erstellen Sie ein Container-Image dafür. Wenn Sie die Anwendung ausführen möchten (oder sie jemand anderem zur Verfügung stellen wollen), laden Sie das Image auf einen beliebigen Computer herunter, der als Host für den Container dient, und starten die darauf basierenden Container.

Container-Images werden manchmal auch als Docker-Images bezeichnet, da die meisten von ihnen für die Ausführung mit Docker konzipiert sind. Technisch gesehen ist Docker jedoch nur eine von mehreren Plattformen, die Container unterstützen.

Container-Images werden in der Regel in Container-Registries gehostet, d. h. in Repositories, von denen die Images heruntergeladen werden können. Registries können öffentlich sein, d. h. jeder kann Images von ihnen herunterladen, oder sie können als privat konfiguriert werden, wobei der Zugang auf bestimmte Gruppen beschränkt ist.

Was sind Helm-Charts?

Helm-Charts sind Pakete, die automatisch Software auf Kubernetes installieren und konfigurieren. Sie werden von Helm verwaltet, einem Open-Source-Paketmanager, der die Softwareverwaltung für Kubernetes vereinfachen soll.

In vielerlei Hinsicht sind Helm-Charts für Kubernetes das, was Debian- oder Yum-Pakete für Linux und MSI-Dateien für Windows sind. Sie enthalten alle Informationen, die für die Installation und Konfiguration einer Anwendung erforderlich sind, damit diese auf eine bestimmte Weise ausgeführt werden kann.

Helm-Charts unterscheiden sich jedoch ein wenig von anderen Arten von Softwarepaketen. Sie enthalten in der Regel keine Anwendungs-Binaries, sondern Anweisungen, die Kubernetes mitteilen, wo die Container-Images zu finden sind, die es für die Ausführung einer bestimmten Anwendung benötigt. Ein weiteres besonderes Merkmal von Helm-Diagrammen ist, dass mit einem einzigen Chart mehrere Anwendungen installiert werden können.

Wenn Sie z. B. einen Webserver und eine dazugehörige Datenbank aufsetzen müssen, können Sie dies über ein einziges Helm-Diagramm tun.

Helm-Charts vs. Container-Images

Container-Images und Helm-Charts sind zwar beides Lösungen für die Installation und den Betrieb von Container-Applikationen, aber es gibt wesentliche Unterschiede zwischen ihnen. Der größte ist, dass mit Container-Images nur eine Applikation (oder in einigen Fällen ein Teil einer Applikation) bereitgestellt wird, nicht aber die für den Betrieb notwendigen Konfigurationsdaten. Das Herunterladen eines Container-Images ist vergleichbar mit dem Herunterladen einer binären Anwendung auf Ihren Computer (im Gegensatz zum Herunterladen eines Pakets oder Installationsprogramms für die Anwendung): Sie erhalten die Anwendung selbst, aber wenn Sie sie ausführen möchten, müssen Sie sie manuell konfigurieren und starten.

Helm-Diagramme sind eher mit einem vollständigen Software-Installationspaket vergleichbar. Wenn Sie ein Helm-Diagramm ausführen, werden nicht nur die Anwendungs-Binärdateien installiert, sondern auch alle für die Ausführung der Applikation erforderlichen Konfigurationsdaten.

Die größte Einschränkung von Helm-Charts besteht darin, dass sie nur für die Installation von Software auf Kubernetes funktionieren. Ein Container-Image kann zwar auch auf Kubernetes ausgeführt werden, aber auch in jedem anderen System, in dem eine kompatible Container-Runtime (die Anwendung, die Container ausführt) installiert ist.

Best Practices für die Verwaltung von Helm-Diagrammen und Container-Images

Der einfachste Weg, Container-Images und Helm-Diagramme für die Nutzung verfügbar zu machen, besteht darin, sie in einem Registry oder Repository zu hosten, von dem Nutzer sie herunterladen können. Container-Registries und Helm-Chart-Repositories sind vergleichbar mit einem App-Store: Es sind Orte, an denen Nutzer ein Container-Image oder ein Helm-Diagramm für die Applikation, die sie ausführen möchten, finden und diese dann herunterladen und ausführen können.

Die Möglichkeit, Container-Images und Helm-Diagramme auf diese Weise zu verteilen, ist einer der Gründe, warum diese Ressourcen so nützlich sind. Wenn alle Container-Images und Helm-Diagramme von einem zentralen Ort aus zugänglich sind, ist es einfach, sie in automatisierte Pipelines zu integrieren und eine große Zahl von Nutzern zu unterstützen.

Um den maximalen Nutzen aus den Container-Image-Registries und Helm-Chart-Repositories zu ziehen, ist es wichtig, dass Sie Ihre Images und Charts auf eine Weise verwalten, die Ihren Anforderungen entspricht.

Verwenden Sie keine öffentlichen Repositories

Es mag verlockend sein, Images und Charts in öffentlichen Repositories zu speichern, wo sie für jeden frei zugänglich sind und Sie sich nicht um die Konfiguration der Zugriffskontrolle kümmern müssen. Wenn Sie jedoch Applikationen bereitstellen, die nur für den internen Gebrauch bestimmt sind, sollten Sie ein privates Repository verwenden, auf das nur von Ihnen festgelegte Benutzer zugreifen können.

Und machen Sie nicht den Fehler, davon auszugehen, dass das Hosting eines öffentlichen Repositorys unter einer privaten URL ausreicht, um es vor unbefugtem Zugriff zu schützen. Vine hat diese Lektion auf die harte Tour gelernt, als jemand die URL eines vermeintlich privaten Container-Image-Repositorys erraten hat.

Sie sollten stets wissen, was sich in Ihren Repositories befindet

Die Vine-Geschichte ist auch eine Warnung, dass es wichtig ist, zu wissen, welche Daten sich tatsächlich in Ihren Repositories befinden. Im Generell ist es nicht sehr sinnvoll, Daten wie Quellcode in einer vermeintlichen Container-Registry zu speichern. Auch wenn Sie in manchen Fällen andere Arten von Artefakten (d.h. jede Art von Binärdateien oder Daten) neben Helm-Charts und Container-Registries speichern möchten, sollten Sie zumindest den Überblick darüber behalten, was wo gespeichert ist, um Sicherheitslücken zu vermeiden.

Granulare Zugriffskontrolle

Manchmal möchten Sie, dass bestimmte Container-Images oder Helm-Charts öffentlich zugänglich sind, während andere privat bleiben sollen. Vielleicht haben Sie z.B. eine Open-Source-Anwendung, die Sie für die Allgemeinheit bereitstellen wollen, während andere Images oder Diagramme für proprietäre, unternehmensinterne Software bestimmt sind. Oder einige Images sollen nur für eine Abteilung innerhalb Ihres Unternehmens zugänglich sein, während andere Images für eine andere Abteilung bestimmt sind.

In einem solchen Szenario ist es von Vorteil, ein Repository zu wählen, das granulare Zugriffskontrolle unterstützt, so dass Sie genau definieren können, wer welche Rechte an den einzelnen Elementen im Repository hat.

Versionskontrolle

Obwohl die meisten Benutzer die neueste Version Ihrer Anwendungen herunterladen möchten, gibt es viele Situationen, in denen ältere Versionen benötigt werden. Beispielsweise kann ein Kompatibilitätsproblem den Einsatz der neuesten Version in einer bestimmten Umgebung blockieren, oder die neueste Version ist noch nicht vollständig getestet. Um sicherzustellen, dass Ihre Nutzer stets genau die Container-Image- oder Helm-Chart-Version herunterladen können, die sie gerade brauchen, können Sie in Ihrem Repository eine Versionsverwaltung einrichten.

Halten Sie Ihre Images und Helm-Charts klein und übersichtlich

Im Normalfall ist es am besten, für jede Anwendung oder jeden Microservice, den Sie zur Verfügung stellen möchten, ein eigenes Container-Image oder Helm-Chart zu verwenden. Es ist zwar möglich, mehrere Anwendungen oder Services in einem einzigen Image oder Chart zusammenzufassen, doch kann dies zu aufgeblasenen Paketen führen, die schwieriger zu verwenden sind.

Das Schöne an einem zentralen Repository ist, dass es so viele einzelne Objekte effizient hosten und verwalten kann, wie Sie brauchen. Machen Sie sich diese Eigenschaft zunutze, indem Sie Ihre Images und Charts kompakt halten, auch wenn das bedeutet, dass Sie mehr davon verwalten müssen.

Zusammenfassung

Container-Images und Helm-Diagramme sind nützliche Tools zur einfacheren Bereitstellung von containerisierten Software-Anwendungen. Um den maximalen Nutzen aus ihnen zu ziehen, sollten sie jedoch in einem Repository gehostet werden, das das für Ihr Unternehmen erforderliche Maß an Zugriffskontrolle, Versionskontrolle und Administrierbarkeit bietet.

JFrog Artifactory bietet eine sichere Lösung, die sowohl als Docker-Image-Registry als auch als Helm-Chart-Repository fungieren kann. Unabhängig davon, wie viele Images oder Charts Sie zu verwalten haben oder welche Arten von Bereitstellungs- und Installations-Tools Sie integrieren müssen, bietet Artifactory eine flexible Lösung zur Verwaltung aller Daten, die den Softwarebereitstellungs-Prozess Ihres Teams steuern.