Einmal im Jahr stecken wir bei der viadee in Forschermanier die Köpfe zusammen. Völlig frei von Vorgaben widmen wir uns dann Themen, die wir immer schon einmal bearbeiten wollten. So auch am ShipIt Day 2018. Was in diesem Jahr dabei herauskam, kann sich meiner Meinung nach mehr als sehen lassen: unser neues OpenSource Tool Nexus X-Ray.
Wofür ist unser neues OpenSource Tool Nexus X-Ray nützlich?
Wer ein Sonatype Nexus-Repository OSS für sein Entwickler-Team betreibt, kennt das Gefühl: Der Speicherhunger wächst - aber ist das gut so? Falls es einzelne Projekte mit exzessivem Speicherbedarf gäbe, würde man das bemerken? Funktionieren die konfigurierten Bereinigungs-Jobs auch so wie gewünscht?Der Nexus-Server ist Drehscheibe für Komponenten und Fertig-Erzeugnisse der Software-Entwicklung. Klassischerweise wird er einerseits von einem Continuous Integration System wie beispielsweise Jenkins mit erstellten Java-Bibliotheken befüllt, andererseits fungiert er als Proxy-Server für frei verfügbare Bibliotheken, um diese den Entwickler-Teams schlicht schneller zur Verfügung stellen zu können.
Unfertige Komponenten (im Allgemeinen JARs) in SNAPSHOT-Versionen werden in unserer Entwicklungsabteilung sehr häufig gebaut - oft nach jeder Änderung im Git-Repository oder einem 10-Minuten-Takt. Das schafft schnelle Feedback-Zyklen und stellt auf technischem Niveau sicher, dass Team-Mitglieder nicht aneinander vorbei entwickeln. Die zunehmende Nutzung von Build-Pipelines und Build-Triggern lässt dann als Kaskade weitere Artefakte entstehen und prüfen, welche potenziell von Änderungen in einer Komponente betroffen sein könnten.
Hinzu kommen in letzter Zeit Docker-basierte Workflows, die nicht mehr JAR-Files, sondern installationsfertige Container produzieren und im Nexus-Server ablegen. Diese sind nicht nur um ein bis zwei Zehnerpotenzen größer als einzelne JARs, sondern aus Sicht des Nexus auch schwerer zuzuordnen: Docker verwendet erfreulicherweise Teile der Container mehrfach.
Das Administrations-Interface des Nexus-Servers bietet bei der Analyse der Datenvolumina aber nahezu keine Hilfe an: Eine Gesamtgröße pro Repository ist zwar zu erkennen und eine Ansicht auf einzelne Artefakte ist möglich. Was fehlt, ist eine Übersicht auf einem mittleren Aggregationsniveau (idealerweise pro Projekt) im zeitlichen Zusammenhang. Erst das ermöglicht eine Administration und Planung der Datenvolumina und erlaubt es, einzelne Projektkonfigurationen zu hinterfragen und verteilte Teams bei der Nutzung der Infrastruktur zu beraten.
Erschwert wird dies wiederum durch die Datenhaltung des Nexus-Servers. Einen Teil seiner Daten hält er in einer Datenbank und einen anderen Teil in Textdateien, die in sehr vielen Ordnern neben den verwalteten Artefakten liegen. Besonders der Zusammenhang „Wer nutzt welche Docker-Dateien?" ist ohne Zugriff auf die Datenbank nicht einfach nachzuvollziehen.
Wie funktioniert unser neues OpenSource Tool Nexus X-Ray?
Um hiermit umgehen zu können, haben wir uns einer Heuristik bedient und alle Datenvolumina aus der Docker-Welt jeweils einem Docker.Name zeitlich zugeordnet. Ein kleines Java-Programm läuft durch das angegebene Dateisystem und trägt alles zusammen. Trittbrettfahrer, die Docker Images bzw. möglichst viele Schichten wiederverwenden, werden auf diese Weise sozusagen belohnt, denn das Datenvolumen wird nur dem ursprünglichen Ersteller des Images zugeschrieben.
In der Java-Welt lassen sich die Maven-Eigenschaften Maven.Group und Maven.Artifact ähnlich nutzen wie der Docker.Name: Über sie ist im Allgemeinen eine Zuordnung zu Projekten und Personen in einem Unternehmen möglich. Auf dieser Ebene lassen sich schnell aussagekräftige Auswertungen erstellen. Damit hier für die Datenanalyse möglichst alle Türen offen bleiben, erstellen wir eine CSV-Datei, welche alle o. g. Daten zusammenträgt.
Als Startpunkt zur Analyse des eigenen Bestands liefern wir ein R-Skript mit, dass die Datenvolumina im Zeitablauf zeigt, eine Tag-Cloud aus Maven-Groups und Docker-Names erstellt, aber auch einfache Balkengrafiken oder Histogramme.
Interessant am Rande: In unserem Datenbestand hat gerade ein großes Java-Projekt den Gesamtsieg für das größte Datenvolumen im Nexus erreicht - noch knapp vor einer Docker-Pipeline.
Da wir bestimmt nicht die einzigen sind, die sich solche Fragen stellen, veröffentlichen wir unser am viadee ShipIt Day 2018 entstandenes Werkzeug Nexus X-Ray gerne unter einer Open Source-Lizenz und freuen uns auf Feedback, Erkenntnisse und Weiterentwicklungen.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
