Eigene lokale Docker Registry -> Unraid sagt "Not Available" zum Versionsstand?

[Crovaxon]

Moin,

 

in meinem Eigeninteresse als Entwickler hab ich mich mal mit Docker Registry im Selbstbetrieb beschäftigt...
Betreibe den Docker Registry aus den CA als Container, vorerst als insecure Registry da ich mich damit nur im lokalen Umfeld erstmal auseinander setzen will bevor ich überlege, den auch von außen erreichbar zu machen, nur zur Info falls das relevant sein sollte.

Mit entsprechendem insecure repository Eintrag kann ich soweit ohne Probleme meine Images taggen und pushen von meinem PC zum Registry Container und meine Unraid Maschine kann mit händisch erstelltem Eintrag im Docker Tab auch problemlos von dieser Registry laden und Container starten - soweit so gut!

 

Was ich jetzt nach längerem Betrieb festgestellt habe... Der Versionsstand bei diesen händischen Containern wechselt früher oder später zu "Not Available" und ich bin bislang beim Recherchieren nicht ganz schlau draus geworden, woran das liegt.

 

Ich erstelle meine Docker jetzt bislang ohne tag, also default ist dann ja "latest", was ja wohl auch der tag ist, den beim Pullen des Images während der Container Erstellung ja auch standardmäßig verwendet wird wenn keiner angegeben wird.
Also halt "lokal Docker build -> auf Registry taggen -> auf Registry pushen".

Wenn ich neue Versionen pushe, ändert sich auch nix am "Not Available" wenn ich auf updates prüfe.

Wenn ich vor habe den Container zu aktualisieren, muss ich das immer via Force Update machen, das klappt dann aber auch.

Liegt das Problem irgendwo bei meinen gebauten Images, oder an den Einstellungen der Registry? Irgendwas im Container Template auf Unraid's Seite das gemacht werden muss?

Oder klappt Unraid's Container Update Check nur mit DockerHub gehosteten Images? Bin da beim Hinterher googlen auf nichts konkretes gestoßen.

[SvenRoettjer]

Habe das gleiche Problem mit meiner selbst gehosten Registry und eigenen Containern. Hast Du schon eine Lösung dafür? :-)

[Squid]

I believe this might be fixed on the next release (7.0) of the OS.   Can’t 100% remember though

[Crovaxon]

18 hours ago, SvenRoettjer said:

Habe das gleiche Problem mit meiner selbst gehosten Registry und eigenen Containern. Hast Du schon eine Lösung dafür? 🙂

Ne bislang noch nicht. Bisherige Vermutung ist, dass die registry hinter https abgesichert sein muss, meine läuft über http, also insecure.

2 hours ago, Squid said:

I believe this might be fixed on the next release (7.0) of the OS.   Can’t 100% remember though

Is there any thread about that? Would be very interested to keep an eye on this. Might this be because of my registry being insecure? It's all running purely local so I did not bother securing it via SSL cert nor am I operating a local DNS for my LAN space where I could put registry for secure access behind.
Additionally I am still a greenhorn when it comes to docker creation, so I am also not sure if I have to observe anything specific about image tags or so for Unraid's image versioning to properly pick up that there is a newer version in the registry. Is anything more than just tagging it latest required?

[SvenRoettjer]

5 hours ago, Crovaxon said:

Ne bislang noch nicht. Bisherige Vermutung ist, dass die registry hinter https abgesichert sein muss, meine läuft über http, also insecure.

 

Danke für die schnelle Antwort. So (insecure) betreibe ich die registry eben auch. Aktuell ignoriere ich das "not available" einfach weg 😉

[ich777]

On 3/5/2024 at 12:23 PM, Crovaxon said:

Liegt das Problem irgendwo bei meinen gebauten Images, oder an den Einstellungen der Registry?

Welche Registry nutzt du denn, ich hab hier keine Probleme mit images aus meiner Gitea Registry (ist aber auch nicht insecure), da werden updates automatisch angezeigt, auch gepullt auf der Docker Seite sowie auch automatisch aktualisiert.

 

On 6/18/2024 at 8:31 PM, SvenRoettjer said:

mit meiner selbst gehosten Registry

Darf ich fragen warum du die Registry denn überhaupt ohne Zertifikat betreibst?

 

Wie bindet ihr die Container in Unraid ein, sprich was tragt ihr beim Repository ein?

 

 

22 hours ago, Squid said:

remember

Nice profile picture, looks like a possible future staff member drawed this.

[Crovaxon]

40 minutes ago, ich777 said:

Welche Registry nutzt du denn, ich hab hier keine Probleme mit images aus meiner Gitea Registry (ist aber auch nicht insecure), da werden updates automatisch angezeigt, auch gepullt auf der Docker Seite sowie auch automatisch aktualisiert.

Docker Registry, auch in den community apps verfügbar.

 

43 minutes ago, ich777 said:

Darf ich fragen warum du die Registry denn überhaupt ohne Zertifikat betreibst?
 

Wie bindet ihr die Container in Unraid ein, sprich was tragt ihr beim Repository ein?

Einfach add container, als repository "localhost:5000/imagename" und halt Rest ausfüllen wie es das eigene Image unterstützt

Und ich persönlich hab da einfach nicht die Notwendigkeit gesehen, da ein Zertifikat vorzusetzen, wenn ich die Registry gar nicht außerhalb meines LANs ansprechen kann/will.
Wenn ich das je mal exposen möchte, würde ich das eh über einen Reverse Proxy machen, der macht dann TLS.

Zumindest Unraid selbst bzw. andere container können ja direkt mit dem Registry Container reden.

[ich777]

15 minutes ago, Crovaxon said:

Docker Registry, auch in den community apps verfügbar.

Die hatte ich mir auch angesehen aber die hab ich für "zu wenig" empfunden für mich persönlich und da Gitea das auch kann spielt mir das sowieso in die Karten.

 

16 minutes ago, Crovaxon said:

localhost:5000/imagename

Hast du schon mal probiert nicht localhost zu nehmen sondern die IP von deinem Server? Ich könnte mir unter umständen vorstellen das dies Probleme macht.

Probier auch evtl. mal das du dem Docker container eine Fixe IP gibst bzw. eine andere IP.

 

Ich für meinen Teil bau hier auch alles lokal am Server aber ich mach das vermutlich ganz anders als du.

Privates Git -> synchron mit GitHub, Jenkins mit dem Plugin CloudBees Docker Build & Publish und LXC container

 

Workflow sieht so aus:

1. Entweder manuelles starten des builds, Zeitgesteuerter Start, Trigger basierter Start oder sogar duch Webhook (für ausgewählte Container) in Jenkins
2. Repo wird von Gitea gepullt
3. Docker Build & Publish baut im dedizierten LXC Container in dem Docker installiert ist
4. Container wird wenn er fertig gebaut ist dann auf DockerHub/GHCR gepusht bzw. wahlweise auch zu Gitea zurück

 

Der dedizierte LXC Container eben deswegen damit ich mir Unraid selbst nicht zumülle und ich prune auch regelmäßig automatisch im LXC Container.

 

Für mich der effizienteste Weg und läuft wirklich seit Jahren stabil für mich.

[Crovaxon]

3 minutes ago, ich777 said:

Die hatte ich mir auch angesehen aber die hab ich für "zu wenig" empfunden für mich persönlich und da Gitea das auch kann spielt mir das sowieso in die Karten.

Ich hatte bereits mit images selber basteln angefangen bevor ich mittlerweile auch Gitea für mich entdeckt habe für Quellcode. Ich hatte images bei mir auf meinem Rechner gebaut und brauchte einfach ne repository zum drauf schubsen und abrufen und da kam Docker Registry als eigener container ganz gelegen.
Das Gitea auch die Registry übernehmen kann hab ich gesehen und behalte ich weit im Hinterkopf, ich würde ja vorher lieber wirklich genau wissen, worauf Unraid's Erkennung für Updates auf einem Docker Image fußt. Sonst hab ich am Ende ja auch wieder denselben Salat, ob ich lokal auf der Maschine Gitea oder die standalone Registry absichern muss  

16 minutes ago, ich777 said:

Hast du schon mal probiert nicht localhost zu nehmen sondern die IP von deinem Server? Ich könnte mir unter umständen vorstellen das dies Probleme macht.

Probier auch evtl. mal das du dem Docker container eine Fixe IP gibst bzw. eine andere IP.

Kann ich beizeiten versuchen, statt localhost mal 127.0.0.1 oder die lokale IP zu nehmen.

 

Was mich ja initial wundert ist, wie Unraid denn da eig. vorgeht.
Es ja nicht so, dass das Ansprechen der registry nicht klappt, ich kann ja initial den Container aufsetzen oder auch bei bereits laufenden Containern das aktuelle Image über "Force Update" ziehen. Nur Unraid's Versionserkennung klappt kein bisschen. Tagst du deine Images noch auf irgendeine spezielle Weise?

[ich777]

12 minutes ago, Crovaxon said:

Was mich ja initial wundert ist, wie Unraid denn da eig. vorgeht.

Sieh dir mal das file: /var/lib/docker/unraid-update-status.json an, dort wird einfach die sha256 von den images verglichen, mehr ist es nicht.

 

Wie die Datei erzeugt wird müsste ich jetzt selbst im Quellcode nachsehen da ich das selbst nicht weiß auf anhieb.

 

13 minutes ago, Crovaxon said:

Tagst du deine Images noch auf irgendeine spezielle Weise?

Wie meinst du das? Ich tagge die dementsprechend dem Repo wo ich sie hin pushe bzw. macht das Docker Build & Publish automatisch je nachdem wie ich es eingestellt hab:

https://hub.docker.com/u/ich777

https://github.com/ich777?tab=packages

[Crovaxon]

21 minutes ago, ich777 said:

Sieh dir mal das file: /var/lib/docker/unraid-update-status.json an, dort wird einfach die sha256 von den images verglichen, mehr ist es nicht.

 

Wie die Datei erzeugt wird müsste ich jetzt selbst im Quellcode nachsehen da ich das selbst nicht weiß auf anhieb.

Ah das ist doch schonmal gut zu wissen.

 

21 minutes ago, ich777 said:

Wie meinst du das? Ich tagge die dementsprechend dem Repo wo ich sie hin pushe bzw. macht das Docker Build & Publish automatisch je nachdem wie ich es eingestellt hab:

https://hub.docker.com/u/ich777

https://github.com/ich777?tab=packages

Es gibt ja den Standard Tag "Latest". Pushes auf ein Repo ohne Angabe eines Tags versieht diesen Push immer automatisch mit "Latest", oder man setzt halt händisch "Latest" in Kombination mit anderen Tags, damit "Latest" auch auf diesen bestimmten Push zeigt.

Ich habe bei meinen Docker Selbstversuchen jetzt nicht speziell getagged, also zeigt "Latest" ja auch auf meinen letzten Push.

Ich gebe bei meinen Containern in Unraid als Repo dann halt auch keinen speziellen Tag in Unraid an (also einfach localhost:5000/imagename), dieser holt dann standardgemäß auch "Latest".

 

Und da ich generell hier noch unerfahren bin was Docker Bauen und eben die Registry angeht, war ich mir nicht sicher ob das Tagging da in irgendeiner Weise eine Rolle spielt.

Aber dass da nur hashes verglichen werden macht ja Sinn.

Und ja, Unraid muss dann wohl Schwierigkeiten haben, den Hash vom Remote abzufragen.

Edited June 20 by Crovaxon

[Crovaxon]

Ich seh auch grad in dem JSON, dass meine eigenen Container da jeweils

        "local": null,
        "remote": null,
        "status": "undef"

stehen haben, dann auch kein Wunder dass keine Versionsabfrage klappt  jetzt nur noch herausfinden, wo bei Unraid der Schuh drückt...

[ich777]

11 minutes ago, Crovaxon said:

stehen haben, dann auch kein Wunder dass keine Versionsabfrage klappt  jetzt nur noch herausfinden, wo bei Unraid der Schuh drückt...

Ich würde da nicht gleich Unraid den Fehler zuschreiben, es kann durchaus sein das die Registry die du verwendest kein Docker Image Manifest v2 unterstützt und es deshalb zu dem Fehler kommt.

 

Wie gesagt, sieh dir mal an ob du ein Manifest von deiner Registry zurück bekommst.

Du kannst doch auch mal testweise deine Gitea installation als Registry nutzen und sehen ob es dort das gleiche ist.

 

Wie gesagt, hier mit einer Privaten Registry mit Gitea und dem Workflow von oben läuft alles perfekt.

[Crovaxon]

10 minutes ago, ich777 said:

Du kannst doch auch mal testweise deine Gitea installation als Registry nutzen und sehen ob es dort das gleiche ist.

Probier ich mal, ich hab gerade dasselbe image auf Gitea's Registry geschubst und einen meiner Container auf dessen repo umgestellt. Soweit ist es grün, aber das ist auch der Fall mit der standalone Registry gewesen nach dem ersten Erstellen oder nach einem force update, das war immer irgendwann auf "Not Available" gehüpft. Mal beobachten.  

[ich777]

5 minutes ago, Crovaxon said:

war immer irgendwann auf "Not Available" gehüpft.

Das kann dir aber auch bei GitHub passieren bzw. DockerHub wenn das manifest nicht richtig runter geladen werden kann.

Is sogar manchmal bei meinen container, gibt sich dann aber wenn man ein paar Stunden wartet und wieder "Check for Update" auf der Docker Seite klickt.

[Crovaxon]

1 hour ago, ich777 said:

Das kann dir aber auch bei GitHub passieren bzw. DockerHub wenn das manifest nicht richtig runter geladen werden kann.

Is sogar manchmal bei meinen container, gibt sich dann aber wenn man ein paar Stunden wartet und wieder "Check for Update" auf der Docker Seite klickt.

Jo, hatte ich auch in selten Fällen, aber das sollte bei DockerHub usw. ja nicht die norm sein. Bei mir allerdings schon

Mittlerweile ist der wieder umgesprungen auf "Not Available", wohl als ich gerade einen anderen Docker aus den community apps installiert habe und Unraid's Routine die Container durchgelaufen ist. Der JSON vom betroffenen Container sieht so aus:

        "local": "sha256:06e0e7f673fc011da77724d331921ba3bf26dc1619e58079d0a470eb820d56cc",
        "remote": null,
        "status": "undef"

Remote ist jetzt schlicht null. Gitea hat da leider auch nicht geholfen. Vermutlich ist es eben doch die Tatsache, dass es insecure betrieben wird. Ich finds zwar affig, lokal direkt auf der Maschine miteinander sprechende Prozesse mit HTTPS absichern zu müssen, aber denke da komm ich nicht dran vorbei.

 

@ich777, sprichst du deine Registry bzw. Gitea von einer public URL an, also von außen erreichbar oder ist das immer noch alles intern und der Container selbst ist mit HTTPS abgesichert?

Edited June 20 by Crovaxon

[ich777]

2 hours ago, Crovaxon said:

sprichst du deine Registry bzw. Gitea von einer public URL an

Mit einer Public URL mittels nginx reverse proxy (SWAG).

 

2 hours ago, Crovaxon said:

also von außen erreichbar

Jap.

 

Ich müsste das mal bei gelegenheit probieren auf eine Insecure Registry umzustellen aber das ist mir ehrlich gesagt zu viel Aufwand weil du die dann wieder einpflegen musst in Unraid das die unsafe ist usw. vielleicht liegts einfach wirklich daran was Squid oben geschrieben hat weil es eine insecure Registry ist.

[Crovaxon]

So, ich habe mich mal dran gemacht und mein Gitea auch mal nach draußen gehängt... Damit hat es jetzt eine schöne URL und ich hab einen container auf diese URL umgebogen.

Und siehe da, nun klappts.

Ich hab mal "Check for updates" laufen lassen und während meine alten auf der separaten registry laufenden Container weiterhin "Not available" melden, zeigt der neue auf meiner publiken Gitea Registry nun schön "up-to-date".

 

Und ich hab auch ne schleichende Vermutung, woher das Problem stammt. Ohne jetzt Unraid's Quellcode zu wälzen... (es ist jetzt schon ein bissl spät und ich will ins Bett )

aber ich glaube Unraid macht es sich einfach beim Identifizieren von Repository und Image(plus Tag).
Da wird einfach nach dem Doppelpunkt gesucht, weil dahinter kann dann ja nur ein Image Tag folgen, gell?
Das haben wir bei einer lokalen IP auf einem nicht standard HTTP port allerdings nicht 😉dort gibts potenziell zwei Doppelpunkte, der erste bei der Portangabe und evt. ein zweiter für ein spezifisches Image Tag.

Einmal oben mit meiner insecure registry auf port 5000, unten jetzt auf meiner publiken Gitea URL.

Man sieht schon dass der erkannte Tag bei der insecure bereits nicht kosher ist. Da wurde einfach nach dem ersten Doppelpunkt vom Image Tag ausgegangen. Es hilft auch nicht, ":latest" spezifisch im Repository des Containers anzugeben. Das erste auftauchende Doppelpunkt wird als Tag Trennzeichen verwendet

Ob dies nur rein visuell ist oder ob Unraid für sich selber auch so das image identifiziert, um damit dann das Repository auf Unterschiede zum laufenden Image zu testen ist jetzt hier die Frage.

 

Ist natürlich nur ein Verdacht. Wenn es nicht so umständlich wäre, jetzt Port 80 bei mir mal frei zu machen, damit ich Docker Registry auf dem default HTTP Port horchen lassen kann, könnte man dies mal so testen, ob dies dann reibungslos funktionieren würde, wenn man dann 127.0.0.1/imagename ohne Portangabe einfach machen könnte und Unraid dann damit klar kommt.

Mal schauen, vielleicht finde ich einen Moment morgen, damit ich das mal umbiegen und testen kann.

 

Auf jeden Fall kann ich bestätigen, dass mit der Public URL es jetzt auch klappt.

[Crovaxon]

On 6/19/2024 at 12:21 PM, Squid said:

I believe this might be fixed on the next release (7.0) of the OS.   Can’t 100% remember though

Do you know by any chance if for Unraid's update check it takes a look at the repository link to identify the image tag to test against? Or if that is what would be fixed in the coming release?
Given the screenshot of my previous post I get the sneaking suspicion that update checks fall flat because insecure repositories would typically be running on non default HTTP ports. Everything that is not 80 or 443 you need to specify in the URL as ip:port/image and the supposed Tag on my affected container starts at the port number, which is of course not the real image tag. Specifying ":latest" in the repo link does not change that behavior.

[Crovaxon]

So, ich hab das mal ne Weile im Auge behalten, hatte auch mal nen Test gemacht, wo ich den port vom Registry docker auf 80 geschubst habe, um ne portnummer bei der repo URL zu vermeiden, Falls die repo:tag Erkennung da irgendeine Rolle spielen sollte. Aber auch dies änderte nix daran, dass Unraid bei diesem Container auf "Not Available" sprang nach einem check for updates.

Ich denke Unraid mag schlicht keine insecure Docker Registries.

 

Meine mittlerweile auch publike Gitea Instanz funktioniert derweil als alternative Docker Registry tadellos über die öffentliche URL angesprochen. Ich könnte jetzt zwar auch den alten Registry container durch mein Reverse Proxy lotsen, aber da ich eh Gitea habe und die Registry dort ebenso gut funktioniert, bleib ich jetzt einfach bei der und ziehe meine images dorthin um.

 

Das Thema hat sich also für mich erstmal gegessen.  Danke für die Anteilnahme.

[Crovaxon]

On 6/19/2024 at 8:27 PM, SvenRoettjer said:

Danke für die schnelle Antwort. So (insecure) betreibe ich die registry eben auch. Aktuell ignoriere ich das "not available" einfach weg 😉

Da ich jetzt zufällig über die Unraid 7 patch notes gestolpert bin, hast du evt. Glück und das ist kein Problem in dieser Version mehr  das wird wohl sein worauf Squid hinweisen wollte.
https://docs.unraid.net/unraid-os/release-notes/7.0.0/#docker