GitOps: Alles über die au­to­ma­ti­sier­te IT-In­fra­struk­tur

GitOps ist ein Konzept, das über einen de­kla­ra­ti­ven Ansatz In­fra­struk­tu­ren und An­wen­dun­gen verwaltet und mit Git kon­trol­liert. Die Ziele dieser Idee sind au­to­ma­ti­sier­te Abläufe, Zeit­er­spar­nis und eine bessere sowie sicherere Zu­sam­men­ar­beit einzelner Teams an den Re­po­si­to­ries.

Im Bereich der Software-Ent­wick­lung spielt Au­to­ma­ti­sie­rung eine große Rolle. Dies ist einer der Gründe, warum DevOps ein solch durch­schla­gen­der Erfolg be­schie­den war. Die Basis hierfür ist die Idee der „In­fra­struc­tu­re as Code (IaC)“, die In­fra­struk­tu­ren und Kon­fi­gu­ra­tio­nen eines IT-Systems abbilden und damit re­pro­du­zier­bar machen soll. GitOps ist eine logische Er­wei­te­rung dieses Ansatzes. Seit 2017 steuert die Open-Source-Software Git den gesamten Ver­wal­tungs­pro­zess einer Anwendung von der Ad­mi­nis­tra­ti­on bis zur letzt­end­li­chen Software-Ent­wick­lung als „Single Source of Truth“. Dafür wird bei GitOps ein Ziel­zu­stand definiert und die In­fra­struk­tur so lange überprüft und ggf. angepasst, bis dieser Zustand erreicht wird.

Wea­ve­works stellt dafür eine Reihe von Best Practices für die Ver­ein­heit­li­chung der einzelnen Mo­ni­to­ring-Methoden für Container bereit. Diese lassen sich auf Ku­ber­netes und andere Tech­no­lo­gien mit Cloud-Back­ground anwenden und so einfacher managen. Git geht dabei auf ein Ver­si­ons­kon­troll­sys­tem zurück, das Linus Torvald 2005 ent­wi­ckelt hat. Dieses erlaubt es un­ter­schied­li­chen Ent­wick­ler­teams, gemeinsam und parallel an einem Projekt zu arbeiten. Dabei werden Än­de­run­gen erst nach ge­mein­sa­mer Ab­stim­mung über­nom­men und ältere Ent­wick­lungs­stän­de bewahrt. Ent­wick­le­rin­nen und Ent­wick­ler können gleich­zei­tig an un­ter­schied­li­chen Aspekten arbeiten und diese am Ende zu­sam­men­füh­ren. Ein um­fang­rei­ches Git-Tutorial finden Sie in unserem Digital Guide.

Bei GitOps wird zunächst der Ziel­zu­stand eines Systems de­kla­ra­tiv be­schrie­ben. Än­de­run­gen werden dann nach dem Prinzip von Git über Pull-Requests vor­ge­nom­men. Werden diese durch­ge­führt, ändern sie das Git-Re­po­si­to­ry. Wenn nun eine Pull-Anfrage in einem Umfeld mit GitOps gestellt wird, aktiviert sich der GitOps-Operator, erfasst den Commit und erfragt den aktuellen Zustand über Git. Diesen ver­gleicht er mit dem ge­wünsch­ten Zustand im Re­po­si­to­ry. Sind die Än­de­run­gen ab­ge­seg­net, werden sie mit dem bis­he­ri­gen Zustand zu­sam­men­ge­führt und direkt für die Live-In­fra­struk­tur über­nom­men. Dies führt zu schnel­le­ren und rei­bungs­lo­sen Abläufen, sorgt gleich­zei­tig aber auch für die Sta­bi­li­tät und Zu­ver­läs­sig­keit des Systems.

Durch klar de­fi­nier­te und un­ab­än­der­li­che Prin­zi­pi­en sollen GitOps-Workflows immer ver­läss­lich funk­tio­nie­ren. Das betrifft zuerst die be­schrie­be­nen de­kla­ra­ti­ven Systeme, die bereits von anderen Cloud Natives bekannt sind. Die de­kla­ra­ti­ve Be­schrei­bung sorgt dafür, dass das gesamte System als Code behandelt und ver­sio­niert werden kann. Dies dient der Si­cher­heit und Sta­bi­li­tät des gesamten Systems, da auch Ab­wei­chun­gen von der Git-Version so sofort erkannt und gemeldet werden können. Zu­sätz­lich sorgen SSH-Keys dafür, dass der Ursprung eines Codes immer nach­ver­folgt werden kann. Durch die vorherige De­kla­ra­ti­on können Än­de­run­gen auch au­to­ma­ti­siert und even­tu­el­le Feh­ler­quel­len früh­zei­tig entdeckt und behoben werden.

Der primäre Ansatz von DevOps ist und war es, Ent­wick­lung und Aus­füh­rung näher zu­sam­men­zu­brin­gen und so Ar­beits­ab­läu­fe zu ver­ein­fa­chen. Weil die einzelnen Teams enger zu­sam­men­ar­bei­ten, ver­bes­sert sich das End­pro­dukt und Än­de­run­gen können schneller und präziser durch­ge­führt werden. Diesen Ansatz greift GitOps auf und wendet ihn kon­se­quent auf den Aus­füh­rungs­teil (Ope­ra­ti­ons) an. GitOps kon­zen­triert sich dabei voll und ganz auf Git, während DevOps und DevSecOps eher als grund­sätz­li­cher Gedanke zu verstehen sind, der die Zu­sam­men­ar­beit ehemals ge­trenn­ter Bereiche vor­an­treibt und auf CI- und CD-Pipelines setzt. Beide Ansätze können al­ler­dings auch mit­ein­an­der verbunden werden.

Im Un­ter­schied zu Con­ti­nuous Delivery und Con­ti­nuous In­te­gra­ti­on zieht GitOps alle be­nö­tig­ten In­for­ma­tio­nen nach dem Pull-Prinzip direkt von Git und ver­zich­tet dabei auf das De­ploy­ment über einen CI-Server. Dieser kann zwar nach wie vor auch mit GitOps verwendet werden, ist al­ler­dings nur noch für Aufbau und Tests zuständig. Mehr zum Thema Con­ti­nuous In­te­gra­ti­on vs. Con­ti­nuous Delivery vs. Con­ti­nuous De­ploy­ment erfahren Sie im Digital Guide.

Ku­ber­netes ist durch seine Viel­sei­tig­keit die wahr­schein­lich wich­tigs­te Plattform für die Ver­wal­tung con­tai­ner­ba­sier­ter An­wen­dun­gen. Auch Ku­ber­netes funk­tio­niert de­kla­ra­tiv und be­trach­tet den Ziel­zu­stand eines Systems. Daher kann Ku­ber­netes mit GitOps sehr gut funk­tio­nie­ren und auch als Operator agieren. Wichtig ist dabei aber, dass Quellcode und Kon­fi­gu­ra­ti­on zur besseren Übersicht und aus Si­cher­heits­grün­den getrennt werden. Der Ist-Zustand kann dann in einem eigenen Git-Re­po­si­to­ry ge­spei­chert werden. Wichtig ist außerdem der Einsatz der passenden Syn­chro­ni­sa­ti­ons­tools, die un­er­laub­te Zugriffe und even­tu­el­le Fehler ver­hin­dern.

Mitt­ler­wei­le gibt es für GitOps zahl­rei­che Tools, die die Au­to­ma­ti­sie­rung deutlich ver­ein­fa­chen und ver­bes­sern sollen – z. B. Werkzeuge für die Arbeit mit Ku­ber­netes, die als Ope­ra­to­ren fungieren und die Im­ple­men­tie­rung von GitOps über­neh­men. Der be­kann­tes­te Operator (oder Custom Con­trol­ler) ist Flux. Al­ter­na­ti­ven sind ArgoCD oder Fleet. Zu den wich­tigs­ten Tools für mehr Si­cher­heit gehören SOPS von Mozilla und Sealed Secrets von Bitnami. Für den Einsatz mit Ku­ber­netes Clustern eignen sich vor allem Cluster API oder Fleet. Insgesamt ist der Markt ver­gleichs­wei­se groß, sodass es für beinahe jeden Ein­satz­zweck auch das passende Werkzeug gibt.

Will man die Frage, wie gut und passend für die eigenen Zwecke GitOps wirklich ist, ab­schlie­ßend be­ant­wor­ten, lohnt ein Blick auf die Vor- und Nachteile des Konzepts.

• Pro­duk­ti­vi­tät: Durch die Au­to­ma­ti­sie­rung können deutlich mehr Än­de­run­gen in kürzerer Zeit durch­ge­führt werden. Ent­wick­le­rin­nen und Ent­wick­ler treiben dadurch Projekte viel ef­fek­ti­ver voran.
• Si­cher­heit und Sta­bi­li­tät: Durch die genauen Kon­trol­len werden Fehler schneller entdeckt und sogar au­to­ma­tisch behoben. Das trägt zu mehr Si­cher­heit und Sta­bi­li­tät bei. Durch be­last­ba­re Rollbacks ist die Wie­der­her­stel­lung älterer Stände außerdem deutlich einfacher und der Pull-Ansatz ver­hin­dert un­ge­woll­te Kom­pli­ka­tio­nen.
• Ein­heit­lich­keit: Ar­beits­ab­läu­fe werden durch GitOps ver­ein­heit­licht. Das führt zu einer besseren und ein­fa­che­ren Zu­sam­men­ar­beit und erlaubt neuen Mit­ar­bei­ten­den außerdem einen schnel­le­ren Einstieg.

• Trennung von CI und CD: Durch die strikte Trennung von CI und CD beim GitOps-Ansatz kann es schwierig sein, Tests nach dem De­ploy­ment durch­zu­füh­ren.
• Übersicht: Gerade bei der Arbeit mit mehreren Um­ge­bun­gen kann es mit GitOps schnell un­über­sicht­lich werden. Zahl­rei­che Re­po­si­to­ries und Kon­fi­gu­ra­tio­nen können zur Ver­wir­rung beitragen.