Blog

4 praktische Tipps für ein schlankes und aufgeräumtes Artifactory

APR 19, 2023

Die Verwaltung eurer Artefakte ist keine besonders spannende, aber eine entscheidende Aufgabe. Das Ops-Team installiert und betreibt Artifactory, doch weil es nicht besonders attraktiv ist, nutzen die Dev-Teams es nicht umfassend.

Sofus Albertsen

Sofus is a Continuous Delivery Trainer and Consultant in Copenhagen. Before joining Eficode Praqma he was assistant professor on an Applied Science Bachelor program. He flies kites and in the summer he escapes the modern world by spending two weeks in a beach hut without electricity or network coverage.

Lasst uns das ändern.

In diesem Beitrag erfahrt ihr praktische Tipps und Tricks, wie ihr euer Artifactory organisiert und aufräumt, damit es nicht zu einem überladenen, unüberschaubaren Datenhaufen wird.

Am Anfang läuft alles gut …

Herzlichen Glückwunsch, ihr habt euer Artifactory installiert und nutzt es nun. Es ist neu, glänzend und noch überschaubar groß. Jetzt ist es an der Zeit, alle Teams an Bord zu holen, damit sie das Tool optimal nutzen können.

Spulen wir ein Jahr oder länger nach der ersten Installation vor: Euer Artifactory wächst exponentiell, weil alle Teams sämtliche Artefakte aus allen CI-Builds dort speichern. Und wer räumt auf? Die Antwort lautet: niemand. 

Die Ops-Teams wissen nicht, was in Artifactory gespeichert ist. Und da die Entwickler nicht für die Erweiterung des Speichers verantwortlich sind, betrifft sie das Durcheinander nicht.

Um das Ausmaß des Problems zu verdeutlichen, machen wir eine einfache Rechnung: 

Drei Teams mit je 8 Personen committen zweimal täglich und erzeugen pro Commit 100 MB an Artefakten – an 200 Tagen im Jahr. Das ergibt fast ein Terabyte an Artefakten pro Jahr, von denen die meisten nie für Kunden veröffentlicht werden. 

Und das gilt für ein kleines Team. Stellt euch vor, welche Dimensionen das in größeren Projekten annimmt. 

Wenn ihr zu lange wartet, Regeln und Richtlinien einzuführen, wird die Situation praktisch unbeherrschbar. Mit der Zeit wird euer Artifactory-Server überladen und ist aus Ops-Sicht bei Backups und Wartung nur noch schwer zu handhaben. 

Was könnt ihr also dagegen tun? In den nächsten Abschnitten findet ihr meine Empfehlungen, wie ihr aus diesem Chaos herauskommt.

1. Definiert Reifegrade für eure Pipeline und Repositories

JFrog beschreibt Best Practices, wie ihr den Reifegrad eurer Artefakte kennzeichnen könnt: durch die Promotion von einem Repository in ein anderes.

maturity

Quelle: JFrog

Ich empfehle euch, diesem Ansatz zu folgen. So stellt ihr sicher, dass ihr das Tool so nutzt, wie es von seinen Entwicklern vorgesehen ist. Dadurch erlebt ihr keine unangenehmen Überraschungen, wenn sich etwas ändert, das ihr auf eine individuelle Weise verwendet.

Wie viele Reifegradstufen ihr braucht, hängt von euren Anforderungen ab. Überlegt aber, wann ein Artefakt von einem Team an ein anderes übergeben wird oder wann eine wichtige Entscheidung für seine Veröffentlichung getroffen werden muss. Dann wird klarer, welche Reifegradstufen ihr benötigt.

Ein Beispiel könnte so aussehen:

Repository

maturity

/type

Example nameRetention period*Comment
sandboxgradle-sandbox-local7 daysThis is a catch-all repo where all, including individual, developers can upload artifacts. No guarantees are made here about quality.
devgradle-dev-local30 daysThe landing place for when the CI system made the artifacts. Further testing is down the pipeline.
qagradle-qa-local60 daysArtifacts stay here when they undergo test. They are on a path to promotion to release, or to be dumped by a quality gate and replaced by a newer version.
releasegradle-release-localneverThis is what is released to the public, and should therefore never be deleted automatically.

Repository

Reifegrad

/Typ

* Aufbewahrungsfristen sollten anhand der Eigenschaften „Zeitpunkt des Uploads“ und „Zeitpunkt der letzten Nutzung“ berechnet werden. Artefakte sollten erst gelöscht werden, wenn beide Fristen abgelaufen sind.

Eine einfachere Alternative

Sind mehrere Repositories für euch vielleicht zu aufwendig? Dann könnt ihr einfache Regeln mit Eigenschaften in Betracht ziehen, die das Verhalten definieren, zum Beispiel cleanup=skip oder released=true. 

Beachtet jedoch, dass es mit der Zeit aufwendig wird, diese einfache Implementierung zu einer ausgereifteren weiterzuentwickeln. Ich empfehle euch daher dringend, Repositories für Reifegrade zu verwenden – und zunächst vielleicht nur mit einem oder zwei zu beginnen.

properties

Das sind die Grundlagen, die ihr in eurem Artifactory schaffen müsst, um anschließend Regeln für die Bereinigung von Artefakten erstellen zu können.

2. Zu bereinigende Artefakte finden

Schaut zuerst in die Speicherübersicht unter dem Tab für Administration und Monitoring. Dort seht ihr sofort, welche Repositories den meisten Speicher belegen.

repos

Damit habt ihr einen groben Überblick darüber, wer das System am stärksten nutzt.

So bekommt ihr eine Vorstellung davon, worauf ihr euch konzentrieren solltet, wenn ihr Repository für Repository vorgeht.

Wenn ihr eure Repositories gerade erst einrichtet, umso besser: Tut euch selbst einen Gefallen und wendet diese „Regeln“ in einem Schritt auf alle Repositories an.

Jetzt verwenden wir die Artifactory Query Language (AQL), um nach den konkreten Artefakten zu suchen, die gelöscht werden müssen. AQL ist eine leistungsstarke Sprache, mit der ihr anhand eurer Abfragen Artefakte und Builds finden könnt.

Über AQL könnt ihr praktisch alles finden. Es dauert etwas, sich an das Modell zu gewöhnen, aber unten findet ihr eine Übersicht des Datenmodells:

aql

Quelle: JFrog

Hier ein Beispiel dafür, wie ihr alle Artefakte findet, die gegen unsere Regel für die Sandbox-Repositories verstoßen:

Weitere Beispiele findet ihr in unserem Artifactory-Training-Repository.

Ihr könnt AQL auf viele verschiedene Arten ausführen. Am einfachsten geht es jedoch mit curl und eurer Authentifizierung sowie der Artifactory-URL in Umgebungsvariablen:

curl -i -X POST -H "${AUTH_HEADER}"  -H "Content-Type:text/plain" "${ARTIFACTORY_URL}/api/search/aql" -T payload.aql

Die Antwort würde folgendermaßen aussehen:

Mit der Methode „.include()“ am Ende eurer AQL könnt ihr die Informationsmenge begrenzen, die ihr zu jedem Artefakt erhaltet.

Über die CLI könnt ihr ebenfalls AQL-Abfragen ausführen, müsst sie dann aber in ein filespec-Format einbetten, was ich, gelinde gesagt, ziemlich unintuitiv finde. Die CLI erlaubt es euch nicht, den „include“-Teil eurer Abfrage anzugeben. Das schränkt eure Möglichkeiten bei Suche und Filterung ein.

Nachdem das eingerichtet ist, schauen wir uns an, wie wir die gerade gefundenen Artefakte löschen.

3. Nicht verwendete Artefakte löschen

Es gibt eine Vielzahl von Tools, die euch beim Bereinigen eurer Artefakte in Artifactory helfen.

Dass es so viele verschiedene Möglichkeiten gibt, sagt mir zwei Dinge:

  • Das hätte von Anfang an im Kernprodukt definiert sein sollen, da 100 % der Nutzerbasis es auf die eine oder andere Weise benötigt.

  • Das Löschen von Artefakten ist eine heikle Angelegenheit, und die Anforderungen daran, was gelöscht werden soll und was nicht, sind unterschiedlich.

Ich werde euch keine vollständige Liste möglicher Tools geben, sondern zwei Ansätze hervorheben:

Mein eigenes Python-Skript

Auf die Gefahr hin, den XKCD-Comic über konkurrierende Standards Wirklichkeit werden zu lassen: Ich brauchte eine Möglichkeit, eine AQL-Abfrage zu erstellen und sie einfach sowohl für die Suche als auch für das Löschen zu verwenden. Da alle verfügbaren Tools entweder filespec oder eine selbst entwickelte beziehungsweise eingeschränkte Abfragemethode nutzten, habe ich beschlossen, es selbst zu skripten.

Bei dieser Methode gebt ihr dieselbe AQL-Datei an, die ihr auch für die Suche verwendet. Statt die Artefakte nur zu suchen und auszugeben, könnt ihr sie auch löschen.

Ihr könnt es entweder als eigenständiges Python-Skript oder als Docker-Container ausführen.

Das Repository mit dem Python-Skript und der Dokumentation findet ihr auf dieser Seite

Artifactory-Cleanup-Anwendung

Eine Alternative zu meinem oben genannten Skript, die ich ebenfalls hervorheben möchte, ist die Artifactory-Cleanup-Anwendung von crazy-max. (Hinweis: Ich kenne den Autor nicht und kann daher nicht für die Sicherheitsqualität des Quellcodes bürgen.)

Der Vorteil: Ihr müsst AQL nicht kennen und habt die gängigsten Einstellungen in der YAML-Konfiguration zur Verfügung.

Jetzt müsst ihr dies nur noch regelmäßig ausführen – entweder als Build-Job in eurem CI-System oder als Cron-Job auf einem Server. Das kann sogar der Artifactory-Server selbst sein. So wird euer Artifactory automatisch und regelmäßig bereinigt.

Eine letzte Möglichkeit zur Wiederherstellung schaffen

Nachdem alle Artefakte gelöscht wurden, steht eurem Artifactory eine deutlich schlankere Zukunft bevor. Doch was ist, wenn ihr etwas gelöscht habt, das für immer hätte behalten werden sollen?

Im Wesentlichen solltet ihr sicherstellen, dass ihr den Papierkorb aktiviert habt (standardmäßig aktiviert) und die Aufbewahrungsdauer auf einen angemessenen Zeitraum festlegt.

trash

Diese Einstellung findet ihr als Administrator im Tab „Artifactory General Settings“.

So könnt ihr Artefakte innerhalb des von euch festgelegten Zeitraums langsam und manuell wiederherstellen.

Falls eure Bereinigung des Papierkorbs etwas zu wild wird, hilft euch möglicherweise dieser Knowledge-Base-Artikel, eure Artefakte von einem bestimmten Zeitpunkt wiederherzustellen, statt sie einzeln zurückzuholen.

4. Mit der Projects-Funktion teilen und beherrschen

Auch wenn ihr all das oben Genannte umgesetzt habt, kann es sein, dass ein Team oder Bereich eurer Organisation mehr Speicherplatz benötigt als der Rest. Natürlich löschen sie Dateien gemäß den Regeln für den Bereinigungsprozess. Aber was, wenn sie Artefakte im Gigabyte- statt im Megabyte-Bereich erstellen? 

Dann geht es nicht nur um Bereinigung. Möglicherweise müsst ihr den Speicherplatz, den sie beanspruchen können, auch auf eine feste Größe begrenzen.

Dafür könnt ihr die relativ neue Funktion „Projects“ nutzen, die mit Artifactory 7.31.10 eingeführt wurde. Mit Projects könnt ihr den Server in „Bereiche“ unterteilen, die eure Projekt- oder Teamstruktur abbilden.

Wir haben sie bei einigen Kunden mit unterschiedlichen Ergebnissen eingesetzt. Die Funktion ist noch relativ neu und nicht vollständig ausgereift – insbesondere, wenn ihr sie als Alternative zu Permission Targets nutzen möchtet und Teams sich selbst verwalten.

Erschwerend kommt hinzu, dass die Anzahl möglicher Projekte stark von der erworbenen Lizenz abhängt. Daher könnt ihr euch möglicherweise nicht für alle Teams und Projekte auf diese Funktion verlassen.

Fazit

Artifact Management ist wichtig, muss streng geregelt sein, um richtig zu funktionieren, und ist ziemlich langweilig. Wenn ihr jedoch die obigen Tipps befolgt, erreicht ihr einen Zustand, in dem die meisten Aufgaben automatisiert sind und auf Regelwerken basieren, die allgemein genug sind, um für alle Teams zu passen – unabhängig von ihrem Reifegrad und ihren Anforderungen.

  • DevOps
  • CI/CD
  • System of Work

Subscribe to our newsletter