Architecture de GitGuardian

L'application GitGuardian repose sur une architecture cloud-native flexible. Elle s'appuie sur des charts Helm pour un déploiement simplifié, en proposant deux méthodes principales : l'interface d'administration KOTS (déploiement basé sur KOTS) ou la CLI Helm (déploiement basé sur Helm).

Architecture évolutive et modulaire

GitGuardian adopte une architecture modulaire, où chaque composant central est déployé en tant que service indépendant. Cette conception améliore l'évolutivité et offre une plus grande flexibilité :

• Mise à l'échelle des réplicas : Ajustez le nombre de réplicas de chaque service pour répondre à la demande.
• Configurations des ressources : Affinez les demandes et limites de ressources. Ces paramètres peuvent être configurés via Helm lors de l'installation ou dans l'interface KOTS avec certaines restrictions.
• Workers dédiés : Créez des pods workers dédiés pour gérer les files d'attente à forte demande (disponible dans les déploiements basés sur Helm).
• Autoscaling : Tirez parti de l'Horizontal Pod Autoscaling pour ajuster automatiquement le nombre de pods workers en fonction de la charge.

Aperçu de l'architecture

L'architecture de GitGuardian utilise un point d'entrée unique pour tous les appels d'API — un Ingress ou un Service de type LoadBalancer — qui achemine le trafic à travers un service Nginx agissant à la fois comme frontend et reverse proxy. Nginx est chargé de répartir les requêtes entrantes entre les API internes, les API publiques et les API hook. Dans cette configuration, Nginx gère toute la logique de routage, et il n'existe qu'une seule ressource Ingress ou LoadBalancer exposant l'application au monde extérieur.

Pour plus de détails sur les configurations de déploiement, les types de pods et leur utilisation, consultez la page Topologie de l'application GitGuardian. Pour les recommandations de mise à l'échelle, consultez Mise à l'échelle de GitGuardian.

ClickHouse pour l'analytique à grande échelle

Certaines fonctionnalités nécessitent ClickHouse, un composant stateful optionnel intégré au cluster et livré dans le cadre du chart Helm de GitGuardian, utilisé pour les charges de travail analytiques nécessitant des requêtes rapides sur de grands volumes de données. Contrairement à PostgreSQL et Redis, il n'est pas conçu pour être remplacé par un service entièrement géré en externe : il s'exécute toujours dans le cluster, adossé à un stockage objet que vous fournissez.

Prise en charge de la ligne de commande Helm

La fonctionnalité helm install permet un déploiement et une gestion simplifiés via le gestionnaire de paquets Helm largement adopté. Cette intégration simplifie l'installation, les mises à niveau et la configuration en tant que code.

À l'avenir, les prochaines versions étendront la prise en charge des outils GitOps comme ArgoCD et introduiront des options de configuration plus avancées, notamment :

• External Secrets Operator
• Istio Service Mesh & Gateway
• Certificate Manager

En savoir plus : Installer sur un existing cluster avec Helm.

Sécurité renforcée avec l'intégration Chainguard

L'architecture de GitGuardian intègre Chainguard, un outil de sécurité de nouvelle génération qui aide à atténuer les Common Vulnerabilities and Exposures (CVE) dans les images de conteneurs Self-Hosted.

Avec Chainguard, GitGuardian renforce sa posture de sécurité en :

• Réduisant les risques de vulnérabilités dans les images de conteneurs.
• Implémentant des modules cryptographiques approuvés FIPS pour un chiffrement sécurisé des données sensibles, à la fois au repos et en transit.

Cette intégration renforce l'engagement de GitGuardian à respecter les normes de sécurité et de conformité les plus élevées.

En savoir plus : Common Vulnerabilities and Exposures.