Migrer une application existante vers Pierrr

Avant de commencer

Cette checklist reprend ce qu'on rencontre en pratique en amenant une application qui tourne déjà ailleurs sur votre propre serveur. Passez-la dans l'ordre : chaque point évite un échec de déploiement ou une coupure.

• Un serveur à vous est connecté à Pierrr et son assistant d'installation est terminé. Voir Serveurs.
• Votre fournisseur de code est connecté à l'organisation, avec accès aux dépôts à migrer. Voir Organisations.
• Vous avez une sauvegarde récente et chiffrée de vos données (base, fichiers envoyés par vos utilisateurs) et une copie de la configuration actuelle du serveur. Ne commencez pas sans elles.
• Vous avez noté les enregistrements DNS actuels de chaque domaine : ils servent au retour arrière.

Route de santé

Pierrr vérifie chaque conteneur avec une requête sur un chemin de santé, et n'envoie le trafic sur une nouvelle version que si elle répond bien. Une route de santé mal réglée est la première cause d'un déploiement annulé.

• Créez une route de santé si elle n'existe pas : elle doit répondre 200 sans dépendre d'une session, d'une base ou d'un service externe.
• Elle doit répondre aux requêtes GET et aux requêtes HEAD. Certains frameworks ne déclarent que GET : une sonde en HEAD reçoit alors une erreur et l'application est vue comme arrêtée alors qu'elle fonctionne.
• Si votre route n'est pas /health, réglez son chemin dans les réglages de build de l'application (onglet Dépôts). Le chemin par défaut n'est pas deviné.
• Un HEALTHCHECK écrit dans votre Dockerfile est ignoré : ne le maintenez pas en double. Voir Projets.

Un Dockerfile dédié

Le Dockerfile utilisé par votre chaîne d'intégration actuelle est souvent pensé pour un autre environnement : il suppose des secrets, des étapes ou un registre qui n'existent pas ici.

• Préférez un Dockerfile écrit pour Pierrr, dans le dépôt, plutôt que de reprendre celui de votre CI tel quel. Quand le dépôt en contient un, Pierrr l'utilise sans le remplacer.
• Sans Dockerfile, Pierrr propose un modèle adapté au framework : vous gardez la main sur les commandes d'installation, de build et de démarrage.
• Le contrôle d'avant build signale les erreurs courantes (ligne LABEL avant le premier FROM, dépendances manquantes) : lisez ses avertissements avant de lancer le premier déploiement.
• L'application doit écouter sur le port déclaré, sur toutes les interfaces, pas seulement sur localhost.

Projets mono-dépôt

Quand un seul dépôt contient plusieurs services (une API, un service annexe, plusieurs sites), chaque service devient sa propre application dans le même projet Pierrr.

• Créez une application par service, chacune liée au même dépôt avec le chemin de son propre Dockerfile.
• Activez « Monorepo : construire depuis la racine du dépôt » quand le Dockerfile vit dans un sous-dossier mais que le build a besoin de voir tout le dépôt (paquets partagés, fichier de verrouillage à la racine). Le contexte de build est alors la racine.
• Dans ce cas, écrivez les chemins des COPY du Dockerfile relativement à la racine du dépôt, pas au sous-dossier.
• Donnez à chaque application son propre chemin de santé et son propre port : ne supposez pas qu'ils sont partagés.

Mémoire de build sur un petit serveur

Un build consomme souvent beaucoup plus de mémoire que l'application une fois lancée. Sur un petit serveur, le constructeur est plafonné et un build peut être arrêté faute de mémoire, avec un message peu parlant.

• Bornez la mémoire de l'outil de build, par exemple en limitant le tas de Node avec NODE_OPTIONS=--max-old-space-size dans le Dockerfile, à une valeur inférieure à la mémoire du serveur.
• Désactivez ce qui n'est pas indispensable au build : cartes de sources, analyses de bundle, vérifications lancées en parallèle.
• Ne lancez pas plusieurs déploiements lourds en même temps sur la même machine : enchaînez-les.
• Un déploiement en échec pour « mémoire insuffisante » se corrige en bornant le build ou en donnant plus de mémoire à la machine, pas en réessayant.

Importer les secrets sans les copier ailleurs

Vos variables d'environnement contiennent des clés qui ne doivent transiter par aucun outil de discussion, ticket ou e-mail.

• Depuis votre poste, ouvrez le coffre du projet et utilisez l'édition groupée : collez le bloc .env directement dans la fenêtre, l'aperçu compte les ajouts et les remplacements avant d'appliquer. Voir Projets.
• Ne collez jamais un fichier .env dans un chat, un ticket ou un message : si cela est arrivé, changez les clés concernées.
• Retirez de la liste les variables qui ne servent plus dans le nouvel environnement (hôtes internes de l'ancien serveur, jetons de CI).
• Les valeurs publiques lues par le navigateur doivent être lues côté serveur au démarrage, pas figées au build.

Base de données

Sur votre serveur, la base du projet est créée sur la machine, jamais chez Pierrr. Vous y restaurez un export de l'ancienne base.

• Exportez l'ancienne base en un fichier SQL, puis restaurez-le avec « Importer mes données » dans l'onglet Sauvegardes, en envoyant le fichier ou en donnant son adresse https.
• Une base volumineuse est copiée en plusieurs minutes : laissez la fenêtre suivre l'avancement et ne relancez pas l'import.
• Si l'ancienne base contient des lignes orphelines (des références vers des lignes supprimées), la restauration peut échouer sur une contrainte : nettoyez les orphelins à la source, ou importez en laissant ces contraintes non validées et corrigez ensuite.
• Comparez ensuite le nombre de lignes des tables principales entre l'ancienne et la nouvelle base avant de continuer.

Cache et volumes

Le cache et les volumes d'un projet sur votre serveur sont inclus : ils s'ajoutent sans achat.

• Ajoutez le cache au projet si l'application en a besoin, puis liez-le explicitement au conteneur : une ressource n'atteint un conteneur que si vous l'y connectez.
• Créez un volume pour chaque dossier à conserver (fichiers envoyés, données locales) et attachez-le au conteneur avec son chemin de montage, dans la Topologie.
• Recopiez le contenu des anciens dossiers dans les nouveaux volumes avant la bascule, puis vérifiez qu'il est bien visible depuis l'application.
• Le contenu d'un cache n'a pas à être migré : il se reconstruit.

Domaines

Un domaine servi par votre serveur se règle avec un enregistrement A vers l'adresse IP publique de la machine.

• Ajoutez chaque hôte séparément (racine, www, sous-domaines) et liez chacun au bon service : un hôte, un service. Voir Domaines.
• Créez un enregistrement A par hôte vers l'adresse IP publique du serveur, et ne touchez pas aux enregistrements de messagerie.
• Le certificat est émis pour chaque hôte séparément, une fois le DNS correct et le port 80 joignable depuis Internet. Avec plusieurs hôtes, certains certificats arrivent quelques minutes après les autres : Pierrr retente tout seul, et « Réessayer le TLS » relance à la demande.
• Baissez la durée de vie (TTL) des enregistrements avant la bascule pour qu'un retour arrière soit rapide.

Désactiver le déploiement automatique pendant les essais

Tant que l'ancienne installation sert encore vos visiteurs, un push ne doit pas relancer les builds de tous les services sans que vous l'ayez décidé.

• Dans l'onglet Dépôts, désactivez l'interrupteur « Déploiement auto » de chaque application pendant la phase d'essai. Un push sur la branche surveillée ne lance alors plus rien.
• Déployez à la main, application par application, et attendez la fin de chaque build avant de lancer le suivant.
• Réactivez l'interrupteur seulement une fois la bascule terminée et vérifiée.

Bascule des ports 80 et 443 et retour arrière

Un serveur ne peut servir vos domaines que si les ports 80 et 443 sont libres. Si un autre programme les occupe (l'ancien serveur web de la machine), l'accès public de vos applications ne se met pas en place et un badge d'échec le signale.

• Vérifiez d'abord l'application sur son adresse Pierrr, avec ses données réelles, avant de toucher aux ports.
• Au moment choisi, arrêtez l'ancien programme qui occupe les ports 80 et 443, puis laissez Pierrr synchroniser l'accès public des applications, ou relancez la synchronisation.
• Retour arrière : gardez l'ancienne configuration et l'ancien programme prêts à redémarrer. Pour revenir, arrêtez l'accès public côté Pierrr, redémarrez l'ancien programme sur les ports 80 et 443, et remettez au besoin les anciens enregistrements DNS notés au départ.
• Ne supprimez ni l'ancienne base, ni l'ancien dossier de fichiers, ni l'ancienne configuration avant plusieurs jours de fonctionnement stable.

Vérifications finales

Avant de considérer la migration comme terminée, parcourez cette liste sur chaque domaine.

• Chaque hôte répond en https avec un certificat valide et sans avertissement du navigateur.
• Chaque application est en bonne santé dans Pierrr, et le dernier déploiement est en succès.
• Les parcours importants fonctionnent avec de vraies données : connexion, envoi de fichier, paiement de test, envoi d'e-mail.
• Les tâches planifiées de l'ancienne installation sont bien reprises, et non exécutées deux fois.
• Une sauvegarde de données est lancée sur le nouveau projet et son résultat est vérifié.
• Le déploiement automatique est réactivé, et l'ancienne installation n'est retirée qu'après quelques jours.