Repository navigation
Exploitation
Le déploiement passe par ArgoCD. Un redéploiement exige un changement de tag d'image : un changement de manifest seul ne redémarre pas les pods.
- Chemin public d'abord : interrogez l'hôte d'ingress sur la racine, l'authentification et le healthz. Établissez ce qui est cassé avant de lire les journaux.
- Journal d'accès du strangler dans Loki pour la route en échec : status, IP d'upstream, temps de réponse. Un upstream sur 3001 pointe le backend cible, sur 8080 le backend historique. Vérifiez la table de routes de la release avant de supposer qu'une route existe.
- Journaux Loki du backend pour séparer le comportement applicatif du routage.
- Vérité en base par psql quand les journaux contredisent les attentes.
Les requêtes passent par le pod backend vers la gateway Loki avec l'en-tête X-Scope-OrgID. Le tenant prod-dso couvre les jobs du console, le tenant prod-infra couvre l'ingress. La rétention est de trente jours ; découpez les fenêtres longues en tranches de vingt-neuf jours. Armez toujours un timeout sur le fetch et bornez la limite. Les journaux du strangler tournent en quelques heures ; au-delà, passez par Loki. Les journaux du backend historique manquent de détail par route.
La base tourne sur CNPG. Le superutilisateur se récupère dans le secret pg-cluster-console-superuser. Exécutez psql dans le conteneur postgres du pod.
Passez le SQL multi-instructions par l'option -c. Un heredoc est consommé par le shell local et n'atteint jamais le pod. Les tables Prisma sont en PascalCase quoted. log_statement vaut none : les journaux PostgreSQL ne montrent pas le DML. L'historique d'application des migrations se lit dans _prisma_migrations.
La stack d'intégration Docker fournit un postgres local. Passez un script SQL par l'entrée standard du conteneur. Pour rejouer une migration suspecte, construisez un fixture minimal, exécutez le SQL de la migration dans une transaction avec rollback : le défaut se reproduit sans changement persistant. Un fixture sur la table Project doit fournir les colonnes de quota non nulles.
Pendant la fenêtre de strangler, les deux backends seedent les rôles système de projet avec des valeurs différentes. Les projets créés via le backend historique portent les valeurs historiques. Toute migration ou invariant sur les lignes de ProjectRole système doit tenir pour les deux sorties. La table n'a pas de contrainte d'unicité sur projet et nom : un backfill par anti-jointure duplique au lieu de converger.
Une table vide alors que la migration de seed est marquée appliquée se répare en réinjectant les lignes du SQL de la migration, source de vérité dans apps/server-nestjs/src/prisma/migrations, avec ON CONFLICT DO NOTHING, via le service en écriture. Vérifiez le comptage par le même chemin que le DSN du backend.
Un watch Pinia est profond : chaque mutation déclenche. Protégez un refetch par un flag de chargement, pas par un test de vide. Une rafale de GET identiques depuis un même navigateur signale une boucle de watch avant un sondage backend.
Console Cloud Pi Native