7.8. Dépannage du processus Source-to-Image

1. During the build configuration stageun pod de construction est utilisé pour créer une image de conteneur d'application à partir d'une image de base et du code source de l'application.
2. During the deployment configuration stageun pod de déploiement est utilisé pour déployer des pods d'application à partir de l'image du conteneur d'application qui a été construite lors de l'étape de configuration de la construction. Le module de déploiement déploie également d'autres ressources telles que des services et des itinéraires. La configuration du déploiement commence après la réussite de la configuration de la construction.
3. After the deployment pod has started the application podsles pannes d'application peuvent se produire dans les modules d'application en cours d'exécution. Par exemple, une application peut ne pas se comporter comme prévu bien que les modules d'application soient dans l'état Running. Dans ce cas, vous pouvez accéder aux modules d'application en cours d'exécution afin d'examiner les défaillances d'une application au sein d'un module.

1. Contrôler l'état de la construction, du déploiement et du pod d'application
2. Déterminer l'étape du processus S2I où le problème s'est produit
3. Examiner les journaux correspondant à l'étape échouée

Procédure

1. Surveillez l'état du pod tout au long du processus S2I afin de déterminer à quel stade une défaillance se produit :

   $ oc get pods -w  1

   1

   Utilisez -w pour surveiller les modifications apportées aux pods jusqu'à ce que vous quittiez la commande à l'aide de Ctrl C.

2. Examinez les journaux d'un pod qui a échoué pour y déceler les erreurs.

   • If the build pod fails, examinez les journaux du module de construction :

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

     Note

     Vous pouvez également consulter les journaux de la configuration de construction en utilisant oc logs -f bc/<application_name>. Les journaux de la configuration de construction comprennent les journaux du module de construction.

   • If the deployment pod failsle cas échéant, examinez les journaux du module de déploiement :

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

     Note

     Vous pouvez également consulter les journaux de la configuration de déploiement à l'aide de oc logs -f dc/<application_name>. Cette commande génère des journaux à partir du module de déploiement jusqu'à ce que ce dernier se termine avec succès. La commande affiche les journaux des modules d'application si vous l'exécutez après la fin du module de déploiement. Après la fin d'un module de déploiement, il est toujours possible d'accéder à ses journaux en exécutant la commande oc logs -f pod/<application_name>-<build_number>-deploy.

   • If an application pod fails, or if an application is not behaving as expected within a running application podpour ce faire, consultez les journaux du module d'application :

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

Procédure

1. Répertorie les événements relatifs à un module d'application spécifique. L'exemple suivant permet de récupérer les événements d'un module d'application nommé my-app-1-akdlg:

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

2. Examiner les journaux d'un module d'application :

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

3. Interroger des logs spécifiques dans un pod d'application en cours d'exécution. Les logs 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 nécessaire que pour les journaux qui ne sont pas envoyés à stdout.

   1. S'il est possible d'accéder à un journal d'application sans les privilèges de l'administrateur dans un module, concaténer le fichier journal comme suit :

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

   2. Si l'accès root est nécessaire pour consulter le journal d'une application, vous pouvez démarrer un conteneur de débogage avec les privilèges root, puis consulter le fichier journal à partir du conteneur. Démarrez le conteneur de débogage à partir de l'objet DeploymentConfig du projet. Les utilisateurs de pods s'exécutent généralement avec des privilèges non root, mais l'exécution de pods de dépannage avec des privilèges root temporaires peut s'avérer utile lors de l'investigation d'un problème :

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

      Note

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

4. Tester les fonctionnalités d'une application de manière interactive et exécuter des outils de diagnostic, dans un conteneur d'application avec un shell interactif.

   1. Démarrer un shell interactif sur le conteneur d'application :

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

   2. Tester les fonctionnalités de l'application de manière interactive à partir de l'interpréteur de commandes. Par exemple, vous pouvez exécuter la commande du point d'entrée du conteneur et observer les résultats. Ensuite, vous pouvez tester les modifications directement à partir de la ligne de commande, avant de mettre à jour le code source et de reconstruire le conteneur d'application par le biais du processus S2I.

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

      Note

      Les privilèges root sont nécessaires pour exécuter certains binaires de diagnostic. Dans ce cas, vous pouvez démarrer un pod de débogage 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 les binaires de diagnostic en tant que root à partir du pod de débogage.

5. Si les binaires de diagnostic ne sont pas disponibles dans un conteneur, vous pouvez exécuter les binaires de diagnostic d'un hôte dans l'espace de noms d'un conteneur en utilisant nsenter. L'exemple suivant exécute ip ad dans l'espace de noms d'un conteneur, en utilisant le binaire ip de l'hôte.

   1. Entrez dans une session de débogage sur le nœud cible. Cette étape instancie un pod de débogage appelé <node_name>-debug:

      $ oc debug node/my-cluster-node

   2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

   3. Déterminer l'ID du conteneur cible :

      # crictl ps

   4. Déterminer l'ID du processus du conteneur. Dans cet exemple, l'ID du conteneur cible est a7fe32346b120:

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

   5. Exécutez ip ad dans l'espace de noms du conteneur, en utilisant le binaire ip de l'hôte. Cet exemple utilise 31150 comme ID de processus du conteneur. La commande nsenter entre dans l'espace de noms d'un processus cible et exécute une commande dans son espace de noms. Comme le processus cible dans cet exemple est l'ID de processus d'un conteneur, la commande ip ad est exécutée dans l'espace de noms du conteneur à partir de l'hôte :

      # nsenter -n -t 31150 -- ip ad

      Note

      L'exécution des binaires de diagnostic d'un hôte dans l'espace de noms d'un conteneur n'est possible que si vous utilisez un conteneur privilégié tel qu'un nœud de débogage.