Documentation Oracle Cloud Infrastructure

Dépannage de DevOps

Utilisez les informations de dépannage pour identifier et résoudre les problèmes courants qui peuvent survenir lors de l'utilisation de DevOps.

Déploiement d'applications vers OKE

L'étape d'application du manifeste Kubernetes a échoué en raison de plusieurs erreurs.

Erreur d'autorisation :

Le cluster n'existe peut-être pas, ou le groupe dynamique et la stratégie sont manquants pour fournir à la ressource de pipeline l'accès aux autres ressources Oracle Cloud Infrastructure (OCI) dans le compartiment.

Vérifiez que les ressources OCI pertinentes existent et assurez-vous qu'un groupe dynamique a été créé pour la ressource de pipeline de déploiement OCI DevOps, de même qu'une stratégie permettant à ce groupe dynamique d'accéder aux ressources OCI applicables.

Par exemple, créez un groupe dynamique pour le pipeline de déploiement. Vous pouvez nommer le groupe dynamique DeployDynamicGroup et remplacer compartmentOCID par l'OCID du compartiment : All {resource.type = 'devopsdeploypipeline', resource.compartment.id = 'compartmentOCID'}

Créez une stratégie IAM pour autoriser le groupe dynamique à accéder à toutes les ressources : Allow dynamic-group DeployDynamicGroup to manage all-resources in compartment <compartment_name>

Reportez-vous à Stratégies IAM DevOps.

Champ de protocole manquant :

Le message d'erreur suivant peut être affiché : io.kubernetes.client.openapi.ApiException: class V1Status { apiVersion: v1 code: 500 details: null kind: Status message: failed to create typed patch object: .spec.template.spec.containers[name=\"helloworld\"].ports: element 0: associative list with keys has an element that omits key field \"protocol\" metadata: class V1ListMeta { _continue: null remainingItemCount: null resourceVersion: null selfLink: null } reason: null status: Failure }

Le manifeste Kubernetes doit comporter un champ de protocole là où un port de conteneur est défini.

Ce problème est un bug existant sur l'application côté serveur Kubernetes pour les versions de cluster antérieures à 1.20. Pour plus d'informations, reportez-vous aux problèmes 130 et 92332.

Ajoutez un champ de protocole là où un port de conteneur est défini.

Délai d'expiration du socket :

Message d'erreur possible : io.kubernetes.client.openapi.ApiException: java.net.SocketTimeoutException: connect timed out

Cette erreur peut survenir si l'adresse publique Kubernetes n'est pas accessible ou connectable.

L'adresse d'API Kubernetes doit être une adresse connectable valide. Pour obtenir une adresse IP publique valide, vous devez vérifier la configuration réseau du cluster. Reportez-vous aux exemples.

Le statut du déploiement a échoué en raison du délai d'expiration:

Ce problème peut survenir si le temps de déploiement de Kubernetes dépasse la durée limite de progression.

Par défaut, la durée limite de progression de Kubernetes est de 600 secondes. Reportez-vous à Durée limite de progression en secondes.

Si les pods du déploiement Kubernetes ne sont pas déployés dans la durée limite, ce message d'erreur apparaît dans les journaux de déploiement. Pour plus d'informations, reportez-vous à Déploiement échoué.

Consultez les journaux de ces pods sur le cluster.

Echec de l'audit de vulnérabilité

Echec de l'étape VulnerabilityAudit lors de la phase de build géré.

Configuration du fichier pom.xml non valide ou échec du traitement des fichiers pom.xml par le fichier JAR du client :

Le fichier JAR du client Maven Application Dependency Management (ADM) ne parvient pas à créer la nomenclature (charge utile pour la création de l'étape VulnerabilityAudit) en raison d'une configuration non valide du fichier pom.xml ou de l'échec du traitement des fichiers pom.xml par le fichier JAR du client.

  1. Corrigez et validez le fichier pom.xml.
  2. Ouvrez une demande de service.

Délai d'expiration ou échec de l'étape VulnerabilityAudit :

L'étape VulnerabilityAudit est créée mais n'atteint jamais le statut final en raison du délai d'expiration ou de l'échec de l'étape VulnerabilityAudit.

Ouvrez une demande de service concernant l'échec.

Erreur de validation

Une erreur de validation peut survenir si la valeur de knowledgeBaseId ou vulnerabilityCompartmentId saisie dans le fichier de spécification de build est incorrecte.

Vérifiez les valeurs fournies dans le fichier de spécification de build.

Stratégies IAM non définies :

L'étape VulnerabilityAudit peut échouer si aucune stratégie n'est définie pour autoriser le pipeline de build à accéder aux ressources ADM.

Définissez les stratégies permettant d'accéder aux ressources ADM.

Erreur du serveur :

Une erreur de serveur peut survenir en raison d'une coupure intermittente.

Ouvrez une demande de service.

Configuration de la connexion privée

L'exécution de build échoue systématiquement à différentes étapes.

L'exécution de build échoue à l'étape de provisionnement de l'accès privé :

Message d'erreur possible : échec de la configuration de l'accès privé en raison de subnetId ou nsgId non authentifié ou introuvable.

Cette erreur peut survenir si les stratégies Identity and Access Management (IAM) sont incorrectes ou si la valeur de subnetId ou nsgId indiquée pendant la configuration n'est pas valide.

Vous pouvez envisager les solutions suivantes en fonction de la cause de l'erreur :

  1. Ecrivez les stratégies IAM appropriées. Pour obtenir des exemples de stratégies, reportez-vous aux stratégies de build.
  2. Vérifiez que les valeurs subnetId et nsgId sont correctes.

L'exécution de build échoue systématiquement à l'étape de configuration de l'environnement logiciel:

Message d'erreur possible : impossible d'extraire le groupe de certificats du service de certificats pour la source de build <source> et caBundleId <identificateur Oracle Cloud (OCID) du package d'autorité de certification>.

Cette erreur peut survenir si la configuration de la stratégie IAM pour que le pipeline de build puisse accéder au certificat est incorrecte ou si vous avez configuré une valeur caBundleId incorrecte sur la ressource de connexion.

Vous pouvez envisager les solutions suivantes en fonction de la cause de l'erreur :

  1. Ecrivez les stratégies IAM appropriées. Pour obtenir des exemples de stratégies, reportez-vous aux stratégies de build.
  2. Vérifiez le fichier caBundleId et corrigez-le dans la ressource de connexion externe.

L'exécution de build échoue systématiquement à l'étape de téléchargement de la source:

Si l'URL est correcte et que le serveur de référentiel a installé un certificat auto-signé, vérifiez TLSVerifyConfiguration sur la ressource de connexion.

Vous pouvez également avoir configuré un serveur de référentiel pour lequel le certificat SSL n'est pas connu.

Suivez les étapes indiquées et configurez la vérification TLS dans la ressource de connexion externe :

  1. Obtenez le certificat de l'autorité de certification à l'aide de la commande echo -n | openssl s_client -connect <hôte>:<port> | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > CA.pem
  2. Téléchargez le certificat vers la ressource de package d'autorité de certification.
  3. Lors de la création d'une ressource de connexion externe, configurez TLSVerifyConfiguration en sélectionnant la ressource de package d'autorité de certification créée.

L'exécution de build échoue systématiquement à l'étape de téléchargement de la source:

Message d'erreur possible : impossible d'accéder au référentiel <URL du référentiel>/Echec de la connexion à <ID et numéro de port du référentiel>

Cette erreur peut survenir si l'URL de référentiel configurée dans l'un des éléments buildSource de buildStage n'est pas accessible à partir du programme d'exécution de build.

Vérifiez si l'URL de référentiel configurée est correcte et configurez l'accès privé si l'URL de référentiel est une adresse IP privée.

L'exécution de build échoue systématiquement à l'étape de configuration de l'environnement logiciel, de téléchargement de la source ou à n'importe quelle étape client du fichier de spécification de build:

L'un des messages d'erreur suivants peut être affiché :
  1. Erreur interne. Survient lors de l'échec de l'étape setup_software_env.
  2. Impossible d'accéder au référentiel. Survient lors de l'échec du téléchargement de la source.
  3. Erreur liée au réseau dans les journaux client.

Cela peut se produire si vous n'avez pas configuré correctement le réseau cloud virtuel (VCN).

Lorsque vous configurez un accès privé, le trafic sortant de la machine virtuelle d'exécution de build est contrôlé par le VCN. La résolution DNS (Domain Name System) interne des réseaux cloud virtuels n'est pas prise en charge pour l'accès privé. Utilisez les adresses IP pour communiquer avec les services hébergés sur le réseau privé. Les prérequis suivants doivent être respectés pour le VCN (sous-réseau) dans lequel vous configurez l'accès privé :

  1. Vous devez disposer d'une passerelle de service ou d'une passerelle NAT dans le réseau cloud virtuel configuré.
  2. Des règles de routage doivent être ajoutées de façon à accorder l'accès à tous les services OCI via l'une de ces passerelles. Si le code source ou les commandes du fichier de spécification de build ont besoin d'accéder à Internet, les règles appropriées doivent exister avant l'exécution du build. Cela est nécessaire car tout le trafic sortant du programme d'exécution de build transite par le réseau.

L'exécution du build échoue lors de l'exécution des commandes docker dans la spécification de build à partir de la phase de build géré avec un accès privé :

Cette erreur survient lorsque la phase de build géré est configurée avec un accès privé et que le fichier de spécification de build contient des commandes docker. Par exemple, le build docker échoue avec une erreur de résolution DNS ou une erreur d'expiration de connexion si le fichier docker contient des commandes accédant à Internet. De même, la commande docker run échoue avec une erreur de résolution DNS ou une erreur d'expiration de connexion lors de la tentative d'accès à Internet à partir du conteneur.

Afin de résoudre ce problème, utilisez --network host dans les commandes docker pour configurer le réseau de conteneur Docker correctement. Par exemple : 
docker build --network host -t hello-world:1.0
docker run --network host hello-world:1.0