Dépannage de Sitecore dans Docker / Blogs / Perficient

On m’a récemment demandé de fournir une session de dépannage des conteneurs Docker avec mes collègues, car la technologie des conteneurs prend le dessus sur le développement de Sitecore et l’outil d’échafaudage Headless SDK et XM Cloud l’utilisent pour fournir des kits de démarrage.

Une fois que vous voyez un message d’erreur, parfois peu explicatif, il vaut la peine de vérifier ces éléments de base avant d’approfondir le dépannage :

• Avez-vous exécuté Docker Desktop ? Plusieurs fois, j’ai dû redémarrer la machine et c’était le cas d’oublier d’exécuter l’application Docker Desktop
• La virtualisation du processeur est-elle activée sur votre machine ? Sinon, vous devrez peut-être accéder au BIOS/UEFI pour le modifier
• Tous les prérequis sont-ils installés ? Cela se produit parfois lorsque vous avez cloné un code source et essayez de l’exécuter immédiatement
• Docker Desktop s’exécute-t-il en mode Windows ? Parfois, l’application utilise par défaut les conteneurs Linux au redémarrage
• Les ports externes sont-ils occupés (port 443 et Solr) ?
• Avec quelle version de Docker Compose votre code s’exécute-t-il ? Assurer la conformité ou envisager une mise à niveau
• L’exécution de scripts Powershell est-elle limitée sur cette machine ?
• Un VPN d’entreprise gâche-t-il la mise en réseau de conteneurs ?
• Y a-t-il suffisamment de ressources disponibles ? Je conseillerais une machine avec un minimum de 32 Go de RAM et 1 To de SSD

En supposant que ce qui précède est correct, allons-y.

L’une des erreurs les plus fréquentes se produit après l’expiration du délai « En attente de CM pour devenir disponible… », semblable à celle ci-dessous :

Parfois, le message d’erreur peut vous demander ce qui ne va pas, comme dans la capture d’écran ci-dessus où l’on peut deviner que Sitecore CLI est manquant et dotnet tool install Sitecore.CLI la commande le corrige pour moi. Mais dans de nombreux autres cas, vous devez procéder comme suit :

• voir la sortie des journaux pour un conteneur défectueux, il y aura très probablement des traces d’un échec
• exécutez le terminal dans le contexte de ce conteneur et dépannez à partir de là, c’est-à-dire. curl localhost

Si les deux éléments ci-dessus ne vous sont pas disponibles, cela peut être dû au fait que le conteneur a été créé/démarré mais n’est pas encore en cours d’exécution/sain, selon son statut. Cela signifie qu’il dépend d’un autre conteneur, tel qu’il est configuré dans le fichier docker-compose, par exemple, ce conteneur dépend de CM pour devenir « sain », ce qui signifie répondre à sondes de santé:

depends_on:
  cm:
    condition: service_healthy

Vous ne devez pas commenter ou supprimer les dépendances, mais dans certains cas, des commentaires temporaires peuvent vous aider à avancer dans le dépannage. Utilisez ces références à bon escient pour dépanner les conteneurs le long de la chaîne de dépendance et trouver le coupable.

Circulation

Les kits de démarrage Windows Container utilisent Traefik comme proxy inverse pour vos conteneurs et toutes les requêtes adressées à votre cluster Sitecore y sont transmises et distribuées conformément aux règles. Il masque également les erreurs de n’importe quel conteneur spécifique de l’appelant, donc si vous devez reproduire une erreur, exécutez PowerShell dans son contexte :

docker exec -it powershell.exe

Et cela vous donnera accès au système de fichiers, y compris les journaux ainsi que la possibilité d’exécuter (et reproduire) toutes les commandes qu’il doit exécuter. Et comme indiqué précédemment, vous pouvez d’abord utiliser curl ou Invoke-WebRequest aux points de terminaison de vivacité et de préparation pour voir quelle erreur il génère, puis agir à partir de cela.

L’une des erreurs que vous pouvez voir avec Traefik est un certificat incorrect/manquant :

Pour en identifier la cause, cliquez sur le libellé d’erreur « Non sécurisé » (dans Chrome, d’autres navigateurs peuvent l’avoir formulé différemment, mais la conséquence reste la même), puis récupérez le nom d’hôte du certificat à comparer. Il pourrait y avoir deux raisons potentielles à cela.

Le premier est assez évident et découle d’un nom d’hôte demandé qui ne correspond pas au nom d’hôte du certificat. Vous devrez peut-être vérifier les certificats Traefik et les dossiers de configuration pour voir quel certificat est utilisé. Par exemple, si un certificat générique est en place, il sert n’importe quel nom d’hôte d’un niveau inférieur, mais pas plus que cela. Dans mon cas, un certificat générique pour xmcloudcm.localhost sera valable pour abc.xmcloudcm.localhost, xyz.xmcloudcm.localhost mais pas pour abc.zyz.xmcloudcm.localhost et non pour xmcloudcm.localhost nom d’hôte lui-même.

La deuxième raison est lorsque vous voyez le nom d’hôte du certificat comme TRAEFIK DEFAULT CERT – cela signifie que Traefik n’a pas réussi à extraire un fichier de certificat et sert son certificat intégré par défaut :

Si cela se produit, vous avez probablement mal orthographié le chemin ou il y a des problèmes avec les volumes mappés. Les certificats sont configurés à certs_config.yaml fichier, et les chemins sont locaux au conteneur Traefik, pas à la machine hôte :

tls:
  certificates:
    - certFile: C:\etc\traefik\certs\xmcloudcm.localhost.pem
      keyFile: C:\etc\traefik\certs\xmcloudcm.localhost-key.pem

Une fois que vous aurez corrigé les chemins, cela fonctionnera comme prévu.

Guide de dépannage

J’ai enregistré une vidéo dans laquelle je parcoure et explique les approches de dépannage de la configuration de vos conteneurs Docker locaux

J’espère que ceci vous aidera!