Les enseignements de l'analyse de 36 000 projets d'OSS | Communiqué de presse

travel audience et Nexus

Gestion du repository combinée à Google Cloud
travel audience

travel audience


travel audience - Sonatype Nexus et la plateforme Google Cloud
Photographe J. Zamora sur Unsplash.

Andre Rocha Ferreira raconte comment lui et son équipe chez travel audience ont mis au point, à l'aide de Nexus Repository Manager, une solution de pipeline DevOps qui s'ajoute à la plateforme Google Cloud.

Le défi

Chez travel audience (TA), nous assurons la conception, l'implémentation, l'exploitation et la maintenance d'un certain nombre de logiciels. Ces derniers ont différents formats, utilisent des technologies diverses et reposent sur des stratégies de déploiements variées, selon leurs besoins.travel audience - Andre Rocha Ferreira.jpg Par exemple, certaines de nos applications consomment, traitent et génèrent des millions de messages par seconde, alors qu'une latence faible, une cadence élevée et une grande disponibilité ne sont atteignables qu'en faisant preuve de minimalisme.

Ces applications sont développées en langages compilés comme le Go et sont généralement regroupées sous forme de conteneurs afin de faciliter l'évolution (horizontale) du nombre d'instances nécessaires à chaque instant, en fonction, par exemple, de la demande utilisateur. À l'opposé, d'autres applications traitent des téraoctets de données chaque jour, parfois presque en temps réel, parfois en quelques heures ou quelques jours. Ces applications se présentent généralement sous forme d'archives Python, Java ou Scala qui doivent être planifiées en tant que jobs dans un lot ou un moteur de stream processing.

En outre — pour mieux comprendre notre plateforme — la plus grande partie de notre charge s'exécute sur la plateforme Google Cloud (GCP) :

  • Les conteneurs sont orchestrés par Kubernetes Engine (GKE), les services Kubernetes entièrement gérés par Google.
  • Les pipelines de lots ou de flux sont fournis par Dataproc et Dataflow.
  • Les données sont stockées dans Cloud Storage, Cloud SQL, BigTable et BigQuery.
  • Etc.
Étant donnée l'hétérogénéité de nos applications et environnements de déploiement, nous avons rapidement pris conscience que nous devions être capable de stocker, référencer et répartir les artéfacts qui, une fois rassemblés, forment la structure de TA.
 
« Nous avons choisi de tester Sonatype Nexus et JFrog Artifactory. Notre choix s'est porté sur Nexus parce que la version OSS semblait offrir presque tout ce que nous recherchions. »

Andre Rocha Ferreira, ingénieur DevOps, travel audience

Exécution

À ce stade, notre équipe d'exploitation avait déjà identifié certaines limites à repousser :

  • La mise en mémoire tampon des conteneurs Docker dans Nexus est complexe, nous avons donc décidé de la mettre de côté dans un premier temps.
  • L'intégration à Google Cloud Identity Access Management (Cloud IAM) est inexistante, nous devons donc la concevoir et la mettre en œuvre.
  • L'intégration à Google Cloud Storage pour le stockage et la récupération de copies de sauvegarde est inexistante, nous devons donc la concevoir et la mettre en œuvre.
  • Il n’y a pas d'assistance officielle pour Kubernetes, la solution d’orchestration de conteneurs en place à TA. Nous devons donc nous pencher également sur ce sujet.

Après un processus de conception méticuleux, voici ce que nous avons proposé :

travel audience - architecture des solutions pour Sonatype Nexus et la plateforme Google Cloud

  1. Les outils de développement, tels que Maven, Docker et GKE, contactent Nexus via une instance de Google Cloud Load-Balancer (GCLB).

  2. L'instance GCLB oriente les messages entrants vers une instance de nexus-proxy.
  3. nexus-proxy contrôle, dans l'en-tête des demandes, l'identité des utilisateurs et l'appartenance à GCP Organization à l'aide des API Cloud IAM.

  4. Si l'utilisateur dispose des autorisations nécessaires, nexus-proxy envoie les messages entrants à Nexus.
  5. nexus-backup télécharge régulièrement des copies de sauvegardes au Cloud Storage.

  6. Nexus met en mémoire tampon les paquets reçus de Maven Central et PyPI.

Authentification Nexus avec Cloud IAM

Nous savions dès le départ que nous devrions authentifier Nexus via Cloud IAM, mais nous voulions rendre cette vérification facultative afin que notre outil puisse être utilisé par d'autres, dans des scénarios plus simples, par exemple sans Cloud IAM.

Pour ce faire, nous avons conçu et mis en œuvre nexus-proxy.

Curieusement, nous avons réalisé plus tard que ce choix facilite grandement la résolution d'autres problèmes, indépendants de l'authentification. Par exemple, Nexus ne peut exposer le registre privé de Docker avec la même configuration que celle utilisée pour exposer celui d'autres artéfacts sans compromettre l'utilisation systématique d'HTTPS. Il a également remplacé Nginx en tant que proxy inversé de GCLB.

Sauvegarde Nexus

Nexus peut être configuré pour sauvegarder sa base de données interne régulièrement. Toutefois, ce processus ne tient pas compte des magasins blob. De plus, les sauvegardes sont conservées uniquement sur le disque local. Donc, si ce dernier est perdu, toutes les sauvegardes le sont également.

Nous avons donc eu l'idée de créer l'outil nexus-backup pour exécuter la procédure de sauvegarde, puis charger le résultat dans Cloud Storage.

travel audience - Sonatype Nexus ajouté à Google Cloud Platform

  1. Les magasins blob de Nexus sont stockés sur un Google Persistent Disk (PD) accessible via nexus-backup.
  2. Un fichier utilisé pour déclencher les sauvegardes est également stocké sur le même PD.
  3. Une tâche configurée dans Nexus dépose régulièrement une sauvegarde de la base de données Nexus dans ce dernier.
  4. Une autre tâche, aussi configurée dans Nexus, signale le déroulement de la sauvegarde en mettant à jour le fichier de déclenchement.
  5. nexus-backup surveille ce dernier et, dès que celui-ci est mis à jour, lance la procédure de sauvegarde des magasins blob.
  6. nexus-backup récupère la copie de la base de données et les fichiers de sauvegarde des magasins blob sur le PD.
  7. nexus-backup charge la sauvegarde dans un contenant Google Cloud Storage prédéfini.
  8. La procédure de reprise consiste à effectuer une copie de sauvegarde sur un PD rattaché à Nexus. Nexus récupère ensuite la copie et la restaure automatiquement au redémarrage.

À noter : si un fichier de verrouillage est présent pendant plus de 12 heures (ce qui correspond probablement à l'échec d'une sauvegarde), il est supprimé pour que d'autres sauvegardes puissent être effectuées.

Utilisation et gestion de Nexus lifecycle

Nous nous appuyons sur Kubernetes (GKE) pour déployer et gérer le cycle de vie de notre installation Nexus. Pour ce faire, nous disposons d'instructions open source détaillées, notamment sur la reprise après sinistre et sur son utilisation par nos développeurs.

De plus, nous travaillons actuellement sur un diagramme Helm, qui devrait être disponible rapidement.

Ce témoignage a été fourni par l'équipe DevOps de travel audience.

travel audience - location banner v02.jpg

 
  
Récits de nos clients