Drone CI-Containers on RL9 Arm Runner cannot resolve DNS #16
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently, containers from the runner on dev.komu.boo cannot resolve FQDNs, which leads to failed pipelines, since important components cannot be downloaded.
Interessante Erkenntnis: das scheint ein image-Problem zu sein:
Mit dem rust image hab ich auch auf
amd64unter RL9 DNS-Probleme, wenn ich jedoch zb.debian:latestnehme und mal einen nslookup mache, dann ist das kein problem, owbohl beide die gleiche/etc/resolv.confhaben.Nvmd, anscheinend gehen im rust image auch andere dinge ohne dns fix
https://drone.libre.moe/lukas/test/14/1/2
Sollen wir die Priorität mal ändern, da wir ja einen workaround haben?
done
Konnten wir das Problem eigentlich außerhalb von Drone reproduzieren?
Wie meinst du das genau:
Ja, also generell, ist dir das Problem schonmal in irgendeiner anderen Art, die nicht mit Drone zu tun hat, aufgefallen? Weil mir noch nicht und ich würde gerne rausfinden, in wie fern RL9 damit verbunden ist.
Also meine Faehrten/Vermutungen sind die folgenden:
Ja, ich gehe auch von Podman aus, aber es scheint ja eine Kombination zwischen Podman's DNS und wie Drone den Container startet zu sein, schließlich sind keinerlei andere Probleme dieser Art bekannt.
SELinux sehe ich da eher weniger (was ja nicht heißen muss), aber das ist ja mehr für file-based dinge.
Jein, ich hatte mal an einer anderen stelle das Problem, das SELinux die Docker-Socket blockiert hat.
Ausserhalb von Drone habe ich noch keine Experimente mit dem oder anderen Images gemacht.
Ich tendiere jedoch auch gegen Podman, da sich das problem ja sogar innerhalb des Containers fixen laesst.
(siehe stupid workaround)
Also ich hatte in RL9 bisher auch nie Probleme mit dem default network, bzw. dem network, dass default ist.
Besonders sollte man vielleicht hervorheben, dass Drone ja auch nur für Docker und nicht für Podman gebaut ist, damit also vielleicht auch einfach nicht gut umgehen kann und wir deshalb diese Probleme haben.
Ansonsten ist das hier meine Haupttheorie:
=> Das Problem tritt auf
Also was "It does not support dns resolution" genau bedeutet ist auch unklar:
Ich hab den Artikel mal genau gelesen, das default network gilt für den Adapter
netavark, der aber nur bei rootful containern default ist. Für rootless container istslirp4netnsdefault. Dafür gilt das ganze "no dns" ding nicht, soweit ich weiß.Vorallem: bisher hatte ich nie DNS issues in irgendwelchen Podman containern oder Netzwerken. Die sind bei mir alle default und nutzen auch Kommunikation miteinander über DNS-Namen, die nutzen also definitiv Podman's DNS.
Da Drone ja eigentlich Docker nutzt, muessten das aber doch eben rootful container sein?
Jagut, da hab ich keine Ahnung.
Aber es sollte angemerkt werden, dass in 90% der Fälle wo man bei Cotnainern über DNS redet, sich das nur auf die resolution von Container names zu IP Addressen bezieht.
Außerdem: rootfull podman containers haben keine Probleme mit public DNS
Containers on RL9 Arm Runner cannot resolve DNSto Drone CI-Containers on RL9 Arm Runner cannot resolve DNSIch schließe dieses Issue mal, da es nicht für uns fix-able ist bzw. wahrscheinlich ein Problem mit Podman darstellt.
Wenn man weiterhin Probleme hat und kein woraround nutzen möchte, kann man ja einfach Docker nutzen (da Podman von Drone nicht offiziell unterstützt wird).