Der Datenverlust über Zeit/Verlust alter Hardware. Wie alte Medien einlesen?

[Harry]

Wer im Jahr 1905 Auto fuhr, war meist Mechaniker, der sein Fahrzeug technisch komplett verstanden hatte. Im Jahr 2022 weiß jeder, was ein Auto ist und ein Großteil der Menschen hat ein Führerschein, aber nicht zwingend ein gleiches Auto. Das Auto reparieren kann und wieder muss aber kaum einer davon.

Ich behaupte ab einem gewissen Grad der Komplexität kann es auch nicht anders laufen. Im Grunde versteht hier von uns vermutlich auch keiner wie ein Computer funktioniert. Sehr oft denkt man "Ich kann programmieren, daher weiß ich das". Aber das ist eben nicht so. Einen Computer bedienen, eine Software Schreiben, ein Betriebssystem schreiben/planen, einen Treiber entwickeln, Hardware entwickeln, Schaltungen, Elektronik, Rohstoff Verarbeitung und Gewinnung und und und. Das ist zu viel für einen und selbst einer der besten Programmierer als Beispiel kann ein Meister auf seinem gebiet sein, trotzdem wird er wohl nicht einmal in der Lage sein eine Benutzeroberfläche sinnvoll gestalten zu können.

 

[Yamagi]

Das ist zu viel für einen und selbst einer der besten Programmierer als Beispiel kann ein Meister auf seinem gebiet sein, trotzdem wird er wohl nicht einmal in der Lage sein eine Benutzeroberfläche sinnvoll gestalten zu können.

Ohne Wikipedia könnte ich nicht mal prinzipiell erklären, wie ein MOSFET funktioniert. Wie man sowas aus Sizilizium herstellt schon gar nicht. Und Logikschaltungen sind auch verdammt lange her. Soviel zu Computer verstanden...

 

[medV2]

Solche Prognosen sind regelmäßig falsch. Als der erste Computer lief, da wurde gesagt es gibt kein Bedarf Weltweit für mehr als fünf Stück oder so. Seit dem ersten Heimcomputer soll quasi alle 5 Jahre in jedem Haushalt mindestens ein Computer stehen. Das hat die letzten Jahrzehnte ja nun nicht geklappt. Ich weiß nicht warum es dieses Jahrzehnt anders laufen sollte.

Egal wie man es dreht und wendet, ein Computer ist zum Leben auch heute nicht notwendig. Er macht das Leben zwar in vielen Bereichen einfacher, aber es geht auch ohne genau so gut. Es gibt nicht wenige Familien die auch nicht die finanziellen Möglichkeiten haben für eine Ausstattung mit Internet.

Dazu kommt dann noch der Lauf der Dinge. Je älter man wird, desto weiter rückt Technik in den Hintergrund. Natürlich gibt es auch Senioren die Technik im hohen Alter entdecken und gerne nutzen, aber die Mehrheit reduziert die Nutzung im fortschreitenden Alter. Ich merke es ja selbst wie es sich verändert. Früher jeden Trend mitgemacht und nicht verstanden warum nicht alle die Möglichkeiten nutzen. Heute denke ich mir eher: Warum soll ich mich damit befassen, es geht ja auch jetzt und wenn ich eh in der Stadt bin, dann kann ich noch dieses und jenes gleich mitmachen und ein Mensch kann bei Fragen besser antworten als ein Formular.

Technik wird zumindest absehbar nichts sein was jeder überall zur Verfügung haben wird.

Es ging ja konkret um die Nutzung eines Computers für Behördengänge. Da ist "Computer" natürlich jedes Gerät mit dem ich eine Website nutzen kann, also auch jedes Smartphone und dafür hat man auch in den ärmsten Schichten Geld übrig. Zusätzlich gibts auch öffentlich benutzbare PCs z.b. in Bibliotheken oder Unis/Schulen.

Zu so einem online Behördengang - was ja nichts weiter als das Bedienen einer Website ist - sind denke ich in absehbarer Zukunft alle Leute fähig.


Und das Menschen in Ämtern Fragen beantworten können ist ja ein Scherz nehme ich an oder? Zumindest in Österreich sind die überfragt wenns nicht das komplette 0815 Tagesgeschäft ist, und freundlich oder zuvorkommend ist da auch niemand.

 

[Harry]

Zu so einem online Behördengang - was ja nichts weiter als das Bedienen einer Website ist - sind denke ich in absehbarer Zukunft alle Leute fähig.

Das sehe ich persönlich nicht in naher Zukunft. Auch unsere Stadt bietet online viele Dinge an, genutzt werden die aber von keinem. Der Grund ist nicht der Computer, sondern die Voraussetzungen. Wenn du dich mit deinem Ausweis legitimieren willst, dann brauchst du zusätzliche Geräte, musst das eingerichtet bekommen und dich zusätzlich noch anmelden. Als Windows 10 Nutzer geht das noch, bei Windows 11 fängt es schon an dass für viele Geräte keine Treiber verfügbar sind, zusätzliche fragwürdige Software installiert werden muss und dann immer noch offen ist ob dein Gerät noch kompatibel ist. Als Linux Nutzer wird es noch schwerer wenn du nicht gerade eine alte Version eines Enterprise Linux nutzt. Bei anderen Systemen wie FreeBSD oder ChromeOS ist eh Schluss. Ob das mit Android oder iOS funktioniert weiß ich nicht. Und wenn doch, dann ist die Frage ob die Diebe Version auch funktioniert...

Da bleibt der Gang zur Behörde einfacher.

 

[PMc]

Arbeite dich doch einfach mal ins Thema Container und Sandboxing ein.

Gerade gefunden:

https://www.diva-portal.org/smash/get/diva2:1453017/FULLTEXT01.pdf

Wenn man dem trauen kann (aber das ist eine BSc-Thesis, und wenn das nicht seriös ist, dann weiss ich auch nicht), dann sind meine deploy-Nodes sowieso schon die ganze Zeit Container - obwohl sie nix neues sind.

Also jetzt bin ich als alter Mann gänzlich verwirrt.

 

[PMc]

Als schlechte Analogie der gute, alte Autovergleich: Wer im Jahr 1905 Auto fuhr, war meist Mechaniker, der sein Fahrzeug technisch komplett verstanden hatte. Im Jahr 2022 weiß jeder, was ein Auto ist und ein Großteil der Menschen hat ein Führerschein, aber nicht zwingend ein gleiches Auto. Das Auto reparieren kann und wieder muss aber kaum einer davon.

Das ist gar keine schlechte Analogie. Inzwischen wirkt der Gebrauchtmaschinen-Markt auf mich sehr ähnlich wie der Gebrauchtwagen-Markt. Auch dadurch, dass sich die Leistungsfähigkeit seit core-i nicht mehr drastisch geändert hat, wird jetzt eine Maschine einfach mit Geschwindigkeit und PS (nodes und MHz) und dem Modelljahr (CPU-generation) beschrieben. Und ja, die Leute, die da als Händler unterwegs sind, machen auf mich auch zunehmend den Eindruck, den man gemeinhin von Neu-, Gebrauchtwagen- und Pferdehändlern hat - es sind jedenfalls nicht mehr die typischen Hacker...

 

[-Nuke-]

Also jetzt bin ich als alter Mann gänzlich verwirrt.

Dann lies Abschnitt 5.2.2 noch einmal und versuche mal daraus weitere Konsequenzen zu ziehen. Und nicht nur in der Hinsicht was dann am Ende läuft, sondern die Möglichkeiten die sich daraus ergeben und wie man das alles verwaltet.

 

[PMc]

Dann lies Abschnitt 5.2.2 noch einmal und versuche mal daraus weitere Konsequenzen zu ziehen. Und nicht nur in der Hinsicht was dann am Ende läuft, sondern die Möglichkeiten die sich daraus ergeben und wie man das alles verwaltet.

Ja, das ist genau der Punkt. Das hatten wir auch schon im englischen Forum ausgiebig diskutiert: containerisierte Applikationen haben den Vorteil, dass man sie unverändert und ohne spezifische Anpassung auf verschiendenen Betriebssystemen ausrollen kann - allerdings mit der Einschränkung, dass das nur dann funktioniert, wenn alle diese Betriebssysteme Linux heissen.

Ich für meinen Teil hatte konkrete Gründe, warum ich Linux in 1995 aufgegeben hab, und diese Gründe bestehen nach wie vor.
Man hat dort ja nur einen Kernel, und das ganze Drumherum, auf das es ankommt, ist sache des Distributors, also im grunde Glückssache. Das daraus sich ergebende Problem, das komplett hausgemacht ist, versucht man nun zu workarounden, indem man die Applikationen nochmal extra verpackt damit sie nicht schmutzig werden. Macht ja auch Sinn - spaßig finde ich, dass man mir dieselbe Praxis in der Obstabteilung grad abzugewöhnen versucht.

In Berkeley brauche ich das nicht; denn da gibt es diesen Wildwuchs gar nicht erst, und da sehen meine Pakete so aus:

# pkg info apache24
Annotations    :
        FreeBSD_version: 1301000
        p23_build      : webs.New.221002202834
        p23_osver      : 1301000
        p23_prev       : 0b927243dda1=55ea846ac6a5+88
        p23_srev       : 0c5ca3f87266=752f813d6ccc+24
        repo_type      : binary

Das ist nicht standard, aber leicht zu ergänzen - und damit ist das Paket bitgenau gegen die ganze Installation positioniert.
Andere mögen etwas anderes brauchen; ich jedenfalls brauche genau das. Andere mögen den Bedarf haben, dass ihre Pakete auf allen möglichen Systemen einfach nur laufen. Ich dagegen habe den Bedarf, dass, wenn etwas nicht wie erwartet läuft, minutiös genau feststellbar ist, warum es nicht so läuft.

Und weil das mit Linux praktisch nicht möglich ist (jedenfalls nicht mit vertretbarem Aufwand), hab ich das gleich wieder aufgegeben, Sollen sie sehen wie sie jetzt damit klarkommen, ich jedenfalls rühre das nur für einen mindestens dreistelligen Stundensatz an. (Das ist ein Vorteil des Alters: man weiß was man kann und was man will.)

 

[Yamagi]

Ich versuche es mal. Zuerst einmal muss man das Begriffschaos aufräumen:

• Unter FreeBSD ist der Begriff Jail doppelt belegt. Er beschreibt einmal die Technologie beliebig viele Instanzen des Userlands unter einem Kernel auszuführen und es beschreibt eben diese Userlandinstanzen. In der Praxis sind die Userlandinstanzen meist - aber nicht nicht technisch zwingend! - letztendlich vollwertige Userlandinstanzen.
• Unter Linux beschreibt der Begriff Container heute meist OCI-Container, also minimale Anwendungsimages ohne State. Zum Ausführen der Container braucht man eine Container Runtime und in der Praxis eine Abstraktionsschicht darüber, die Container Engine.

Technisch mag es ähnlich sein, in der Praxis liegen Jails und Container aber grundverschiedene Denkweisen zugrunde. Ein Jail wird vereinfacht gesagt installiert und hinterher wie ein vollwertiges FreeBSD-System administriert, oft beinhaltet ein Jail diverse Prozesse. Ein Container hingegen wird automatisiert erstellt und beinhaltet ausschließlich die minimalen Abhängigkeiten, die der einzige darin laufende Prozess benötigt. Ein Container wird nicht administriert, er wird bei Änderungsbedarf verworfen und durch ein neues Images ersetzt.

Daraus kann man einen vollautomatisierten Workflow bauen. Entwickler schreiben ihre Anwendung idealerweise, aber nicht zwingen, so, dass sie entweder keinen State benötigt oder wenn diesen extern in z.B. einem Object Store speichert. Commiten die Entwickler eine Änderung in ihre Anwendung, erstellt ein Continuous Integration Server daraus ein neues Container Image. Dieses Image besitzt Properties, anhand der ein System wie Kubernetes ihn automatisch innerhalb des Clusters deployed. So kann eine neue Version eines Containers beispielsweise ältere Versionen sukzessive verdrängen, bei Problemen mit der neuen Version wird das Deployment abgebrochen. Das System stellt auch sicher, dass (lastabhängig) eine ausreichende Anzahl Instanzen verfügbar ist. Bricht zum Beispiel eine physische Node weg, werden der darauf laufenden Container automatisch an einem anderen Ort neugestartet. Der Admin bekommt keinen Anruf und kann das Problem zu Arbeitszeiten behebe. Der Administrator kann das System auch anweisen eine physische Node zu leeren, sobald das passiert ist, kann er oder sie rebooten. Downtimes sind nicht notwendig.

Container sind kein Allheilmittel. Aber wo man sie nutzen kann, ermöglichen sie es relativ einfach und mit überschaubaren Ressourcenaufwand sehr skalierbare und robuste Infrastrukturen zu bauen. Sie machen auch das Bauen von Testsetups und Entwicklungsumgebungen komplexer Anwendungen einfach, der unbedarte Entwickler kann sich letztendlich mit einem Kommando den Kram automagisch hochziehen.

 

[Andy_m4]

Als Ergänzung:

Man könnte vielleicht auch vereinfacht sagen, das Jails und Container auf verschiedenen Ebenen stattfinden.
(OCI-)Container fußen ja letztendlich auf Technologien wie Jails (bzw. ihren Linux-Pendants LXC bzw. Namespaces usw.).
Auf Basis von Jails könnte man sowas wie Container bauen. Da gibts ja schon Projekte die sich der Thematik widmen wie z.B. BastilleBSD oder auch runj, wo versucht wird etwas OCI-kompatibles zu bauen.

OCI-Container wären also eher sowas wie HTTP und Jails eher sowas wie TCP/IP, um ausnahmsweise mal keinen Autovergleich zu bemühen. :-)

 

[PMc]

Ah, verstehe. Das OCI ist dann wohl eher dafür, wenn man nicht mehr handwerksmäßig eine Anzahl spezifischer Applikationen auf eine Anzahl bekannter Nodes montiert, sondern eher fabrikmäßig eine mittelgroße Anzahl quasi anonymer Nodes hat, die automatisiert austauschbar sind und auf denen die Anwendungen einfach per Gießkanne verteilt werden...

 

[-Nuke-]

Alles andere skaliert halt schlecht. Beispiel, ich will ein nginx laufen haben.

Wartungsaufwand FreeBSD: 1x Jail Userland, 1x nginx-pkg
Wartungsaufwand Docker: 1x nginx Container

Jetzt reicht ein nginx nicht mehr aus. Last zu groß, was auch immer. Ich brauche 5 nginx Server.

Wartungsaufwand FreeBSD: 6x Jail Userland, 5x nginx-pkg, 1x load balancer pkg
Wartungsaufwand Docker via Swarm: 1x nginx Container, 1x load balancer Container

Ganz zu schweigen davon, dass es eine starke Abhängigkeit zwischen FreeBSD Host Version und FreeBSD Jail Version gibt. Letztere darf nicht größer sein als die des Host.

Natürlich kannst du jetzt anfangen, dir den Kram so zurecht zu konfigurieren und bereitzulegen, sodass das alles nur ein rsync über verschiedene Server ist. Das machst du aber weiterhin manuell und der Aufwand steigt mit jedem Server, ganz zu schweigen von der entsprechend nötigen Netzwerkkonfiguration. Es geht halt immer noch um Werkzeuge sein Ziel zu erreichen, nicht um das was am Ende läuft.

 

[PMc]

Alles andere skaliert halt schlecht. Beispiel, ich will ein nginx laufen haben.

Wartungsaufwand FreeBSD: 1x Jail Userland, 1x nginx-pkg
Wartungsaufwand Docker: 1x nginx Container

Jetzt reicht ein nginx nicht mehr aus. Last zu groß, was auch immer. Ich brauche 5 nginx Server.

Wartungsaufwand FreeBSD: 6x Jail Userland, 5x nginx-pkg, 1x load balancer pkg
Wartungsaufwand Docker via Swarm: 1x nginx Container, 1x load balancer Container

Spannend wäre, das zu verheiraten, so dass die Sauberkeit und Stringenz von BSD bestehen bleibt und man das beste von beidem kriegt.

Nur hab ich hier keine Services, die ich gleich x-mal bräuchte, also ist meine Motivation da begrenzt. Ausgenommen höchstens die Web-Applikationen (ruby-on-rails)...

 

[-Nuke-]

Man kann es auch kleiner drehen. Gerade letztens erst auf einem privaten FreeBSD Server. Haben eigentlich nur eine Jail für Datenbanken. Dort haben wir PostgreSQL und MariaDB laufen. Nun braucht ein Service nach einem Upgrade aber zwingen MySQL und ist inkompatibel zu MariaDB. Tja, MariaDB und MySQL kriegst du nicht zusammen in eine Jail installiert. D.h. zwei Optionen: Eine weitere Jail (damit wir eine Service-Isolation haben), was den Wartungsaufwand um ein weiteres FreeBSD Userland erhöht, oder die Datenbank direkt neben die Anwendung installieren (geringerer Wartungsaufwand, schlechtere Isolation).

Das gilt auch für Anwendungen die so unterschiedliche Runtimes in unterschiedlichen Versionen brauchen. PHP, Python, Ruby, Java, ... Man ist auch entkoppelt von dem, was die Distribution in ihren Paket-Repositories hat. Das was benötigt und getestet wurde ist Teil des Container-Images.

Es gibt natürlich auch Dinge wie Ansible, was einem hier einen Haufen Arbeit abnehmen kann. Es ist im Vergleich aber auch ein großer initialer Aufwand und hat weiterhin ähnliche Probleme mit Versionen.

 

[Andy_m4]

Wartungsaufwand FreeBSD: 6x Jail Userland, 5x nginx-pkg, 1x load balancer pkg

Naja. Wenn Du ein komplettes Userland installierst (was man ja nicht muss), dann ist das ja kein Problem von Jails, sondern von Deinem Vorgehen. Und dann ist es schwierig sich darüber zu beschweren. :-)

Ganz zu schweigen davon, dass es eine starke Abhängigkeit zwischen FreeBSD Host Version und FreeBSD Jail Version gibt. Letztere darf nicht größer sein als die des Host.

Das ist auch ein eher schwieriges Argument. Warum sollte jemand freiwillig eine niedrige FreeBSD-Version fahren um eine höheres Jail darauf zu packen?
Übrigens gilt das für Deinen Docker-Container genauso. Wenn Du da ne uralt Linux-Version als Host hast, wirds auch eher schwierig.

Nun braucht ein Service nach einem Upgrade aber zwingen MySQL und ist inkompatibel zu MariaDB. Tja, MariaDB und MySQL kriegst du nicht zusammen in eine Jail installiert.

Zwei verschiedene Datenbanken/Datenbankverianten/Datenbankversionen würdest Du auch in einer Docker-Umgebung nicht in ein Container packen.

Man ist auch entkoppelt von dem, was die Distribution in ihren Paket-Repositories hat.

Entkopplung ist doch auch das, was man klassischerweise mit Jails erreichen will.
Auch da bist Du nicht zwingend darauf angewiesen, was Dir die "Distribution" liefert.
Wirklich entkoppelt bist Du übrigens auch bei Docker und Co nicht, denn Deine Applikation läuft ja nicht irgendwie im luftleeren kaum. Betriebssystemfunktionen, System-Bibliotheken usw. brauchst Du da genauso. Und auch da für fällt Pflegeaufwand an. Das wird nur gern vergessen. Im Ergebnis hast du dann irgendwelche Dockerimages die Security-Probleme haben, weil da in irgendeiner Ecke eine uralt-Bibliothek liegt auf die aber nie jemand geachtet hat.

Natürlich kannst du jetzt anfangen, dir den Kram so zurecht zu konfigurieren und bereitzulegen

Ja. Da kommen wir der Sache schon näher.
Wie bereits angedeutet. Der Vorteil von Docker und Co liegt weniger darin, das man damit irgendwas machen kann, was mit plain-Jails nicht geht oder so. Sondern der Vorteil liegt darin, das standardisierte ('standardisiert' hat den einen Vorteil des es überall gleich zu bedienen ist aber vor allem, was man darauf basierend dann auch weitere Werkzeuge/Techniken entwickeln/aufsetzen kann) Werkzeuge die einem halt viel abnehmen an Aufgaben die halt so anfallen, wenn man mit Containern arbeitet.
Ich würde sagen dieser Vorteil ist hinreichend. Daher finde ich es immer etwas unglücklich, wenn dann ein extra schlechtes Jail-Beispiel gebracht wird, nur damit Docker noch besser aussieht. :-)
Das wirkt dann ein wenig wie Werbung und Marketing und auf die Ebene sollten wir uns dann vielleicht nicht begeben. :-)

Denn, ich weiß nicht wie es euch geht. Aber mir ist es immer lieber jemand benennt zu einer Lösung klar die Vorteile, Grenzen und Nachteile, als wenn da so Teleshopping-Vibes rüber kommen: "Kennen Sie das auch? Ihre Application zickt mal wieder rum und Sie wollen Sie zähmen? Auf der einen Seite haben wir eine gewöhnliche und unflexible, schwerfällige Jail (man sieht im Hintergrund einen zerzausten und verzweifelt guckenden Nerd, dem grad sein klappriger Computer in Rauch aufgeht). Auf der anderen Seite haben wir das neue Docker Ultra Action (man sieht, wie Neo durch ein hochmodernes Rechenzentrum fliegt)" ....
Also ich hoffe, ihr versteht, was ich meine. :-)

 

[-Nuke-]

Naja. Wenn Du ein komplettes Userland installierst (was man ja nicht muss), dann ist das ja kein Problem von Jails, sondern von Deinem Vorgehen. Und dann ist es schwierig sich darüber zu beschweren. :-)

Wie kriege ich denn eine Jail, die nur die Abhängigkeiten hat, die ich brauche? Also alles außer "manuell zusammensuchen was du brauchst und was nicht".

Das ist auch ein eher schwieriges Argument. Warum sollte jemand freiwillig eine niedrige FreeBSD-Version fahren um eine höheres Jail darauf zu packen?
Übrigens gilt das für Deinen Docker-Container genauso. Wenn Du da ne uralt Linux-Version als Host hast, wirds auch eher schwierig.

Du kannst dir sicher sein, wenn Docker auf der Kiste läuft, dann funktioniert dein Container mit großer Wahrscheinlichkeit auch. Wenn ich einen FreeBSD Container einrichte und ggf. verteilen will, dann muss der Host auch passen. Ich kann kein FreeBSD 13 Container auf ein FreeBSD 12 packen. Ich brauche zwangsweise einen FreeBSD 12 Container. Ich muss also zwingend wissen was mein Host ist. Ein FreeBSD was Jail-Support hat ist nicht ausreichend. Das ist ein himmelweiter Unterschied.

Zwei verschiedene Datenbanken/Datenbankverianten/Datenbankversionen würdest Du auch in einer Docker-Umgebung nicht in ein Container packen.

Das stimmt. Aber es ist wesentlich schmerzfreier einen weiteren Container hochzuziehen, da ich eben kein weiteres Userland selbst verwalten muss. (s.u.)

Entkopplung ist doch auch das, was man klassischerweise mit Jails erreichen will.
Auch da bist Du nicht zwingend darauf angewiesen, was Dir die "Distribution" liefert.
Wirklich entkoppelt bist Du übrigens auch bei Docker und Co nicht, denn Deine Applikation läuft ja nicht irgendwie im luftleeren kaum. Betriebssystemfunktionen, System-Bibliotheken usw. brauchst Du da genauso. Und auch da für fällt Pflegeaufwand an. Das wird nur gern vergessen. Im Ergebnis hast du dann irgendwelche Dockerimages die Security-Probleme haben, weil da in irgendeiner Ecke eine uralt-Bibliothek liegt auf die aber nie jemand geachtet hat.

Wenn wir vom Image von Dockerhub ausgehen, ist aber alles da und in der korrekten Version und bestenfalls vom Ersteller des Images auch getestet. Nimmst du einfach nur die Software und baust sie ggf. selbst in der Jail, dann ist das nicht zwangsläufig der Fall. Es vollkommen egal, ob der Hersteller nun ein Debian-Userland, Fedora-Userland oder "From Scratch" ein Image erstellt.

Den Pflegeaufwand habe in den allermeisten Fällen nicht ich. Ein Großteil der Abhängigkeiten kommt weiterhin aus den Repos der zugrundeliegenden Distribution. Ändert sich einer darüber liegendes Image wird bei Dockerhub das abgeleitete Image entsprechend auch neu gebaut. Das ist eben der Vorteil der App-Container, das Userland ist einfach nur eine simple Abhängigkeit der Anwendung und nichts was ich grundlegend selbst verwalten muss. Bei FreeBSD aktualisiert mir ein "pkg upgrade" leider immer noch nicht das Basissystem. Ich muss mich separat darum kümmern.

Ja. Da kommen wir der Sache schon näher.

Ich rede ja schon die ganze Zeit von Werkzeugen. Habe ich ja auch mehrfach erwähnt. Klar, am Ende rennt ein MySQL auf meinem Computer. Ob ich das nun direkt auf dem Host via Paketmanager installiere, in einer VM, in einem OS-Container oder in einem App-Container. Am Ende lauscht auf Port X ein MySQL Server. Der Weg dahin und der nachfolgende Pflegeaufwand ist aber der Knackpunkt. Und wenn ich mir anschaue wie ultra-langsam das freebsd-update Skript ist, ist mir eigentlich jede weitere Jail eine zu viel.

Und der Wartungsaufwand ist ja auch nur ein Vorteil. Es gibt ja noch weitere, auch abseits des "Ich brauche eine Server-Farm". Mittels Docker Compose kannst du dir relativ mühelos komplexe Services zusammenbauen. Irgend eine Rails App mit MariaDB Datenbank, Redis Server, Sidekiq und was weiß ich. docker-compose.yml vom Hersteller nehmen, "docker compose pull" und "docker compose up" und schon läuft der Kram erst einmal. Da ist z.B. ein NextCloud in wenigen Sekunden eingerichtet.

Weiter geht's ja auch mit der Dokumentation. Das Dockerfile beschreibt recht genau was du mit dem Basis-Image so angestellt hast. Ich hab keine Jail laufen die irgendwer überall modifizieren kann. Die Images sind unveränderlich und der Container verwirft beim Shutdown alles was nicht explizit gesichert wird.

 

[Andy_m4]

Wie kriege ich denn eine Jail, die nur die Abhängigkeiten hat, die ich brauche? Also alles außer "manuell zusammensuchen was du brauchst und was nicht".

Das ist bei einem Docker-Container aber letztlich nicht anders. Wie gesagt. Die Applikation schwebt ja durch Docker nicht in einem luftleeren und abhängigkeitsfreien Raum.
Du kriegst halt bei Docker mehr Support. Durch die entsprechenden Werkzeuge und Infrastruktur. Durch den Umstand, das viele Applikationen schon docker-aware sind bishin das Du Dir ja sogar fertig als Docker-Container kriegst, den Du nur noch verwenden musst. Dadurch musst Du Dich weniger manuell drum kümmern. Das bedeutet aber nicht, das es nicht da ist.
Ein Kühlschrank muss auch kühlen. Nur weil Du nicht wie früher da Eisblöcke reinschieben musst, kommst Du da ohne Kühlmittelmittel aus.

Ein FreeBSD was Jail-Support hat ist nicht ausreichend. Das ist ein himmelweiter Unterschied.

Ja. Wie ich bereits sagte, lassen sich Docker und Jail ja ohnehin nur schwer miteinander vergleichen. Die eigentliche Frage war ja auch, warum sollte ich irgendein uralt FreeBSD als Jail-Host überhaupt benutzen. Ist ja jetzt nicht so das würde FreeBSD unheimlich viel Geld kosten und man versucht deshalb die alte Version so lange wie möglich zu benutzen. :-)
Abgesehen davon ist das Deployment bei Docker natürlich einfacher. Das ist ja auch eines der zentralen Designziele gewesen.

Wenn wir vom Image von Dockerhub ausgehen

Da fängts ja schon an. Du nimmst halt viele Dinge als gegeben an und dann fällt natürlich vieles hinten runter was man dann nicht mehr sieht. Das bedeutet aber nicht, das es nicht da ist. Das Image auf Dockerhub war ja auch nicht einfach da. Das musste mal jemand bauen. Und natürlich ists es einfacher etwas Vorhandenes zu nehmen als etwas selbst zu bauen. Das ist doch gar keine Frage. Das war aber auch gar nicht der Punkt.

Der Punkt war, das (aber vielleicht hab ich Dich da ja auch missverstanden) Deine Beispiele immer so ein bisschen rüber kamen wie "Das geht mit Docker, aber mit Jails nicht". Was aus meiner Sicht aber inkorrekt ist. Der wesentliche Unterschied ist der Aufwand den man treiben muss.
Du schleppst ja in Jails nicht deshalb ein Userland mit herum, weil Du es zwingend brauchst. Sondern weil es bequemer ist. Der Nachteil von Jails ist also nicht, das man da ein Userland mit zumschleppen muss (so wie das in Deinem Posting klingt), sondern das es aufwendiger ist sich manuell so ein Jail-Container zu bauen. Und würdest Du es so formulieren, würde ich da auch mitgehen.

Bei FreeBSD aktualisiert mir ein "pkg upgrade" leider immer noch nicht das Basissystem. Ich muss mich separat darum kümmern.

Ja. Wobei Pkgbase dahin gehend Erleichterung bringt und gleichzeitig man auch das Basissystem mit überschaubareren Aufwand kleinteiliger machen kann. Evtl. fällt ja dann über kurz oder lang freebsd-update weg und man macht dann alles über pkg.

Ich rede ja schon die ganze Zeit von Werkzeugen.

Das kam bei mir halt nicht so ganz klar an. Und es ist ja auch nicht so, das Du Unrecht hast oder so. Aber ich fand halt die Beispiele etwas ungünstig gewählt oder zumindest etwas unglücklich präsentiert. Wie halt das Beispiel mit MariaDB und MySQL wo ich mir denke: WTF?
Das wirkte dann doch arg konstruiert.

Irgend eine Rails App mit MariaDB Datenbank, Redis Server, Sidekiq und was weiß ich. docker-compose.yml vom Hersteller nehmen, "docker compose pull" und "docker compose up" und schon läuft der Kram erst einmal. Da ist z.B. ein NextCloud in wenigen Sekunden eingerichtet.

Ja. Wobei man auch hier das ein bisschen gucken muss. Das ist fürs testen und entwickeln sicher ganz nett. Wenn du darauf geschäftskritische Anwendungen oder da ne WebApp mit ins Internet stellen willst, ist das eben keine Sache von Sekunden oder Minuten. Zumindest ist es nicht empfehlenswert es so zu machen, wenngleich es immer mal wieder vorkommt.

Jedenfalls ist das wieder was ich meine. Da wird irgendwie gezielt ein Szenario gezeigt, wo Docker super gut aussieht. Was man ja durchaus auch machen kann, um Vorteile zu verdeutlichen. Dann aber nicht mal wenigstens in einem Nebensatz das entsprechend einzuordnen. Das wirkt dann auf mich wie so Marketing-Gerede und nicht wie ein differenziertes Auseinandersetzen mit der Thematik. Und mich schreckt sowas eher ab. Du meinst das vielleicht gar nicht so, aber es wirkt so. Und das ist eigentlich das Feedback, was ich Dir geben möchte.

 

[-Nuke-]

Da fängts ja schon an. Du nimmst halt viele Dinge als gegeben an und dann fällt natürlich vieles hinten runter was man dann nicht mehr sieht.

Genau das ist doch der Sinn von besseren Werkzeugen. Natürlich hat da jemand im Vorfeld Arbeit rein gesteckt. Aber diese Arbeit liegt nicht bei mir. Jemand der sich mit der Thematik besser auskennt (oft der Hersteller der Anwendung selbst) baut es für mich und ich nehme es einfach in Betrieb. Übrigens verbietet dir keiner, dir deinen eigenen Container/Image zu bauen, falls du meinst du kannst es besser. OCI ist kein One-Way-Ticket.

Wie ich schon sagte. Natürlich geht das alles auch mit Jails. Aber dann habe ICH die Arbeit das Ziel zu erreichen.

Du ziehst dir ja vermutlich auch nicht per Hand die Paketsourcen vom Hersteller und kompilierst diese mit allen Abhängigkeiten selbst mittels ./configure && make && make install. Du nimmst vielleicht auch nicht ein Build-Tool wie portmaster, was dir diese Arbeit abnimmt. Du nimmst wohl eher den Paketmanager deines Betriebssystems, der dir bereit vorkompilierte Anwendungen ausliefert.
Du programmierst ja auch nicht direkt Maschinencode. Vermutlich auch nicht Assembler. Vielleicht auch gar nicht mehr direkt C.

Egal wie: Du nimmst vermutlich etwas, was den ganzen ekligen Kram weg abstrahiert, damit es einfacher ist. Das gilt für Programmierung als auch für Systemadministration.

edit:

Jedenfalls ist das wieder was ich meine. Da wird irgendwie gezielt ein Szenario gezeigt, wo Docker super gut aussieht. Was man ja durchaus auch machen kann, um Vorteile zu verdeutlichen. Dann aber nicht mal wenigstens in einem Nebensatz das entsprechend einzuordnen. Das wirkt dann auf mich wie so Marketing-Gerede und nicht wie ein differenziertes Auseinandersetzen mit der Thematik.

Im Gegenzug hab ich aber von Jails auch noch nichts gehört außer "das kannst du mit Jails auch machen" und verschwiegen wird "aber nur mit (großem) händischen Aufwand". Wer verschweigt jetzt was?

Ich persönlich arbeite täglich mit Docker, sowohl in der Softwareentwicklung als auch in der produktiven In-Betriebnahme. Ich habe privat im Gegenzug auch FreeBSD mit Jails laufen und meine Meinung hier ist schlicht, dass ich im Vergleich so gar kein Argument für Jails finden kann. Docker/OCI ist halt einfach mal 1-2 Generationen weiter. Und dieses "alte Herren Argument", dass "die Jugend von heute die Grundlagen nicht mehr kennt" kann man sich mir gegenüber mit meinen fast 40 auch stecken lassen

 

[Andy_m4]

Genau das ist doch der Sinn von besseren Werkzeugen.

Klar. Das hab ich doch auch nie bestritten.

Wie ich schon sagte. Natürlich geht das alles auch mit Jails. Aber dann habe ICH die Arbeit das Ziel zu erreichen.

Ich glaube schon, das wir da grundsätzlich die gleiche Meinung haben.
Es geht lediglich darum, wie gewisse Dinge dargestellt werden.

Beispiel: Es soll irgendwie ein großes Loch gegraben werden. Und auf der einen Seite hat man jemand mit einer Schaufel und auf der anderen Seite jemand mit nem Bagger.
Wenn mir jetzt jemand erklärt, das der mit dem Bagger früher fertig ist, weil der Bagger kräftiger ist und in den Grabelöffel auch viel mehr Erde reinpasst als in so ne Schaufel, dann ist das ja auch alles in Ordnung und der Vorteil hinreichend belegt.
Wenn der dagegen noch anfängt damit, das sich der mit der Schaufel extra blöd anstellt und die Schaufel falsch herum hält und solche Sachen, dann wirkt das halt einfach seltsam.
Jetzt klar?

Im Gegenzug hab ich aber von Jails auch noch nichts gehört außer "das kannst du mit Jails auch machen"

Das bestimmte Dinge aufwändiger sind habe ich mehrmals(!) gesagt. Also bitte.

 

[-Nuke-]

Wenn der dagegen noch anfängt damit, das sich der mit der Schaufel extra blöd anstellt und die Schaufel falsch herum hält und solche Sachen, dann wirkt das halt einfach seltsam.
Jetzt klar?

Mir ist schon klar, dass du meine Beispiele nicht toll fandest oder schlicht nicht verstanden hast (oder wolltest).

Das MySQL Beispiel war hier auch schlicht so wie es mir passiert ist. Es sollte schlicht zeigen, dass es eben in Docker wesentlich einfacher ist einen weiteren Container einzurichten und zu verwalten als mittels Jails. Jails sind halt von Haus aus keine Applikations-Container, darum verwendet man sie auch nicht so (wegen des Wartungsaufwands) und deswegen hat man eben solche Probleme. Das Argument ist weder konstruiert, noch vollkommen realitätsfern.

Ich weiß deswegen auch nicht, warum du mich jetzt so hinstellen willst, als sei ich vollkommen verblödet mit dem Problem und das mein Vorgehen total falsch war.

 

[Yamagi]

Ich wollte hier keine Grundsatzdiskussion über Container vs. Jails lostreten. Kommt bitte mal zurück zum Thema

 

[midnight]

Ich wollte eigentlich nichts dazu schreiben, aber das erinnert mich an vi vs. Emacs oder VW vs. Opel oder C vs. Pascal oder Windows vs. Linux. Jeder hat hier seine Praeferenzen und Vorlieben und nutzt und verteidigt das Tool, was er beherrscht und was in der Situation angemessen ist. Wer bereits eine perfekte Emacs config hat, wird nichts anderes mehr nutzen wollen und umgekehrt hat Emacs eine hohe Einstiegshuerde und es dauert Jahre, bis die Schuhe eingelaufen sind und die Config den eigenen Beduerfnissen gerecht werden. Ist VSCode z.B. daher besser?