Choisir votre méthode d’installation
Avant d ’installer l’application, vous devez choisir parmi ces types d’installation :
- Cluster existant avec Helm (recommandé) - pour les déploiements sur des clusters Kubernetes existants avec des charts Helm (y compris l’option GCP Marketplace),
- Cluster intégré avec KOTS - pour les installations tout-en-un qui créent leur propre cluster Kubernetes avec une interface d’administration web.
Ce guide explique les différences entre ces méthodes et vous aide à choisir celle qui convient le mieux à vos besoins.
Qu’est-ce que Helm ?
Helm est un gestionnaire de paquets pour Kubernetes, souvent qualifié d’« équivalent Kubernetes d’apt/yum/homebrew ». Il permet de définir, d’installer et de mettre à jour les applications Kubernetes les plus complexes. Helm utilise des « charts », des ensembles de fichiers YAML qui décrivent un ensemble cohérent de ressources Kubernetes. L’outil simplifie la gestion des applications Kubernetes en offrant une commande unique pour déployer une application, gérer son cycle de vie et suivre l’historique des versions. Les configurations Helm peuvent être versionnées dans un dépôt Git et s’intègrent bien aux outils de CD comme ArgoCD ou FluxCD.
La conformité FIPS (Federal Information Processing Standards) n’est disponible que pour les installations basées sur Helm. Si vous avez besoin de modules cryptographiques conformes FIPS pour des raisons réglementaires, vous devez choisir la méthode d’installation Helm. Pour plus de détails, consultez la page Recommandations de sécurité.
GCP Marketplace
GitGuardian est également disponible sur le GCP Marketplace, la plateforme Google Cloud pour découvrir, déployer et gérer des solutions logicielles tierces. Cela permet un déploiement sur des clusters Google Kubernetes Engine (GKE) avec une facturation consolidée via votre compte GCP.
Les principaux avantages du déploiement GCP Marketplace sont la facturation consolidée sur votre facture GCP, la possibilité d’appliquer des remises d’engagement d’utilisation et un achat simplifié via vos accords GCP existants.
Le déploiement GCP Marketplace utilise Helm. Le déploiement initial se fait via la console GCP, mais les mises à jour et l’exploitation se font directement avec Helm : vous bénéficiez donc de tous les avantages des installations Helm.
Pour plus de détails, consultez le guide de déploiement GCP Marketplace.
Qu’est-ce que KOTS ?
KOTS (Kubernetes Off-The-Shelf) est un framework conçu pour aider les éditeurs logiciels à gérer le cycle de vie des applications Kubernetes de façon conviviale pour les clients entreprise. Il fournit des outils et une interface qui simplifient le déploiement, la gestion et le support des applications Kubernetes.
Qu’est-ce qu’une installation sur cluster existant
Vous pouvez installer l’application sur un cluster Kubernetes existant qui contient déjà des nœuds, en utilisant Helm. Vérifiez que ce cluster respecte les exigences système et réseau.
La section préparation des bases de données vous aide à les configurer correctement pour votre environnement.
Si vous prévoyez d’installer GitGuardian sur un cluster OpenShift, consultez les directives détaillées pour l’installation sur OpenShift.
Qu’est-ce qu’une installation sur cluster intégré
L’installation intégrée (Embedded) est une installation « tout-en-un » où le cluster Kubernetes est créé sur votre machine et tous les composants nécessaires à l’application sont installés. Cette méthode utilise KOTS (Kubernetes Off-The-Shelf) pour fournir une interface web conviviale pour le déploiement et la gestion.
Vous pouvez aussi utiliser des bases de données externes avec votre cluster Kubernetes intégré (et nous le recommandons). La section préparation des bases de données vous aide à les configurer correctement pour votre environnement.
Comment choisir entre ces options
Avant d’installer l’application, tenez compte des points suivants :
- disposez-vous des ressources et des compétences nécessaires pour gérer votre cluster Kubernetes ?
- des politiques de sécurité sont-elles en place sur votre cluster Kubernetes ?
- avez-vous les compétences et les ressources pour gérer vos propres bases de données ?
- aurez-vous besoin d’ajuster finement l’application ?
Si vous disposez déjà d’un cluster Kubernetes qui exécute différentes applications, avec des politiques de gestion et de sécurité précises et un responsable dédié dans vos équipes, vous devriez utiliser l’installation sur cluster existant avec Helm. L’application peut être installée dans un namespace dédié pour une meilleure isolation et organisation. Notez qu’un accès à une base PostgreSQL et à un cache Redis est également nécessaire.
L’installation Helm offre de nombreuses options de configuration et s’intègre bien aux pipelines d’automatisation et aux pratiques d’Infrastructure as Code.
Si vous déployez sur Google Cloud Platform et souhaitez consolider la facturation via votre compte GCP, envisagez le déploiement GCP Marketplace. Vous pouvez utiliser vos engagements de dépenses GCP et simplifier les achats tout en tirant parti des services managés GCP (Cloud SQL, Memorystore, GKE).
Si vous n’avez pas de ressources dédiées à la maintenance d’un cluster Kubernetes et des bases de données, privilégiez l’installation intégrée, qui utilise KOTS pour fournir une interface web conviviale pour la configuration et la gestion. Toutefois, les installations intégrées ne sont pas recommandées pour la production et conviennent plutôt à un essai ou à une preuve de concept (PoC).
Tableau des fonctionnalités : cluster existant (Helm) vs cluster intégré (KOTS)
Ce tableau compare les installations Helm (cluster existant) et les installations KOTS (cluster intégré), et met en évidence leurs capacités et différences principales.
| Fonctionnalité | Cluster existant (Helm) | Cluster intégré (KOTS) |
|---|---|---|
| Déploiement Infrastructure as Code (IaC) (recommandé) | Oui | Non |
| Déploiement avec interface graphique (GUI) | Non | Oui |
| Déploiement airgap | Oui | Oui |
| Prise en charge d’OpenShift | Oui | Oui |
| PostgreSQL et Redis externes (recommandé) | Oui | Oui |
| PostgreSQL et Redis intégrés | Non | Oui |
| Gestion de la charge (nombre de replicas) | Oui | Oui |
| Gestion des ressources (requêtes/limite CPU-mémoire) | Oui | Oui |
| Proxy HTTP | Oui | Oui |
| Autorité de certification personnalisée | Oui | Oui |
| Équilibreur de charge + Ingress | Oui | Oui |
| Prise en charge ARM | Oui | Non |
| Architecture compatible Ingress | Oui | Non |
| HPA (autoscaling horizontal de pods) | Oui | Non |
| Systèmes externes d’agrégation des journaux | Oui | Non |
| Volumes éphémères génériques inline | Oui | Non |
| Affinité de nœuds (planification) | Oui | Non |
| Service mesh Istio | Oui | Non |
| Labels personnalisés sur les pods | Oui | Non |
| Secrets Kubernetes existants | Oui | Non |
| Registre Docker privé | Oui | Non |
| Déploiement avec ArgoCD | Oui | Non |
| Déploiement avec FluxCD | Oui | Non |
| FIPS | Oui | Non |
| IPv6 | Oui | Non |
| GCP Marketplace | Oui | Non |
