So, fangen wir an. Herzlich willkommen zu meinem Vortrag GitLab CI und Docker Registry.

Das heutige Agenda sieht folgendermaßen aus. Ich erzähle ein bisschen über mich, für diejenigen, die mich noch nicht kennen. Wir gehen nochmal auf Sachen, was wir mit diesem Vortrag überhaupt erreichen möchten.

Für diejenigen, die GitLab noch nicht kennen oder nicht so gut kennen, nur vom Namen her, gehen wir auf Basics von GitLab und dann konzentrieren uns auf das Deployment on-premise und essentiell auf einer Enterprise-Infrastruktur. Und wer schon in großen Enterprise gearbeitet

hat, weiß, dass das Deployment bei diesen Infrastrukturen ein großes Schmerzen bereiten kann. Daher, wir haben die Erfahrung gemacht und wir möchten die Erfahrung einfach scheren und so eine Diskussion machen.

Und zum Schluss gehen wir noch auf die bekannten Bugs, die GitLab zurzeit hat und die sind dabei, das zu fixen, damit ihr da auch Bescheid weiß, was auf euch wartet, wenn ihr GitLab deployen möchtet. Und zum Schluss gibt es eine Fragen-Antwort-Session, Diskussionsrunde. Oh, die ist kaputt gegangen, sorry. Vielen Dank.

Noch mal. Okay, alles klar. Dann über mich. Ich bin Oleg Fixl. Ich bin Security Consultant bei der Firma CSP, früher ModComp.

Ich mache Architektur, ein bisschen Perlcoding, Development Cycles. Privat lerne ich ein bisschen Golang und Bastel am Gentoo. Was möchten wir mit diesem Talk erreichen? Ich möchte keinen Vergleich hier machen, GitLab gegen Jenkins, gegen was anderes.

Also hier geht es um GitLab, wenn ihr euch schon für GitLab entschieden habt oder euch entscheiden möchtet, dann geht es hier um GitLab CI.

Und wir möchten eine Übersicht verschaffen, was GitLab Deployment mit sich bringt, wenn man dann auch eigene Docker-Container mit CI bauen möchte in einer on-premise Enterprise-Architektur.

Wir gehen auf GitLab CI Community oder GitLab Community Edition. Mit Enterprise Edition haben wir noch keine Erfahrungen gesammelt. So, und ich bin kein Mitarbeiter von GitLab. Das heißt, das, was wir besprechen, ist halt unsere Erfahrung und unser bestes Effort.

Okay, wer hat schon mal GitLab gehört? Okay, wer arbeitet mit GitLab? Okay, cool. Ich gehe mal kurz, was GitLab ist,

was es macht und das Wording von GitLab überhaupt, damit wir auf denselben Welle sind und die gleichen Wording die Bedeutung verstehen. Okay, also GitLab, Git Repository Manager, wie GitHub nur selbst hostet, das war so die Idee,

gestartet in 2011. Und jetzt ist es rapide gewachsen bis auf 150 Mitarbeiter und Enterprise-Produkt. In 2016 haben sie CI Pipelines eingebaut und damit ist GitLab reif zum CI und

automatischen Deployment. GitLab ist schon benutzt von mehreren Firmen, IBM, Sony, SpaceX, NASA und CSP.

So, wer kennt, was Docker ist? Ja, super, alle. Dann könnt ihr wahrscheinlich sogar mehr als ich. Okay, ich gehe ganz kurz auf Docker, was es ist. Ganz kurz sieht Docker vollendermaßen aus.

Wir haben Docker Client, wir haben Docker Host, wo die ganzen Container laufen. Container, so eine Art wie virtuelle Maschine, aber nicht virtuelle Maschine, gar nicht virtuelle Maschine, also mehr als ein separater Sandbox-Prozess. Und wir haben richtig Registry, wo die ganzen Container liegen. Das heißt, es gibt natürlich viel mehr Möglichkeiten. Wir können Container

bauen von einem Docker-File, das heißt wir laufen Docker-Build und der erstellt uns einen Container, hier glücklicherweise ein Gentoo-Container. Und dann können wir mit Docker Run diesen Container oder einen anderen Container aus unseren Images,

lokalen Images dann laufen lassen. Man sieht hier schön, dass die Container, die laufen, da gibt es so Schichten, das heißt jedes Mal, wenn man zum Container irgendwas hinzufügt, kommt eine Schicht oben drüber.

Das ist ein Filesystem Schichtmodell. Und ich habe auch die Möglichkeit, Docker Pull zu machen und einen Container aus dem Registry zu ziehen in mein lokales Container. repository, lokales Speicher. So, das ist ganz kurz zu Docker. Fragen? Gut, ja, okay. So, zum

Boarding, damit wir auf derselben Seite sind, was ich oder was GitLab mit einem bestimmten Wortsatz meint. GitLab Server ist gemeint ein Server, der hat Repositories und hostet diese Repositories. Dann gibt es GitLab CI Runner, das ist ein kleines

Go-Binary, das läuft im User Space und sorgt dafür, dass die macht eine Verbindung zum GitLab Server und sorgt dafür, dass die

Tests, Builds, was auch immer, was GitLab anstoßt, dass die aufgerufen werden und evaluiert werden. So, dann wenn zum Beispiel ein CI Runner, ein Build-Prozess laufen lässt, dann entsteht am Ende dieses Build-Prozess ein Binary oder ein Build oder ein PDF oder was auch immer, ein Artifakt.

Und dieses Artifakt kann eventuell dann an GitLab wieder zurück hochgeladen werden. GitLab hat dafür dann so ein Artifact Storage. So,

dann gibt es auch, es gibt auch noch viel mehr, aber in diesem Vortrag gehen wir nur auf diese Sachen zu. Dann gibt es GitLab Container Registry und das ist nicht viel mehr als ein Frontend für Docker Container Registry.

Das heißt, man muss nicht missverstehen, ich mache da ein Häkchen an und ich habe direkt ein Docker Registry. Nein, das ist nur ein Frontend, der greift nämlich auf das Docker Registry Service und ich habe halt

dann die Möglichkeit im Docker Registry meine Images zu verwalten, zu löschen und das macht auch die Authentifizierung. Das heißt, der GitLab hat dann ein Frontend für Docker Registry Service. Den muss man dann auch separat laufen lassen. Dann gehen wir gleich in der Architektur nochmal drauf ein.

So, wie sieht so ein Deployment von GitLab mit CI on-premise aus? Wir haben ein Checklist, was wir alles dafür brauchen.

Wir brauchen zwei VMs, man kann, also ich würde sagen mindestens zwei VMs. Wir können natürlich auf einer VM laufen, dann hat man so eine riesen VM und alles da drin ist, ist nicht schön. Also mindestens zwei würde ich sagen oder wenn sie schon Kubernetes Cluster oder Rancher Cluster oder Mesos Cluster oder was auch immer. Amazon, Amazon ist ja nicht mehr on-premise.

Also zwei VMs. Wir brauchen eventuell optional ein Reverse Proxy oder ein Load Balancer für SSL Offload. Praktisch, da hat man die ganzen SSL Zertifikate drauf. Wichtig ist, dass das Ding ein HTTP 1.1 vorne und nach hinten verstehen muss, also können muss. Zum Beispiel

mit light-httpd hatten wir die Erfahrung, der macht nach vorne HTTP 1.1, bricht aber nach hinten 1.0. Also put und delete HTTP Request kommen nach hinten nicht durch. Zum Beispiel eine direkte

Verbindung zum Internet, am besten eine direkte Verbindung zum Internet für das Ziehen der Docker Images. Der CI Runner, das ist der, der der Builds laufen lässt, der wird sich Docker Images ziehen, um halt

irgendwas Java Docker Image, um halt Java Dateien oder War Dateien zu bauen, muss er halt irgendwie ans Internet. Wir gehen noch auch darauf ein, was man machen kann, wenn man wie üblich in Enterprise Architekturen einen Forward Proxy hat und man bräuchte SSL Zertifikate für das Frontend, für die Zwischenkommunikation.

Interessant wird, wenn man intern eine eigene CA betreibt, das heißt also das GitLab eventuell nach extern erreichbar

ist, großteils nicht, nur intern und intern wird eine eigene SSL CA benutzt und dann wird es spannend. Das ist der Hauptteil von dem Vortrag. Okay, was für Probleme können dabei auftreten oder was kann Schwierigkeiten bereiten, wenn man dann so ein Deployment macht.

Also internal CA ist auf jeden Fall eine Sache, die euch viel Arbeit, viel Gehirnschmal braucht.

Also man sieht ja auch der Smiley, der hat wirklich so eine schöne Kurve drin. Also Forward Proxy kann auch ein bisschen schwierig sein, hat auch eine leichtere Kurve so im Gesicht und DNS Split Horizon, was nicht in diesem Vortrag, nicht Teil dieses Vortrags.

Wer versteht was, DNS Split Horizon? Okay, also DNS Server, Name, gib mir einen IP, ich frag den an, ich geb ihm einen Namen, der gibt mir einen IP.

So, Split Horizon heißt, ich hab einen DNS Server, der ist sowohl für außen zuständig als auch für innen. Und wenn jemand von außen fragt, gib mir gitlab.domain.com, der gibt eine Public Adresse.

Wenn ich von innen frage, der sieht, aha, okay, du hast eine interne IP, da hab ich eine andere View, da geb ich dir eine interne IP. So, das ist Split Horizon, also für den gleichen Namen, zwei verschiedene Einträge, IP-Adressen und abhängig von der Source IP des Anfragenden. So, das kann auch ein Interne Trick gewähren.

Okay, so, das GitLab CI Runner ist das Ding, was die Builds und die Tests und die Docker Images baut und das ganze CI Doing macht, der Worker dafür.

Der sieht, die Architektur kann vollendermaßen aussehen, also hier haben wir GitLab CI, das ist der Server oder ein Teil des Servers, das CI Teil, das Command and Control Center, was sagt, welcher Runner was machen muss.

Und da haben wir verschiedene Möglichkeiten, wir können zum Beispiel einfach einen CI Runner bei uns auf dem Laptop laufen lassen, der verbindet sich dann über HTTP zum GitLab Server und rollt sich dann die Befehle, was er machen soll und macht das dann, kann eventuell auch mit Docker funktionieren,

also wenn man gerade da eine VM mit Docker hat oder ein Nativ, man kann Runner als virtuelle Maschinen in der Cloud aufsetzen. Ich glaube, GitLab hat sogar einen Connector zum Digital Ocean, da kann er bei Digital Ocean einen Runner einfach erstellen,

Sachen laufen lassen und wieder löschen, das heißt, in der Cloud ist es auch kein Problem, es ist sehr dynamisch. Hauptsache derjenige kommt dahin, also die Befehle gehen von einem GitLab CI, aber die Verbindung geht andersrum. Und ich habe noch die Möglichkeit, einfach einen Shell Runner laufen zu lassen, der kann dann in normalen Shell

Befehle absetzen, also dann programmiere ich meine CI Konfiguration so, dass ich halt wie auf der Shell Befehle aufrufen soll. Und ganz interessant wird es nämlich mit dem Docker Runner, das heißt, der Docker CI Runner verbindet sich dann an den Docker Container und für

jeden CI Job startet er einen Docker Container oder zieht sich einen Docker Container und klont da die Repository rein und lässt die Befehle laufen, oder was auch immer, das heißt, man kann hier verschiedene Container aus dem Registry ziehen und da

die CI laufen lassen, was hier aber noch nicht da ist, was auf dem anderen Slide da ist, man kann hier in dem CI Runner, der Docker Container benutzt, noch einen Docker Container erstellen

und in diesem Docker Container ein Docker Image bauen, so baut man dann die Images nochmal. Ja, das heißt Dint Docker in Docker, das ist ein ganz kruder Konstrukt, man kann es auch anders machen, aber das ist wohl die Sache, die bis jetzt so ja empfohlen wird.

Und also so wie es aussehen kann. Okay, jetzt kommt ein ganz interessanter Slide, den müsste ich mal durchgehen. So kann es aussehen, sieht vielleicht sehr kompliziert aus, aber gehen wir einfach mal durch und man sieht, das ist relativ logisch.

Also das ist unser GitLab Server, da gibt es verschiedene Komponenten, GitLab, Repository, dann gibt es GitLab CI, dann gibt es Artifact Storage, dann gibt es Registry Frontend und Authentifizierungsstelle.

So, wenn der CI Runner startet, verbindet er sich, ja okay, an dem CI, wahrscheinlich muss er sich an GitLab verbinden, aber der verbindet sich an GitLab, holt sich die Befehle und dann verbindet sich an, sorry, der

verbindet sich an die CI, holt sich die Befehle und dann holt er das Repository von dem GitLab Server runter. Dann klont die in einen Container, ein Container macht dann die Builds und Tests oder was auch immer

und der Runner hat dann die Möglichkeit, dann noch per HTTPS dann die Artifacts hochzuladen in die Artifact Storage. Und hier hat man auch dann die Möglichkeit, in dem Docker Container nochmal Docker Build zu bedienen und ein

Docker Container als Artifact zu erstellen und dieses Artifact geht dann nicht in Artifact Storage, sondern der geht in Registry. Das heißt, als Resultat unseres Builds ist ein Docker Container, der dann später in die Registry

eingecheckt wird für dieses Projekt und der später benutzt werden kann, um andere Builds zu machen. So, dann haben wir die Registry, die ist relativ simpel, das ist ein ganz

kleiner Container, auch ein Golang Binary, der braucht eine Storage und eine Config-Datei. Die Storage kann eventuell S3 sein oder lokale Storage, also irgendein Mount auf dem System oder Swift, Azure. Der braucht eine Config-Datei, wo er den GitLab findet, die Authentifizierungsstelle, dafür muss man selbst sein CA erstellen,

da ist wirklich die Doku sehr gut, was mir aber gefehlt hat, diese Verbindung, wie die ganze Kommunikation durchläuft. Das heißt, der verbindet sich mit dem Docker für die Authentifizierung, wenn ich für das Projekt nicht

freigeschaltet bin, kann ich auch keine Images dahin pushen und das ist dann für die Authentifizierung hier. Der GitLab hat ein Frontend für das Registry und braucht dann auch die Storage gemountet, das heißt die Storage muss an beiden Systemen gemountet sein oder wenn es S3 ist, dann gibt man die Credentials und dann können die beide die Storage erreichen.

Der muss auch das Zertifikat, das CA haben, damit die Verbindung hier verschlüsselt mit dem eigenen CA, also mit dem CA nur für diese Kommunikation, da stellt man halt ein eigenes CA. Und der Docker Client, der geht erstmal hin, authentifiziert sich und dann mit irgendeinem Token kann er dann pushen.

Also hier gibt es die Authentifizierung zweimal, einmal hier, einmal hier. Ich weiß ehrlich gesagt nicht, was genau greift, also wozu diese hier?

Wahrscheinlich um den hier push zu machen, gehe ich mal von aus, weil der Client laut Dokumentation authentifiziert sich direkt mit dem GitLab und dann geht er in Docker Registry. So, die roten Pfeile, die wären dann interessant, wenn man eine eigene CA benutzt.

Dann diese Kommunikation muss alle Clients, die diese rote Pfeile, rote Kommunikation betreiben, die müssen alle dieser CA vertrauen. Das heißt, der muss die CA lokal installiert haben und vertrauen, der und ganz interessant, der.

Das Problem werden wir später sehen, der wird aus dem Internet teilweise gezogen. Der hat die CA gar nicht drin. Das heißt, wie kann er dann pushen? Kann er gar nicht. Da kriegt man einen Zertifikatfehler.

Und das ist auch ein großer Teil dieses Vortrags. Wie man dieses Image anpasst, damit man die eigene CA oder Proxy-Konfiguration, oder was auch immer da integriert, damit diese Kommunikation hier klappt.

Der Pfeil, der rote Pfeil muss eigentlich von hier kommen. Teilweise pusht der, aber Großteil pusht der. Vor allem, wenn man Docker-Images baut, dann pusht der Docker-Container. Ja.

Soll ich die Frage wiederholen? Die Frage war, der GitLab CI-Runner, ist das ein Container oder ist das kein Container? Beides.

Es ist ein Golang-Binary, der verbindet sich an den Docker-Container und startet da ein CI-Runner-Docker-Container. Und dieses Container hat dann die Möglichkeit, andere Container zu starten. Das ist sehr verschachtelt.

Ganz krude wäre das, wenn man wirklich Docker-in-Docker macht, dann ist es dieses CI-Runner-Container macht noch ein Container, tut da den Socket rein von Docker und damit der Docker-Container da drin sich an den Docker selbst verbinden kann.

Das muss man sich ein bisschen da rein denken. Ich weiß nicht, warum man das so macht. Man kann das auch über Shell-Befehle machen, aber dann muss man halt Shell-Befehle tippen. Erstmal ganz laut in Diskussion, ob man es so machen muss oder so machen muss. Bei beiden Möglichkeiten gibt es verschiedene Probleme. Auf ein Problem gehe ich darauf ein, mit dem Storage-Backend von Docker.

Dass es auch teilweise sehr langsam sein kann. Da gibt es aber ein Workaround oder ein Fix dafür. So, habe ich die Frage beantworten? Okay, noch Fragen? Also diese CA brauchst du auf jeden Fall.

Das Thema heute ist, was machst du, wenn du intern eine eigene CA betreibst und kein offizielles Zertifikat.

Wenn du ein offizielles Zertifikat im internen Netz betreibst für GitLab, dann hast du überhaupt kein Problem. Dann ist es trusted von allen, dann ist die Kommunikation, da hast du überhaupt kein Problem. Da hast du keinen Krampf. Das Interessante wird, wenn du im internen Netz kein offizielles Zertifikat hast, kein Wildcard gekauftes oder kein gekauftes Zertifikat,

wenn du wirklich eine selbstsignierte CA klickst und daraus Zertifikate signiert, dann wird es interessant. Aber diese Kommunikation, da erstellst du halt drei Befehle, erstellst du eine CA nur für diese Konfiguration.

Ist alles super beschrieben auch, funktioniert auch genauso. Da gibt es auch kein Problem. Okay, so, bevor wir dann Docker in Docker bauen, gibt es ein interessantes Phänomen,

wenn man, das heißt dint, Docker, dint, Docker in Docker, Docker, zu viele Docker. Wenn man Docker in Docker baut, laufen lässt, der interne Docker-Container, der heißt dint, der bei Default benutzt ein WFS-Storage-Driver.

Und dieser Storage-Driver kann sehr langsam werden, wenn man gerade, weiß ich nicht, an einem Tag zwei, drei Images baut, ist es nicht schlimm, abhängig natürlich von der Menge. Aber wenn man wirklich sehr viele Images sehr oft baut, dann kann es für die Storage sehr viel Arbeit bedeuten.

Das heißt, als erstes, was man eventuell machen möchte an der Maschine, die CI-Runner hat, ist auf das Overlay Docker Storage Backend zu gehen.

Und das geht sehr leicht bei Ubuntu. Man muss das Modul haben, das Kernel -Modul, muss das Modul Modproben, das System neu starten, dann wird es automatisch geladen. Und man muss den Storage Backend in dem Docker anpassen auf Overlay und dann

wird das ganze Fallsystem nicht auf einmal kopiert, sondern wird in diesen Layern auch gehandelt. Wichtig ist dabei, sobald man das macht, erstellt der Docker ein neues Verzeichnis

in VAR Docker Storage mit dem Namen Overlay und das ist erstmal leer. Das heißt, wenn man lokal irgendwelche Container hatte, die sind dann mal weg. Das heißt, die liegen halt woanders. Wenn man dann wieder umstellt, dann sieht man die wieder, weil er wieder auf ein anderes Verzeichnis schwenkt.

Aber muss man halt im Hinterkopf behalten, dass die Container, die man jetzt lokal hat, werden halt weg sein mit dieser Umstellung. Ok, jetzt wird es interessant, wenn man eine eigene CA hat, was braucht man dafür, um GitLab

überhaupt zum Laufen zu kriegen mit Docker Registry und mit Docker in Docker, also bauen von Docker Containern.

So, alle müssen die CA wirklich trusted haben, die Clients, aber wahrscheinlich wird es dann automatisch irgendwie aufverteilt oder jeder, der Docker Registry erreichen möchte oder GitLab erreichen möchte, jeder Client muss dann die CA trusted haben.

Und das gehört auch, das gilt auch für CI-Runner. Das heißt, der pusht dann später die ganzen Artifacts, die ganzen Sachen Richtung GitLab, der muss natürlich auch die CA haben. Es wird viral. Sobald man eine eigene CA hat, jeder muss die CA integriert

haben. Am besten integriert man die in die Images rein, dann hat man kein Problem. So, das Problem, was wir vorher angesprochen haben, dass der Docker Container von CI holt einen

Docker Container aus dem Internet und baut damit dann irgendein Artifact oder wiederum ein Docker Image. Die Tatsache, dass er aus dem Internet holt, hat er die CA nicht integriert. Das heißt, der kann die Artifacts oder was auch immer, kann er gar nicht pushten.

Das heißt, ein Problem, die Public Images haben blöderweise unsere CA nicht integriert. Das heißt, die muss man dann irgendwie integrieren. Also, wir sind dann mit der Lösung oder mit dem Workaround gekommen, um die Images

aus dem Internet zu nehmen und die automatisch zu bauen mit Integration von unserer eigenen CA. Das heißt, wir haben ein Docker Image, der sagt From, das und das, CA rein und das war's. Nichts

mehr. Und die werden dann gescheduled, gebaut, einmal am Tag, damit man dann immer auf den aktuellen Images, dann baut man halt die Docker Images, die Docker in Docker Images und eventuell die Base System Images, die man braucht. So, wie geht man da vor? Das wird jetzt, ja?

Eine kurze Frage noch. Habt ihr versucht, die Zertifikate in die Docker Images rein zu mounten? Also, dass man die Zertifikate in das Image rein mountet?

Sehr gute Idee, ja. Du kannst das Zertifikat rein mounten, ja. Und du

müsstest dann das Zertifikat in die Trusted CA nochmal hinzufügen. Ja, das würde gehen. Dann hast du, ja, nee, nee, nee. Sehr, sehr, sehr gute Idee. Dann hast du nochmal die Proxy Settings. Die Proxy Settings machen wir auch dann beim Imagebauen.

Tun wir die ganzen APT, Proxy Settings oder was auch, die Environment Variablen. So. Und irgendwann hast du 10 Docker Images und in jeder CA-Konfiguration hast du diese Zeilen. Und das, wenn du dann dein Proxy, eine IP oder einen Namen ändert, hoffentlich

nicht, oder eine neue CA hast, dann musst du wirklich alle deine CA-Konfiguration ändern. So änderst du nur eine Konfiguration und darauf wird dann automatisch gebaut. Das ist so und so. Kann man so machen? Klar. Ja, ist auf jeden Fall viel einfacher, die Zertifikate einfach da rein zu tun.

Aber bei viel CA-Konfiguration kannst du dazu führen, dass du wirklich viel anpassen musst. Und das ist auch großer Overhead bei CA-Konfiguration. Das ist immer das Gleiche. Ja.

Kann man machen, muss man aber nicht. Genau, ja. Also die Frage, warum soll man die Images direkt vom Docker Hub immer ziehen, muss man nicht.

Natürlich, dafür ist die eigene Registry da. Wir bauen eigene. Aber Ubuntu oder CentOS oder Docker, also Docker Image mit Docker drin, die willst du eigentlich selber bauen. Kannst du. Nimmst du die, klonst du die Repository? Klar.

Ja, klar, natürlich. Direkt vom Scratch kompilieren, alles klar, natürlich. Dann macht man einfach dann den Clon von dem Docker Repository ins GitLab rein, tut da CCI-Konfiguration und wird dann gebaut.

Dann hast du eigene, clean Images, nicht verseucht mit irgendwelchen Sachen. Ja, klar. Ja, ich wiederhole nochmal die Frage. Kann man nicht einfach letzten Crypt benutzen und sich den ganzen Stress sparen?

Ja, sicherlich, klar. Wenn du die Möglichkeit hast, auf ein valides Zertifikat drauf zu kommen, klar. Aber bei großen Enterprise ist es größer. Du hast keine Kontrolle über DNS. Du hast keine Kontrolle über das Traffic, der reinkommt. Wie willst du überhaupt letzten Crypt bekommen? Das heißt, du musst entweder DNS Entry oder du musst irgendwas nach außen laufen lassen.

Ja, sicher, klar. Kannst du. Nein, nein. Die CCI ist nur für HTTPS, damit die HTTPS Verbindung vertraut aufgebaut werden kann.

Und wenn man dafür ein offizielles Zertifikat benutzen kann, ohne viel Schmerzen, dann auf jeden Fall machen.

Letzten Crypt ist eine super Sache. Nur in einer großen Enterprise dauert eventuell so ein DNS Change vielleicht mal einen Monat. Wenn du das gemacht hast, hast du ein Zertifikat bekommen, dann ist das schon abgelaufen, bis du den nächsten Change hast.

Stell dir vor, du hast keine Kontrolle über DNS, du hast keine Kontrolle über Firewall, du hast keine Kontrolle über einkommenden Traffic. Aber du möchtest trotzdem CCI machen.

Also große Konzerne sind halt so, dass du sehr lange auf so einem Change, der irgendwie nichts bewirkt, also kein Benefit hat, die dauern halt so lange, wie dein letzten Crypt Zertifikat läuft.

Ja, deshalb der Vortrag. Genau. Das Problem ist, wenn man einen Docker Container erstellt mit der eigenen CCI, der GitLab CCI ist so konfiguriert, der bei Default immer Images von Docker Hub pullt.

Das heißt, wenn er auch lokales Image hat, pullt er das trotzdem, um zu gucken, ob da eine neue Version gibt. Man kann natürlich sagen, der soll woanders pullen, aber bei Default pullt er aus dem Internet. Das heißt, man muss erstmal die Base Docker Images selbst bauen und selbst auf die Repository

hochladen, damit das Prozess dann später laufen kann, damit er die Images schon mal vorrätig hat. Ansonsten hätte man Henne-Eye-Problem. Der versucht die zu holen, der kann die

nicht holen, weil der kann die nicht bauen, weil die noch nicht gebaut sind. Und dafür müssen wir erstmal die Runner-Konfiguration anpassen. Dann bauen wir die ersten Docker Images selbst, pushen die zu Repository und sobald die im Repository drin sind,

dann können wir die CI-Konfiguration anlegen, bitte nimm die Images aus dem Repository und baue mir die selbst. Das heißt, der nimmt die Images selbst und baut die selbst damit. So. Und CI-Konfiguration erstellen.

Eventuell kann man halt, wenn man so ein eigenes Ubuntu Image pflegen möchte, mit eigenem Custom, vielleicht Security Patches oder Security Guidelines, die man in so einem Enterprise öfters mal hat, da kann man so ein Docker Image dann immer einmal am Tag bauen.

Die Runner-Konfiguration ist ein Feature von CI, Scheduled Builds, das heißt, immer täglich wird es gebaut und hat man dann immer die aktuelle Version. So. Bei der Runner-Konfiguration ist wichtig, dass der Executor, ein Docker Executor, dass er Privileged ist.

Privileged heißt, er hat die, es ist ihm erlaubt, an den Docker-Deam dran zu gehen und neue Docker-Container zu starten. Da muss man vorsichtig sein, also nicht alle Jobs möchte man in Privileged Mode laufen lassen, nur die

Jobs, die auch die Docker-Container bauen und so verschiedene Tests oder so, die müssen nicht Privileged sein. Und man muss den Docker-Socket rein-mounten. Also hier würde man nochmal den Mount, den du meintest, mit der CI, hier würde man den da rein-mounten.

So. Dann erstellen wir den, wir müssen zwei Images bauen. Ein Image für das Docker-Latest, also das Docker-Image, also Docker-Image mit dem Docker-Vinary da drinnen.

Und ein Image, Docker-Dint, das ist ein extra Image, der ist sehr ähnlich zu dem normalen Docker-Image, nur der ist gedacht in einem Docker-Container zu laufen. Das heißt, ein Docker-File für das Docker-Latest, wir nehmen das Docker-Latest, kopieren da unser Test-Zertifikat, fügen das zu den CAS und das war's. Mehr ist das nicht.

Die Dateien sind alle auf dem GitHub, den Link gibt es in den Slides und in

dem Vortragsprogramm auf dem GitHub-Account, da gibt es die Files, da gibt es auch ein Readme, was man machen muss, um halt sowas zu bauen, also man müsste nicht abfotografieren oder Copy-Paste aus der Präsentation, da gibt es alles, muss man sogar nur die Verzeichnisse reinklonen in GitLab und dann einfach Bild laufen lassen, ist alles auf dem GitHub, dann gut geladen.

Bitte? Boah, frag mich nicht. Artistic. So, dann braucht man dafür eine CI-Konfiguration, die ist ein bisschen komplizierter, aber wir gehen die mal durch.

Wenn man Overlay benutzt hat, braucht man dann dieses Docker-Driver, wenn man nicht umgestellt hat, dann kann man es weglassen. Image-Tag ist auch eine Variable, die setzt sich zusammen aus unserem Registry-Fahrt, HTTPS, Docker-Registry-Domain.com, der GitLab kennt

die ja, weil der hat einen Frontend dafür und commit-reference-name, also wäre dann Master oder Branch-Name oder Tag-Name. Also, bevor wir überhaupt anfangen, lockt er sich ein mit dem CI-Token, Token wird auch per Variable, den sehen wir nicht, das ist intern, das ist so die Standard-Konfiguration wirklich von CI.

So, und dann bauen wir ein Docker-Image, Stage-Build, also kann man verschiedene Stages test, build, deploy und wir benutzen ein eigenes Image, das ist die Gruppe, die wir erstellt haben und Docker-Master, also Master-Branch.

So, das ist interessant, Services, um ein Docker-Image zu bauen über CI, braucht man dann ein Service, Service ist ein zusätzlicher Container einfach, der gestartet wird und das ist nämlich der Docker-in-Docker-Image, den wir dann später nochmal bauen. Tags kann man weglassen, aber die CI-Runner kann man taggen, also diese CI-Runner ist zum Beispiel Privilege, läuft in Privilege Mode, das

heißt, der ist dann dint getaggt, das heißt, auf diesem CI-Runner laufen nur dint-Jobs, also Docker-in-Docker-Jobs und sonst keine. So, und dann Docker-Build, Docker-Push, das war's. Das gleiche macht man dann für Docker-in-Docker-Image, also dint-Image,

das ist genauso aufgebaut, nur hat hier ein paar Unterschiede, ist so original, kopiert von dem Docker-Image, von dem Docker-File.

Und die gleiche CI-Konfiguration. Sobald man diese zwei Container gebaut hat, gepusht hat, kann man dann verschiedene Docker-Container damit

bauen oder auch die selbst dann nochmal damit bauen, regelmäßig und die Konfiguration dafür sieht dann folgendermaßen aus, genauso wie davor. Also Overlay, wie ich schon sagte, könnte man weglassen, könnte man auskommentieren und zum Schluss baut man

eine Image mit dem Image-Tag und pusht das in die lokale Registry zu diesem Projekt hoch. Und man fügt diese Datei in das Repository, man fügt da ein Docker-File hinzu und verschiedene Dateien, die man halt braucht dafür und das war's. Somit baut man dann im Endeffekt eigene Docker-Images mit GitLab CI.

So, gibt's dazu noch Fragen zu dem Thema Bauen? Okay, dann gehen wir mal weiter vor. Forward

-Proxy. Viele Enterprise haben Forward-Proxy mit Filtering, mit was auch immer, auch in der Server-Infrastruktur. Wenn man Glück hat, ist das ein relativ einfaches Forward-Proxy und es filtert nicht viel und es ist ein transparenter Proxy. Wenn man Pech hat, ist es kein transparenter Proxy.

Dann gehen wir kurz darauf ein, was man da machen kann oder was wir damit machen, um das umzugehen. Also, Problem ist klar, nicht jede Applikation immer hat Proxy-Support oder es ist

manchmal sehr tricky, muss man lange suchen, versionsabhängig, wie man die Proxy-Konfiguration macht. Wenn man, wie wir schon angesprochen, wenn man die Proxy-Konfiguration immer in CI-Konfiguration machen, dann

hat man immer so einen Blob in CI, der nochmal dazukommt und den man dann eventuell anpassen muss. Das heißt, das möchten wir auch dann vermeiden. Wir möchten es auf einer Stelle irgendwo konfigurieren oder an wenigen Stellen wie möglich. So, man möchte dann wahrscheinlich Environment-Variablen setzen in dem System und hoffen, dass das Programm Gebrauch

von diesen Environment-Variablen nimmt und wenn das nicht der Fall ist, das gibt es nämlich auch, dann haben wir uns gedacht, ein lokales Transparent-Proxy auf dem CI-Runner-Maschine laufen zu lassen,

der nichts anderes tut, als der ganze HTTP-Traffic durch sich leitet und zu der nächsten Proxy-Instanz. Also, das ist so die minimale Konfiguration. Hier würde man den Upstream-Proxy

konfigurieren und dazu gibt es dann noch einen IP-Tables-Rule, Quick and Dirty. Funktioniert aber nicht für HTTPS. Für HTTPS muss man trotzdem HTTPS-Proxy

setzen und der Proxy muss das unterstützen. Und der Proxy muss Connect unterstützen. Mit HTTPS kann eventuell tricky sein. So, keine Fragen? Gut. Dann zum Schluss gibt es

noch ein paar Bugs, die wir gesehen haben, die gerade dabei sind gefixt zu werden. Der eine Bug ist mit Git-Sub-Modules. Git-Sub-Modules, sagt's irgendwas? Okay, einige nicken.

Von damals noch. Manchmal hat man viele Repositories. Manchmal, wie Facebook, hat man den größten Repository in der Welt, oder war das Microsoft?

Die haben eine Extension geschrieben für Git, damit das große Repository da einpasst. Und manche haben dann viele kleine Repository und so ein Meter-Repository, der auf die anderen dann verweist. Also, noch mal zu Git-Modules. Ich habe ein Repository, ich habe da Dateien, aber

ich möchte auch nicht Dateien von einem anderen Repository einfach kopieren, sondern ich möchte es verlinken. Und beim klonen mache ich Recursive, glaube ich, und dann klont er mein Repository und guckt, aha, da gibt es auch einen Verweis auf ein anderes Repository und klont das nochmal rein in ein Verzeichnis.

Ich weiß nicht, bei SVN, wie ist es damals? Genau, genau.

Gibt es Vor- und Nachteile? Ich wiederhole nochmal, was du gesagt hast. Sobald man ein Repository zu einem Sub-Module-Repository verlinkt, verlinkt man wirklich zu einem Commit, also geht im Endeffekt alles Commit, zu einem Commit.

Das heißt, man kriegt nicht immer die latest Version, sondern man kriegt irgendeine Version, gibt es Vor- und Nachteile. Vorteil natürlich, ich bin immer auf der Version, die es funktioniert und nicht der Upstream hat irgendwas geändert, hat eine neue Version gebraucht und plötzlich funktioniert bei mir nichts. Aber hat den Nachteil natürlich, ich muss immer aufpassen, aha, gibt es da eine neue Version, dann verweise ich immer auf die neue Version.

Bist du sicher? Ich glaube, du kannst nur auf Commit-Basis, auch wenn du auf Master verweist, dann ist das immer nur der jetzige Master, ne?

Genau, musst du manuell dann anpassen.

Ich wiederhole nochmal, damit man den Verweis von dem Repository auf ein Sub-Module-Repository

auf ein latest oder auf einen bestimmten Master macht, muss man in die configs rein. Ja, ok, das wusste ich auch nicht, guck mal. So, wenn wir über CI ein Repository auschecken und darauf irgendwelche Builds, Tests laufen lassen möchten und wir haben dieses Repository mit Sub-Modules gelinkt zu einem anderen Repository, haben wir so ein Fehler bekommen.

SSL-Certificate-Problem, enable to access und dann github.com. So, das heißt, man muss es jetzt nicht mit CA vertauschen, das ist tatsächlich irgendein

Problem mit Golang, wie Golang verschiedene Zertifikate behandelt, dafür gibt es einen Bug und der fix soll in der nächsten Release, in ein paar Wochen kommt es raus, soll es gefixed sein. Also, wenn ihr das aufsetzt und diesen Fehler seht, das hat nichts mit eurer CA oder mit Zertifikat zu tun, das ist was anderes.

Also, es ist tatsächlich ein Problem, du kannst keine Repositories auschecken, die Sub-Modules haben zurzeit. So, dann gibt es noch eine Sache mit Git LFS. Git LFS ist ein Large File Storage für Git, also Git geht

super um mit Textdateien, Code, TeX oder was auch immer, was Text ist, Git geht ganz schlecht um mit Binary Dateien, um Videos.

So, Git LFS macht da einen Verweis in Git und lädt die Dateien hoch auf Git LFS Server, in dem Fall ist er in GitLab integriert.

So, und das klappt auch nicht, sobald man ein Projekt mit LFS-Objects hat, man hat dann ein Projekt, die Verweise, aber die Objects nicht, die werden nicht ausgecheckt.

Wir haben Workaround, wir haben ein eigenes Image, wir haben wirklich nur sehr wenige Repositories, die die LFS benutzen und wir möchten dieses Repository an dem Release einfach taren, wandeln und als Artifakt hochladen in Git, damit der Kunde oder

diejenige einfach mal auf das Artifakt Download Button klicken muss und hat dann Archiv mit allen, Artifakt mit allen da drinnen. So, und dafür haben wir dann Docker Image gebaut, der holt sich LFS-Sourcen und dann macht Git LFS Fetch und holt die LFS-Objekte manuell.

So sieht es aus, also man kennt ja schon, Image, Ubuntu, also wir nehmen ja unser eigenes Ubuntu oder man kann Original Ubuntu nehmen, man lädt das aktuelle LFS runter, installiert Git LFS Install, Git LFS Fetch und Checkout und der holt sich dann die ganzen Objekte aus dem GitLab.

Und dann tat man das, man sagt man soll dann das Artifakt hochladen, der soll für zwei Wochen aufgehoben werden und da soll nur an den Branches oder Tags erfolgen, wo Release drin ist.

So, das war's, also ich finde GitLab ist ein sehr tolles Produkt, also vielleicht wenn ich ein bisschen gemerkt habe, aber das Produkt hat sich, also die Community ist super, das entwickelt sich sehr schnell.

Man sieht ja in einer Enterprise Architektur, die bekommen jetzt immer mehr Enterprise Kunden, man sieht so einen Bugs, dass die damit manchmal sehr viel Challenge haben, das in Enterprise Infrastrukturen zu deployen. Was mir persönlich ein bisschen fehlt bei GitLab, dass die Entwickler Ruby on

Rails entwickeln und auch ein Großteil Beispiele für Ruby on Rails und auch Frontend. Also ich hätte mir gewünscht, dass da auch ein bisschen Systemtools, Golang, Perl oder PHP oder was auch immer,

da könnt ihr Beitrag leisten, mal Videos machen, wie man eine bestimmte Sache mal schnell in GitLab CI aufsetzt. Und jetzt gibt es Fragen. Ja, Großteils, ich wiederhole nochmal, wir haben verschiedene Bugs gefunden oder wir

haben verschiedene Bugs getrackt, wie lange dauert bis ein Bug gefixt ist. Großteils schnell, manche Bugs, weiß man ja so, Legacy Sachen oder Architekturänderungen, manchmal so ein Golang, dieses

Submodules Bug, da ist so ein Rattenschwanz rausgekommen, da haben die angefangen, ist ja hier eine kleine Sache. Und dann nochmal Dependencies, da Golang Version updaten, manchmal dauert, also dieser Bug ist schon länger unterwegs.

Aber Großteils, so wirklich Kleinigkeiten, die sind sehr schnell, also schneller als man erwarten würde. Ja, da haben wir so ein Workaround, wenn ein Workaround möglich ist. Also mit Submodules haben wir

kein Workaround gefunden, aber Gott sei Dank haben wir fast keine Repositories, noch keine Repositories mit Submodules.

Weiß ich nicht. Also die Frage war, ist GitLab ein Versuch, wie Jenkins und Artifactory zu integrieren? Ja und nein, Artifactory kann

man trotzdem dazu haben, würde ich sogar empfehlen, da sind wir auch dabei, weil Jar-Dateien will man nicht unbedingt als Artifacts, weil Artifactory ist viel mehr. Ich bin mir nicht sicher, ob man mit Artifactory auch Golang und Perl-Module hochladen kann, da bin ich mir nicht sicher.

Aber das wäre halt Alternative, Artifactory ist glaube ich sehr stark auf Java orientiert. Wir benutzen auch dazu Artifactory, auf jeden Fall. Artifacts im GitLab ist eher so, das ist ein Release, das ist der Bundle dazu. Bitte

Kunde oder wer auch immer, Product Manager, klickt drauf, schickt dem Kunden das Release und fertig. Du weißt, dass es die Pipelines durchgegangen ist, dass es getestet ist und dass es bestimmte Qualität hat. Wenn man Artifakten baut, die man später in die Projekte inkludieren möchte, so wie Jar-Dateien in Java, dann besser über Artifactory.

Jenkins ist ein anderes Thema, da gibt es Vorteile, der hat sich wirklich sehr stark verbessert in der letzten Zeit. GitLab ist hinterher ein bisschen meiner Meinung nach, aber es hat meiner Meinung nach ein bisschen frisches Gefühl.

Da gibt es zwar ein paar Kinderklarankeiten, aber diese Runner-Architektur hat mich fasziniert.

Wir starten jetzt damit, wir wollen das sehr gerne machen, können gerne Austausch machen. Wir haben auch einen Kunden, der das machen möchte.

Ich kann noch nicht viel dazu sagen, wir müssen erstmal sogar gucken, was wir als Backend haben, weil ich glaube, GitLab unterstützt nur Kubernetes ganz gut und bei Kubernetes höre ich immer negativen Feedback.

Das ist auch die Sache, die wir noch evaluieren, vielleicht bis nächstes Jahr. Aber das ist genau die Sache, warum dieser Vortrag, weil es gibt ein 10 Minuten Video von GitLab,

ich habe hier ein Ruby und Rails Projekt, ich habe hier ein Kubernetes Cluster, ich habe hier ein Template von GitLab CI und dann habe ich direkt die Tests, das Deployment, Auto Scaling und alles in 10 Minuten. Wir haben gesagt, super Sache, probieren wir mal und dann das, dies und dann habe ich mir gedacht, okay,

wir haben die Arbeit gemacht und das wollen wir der Community weitergeben, damit ihr auch weiß, was euch erwartet. Dass du nicht dein Manager sagst, mit GitLab bin ich in 10 Minuten fertig, da habe ich die Pipeline aufgesetzt. Noch mehr Fragen?

Eine Frage, meine Erfahrung nach ist es in Companies, die teilweise auch eine eigene PKI haben, gar nicht so schwer, ein eigenes Zertifikat zu kriegen. Was war euer Grund jetzt zu sagen, wir machen das auf einen anderen Weg, weil ich meine, ihr habt jetzt ja auch relativ viel Zeit dabei investiert, das mit einer Self-Science zu machen.

Du kriegst ein Zertifikat von der CA gesigned, aber der ist von der CA gesigned, von deiner internen CA. Das heißt, wenn du das Zertifikat haben willst, das kannst du ausstellen, können wir hunderte von ausstellen.

Das ist kein Problem, nur du trustest ihn nicht, weil die CA selbst signed ist oder meinst du eine... Ja, normalerweise, die haben halt irgendwie ihr eigenes Zwischenzertifikat, aber natürlich ein globales Sign. Ach so, okay, ja. Dann ist das so ein offiziell nötiges. Das ist aber auch nicht der Fall, dass die... Okay, verstanden.

Ja, das ist ein selbst erstelltes, unter das CA. Ah, okay, das habe ich verstanden. Das ist nicht immer, dass man intern eine CA offiziell signed betreibt, aber macht auch Sinn. Wir haben auch Kunden, die eigene CA betreiben, selbst eigene CA haben, also eigene CA Center.

Da ist es natürlich kein Problem, musst du halt nur drei Wochen warten. Ja? So ein Wildcard-Zertifikat kostet auch nicht die Welt. Das macht dir ja mehr Arbeit, das einzufüllen.

Ja, ja. Das ist halt so ein scheiß Zertifikat kostet. Ja. Ist das 600 Euro, oder was kostet ein Wildcard? Ja, ja. Die Frage war, macht das wirklich Sinn, eine eigene CA zu betreiben, wenn man relativ günstig ein Wildcard-Zertifikat für das interne Netz einfach kaufen kann?

Nein, macht das keinen Sinn. Aber wenn man es schon hat und wenn man beim Kunden als Konsulten unterwegs ist, man sagt ja nicht, nee, du musst erstmal ein CA-Zertifikat kaufen. Natürlich kann man es machen, aber dann wird gesagt, nee, machen wir nicht. Wir machen so und nicht anders. Da muss man mitmachen.

Ja, natürlich macht das Sinn. Deshalb sagte ich ganz am Anfang, wenn ihr die Möglichkeit habt, offizielle Zertifikat, ob es Let's Encrypt, ob es signierte CA, ob es gekauftes Wildcard ist, immer besser.

Dann, ich bedanke mich für die Teilnahme. Die Dateien sind auf GitHub und die Slides lade ich gleich hoch.