> ## Documentation Index > Fetch the complete documentation index at: https://infra-docs.kaeyros.org/llms.txt > Use this file to discover all available pages before exploring further. # Renommer une Application ArgoCD sans casser la prod > Renommer une Application ArgoCD recrée toutes les ressources Kubernetes. Découvrez les effets, les risques et la procédure recommandée pour éviter une interruption de service. Sur Kaeyros Analytics, le nom complet d'une ressource Kubernetes est dérivé du couple `Application + chart`. Par conséquent, renommer une Application ArgoCD ne modifie pas simplement une étiquette : cela recrée l'intégralité des ressources Kubernetes associées (Rollout, Service, Ingress, ServiceAccount). Cette page détaille les effets concrets de cette opération et vous guide dans sa préparation. ## Ce qui se passe Lorsque vous modifiez le nom d'une Application dans ArgoCD, la chaîne de déploiement déclenche une séquence irréversible de création et de suppression. **1. Création des nouvelles ressources** ArgoCD détecte le nouveau nom d'Application et provisionne un nouveau Rollout, un nouveau Service, un nouvel Ingress et un nouveau ServiceAccount sous le préfixe `fullname` mis à jour. **2. Suppression des anciennes ressources** ArgoCD applique la politique de pruning : les anciennes ressources portant l'ancien `fullname` sont supprimées du cluster. Cette étape est automatique et non configurable depuis l'interface ArgoCD. **3. Changement du nom DNS interne** Le Service ClusterIP porte le nom `-`. Son renommage entraîne un changement immédiat du nom DNS interne résolvable dans le cluster : `http://..svc.cluster.local`. ## Les deux effets à anticiper Deux conséquences directes affectent la disponibilité et la connectivité de vos services. Anticipez-les impérativement avant de valider un renommage. > [!WARNING] > > **Coupure de service pendant la bascule** > > Entre la suppression de l'ancien Rollout et la mise en route du nouveau, les pods actifs disparaissent momentanément. Le Ingress n'a plus de cible backend valide. Les utilisateurs externes et les jobs internes subissent une interruption de quelques secondes à quelques minutes, selon la vitesse de démarrage des conteneurs et la propagation DNS. > [!WARNING] > > **Rupture des appels service-à-service hardcodés** > > Si d'autres applications ou des traitements `data-precompute` appellent votre service via une URL interne écrite en dur, du type `http://..svc.cluster.local`, ces requêtes échouent immédiatement après le pruning. Le nouveau Service répond désormais sous `http://..svc.cluster.local`. ## Migration rollout vers rollout-v2 Le même mécanisme s'applique lorsque vous migrez un déploiement du chart `rollout` vers `rollout-v2`. Le suffixe du `fullname` passe de `…-rollout` à `…-rollout-v2`, ce qui déclenche la recréation complète de la stack. > [!NOTE] > > Traitez une migration `rollout` → `rollout-v2` comme un renommage à part entière. Toutes les ressources sont recréées, le nom DNS interne change et une coupure est inévitable. Planifiez cette opération en dehors des heures de pointe de vos utilisateurs finaux (Tenants). ## Procédure recommandée Suivez cette séquence pour minimiser l'impact d'un renommage ou d'une migration de chart. **1. Inventorier les appelants** Parcourez les dépôts de code, les fichiers `values` des autres Applications et les configurations de jobs `data-precompute` pour identifier toutes les occurrences de l'ancien nom DNS interne. Recherchez aussi les références dans les variables d'environnement et les secrets Kubernetes. **2. Choisir une fenêtre de maintenance** Sélectionnez un créneau hors heures de pointe, de préférence en coordination avec les équipes produit concernées (Distribution, Santé, RH, etc.). Informez les stakeholders via le canal habituel avant de commencer. **3. Préparer un PR unique** Créez une pull request regroupant : * le nouveau fichier d'Application dans `apps/` * la mise à jour de tous les appelants (code source et fichiers de valeurs Helm) * la suppression programmée de l'ancien fichier d'Application Évitez de scinder ces modifications en plusieurs PR. Une synchronisation partielle laisse le cluster dans un état incohérent. **4. Merger et surveiller ArgoCD** Après fusion, surveillez la synchronisation dans l'interface ArgoCD (serveur `argo-production`). Vérifiez que le nouveau Rollout atteint l'état `Healthy` et que les pods sont prêts (`Ready`) avant de considérer l'opération comme terminée. **5. Vérifier le nettoyage** Confirmez dans ArgoCD que l'ancien Ingress, l'ancien Service et l'ancien Rollout ont bien été supprimés (prune effectuée). Un résidu manuel peut provoquer des conflits de routage Traefik ou des erreurs de certificat TLS. ## Ce qu'il faut ne PAS faire > [!WARNING] > > **Évitez ces erreurs courantes :** > > * **Renommer sans prévenir** : ne modifiez jamais le nom d'une Application sans communication préalable aux équipes et sans fenêtre de maintenance définie. > * **Ignorer les appels internes hardcodés** : une URL en dur du type `http://..svc.cluster.local` dans un autre microservice ou un traitement planifié provoque une panne en cascade invisible depuis ArgoCD. > * **Merger le renommage avant la mise à jour des appelants** : si le nouveau Service existe mais que les consommateurs pointent encore vers l'ancien nom, vous créez une partition réseau partielle. > * **Oublier de vérifier les certificats TLS** : le nouvel Ingress génère une nouvelle demande cert-manager. Surveillez l'apparition éventuelle de pods `cm-acme-http-solver-*` en attente. Si vous avez un doute sur la portée d'un renommage ou si vous souhaitez une revue de votre PR, contactez l'équipe DevOps à [devops@kaeyros-analytics.com](mailto:devops@kaeyros-analytics.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.