Springe zum Hauptinhalt

OCCTET-Ergebnis D4.1

Referenzinstallation

Das OCCTET-Ergebnis D4.1 betreibt das Open-Source-Toolkit als containerisierten Cloud-Dienst, validiert am Portfolio der Eclipse Foundation, an KMU-Produkten und an populären Open-Source-Projekten. Nutzen Sie die gehostete Instanz oder bauen Sie die Installation mit dem öffentlichen Deployment-Material nach.

Auf dieser Seite

Das OCCTET-Toolkit, sofort einsatzbereit

Das Ergebnis D4.1 macht aus den Werkzeugen des OCCTET-Toolkits eine Referenzinstallation: einen containerisierten Cloud-Dienst, den die Eclipse Foundation in der EU betreibt und den KMU und Open-Source-Projekte nutzen, ohne etwas zu installieren.

Jede Komponente ist Open Source, und das gesamte Deployment-Material ist öffentlich. So kann jede Organisation die Installation auch nachbauen, auf ihrer eigenen Infrastruktur, und ihren Quellcode im Haus behalten.

An realen Arbeitslasten validiert

Die Installation wurde im Maßstab einer Open-Source-Stiftung, an KMU-Produkten und an weit verbreiteten Open-Source-Projekten getestet.

Zu den Ergebnissen

Ein Blick in die Referenzinstallation

Vier Dienste laufen auf einem verwalteten Kubernetes-Cluster in der EU. ORT Server und der Curator prüfen Schwachstellen anhand zweier offener Datenquellen: OSV und VulnerableCode, Teil der föderierten Plattform für Software-Metadaten des Projekts.

ORT Server

Analysiert Repositories mit einer Pipeline von Jobs, bietet eine Web-Oberfläche, eine REST-API und eine CLI und erzeugt SBOMs in SPDX und CycloneDX.

OCCTET Curator

Importiert, kuratiert und bewertet SBOMs. Seine KI-gestützten Dienste nutzen ein lokales Sprachmodell, sodass keine Daten die Installation verlassen.

VulnerableCode

Eine offene Schwachstellendatenbank, die Advisories aus vielen Quellen zusammenführt und sie nach Package URL bereitstellt.

Keycloak

Single Sign-on für ORT Server und den Curator, mit dem OCCTET-Theme.

Gestaltungsprinzipien

  • Ein Einstiegspunkt: Ein einziger Load Balancer bedient alle Hostnamen über HTTPS.
  • Ein Namespace pro Dienst: Jeder Dienst hat seine eigene Datenbank und seinen eigenen Lebenszyklus.
  • Helm überall: Jede Komponente wird als eigenes Helm-Release installiert und aktualisiert.
  • Gemeinsame Identität: Ein Konto öffnet ORT Server und den Curator.

Die gehostete Instanz nutzen

Organisationen, die die Installation nicht selbst betreiben möchten, können die OCCTET-Instanz nutzen. Nach einer Zugangsanfrage melden sich Nutzer einmal mit einer E-Mail-Adresse oder einem GitHub-Konto an, und dasselbe Konto öffnet ORT Server und den OCCTET Curator.

Jedes Konto kann die Ergebnisse der öffentlichen Open-Source-Organisationen von ORT Server lesen: Eclipse projects, Eclipse Research Labs, Renowned FOSS projects und FOSS Validation. Jedes KMU arbeitet in seiner eigenen Organisation, die nur ihre Mitglieder sehen. Die API und die CLI von ORT Server sowie Tokens für CI-Pipelines decken die automatisierte Nutzung ab.

Bereit zum Ausprobieren?

Der Einstiegsleitfaden erklärt, was Sie vorbereiten sollten und wie Sie Zugang anfragen.

Erste Schritte

Selbst installieren

Das gesamte Deployment-Material ist öffentlich, in der GitLab-Gruppe occtet-eu/reference-installation der Eclipse Foundation, unter Open-Source-Lizenzen. Ein einziges Repository, occtet-helm-chart, installiert die gesamte Plattform, mit einem Helm-Release pro Komponente.

  1. Einen Kubernetes-Cluster vorbereiten

    Ein verwalteter Kubernetes-Cluster mit Block Storage, einem Load Balancer und vier DNS-Hostnamen. Die Dokumentation nennt die Dimensionierung der Referenzinstanz.

  2. Ingress-Controller und Zertifikate installieren

    Der Einstiegspunkt terminiert TLS für jeden Dienst, mit Zertifikaten von Let’s Encrypt.

  3. Single Sign-on installieren

    Keycloak, mit dem OCCTET-Theme und dem von den Werkzeugen gemeinsam genutzten Realm.

  4. Die Werkzeuge installieren

    ORT Server, den OCCTET Curator und VulnerableCode, jeweils in einem eigenen Namespace.

  5. Veröffentlichen und prüfen

    Die Dienste über den Einstiegspunkt veröffentlichen, sich anmelden und eine erste Analyse starten.

Repositories nach Komponente Das Deployment-Material von OCCTET im GitLab der Eclipse Foundation und die Upstream-Projekte, auf denen es aufbaut.
KomponenteOCCTET-DeploymentUpstream-Projekt
ORT Serverocctet-ort-server-helm-chartDokumentation · Helm-Charts
Konfiguration von ORT Serverocctet-ort-server-configBeispielkonfiguration
OCCTET Curatorocctet-curator-helm-chartBenutzerhandbuch · Helm-Chart
VulnerableCodeocctet-vulnerablecode-helm-chartDokumentation
Single Sign-onocctet-keycloak · occtet-keycloak-themeDokumentation von Keycloak · Helm-Charts
Portfolio-Kampagnenocctet-eclipse-projectsAPI von ORT Server
Statistiken und Dashboardsocctet-stats–

Lokale Entwicklung

Die gesamte Plattform läuft auch auf einem Arbeitsplatzrechner, auf einem lokalen minikube-Cluster. Damit können Sie die Installation ausprobieren, bevor Sie sie auf einem Cluster nachbauen, oder die Änderung eines Charts, seiner Values oder eines Secret-Skripts testen, bevor sie zusammengeführt und von der CI ausgerollt wird. Sie verwendet dieselben Charts, Values und Secret-Skripte wie die Produktion; nur einige Entwicklungseinstellungen weichen ab.

  1. Die Repositories nebeneinander klonen

    occtet-helm-chart, occtet-keycloak, occtet-ort-server-helm-chart, occtet-curator-helm-chart und occtet-vulnerablecode-helm-chart.

  2. Die Plattform installieren

    make dev-up in occtet-helm-chart erstellt den Cluster, installiert die Secrets und alle Releases und gibt dann die Zeile aus, die in /etc/hosts einzutragen ist.

    Unter Linux zuerst die inotify-Grenzwerte des Rechners erhöhen (fs.inotify.max_user_instances=1024): Der minikube-Node teilt sie.

  3. Der lokalen Zertifizierungsstelle vertrauen

    make dev-ca-install importiert sie in Chrome, Chromium und Firefox. Sie kann nur Namen unter occtet.local signieren.

  4. Anmelden

    make dev-accounts gibt die Passwörter der Entwicklungskonten aus. Öffnen Sie dann https://ort-server.occtet.local und https://curator.occtet.local.

Was sich von der Referenzinstanz unterscheidet
ReferenzinstanzLokale Installation
ClusterVerwaltetes Kubernetesminikube mit dem Docker-Treiber: 8 CPUs, 12 GB Arbeitsspeicher, 60 GB Festplatte
Hostnamen*.occtet.eu, öffentliche DNS-Einträge*.occtet.local, in /etc/hosts
ZertifikateLet’s EncryptEine selbst signierte Zertifizierungsstelle, beschränkt auf occtet.local
RessourcenDimensionierung für die ProduktionKleinere Anforderungen; kein lokales KI-Modell für den Curator; weniger VulnerableCode-Worker
Single Sign-onVon einem Administrator konfigurierter RealmBeim Start importierter Entwicklungs-Realm, mit einem Administratorkonto
Chart-RepositoriesAls Git-Submodule fixiertLokale Klone: Eine Änderung wird getestet, bevor sie committet wird

Über das Projekt hinaus

Das Projekt endet am 31. Oktober 2026. Die Eclipse Foundation betreibt die Plattform bis Anfang 2027 weiter.

Die Software hängt nicht von dieser Instanz ab. ORT Server wird in Eclipse Apoapsis entwickelt, einem Projekt der Eclipse Foundation, und der OCCTET Curator und VulnerableCode sind Open-Source-Projekte auf GitHub. Jeder kann sie nutzen, zu ihnen beitragen, sie forken und die Installation nachbauen. Das Ergebnis enthält außerdem eine Schätzung der Infrastrukturkosten für ein Jahr und einen Plan zur Betriebsreife für einen voll betriebsfähigen Dienst.

Das vollständige Ergebnis lesen

D4.1 ist ein öffentlicher Demonstrator des Arbeitspakets 4 unter der Leitung von Double Open. Seine Dokumentation ist in Markdown geschrieben und wird zusammen mit dem Deployment-Material gepflegt, unter der Lizenz CC BY 4.0.

Zurück nach oben