Fragen? Antworten! Siehe auch: Alternativlos
Mir ist ja nach wie vor unklar, wieso Container als Methode zum Downloaden und sicheren Ausführen von Fremdsoftware aus dem Internet verkauft wird. Wenn man nicht gerade ein Cloud-Provider ist: Wie viele Szenarien beinhalten denn bitte, dass man unvertrauenswürdige Software ausführt? Wenn die Software nicht vertrauenwürdig ist, dann führt man sie nicht aus. Oder man lebt halt damit, dass die Software Mist machen kann, und lässt sie nicht an die Datenbank mit den Payroll-Daten oder das Corpnet ran.
Ich finde, Container muss man eher als Deployment-Technologie betrachten. Für Software, die man im Moment per # ./install deployed, oder per RPM oder DEB. Da schiebt man jetzt halt nicht ein RPM mit Dependencies herum, sondern aus dem Buildsystem fällt ein Image mit allen Abhängigkeiten, und die schiebt man auf das Zielsystem. Wenn das Ärger macht, dann fährt man das vorherige Image nochmal hoch und hat nur ein paar Sekunden Downtime. Das ist ein Versprechen, das Container grundsätzlich einlösen können, und da sind sie auch nicht schlechter als irgendein gammeliges manuell hochgepatches (wenn überhaupt) Redhat mit handinstallierter Anwendung — sondern haben sogar echte Vorteile.
Die ganze Idee hinter Containern ist dann, dass man beim Deployment agiler wird, und Fehler nicht so schlimm sind, weil man das alte Image noch hat. Dann muss man aber natürlich auch agil sein und seine Images häufiger neu bauen, insbesondere auch mit den aktualisierten Abhängigkeiten frisch. Warum das keiner macht, ist aber eine Frage für einen anderen Blogrant :-)