Als Observability-Unternehmen erstellt und verwaltet New Relic mehrere sprach- und technologiespezifische Agents, um Telemetriedaten aus den Umgebungen unserer Kund:innen zu sammeln. Wenn die Agent-Teams neue Updates manuell veröffentlichen, führen sie zahlreiche Überprüfungen durch, um sicherzustellen, dass der Prozess keine durch menschliche Fehler verursachten Regressionen mit sich bringt. Um den Zeitaufwand für die Bereitstellung einer neuen Version zu reduzieren, automatisierte das Kubernetes-Agent-Team den gesamten Release-Prozess für Software-Agents. Wiederverwendbare GitHub-Aktionsworkflows dienen zur Nachverfolgung gefährdeter Abhängigkeiten, schreiben die Dokumentation und stellen die umfassende Synchronisierung mit Partnern wie Amazon Elastic Kubernetes Service (Amazon EKS) sicher. Bisher erfolgte die Veröffentlichung von Updates für unsere Kubernetes-Integration manuell und dauerte bis zu zwei Wochen; heute ist der automatisierte Prozess jede Woche nach einer Stunde erledigt.
Verkürzung der Reaktionszeit bei Sicherheitsvorfällen
Eine unserer Herausforderungen war die Handhabung von Sicherheitslücken: Wir reagierten auf eine Schwachstelle nur, wenn sich Kund:innen damit an den Global Technical Support (GTS) wandten. Das führte sowohl bei den Kund:innen zu Frustration über unsere Integrationen als auch bei den Entwickler:innen zu Stress, weil wir geplante Arbeiten zugunsten des Patchens unserer Software stoppen mussten.
Im Rahmen unserer Continuous-Integration(CI)-Pipeline haben wir Codescan-Tools aktiviert, die uns über die neuesten Schwachstellen in unserer Codebasis informieren. CodeQL sucht nach Sicherheitslücken in unserer Codebasis, und Trivy sorgt dafür, dass unsere Docker-Images keine Schwachstellen enthalten, die aus dem Basis-Image und den darin enthaltenen Bibliotheken eingeschleust wurden.
Einer unserer häufigsten Anwendungsfälle ist die Erkennung von Schwachstellen in unserem Basis-Image (Alpine). Dieser Prozess macht uns auf aktuelle Probleme aufmerksam, die behoben werden müssen. Durch die Kombination von Vulnerability Scanning und automatischem Abhängigkeitsmanagement sind wir in der Lage, Korrekturen automatisch an der Codebasis vorzunehmen, ohne dass menschliches Eingreifen erforderlich ist. Unsere Workflows laufen wöchentlich, d. h. Kund:innen erhalten innerhalb einer Woche nach Verfügbarkeit eines Fixes eine gepatchte Version.
Ein konkretes Beispiel für unsere erhöhte Reaktionszeit: Unser Sicherheits-Dashboard meldete folgende Schwachstellen in alpine:3.18.4 (dem Image, das wir zu diesem Zeitpunkt in der nri-Kubernetes-Integration verwendeten):
Diese Schwachstellen wurden in alpine:3.18.5 (veröffentlicht am 30. November 2023) und alpine:3.19.0 (veröffentlicht am 7. Dezember 2023) behoben. Renovate, unser universelles Abhängigkeitsmanagement-Tool, erstellte Pull-Requests für beide Releases an dem Tag, an dem die Releases veröffentlicht wurden, und sie wurden am 8. Dezember 2023 in unser Release aufgenommen – nur einen Tag nach der Veröffentlichung von alpine:3:19.0.
Alle drei genannten alpine-Images weisen zwei weitere Schwachstellen auf, die im Nachhinein entdeckt wurden:
- CVE-2023-6129 am 9. Januar 2024
- CVE-2023-6237 am 15. Januar 2024
Diese beiden noch ausstehenden Schwachstellen werden derzeit in unserem Sicherheits-Dashboard hervorgehoben.
Sobald ein Fix von Alpine freigegeben wird, können unsere Kund:innen innerhalb einer Woche mit einem korrigierten Release unserer Integrationen rechnen.
Erstklassiger Support für die neueste Kubernetes-Version
Für den Support neuer Versionen von Kubernetes sind Updates an Testtools von Drittanbietern sowie umfassende Konformitätstests notwendig, um sicherzustellen, dass eine neue Kubernetes-Version nicht die Funktion unsere Integrationen beeinträchtigt. Ein häufiges Problem, das wir prüfen müssen, sind Kubernetes-APIs in der Alpha- oder Beta-Version, da es dabei ohne Ankündigung zu Änderungen kommen kann.
Mit unseren vollautomatischen Abhängigkeitsmanagement-Tools haben wir, sobald die Tools vorhanden sind, sofortigen Zugriff darauf. Da unsere Konformitätstests ebenfalls vollständig automatisiert sind, können wir die Validierungszeit verkürzen und liefern so optimalen Kubernetes-Support.
Wenn ein neues Kubernetes-Release verfügbar wird, ist es wichtig, unsere Test-Workflows zu aktualisieren, um die neueste Version zu integrieren. Renovate, unser Abhängigkeitsmanagement-Tool, hat automatisch einen Pull-Request (PR) geöffnet, um Minikube auf die neueste Version zu aktualisieren. Wir verwenden Minikube, um schnell einen Cluster hochzufahren und dann End-to-End-Tests durchzuführen. Anschließend führen wir die gesamten Tests in jeder Kubernetes-Version aus, die wir unterstützen. Sobald dieser Minikube mit der neuesten Kubernetes-Version aktualisiert wurde, aktivieren wir in unserem Test-Framework das Testen für diese Version. Wenn Tests bestätigen, dass die Integration wie erwartet funktioniert, können wir den Support für die neueste Kubernetes-Version öffentlich machen. Aufgrund unserer automatisierten Workflows haben wir unsere Testsuite am selben Tag, an dem minikube das Release ankündigte, auf die neueste Version von Kubernetes aktualisiert. Dadurch konnten wir die Kompatibilität innerhalb eines Tages testen und sieben Tage nach dem Minikube-Release bekannt geben, dass unsere Kubernetes-Integration mit der neuesten Version kompatibel war.
Synchronisieren des neuesten Agent-Release mit AWS-EKS-Anywhere-Add-ons
Wir unterstützen das Amazon-EKS-Anywhere-Partnerprogramm, indem wir den New Relic Kubernetes-Agent als sofort einsatzbereites Add-on für Amazon-EKS-Anywhere-Cluster anbieten. Wir haben einen GitHub-Actions-Workflow entwickelt, um automatisch einen Pull-Request zu öffnen, wenn wir eine neue Version unseres Agent erstellen. Dadurch haben unsere Endbenutzer:innen von Amazon EKS Anywhere stets die neuesten Agent-Releases und wir können sicherstellen, dass New Relic kontinuierlich die neuesten Konformitätstests besteht und ein von Amazon EKS Anywhere validierter Partner bleibt.
Automatisieren von Changelog, Mitteilungen und Dokumentation
Die Erstellung und Aktualisierung der Dokumentation nimmt viel Zeit in Anspruch. Um einen wöchentlichen Release-Rhythmus zu erhalten, mussten wir alle Kommunikationskanäle für alle internen Beteiligten, externen Kund:innen und Partner:innen auf Vordermann bringen. Zur Automatisierung der Kommunikation mit all diesen Stakeholdern haben wir wiederverwendbare Workflows erstellt, die jede Woche ausgeführt werden und Versionshinweise automatisch aktualisieren, Slack-Nachrichten zu den neuesten Versionen in internen New Relic Stakeholder-Kanälen senden und die Entwicklerdokumentation aktualisieren.
Anschließend stellt unser eigener GitHub-Workflow die Dokumentation und Versionshinweise zusammen und sendet Mitteilungen über alle Kanäle. Um besser mit internen Stakeholdern kommunizieren zu können, haben wir unseren eigenen K8s-Agent-Bot erstellt, der mit unserem GitHub-Actions-Workflow verknüpft ist, sodass unsere Kund:innen und Partner:innen automatisch über Release-Updates benachrichtigt werden können.
Fazit
Eine CI-Pipeline bietet mehr Vorteile, als nur den Entwickler:innen die Arbeit zu erleichtern – Kunden:innen erhalten Zugang zu sicherer, gut dokumentierter und modernster Software.
Bei einer effektiven CI-Pipeline geht es um mehr als nur die Automatisierung des Agent-Release-Prozesses. Testabläufe werden verbessert, um sicherzustellen, dass es im Prozess nicht zu Regressionen kommt, Sicherheitslücken werden schnell erkannt und behoben, und die Kommunikation mit allen Beteiligten läuft klar und effektiv ab.
Nächste Schritte
Informieren Sie sich über unsere Open-Source-Integration für Kubernetes und sehen Sie sich unsere Dokumentation an, um auch in Ihren Kubernetes-Clustern für Transparenz zu sorgen!
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.
