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.

Le chemin dans l'interface

1. 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.
2. Ouvre la fiche du site et descends jusqu'à la section Production.
3. Clique sur Mettre en production. Un encadré rappelle que l'opération prend plusieurs minutes et t'annonce l'adresse finale.
4. Pour une application Node, un champ facultatif Commande qui démarre ton application apparaît. Laissé vide, il lance le script start de ton package.json, autrement dit npm start : c'est le bon choix dans la plupart des cas. N'écris node server.js que pour un site Next.js construit en mode standalone, qui produit ce fichier. Iridflow contrôle la commande avant de commencer et, s'il la refuse, affiche le motif.
5. Clique sur Confirmer. Une mise en production prend souvent plusieurs minutes, davantage avec une base de données, qu'il faut d'abord installer. Au-delà d'une quarantaine de secondes, la section l'annonce : l'opération continue sur le serveur, et la carte se met à jour toute seule. Tu peux fermer la page, rien ne s'arrête.
6. La section affiche alors l'adresse publique, l'état du conteneur et ses ressources. Le site apparaît aussi dans le menu Production. Si l'opération échoue, la section l'affiche en rouge avec le motif et l'heure : corrige la cause, puis relance.

Ce que la promotion fait réellement

1. 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.
2. 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é.
3. 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.
4. 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.

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, sauf pour WordPress. Pour une application avec sa base PostgreSQL, ce 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. Pour WordPress, la base et le contenu de la préproduction sont transportés : le site de production est celui que tu as vérifié.

Les six runtimes promouvables

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.

Les courriels du site

Iridflow n'envoie pas les courriels de tes sites. Un formulaire de contact, une commande ou un mot de passe oublié partent par ton fournisseur de messagerie (Brevo, Mailjet, Google Workspace, la messagerie de ton nom de domaine), avec tes identifiants.

• Les ports 465 et 587 sont ouverts, le port 25 est fermé, en préproduction comme en production. Le 25 partirait de l'adresse que partagent tous les sites : un seul site piraté en ferait un envoyeur de pourriel pour tous.
• WordPress : installe une extension SMTP (WP Mail SMTP, FluentSMTP) et règle-la avec les paramètres de ton fournisseur. Sans elle, WordPress n'envoie rien et le dit : il affiche que le message n'a pas pu être envoyé.
• Application Node : ta bibliothèque d'envoi lit l'hôte, le port et les identifiants dans les variables du site. Voir Variables.
• L'adresse d'expédition doit appartenir à un domaine que ton fournisseur a le droit de signer (SPF, DKIM et DMARC posés sur ton domaine). Sinon tes courriels arrivent en indésirables, ou pas du tout.

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.

Retirer un site de la production

1. Fiche du site, section Production.
2. 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.
3. 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.

En complément, par le MCP

promote_to_prod({ site_id: "site_xxxxxxxx" })      // start_command vide : npm start
get_site({ site_id: "site_xxxxxxxx" })             // promotion : issue de la dernière mise en production
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.