Mettre en production
C'est l'acte final de la mise en ligne : sortir un site de l'environnement de travail pour le faire servir les vrais visiteurs, sur une machine qui n'est qu'à lui.
Deux environnements, pas un
Tout site Iridflow naît en préproduction. C'est là qu'on le construit, qu'on le déploie, qu'on le casse et qu'on le répare. Son adresse se termine par staging.iridflow.com, et rien n'y est définitif.
La production est un second environnement, séparé. Un site n'y arrive que si quelqu'un l'y met explicitement. Il y tourne alors dans un conteneur système dédié sur la grappe, isolé des autres sites, joignable uniquement par le répartiteur de charge, et publié sur une adresse qui se termine par prod.iridflow.com.
| Préproduction | Production | |
|---|---|---|
| Existe | Dès la création du site | Sur décision explicite |
| Adresse | <slug>.staging.iridflow.com | <slug>.prod.iridflow.com |
| Voisinage | Partagé avec les autres sites | Un conteneur dédié, avec ses propres ressources |
| Sauvegardes Iridflow | Oui | Non |
Attention
Les sauvegardes automatiques portent sur la préproduction. Ce qui est écrit en production, base de données comprise, n'est pas repris par le bouton Backup now. Voir Sauvegardes et export.
Le chemin dans l'interface
- Déploie et recette le site en préproduction. C'est un prérequis, pas un conseil : c'est le résultat de ce déploiement qui partira en production.
- Ouvre la fiche du site et descends jusqu'à la section Production.
- Clique sur Mettre en production. Un encadré rappelle que l'opération prend quelques minutes et t'annonce l'adresse finale.
- Pour une application Node, un champ Commande qui démarre ton application apparaît. Il est obligatoire, et pré-rempli avec
node server.jspour un site Next.js. Iridflow ne devine pas comment lancer ton application. - Clique sur Confirmer. Le bouton se change en « Mise en production en cours, patiente ». Laisse la page ouverte, l'opération se termine toute seule.
- La section affiche alors l'adresse publique, l'état du conteneur et ses ressources. Le site apparaît aussi dans le menu Production.
Note
Si le runtime du site n'a pas d'équivalent en production, la section le dit au lieu de proposer un bouton : « ce runtime fournit son propre assemblage et n'a pas de transposition automatique en production ». La liste des runtimes concernés est plus bas.
Ce que la promotion fait réellement
- Elle fabrique un conteneur système dédié sur la grappe, avec un plafond de processeur, de mémoire et de disque, et un pare-feu qui ne laisse entrer que le répartiteur de charge.
- Elle y installe l'artefact déjà recetté. Pour un site qui se construit, le produit fini est extrait de l'image de préproduction. Pour un site servi tel quel, le contenu est copié depuis la préproduction. Dans les deux cas, rien n'est reconstruit et rien n'est réinstallé.
- Elle crée une base de données si le site en a une. Une base PostgreSQL rattachée en préproduction donne une base de production, dans son propre conteneur, dont les identifiants sont injectés dans l'application.
- Elle pose le routage sur le répartiteur de charge, ce qui rend l'adresse publique joignable. C'est la dernière étape, et elle fait partie de la mise en production : il n'y a rien à brancher ensuite.
Astuce
Transporter plutôt que reconstruire est la propriété la plus utile de cette opération. Ce qui part en production est exactement ce que tu viens de valider, octet pour octet. Une dépendance qui aurait changé entre-temps, un paquet republié, une construction qui ne donne plus le même résultat : rien de tout cela ne peut te surprendre au moment de la mise en ligne, puisqu'il n'y a pas de nouvelle construction.
Deux conséquences à connaître
- Promouvoir deux fois donne deux fois le même site. Pour publier une nouvelle version, il faut d'abord la déployer en préproduction, la vérifier, puis retirer le site de la production et l'y remettre. Un site déjà en production ne se met pas à jour en place.
- La base de production démarre vide. Elle n'est pas une copie de la base de préproduction : c'est une base neuve, prête à recevoir tes données. Prévois de les y verser toi-même.
Les six runtimes promouvables
| Runtime | Ce qui part en production | Commande de démarrage |
|---|---|---|
| static | Les fichiers du site, copiés tels quels | Inutile |
| wordpress | Le contenu WordPress, copié tel quel | Inutile |
| frontend-static | Le site construit, extrait de la préproduction | Inutile |
| nextjs-ssg | Le site construit, extrait de la préproduction | Inutile |
| nextjs | L'application construite, extraite de la préproduction | Obligatoire |
| node-generic | L'application construite, extraite de la préproduction | Obligatoire |
Les autres runtimes de la liste complète fournissent leur propre assemblage et n'ont pas de transposition automatique. Ils continuent de tourner normalement en préproduction.
Ressources allouées par défaut
- Site servi tel quel : 1 cœur, 512 Mo de mémoire, 5 Go de disque.
- Application Node : 2 cœurs, 2 Go de mémoire, 10 Go de disque.
- Une base de production, quand il y en a une, a son propre conteneur avec 2 cœurs, 2 Go et 20 Go.
Le nombre de conteneurs de production est plafonné par projet, cinq par défaut. Une base de production compte pour un conteneur : un site qui en a une en consomme donc deux. Au delà du plafond, Iridflow refuse la mise en production avant de commencer le moindre travail, en indiquant le compte atteint et la limite.
Quand ça ne se passe pas comme prévu
- Le site n'a jamais été déployé en préproduction. Il n'y a rien à transporter : déploie-le d'abord, puis recommence.
- Le site est déjà en production. Iridflow refuse d'en fabriquer un second conteneur. Retire-le de la production, puis remets-le.
- Le conteneur tourne mais l'adresse ne répond pas. Le répartiteur de charge n'a pas pu être configuré. Un avertissement est affiché sous l'état, sur la fiche du site et dans le menu Production. C'est un problème de plateforme : préviens un administrateur.
- La mise en production échoue. Iridflow supprime ce qu'il avait commencé à créer, pour ne rien laisser derrière. Le message d'erreur te dit s'il y est parvenu.
- Un état qui ne correspond pas à ce que tu attends. Voir Comprendre l'état de ses sites, qui détaille l'alerte de la page Production et la conduite à tenir.
Note
Domaine personnalisé et production. Un domaine ajouté à un site déjà en production est branché à la fois sur la préproduction et sur la production. Ajouté avant la mise en production, il ne mène qu'à la préproduction. Mets donc le site en production d'abord, ajoute le domaine ensuite. Voir Domaines personnalisés.
Retirer un site de la production
- Fiche du site, section Production.
- Clique sur Retirer de la production. Une fenêtre demande confirmation et annonce ce qui va disparaître : le conteneur, son disque et son adresse publique.
- Confirme. Le retrait prend quelques instants.
Ce qui disparaît :
- Le conteneur de l'application et son disque.
- Le conteneur de sa base de données, s'il y en a un, avec les données qu'il contient. Les deux partent ensemble.
- L'adresse publique. Le routage est retiré avant le conteneur, pour qu'un visiteur ne tombe pas sur une erreur de passerelle entre les deux.
Ce qui reste : la préproduction, intacte, avec son code, ses données, son dépôt Git et ses sauvegardes. Retirer de la production ne supprime pas le site.
Attention
Le retrait est définitif et rien n'en est sauvegardé. Avant de retirer un site qui sert de vrais visiteurs, sors ce que tu veux garder de sa base de production : les sauvegardes Iridflow ne la contiennent pas.
En complément, par le MCP
promote_to_prod({ site_id: "site_xxxxxxxx", start_command: "node server.js" })
list_prod_lxc({}) // ce qui tourne en production
demote_prod({ site_id: "site_xxxxxxxx", confirm_slug: "mon-site" })La promotion accepte aussi des ressources sur mesure et des variables d'environnement. Voir MCP et Claude Desktop.