8.7. Dépannage du processus Source-à-Image

1. Au cours de l’étape de configuration de la construction, un module de construction est utilisé pour créer une image conteneur d’application à partir d’une image de base et d’un code source de l’application.
2. Au cours de la phase de configuration de déploiement, un pod de déploiement est utilisé pour déployer des pods d’application à partir de l’image du conteneur de l’application qui a été construit dans l’étape de configuration de construction. Le module de déploiement déploie également d’autres ressources telles que les services et les itinéraires. La configuration de déploiement commence après le succès de la configuration de construction.
3. Après que la pod de déploiement a commencé les pods d’application, des défaillances d’application peuvent se produire dans les pods d’application en cours d’exécution. À titre d’exemple, une application peut ne pas se comporter comme prévu même si les pods d’application sont dans un état d’exécution. Dans ce scénario, vous pouvez accéder aux pods d’application en cours d’exécution pour enquêter sur les échecs de l’application dans un pod.

1. Contrôlez l’état de la construction, du déploiement et de la pod d’application
2. Déterminer l’étape du processus S2I où le problème s’est produit
3. Journaux de révision correspondant à l’étape échouée

Procédure

1. Attention à l’état de la gousse tout au long du processus S2I pour déterminer à quel stade une défaillance se produit:

   $ oc get pods -w  

   1

   Copy to Clipboard Toggle word wrap

   1

   Utilisez -w pour surveiller les pods pour détecter les modifications jusqu’à ce que vous quittez la commande en utilisant Ctrl+C.

2. Examinez les journaux d’un pod échoué pour détecter les erreurs.

   • En cas d’échec de la gousse de construction, consultez les journaux de la gousse de construction:

     $ oc logs -f pod/<application_name>-<build_number>-build

     Copy to Clipboard Toggle word wrap
     Note

     Alternativement, vous pouvez consulter les journaux de la configuration de construction en utilisant oc logs -f bc/<application_name>. Les journaux de configuration de la configuration de construction incluent les journaux à partir du groupe de construction.

   • En cas d’échec du module de déploiement, consultez les journaux de la pod de déploiement:

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     Copy to Clipboard Toggle word wrap
     Note

     Alternativement, vous pouvez consulter les journaux de la configuration de déploiement en utilisant oc logs -f dc/<application_name>. Cette sortie se connecte à partir de la pod de déploiement jusqu’à ce que la pod de déploiement se termine avec succès. La commande sort les journaux à partir des pods de l’application si vous l’exécutez une fois que la pod de déploiement est terminée. Après la fin d’un module de déploiement, ses journaux peuvent toujours être accessibles en exécutant oc logs -f pod/<application_name>-<build_number>-deploy.

   • En cas d’échec d’un pod d’application ou si une demande ne se comporte pas comme prévu dans un pod d’application en cours d’exécution, examinez les journaux de la pod de la demande:

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

     Copy to Clipboard Toggle word wrap

Procédure

1. Liste des événements relatifs à un pod d’application spécifique. L’exemple suivant récupère les événements pour un pod d’application nommé my-app-1-akdlg:

   $ oc describe pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

2. Consulter les journaux d’un pod d’application:

   $ oc logs -f pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

3. Interrogez des journaux spécifiques dans un pod d’application en cours d’exécution. Les journaux qui sont envoyés à stdout sont collectés par le framework OpenShift Logging et sont inclus dans la sortie de la commande précédente. La requête suivante n’est requise que pour les journaux qui ne sont pas envoyés à stdout.

   1. Lorsqu’un journal d’application peut être consulté sans privilèges root dans un pod, concaténer le fichier journal comme suit:

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap

   2. Lorsque l’accès root est nécessaire pour afficher un journal de l’application, vous pouvez démarrer un conteneur de débogage avec des privilèges root, puis afficher le fichier journal à partir du conteneur. Démarrez le conteneur de débogage à partir de l’objet DeploymentConfig du projet. Les utilisateurs de Pod fonctionnent généralement avec des privilèges non-root, mais l’exécution de modules de dépannage avec des privilèges racine temporaires peut être utile lors de l’enquête sur les problèmes:

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap
      Note

      Il est possible d’accéder à un shell interactif avec un accès root dans le pod debug si vous exécutez oc debug dc/<deployment_configuration> --as-root sans ajouter -- <command>.

4. Tester la fonctionnalité de l’application de manière interactive et exécuter des outils de diagnostic, dans un conteneur d’application avec une coque interactive.

   1. Démarrez un shell interactif sur le conteneur de l’application:

      $ oc exec -it my-app-1-akdlg /bin/bash

      Copy to Clipboard Toggle word wrap
   2. Tester la fonctionnalité de l’application de manière interactive à partir de l’intérieur de la coque. À titre d’exemple, vous pouvez exécuter la commande point d’entrée du conteneur et observer les résultats. Ensuite, testez les modifications de la ligne de commande directement, avant de mettre à jour le code source et de reconstruire le conteneur de l’application via le processus S2I.

   3. Exécutez les binaires de diagnostic disponibles dans le conteneur.

      Note

      Les privilèges racine sont nécessaires pour exécuter certains binaires de diagnostic. Dans ces situations, vous pouvez démarrer un pod debug avec un accès root, basé sur l’objet DeploymentConfig d’un pod problématique, en exécutant oc debug dc/<deployment_configuration> --as-root. Ensuite, vous pouvez exécuter des binaires diagnostiques comme racine à partir de l’intérieur de la gousse de débogage.