Swirl.SWIRL CLOUD
Comment fonctionne Swirl Cloud. Des serveurs nus aux applications en production.
Un hub d’installation prépare vos serveurs, installe chaque couche de la plateforme et vérifie le résultat. Ensuite, Git décrit l’état voulu : la plateforme et vos applications s’y alignent en continu.
L’installation
Préparer
Des serveurs Ubuntu, loués ou à vous, et un nom de domaine. Un premier serveur demande au moins 8 cœurs, 32 Go de mémoire et 500 Go NVMe.
Répondre au hub
Le hub, en français ou en anglais, vérifie le serveur, ne pose que les questions d’une installation express (ou toutes en mode avancé) et teste vos jetons avant d’installer.
Installer et vérifier
Kubernetes, le stockage, l’entrée réseau, Vault, les données, l’authentification unique, GitLab, Argo CD et Odoo sont installés dans l’ordre, puis contrôlés.
Grandir
Le même hub ajoute des serveurs et importe vos dépôts d’applications. Les réponses enregistrées permettent de relancer l’installation sans intervention.
L’architecture
- Accès
- Visiteurs et équipesNavigateur, Git, API
- Périphérie
- CloudflareDNS, TLS, pare-feu applicatif, accès d’administration
- Entrée
- TraefikRoutage des adresses
- KeycloakAuthentification unique
- Services
- PlateformeGitLab · Argo CD · Grafana · Kibana · Trivy · SonarQube
- Vos applicationsint · uat · prod
- OdooERP · CRM · chat
- Données
- Bases et messagesPostgreSQL · MongoDB · Redis · Kafka
- VaultSecrets, transmis par External Secrets
- Socle
- KubernetesSur des serveurs Ubuntu
- LonghornStockage répliqué
- Réseau privévRack · Tailscale · LAN
Du commit à la production
Pousser
Un commit arrive dans le projet GitLab de l’application.
Construire
La CI teste le code et publie une image immuable dans le registre de la plateforme.
Promouvoir
La CI inscrit dans Git l’empreinte de l’image pour l’environnement visé : int, uat ou prod.
Déployer
Argo CD applique la version, puis la CI vérifie la révision, la santé et l’adresse publique.
Haute disponibilité et reprise
Un serveur, puis plusieurs
Tout fonctionne sur un seul serveur. Les serveurs ajoutés rejoignent le cluster par un réseau privé et reçoivent des charges et des répliques de stockage.
Haute disponibilité à la demande
Un profil pour trois serveurs de contrôle ou plus : etcd intégré, entrée réseau sur chaque serveur, PostgreSQL, Kafka et Redis répliqués, et un contrôle de préparation avant activation. L’exercice de bascule sur trois serveurs reste à mener.
Archive de restauration
Chaque nuit : l’état de Kubernetes, un instantané de Vault, les sauvegardes PostgreSQL et MongoDB, les fichiers d’Odoo et la procédure de restauration. Sept copies locales ; en option, une copie chiffrée hors site conservée 7 jours, 5 semaines et 12 mois.
Exercices de panne
Hors production, un exercice supprime un pod de chaque service, mesure le temps de retour et sonde les adresses de l’environnement ; le résultat rejoint le rapport mensuel.
Mesuré, pas promis
Mesuré sur notre propre installation, un serveur, en octobre 2026.
- Réservé par les services de la plateforme
- environ 5,4 cœurs et 16 Gio
- Pic d’utilisation CPU, applications comprises
- 3 cœurs
- Adresses publiques sondées (objectif 99,5 %)
- 25
- Retour d’un service après la perte d’un pod
- 7 à 47 secondes
- Point de reprise de l’archive nocturne
- jusqu’à 24 heures