Zwar ist das nicht immer der Fall, aber es gibt Umstände, bei denen es wichtig ist, Docker und andere Container zu sichern, um kostspielige Verluste zu vermeiden. [...]
Weltweit werden Backups von Containern zerstört, doch es gibt Schritte, die Sie ergreifen können, um sicherzustellen, dass die wichtigsten Teile Ihrer Container-Infrastruktur vor den schwersten Schäden, die Ihrem Rechenzentrum passieren können, geschützt sind.
Auf den ersten Blick mag es so aussehen, dass Container nicht gesichert werden müssen; bei genauerem Hinsehen macht es jedoch Sinn, um sich vor Katastrophen und anderen, weniger verheerenden Ereignissen zu schützen.
Container-Grundlagen
Container sind eine weitere Art der Virtualisierung, und Docker ist die beliebteste Container-Plattform. Container sind spezialisierte Umgebungen, in denen Sie eine bestimmte Anwendung ausführen können. Man kann sie sich wie leichtgewichtige virtuelle Maschinen vorstellen. Wenn jede VM auf einem Hypervisor-Server eine vollständige Kopie eines Betriebssystems enthält, teilen sich Container das zugrunde liegende Betriebssystem, und jede von ihnen enthält nur die erforderlichen Bibliotheken, die von der Anwendung benötigt werden, die in diesem Container ausgeführt werden soll. Folglich benötigen viele Container auf einem einzigen Knoten (eine physische oder virtuelle Maschine, auf der ein Betriebssystem und die Container-Laufzeitumgebung ausgeführt werden) weit weniger Ressourcen als die gleiche Anzahl von VMs.
Ein weiterer Unterschied zwischen VMs und Containern besteht darin, dass bei Unternehmen, die viele Anwendungen gleichzeitig in einer einzigen VM ausführen, Container typischerweise so konzipiert sind, dass sie jeweils eine einzelne Anwendungskomponente bedienen, die typischerweise eine einzige Aufgabe wie z.B. die Protokollierung oder Überwachung übernimmt. Wenn mehrere Anwendungskomponenten interagieren müssen, läuft jede in der Regel in einem eigenen Container und kommuniziert über das Netzwerk. Dies ermöglicht eine individuelle Skalierung jeder Anwendung und bietet eine gewisse Fehler- und Sicherheitsisolierung zwischen den Anwendungen.
Während VMs so konzipiert sind, dass sie innerhalb eines bestimmten Hypervisors auf einer bestimmten Hardware ausgeführt werden, sind Container viel portabler. Container sind so ausgelegt, dass sie auf praktisch jedem Linux-System ausgeführt werden können, und können sogar unter Windows laufen, wenn die entsprechende Software installiert ist. Schließlich sind Container so konstruiert, dass sie viel temporärer sind als VMs. Wo eine typische VM über Monate oder sogar Jahre laufen kann, leben 95% aller Container weniger als eine Woche, so eine aktuelle Sysdig-Umfrage.
Der Betrieb vieler Container in einer Produktionsumgebung erfordert eine Orchestrierung, und genau hier kommt Kubernetes (oft K8s geschrieben) ins Spiel. Es gruppiert Container in Pods, die ein weiterer Container sind, der einen einzigen Zweck erfüllt: Die Container in einem Pod können leicht miteinander kommunizieren und können sich den Speicherplatz teilen, indem sie ein gemeinsames Volumen aufbauen.
Wie Container Backups zerstören
In der Vergangenheit wurden Backups durchgeführt, indem ein Agent auf einem Server platziert wurde, der gesichert werden musste. Die Virtualisierung brach dieses Modell auf, so dass ein anderes Modell entstand, bei dem der Agent auf Hypervisor-Ebene ausgeführt wird und die VMs als Images sichert. Container bieten keine dieser beiden Möglichkeiten.
Zwar könnte man theoretisch einen Agenten in einem Container-Image platzieren, aber diese Vorgehensweise wird aus vielen Gründen als sehr schlecht angesehen, so dass das eigentlich niemand tut. Außerdem gibt es derzeit keine Möglichkeit, einen Agenten auf der Container-Laufzeitebene zu betreiben, was analog zur Hypervisor-Ebene funktioniert. Schließlich scheint die Idee, Container zu sichern, vielen Anwendern eher fremd zu sein. Denken Sie daran, die meisten Container leben weniger als eine Woche.
Warum Container gesichert werden müssen
In gewisser Weise muss ein typischer Container nicht in seinem Betriebszustand gesichert werden; er ist nicht einzigartig genug, um einen solchen Vorgang zu rechtfertigen. Außerdem sind die meisten Container zustandslos – es sind keine Daten im Container gespeichert. Es handelt sich lediglich um eine weitere laufende Instanz eines bestimmten Container-Images, die bereits über eine andere Operation gespeichert wurde.
Viele Befürworter von Containern weisen sofort darauf hin, dass hohe Verfügbarkeit in jedem Teil der Container-Infrastruktur verankert ist. Kubernetes wird immer in einem Cluster betrieben. Container werden immer erzeugt und bei Bedarf gelöscht. Leider verwechseln viele diese hohe Verfügbarkeit mit der Fähigkeit, sich nach einer Katastrophe ebenso schnell zu erholen.
Um das Thema zu wechseln, fragen Sie jemanden, wie er seine gesamte Kubernetes- und Docker-Umgebung replizieren würde, wenn etwas den gesamten Cluster, die Container-Knoten und den zugehörigen persistenten Speicherplatz auslöschen würde. Ja, es gibt Gründe dafür, dass Kubernetes, Docker und zugehörige Anwendungen gesichert werden müssen.
Erstens, um sich von Katastrophenfällen zu erholen. Was tun Sie, wenn das Schlimmste passiert? Zweitens, um die Umgebung zu replizieren, wie beim Übergang von einer Test-/Dev-Umgebung zur Produktion oder von der Produktion zum Staging vor einem Upgrade. Und drittens, um einen Kubernetes-Cluster leichter zu migrieren.
Was würden Sie im Falle einer Katastrophe brauchen?
Es gibt mehrere Dinge, die Sie benötigen würden, um im Katastrophenfall eine ganze Umgebung zu replizieren:
Container-Images – Ein Container-Image ist eine statische Datei, die den gesamten ausführbaren Code enthält, der für die Ausführung eines Containers erforderlich ist. Container-Images ändern sich nicht; sie sind das, was zum Betrieb eines bestimmten Containers verwendet wird. Wenn Änderungen an den Libraries und dem Code für einen bestimmten Container vorgenommen werden müssen, wird ein neues Image für diesen Container erstellt. Container-Images müssen auf irgendeine Weise geschützt werden, oft unter Verwendung eines Repositorys für solche Dinge. Im Gegenzug sollte dieses Repository wiederum gegen Katastrophen geschützt werden.
Attached Storage, Datenbanken – Container erzeugen oft Daten, die die Lebensdauer des Containers überdauern. Um das zu erreichen, laden Sie ein Volumen über NFS, einen Objektspeicher oder einen ähnlichen Mechanismus und schreiben Daten auf dieses Volumen. Es kann auch eine Verbindung zu einer Datenbank herstellen.
Persistent Volumes – Kubernetes Pods verwenden zunehmend persistenten Speicher. Diese Daten sollten auch gesichert werden, wenn die darauf gespeicherten Daten für das Unternehmen wertvoll sind.
Deployments – Ein Deployment ist ein Kubernetes-Konzept, bei dem eine Reihe von Pods eine bestimmte Funktion erfüllen. Deployments werden als YAML-Dateien gespeichert, die ebenfalls gesichert werden müssen.
Kubernetes etcd – Die zentrale Datenbank von Kubernetes ist etcd und muss daher gesichert werden. Sie ist relativ klein, und K8s stellt Ihnen Tools zur Verfügung, um ihren Inhalt in eine Datei zu schreiben, die Sie dann sichern können.
Prometheus – Prometheus wird oft zur Überwachung von K8s und Docker verwendet. Seine Konfiguration sollte ebenfalls gesichert werden.
Kubernetes-Ressourcen – Wenn Entwickler Ressourcen in K8s erstellen, müssen diese Ressourcen mit der richtigen Gruppe und Version gesichert werden.
Was sollte keine Sicherung benötigen?
Nicht alles muss gesichert werden. Zum Beispiel:
Laufende zustandslose Container – Ein laufender Container ist temporär. Er wurde aus einem Image erzeugt – das gesichert werden muss -, aber die laufende Instanz des Containers muss nicht gesichert werden. Alle Daten, die er erzeugt, sollten vermutlich gesichert werden, aber wenn der Container selbst gesichert werden muss, stimmt etwas nicht. Wenn ein Container tatsächlich Daten enthält, anstatt sie auf einem externen Volume zu speichern, dann müsste er gesichert werden – aber das kommt sehr selten vor.
Pods – Da Pods einfach Gruppen von laufenden Containern sind, müssen auch sie nicht gesichert werden.
Jede der oben genannten Entitäten bietet ein natives Tool, das zur Sicherung der Entität auf einem lokalen oder entfernten Datenträger verwendet werden kann. Es gibt auch kommerzielle Programme auf dem Markt, die auf verschiedene Arten laufen. Der nächste Artikel wird diese verschiedenen Methoden im Detail behandeln, einschließlich der Verwendung zur Wiederherstellung der verschiedenen Teile Ihrer Kubernetes- und Docker-Umgebung.
*W. Curtis Preston ist ein Experte für Datensicherung, -speicherung und -wiederherstellung und arbeitet seit 1993 in diesem Bereich. Er war Endbenutzer, Berater und Analyst und ist seit kurzem Mitglied des Teams von Druva, einem Cloud-basierten Datensicherungsunternehmen.
Be the first to comment