zurück zum Artikel

Langsame Pipelines, blockierte Reviews, Abbrüche: Um diese Probleme in CI/CD-Pipelines zu lösen, gibt es bewährte Tools und Observability-Praktiken.

Viele Administratorinnen und Administratoren kennen es: Die CI/CD-Pipelines sind angelaufen und der Prozess testet viele Schritte automatisiert, baut Software, packt Releases und überträgt alles in die Produktion. Eigentlich funktioniert es – wenn da nicht lästige Wartezeiten wären: Reviews blockieren, und Entwicklerinnen und Entwickler können nicht weiterarbeiten. Um den Problemen auf die Spur zu kommen, müssen die Beteiligten die Struktur von CI/CD-Pipelines besser verstehen und mit Observability-Praktiken tief in Prozesse und Workflows hineinschauen, um darauf aufbauend Optimierungsstrategien zu entwickeln. Dieser Artikel dreht sich um Pipeline-Effizienz und Observability-Analysen.

Michael Friedrich

Michael Friedrich ist Senior Developer Evangelist bei GitLab mit Fokus auf Observability, DevSecOps, AI und schreibt auf opsindev.news über seine Erfahrungen. Michael entspannt gerne beim LEGO-Bauen.

Ineffiziente Pipelines

Auf GitLab findet sich für Testzwecke ein Pipeline-Projekt [1] (siehe Abbildung 1) mit mehreren Stages und Jobs. Das Monorepo simuliert ressourcenintensive Aufgaben (Build aus C++- und Go-Quellen), Frontend-Jobs mit Caching-Anforderungen (Node.js) sowie Test- und Deployment-Jobs auf unterschiedlichen Plattformen (Linux und Cloud Native). Hinzu kommen komplexe Ressourcen-Provisionierungen (Ansible, Terraform etc.), Secrets Management, Sicherheits- und Laufzeit-Observability sowie eine Performance-Überprüfung. Das Projekt stellt die Pipeline-Effizienz vor echte Herausforderungen und dient als Beispiel für wichtige Aspekte der Observability.

CI/CD-Plattformen verhalten sich im Prinzip ähnlich wie das Beispielprojekt. In einem ersten Schritt bekommen Anwenderinnen und Anwender einen Überblick über die Laufzeit, indem sie sich über fehlgeschlagene und erfolgreiche Jobs ein Bild machen und so erste Muster erkennen. Wenn zum Beispiel die Zahl der fehlgeschlagenen Jobs übermäßig ansteigt, könnte dies mitunter ein Fehler in der CI/CD-Infrastruktur sein, der Benutzer zwingt, diese Jobs immer wieder neu anzustoßen.

Ebenso hilfreich ist es, sich die Laufzeiten der Commits anzuschauen. Zum Beispiel lässt sich die Frage beantworten, welche Code-Änderung dafür sorgt, dass die Pipeline eine Minute länger läuft. Möglicherweise verwendet der Code mehr externe Abhängigkeiten, was die Download-Zeit erhöht, sofern kein Caching konfiguriert ist. Oder die Änderung erfordert längere Kompilierungszeiten, was sich nicht nur negativ auf den aktuellen Merge-Request auswirkt, sondern, falls in den Hauptzweig gemergt, auch auf alle nachfolgenden Entwicklungsarbeiten und Pipelines.

Ein wichtiger Analyseschritt ist, sich einen Überblick über den roten Faden der CI/CD-Pipelines zu verschaffen. Unterschiedliche Plattformen führen Jobs unterschiedlich aus: Sie fassen diese in bestimmten Stages oder Workflows zusammen. Erst wenn die Pipeline einen Workflow mit allen Schritten erfolgreich beendet hat, stößt sie darauffolgende an. Diese Reihenfolge wird zum Problem, wenn Jobs falsch gruppiert sind: Während beispielsweise der ressourcenhungrige C++-Job fünf Minuten läuft, blockiert er die Build-Stage. Dort könnte die darauffolgende Test-Stage schon für alle fertigen Build-Jobs laufen. Als Lösung bieten manche Systeme eine asynchrone Job-Ausführung an, in der Admins Job-Abhängigkeiten definieren.

Im asynchronen Verfahren schreitet die Pipeline unabhängig vom Workflow-Status fort und stößt schnellere Go- oder Node.js-Jobs an und testet sie. Dies ist für Entwicklungsarbeiten von Vorteil, die größere Änderungen vornehmen und nicht alle Builds abwarten sollen. Wenn beispielsweise der Test im Node.js-Build-Job fehlschlägt, während der C++-Build-Job noch kompiliert, können die Entwicklerinnen und Entwickler bereits die Fehlerbehebung angehen. Wenn sie darüber hinaus die fehlerhafte Pipeline abbrechen, sparen sie Ressourcen, da nachfolgende C++-Tests nicht nötig sind. Im GitLab-Beispiel schalten Anwender das asynchrone Verhalten [2] mit dem Attribut needs ein.

Listing 1 zeigt vereinfacht die Pipeline des Beispiel-Projekts mit Build- und Test-Jobs für C++, Go und Node.js mit asynchroner Ausführung. Die Jobs test-go und test-nodejs starten, sobald die entsprechenden Build-Jobs fertig sind, obwohl die gesamte Build-Stage noch arbeitet.

Listing 1: Vereinfachte GitLab-Pipeline mit Abhängigkeiten

# Stage Definition
stages:
  - build
  - test
  - deploy

# Jobs 
build-cpp:
  stage: build
  script:
    - ci/build_cpp.sh

build-go:
  stage: build
  script:
    - ci/build_go.sh

build-nodejs:
  stage: build
  image: ubuntu:22.04
  script:
    - ci/build_nodejs.sh
  artifacts:
    paths:
      - '*.txt'

test-cpp:
  stage: test
  script:
    - ci/test_cpp.sh

test-go:
  stage: test
#Async execution, build stage does not need to finish
  needs: [build-go]
  script:
    - ci/test_go.sh

test-nodejs:
  stage: test
# Async execution, build stage does not need to finish
  needs: [build-nodejs]
  script:
    - ci/test_nodejs.sh 

Tieferer Einblick mit Open-Source-Tools für Metriken

Zur tiefergehenden Analyse bieten sich Observability-Daten in der Form von Metriken und Traces an. Allgemein siehe dazu den Artikel "Observability als Denkweise [3]". Für das Einsammeln von Metriken für Observability-Tools gibt es ausgereifte Open-Source-Projekte wie Prometheus und dessen Exporter-Agenten. Der GitLab CI Pipeline Exporter [4]holt die Laufzeit-Werte von Jobs der GitLab-Rest-API ab. Diese Werte lassen sich historisch in Grafana-Dashboards visualisieren. Der Alert-Manager alarmiert bei zu langen Laufzeiten von Pipelines direkt. Listing 2 liefert ein Beispiel dafür, wie sich der GitLab CI Pipeline Exporter mit Docker Compose starten lässt, um Projekte auf GitLab-SaaS zu überwachen. Das Beispiel erfordert Docker (Docker Desktop, Rancher Desktop, Podman etc.).

Listing 2: Beispiel mit Docker Compose

$ git clone https://github.com/mvisonneau/gitlab-ci-pipelines-exporter
$ cd gitlab-ci-pipeline-exporter/examples/quickstart
$ docker compose up -d

# Grafana ist erreichbar auf http://localhost:3000

Neben den CI/CD-spezifischen Metriken ist es wichtig, Storage- und Netzwerk-Traffic sowie die Runner- und Executor-Services zu überwachen. Disk-IO-, CPU-Usage-, node/pod- und Container-Metriken können direkten Einblick geben, wo Performance-Engpässe herkommen. Mit Prometheus Node Exporter bekommen Anwender detaillierte Einblicke. Manchmal kommen auch langsame oder mit Paketverlust behaftete Verbindungen ins Spiel, weil eine nicht geplante Route zwischen CI/CD-Server und -Runner verläuft.

Noch tiefer: Pipeline Tracing

Wie im einführenden Artikel "Observability als Denkweise [5]" beschrieben, vertieft Tracing die Fehlersuche, denn neben Metriken und Logs erhalten Anwenderinnen und Anwender damit zusätzliche Observability-Datentypen. Diese erkennen auch vollkommen unvorhersehbare Faktoren (Unknown Unknowns). Ein Beispiel: Die Monatsabrechnung einer Cloud-Infrastruktur wächst stetig, während die Analyse der Ressourcen-Graphen im Monitoring nur eine konstante Auslastung mit einigen Spitzen zeigt, die jedoch auf keinerlei Ursachen zurückschließen lassen. Nachdem das DevOps-Team alle Daten auf einer CI/CD-Observability-Plattform gesammelt hatte, ergab das Metrik-Monitoring Lastspitzen Mittwoch um 11 Uhr.

Die zugehörigen Logs zeigen Applikations-Timeouts bei ausgehenden Requests, und Traces von den CI/CD-Pipelines liefern Aufschluss darüber, dass bestimmte Abhängigkeiten-Downloads in DNS-Resolve-Timeouts laufen. Die daraus resultierenden Wiederholungsversuche wurden überschattet von ungeduldigen Benutzern, die zusätzliche manuelle Jobs anstießen, um das Pipeline-Ergebnis noch vor der Mittagspause dokumentieren zu können. Das Problem löste sich, nachdem stabile Netzwerk-Routen und DNS-Server konfiguriert waren.

Erste Ergebnisse im Tracing liefert die Laufzeit von Abschnitten: Eine Pipeline mit Stages und Jobs lässt sich anhand der Laufzeit aller Komponenten als Zeitstrahl visualisieren. Ähnlich zur Ladezeit einer Webseite, die man mittels Browser-Development-Tools auf potenzielle Probleme untersuchen kann, gibt die Laufzeit von Jobs fundierten Einblick.

Eine einfache Möglichkeit zum Messen der Ausführungszeiten von Scripts ist, sich Start- und Endzeit in Shell-Variablen zu merken und dann die Differenz zu berechnen. Das Beispiel in Listing 3 zeigt einen Job für die Installation von Node.js mit vielen Einzelschritten. Die Variablen START und END speichern die aktuelle Zeit in Sekunden, und der echo-Befehl gibt die Differenz im CI/CD-Log aus. Der Befehl apt update && apt -y install nodejs dauert hier zu lange, weil apt standardmäßig alle Empfehlungen installiert. Der Parameter --no-install-recommends würde die Laufzeit verringern.

Listing 3: Eine Zeitmessung im Skript zeigt Mängel in der Konfiguration

build-nodejs:
  stage: build
  image: ubuntu:22.04
  script:
    - export START=`date +%s`
    - apt update && apt -y install curl
    - export END=`date +%s`
    - echo "Duration: $((END-START))"

    - export START=`date +%s`
    - curl -fsSL https://deb.nodesource.com/setup_current.x | bash -
    - export END=`date +%s`
    - echo "Duration: $((END-START))"

    - export START=`date +%s`
    - apt update && apt -y install nodejs
    - export END=`date +%s`
    - echo "Duration: $((END-START))"

    - export START=`date +%s`
    - npm install
    - export END=`date +%s`
    - echo "Duration: $((END-START))"

In der Praxis ist dieser Logging-Ansatz jedoch fehleranfällig und verschlechtert die Lesbarkeit der Konfiguration. Die Open-Source-Community und Observability-Anbieter haben unterschiedliche Tools entwickelt, die das Problem besser beherrschen. Clientseitige Tracer erhalten dabei die Informationen, die die CI/CD-Systeme ihnen zur Verfügung stellen. Oftmals fragen sie zusätzlich noch API-Endpunkte der Pipeline ab, um die gesammelten Daten mit mehr Kontext anzureichern.

Mastering Observability: Die Online-Konferenz von heise

Die Online-Konferenz Mastering Observability [6] am 11. Juni 2024 zeigt, wie ein ganzheitlicher Observability-Ansatz dabei hilft, Softwaresysteme zu verstehen, zu steuern und zu verbessern. Die von iX und dpunkt.verlag organisierte Online-Konferenz richtet sich an Entwicklerinnen, Entwickler, Ops-Fachleute und DevOps-Teams, die Probleme in CI/CD, Deployment und Operations schneller aufspüren wollen und den Ursachen auf den Grund gehen möchten – mit dem Ziel, Mängel gezielt zu beheben und in Zukunft möglichst zu vermeiden.

Interessierte können sich jetzt für die Mastering Observability anmelden [7] – das Ticket kostet bis 13. Mai 2024 zum Frühbucherpreis 229 Euro, danach dann 279 Euro (alle Preise zzgl. MwSt.). Gruppen ab drei Personen erhalten im Ticketshop darüber hinaus automatisch mindestens 10 Prozent Rabatt.

Wer über den Fortgang der Konferenz Mastering Observability auf dem Laufenden bleiben möchte, kann sich auf der Website für den Newsletter registrieren [8] oder den Veranstaltern auf LinkedIn [9] folgen – der aktuelle Hashtag lautet #masteringobs [10].

Open Source: OpenTelemetry mit tracepusher

Ein Beispiel ist das noch recht neue Tool Tracepusher, das Administratorinnen und Administratoren entweder in CI/CD-Pipelines integrieren oder eigenständig auf der Kommandozeile ausführen. Tracepusher erstellt Traces und Spans im CI/CD-Kontext (insbesondere GitLab [11]) und schickt sie an einen OpenTelemetry-Collector. Ein Beispiel für ein OpenTelemetry-Setup mit einem vorkonfigurierten HTTP-Endpunkt [12] und der Tracepusher-Integration in die Beispiel-CI/CD-Pipeline [13] finden sich auf GitLab.

CI-Visibility mit Datadog

Das Tool Datadog bietet CI-Visibility für unterschiedlichste Plattformen an. Es sammelt CI/CD-Events entweder in eine SaaS-Plattform integriert oder lokal über den Datadog-Agent. Logs und Traces schickt es direkt an die Datadog-API. In der dortigen Weboberfläche lassen sich die Daten dann mit anderen Metriken, Logs und Traces korrelieren. Für eine Beispielkonfiguration mit dem Beispiel-Projekt erstellen Admins zunächst einen API-Key für Datadog [14]. Im GitLab-Projekt navigieren sie zu "Settings/Integrations" und aktivieren die Datadog-Integration [15]. Der richtige Datadog-Endpunkt hängt vom Standort ab, bei falscher Auswahl erhält man die Fehlermeldung "Error: API invalid or blacklisted". Das Skript hat datadoghq.com voreingestellt. Verwendet man die EU-SaaS-Instanz, muss der Wert datadoghq.eu heißen.

Die Weboberfläche von Datadog zeigt alle laufenden und historischen Pipelines und erlaubt tiefen Einblick in die CI/CD-Jobs inklusive einer Zeitlinie und Details zu den Fehlern. Admins verwenden dafür verschiedene Filter. Ein historischer Stage-Breakdown zeigt, wie stark sich die Laufzeiten in unterschiedlichen Commits verschoben haben. So lassen sich etwa Ausreißer von Merge-Request-Pipelines mit neuen Features einfacher identifizieren. Anwender finden auch schnell heraus, dass eine neue Software viele Abhängigkeiten herunterlädt, ohne dass Caching aktiviert ist.

Trace- und Span-IDs mit Honeycomb.io buildevents

Das Open-Source-Projekt buildevents von Honeycomb.io war eines der ersten zum Sammeln von CI/CD-Informationen. Das Kommandozeilenprogramm verwendet den globalen Kontext mit den Umgebungsvariablen, um Trace IDs und Span IDs zu erstellen. Alle Jobs befüllen die Traces, bis am Ende der Pipeline ein extra definierter Job die Sammlung zur Honeycomb.io-API schickt. OpenTelemetry als generisches Ziel unterstützt es bedauerlicherweise bisher noch nicht [16].

OpenTelemetry mit New Relic

New Relic hat eine experimentelle Integration für GitLab-CI/CD-Pipelines [17] bereitgestellt, die Logs, Traces und Metriken sammelt und an den OpenTelemetry-Endpunkt von New Relic schickt. Administratorinnen und Administratoren definieren in der CI/CD-Pipeline eine neue Stage mit einem abschließenden Job, der über Parent-Child-Pipelines eine weitere Pipeline startet. Diese holt sich die Parent-Daten von der GitLab-API, erstellt Logs, Traces und Metriken, die sie anschließend an den OpenTelemetry-Endpunkt schickt. Standalone-Support für OpenTelemetry funktioniert nicht, sodass ein API-Key für New Relic erforderlich ist.

Erste Optimierungen

Mit einigen schnell umsetzbaren Maßnahmen lassen sich CI/CD-Pipelines optimieren. Nicht alle Jobs müssen beispielsweise immer ausgeführt werden: In einem großen Mono-Repository konfigurieren Admins Backend- und Frontend-Jobs in einer Pipeline. Wenn ein Merge-Request nur mit Änderungen im Backend startet, müssen die anschließenden Frontend-Jobs nicht zwingend laufen. Diese Strategie reduziert Laufzeiten und spart Ressourcen.

Das Tool Circle CI erlaubt es, Jobs nur dann auszuführen, wenn ein entsprechender Branch-Name oder Git-Tag dafür erscheint [18]. In GitHub Actions gibt es Filter für Aktions-Trigger [19] und in GitLab steuern Anwenderinnen und Anwender Jobs mit Regeln [20], die Pipelines für unterschiedliche Anwendungsfälle erzeugen. Es lässt sich so nach Git-Branch-Name oder -Tag filtern, Merge Requests als Trigger-Event einschränken oder eigene CI/CD-Variablen prüfen. Diese Regeln greifen über Template-Grenzen hinweg, und erlauben eine Abstraktion für Endnutzer.

Eine effiziente Maßnahme ist "Fail fast": Wenn Admins aus Erfahrung wissen, dass bestimmte Jobs fehlschlagen (etwa Programmierfehler in einer neuen Sprache oder Tests, die niemand lokal ausführt), sollten diese mit Priorität starten und schnell wieder enden, um Ressourcen nur kurz zu binden. Nachfolgende Jobs müssen dann in Abhängigkeit definiert sein.

Caching [21] ist ein wichtiges Thema für Frameworks mit vielen Abhängigkeiten oder großen Paketen, die andernfalls bei jeder Ausführung von Neuem heruntergeladen werden. Caching verringert auch den Traffic in Cloud-Umgebungen – der je nach Dienstanbieter teuer sein kann. Eine weitere Optimierungsstrategie sind reduzierte Container-Images [22]. Blockierend kann bei großen Projekten auch die Git-Historie wirken. Hier hilft eine Clone-Strategie, die nur den aktuellen HEAD auscheckt und auf Historie verzichtet (Shallow Clone [23]).

Jobs, die die gleichen Workflows ausführen, aber auf unterschiedlichen Distributionen getestet werden, lassen sich parallelisieren (Tags in GitLab [24]). Gängige CI/CD-Systeme beherrschen diese Matrix Builds und können zusätzlich Sourcecode unterschiedlicher Sprachversionen testen. Eine wichtige Optimierung gilt auch der Hardware-Konfiguration, denn ressourcenhungrige Jobs sollten auf leistungsstärkeren Geräten laufen, während für die leichtgewichtigen kleiner dimensionierte VMs genügen. Hierzu bietet es sich an, Jobs auf bestimmten Exekutoren festzupinnen. In Kubernetes verwenden Admins node und pod affinity [25].

Kosteneffizienz und Kapazitätsplanung

Mehr Effizienz und schnellere Pipelines müssen nicht zwangsläufig Mehrkosten für schnellere (Cloud-)Ressourcen bedeuten. Die Verantwortlichen sollten analysieren, welche Ressourcen tatsächlich dauerhaft notwendig sind, und wo man den Rotstift ansetzt. Projekte wie OpenCost dokumentieren Kosten für Ressourcen in maschinenlesbarer Form. Kepler verwendet eBPF (Kernel-Monitoring) um Low-Level-Performance-Counter auszulesen. Mit ML-Modellen berechnet es den Workload-Energie-Verbrauch und stellt das Ergebnis als Metrik für Prometheus bereit. Solche Analysen helfen, Energieverbrauch und CO2-Emissionen zu verringern.

Ein weiteres Beispiel sind CI/CD-Exekutoren, die dauerhaft mit vielen Ressourcen laufen. Das kann ein Bare-Metal-Computer in einem Rechenzentrum sein, großzügig dimensioniert virtuelle Maschinen oder ein Container-Cluster mit hoher Rechenleistung. Eine Möglichkeit zu sparen, ist das CI/CD-Autoscaling (Beispiele für GitLab [27] und für GitHub [28]). Dieses provisioniert mehr Ressourcen nur zu bestimmten Zeiten, wenn Pipelines schneller laufen sollen. Anschließend entfernt das System deren Ressourcen, anstatt sie im Idle-Modus weiterlaufen zu lassen.

Verantwortliche planen im Budget oft keine Entwicklungs- und Staging-Umgebung ein, sodass alle CI/CD-Workloads in der Produktionsumgebung arbeiten. Das führt oft zu Deadlocks und Ressourcenverschwendung, da die Produktionslimits für Auto-Skalierung und Overcommitment anders gesetzt sind. Für effiziente Pipelines empfiehlt es sich daher, die CI/CD-Infrastruktur in einer isolierten Umgebung zu betreiben. Das vereinfacht auch die Analyse von ausgehendem und eingehendem Traffic, um beispielsweise Downloads und Container-Pull-Operationen zu minimieren. Generell vereinfacht eine eigene Infrastruktur die Observability, da Admins gezielte Aussagen zur Umgebung treffen können. Mit Automatisieren und Infrastructure-as-Code-Prozessen lässt sich der zusätzliche Aufwand eingrenzen.

Für eine bessere Kapazitätsplanung sind Forecasts wünschenswert, um die stetig wachsende CI/CD-Infrastruktur besser abschätzen zu können. Ein Tool dafür ist Tamland [29], das Prometheus-Monitoring-Metriken analysiert und mit Machine Learning, Prophet und Jupyter Notebook entsprechende Forecasts erzeugt. Das Infrastrukturteam von GitLab entwickelt dieses Projekt und überwacht damit die SaaS-Infrastruktur der Firma.

Security-Observability zur Laufzeit

CI/CD-Infrastruktur ist ein beliebter Angriffspunkt nicht nur für Software-Supply-Chain-Attacken. Oftmals verwendet die CI/CD-Umgebung die gleichen Passwörter und API-Keys wie der Live-Betrieb. Angreifer manipulieren die Software oder kapern Infrastruktur-Accounts, um Bitcoin-Miner zu platzieren. Diese senden sogar Fake-Daten an die Observability-Plattform. Die Beispiele zeigen die Notwendigkeit, CI/CD-Umgebungen zur Laufzeit abzusichern. Im Zeitalter von Container-Clustern ist nicht immer klar, wie es gelingt, alles abzusichern. Hardening Kubernetes, Security Policies und Zero-Trust-Prinzipien sind einige der Themen, denen sich Administratorinnen und Administratoren widmen sollten. Das Buch "Hacking Kubernetes [30]" bietet hier einen umfassenden Einstieg. Der Blogpost "Fantastic Infrastructure as Code security attacks and how to find them [31]" bildet ferner ein informationsreiches Tutorial für die Absicherung von CI/CD-Infrastruktur.

Neben den Werkzeugen kommerzieller Anbieter finden sich für die auf Security ausgerichtete Observability auch zahlreiche Open-Source-Projekte: Falco, Cilium Tetragon und Tracee sind Beispiele für Tools, die frühzeitig Alarm auslösen. Für das Härten von Kubernetes empfehlen sich Open Policy Agent, Kyverno oder Bridgekeeper.

KI – neue Wege für mehr Effizienz?

Künstliche Intelligenz (KI) hilft auch bei CI/CD-Problemen und der Gestaltung effizienter Prozesse. In der OS-Community kam die Idee auf, CI/CD-Job-Logs an ChatGPT zu schicken, um kontextuelle Hilfe zu generieren. Das Project cigpt für OpenAI [32] orientiert sich dabei am Upstream-Project k8sgpt [33] für Kubernetes-Optimierungen. Das hat sich im Falle von Shell-Scripting-Fehlern bewährt (siehe Abbildungen 5 und 6). Wünschenswert wären automatisierte Vorschläge für einen Fix. Neben der OS-Community arbeiten auch die kommerziellen CI/CD-Anbieter an KI-gestützter Fehleranalyse. In Zukunft könnte das so ablaufen: Die KI liefert Ideen, um die Konfiguration zu überarbeiten, sie könnte Tipps für Container-Images geben, die oft Security-Probleme hervorrufen, und sie könnte Vorschläge für das asynchrone Ausführen von blockierenden, kritischen Pfaden erteilen.

Da Job-Logs mitunter sensitive Daten enthalten (Secrets, Passwörter oder Betriebsgeheimnisse), sollten Admins genau prüfen, welche Daten sie an KI-Systeme senden. Die Logs lassen sich mit Webhooks zunächst an OpenTelemetry schicken, um sie dort mit Transformation-Pipelines zu filtern [34], bevor sie an ein KI-Modell gelangen. Das lässt sich mit CI/CD-Tracing kombinieren.

DevSecOps-Effizienz

Admins könnten versucht sein, die Sicherheit betreffende CI/CD-Jobs zu reduzieren, die eine gewisse Laufzeit überschreiten. Hier gilt die Faustregel: Diese Jobs sollten bleiben, denn Security-Scanner erkennen Sicherheitslücken in einem Merge Request frühzeitig, bevor das Problem die Produktion erreicht. Wenn Lücken, die direkt im Main-Branch landen, schnell erkannt sind, lassen sie sich durch sofortigen Commit-Rollback wieder schließen. Oft sind Security-Scanner per Default nicht für bestimmte Programmiersprachen oder Frameworks optimiert, sodass Entwicklerinnen und Entwickler selbst Hand anlegen müssen, um Laufzeit und Testfälle einzuschränken. In GitLabs Static Application Security Testing (SAST) [35] findet sich eine Fülle an unterstützten Sprachen und Frameworks.

Alle können zu Effizienz beitragen

Nicht jedes Entwicklungs- oder DevOps-Team muss eigene Pipelines bauen und pflegen. Ein gemeinsamer CI/CD-Katalog ist eine empfehlenswerte Einrichtung. Ein Beispiel für solch einen Reusable Workflow ist der GitLab CI/CD Components Catalog [36]. In der Praxis ist es vorteilhaft, wenn alle Mitarbeiterinnen und Mitarbeiter im Team Pipeline-Probleme schnell beheben können, denn beispielsweise darauf warten zu müssen, bis jemand aus dem Urlaub zurückkehrt, ist sehr ineffizient. Beim Erstellen einer Pipeline sollten Entwicklerinnen und Entwickler deren Architektur entsprechend dokumentieren, wozu sich unter anderem Mermaid-Charts in Markdown anbieten. Scripts und Befehle sollten sich an bewährten Programmierstilen orientieren: lesbare Fehlermeldungen vorsehen, Stacktraces vermeiden und Dokumentationslinks mit weiterführender Information anlegen. So können alle im Team asynchron an der Fehlerbehebung arbeiten oder Vorschläge für effizientere Pipelines einbringen.

Ebenso wichtig ist es, Pipeline-Observability-Daten nicht im SRE-Dashboard zu verstecken. Insbesondere die Integration in Merge-Request-Widgets und Direktlinks in Kommentaren helfen bei einer schnelleren Analyse.

Quo vadis DevOps-Effizienz?

Infrastruktur- und Security-Observability helfen bei der Erkennung von Problemen in CI/CD-Pipelines – seien es mangelnde Ressourcen, Sicherheitslücken oder blockierende Prozesse. Zusätzliche Einblicke eröffnen Tracing und CI-Visibility. Observability-Daten machen auch bislang noch unbekannte Probleme sichtbar und tragen zu Ressourceneinsparung und Kostenoptimierung bei. Das Beispiel KI zeigt, dass Innovationen in diesen Bereichen schnell voranschreiten.

(map [37])

URL dieses Artikels:
https://www.heise.de/-9665698

Links in diesem Artikel:
[1] https://go.gitlab.com/cIwZfg
[2] https://docs.gitlab.com/ee/ci/yaml/#needs
[3] https://www.heise.de/hintergrund/Modernes-Monitoring-Observability-als-Denkweise-9324670.html
[4] https://github.com/mvisonneau/gitlab-ci-pipelines-exporter
[5] https://www.heise.de/hintergrund/Modernes-Monitoring-Observability-als-Denkweise-9324670.html
[6] https://www.mastering-obs.de/index.php
[7] https://www.mastering-obs.de/tickets.php
[8] https://www.mastering-obs.de/
[9] https://www.linkedin.com/events/7176578490597543936/about/
[10] https://www.linkedin.com/search/results/content/?keywords=%23masteringobs
[11] https://github.com/agardnerIT/tracepusher/tree/main/samples/gitlab
[12] https://go.gitlab.com/TBJjtL
[13] https://go.gitlab.com/FzJH1C
[14] https://app.datadoghq.eu/organization-settings/api-keys
[15] https://docs.gitlab.com/ee/integration/datadog.html
[16] https://github.com/honeycombio/buildevents/issues/125
[17] https://github.com/newrelic-experimental/gitlab
[18] https://circleci.com/docs/workflows/#branch-level-job-execution
[19] https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet
[20] https://docs.gitlab.com/ee/ci/jobs/job_control.html
[21] https://docs.gitlab.com/ee/ci/caching/
[22] https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html#optimize-docker-images
[23] https://docs.gitlab.com/ee/user/project/repository/monorepos/index.html#shallow-cloning
[24] https://docs.gitlab.com/ee/ci/yaml/#tags
[25] https://docs.gitlab.com/runner/executors/kubernetes/index.html
[26] https://github.com/sustainable-computing-io/kepler
[27] https://docs.gitlab.com/runner/configuration/autoscale.html
[28] https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners
[29] https://www.youtube.com/watch?v=2R42jW98MXg
[30] https://www.heise.de/hintergrund/Buchbesprechung-Hacking-Kubernetes-6662043.html
[31] https://about.gitlab.com/blog/2022/02/17/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them/
[32] https://github.com/matthisholleville/cigpt
[33] https://github.com/k8sgpt-ai/k8sgpt
[34] https://opentelemetry.io/docs/collector/transforming-telemetry/
[35] https://docs.gitlab.com/ee/user/application_security/sast/
[36] https://docs.gitlab.com/ee/ci/components/
[37] mailto:map@ix.de

Copyright © 2024 Heise Medien