Planification de votre génération

Avant de commencer à générer des images avec IBM Cloud® Code Engine, découvrez les différentes options dont vous disposez pour votre génération.

Une génération, ou génération d'image, est un mécanisme que vous pouvez utiliser pour créer une image de conteneur à partir de votre code source. Code Engine prend en charge la génération à partir d'un Dockerfile et de Cloud Native Buildpacks.

Si vous avez une image qui existe dans un registre de conteneurs et que l'image a été construite avec un processeur non basé sur Intel, Code Engine ne peut pas exécuter votre image de conteneur. Code Engine utilise un processeur basé sur Intel. Vous pouvez créer votre propre image si vous utilisez un processeur Intel ( x86 ). Vous pouvez également choisir de laisser Code Engine gérer le processus de construction pour vous.

Code Engine fournit des méthodes de définition de ressource personnalisée (CRD). Pour plus d'informations, voir les méthodes de CRD source-image.

Préparez votre emplacement source

Pour permettre à Code Engine d'accéder à votre code source, vous devez le rendre disponible dans un référentiel Git ou dans un emplacement accessible sur votre poste de travail en local.

référentiel Git
Stockez votre code dans un dépôt Git, par exemple dans GitHub ou GitLab. Votre code peut être dans le niveau principal de votre référentiel ou dans un sous-répertoire. Si votre référentiel source n'est pas public, vous devez ajouter un accès à Code Engine.
Poste de travail en local
Stockez votre code sur votre poste de travail en local. Lorsque vous soumettez une génération qui extrait du code à partir d'un répertoire local, votre code source est compressé dans un fichier archive et téléchargé sur votre instance IBM Cloud Container Registry. L'image source est créée dans le même espace de nom que votre image de génération. Notez que vous ne pouvez cibler que IBM Cloud Container Registry pour vos générations locales. Vous pouvez choisir d'ignorer certains modèles de fichier à partir de votre code source à l'aide du fichier .ceignore, qui se comporte de la même manière qu'un fichier .gitignore. Par exemple, les entrées d'un fichier .ceignorepour une application node.js peuvent inclure node_moduleset.npm. Pour plus d'exemples de modèles de fichiers à ignorer, voir le dépôt GitHub.gitignore.

Choix d'une stratégie de génération

Code Engine peut générer votre image de conteneur à l'aide de l'une des stratégies suivantes.

Fichier Docker

Construction d'un fichier Docker qui utilise l'outil BuildKit outil. Pour utiliser cette stratégie, ajoutez un fichier Dockerfile à votre référentiel source. Ce fichier Dockerfile décrit les étapes nécessaires à la génération d'une image de conteneur à partir de votre référentiel source. Le fichier Dockerfile peut contenir les étapes permettant de copier des fichiers statiques de vos sources dans le conteneur pour être hébergés par un service Web, par exemple. Il peut compiler le code source qui est écrit dans le langage de votre choix et ajouter le contenu binaire qui en résulte à votre image de conteneur. Pour plus d'informations sur les générations de fichier Dockerfile, voir Ecrire un fichier Dockerfile pour Code Engine.

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. Pour augmenter les limites tarifaires, vous pouvez passer à un abonnement Docker Pro ou Team.

Cloud Native Buildpacks

Cloud Native Buildpack qui utilise Paketo pour inspecter votre dépôt de sources et détecter l'environnement d'exécution sur lequel votre code est basé et comment une image de conteneur est construite à partir de vos sources. Les packs de construction émettent des hypothèses concernant la structure de répertoire de vos référentiels source. Pour savoir comment structurer correctement votre référentiel source, voir les exemples fournis pour votre environnement d'exécution.

Exemples de fichier d'environnement d'exécution
Environnement d'exécution Version Exemples
Go 1.24.12 Aller chercher des échantillons.
Java 21.0.10 Java échantillons.
Node.js 24.14.0 Node.js échantillons.
PHP Hypertext Preprocessor 8.1.28 Exemples de PHP.
Python 3.11.14 Python échantillons.
Ruby 3.1.7 Ruby échantillons.
.NET Core 9.0.311 (.NET Core SDK),
9.0.13 (.NET Core Runtime)		 .NET Core échantillons.

Les images créées à l'aide de Cloud Native Buildpacks n'utilisent plus l'horodatage neutre de Jan, 1st 1980 comme horodatage de création de l'image. L'horodatage de la source d'entrée est utilisé comme horodatage de la création de l'image; par exemple, l'horodatage du commit Git du commit qui a été utilisé pour votre compilation.

La version d'un runtime spécifique pour un buildpack Paketo peut différer entre les régions pendant un court laps de temps lorsqu'une version mise à jour d'un buildpack est déployée dans les différentes régions IBM Cloud.

Définition de la taille de la génération

Code Engine classe les bâtiments dans les catégories suivantes : small, medium, large, xlarge, et xxlarge. Cette taille détermine la façon dont les coeurs d'UC, la mémoire et l'espace disque sont affectés à la génération. Une version plus petite est moins coûteuse, mais généralement plus lente car elle utilise moins de cœurs d'unité centrale. En outre, les besoins en mémoire et en espace disque de votre génération peuvent provoquer son échec si sa taille est plus petite.

Valeurs de taille de génération
Taille Fichier Docker Buildpacks
small
  • UNITÉ CENTRALE 0.5
  • Mémoire 2 Go
  • Disque 2 Go
  • UNITÉ CENTRALE 0.5
  • Mémoire 2 Go
  • Disque 2 Go
medium
  • UNITÉ CENTRALE 1
  • Mémoire 4 Go
  • Disque 4 Go
  • UNITÉ CENTRALE 1
  • Mémoire 4 Go
  • Disque 4 Go
large
  • UNITÉ CENTRALE 2
  • Mémoire 8 Go
  • Disque 8 Go
  • UNITÉ CENTRALE 2
  • Mémoire 8 Go
  • Disque 8 Go
xlarge
  • UNITÉ CENTRALE 4
  • Mémoire 16 Go
  • Disque 16 Go
  • UNITÉ CENTRALE 4
  • Mémoire 16 Go
  • Disque 16 Go
xxlarge
  • CPU 12
  • Mémoire 48 GB
  • Disque 48 GB
  • CPU 12
  • Mémoire 48 GB
  • Disque 48 GB

Si vous n'êtes pas certain de la taille à choisir, vous pouvez commencer par small ou medium. Si la génération échoue en raison d'un manque de mémoire ou d'espace disque, ou n'est pas assez rapide, vous pourrez passer à des tailles plus grandes.

Choix de votre registre d'images de conteneur

Code Engine extrait le code source à partir d'un référentiel Git ou d'un répertoire local, le génère, puis il insère (télécharge) l'image à un registre d'images de conteneur.

Vous pouvez utiliser des référentiels pour votre source et des registres pour votre image de conteneur qui sont publics ou privés. Vous pouvez également choisir de spécifier les détails du registre avec un secret de registre pour votre résultat de construction, ou vous pouvez choisir que Code Engine se charge de construire l'image pour vous à partir de votre source et de stocker l'image dans IBM Cloud Container Registry avec un accès automatique.

Choisissez votre méthode de construction

Dans les options de construction suivantes, Code Engine extrait le code source d'un dépôt Git ou d'un répertoire local, construit l'image du conteneur, puis pousse (télécharge) l'image du conteneur vers un registre. Vous pouvez choisir des dépôts et des registres publics ou privés. Si votre registre est privé, spécifiez les détails du registre avec un secret de registre pour votre sortie de compilation avec un accès fourni par l'utilisateur. Vous pouvez également demander à Code Engine de créer un accès pour stocker l'image dans IBM Cloud Container Registry pour vous avec un accès automatique.

Créer des configurations de construction

Dans ce scénario, Code Engine crée une configuration pour votre construction.

La création d'une configuration de construction ne crée pas d'image, mais crée la configuration pour construire une image. Vous pouvez créer une image à partir de la configuration en exécutant la compilation. La configuration de génération n'est pas validée ou utilisée pour créer une image tant que la génération n'est pas exécutée. La configuration de génération permet plusieurs générations ultérieures d'une image, par exemple lorsque des modifications sont appliquées au référentiel source.

Pour plus d'informations, reportez-vous aux rubriques suivantes.

Après avoir créé votre configuration de construction, vous pouvez l'exécuter.

Créer une image de conteneur avec des commandes de compilation autonomes

Pour savoir comment générer votre image de conteneur à l'aide d'une commande CLI unique Code Engine et créer l'image du conteneur sans créer de configuration de génération réutilisable, voir Création d'une image de conteneur avec des commandes de génération autonomes (CLI).

Construisez votre code et créez votre charge de travail

Lorsque vous créez une charge de travail à partir d'un code source local, le code source est emballé dans un fichier d'archive et téléchargé dans un espace de noms géré au sein de l'instance IBM Cloud Container Registry de votre compte. L'image est également stockée dans ce même espace de noms.

Pour élaborer votre code et créer votre charge de travail en une seule opération, consultez les rubriques suivantes.

référentiel Git
Fichier local

Etapes suivantes pour les générations

Vous recherchez d'autres exemples de code ? Consultez le répertoire Samples for IBM Cloud Code Engine GitHub.