Hi zusammen,
ich möchte Docker Images über die CI bauen und in die Container Registry meines Projektes ablegen. Obwohl sich verschiedene Skripte mit Lösungen finden, schaffe ich es nicht ein Image zu bauen. Diese schlagen immer fehl mit „Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?“
Gibt es hierfür eine Anleitung ? Welche Einstellungen muss man unabhängig der Yaml vornehmen?
Wie ist der gedachte Weg, um Container Images zu bauen? Ich denke, man wird in Fällen wie dagger.io nicht um den privilegierten Build von Container Images herumkommen. Der docker executor von dagger.io benötigt im dargestellten Beispiel (GitLab CI | Dagger) ebenfalls dind.
Für „normale“ Container Images: Was ist die Alternative zu kaniko? buildah?
Ein anderes Szenario gibt es bei der Bereitstellung von kyverno Policies der IG-BvC anhand von SYS.1.6 und APP.4.4.
Die meisten Test funktionieren mit kyverno test. Jedoch benötigen einige wenige Tests ein echtes Kuberntes Cluster. Da jedoch kein privilegierter Modus zur Verfügung steht, kann kein ephemeral Cluster innerhalb einer Pipeline angelegt werden.
Einen eigenen GitLab Runner aufzusetzen ist keine Alternative, da man so die Zugangsinfos für alle Mitglieder des Projektes bzw. der Gruppe bekant geben würde.
Als Ausweg bleibt derzeit ein remote trigger zu einer Pipeline bei gitlab.com. Dort ist ein privilegierter Modus möglich und die Pipeline kann dort ein temporäres k3d Cluster anlegen.
Chainguard (mittlerweile Arbeitgeber zweier der ursprünglichen Kaniko-Entwickelnden) hat scheinbar auch Kaniko geforked, so dass „einfach mit neuem Image-Pfad weitermachen“ vermutlich auch eine Option wäre.
Insofern auch rootless BuildKit entsprechend https://docs.gitlab.com/ci/docker/using_buildkit/#migrate-from-kaniko-to-buildkit nicht ohne Weiteres auf den openCode-Runnern zu funktionieren scheint, würde ich jetzt vermutlich tatsächlich den Chainguard fork versuchen, allerdings muss man die Images scheinbar selbst bauen. (Hier wäre es natürlich schon, wenn openCode so ein Image zentral bereitstellen/pflegen könnte.)
Für den Fall des Build eines Images funktioniert die Vorgehensweise. Aber in anderen Szenarien wie die ephemeral Ausführung von z.b. k8s Testclustern werden dennoch oft root Privilegien benötigt.
Sicherlich, die Frage ist ob das Anwendungsfälle sind die openCode mit den Shared Runner abdecken muss. Prinzipiell spricht nichts dagegen für spezifische Zwecke spezifische Runner selbst zu betreiben und diese entsprechend getagged in den relevanten openCode/GitLab-Projekten zu registrieren.
Niemand sagt, dass diese Runner im einem bestimmten RZ laufen müssen. Die Rechenkapazitäten kann ja auch anderswo laufen, zumindest so lange selbige ausreichend vertrauenswürdig ist.
Ich denke, dass es grundlegend wichtig ist, openCode bzw. das ZenDIS nicht mit allen irgendwie denkbaren Anforderungen zu überfrachten. Besser ist es die für 80% relevanten Anforderungen zu finden und zu bedienen. Sonst kommt am Ende so etwas wie die Betriebsumgebung am ITZBund raus, die zwar auch für die 10% kritischen Systeme geeignet wäre, aber für die 90% Brot-und-Butter-Systeme viel zu komplex und damit zu teuer ist.
In gewissem Sinne sind ein „RZ“ und „anderswo“ externe compute resources. Daher also das gleiche.
Im ernsthaften produktiven Betrieb sind realitätsnahe Testläufe durchaus keine Seltenheit, sondern eine MUSS Anforderung. Daher stammt der Fall einer realitätsnahen Testumgebung direkt aus der Praxis.
Würde das nicht zusätzlich für Runner in der eigentlichen Betriebsumgebung sprechen? Dann halt entsprechend isoliert. Die Betriebsumgebung die openCode zentral bereitstellt würde gerade nicht realitätsnah sein wenn die System dann auf einer ganz anderen Infrastruktur eingesetzt werden.
Gibt es hierzu mittlerweile eine Lösung? Also eine abseits von der Option die Images lokal zu bauen und in der opencode registry zu hinterlegen. Wenn nicht, sollten wir OpenCode bitten dafür eine Lösung bereitzustellen.
Wir nutzen jetzt seit einiger Zeil des osscontainertools-Fork von Kaniko um unsere Container Images via openCode GitLab zu bauen und haben damit soweit keine Probleme.
, vgl.