Dann hast du Containerisierung noch nicht verstanden.
Doch. Aber für einen privaten Webserver, wo a) eigene Bastelsoftware und b) fertige Packages von vernünftigen Entwicklern laufen, sind die von dir erwähnten Punkte imho reichlich irrelevant (weil man dort eben nicht x-Versionstände vorhalten muss und im Zweifelsfall eben auch die Anwendungen updatet (und in den Fällen, wo das nicht geht, dürfte die Anwendung auch nicht besonders sicher sein))
Alpine bietet gerade, beispielsweise, PHP 7.2 an. Darauf läuft deine Applikation. Schön. Jetzt kommt PHP 7.3 in die offiziellen Alpine-Repos und genau jetzt hast du ein Problem, welches du mit Containern nicht hättest. Entweder (A) du updatest dein Betriebssystem nicht mehr und lässt dementsprechend auch alle Updates aus, bis du dir sicher bist, dass deine Applikation unter PHP 7.3 funktioniert, (B) du updatest alles außer PHP und betest, dass PHP danach noch funktioniert (Stichwort Linking) oder (C) du updatest einfach und betest, dass deine Applikation noch funktioniert.
Es hindert dich aber auch so niemand daran, einfach ein eigenes APKBUILD vorzuhalten, mit dem du dann die "kritischen Pakete" in eigenen Versionen pflegst (abgesehen von dem Punkt, dass der Overhead einer VM wenn man dann unterschiedliche Softwarestände braucht, zu hoch sein sollte).
Das ist, wenn man es genauer betrachtet, abgesehen vom Deployment auf einem Cluster (das ist ja eigentlich der USP dieser ganzen kommerziellen Containerlösungen, dass es effektiv egal ist, wieviele Server man hat) auch nicht viel komplexer... Und Sicherheit: nunja, Dockerimages sind in den Basiskomponenten auch nicht notwendigerweise up-to-date. Effektiv "löst" man das Problem dadurch, dass man nach außen jeweils nur die gepflegten Komponenten zeigt.
Inoffizielle Repos sind keine Alternativen, weil sie meistens von Privatpersonen bereitgestellt werden und potenziell erstmal nicht vertrauenswürdig sind.
Aber Docker-Images sind potenziell vertrauenswürdig? Es gibt (gerade wenn es nicht ums Deployment selbstentwickelter Software und der dafür nötigen Basisinfrastruktur (für die z.B. für Redhat auch durchaus Möglichkeiten zur Versionierung existieren) geht), genug Images, die einfach irgendwelche Binaries downloaden. Und viele der "deploy 'hyped'-software" with Docker Dockerfiles sehen so aus.
Selber bauen ist auch keine Alternative, weil du deinen Pflegeaufwand um ein Vielfaches erhöhst.
Nicht höher, als das Erstellen und Warten eines Dockerfiles. Und ob jetzt die Umstellung des Deployment-Prozesses für kleine Nutzer die wahnsinnigen Effizienzgewinne liefert?
Du machst deine Applikation von dem Betriebssystem abhängig, auf das die Applikation läuft. Und wenn du eine Applikation mal zwei Jahre später wieder erst bauen willst, hast du eventuell ein riesengroßes Problem.
Wie denn? Ich baue dann für eine minimale Linux-Distribution in einer VM einfach die nötigen Dependencies und die jeweilige Software (gut, bin an den Paketmanager gebunden)? Was anderes macht so ein Dockerskript (bin an Docker gebunden) nämlich auch nicht, außer dass der Distributionsmechanismus für die gebauten Binaries ein anderer ist.
Nein. Docker-Container laufen unter Linux auf dem Host-Kernel und benutzen auch exakt die gleiche Hardware. Ein Container ist grundsätzlich nicht mehr als ein chroot. Die Performance ist in jedem Szenario identisch.
An dem Punkt reden wir minimal aneinander vorbei, denn ich rede über die Performancedifferenz von Numerikbibliotheken zwischen Binaries für eine generische Architektur und solchen, die für ein bestimmtes System kompiliert wurden. Und nicht nur da sehe ich gerade in dem Konzept von Spack auch erhebliche Vorteile gegenüber den (ebenfalls durchaus gebräuchlichen) "how to setup an easy dev environment with docker"-Tutorials.