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 du service DevOps.

Déploiement d'applications vers OKE

Échec de l'étape d'application du manifeste Kubernetes en raison de diverses erreurs.

Erreur d'autorisation :

La grappe n'existe pas ou le groupe dynamique et la politique donnant à la ressource de pipeline l'accès aux autres ressources Oracle Cloud Infrastructure (OCI) du compartiment sont manquants.

Vérifiez si les ressources OCI pertinentes existent et si un groupe dynamique a été créé pour la ressource de pipeline de déploiement DevOps, avec une politique permettant à ce groupe dynamique d'accéder aux ressources OCI pertinentes.

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 politique GIA pour permettre au groupe dynamique d'accéder à toutes les ressources : Allow dynamic-group DeployDynamicGroup to manage all-resources in compartment <compartment_name>

Voir Politiques GIA pour DevOps.

Champ de protocole manquant :

Le message d'erreur suivant peut s'afficher : 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 partout où un port de conteneur est défini.

Ce problème est un bogue existant de l'application côté serveur Kubernetes pour une version de grappe inférieure à 1.20. Pour plus d'informations, voir les problèmes 130 et 92332.

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

Temporisation du connecteur logiciel :

Le message d'erreur suivant peut s'afficher : io.kubernetes.client.openapi.ApiException: java.net.SocketTimeoutException: connect timed out

Cette erreur peut survenir si le point d'extrémité public Kubernetes n'est pas accessible ou que la connexion à celui-ci est impossible.

Le point d'extrémité de l'API Kubernetes doit être une adresse valide permettant la connexion. Pour un point d'extrémité IP public valide, vous devez vérifier la configuration de réseau de la grappe; voir les exemples.

Le statut du déploiement échoue en raison d'une temporisation :

Cela peut se produire si le délai de déploiement de Kubernetes dépasse la date limite de progression.

Par défaut, le délai de progression pour Kubernetes est de 600 secondes. Voir Délai de progression en secondes.

Si les pods de déploiement K8s ne sont pas déployés avec succès avant l'expiration du délai, ce message d'erreur s'affiche dans les journaux de déploiement. Pour plus d'informations, voir Échec de déploiement.

Vérifiez les journaux de ces pods dans la grappe.

Échec de la recherche de vulnérabilités

L'étape VulnerabilityAudit échoue lors de l'étape de compilation gérée.

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 de gestion des dépendances d'application ne parvient pas à créer la nomenclature (charge utile pour la création de l'étape VulnerabilityAudit) en raison d'une configuration de fichier pom.xml non valide 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.

Temporisation ou échec à l'étape VulnerabilityAudit :

L'étape VulnerabilityAudit est créée, mais n'atteint jamais le statut final de réussite en raison d'une temporisation ou d'un échec à l'étape VulnerabilityAudit.

Ouvrez une demande de service pour un échec.

Erreur de validation :

Une erreur de validation peut survenir si une valeur knowledgeBaseId ou vulnerabilityCompartmentId incorrecte est entrée dans le fichier de spécification de compilation.

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

Politiques GIA non définies :

L'étape VulnerabilityAudit peut échouer si aucune politique n'est définie pour permettre au pipeline de compilation d'accéder aux ressources ADM.

Définissez des politiques pour l'accès aux ressources ADM.

Erreur du serveur :

Une erreur de service peut survenir en raison d'une panne intermittente.

Ouvrez une demande de service.

Configuration d'une connexion privée

L'exécution de la compilation échoue régulièrement à diverses étapes.

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

Le message d'erreur peut indiquer que la configuration de l'accès privé a échoué car subnetId ou de nsgId n'est pas authentifié ou est introuvable.

Cela peut se produire si les politiques du service de gestion des identités et des accès (GIA) sont incorrectes ou si les valeurs de subnetId ou nsgId indiquées lors de la configuration ne sont pas valides.

L'une des solutions suivantes peut être envisagée, en fonction de la cause de l'erreur :

  1. Écrivez des politiques GIA correctes. Pour obtenir des exemples de politique, voir Politiques de pipeline de compilation.
  2. Vérifiez que les valeurs subnetId et nsgId sont correctes.

L'exécution de la compilation échoue régulièrement à l'étape de configuration de l'environnement logiciel :

Le message d'erreur peut indiquer qu'il est impossible d'extraire l'ensemble de certificats du service de certificats pour la source de compilation <source> et caBundleId <identificateur Oracle Cloud (OCID) de l'ensemble AC>.

Cela peut se produire si la configuration de la politique GIA du pipeline de compilation pour accéder au certificat est incorrecte ou si vous avez configuré une valeur caBundleId incorrecte pour la ressource de connexion.

L'une des solutions suivantes peut être envisagée, en fonction de la cause de l'erreur :

  1. Écrivez des politiques GIA correctes. Pour obtenir des exemples de politique, voir Politiques de pipeline de compilation.
  2. Vérifiez le fichier caBundleId et corrigez-le dans la ressource de connexion externe.

L'exécution de la compilation échoue régulièrement à 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 avez peut-être configuré un serveur de référentiel dont 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 : echo -n | openssl s_client -connect <host>:<port> | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ca.pem
  2. Chargez le certificat dans la ressource d'ensemble de l'autorité de certification.
  3. Lors de la création d'une ressource de connexion externe, configurez TLSVerifyConfiguration en sélectionnant la ressource d'ensemble AC créée.

L'exécution de la compilation échoue régulièrement à l'étape de téléchargement de la source :

Le message d'erreur peut indiquer : Impossible d'accéder au référentiel <repo URL>/Échec de connexion à <repo ID and port number>

Cela peut se produire si l'URL du référentiel configurée dans un élément buildSource de buildStage n'est pas accessible à partir de l'exécuteur de compilation.

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

L'exécution de la compilation échoue régulièrement à l'étape de configuration de l'environnement logiciel ou de téléchargement de la source, ou à toute autre étape du client dans le fichier de spécification de compilation. :

L'un des messages d'erreur suivants peut s'afficher :
  1. Erreur interne. Se produit 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 du client.

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

Lorsque vous configurez l'accès privé, le trafic sortant de la machine virtuelle de l'exécuteur de compilation est contrôlé par le VCN. La résolution du système de noms de domaine (DNS) interne des réseaux en nuage virtuels n'est pas prise en charge pour l'accès privé. Utilisez des adresses IP pour communiquer avec les services hébergés dans le réseau privé. Les préalables suivants doivent être respectés pour le VCN (sous-réseau) dans lequel vous configurez l'accès privé :

  1. Une passerelle de service/NAT doit exister dans le réseau VCN configuré.
  2. Des règles de routage doivent être ajoutées pour permettre l'accès à tous les services OCI au moyen d'une de ces passerelles. Si le code source ou les commandes du fichier de spécification de compilation doivent accéder à Internet, les règles appropriées doivent exister avant l'exécution de la compilation. Cela est nécessaire car tout le trafic sortant de l'exécuteur de compilation passe par le réseau.

L'exécution de la compilation échoue lors de l'exécution des commandes Docker de la spécification de compilation à partir de l'étape de compilation gérée avec accès privé :

Cette erreur survient lorsque l'étape de compilation gérée est configurée avec un accès privé et que vous avez des commandes docker dans le fichier de spécification de compilation. Par exemple, la création du docker échoue avec une erreur de résolution DNS ou une erreur de temporisation de connexion si le fichier docker contient des commandes accédant à Internet. De même, l'exécution de Docker échoue avec une erreur de résolution DNS ou une erreur de temporisation de connexion lors de la tentative d'accès à Internet à partir du conteneur.

Pour résoudre ce problème, utilisez --network host dans les commandes docker pour configurer le réseau en conteneurs Docker de manière appropriée. Par exemple :
docker build --network host -t hello-world:1.0
docker run --network host hello-world:1.0