© Ivan Smuk,123RF

Fast unbemerkt vollzieht sich in der Container-Welt gerade eine Wachablösung: Das zuvor gesetzte Docker weicht der CRI-O-Umgebung Podman. Wie wirkt sich das auf den IT-Alltag aus, was merken Admins davon?

Container haben im Kontext von Linux eine wechselvolle Geschichte hinter sich. Das Prinzip per se ist ja nicht neu, ganz im Gegenteil: Container gab es lange vor Linux bereits als Konzept, und auch die ersten echten Container-Implementierungen für Linux sind älter, als so mancher Admin glauben möchte.

Erinnert sei etwa an OpenVZ, das bereits Anfang der 2000er-Jahre erst als Konzept und dann als konkrete Implementierung vorlag. Bald schon ließ “echte” Virtualisierung in Form von Xen & KVM die Container hinter sich, und es wurde ruhig um das Konzept. Daran änderten auch die Linux-Container (LXC) nichts, die zwischenzeitlich aufkamen, aber nie nennenswerte Marktdurchdringung für sich beanspruchen konnten.

Dafür gibt es freilich gute Gründe: Eine Container-Implementierung an sich genügt kaum, um Administratoren glücklich zu machen. Komplementär dazu ist eine Laufzeitumgebung nötig, idealerweise mit der Möglichkeit, fertige Container über ein standardisiertes Protokoll zu verteilen. Nur so wird auch ein Schuh daraus: Wenn der Admin einen Container ebenso herrichten muss, wie es bei einer virtuellen Maschine der Fall wäre, ergibt sich kein Mehrwert. Lässt sich ein neuer Container jedoch schnell mit wenigen Befehlen auf der Kommandozeile starten, erspart das dem Admin viel Arbeit.

Docker legt los

Docker hat das als Unternehmen frühzeitig erkannt. Unter dem eigenen Namen entwickelte man eine Laufzeitumgebung für Container, die über Jahre zum Synonym für Container unter Linux (und später sogar unter Windows und MacOS) werden sollte.

Einerseits war es kinderleicht, Hosts für den Betrieb von Docker-Containern herzurichten. In der Regel genügte es, »docker-ce« aus dem Repository des Herstellers zu installieren, um einen Server fit für Container zu machen. Andererseits schuf Docker schnell ein lebendiges Ökosystem: Docker Hub dient bis heute als zentrale Anlaufstelle für Images aller Art, die regelmäßig auch von den Distributoren stammen – also aus erster Hand. Nicht nur der Image-Dienst ist eine echte Docker-Errungenschaft, sondern auch die Definition eines Paketformats für Container, die zentrale Dienste wie Docker Hub überhaupt erst möglich machte.

Letztlich dominierte Docker über Jahre hinweg die Schlagzeilen in Sachen Linux und Container, und vermutlich hätte sich das auch nicht geändert, hätte man sich in San Francisco nicht mit den Falschen angelegt.

Erst Freund …

Die gemeinsame Geschichte von Red Hat und Docker begann äußerst verheißungsvoll, besonders für Docker, das damals noch unter dotCloud Inc. firmierte. Im Jahr 2013 verpartnerten sich die beiden Unternehmen, und Red Hat nutzte Docker als integralen Bestandteil seiner PaaS-Umgebung OpenShift. Mitte 2015 bewerteten Investoren Docker erstmals als Unicorn Company, also als Firma mit einem Marktwert von mehr als einer Milliarde Dollar. Auch Microsoft hatte man zwischenzeitlich als Partner mit ins Boot geholt.

Womöglich bekam der Firma der eigene Ruhm nicht gut. Bald schon kamen jedenfalls erste Stimmen auf, die die völlige Dominanz des Linux-Container-Markts durch Docker nicht guthießen. Der Hersteller tat nicht viel, um solche Zweifel zu zerstreuen.

… dann Feind

Eigentlich eine Lappalie führte letztlich dazu, dass Red Hat sich langsam von Docker abzuwenden begann: Zwischen den Entwicklern der beiden Firmen entbrannte ein Streit um einen kleinen technischen Teilaspekt von Containern. Im Fokus stand dabei das Container-Format, das ursprünglich Docker selbst entwickelt hatte.

Docker-Container bestehen aus zwei Teilen: Neben einem Tarball mit dem eigentlichen Dateisystem enthalten sie eine JSON-Datei mit Informationen über den Container-Inhalt sowie über dessen Konfiguration. Das Problem vor ein paar Jahren war, dass das Docker-Programm auf der Kommandozeile nicht die Möglichkeit bot, die JSON-Datei eines Containers anzuzeigen, ohne diesen aus dem entfernten Verzeichnis herunterzuladen. Wollte der Admin also wissen, welche Konfiguration ein bestimmter Container in Docker Hub hat, musste er dazu auch den kompletten Tarball herunterladen und konnte sich erst dann lokal die Informationen anzeigen lassen. Docker-Abbilder haben oft etliche Hundert Megabyte Umfang, die herunterzuladen für die einfache Anzeige der Container-Metadaten nicht sinnvoll ist.

Bei Red Hat tat man, was man dort in solchen Situationen immer tut: Weil Docker als Open-Source-Software firmierte, sandten die roten Hüte einen Patch ein, der »docker« um einen entsprechenden Parameter erweitert hätte. Den lehnten die Docker-Entwickler jedoch ab: Man wolle die CLI von Docker nicht unnötig verkomplizieren. Letztlich sei Docker Hub ein ganz normaler Webserver – wolle Red Hat die gewünschte Funktion also unbedingt haben, könne man sie in Form eines kleinen Programms ja selbst so implementieren, wie gewünscht.

Das ließ sich Antonio Murdaca von Red Hat nicht zwei Mal sagen, und kurze Zeit später entstand die erste Version von Skopeo [2]. Retrospektiv betrachtet, darf man wohl annehmen, dass diese Lappalie den Abstieg Dockers mit einleitete. Zwar gab man es in Raleigh nicht zu, doch dieser Vorgang weckte ernsthafte Zweifel daran, dass Docker ein verlässlicher Partner bleiben würde.

Und wieder tat Red Hat, was das Unternehmen in solchen Fällen üblicherweise tut: Behutsam, aber äußerst konsequent begann man damit, sich Verbündete für einen alternativen Ansatz zu suchen.

Die CNCF entsteht

Das war nicht besonders schwierig, denn auch andernorts hatte man längst damit begonnen, Dockers Vormachtstellung sehr kritisch zu hinterfragen. Zudem war mittlerweile auch klar, dass Container alleine nicht glücklich machen. Nur in Kombination mit einem zuverlässigen Orchestrierer waren Workloads sinnvoll in Container-Umgebungen zu betreiben. Im Hinblick auf Runtimes war der Zug aus Sicht von Docker aber längst abgefahren, denn hier war Google mit Kubernetes bereits 2015 praktisch omnipräsent. Dockers späterer Versuch, Docker Swarm als Antwort auf Kubernetes zu positionieren, scheiterte furios.

Zusammen mit Kubernetes 1.0 veröffentlichte Google 2015 Pläne für eine Cloud Native Computing Foundation, die unter das Dach der Linux Foundation schlüpfen sollte. Alle relevanten Unternehmen der Branche gehörten der neuen Stiftung von Anfang an an, darunter Red Hat, IBM, VMware und Intel, und auch Docker zählt zu den Gründungsmitgliedern der CNCF.

Technisch trug Docker sogar erheblich zur CNCF bei: Bereits Anfang 2015 hatte man das eigene Container-Format der Linux-Foundation geschenkt, die es zunächst zur Spezifikation der Open Container Initiative machte. Die OCI ging später in der CNCF auf, der Name der Spezifikation hat sich allerdings nicht geändert. Wenn heute also von OCI-Containern die Rede ist, bezieht sich das noch immer auf das Format, das ursprünglich von Docker kam.

Medial präsentierte Docker sich seinerzeit freilich als edler Ritter im Kampf um offene Standards und freie Software. Doch man darf wohl davon ausgehen, dass Docker auch klar war, dass es vollkommen sinnlos gewesen wäre, gegen die CNCF mit quasi allen Riesen der Branche anzutreten. Wohl auch nach dem Motto “Halte deine Freunde eng, halte deine Feinde enger” schickte Docker sich an, künftig Teamplayer zu sein.

In Raleigh hatte man die einstigen Eskapaden indes nicht vergessen. Obendrein war Red Hat mittlerweile klar geworden, dass die Zukunft von Containern (und implizit auch von OpenShift) nicht Container per se sein würden, sondern deren Nutzung in Kubernetes (Abbildung 1). Im Rahmen der CNCF erarbeitete man deshalb eine auf OCI basierte Laufzeitumgebung für Container, die speziell an die Bedürfnisse von Kubernetes angepasst ist. Sie trägt den Namen Podman [1].

Abbildung 1: Der primäre Grund, Podman zu entwickelt, ist die bessere Kompatibilität mit Kubernetes. Quelle: Red Hat

Über den Umweg von RHEL 8, CentOS 8 und OpenShift kommt Podman mittlerweile auch im Alltag an. Für alle gängigen Distributionen stehen zudem passende Pakete bereit. Was sind also die zentralen Unterschiede zwischen Docker und Podman, und womit müssen Admins rechnen? Höchste Zeit, sich mit diesen Fragen einmal zu beschäftigen.

Container-Grundlagen

Um die Unterschiede zwischen Podman und Docker zu verstehen, ist es nötig, zunächst auf die Gemeinsamkeiten einzugehen. Beide Lösungen nennen sich völlig zu Recht Laufzeitumgebung (runtime environment) für den Betrieb von Containern. Podman fokussiert aktuell auf Linux, während Docker auch MacOS und Windows unterstützt. Auf anderen Betriebssystemen bildet Docker dabei Sicherheitsfeatures nach, die der Linux-Kernel implementiert.

Das ist bei Laufzeitumgebungen für Container immer so: Die eigentliche Funktion steckt im Kernel; die Laufzeitumgebungen kombinieren die Features lediglich so miteinander, dass für Admins echter Mehrwert entsteht. Die maßgeblichen Features des Linux-Kernels im Container-Kontext sind einerseits Cgroups und andererseits Namespaces (Letztere für verschiedene Instanzen wie Netze, Dateisysteme oder Prozess-IDs). Aus diesem Werkzeugkasten bedienen Docker und Podman sich in nahezu gleicher Art und Weise.

Massive Unterschiede

Die Art der Implementierung unterscheidet sich zwischen Docker und Podman allerdings deutlich. Einer der größten Unterschiede, der Docker im Verlaufe der Jahre immer wieder auch heftige Kritik eingebracht hat, ist der Docker-Daemon »dockerd«, der auf jedem Docker-System notwendig ist (Abbildung 2). Eingefleischte Linux-Admins rümpfen bekanntlich schnell die Nase, wenn sie vermeintlich überladenes Engineering wittern. Schnell ist dann vom Bloat die Rede, und genau diesem Vorwurf sieht der Docker-Daemon sich seit Jahren immer wieder ausgesetzt.

Abbildung 2: Ohne Daemon geht es nicht: Bei Docker läuft stets auf jedem Host der Docker-Daemon mit, der sich um alle Container kümmert. Quelle: Docker

Die ursprüngliche Idee hinter dem Daemon war es, eine Instanz auf dem System zu haben, die für alle laufenden Container verantwortlich ist. Dockerd startet und stoppt also Container auf Zuruf des Admins. Er bietet auch eine API-basierte Schnittstelle an, um eine Steuerung von außen zu erlauben. Ruft der Admin auf der Kommandozeile »docker« auf, startet er eigentlich genau diesen Client, der dann per API mit »dockerd« kommuniziert.

Das finden viele Admins zu umständlich, zumal der Docker-Daemon nicht selten Ärger macht: Viele Admins berichten etwa genervt davon, dass der Betrieb des Docker-Daemon auf ihren Systemen die komplette Leistung ganzer CPU-Kerne abzapft. Podman verfolgt in der Tat einen gänzlich anderen Ansatz. Einen Daemon sucht der Admin hier vergebens, stattdessen funktioniert das Podman-Binary per »fork()«, wenn es einen Container starten soll (Abbildung 3). Unter der Haube nutzt Podman dafür »runc«, das den eigentlichen Betrieb des Containers steuert und die Runtime-Spezifikation der OCI auf dem jeweiligen System implementiert.

Abbildung 3: Podman nutzt, anders als Docker, das Fork-Prinzip und braucht deshalb keinen Daemon. Quelle: Red Hat

Theoretisch würde dadurch eine Funktion fehlen, die der Docker-Daemon in den dortigen Umgebungen übernimmt: die Überwachung laufender Container. Startet der Admin per CLI explizit einen Container, soll der zum einen laufen und zum anderen je nach Konfiguration neu gestartet werden, falls er abstürzt. Zumindest möchte der Admin aber zeitnah davon erfahren, wenn Container abstürzen, um nötigenfalls Gegenmaßnahmen einzuleiten. An jeden Container, den es startet, hängt Podman deshalb ein kleines Programm namens »conmon« an. Es überwacht die wichtigsten Vitalwerte und ergreift Gegenmaßnahmen, falls etwas schiefläuft.

Container ohne Root

Kritik üben Admins an Docker regelmäßig auch deshalb, weil dessen Daemon bis Mitte 2019 mit den Rechten des Benutzers Root laufen musste. Eine ganze Weile galt das sogar für die Container selbst, im Docker-Sprech Privileged Container genannt.

Das ist mittlerweile zwar Schnee von gestern. Unprivilegierte Container gibt es in Docker schon lange, und seit der Version 19.03 – immerhin auch schon wieder ein ganzes Jahr alt – lässt der Daemon in Docker sich komplett ohne Root-Rechte betreiben.

Podman implementierte die Rootless-Funktion allerdings von Anfang an, was Admins zum Teil bejubelten: Berechtigungen, die eine Anwendung auf einem System nicht hat, lassen sich im Falle eines Einbruchs auch nicht durch den Angreifer missbrauchen.

Viele Gemeinsamkeiten

Zwar unterscheiden Podman und Docker sich im Hinblick auf ihr Design erheblich, doch merken Administratoren davon vermutlich nicht allzu viel. Insbesondere das Programm »podman« funktioniert auf der Kommandozeile zum allergrößten Teil exakt so, wie Admins es von »docker« gewohnt sind.

Wer etwa die Logs eines Containers anschauen möchte, der benutzt auf Systemen mit Docker den Befehl »docker logs Container« und auf Systemen mit Podman »podman logs Container«. Auch die Syntax zum Ausführen von Befehlen in Containern ist bei Podman und Docker identisch. Der Aufruf »podman exec -i -t Container /bin/bash« führt also zum selben Resultat, zu dem der gleichlautende Befehl mit »docker« führt.

Aus Nutzersicht extrem wichtig: Podman beherrscht den Umgang mit Images für Docker. De facto lassen sich dadurch sämtliche Images aus Docker Hub nahtlos in Podman verwenden. Auf Zuruf lädt Podman sie auch unmittelbar von Docker Hub herunter. Der Aufbau einer Parallelwelt zu Docker Hub für Podman-Images entfällt insofern. Das ist auch kommerziell sehr wichtig: Müssten die großen Distributoren oder die Anbieter von Software beim Image-Bau eine zweite Container-Lösung beachten, wäre das ein Mehraufwand. Den würde sich vermutlich längst nicht jeder Anbieter antun.

Durchaus bemerkenswert bei Podman ist, dass sich dessen Container per Unit-Datei in Systemd integrieren lassen. Ein Container funktioniert dann im Grunde wie ein typischer Daemon, der beim Systemstart hochfährt und beim Herunterfahren des Systems automatisch beendet wird. Obendrein lassen sich Podman-Container dank der Systemd-Integration über Systemctl steuern und ihr Status mit demselben Tool überwachen.

Podman mit eigener Toolchain

Die bloße Container-Umgebung genügt in der Regel nicht, um den Admin glücklich zu machen. Das gilt schon für Docker: Für den sinnvollen Betrieb von Containern ist mehr nötig als nur »docker« auf der Kommandozeile.

Regelmäßig werden Unternehmen eine Build-Pipeline für eigene Container bauen wollen, an deren Ende fertige Abbilder für den produktiven Betrieb aus der CI/CD-Umgebung fallen. Dafür braucht es aber ein entsprechendes Werkzeug, das den Bau der Container übernimmt. Podman greift dem Admin hier mit Buildah [3] unter die Arme – falls dem nicht ohnehin schon der Befehl »podman build« in Kombination mit einem Dockerfile genügt: Die von Docker stammenden Dockerfiles kann Podman ebenfalls lesen und benutzen.

Buildah allerdings geht mehrere Schritte weiter. Es ermöglicht dem Admin die Konstruktion eines nagelneuen Containers von Anfang an. Das ist vorrangig in Umgebungen hilfreich, in denen die Images so klein wie möglich ausfallen sollen. Der verbreitetere Ansatz ist es, ein Basis-Abbild von Ubuntu oder Red Hat zu verwenden und die eigene Applikation darin zu integrieren. Generische Container schleppen freilich einigen Ballast mit sich herum, der längst nicht in jedem Umfeld benötigt wird.

Skopeo: Hilfreiches Fernglas

Nicht unter den Tisch fallen soll bei der Übersicht der Podman-Tools das vorher schon erwähnte Skopeo. Es hat sich in der Podman-Welt fest als dasjenige Werkzeug etabliert, mit dem sich Informationen über Images aus entfernten Container-Registrys besorgen lassen. Dafür steht übrigens auch der Name, denn Skopeo leitet sich aus dem Altgriechischen her und heißt so viel wie “in die Ferne schauen”.

Mittlerweile kann Skopeo jedoch noch deutlich mehr als das: Es lädt beispielsweise auf Kommando ein Image aus einer Container-Registry herunter und kopiert es in eine andere. Es begibt sich außerdem anhand der Vorgaben des Admins in entfernten Docker-Repositories auf die Suche nach bestimmten Abbildern.

Gesucht: Eine eigene Registry

Praktisch lassen sich mit Skopeo die Inhalte einer Registry oder eines bestimmten entfernten Repositories (etwa des Docker Hub) in eine andere Registry kopieren. Das ist vorteilhaft, wenn man vor Ort eine große Flotte von Servern nutzt, auf denen dieselben Podman-Container laufen sollen. Dann betreibt man eine lokale Docker-Registry und erspart sich so das fortwährende Herunterladen der Inhalte. Zwar wäre das Problem auch mittels eines cachenden Proxy-Servers zu lösen, doch die Skopeo-Lösung ist viel eleganter: Sie vermag Aspekte wie Image-Tags in Betracht zu ziehen.

Hier stößt der Admin allerdings auf ein eher unschönes Loch in der Podman-Toolchain. Einen Dienst, der eine lokale Container-Registry betreiben könnte, sucht man in der Podman-Welt aktuell vergebens. Will man eine eigene Container-Registry, bleibt nur der Umweg über den dafür von Docker selbst angebotenen Dienst oder über eine Drittanwendung wie etwa jene in GitLab. Damit sind Podman, Skopeo und Buildah zwar wie beschrieben kompatibel, doch schöner wäre es, böte Red Hat hier etwas von der Stange an. Ein entsprechendes kommerzielles Produkt gibt es in Form von Red Hat Quay ja schon.

Sieht man von der fehlenden Registry einmal ab, wird jedoch schnell klar: Podman vermag Docker praktisch vollständig zu ersetzen. Dass genau das auch Red Hats Ziel war, darf als sicher gelten.

Eingebettet in Kubernetes

Sich mit Podman zu beschäftigen, bedeutet implizit auch, sich mit Kubernetes zu beschäftigen (Abbildung 4). Die große Nähe steckt bei Podman schließlich schon im Namen: Pods sind ja eigentlich eine zentrale Erfindung aus dem Kubernetes-Universum. Der Begriff meint dort mehrere Container mit jeweils einzelnen Applikationen, die auf denselben Servern laufen.

Abbildung 4: Ohne Kubernetes ergibt der Betrieb von Software im Container kaum Sinn – der Container-Orchestrierer ist mittlerweile praktisch ubiquitär. Quelle: Kubernetes

Im Kontext von Podman stoßen Admins immer wieder auch auf die Bezeichnungen OCI und CRI-O. Eine Einführung in Podman wäre nicht vollständig, ginge sie auf diese beiden zentralen Begriffe nicht auch ein. Wer sich mit Containern befasst, hat fast immer auch mit Kubernetes und damit mit OCI und CRI-O zu tun.

Docker verdankt seine Popularität vorrangig der Tatsache, dass es als erste vollständige Laufzeitumgebung für Container in Linux zur Verfügung stand. Als Google vor Jahren mit der Kubernetes-Entwicklung begann, legte man sich schnell auf die Docker-Umgebung als Ziel fest. Auf diese Weise musste Google das Rad (erst einmal) nicht neu erfinden. Von Anfang an waren Docker und Kubernetes auf diese Weise eng miteinander verknüpft – zu eng, wie manche in der Community befanden.

Kaum zu integrieren

Die enge Verwandtschaft von Kubernetes und Docker sorgte dafür, dass es extrem schwierig war, andere Laufzeitumgebungen in Kubernetes zu integrieren. Genau das war aber Red Hats Ziel. Schließlich hatte man mit Podman viel vor, aber dafür musste die Integration in K8s funktionieren. Also drehte Red Hat ein weiteres Mal am ganz großen Rad und rief Anfang 2017 innerhalb der CNCF CRI-O ins Leben.

CRI-O steht für Container Runtime Environment – OCI und ist eine Schnittstellendefinition für den Container-Orchestrierer Kubernetes. Die Idee: Jede Laufzeitumgebung für Container, die dem CRI-O-Standard folgt, lässt sich modular in Kubernetes ohne Anpassungen an dessen Code nutzen. K8s selbst verwendet stets CRI-O als Laufzeit, und der Admin definiert die gewünschte Laufzeitumgebung als eine Art Treiber in CRI-O. Auf diese Weise gelingt es mittlerweile sogar, unterschiedliche Laufzeitumgebungen im selben Kubernetes-Cluster auf unterschiedlichen Hosts zu verwenden, wobei dieser Einsatzfall im Alltag freilich recht selten vorkommt.

Die Kombination aus Kubernetes und CRI-O mit Podman hingegen gilt in der Red-Hat-Welt mittlerweile als Standard. Da Podman selbst den Betrieb von Pods übernehmen kann, wandert ein Teil der Funktionalität aus dem »kubelet«-Dienst auf den Zielsystemen dann auch hin zu Podman.

Der Rest ist Geschichte: Mittlerweile unterstützt Kubernetes CRI-O und Docker im selbem Umfang. Dank der CRI-O-Definition und Podman lässt sich ein kompletter Kubernetes-Cluster vollständig ohne Docker betreiben (Abbildung 5). Letztlich hat Red Hat sein Ziel also erreicht und darf sich technisch wie kommerziell als Gewinner im Kräftemessen betrachten.

Abbildung 5: OpenShift ist Red Hats Kubernetes-Distribution. In seiner aktuellen Form wäre das Produkt ohne Podman kaum denkbar. Quelle: Red Hat

Fazit

Podman ist Docker technisch eigentlich nicht überlegen. Die große Mehrzahl aller Funktionen finden sich in beiden Ansätzen, und an diversen Stellen achten die Podman-Entwickler ausdrücklich auf Docker-Kompatibilität. Hier kommt dem Programm seine Erfolgsgeschichte zugute, denn lange Zeit waren Container in Linux und Docker quasi dasselbe. Docker hat trotzdem ein Problem, denn Podman geht als Container-Plattform unter dem Schutz von Red Hat ins Rennen. Es kommt selbst außerhalb des Cloud- und Container-Umfelds bei RHEL 8 an vielen Stellen zum Einsatz.

Der Trend geht ganz klar in die Richtung, das Betriebssystem auf das absolut notwendige Minimum zu beschränken. Alle relevanten Dienste laufen dann in Form von Containern. Sogar eigene Paketformate stehen dafür bereits zur Verfügung, nämlich Flatpaks im Red-Hat-Universum und Snaps in der Ubuntu-Welt.

Wenn die eigene Distribution aber schon mit einer ausgesprochen leistungsfähigen Container-Lösung daherkommt, gibt es letztlich keinen Grund mehr, Docker als externe Zusatzkomponente zu installieren. Obendrein liefert Red Hat Support für Podman als Bestandteil des Supports für RHEL 8 selbstverständlich mit, während man für Docker einen eigenen Support-Vertrag bräuchte und somit auch der Vorteil des “Single Point of Contact” in Support-Fragen wegfiele. Düstere Aussichten also für Docker.

Admins tun indes gut daran, sich mit Podman zeitnah vertraut zu machen. Dessen Kommandozeilensyntax ist weitgehend kompatibel zu Docker; wer also schon einmal mit Docker gearbeitet hat, findet sich in Podman leicht zurecht. Zumindest im Red-Hat-Universum darf Podman als künftiger Standard für den Betrieb von Containern als gesetzt gelten. (jcb/jlu)