Tester gesucht: OCI Container auf FreeBSD

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Die FreeBSD OCI Runtime Extension Working Group wird zwischen dem 2. September und dem 11. Oktober eine Testkampagne ("Testing Timebox") für die experimentelle Implementierung von Podman, Buildah und der ocijail OCI Container Runtime durchführen. Dafür werden Tester gesucht. Idealerweise Nutzer, die bereits über größere Erfahrungen im Umgang mit OCI Containern verfügen, aber jeder ist willkommen. Weitere Informationen gibt es unter: https://github.com/oci-playground/freebsd-podman-testing

Vielleicht ist es noch wichtig zu erwähnen, dass Podman in diesem speziellen Moment sozusagen "nur" das konkrete Werkzeug ist. Das Projekt ist deutlich größer, im aktuellen Schritt geht es neben dem konkreten Werkzeug vor allem darum Anwenderfeedback zu sammeln und darauf aufbauend eine offizielle OCI Runtime Extension für FreeBSD zu entwickeln. Doug Rabson hat vor einigen Monaten den Stand des Projekts, Hintergründe und die zukünftigen Ziele bis hin zu möglicher K8S Unterstützung in einem Lightning Talk auf den Container Days zusammengefasst:
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
ich wünsch(t)e mir, dass FreeBSD (bzw die BSDs generell, sind portierungen nach Net oder Open geplant?) dadurch einen Schub bekommt
 
double-p schrieb:
Ein FreeBSD kernel "versteht" halt keine Linux syscalls.
Zum Vergrößern anklicken....
Ja doch, eigentlich tut er das schon. Das Problem hat man zB mit dart-sass. Sonst müsste man ja Anwendungen, die das brauchen (zB das discourse-Forum), in einem linux-guest laufen lassen.

Hintergrund: Sass ist ein Preprozessor für CSS. (CSS dient dazu, die Elemente in einer HTML Seite anzuordnen.) Mit Sass kann man da zB Variablen verwenden und Berechnungen einbauen, und das wird dann preprozessiert, sodass der Browser normales CSS bekommt.
Sass gibt es u.a. in Javascript, aber wenn man komplexere Sachen machen will (zB höhere Mathematik beim Gestalten der Webseite nutzen), dann braucht man ein spezielles Sass, das in der Sprache DART läuft und das dazuhin embedded ist, also nicht einmalig kompiliert, sondern mittels Streams laufend mit seinem DART Runtime labert. (Welche Vorteile das bieten soll, weiß ich nicht.)

Das DART ist eine Ausgeburt von Google. Hat irgendwas mit Chrome zu tun. Und Google will justament nicht, dass das auf einem Berkeley läuft. Es bräuchte wohl nur die passenden if-else, denn wenn etwas auf MacOS und Linux geht, dann geht es ja prinzipiell auf Berkeley auch. Aber Google will nicht.

Anyway, jedenfalls hatte ich dann diese DART runtime für Linux rumliegen - und das lief ganz problemlos. Und das Discourse-Forum dann auch. (Die wollen aber auch justament nicht, dass das auf Berkeley läuft. :( )
 
Ich weiss nicht so ganz, was das zum Thema hat.. aber dann nochmal so:
Wenn man einen Prozess unter FreeBSD zum laufen bekommt, kann man den auch containern - ok.
Man kann aber nicht "beliebig" linux-basierte images von docker.io+Co runterladen und die in
eine FreeBSD OCI isolation verfrachten und denken, dass das einfach laeuft -- in die Richtung
geht die Frage ueblicherweise.
 
double-p schrieb:
Ich weiss nicht so ganz, was das zum Thema hat.. aber dann nochmal so:
Wenn man einen Prozess unter FreeBSD zum laufen bekommt, kann man den auch containern - ok.
Zum Vergrößern anklicken....
Das muss aber jemand tun.
Üblicherweise stellt ja jemand seine Software als Container zur Verfügung. Und wenn es FreeBSD-native Container gibt, dann könnte derjenige auf die Idee kommen, Container für FreeBSD bereitzustellen. Oder halt auch nicht.

double-p schrieb:
Man kann aber nicht "beliebig" linux-basierte images von docker.io+Co runterladen und die in
eine FreeBSD OCI isolation verfrachten und denken, dass das einfach laeuft -- in die Richtung
geht die Frage ueblicherweise.
Zum Vergrößern anklicken....
Nicht auf Anhieb. Aber vielleicht läßt sich da was machen? Ein Linux kann ja auch in einem chroot (aka jail) laufen...
 
PMc schrieb:
(Die wollen aber auch justament nicht, dass das auf Berkeley läuft. :( )
Zum Vergrößern anklicken....
weiß man warum?
wieder mal ne License-Geschichte, wie üblich?


PMc schrieb:
... Container für FreeBSD bereitzustellen. Oder halt auch nicht.
Zum Vergrößern anklicken....
idealerweise müsste es dann auch sowas wie hub.docker.com oder docker.io für die BSD Container geben, z.B. ein hub.bsdoci.org, um die ganze Containerei wie unter Linux/Docker zu vereinfachen - oder war die OCI Runtime Extension dazu gedacht, bestehende (Linux)Docker-Container einfach nutzen zu können? (Diese Info hab ich aus dem Video leider nicht entnehmen können, habs aber vllt auch nur übersehen)
 
turrican schrieb:
weiß man warum?
Zum Vergrößern anklicken....
Man vielleicht, ich nicht so recht.

turrican schrieb:
wieder mal ne License-Geschichte, wie üblich?
Zum Vergrößern anklicken....
Nein. das eigentlich gar nicht. Vordergründig ne Support-Geschichte. Also, Motto, wir supporten nur genau das XYZ-Linux mit dem UVW-Container und unsere Anwendung darin. Das wäre natürtlich nebensächlich, denn wenn etwas als OpenSource ohne Bezahlung zu kriegen ist, dann erwarte ich eh keinen Support. Oder anders gesagt, wer Lust dazu hat, kann sich dann ja seinen Support für welche-Konfiguration-auch-immer selber machen.
Das mögen sie aber auch nicht, genauer gesagt, das löschen sie im Zweifelsfall als unwillkommen.
Und damit ist dann bei mir der Buckel-runter-rutschen Punkt erreicht. Irgendwann vor langer Zeit hab ich für mich beschlossen, dass ich PHP nicht mag und Ruby-on-Rails mag, und hab mir immer ein Webforum gewünscht, das auf RoR läuft. Dieses ist allerdings ein Riesenbiest und hat ziemlich viele Design-Features, die ich so lieber nicht haben wollte. Also hab ich nur mal geschaut und festgestellt: es kann auf FreeBSD laufen.

turrican schrieb:
idealerweise müsste es dann auch sowas wie hub.docker.com oder docker.io für die BSD Container geben, z.B. ein hub.bsdoci.org, um die ganze Containerei wie unter Linux/Docker zu vereinfachen
Zum Vergrößern anklicken....
Ja, das wird man vielleicht brauchen. Aber das ist nicht meine Baustelle - ich bin old-school und brauche -für meine Zwecke- gar nicht unbedingt Container. Ich bin nur damit konfrontiert, dass zB etwas -im negativen Sinn- nur mit Container genutzt werden soll, oder auch -im positiven Sinne- dass die Doku für die Container-Installation die einzige ist, die technische Details über zB die Netzwerk-Integration verrät (weil die anderen Dokus i.W. auf "klicke 'Installieren' und beobachte den Balken" hinauslaufen).
 
PMc schrieb:
Man vielleicht, ich nicht so recht.
Zum Vergrößern anklicken....
:D

PMc schrieb:
Ja, das wird man vielleicht brauchen. Aber das ist nicht meine Baustelle - ich bin old-school und brauche -für meine Zwecke- gar nicht unbedingt Container.
Zum Vergrößern anklicken....
Generell finde ich die Container-Idee nicht schlecht, etwas mehr Security täte halt gut (aber das ist ja nicht das Problem vom OCI an sich sondern der einzelnen Implementierung, hallo dockerd) - und, vor allem: kann ich den Docker-Images aus dem Netz wirklich trauen? Gut, ich könnte Images selber stricken, aber Zeit ist immer noch Geld und wenns schon ein fertiges Image für Anwendung xy im Netz gibt...

Auch ist ein "FreeBSD owned trusted Base-Image" gefordert, wie Doug Rabson es hier in diesem Talk auf dem 2024 FreeBSD Developer Summit in den ersten Minuten anspricht.
 
Ich würde sagen, dass zum derzeitigen Zeitpunkt viele Dinge einfach nicht geklärt sind, weil das Projekt noch zu jung ist. Man hat nun mit Podman <-> Buildah <-> ocijail eine Implementierung, mit der man testen und Erfahrungen sammeln kann. Daraus muss erst einmal eine Spezifikation werden, damit alle Parteien wissen, was FreeBSD Container von ihrer Runtime erwarten können und wie sie sich gegenüber der Runtime verhalten. Die Spezifikation macht es wohl möglich, zumindest verstehe ich es so, dass man FreeBSD-Unterstützung in das OCI-Ökosystem bringen kann. Das wäre als wohl größer Brocken K8S, womit man dann Orchestrierung hätte.

Die Spezifikationen sind gar nicht so komplex. Die Kunst dürfte eher sein, es für alle Zeiten richtig und korrekt hinzubekommen, als sich überhaupt was zu überlegen. Zum Beispiel Linux und Windows. Das dürfte auch gleich ein großer Schritt in Richtung Container für die anderen BSDs sein, wobei sich bei NetBSD und OpenBSD natürlich das Problem stellt, dass es dort keine Jails gibt und man daher die für FreeBSD geschriebene Runtime nicht übernehmen kann.

Linux-Images auf FreeBSD würde bedeuten, dass man die Linux-Spezifikation irgendwie auf FreeBSD implementiert. Das sieht mit dem Linuxulator nicht unmöglich aus, aber man müsste wohl einige optionale Teile der Spezifikation weglassen. FreeBSD hat halt keine cgroups und auch kein funktionales Äquivalent, was eine Implementierung in den Linuxulator schwer macht. seccomp dürfte ähnlich sein und so weiter. Und da ist man dann schnell bei der Frage, wie sinnvoll das ist. Ich würde aus dem Bauch heraus in der Praxis eher zu hybriden K8S Clustern tendieren, mit FreeBSD Nodes für FreeBSD Container und Linux Nodes für Linux Container. Genauso, wie man meist Windows Coontainer integriert.

Registry ist auch so ein Thema. Optimal wäre es wohl, wenn das FreeBSD Projekt selbst eine sozusagen offiziellere FreeBSD-Registry hosten würde. Aber im Projekt hat man irgendwo verständlicherweise Hemmungen, sich noch mehr Dienste ans Bein zu binden, denn das braucht halt auch alles Ressourcen und Manpower. Bei einer Registry kommt noch dazu, dass prinzipbedingt letztendlich jeder Hansel beliebige Images hochladen kann und sich kaum überprüfen lässt, was da drin steckt. Woraus juristische Verantwortung resultiert, das erste DCMA Takedown Request dürfte eine Frage von Wochen sein
 
Also, ich sags mal so (IMHO):

  • Es wäre ein absoluter Gamechanger, wenn ich dadurch unter FreeBSD auf das existierende Linux-Docker-Ökosystem inklusive existierender Images zugreifen kann. Und dann schön integriert als Jails? Das würde ganz neue Argumentationsgrundlagen für FreeBSD als Server im Firmenkontext ergeben und mir zB erlauben sofort meinen Arbeitslaptop auf FreeBSD zu migrieren. Auch privat würde ich mich freuen, einfacher experimentieren zu können mit bestimmten Diensten auf meinem Homeserver.
  • Ohne Support für Linux container sehe ich allerdings garkeinen Wert darin. Ist ja nicht so, dass der Tech-Stack an sich besonders toll ist, der Nutzen kommt doch daher, dass er weit verbreitet ist.
 
Yamagi schrieb:
Linux-Images auf FreeBSD würde bedeuten, dass man die Linux-Spezifikation irgendwie auf FreeBSD implementiert. Das sieht mit dem Linuxulator nicht unmöglich aus, aber man müsste wohl einige optionale Teile der Spezifikation weglassen.
Zum Vergrößern anklicken....
Doug geht in dem oben genannten Talk (bei ca. 1:15+) auf diese Frage ein, ob und wie er aktuell Linux-Container zum Testen auf FreeBSD laufen läßt - er nutzt seiner Aussage nach dazu "die in FreeBSD enthaltene Linux-emulation"; es laufen wohl erstaunlich viele Container erfolgreich damit, außer natürlich diejenigen, welche Linux-spezifisches benötigen, wie z.B. die angesprochenen cgroups, spezielle Treiber, etc

Yamagi schrieb:
Registry ist auch so ein Thema.
Zum Vergrößern anklicken....
darauf geht er auch an mehreren Stellen des Talks ein, er sieht da etliche Möglichkeiten, z.B. eine eigene (z.B. "registry.freebsd.org") oder die Nutzung von den etablierten wie docker.io, quay oder ghcr
 
  • Like
Reaktionen: h^2
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben