🚀 Architecture GitOps & Multi-Cloud : Déploiement automatisé d'une infrastructure OwnCloud résiliente

Bienvenue sur cette nouvelle publication de KernelLab ! Aujourd'hui, je vous propose une plongée technique au cœur d'un projet d'infrastructure complet : le déploiement hautement disponible d'une solution OwnCloud. L'enjeu de ce projet était de concevoir une architecture capable d'être disponible 24h/24 pour des utilisateurs mondiaux, avec un focus drastique sur l'automatisation GitOps, la sécurité (SecOps) et l'optimisation budgétaire (FinOps).

Afin d'entrer dans les détails de l'ingénierie, j'ai décomposé cet article en plusieurs axes stratégiques, de la conception réseau à l'observabilité fédérée.

🏗️ L'Architecture Multi-Cloud : Le Choix de la Résilience

Pour garantir une tolérance aux pannes maximale et éviter un Single Point of Failure lié à un fournisseur unique, l'infrastructure a été pensée en Multi-Cloud. Ce découplage stratégique sépare l'environnement d'exécution de son système de supervision.

(Schéma d'architecture Macro/Mezzo détaillant les flux réseaux et la répartition des services)

1. Google Cloud Platform (GCP) : Le Socle Applicatif

La totalité des workloads applicatifs est hébergée sur l'infrastructure Google, répartie comme suit :

• Google Kubernetes Engine (GKE) : L'orchestration s'appuie sur un cluster GKE Standard (non-Autopilot). Ce choix nous offre une maîtrise totale sur l'allocation des ressources et permet l'utilisation d'instances Spot (e2-standard-2) pour optimiser massivement les coûts.
• Bases de données & Cache : Les données persistantes reposent sur Cloud SQL (MySQL managé), garantissant une scalabilité élastique et l'externalisation automatique des backups (rétention sur 7 jours). Pour le stockage temporaire, Redis est déployé directement en intra-cluster pour des raisons de performances et de coûts.
• Workloads Serverless : Notre brique d'analyse CI interne (développée en FastAPI/Python) est exécutée sur Cloud Run et interagit avec Artifact Registry, bénéficiant ainsi d'une facturation à l'usage pur.

2. Amazon Web Services (AWS) : L'Îlot d'Observabilité

La supervision est volontairement isolée sur AWS pour garantir l'indépendance de l'alerte en cas de défaillance majeure du cluster principal.

• Infrastructure de calcul EC2 : Déploiement d'une instance t3.medium allouée à Prometheus (pour répondre à son exigence en RAM) et d'une instance t3.small pour Grafana (le langage Go permettant une empreinte mémoire très réduite).
• Réseau isolé : Les instances évoluent dans un VPC dédié avec une Internet Gateway et un durcissement strict via les Security Groups (autorisant le port 22 pour l'administration restreinte).

⚙️ Infrastructure as Code (IaC) & Gestion de Configuration

L'intégralité du cycle de vie des ressources est pilotée par le code pour garantir immuabilité et reproductibilité. Fini la configuration manuelle et le "configuration drift".

(Vue micro des pipelines et du provisionnement)

1. Provisioning Multi-Fournisseurs avec Terraform

L'approche GitOps commence dès la couche infrastructure :

• Pipeline CI de validation : Chaque modification du code Terraform déclenche des jobs de validation (fmt, validate) et de planification (plan) accessibles sur l'ensemble des branches Git.
• Déploiement contrôlé : L'exécution des modifications (apply) est strictement conditionnée à une validation manuelle et uniquement autorisée sur la branche principale (main).
• Sécurité de l'état : Le remote state de l'infrastructure est sécurisé sur un bucket GCP (Cloud Storage) doté d'un mécanisme de state lock pour éviter toute corruption lors de travaux collaboratifs.

2. Harmonisation Post-Déploiement avec Ansible

Une fois les serveurs provisionnés, Ansible prend le relais pour standardiser l'OS :

• Playbooks idempotents : Installation des prérequis (Docker, dépendances système) pour nos outils de monitoring (Grafana/Prometheus).
• Sécurisation CI : Le déploiement s'appuie sur un repository unique. Les clés SSH nécessaires pour se connecter aux instances AWS sont injectées de manière sécurisée sous forme de variables encodées en Base64 dans GitLab CI.

🔄 L'Usine Logicielle (CI/CD) & L'Approche GitOps

L'automatisation de nos déploiements s'appuie sur GitLab Workflow et ArgoCD, faisant de Git l'unique source de vérité.

1. Intégration Continue (GitLab CI) & "Shift-Left"

Notre pipeline logicielle est découpée en plusieurs étapes critiques pour assurer la qualité du livrable avant même de penser à la production :

• Phase de Test & Qualité : Analyse statique stricte via PHPStan, détection de vulnérabilités et gestion de la dette technique avec SonarCloud, et validation fonctionnelle avec PHPUnit.
• Build & Push : Génération de l'image Docker OwnCloud compilée depuis les sources, puis persistance de l'artefact sur GitLab Container Registry.
• Mise à jour des Manifestes : Un job CI met à jour automatiquement le SHA de la nouvelle image dans notre dépôt Git dédié aux manifestes Kubernetes.

2. Déploiement Continu avec ArgoCD

Plutôt que de "pousser" les modifications vers le cluster, c'est le cluster qui vient synchroniser son état avec Git.

(Interface ArgoCD assurant la synchronisation des workloads : Kong, Redis, OwnCloud, Cert-Manager)

• Synchronisation Automatique : ArgoCD, déployé via Helm, scrute en permanence notre dépôt. Dès qu'une modification est détectée (nouveau tag d'image, modification de config), il synchronise le cluster GKE.
• Traçabilité et Réversibilité : Tout l'historique étant versionné, un Rollback vers une version stable précédente est instantané en cas d'anomalie en production.

📊 Observabilité : Fédérer pour mieux anticiper

Notre stratégie de monitoring repose sur les standards de la CNCF, avec une architecture pensée pour la résilience.

(Dashboard Grafana : Suivi de l'état des Pods GKE, saturation mémoire et trafic réseau)

1. Architecture Fédérée Prometheus

• Collecte locale (GCP) : Un premier agent Prometheus est déployé en intra-cluster sur GKE pour scraper automatiquement les métriques de nos charges de travail (Pods, Nœuds).
• Centralisation externe (AWS) : Un second Prometheus externe vient interroger l'agent GCP. Cette séparation garantit que la donnée n'est ni altérée ni perdue en cas de crash complet du cluster Kubernetes.

2. Pilotage Dynamique avec Grafana

• Analytique Visuelle : Création de tableaux de bord granulaires permettant d'observer en temps réel la consommation CPU/RAM des nœuds, le trafic réseau In/Out, et la santé (Running, Pending, Failed) de nos conteneurs.
• Alerting Proactif : Configuration de seuils critiques générant des notifications automatiques (via SMTP et Webhooks Discord) pour prévenir les équipes avant même que l'utilisateur ne subisse de lenteurs.

💰 FinOps & Sécurité (SecOps)

Une architecture élégante doit également être économiquement performante et sécurisée en profondeur.

1. Maîtrise des Coûts (Démarche FinOps)

• Arbitrage des bases de données : Le déploiement de Redis en tant que conteneur interne au cluster nous fait économiser au minimum 25€/mois par rapport à une offre externe.
• Optimisation Compute : Le choix de GKE Standard face à Autopilot, couplé à l'utilisation d'instances Spot, réduit considérablement la facture GCP (économie d'environ 20 à 30%).
• Hébergement Monitoring : Les instances EC2 sur AWS se sont révélées 10 à 15% plus compétitives que leurs équivalents GCP pour le profil de charge de nos outils d'observabilité.

2. Durcissement des accès (SecOps)

• Gestion des Identités (IAM) : Application stricte du principe de moindre privilège. Chaque ressource (Terraform, Cloud Run, EC2) ne dispose que des droits IAM ou Comptes de Service strictement nécessaires à son exécution.
• Exposition maîtrisée : L'accès public à l'application OwnCloud se fait via Kong API Gateway (déployé au sein de GKE) qui gère la terminaison TLS (HTTPS) et le routage applicatif. Ce choix anticipe le standard Gateway API de Kubernetes, plus robuste que les Ingress traditionnels.
• Identité Numérique : L'utilisation souveraine d'OVHCloud pour la gestion DNS et l'implémentation du serveur SMTP métier nous assure une parfaite maîtrise de nos flux de communication et du budget.

🚀 Perspectives et Améliorations Futures

Ce projet illustre concrètement l'agilité qu'offre l'écosystème Cloud Native. L'association de Terraform, Kubernetes et d'un workflow GitOps sous ArgoCD garantit une sérénité de déploiement indispensable en environnement de production.

Cependant, l'infrastructure est un produit vivant. Les prochaines itérations prévoient :

1. SecOps avancé : L'intégration de Trivy dans nos pipelines CI pour le scan de vulnérabilités des images Docker en amont, et l'implémentation d'un Bastion d'administration sur le VPC AWS pour supprimer tout accès SSH public aux instances EC2.
2. Observabilité prédictive : L'affinement de nos seuils d'alertes Grafana et l'exploitation directe de l'interface de Prometheus.