Hallo,vielen Dank für die Antwort und bitte entschuldige, dass ich sie erstmal eine Woche lang liegen lassen hab.
Was ich inzwischen gelernt habe, ist dass die ganze Magie hinter dem Auto-Devops gar nicht so magisch ist, sondern nur eine sehr ausführliche .gitlab-ci.yml, die man hier [1] sehen und außerdem auch selber als Template über den Datei-hinzufügen-Dialog in ein Projekt einfügen und dann natürlich nach eigenem Geschmack verändern kann. In dem Template steht dann auch alles mehr oder weniger ausführlich beschrieben. Dieses Mysterium ist also schon mal gelöst.
Das erklärt vielleicht auch, was Auto Devops bei dem Minimal Example machen soll. Ich habe das testweise auch mal auf gitlab.com ausgeführt. Zunächst mit einem Runner, den ich auf meinem Rechner auf dem Schreibtisch gestartet hab, und zwar folgendermaßen:
docker pull gitlab/gitlab-runner
docker run -v /var/run/docker.sock:/var/run/docker.sock --name
runner -d gitlab/gitlab-runner
docker exec -ti runner gitlab-runner register
…
dann die Adresse, den Token usw. eingeben, dann wird der Runner im
Projekt angezeigt und auch benutzt. Ich hab auch den Docker-Socket in
den Container gemountet, wie man sieht.
root@e0a1363a6996:/# ls -la /var/run/docker.sock
srw-rw---- 1 root 974 0 Jan 17 14:51 /var/run/docker.sock
Die Gruppe stimmt auch:
root@e0a1363a6996:/# id gitlab-runner
uid=999(gitlab-runner) gid=999(gitlab-runner)
groups=999(gitlab-runner)
Darum frag ich mich zum Beispiel, ob das überhaupt so gedacht ist, den Runner in dem Fall auch in einem Container laufen zu lassen. Aber warum auch nicht, wofür sollte er sonst da sein?
Meine Fragen zu Kubernetes stell ich mal hinten an, bis wir das geklärt haben :)
Danke nochmal für die Rückmeldung und viele Grüße Marc[1]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
Am 2019-01-09 20:39, schrieb [email protected]:
Hai, ich bin ja bis jetzt nur ein stiller readonly Mailman-Abonnent, weil ich es einfach schon seit Jahren bin. Bei den Buzzwords will ich mich aber doch mal zur Stelle melden, vor allem weil ich das Thema hier noch nie auch nur im Geringsten wahrgenommen habe, es aber u.a. zu meinem beruflichen Hauptgebiet gehört.Das ist also meine erste Mail an die Gruppe - von daher Hallo an Alle ;-)Ich habe eine Handvoll produktive Gitlab Instanzen in Entwicklungsumgebungen laufen, die mit CI Runner und externer Registry eingerichtet sind. Das Wort Spezialist mag ich zwar nicht so und weiß auch in Sachen Gitlab, dass ich noch nicht alles weiß, aber sicher kann ich für ein halbwegs vernünftiges Start-Setup helfen, mit dem Du weiter kommst. Das Auto-DevOps Feature ist meiner bescheidenen Meinung nach gut gemeint aber eher Unsinn, weil nur die kleinste Abweichung der Anforderung sowieso eine eigene gitlab-ci.yml im jeweiligen Repo benötigt, was sowieso übersichtlicher ist und man mit Taggen, explizit setzen, oder shared Runners mehr Kontrolle für höhere Workloads hat. Bei dem minimal-example ist z.B. garnicht gleich ersichtlich, was genau er tun soll und wie er es tut. Deine Fehlermeldung kann eigtl. nur bedeuten, dass entweder der Docker-Socket nicht in den Container reingeountet ist, oder der gitlab-runner ist nicht in der docker group und hat somit keine Rechte drauf. privileged=true ist jedenfalls definitiv unnötig. Für weiteres Sachfimpeln bin ich gern zu haben :-) Viele Grüße, Silvio Gohl On 2019-01-08 16:20, [email protected] wrote:Hallo LUG, hoffentlich waren das genug Buzzwords im Titel, um die nötige Aufmerksamkeit zu bekommen :) Ich bin auf der Suche nach Leuten mit Erfahrung im Umgang mit selbst gehostetem GitLab und speziell mit diesem Auto-DevOps Feature [1], korrekter Einsatz von GitLab-Runner, Docker und optimalerweise auch mit selbst gehostetem Kubernetes. Falls es in Dresden derartige Spezialisten gibt, würde ich mich gern mal auf eine Unterhaltung und Hack-Session verabreden. Meine Probleme damit sind zur Zeit zu nebulös, um hier auf der Liste konkrete Fragen zu stellen. Ich krieg es einfach nicht auf die Reihe und fürchte, dass ich möglicherweise noch gar nicht richtig verstanden habe, was dieses Auto-DevOps eigentlich macht bzw. machen soll. Zum Beispiel: Minimal Example [2] build schlägt fehl mitCannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?Ich könnte mir da jetzt irgendeine Lösung zusammengoogeln, denn Stackexchange usw. ist voll mit Problemen wie diesen. Aber einfach irgendwas auf "privileged=true" setzen damit es geht fühlt sich falsch an, zumal überall auch entsprechende Warnungen dazu zu lesen sind. Ich bin mir nicht mal sicher, ob meine Ansätze überhaupt in die richtige Richtung gehen. Darum würde ich gern mal mit anderen Nutzern ein bißchen darüber fachsimpeln.Fühlen sich hier Mitlesende angesprochen? Kennt jemand jemanden? Sagt bescheid.Gruß Marc [1]: https://docs.gitlab.com/ce/topics/autodevops/ [2]: https://gitlab.com/gitlab-examples/minimal-ruby-app
signature.asc
Description: OpenPGP digital signature
