Docker: Langfristig funktionstüchtiges Image bauen

Hallo zusammen,
ich möchte ein Docker-Image bauen, das möglichst lange ohne weitere Wartung funktioniert (sagen wir mal 10-20 Jahre). Darin soll unter anderem openssh-server, x11-apps, und einiges weiteres installiert und passend konfiguriert sein. Das ganze dient dazu, Studenten eine Toolbox zugänglich zu machen, die nur unter ganz bestimmten Umständen läuft.

Wenn ich das mit Dockerfiles richtig verstanden habe, kann ich darüber einzelne Pakete laden und bekomme jeweils den aktuellsten Stand. Allerdings möchte ich ja genau meinen Stand beibehalten - nichts soll aktualisiert werden. Selbst wenn ich feste Versionen dort angeben kann, hilft das nur bedingt, da diese vielleicht in 10 Jahren nicht mehr zum Download zur Verfügung stehen...

Meine Idee/mein Test:
Ich habe nun ein Ubuntu-Docker-Image geladen und darin manuell meine Software installiert. Mit docker commit den Container wieder zu einem Image verpackt und in den Dockerhub geladen. Es scheint so, als ob er mit Ubuntu verlinkt ist, alle meine Installationen jedoch fest Teil des Images sind. Ist das der Weg in die richtige Richtung? Kann ich die Verlinkung zu Ubuntu auch noch irgendwie aufheben, damit ich einen komplett festen Stand habe?

Vielen Dank!

PS: Ich bin (noch) nicht sehr familiär mit Linux und habe für den Container aus Gründen der Einfachheit Ubuntu gewählt. Gibt es eine kleinere Distribution (Ubuntu-Image hat ca. 200 MB), die ebenfalls auf einfache Art und Weise die Installation von Anwendungen (apt-get install openssh-server, ...) sowie reibungslosen Betrieb für Linux-Anfänger erlaubt?

Ein Image und auch ein laufender Container aktualisiern sich nicht von alleine. Solange du das Image in der benötigten Version vorhälst, bleibt das auf dem Stand. Im Zweifel das Image "Exportieren" und sichern. Dann kannst du es bei Bedarf wieder zurückspielen... falls der Host mal stirbt etc.

Das was du mit "verlinkt" meinst, sind wahrscheinlich die Layer. Darüber brauchst du dir keine Gedanken machen. Wenn du ein Image hast, ist das vollständig unanbhängig.

Zusätzlich zu dem Image musst du dir aber auch Gedanken machen, die Hard- und Software zum Betreiben von Docker über die gewünscht Betriebszeit parat zu halten.

Zu deinem PS: ja, es gibt selbstverständlich minimalistischere Images, die sich als Basissystem eignen (Alpine dürfte sowas sein). Im Kontext von "Linuxanfänger" und "reibungslos" ist Ubuntu aber vielleicht erstmal eine brauchbare Wahl.

Ich glaube ich habe mich unklar ausgedrückt: Jeder Student soll bei sich lokal einen solchen Docker-Container starten, damit er selbst alles tun (und kaputt machen) kann. Falls etwas nicht mehr funktioniert, erzeugt er sich aus dem Image einen neuen Container.
Das bedeutet auch, dass jedes Semester dieses Image von vielen Studenten gezogen wird.
Wenn nun Ubuntu ein "Layer" dieses Images ist, dann wird doch (korrigiert mich) zu der Zeit, wenn jemand mein Image vom Dockerhub pullt, das aktuelle Ubuntu-Image ebenfalls heruntergeladen. Das würde bedeuten, dass ein Student, der sich das Image heute zieht, eventuell eine andere Ubuntu-Version als ein anderer Student hat, der das Image morgen zieht?!

Gedanken über Hard- und Software fallen weg, da die Container wie gesagt bei den Studenten laufen. Sollte sich etwas grundlegend an docker ändern, muss natürlich angepasst werden.

Okay, ich werde mich mal etwas in Alpine einlesen. Vielleicht ist es für die Studenten aber auch ganz nett ein Ubuntu zu haben - man kann das ja mit Usability begründen

Nein das Image bleibt immer in diesen Zustand wie es gebuilded wird, nutzt du ein unbuntu 16.4 dann wird es in 10 Jahren auch noch ein ubuntu 16.4 sein.

Du musst beim Bauen des Images drauf achten das deine Studenten keine Möglichkeit haben den Container zu upgraden.

Dir ist aber klar das du keine gui im klassischen Sinne mit auslieferst oder?

Die Frage ist außerdem ob es Sinn macht Images zu nutzen die so alt sind gerade wenn es um Software geht.

Der Sinn hinter docker ist ja gerade schnell Services ausrollen und wieder zerstören zu können.

Wie sieht es mit der Notwendigkeit von Persistenz der Daten aus?

Wenn im Container gearbeitet wird und dieser Container zerstört wird sind alle Arbeitsstände weg

Ist das auch der Fall, wenn ich ein Dockerfile verwende? Dann wird das Image doch erst richtig zusammengebaut, wenn jemand bei sich dieses Dockerfile als Image einsetzen möchte - Docker weiß ja nicht, wann ich dieses File erstellt habe?

Vielleicht sollte ich etwas genauer beschreiben: Ein Professor hat über 20 Jahre eine riesige Library inkl GUI in SWI-Prolog (Logikprogrammierung) geschrieben. Die läuft auf seinem System auch super. Leider kommt es immer wieder zu Problemen, wenn Studenten oder Firmen diese Library nutzen möchten (jeder hat eine andere Version von SWI-Prolog, diverse aliase gehören im System eingerichtet, manche haben Windows, ...). Sogar eine GUI gehört dazu.

Deshalb wäre es schön, ein komplettes System mit den nötigen Voraussetzung bereitzustellen. Sicher wäre eine VM auch eine Lösung, gerade für Linux-User ist ein Docker-Image aber wesentlich einfacher/schöner einzubinden.
Die Library wird bei den Usern lokal liegen und in den Container gemappt. Das hat den Vorteil, dass die Library unabhängig vom Container ausgetauscht und angepasst werden kann - es kann sogar manchen Usern ganz einfach eine mächtigere Library zur Verfügung gestellt werden. Die vom Studenten geschriebenen Programme liegen dann auch in diesem Verzeichnis (und damit lokal) und können nach dem Wechsel des Containers einfach weiterverwendet werden.

Der Workflow soll dann so aussehen, dass der Student seinen Container startet und dorthin eine SSH-Session macht. Über X11Forwarding bekommt er auch die GUI angezeigt.
Windows-User müssen sich leider mit der Docker Toolbox (das macht dann eine kleine VM), Xming (für X11) und Putty (SSH mit X11Forwarding) rumschlagen.
Das ist alles dennoch besser als alles in eine VM zu packen und den Studenten zu zwingen innerhalb der VM in einem fremden System zu programmieren.

Ich denke mein Weg ist keine schlechte Richtung, bin aber für jegliche Kritik offen.

Also ein dockerfile baut immer ein Image am Stichtag sprich immer die aktuelle Version.

Daher wenn du das so machen willst gibt es diese Möglichkeiten:

1. du baust ein Images mit den Abhängigkeiten die benötigt werden dieses stellst du entweder durch den docker Save auf einem Fileserver bereit.
Die stundenden ziehen sich dann das Image und mit docker load können sie es nutzen
2. du baust das Image und pullst das in ein eigenes docker Repo
Wäre sehr komfortabel allerdings muss du dann ein eigens repo aufbauen oder dir diesem Dienst einkaufen (gibt es Anbieter)

3. du stellst die Bibliotheken in einem repo bereit und gibst im dockerfile genau an welche Pakte mit welchen Versionen er installieren soll.

Und es muss sicher gestellt sein das der Student kein Upgrade des Containers durchführen kann.

Ich glaube du kommst mit einem VM Template besser. Dieses zieht sich jeder Student importiert es in seine VM-Software und fertig ist der Lack.

wenn du im dockerfile das latest tag unter "FROM" verwendest, wird beim bauen des images das neueste tag genommen. (falls der autor des images denn alles immer mit latest taggt)
aber das ist ohnehin dumm, latest sollst du eben aus diesem grund nicht verwenden. gib eine explizite version an, dann ist der build auch deterministisch.

Das funktioniert beim Basis Image welches dem docker-Image zugrunde liegt aber das funktioniert nicht bei Paketen die danach installiert werden

dann solltest du einmalig das image auf dem fuer dich richtigen stand bauen und in eine registry hochladen, also zb dockerhub.

wenn genau dieses image mit seinem hash referenziert wird von anderen und mit pull run etc verwendet wird, bekommt man exakt dieses mit genau diesem inhalt. immer und garantiert. dahinter liegen mehrere layer, aber auch diese verhalten sich exakt so: die haben einen hash und werden quasi von deinem "ganzen image" (welches, stark vereinfacht gesagt eine liste von layern hat( referenziert. und alle diese layer sind content addressable, das heisst dass nur exakt ein hash zu einem layer passen.

kurz: wenn jemand einen bestimmten hash bzw einen tag der auf einen best. hash gemappt ist referenziert, kann er rein technisch bedingt auf immer und ewig nur das selbe image bekommen. (hash kollisionen lasse ich aussen vor und sind praktisch kein thema)

Seiyaru2208 schrieb:

Ich glaube du kommst mit einem VM Template besser. Dieses zieht sich jeder Student importiert es in seine VM-Software und fertig ist der Lack.

Zum Vergrößern anklicken....

Darüber habe ich eben lange nachgedacht. Irgendwie umgehe ich schon viele Vorteile von Docker. Allerdings haben viele der Studenten (Informatik) sowieso Linux/Docker und können damit profitieren und andererseits scheint Microsoft an einer nativen Unterstützung von Linux-Dockern zu arbeiten bzw. hat das für Windows 10 schon veröffentlicht.

birday schrieb:

dann solltest du einmalig das image auf dem fuer dich richtigen stand bauen und in eine registry hochladen, also zb dockerhub.

Zum Vergrößern anklicken....

So dachte ich mir das. Ich ziehe mir eine blanke Linux-Distribution per Docker und installiere alles manuell dort rein (das hat den Vorteil, dass auch der Prof, dem Dockerfiles nichts sagen, später mal einfach eine Aktualisierung vornehmen kann). Läuft der Container so wie ich will, commite ich ein Image davon und lade das auf dockerhub öffentlich hoch.

Seiyaru2208 schrieb:

Und es muss sicher gestellt sein das der Student kein Upgrade des Containers durchführen kann.

Zum Vergrößern anklicken....

Wo siehst du da ein Problem? Ich lade ein passendes Image auf Dockerhub und die Studenten ziehen das von dort.
Wenn einer seinen Container verhaut, erzeugt er einen neuen aus dem Image. Verhaut einer sein Image, muss er es eben neu vom Dockerhub holen.


Übrigens Danke für eure rege Beteiligung. Die Diskussion bringt mich wirklich weiter

naja, ganz ehrlich, dieses von hand bauen und dann docker commit ist totaler mist.
wenn man sowas macht, nur mit dockerfile bzw. packer bei VMs.
ist sonst null reproduzierbar, sowas bringt einfach nur probleme mit sich. es ist weder versioniert noch nachvollziehbar was drin ist. infrastructure as code nennt sich das dann, wenn man es richtig macht.

Ich muß birday zustimmen. Warum ist eine VM hier nicht sinnvoller?

Das ist jetzt nicht bös gegen den TS gemeint, aber wie soll es Docker Images geben, die 20 Jahre halten sollen, wenn sich das OS des Hostsystems innerhalb der 20 Jahren ändert (was für mich erstmal nicht möglich und machbar klingt)? Rein sicherheitstechnisch wäre ein uraltes Docker-Image ein hohes Risiko bgzl. alter Libs und Co. Zudem orientieren sich doch immer die Images an dem Kernel bzw. Teile des Linux-Kernels, wie will man hier überhaupt gewährleisten, daß dann entsprechende Libs dann noch damit zusammenarbeiten? Und unter Windows bzw. MacOS muß für Docker trotzdem ein kleiner Hypervisor gestartet werden, sprich: man hat dann doch wieder an sich eine VM, eben nur nochmal gekapselt, dann kann man doch gleich eine VM machen? Und dann behält man einfach eine Kopie der VM-Image, und spielt diese wieder im Fehlerfall zurück.

Bis auf wenige Anwendungsfälle hat sich mir bisher noch nicht erschlossen, daß Docker gegenüber einer VM praktischer ist. Man tut in den Medien vielerlei so, als ob Docker das Allheilmittel sei. Trotzdem ist man von den Ressourcen nach wie vor an das Hostsystem gebunden, und man kann auch mit VMs mit eigenen OS entsprechend skalieren. Vom Kopieren und in Betriebnahme nimmt sich das mit aktuellen praktischen Erfahrungen nichts. Da sind vielfach Microservices sinnvoller, oder?

PHuV schrieb:

...aber wie soll es Docker Images geben, die 20 Jahre halten sollen, wenn sich das OS des Hostsystems innerhalb der 20 Jahren ändert (was für mich erstmal nicht möglich und machbar klingt)?
...Zudem orientieren sich doch immer die Images an dem Kernel bzw. Teile des Linux-Kernels, wie will man hier überhaupt gewährleisten, daß dann entsprechende Libs dann noch damit zusammenarbeiten?
...Und unter Windows bzw. MacOS muß für Docker trotzdem ein kleiner Hypervisor gestartet werden, sprich: man hat dann doch wieder an sich eine VM

Zum Vergrößern anklicken....

Okay, okay. Da muss ich dir uneingeschränkt recht geben. Für mich persönlich würde ich wohl auch eine VM nehmen.
Ich muss am Ende halt eine Arbeit darüber schreiben und ich dachte mir, da würde sich Docker doch besser machen als eine einfache VM (wobei es ohne Dockerfile auch nicht prickelnd geworden wäre).

Gehe ich von einer VM aus... Womit baue ich die, damit möglichst viele Programme die am Ende auch importieren/starten können?

z.B. https://www.packer.io/