Lorsque vous déployez, démarrez, mettez à l'échelle horizontale (scale out) ou réduisez l'échelle horizontale (scale in) d'une application dans Enterprise Distributed Application Service (EDAS), la page Change Records assure le suivi de chaque étape du processus de modification. En cas d'échec, utilisez la page Change Details pour identifier l'étape défaillante et sa cause racine.
Identification de l'étape ayant échoué
-
Sur la page des détails de l'application, cliquez sur Change Records dans le volet de navigation de gauche.
Une modification échouée affiche Execution failed dans la colonne Change Status.
Repérez l'enregistrement de modification ayant échoué et cliquez sur View dans la colonne Actions.
-
Sur la page Change Details, cliquez sur l'étape ayant échoué (par exemple, Deploy) dans l'onglet Batch 1 Change. Si vous avez configuré un déploiement par lots multiples, la page affiche des onglets distincts tels que Batch 1 Change et Batch 2 Change. Cliquez sur l'onglet correspondant au lot ayant échoué.
Examinez le journal situé à droite de l'onglet pour identifier la cause racine.
Si le journal ne révèle pas clairement la cause, vérifiez les scénarios d'échec courants suivants.
Échec du contrôle de santé du port
Symptômes
Le processus de modification échoue à l'étape du contrôle de santé. Le port 65000, qu'EDAS utilise pour vérifier le démarrage de l'application, est inaccessible.
Causes
Conflit de port : Un autre processus occupe déjà le port 65000 au démarrage de l'application.
Échec du démarrage de Tomcat : Le conteneur Tomcat ne parvient pas à démarrer en raison d'une erreur de configuration ou de dépendance.
Solution
Consultez les journaux de démarrage de l'application pour repérer les exceptions. Recherchez des erreurs telles que
java.net.BindException: Address already in useou des erreurs de dépendances manquantes.En cas de conflit de port, arrêtez le processus qui occupe le port 65000 ou reconfigurez-le pour utiliser un autre port.
Corrigez l'erreur de démarrage sous-jacente et redéployez l'application.
Échec du contrôle de santé de l'URL
Symptômes
Le processus de modification échoue à l'étape du contrôle de santé. Lorsque vous configurez une URL de contrôle de santé, EDAS envoie une requête HTTP vers cette URL après le démarrage de l'application. Le contrôle n'est validé que si le code d'état HTTP 200 est reçu. Tout autre code d'état renvoyé dans le délai d'expiration de trois minutes entraîne l'échec du contrôle et l'arrêt du déploiement.
Causes
L'application ne parvient pas à démarrer, rendant l'URL de contrôle de santé indisponible.
L'URL de contrôle de santé configurée est incorrecte ou pointe vers un chemin inexistant.
Un filtre de requête, une règle de pare-feu ou un groupe de sécurité bloque les requêtes HTTP vers l'URL de contrôle de santé.
Solutions
Vérifiez le journal de démarrage de l'application pour confirmer que celle-ci a démarré sans erreur.
-
Assurez-vous que le chemin de l'URL de contrôle de santé est correct et que l'application renvoie une réponse 200 à ce chemin. Testez cela en exécutant une requête depuis l'hôte de l'application :
curl -I http://localhost:<port>/<health-check-path> Confirmez qu'aucun filtre de requête, règle de pare-feu ou groupe de sécurité ne bloque les requêtes HTTP entrantes vers l'URL de contrôle de santé.
Après avoir résolu le problème, redéployez l'application.
Erreur de disque plein
Symptômes
L'application reste bloquée pendant une période prolongée à une étape du processus de modification. Le journal de modification contient l'un des messages d'erreur suivants :
The [EDAS-10000] disk has no space available.No space left on device. Free space (for /home/admin) in bytes: 0exit 1.Cause
Dans la plupart des cas, les journaux métier de l'application consomment tout l'espace disque disponible.
Solutions
| Type de déploiement | Action |
|---|---|
| Cluster ECS | Connectez-vous à la console Elastic Compute Service (ECS) et supprimez les fichiers journaux inutiles du disque. |
| Application Docker dans un cluster Swarm | Reset the application. Cette action arrête, supprime et reconstruit le conteneur, ce qui libère l'espace disque occupé. |
Pour éviter que le problème ne se reproduise, configurez la rotation des journaux ou définissez une politique de rétention pour vos journaux d'application.
Rôle AliyunServiceRoleForAutoScaling manquant
Symptômes
Le processus de modification échoue car EDAS ne peut pas appeler Auto Scaling pour gérer les ressources.
Cause
Le rôle lié au service AliyunServiceRoleForAutoScaling n'est pas attribué à votre compte Alibaba Cloud. Ce rôle accorde à Auto Scaling les autorisations nécessaires pour accéder à Elastic Compute Service (ECS), Virtual Private Cloud (VPC) et à d'autres services requis.
Solution
Attribuez le rôle AliyunServiceRoleForAutoScaling à votre compte dans la console Auto Scaling, puis réessayez la modification. Pour plus d'informations, consultez Accorder des autorisations à Auto Scaling.