Bei der Bereitstellung von Anwendungen auf Servern gibt es normalerweise eine Trennung zwischen dem, was die Anwendung mit sich selbst bündelt, und dem, was sie von der Plattform (Betriebssystem und installierte Pakete) erwartet. Ein Punkt dabei ist, dass die Plattform unabhängig von der Anwendung aktualisiert werden kann. Dies ist beispielsweise nützlich, wenn Sicherheitsupdates dringend auf von der Plattform bereitgestellte Pakete angewendet werden müssen, ohne die gesamte Anwendung neu zu erstellen.
Traditionell wurden Sicherheitsupdates einfach durch Ausführen eines Paketmanagerbefehls angewendet, um aktualisierte Versionen von Paketen auf dem Betriebssystem zu installieren (z. B. "yum update" auf RHEL). Aber mit dem Aufkommen der Containertechnologie wie Docker, bei der Containerimages im Wesentlichen sowohl die Anwendung bündeln und die Plattform, was ist der kanonische Weg, um ein System mit Containern auf dem neuesten Stand zu halten? Sowohl der Host als auch die Container verfügen über eigene, unabhängige Pakete, die aktualisiert werden müssen, und die Aktualisierung auf dem Host aktualisiert keine Pakete in den Containern. Mit der Veröffentlichung von RHEL 7, in der Docker-Container besonders vorgestellt werden, wäre es interessant zu hören, wie Redhat mit Sicherheitsupdates von Containern umgeht.
Gedanken zu einigen der Optionen:
Wenn Sie den Paketmanager Pakete auf dem Host aktualisieren lassen, werden Pakete in den Containern nicht aktualisiert.
Alle Container-Images neu generieren zu müssen, um Aktualisierungen anzuwenden, scheint die Trennung zwischen der Anwendung und der Plattform aufzuheben (für die Aktualisierung der Plattform ist Zugriff auf den Anwendungserstellungsprozess erforderlich, der die Docker-Images generiert).
Das Ausführen manueller Befehle in jedem der ausgeführten Container scheint umständlich zu sein, und Änderungen laufen Gefahr, beim nächsten Aktualisieren von Containern aus den Artefakten der Anwendungsversion überschrieben zu werden.
Keiner dieser Ansätze scheint also zufriedenstellend zu sein.
Ein Docker-Image bündelt Anwendung und "Plattform", das ist richtig. Normalerweise besteht das Bild jedoch aus einem Basisbild und der eigentlichen Anwendung.
Die kanonische Methode zum Umgang mit Sicherheitsupdates besteht also darin, das Basisimage zu aktualisieren und dann Ihr Anwendungsimage neu zu erstellen.
Die Behälter sollen leicht und austauschbar sein. Wenn Ihr Container ein Sicherheitsproblem aufweist, erstellen Sie eine gepatchte Version des Containers neu und stellen den neuen Container bereit. (viele Container verwenden ein Standard-Basisimage, das Standard-Paketverwaltungstools wie apt-get verwendet, um ihre Abhängigkeiten zu installieren, und die Aktualisierungen aus den Repositorys abruft.)
Während Sie in Containern patchen könnten, wird das nicht gut skalieren.
Erstens befinden sich viele Ihrer Updates, die Sie in der Vergangenheit traditionell ausgeführt haben, einfach nicht im Container selbst. Der Container sollte eine relativ leichte und kleine Teilmenge des vollständigen Dateisystems sein, das Sie in der Vergangenheit gewohnt waren. Die Pakete, die Sie aktualisieren müssen, sind diejenigen, die Teil Ihrer Docker-Datei sind, und da Sie über die Docker-Datei verfügen, sollten Sie in der Lage sein, die Pakete und Container-IDs zu verfolgen, die aktualisiert werden müssen. Die Benutzeroberfläche von Cloudstein, die in Kürze veröffentlicht wird, verfolgt diese DockerFile-Zutaten für Sie, damit Sie das Update-Schema erstellen können, das am besten zu ihren Containern passt. Hoffe das hilft
Die beste Idee dafür, die ich bisher gesehen habe, ist [Project Atomic] (http://www.projectatomic.io /). Ich glaube jedoch nicht, dass es für die Hauptsendezeit bereit ist.
Valko, mit welchem Workflow bist du am Ende gelandet? Ich betreibe Langzeitcontainer (zum Beispiel Hosting von PHP-cgi) und habe bisher Folgendes gefunden: docker pull debian / jessie, um das Image zu aktualisieren und dann meine vorhandenen Images neu zu erstellen. dann stoppen Sie die Container und führen Sie sie erneut aus (mit dem neuen Image). Die Bilder, die ich erstelle, haben den gleichen Namen wie die vorherigen, daher erfolgt der Start über das Skript. Ich entferne dann “unbenannte” Bilder. Ich würde mich sicherlich über einen besseren Workflow freuen.
Interessante Frage. Ich wundere mich selbst darüber. Wenn auf einem Docker-Host 20 Anwendungen ausgeführt werden, müssen Sie Basisimages aktualisieren, neu erstellen und neu starten! 20 Anwendungen und Sie wissen nicht einmal, ob das Sicherheitsupdate alle oder nur eine davon betroffen hat. Sie müssen das Image beispielsweise für Apache neu erstellen, wenn das Sicherheitsupdate beispielsweise nur libpng betrifft. So enden Sie mit unnötigen Umbauten und Neustarts…
miha: Das klingt ähnlich wie das, was ich am Ende gemacht habe. Grundsätzlich werden alle Bilder im Rahmen der Erstellung neuer Versionen kontinuierlich aktualisiert und neu erstellt. Und die Container mit den neuen Images neu starten.
Ich habe keine Antwort, aber für den Fall, dass jemand ein einfaches Skript wünscht, mit dem die Überprüfung auf Basis-Image-Updates automatisiert werden kann: [dockcheck] (GitHub - foresto/dockcheck: Docker image update checker )