<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1127487224079104&amp;ev=PageView&amp;noscript=1 https://www.facebook.com/tr?id=1127487224079104&amp;ev=PageView&amp;noscript=1 ">

Sonatype veröffentlicht den "2018 State of the Software Supply Chain Report" 2018 Pressemitteilung

travel audience und Nexus

Repository-Verwaltung in der Google Cloud
travel audience

travel audience


travel audience – Sonatype Nexus und die Google-Cloud-Plattform
Foto: j zamora auf Unsplash.

Andre Rocha Ferreira beschreibt, wie er und sein DevOps-Team bei travel audience mithilfe des Nexus Repository Managers eine DevOps-Pipeline-Lösung auf der Google-Cloud-Plattform entwickelt haben.

Die Herausforderung

Bei travel audience (TA) entwickeln, implementieren, betreiben und pflegen wir eine ganze Reihe von Software-Elementen. Diese Software-Elemente haben verschiedene Formen und verwenden unterschiedliche Technologien sowie Implementierungsstrategien, je nachdem, welche Ziele sie verfolgen.travel audience - Andre Rocha Ferreira.jpg Wir haben zum Beispiel Apps, die Millionen Nachrichten pro Sekunde aufnehmen, verarbeiten und generieren und bei denen Minimalismus der Schlüssel für geringere Latenzzeiten, eine hohe Durchsatzquote und eine hohe Verfügbarkeit ist.

Diese Apps sind in kompilierten Sprachen wie Go programmiert und werden in der Regel als Container bereitgestellt, damit die Anzahl der benötigten Instanzen zu einem bestimmten Zeitpunkt (z. B. je nach Benutzernachfrage) leichter (horizontal) skaliert werden kann. Auf der anderen Seite haben wir aber auch Apps, die täglich Terabyte an Daten verarbeiten – manchmal in Echtzeit, manchmal aber auch innerhalb weniger Stunden oder Tage. Diese Apps werden in der Regel als Python-, Java- oder Scala-Archive gepackt, die als Jobs in einer Batch- und/oder Stream-Verarbeitungs-Engine eingeplant werden.

Und die meisten unserer Workloads laufen auf der Google-Cloud-Plattform (GCP) (um ein bisschen mehr Aufschluss über unsere Plattform zu geben).

  • Container werden mit Kubernetes Engine (GKE), Googles vollständig verwaltetem Kubernetes-Service, orchestriert.
  • Batch- und Streaming-Pipelines werden von Dataproc und Dataflow bereitgestellt.
  • Daten werden in Cloud Storage, Cloud SQL, BigTable und BigQuery gespeichert.
  • etc.
Angesichts der Heterogenität unserer Apps und Bereitstellungsumgebungen erkannten wir schnell, dass wir eine Lösung brauchen, um unsere Artefakte zu speichern, zu katalogisieren und zu verteilen, damit sie ineinander greifend die zugrundeliegende Struktur für travel audience bilden können.
 
„Wir testeten nur Sonatype Nexus und JFrog Artifactory. Wir haben uns für Nexus entschieden, da die OSS-Version für den Großteil unserer Anforderungen geeignet zu sein schien.“

Andre Rocha Ferreira, DevOps Engineer, travel audience

Die Umsetzung

Zu diesem Zeitpunkt hatte unser Ops-Team bereits bestimmte Einschränkungen entdeckt, für die wir Lösungen finden mussten:

  • Das Zwischenspeichern von Docker-Containern in Nexus ist eine komplexe Angelegenheit, daher beschlossen wir, es vorerst zu lassen.
  • Es gab keine Integration mit Google Cloud Identity Access Management (Cloud IAM), weshalb wir solch eine Integration entwickeln und implementieren mussten.
  • Es gab keine Integration mit Google Cloud Storage für Back-up-Speicherung und Wiederherstellung, weshalb wir solch eine Integration entwickeln und implementieren mussten.
  • Kubernetes, die Lösung zur Orchestrierung der Container bei travel audience, wird nicht unterstützt, also mussten wir uns auch darum kümmern.

Nachdem wir gründlich über den Designprozess nachgedacht hatten, kamen wir zu folgender Lösung:

travel audience – Lösungsarchitektur für Sonatype Nexus und die Google-Cloud-Plattform

  1. Entwickler-Tools (wie z. B. Maven, Docker und GKE) erreichen Nexus über eine Google Cloud Load Balancer (GCLB)-Instanz.

  2. Die GCLB-Instanz leitet eingehenden Traffic zu einer Instanz von nexus-proxy. weiter

  3. nexus-proxy prüft die Anfrage-Header mittels der Cloud IAM-APIs auf die Identität des Benutzers und anschließend auf die GCP-Organisationsmitgliedschaft.

  4. Wenn der Benutzer autorisiert ist, leitet nexus-proxy den eingehenden Traffic an Nexus weiter.

  5. nexus-backup lädt in regelmäßigen Abständen Back-ups in Cloud Storage.

  6. Nexus legt Pakete von Maven Central und PyPI im Zwischenspeicher ab.

Nexus-Authentifizierung mit Cloud IAM

Wir wussten vorher, dass wir Nexus mit Cloud IAM authentifizieren müssen, aber wir wollten diese Authentifizierung optional machen, damit das von uns entwickelte und implementierte Tool auch in anderen einfacheren Szenarien verwendet werden kann – z. B. ohne Cloud IAM.

Für die Bereitstellung haben wir uns um das Design und die Implementierung von nexus-proxy gekümmert.

Interessanterweise haben wir später herausgefunden, dass wir mit dieser Option auch viel leichter andere Probleme lösen konnten, die rein gar nichts mit der Authentifizierung zu tun haben. Beispielsweise kann Nexus das private Docker-Registry nicht mit der gleichen Konfiguration wie die anderen Artefakt-Repositorys freigeben, was die Entscheidung, HTTPS für alles zu verwenden, zunichte gemacht hätte. Es ersetzte auch Nginx als Reverse-Proxy hinter GCLB.

Nexus-Back-up

Nexus kann so konfiguriert werden, dass regelmäßig Back-ups seiner internen Datenbank erstellt werden. Doch dieser Prozess berücksichtigt keine BLOB-Speicher. Darüber hinaus werden die Back-ups nur auf der lokalen Festplatte hinterlegt. Das bedeutet: Ist die Festplatte weg, sind auch die Back-ups verloren.

Aus diesem Grund entwickelten wir ein Tool namens nexus-backup (ein Container aus einer Reihe von Skripten), um den Back-up-Prozess durchzuführen und das Ergebnis anschließend in Cloud Storage hochzuladen.

travel audience – Sonatype Nexus auf der Google-Cloud-Plattform

  1. Die Blobstores von Nexus werden auf einer Google Persistent Disk (PD) gespeichert, auf die nexus-backup zugreifen kann.
  2. Eine Datei, die Back-ups auslöst, wird ebenfalls auf derselben PD gespeichert.
  3. Eine Aufgabe, die in Nexus konfiguriert wird, erstellt in regelmäßigen Abständen einen Back-up-Speicherauszug der Nexus-Datenbank auf derselben PD.
  4. Eine weitere Aufgabe, die in Nexus konfiguriert wird, signalisiert, dass ein Back-up stattfindet, indem die Trigger-Datei angestoßen wird.
  5. nexus-backup beobachtet die Trigger-Datei und startet, sobald die Trigger-Datei angestoßen wird, den Blobstore-Back-up-Prozess.
  6. nexus-backup ruft den Speicherauszug der Nexus-Datenbank und die Blobstore-Back-up-Dateien von der PD ab.
  7. nexus-backup lädt das Back-up in einen vorkonfigurierten Cloud-Storage-Bucket.
  8. Ein Wiederherstellungsverfahren kann durch Kopieren eines Back-ups auf eine PD, die an Nexus angehängt ist, durchgeführt werden. Nexus ruft das Back-up ab und stellt es nach dem Neustart automatisch wieder her.

Bemerkenswert ist Folgendes: Wenn eine Lock-Datei länger als 12 Stunden vorhanden ist (was wahrscheinlich auf ein fehlgeschlagenes Back-up hinweist), wird die Lock-Datei entfernt, damit nachfolgende Back-ups durchgeführt werden können.

Lifecycle Management mit Nexus

Wir vertrauen auf Kubernetes (GKE), um den Lebenszyklus unserer Nexus-Konfiguration bereitzustellen und zu verwalten. Wir haben detaillierte Anweisungen zu unserem Ansatz als Open-Source-Angebot bereitgestellt, darunter die Notfallwiederherstellung und die Vorgehensweise unserer Entwickler.

Außerdem arbeiten wir derzeit an einem Helm-Chart dafür, das bald zur Verfügung stehen sollte.

Diese Story wurde uns zur Verfügung gestellt vom DevOps-Team bei travel audience.

travel audience - location banner v02.jpg

 
   
Erfolgsstorys unserer Kunden