2014-10-20 9 views
7

Auf meinem aktuellen Server verwende ich unbeaufsichtigte Upgrades, um automatisch Sicherheitsupdates zu verarbeiten. Aber ich frage mich, was die Leute für die Arbeit in Docker Container vorschlagen würde. Ich habe mehrere Docker Container für jeden Dienst meiner App ausgeführt. Sollte ich die unbeaufsichtigten Upgrades in jedem Setup haben? Oder vielleicht aktualisieren sie lokal und drücken Sie die aktualisierten Bilder? Irgendwelche anderen Ideen?Docker: Die beste Methode, um Sicherheitsupdates von Paketen von apt-get in Docker-Containern zu verarbeiten

Hat jemand Erfahrung damit vielleicht in der Produktion?

+0

Benötigen nicht unbeaufsichtigte Upgrades einen Cron-Prozess? Wirbeln Sie Cron in jedem Container auf? – lid

+0

Hi @lib, Derzeit bin ich, obwohl ich denke, ich könnte einen Cron-Container haben, der dann das unbeaufsichtigte-upgrades-Programm direkt auf jedem Server ausführt, sowie alle anderen benötigten Crons ... – stilliard

Antwort

2

Ich aktualisiere automatisch wie Sie (vorher). Momentan habe ich Bühnencontainer und noch nichts in Prod. Es ist jedoch kein Nachteil, wenn Updates auf jeden Container angewendet werden: einige überflüssige Netzwerkaktivitäten, wenn Sie mehrere Container haben, die auf demselben Image basieren, aber ansonsten harmlos sind.

Der Wiederaufbau eines Containers erscheint mir unnötig zeitraubend und erfordert einen komplexeren Prozess.

WRT-Zeit: Die Zeit für die Neuerstellung wird zu der Zeit addiert, die für die Aktualisierung benötigt wird, daher ist es in diesem Sinne "zusätzliche" Zeit. Und wenn Sie Startprozesse für Ihren Container haben, müssen diese wiederholt werden.

WRT Komplexität: Auf der einen Seite führen Sie einfach Updates mit apt. Zum anderen agieren Sie grundsätzlich als Integrationsserver: Je mehr Schritte, desto mehr schief gehen.

Auch die Updates erstellen kein "goldenes Bild", da es leicht wiederholbar ist.

Und schließlich, da der Kernel nie tatsächlich aktualisiert wird, müssten Sie nie den Container neu starten.

+0

Hi @Rondo, Du hast recht, ich mache mir keine Sorgen wegen ein bisschen überflüssiger Netzwerkaktivität, und die Fähigkeit der Container, live zu bleiben/laufen, anstatt jedes Mal neu aufbauen und ausführen zu müssen, wäre viel geeigneter, Danke, ich werde dann mit den unbeaufsichtigten Upgrades anfangen. – stilliard

+2

Der Container muss wahrscheinlich neu gestartet werden, wenn das Update die gemeinsam genutzten Bibliotheken ändert, da die Bibliotheken normalerweise nur geladen werden, wenn der laufende Prozess gestartet wird. – jochen

2

Ich würde den Container neu erstellen. Sie sind in der Regel darauf ausgerichtet, eine App auszuführen, und es kann wenig Sinn machen, das unterstützende Dateisystem und alle darin enthaltenen, aber nicht verwendeten/bereitgestellten Apps zu aktualisieren.

Wenn Sie die Daten in einem separaten Volume haben, können Sie ein Skript erstellen, das den Container neu erstellt und neu startet. Es hätte den Vorteil, dass beim Laden eines anderen Containers aus diesem Image oder beim Durchschieben eines Repositorys auf einen anderen Server alle Fixes angewendet würden.

+0

Hi @gmuslera, das macht Sinn obwohl, wenn Sie viele Behälter hatten, zu pflegen? Müssen Sie die Sicherheitspatches der einzelnen in den einzelnen Containern verwendeten Pakete manuell oben halten und die entsprechenden Container jedes Mal neu erstellen? Oder würdest du das irgendwie automatisieren? Vielleicht einfach jede Woche neu bauen lassen? – stilliard

+0

Es gibt Updates, die (nach Ihren eigenen subjektiven Kriterien) "wichtig" sind, und Updates, die dies nicht tun, und somit die Richtlinie, die sie betrifft. Wenn dies auf einzelne Apps mit nicht häufigen Sicherheitsproblemen abzielt, die Sie betreffen, sollte etwas besonderes, nicht normales sein. YMMV – gmuslera

+0

Danke @gmuslera, das macht viel Sinn. Ich denke, ich werde diesem Plan folgen, aber ich werde meine Frage noch etwas länger offen lassen, wenn das in Ordnung ist, falls es andere Ideen gibt, aber ansonsten werde ich diese als die Antwort markieren, da es ein großartiger Plan ist :) – stilliard