Héberger une application métier.
Pour une équipe qui a développé un outil sur mesure en Symfony, Node.js ou Next.js, et qui veut le déployer sans gérer de serveur.
Ce qui menace une application.
Une application a plusieurs pièces qui doivent tourner ensemble. Le risque se loge souvent entre elles.
- Le déploiement à la main
- Une commande oubliée, une variable d’environnement manquante, et la nouvelle version ne démarre pas.
- La tâche de fond arrêtée
- L’interface répond, mais les imports, les exports ou les e-mails ne partent plus.
- L’écart entre les environnements
- Ce qui marche sur le poste du développeur casse en production, parce que les versions diffèrent.
- Les données sensibles
- Données clients, documents, historiques métier : il faut savoir où elles sont, et pouvoir le prouver.
Imaginons une application de planning.
Exemple inventé pour illustrer, pas un incident client. Le développeur fusionne une nouvelle version sur GitHub à 17 h. Argo CD la déploie dans le cluster. Les tâches de fond s’arrêtent sur une erreur : nous revenons à la version précédente, déjà décrite dans le dépôt, le temps que le développeur corrige.
Le schéma, du visiteur aux sauvegardes.
Chaque brique porte la couleur de sa couche : orange pour le logiciel, gris métal pour le matériel.
Ce que nous mettons en place, et pourquoi.
Le principe : tout ce qui tourne est décrit dans un dépôt, et rien ne se modifie à la main.
Un container par service
L’interface, l’API et les tâches de fond tournent séparément. L’un peut redémarrer sans emporter les autres.
Le déploiement continu avec GitHub et Argo CD
Une fusion sur la branche principale suffit. Argo CD aligne le cluster K3s sur ce que décrit le dépôt, et revenir en arrière revient à revenir à la version précédente du dépôt.
La base qui convient
MariaDB, PostgreSQL ou MongoDB selon votre application, avec Redis en cache quand il est utile.
Des images scannées
Chaque image est analysée avec Trivy avant d’être déployée, pour repérer les failles connues.
Une préproduction alimentée par le même dépôt
Une branche, un environnement de test identique à la production, et la recette se fait avant la mise en ligne.
Des données en France
Fichiers, bases, sauvegardes et journaux restent en France. Vous savez où elles sont.
Ce dont nous parlons avant de démarrer.
Nous regardons le code avec vous pour vérifier qu’il se déploie bien en container.
- 1Comment l’application est-elle découpée : interface, API, tâches de fond, planificateur ?
- 2Quelle base de données utilise-t-elle, et quel volume de données ?
- 3Le code est-il sur GitHub, et qui fusionne sur la branche principale ?
- 4Quelles variables et quels secrets faut-il fournir à chaque environnement ?
- 5Quels services extérieurs l’application appelle-t-elle : paiement, e-mail, stockage, API métier ?
- 6Combien d’utilisateurs en même temps, et à quels moments de la journée ?
Les autres architectures
Parlons de votre application.
Un audit rapide du code et de son déploiement, puis une architecture décrite dans un dépôt. Réponse dans la journée.
Site en panne ? 06 82 96 38 89, du lundi au samedi, de 9 h à 18 h