Résolution d'un problème de limite de mémoire lors de la génération

Voir La génération échoue lorsque la limite de mémoire est dépassée pour des informations relatives à la résolution.

Résolution d'un problème de registre de conteneur lors de la génération

Dans ce scénario, un secret de registre permettant d'accéder au registre de votre conteneur n'existe pas ou le secret n'est pas correct.

1. Déterminez le secret utilisé. Utilisez la commande ibmcloud ce build get pour afficher le secret de registre utilisé.

2. Déterminez si une clé .dockerconfigjson existe. Utilisez la commande ibmcloud ce secret get pour le secret de registre. Notez que les données du secret sont codées en base64 et ne sont pas directement visibles ; toutefois, le secret contient des données d'identification. Dans la sortie de la commande, vérifiez la section Data. Elle doit contenir une clé appelée .dockerconfigjson. Si la clé .dockerconfigjson ne figure pas dans la section, ce secret ne convient pas pour l'authentification auprès d'un registre de conteneur et vous devez créer un secret correct et y faire référence dans la génération. Pour plus d'informations, voir Ajout d'un accès à un registre de conteneur privé.

   Exemple de sortie

   $ ibmcloud code-engine secret get -n <REGISTRY_SECRET>
   Getting secret <REGISTRY_SECRET>...
   OK
   
   Name:        <REGISTRY_SECRET>
   ID:          <REGISTRY_SECRET_ID>
   Project:     <PROJECT_NAME>
   Project ID:  <PROJECT_NAMESPACE>
   Age:         8s
   Created:     2021-02-12T10:26:59-06:00
   
   Data:
   ---
   .dockerconfigjson: <BASE64_STRING>
   

3. Si la clé .dockerconfigjson existe, décodez cette chaîne codée en base64 en utilisant la commande suivante :

   echo "<BASE64_STRING>" | base64 -d
   {"auths":{"<REGISTRY>":{"username":"<USERNAME>","password":"<PASSWORD>","auth":"<AUTH>"}}}
   

   La sortie de cette commande contient généralement une clé <REGISTRY>.

4. Vérifiez les informations suivantes au sujet de la clé :

   a. Examinez la valeur <REGISTRY>. Cette valeur doit correspondre à l'image de la génération.

   • Si le nom de l'image est sous IBM Cloud Container Registry, par exemple us.icr.io/aNamespace/anImage, <REGISTRY> doit être us.icr.io.

   • Si le nom de l'image est docker.io/aNamespace/aRepository ou /aNamespace/aRepository sans nom d'hôte, la génération utilise alors Docker Hub. Dans ce cas, <REGISTRY> doit être https://index.docker.io/v1/.

   b. Examinez la valeur <USERNAME>. Si le registre est un IBM Cloud Container Registry, la clé d'API doit être utilisée pour l'authentification. Le <USERNAME> doit être iamapikey et le mot de passe doit être une clé d'API. Pour connaître les étapes de création de la clé d'API, voir Automatisation de l'accès à IBM Cloud Container Registry.

   c. Les données d'identification doivent être validées. IBM Cloud® Identity and Access Management (IAM) permet d'affecter des droits d'accès de manière précise. Par exemple, un ID de service avec accès à un espace de nom IBM Cloud Container Registry et les droits d'extraction d'images, peut ne pas être autorisé à envoyer des images. Or, ces droits sont requis dans ce cas.

5. Après avoir déterminé les modifications requises, créez un secret de registre de conteneur qui utilise les valeurs corrigées. Utilisez la commande ibmcloud ce secret create --format ; par exemple,

   ibmcloud ce secret create --format registry --name <REGISTRY_SECRET> --server <REGISTRY_SERVER> --username <USERNAME> --password <PASSWORD>
   

6. Mettez à jour la génération pour faire référence au nom de votre secret de registre.

   a. Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de génération afin d'utiliser le nom de votre secret de registre ; par exemple

   ibmcloud ce build update --name <BUILD_NAME> --registry-secret <REGISTRY_SECRET>
   

   b. Utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Résolution d'un problème de fichier Dockerfile introuvable lors de la génération

Une génération de fichier Docker a besoin d'un fichier Dockerfile qui spécifie de quelle façon l'image de conteneur doit être générée. Si le référentiel source ne contient pas un tel fichier, vous devez le fournir ou envisager d'utiliser des packs de construction comme stratégie de génération. Pour plus d'informations, voir Planification de votre génération.

1. Si le fichier Dockerfile existe mais avec un nom différent ou s'il ne figure pas dans le répertoire racine, d'autres paramètres doivent être spécifiés dans la génération.

   • Si le fichier Dockerfile ne figure pas dans le répertoire racine du référentiel source, vous devez spécifier l'argument --context-dir et fournir le chemin d'accès au répertoire contenant le fichier Dockerfile.
   • Si le fichier Dockerfile porte un nom autre que Dockerfile, vous devez spécifier l'argument --dockerfile et fournir le nom de votre fichier Dockerfile.

2. Mettez à jour la génération afin d'utiliser les options --context-dir ou --dockerfile selon les besoins.

   a. Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de génération afin d'utiliser les options --context-dir ou --dockerfile selon vos besoins. Par exemple :

   ibmcloud ce build update --name <BUILD_NAME> [--context-dir <CONTEXT_DIR>] [--dockerfile <DOCKERFILE_NAME>]
   

   b. Utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

La résolution de la limite de quota IBM Cloud Container Registry est atteinte lors de la génération

IBM Cloud Container Registry comporte deux plans de service, un plan gratuit et un plan standard. Pour le plan gratuit, IBM Cloud Container Registry applique des limites strictes, en particulier sur la taille d'image totale qui peut être stockée (500 Mo). Pour le plan standard, vous pouvez configurer les quotas. Pour plus d'informations, voir A propos d'IBM Cloud Container Registry.

1. Exécutez l'une des actions suivantes :

   • Supprimez les images inutilisées de l'espace de nom IBM Cloud Container Registry pour augmenter l'espace disponible.
   • Passez du plan gratuit au plan standard.
   • Augmentez les quotas de l'espace de nom IBM Cloud Container Registry.

   L'URL d'image est incluse dans le message d'erreur pour vous aider à identifier l'espace de nom IBM Cloud Container Registry qui est affecté. L'espace de nom peut se trouver dans un autre compte IBM Cloud que votre projet IBM Cloud Code Engine.

2. Une fois les actions correctives terminées, utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Résolution d'un problème de source de génération incorrecte

Cette erreur se produit généralement si la source de génération ne se trouve pas dans le répertoire racine du référentiel Git, mais dans un répertoire enfant. Si la source de génération ne réside pas dans le répertoire racine, indiquez l'emplacement dans la génération.

1. Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de génération afin d'utiliser l'option --context-dir pour spécifier le chemin d'accès à la source dans le référentiel Git. Par exemple :

   ibmcloud ce build update --name <BUILD_NAME> --context-dir <CONTEXT_DIR>
   

2. Utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Résolution d'un problème dû aux limites de débit du concentrateur Docker

Lorsque vous tirez une image de Docker Hub pour l'utiliser avec des applications ou des travaux dans Code Engine, tenez compte des limites de taux de Docker pour les utilisateurs du plan gratuit (non authentifiés). Vous risquez d'être confronté à des limites d'extraction, avec réception d'une erreur 429 indiquant que vous avez atteint votre limite de débit d'extraction. Si vous recevez cette erreur, essayez l'une des solutions suivantes.

• Augmentation des limites de débit. Vous pouvez vous authentifier avec Docker Hub ou mettre à niveau votre compte vers un abonnement Docker Pro ou Team, si nécessaire.

• Extrayez l'image générée de Docker Hub et publiez l'image dans un registre différent, tel que IBM Cloud® Container Registry. Ensuite, extrayez votre image du nouvel emplacement. Code Engine prend en charge le référencement d'un secret unique. Si l'image de base de votre génération Dockerfile est extraite d'un registre différent de celui dans lequel l'image générée est publiée et que les deux registres requièrent une authentification, vous pouvez utiliser kubectl pour créer un secret Kubernetes de type kubernetes.io/dockerconfigjson qui contient des données d'identification pour les deux registres. Pour plus d'informations sur l'utilisation des données d'identification d'accès pour les deux registres, voir la documentationKubernetes sur l'extraction d'une image à partir d'un référentiel privé.

Résolution d'un problème de source de génération non prise en charge par les packs de construction

Pour vérifier si votre référentiel source de génération est pris en charge dans Code Engine, voir Choix d'une stratégie de génération pour les environnements d'exécution pris en charge. Si votre langage est répertorié, vérifiez les exemples liés et prenez soin de structurer correctement vos sources afin de permettre aux packs de construction de les détecter et les générer. Si vous ne pouvez pas trouver un pack de construction approprié pour votre source ou que la méthode standardisée d'exécution de la génération par les packs de construction ne répond pas à vos besoins, vous pouvez spécifier un fichier Dockerfile, décrire manuellement la génération du conteneur puis utiliser la stratégie de génération dockerfile dans la configuration de génération.

Résolution d'un problème lié à la génération de fichier Docker

Si l'échec de l'étape de génération et d'envoi n'est pas lié à la mémoire, à un secret de registre de conteneur ou à un fichier Dockerfile, il s'agit probablement d'un problème lié à la génération de fichier Docker. Il peut s'agir d'une erreur dans le fichier Dockerfile lui-même, par exemple, d'une erreur de syntaxe ou de l'exactitude de l'opération qu'il effectue. Le problème peut également se trouver dans votre code source, qui risque de ne pas être compilé, par exemple, si le code Java est inclus.

Si vous avez généré correctement votre projet en local mais que le même code source n'est pas généré dans Code Engine, il est possible que des fichiers disponibles en local ne se trouvent pas dans votre référentiel Git. Par exemple, pour les projets Node.js, il est courant d'exécuter la commande npm install en local pour que les dépendances de projet soient téléchargées et placées dans le répertoire node_modules du répertoire de projet. Il est conseillé d'inclure le répertoire node_modules dans le fichier.gitignore afin de limiter la taille du dépôt Git. Une erreur fréquente est d'oublier d'exécuter en plus la commande npm install (ou npm ci) dans le fichier Dockerfile. Une compilation de Docker que vous exécutez localement peut accéder au répertoire local node_modules, si vous copiez l'ensemble du projet dans le conteneur, par exemple, en utilisant la commande COPY . /app dans le fichier Docker. Toutefois, la génération Code Engine s'exécute à partir d'un référentiel Git qui vient d'être réservé et ne peut pas accéder au répertoire node_modules. Vous devez donc exécuter la commande npm install (ou npm ci) dans le fichier Dockerfile lors de la génération.

Une bonne pratique consiste à inclure des répertoires comme node_modules dans un fichier.dockerignore afin que la version Docker que vous exécutez localement se comporte de la même manière que la version Code Engine.

Les limitations de sécurité constituent une autre cause expliquant que la génération d'un projet aboutisse localement mais échoue dans Code Engine. Comme pour les applications et les travaux par lots, Code Engine ne permet pas les opérations système arbitraires dans le cluster Code Engine. De toute façon, la plupart des opérations système ne sont pas pertinentes pour les générations Docker. Cependant, Code Engine n'autorise pas l'ouverture de sockets de serveur pour les ports privilégiés. La plage est comprise entre 0 to 1023. Par exemple, si vous générez une application Web et que votre génération inclut une étape de test impliquant un serveur d'applications Web, vous devez utiliser des ports avec des numéros plus élevés pour ce serveur.