Utilisation des applications dans Code Engine

Une application exécute votre code pour servir les demandes HTTP. Outre les demandes HTTP traditionnelles, IBM Cloud® Code Engine prend en charge les applications qui utilisent WebSockets comme protocole de communication. Le nombre d'instances en cours d'exécution d'une application est automatiquement augmenté ou réduit (jusqu'à zéro) en fonction des demandes reçues et de vos paramètres de configuration. Une application contient une ou plusieurs révisions. Une révision représente une version non modifiable des propriétés de configuration de l'application. Chaque mise à jour d'une propriété de configuration d'application crée une nouvelle révision de l'application.

Avant de commencer

Si vous souhaitez utiliser la console Code Engine, allez sur Code Engine overview.
Si vous souhaitez utiliser l'interface de ligne de commande, configurez votre environnement d'interface de ligne de commande Code Engine.
Planifiez et choisissez votre approche pour faire fonctionner votre code en tant que composant d'application Code Engine.
Vérifiez que votre application suit la méthodologie de l'application à 12 facteurs.

Pour les fonctions de sécurité fournies avec Code Engine, voir Code Engine et sécurité.

Code Engine fournit des méthodes de définition de ressource personnalisée (CRD). Pour plus d'informations, voir Méthodes CRD de service.

Vous ne savez pas quel type de charge de travail Code Engine créer? Voir Planification pour Code Engine.

Comment puis-je faire fonctionner mon code en tant que composant d'application Code Engine ?

Que votre code existe en tant que source dans un fichier local ou dans un dépôt Git, ou que votre code soit une image de conteneur qui existe dans un registre public ou privé, Code Engine vous offre un moyen rationalisé d'exécuter votre code en tant qu'application.

Si vous disposez d'une image de conteneur, conformément à la norme de l'Open Container Initiative(OCI), vous ne devez fournir qu'une référence à l'image, qui pointe vers l'emplacement de votre registre de conteneurs lorsque vous créez et déployez votre application. Vous pouvez déployer votre application avec une image dans un registre public ou un registre privé.
Si vous démarrez avec le code source qui réside dans un référentiel Git, vous pouvez choisir de laisser Code Engine prendre soin de construire l'image à partir de votre source et de déployer l'application avec une opération unique. Dans ce scénario, Code Engine télécharge votre image sur IBM Cloud® Container Registry. Pour en savoir plus, reportez-vous à la section Déploiement de votre application à partir du code source du référentiel. Si vous souhaitez plus de contrôle sur la génération de votre image, vous pouvez choisir de créer l'image avec Code Engine avant de créer et de déployer votre application.
Si vous démarrez avec le code source résidant sur un poste de travail en local, vous pouvez choisir de laisser Code Engine prendre soin de construire l'image à partir de votre source et de déployer l'application avec une commande CLI unique. Dans ce scénario, Code Engine télécharge votre image sur IBM Cloud® Container Registry. Pour en savoir plus, reportez-vous à la section Déploiement de votre application à partir du code source local avec l'interface de ligne de commande. Si vous souhaitez plus de contrôle sur la génération de votre image, vous pouvez choisir de créer l'image avec Code Engine avant de créer et de déployer votre application.

Une fois votre application déployée, vous pouvez également mettre à jour votre application déployée avec n'importe quelle méthode précédente, indépendamment de la façon dont vous avez créé ou mis à jour votre application.

Lorsque vous déployez votre application, la dernière version de votre image de conteneur référencée est téléchargée et déployée, sauf si une balise est spécifiée pour l'image. Si une balise est spécifiée pour l'image, l'image balisée est utilisée pour le déploiement.

L'image associée à votre révision d'application spécifique possède un code unique de registre de conteneur, et Code Engine utilise ce code pendant toute la durée de vie de votre révision d'application. Si vous créez une version plus récente d'une image avec la même balise que l'image d'origine, l'image d'origine est remplacée dans le registre de conteneur et devient non balisée. L'image la plus récente est balisée, et cette image plus récente a un résumé différent. Votre application Code Engine n'utilise pas cette image plus récente, parce qu'elle a un résumé différent de l'image référencée par la révision de l'application. Code Engine peut toujours créer de nouvelles instances de la révision de l'application tant que l'image non marquée, référencée à l'origine, existe toujours. Pour plus d'informations, voir Pourquoi Code Engine ne parvient-il pas à extraire une image?

L'adresse URL par défaut pour les applications est au format https://<appname>.<uuid>.<region>.codeengine.appdomain.cloud où appname est le nom de votre application, uuid est l'identifiant unique généré automatiquement et region est la région dans laquelle votre projet Code Engine réside. La partie UUID de l'adresse URL d'une application est au format aaaabbbbccc. L'application URL générée automatiquement persiste pendant le cycle de vie du projet de votre application.

Pour plus d'informations sur les noeuds finaux permettant d'accéder aux applications par région, voir Noeuds finauxCode Engine pour accéder aux applications.

Que dois-je savoir sur les ports des applications dans Code Engine?

Par défaut, Code Engine part de l'hypothèse que les applications sont à l'écoute des connexions entrantes sur le port 8080. En outre, Code Engine attribue à la variable d'environnement PORT la valeur du port sur lequel l'application est censée écouter. Si votre application doit écouter sur un port autre que le port 8080, déployez votre application depuis la console et spécifiez le port correct ou utilisez l'option --port sur la commande app create pour l'option. Pour plus d'informations sur les variables d'environnement définies par Code Engine, voir Variables d'environnement injectées automatiquement. Les ports suivants sont réservés par Code Engine: 8022, 8008, 8012, 9090, 9091 et 15090. Un seul port peut être exposé en tant que port d'écoute.

Les connexions entrantes vers Code Engine sur HTTP sur l'Internet utilisent le port 80. Les connexions entrantes vers Code Engine via HTTPS sur l'Internet utilisent le port 443

Si une analyse de port affiche plus de ports ouverts, voir Pourquoi mon analyse de port affiche-t-elle plus de ports ouverts que prévu?

Considérations relatives à la gestion HTTP

Lorsque vous travaillez avec des applications (ou des travaux), il est utile de connaître la gestion HTTP de base dans Code Engine.

Pour les connexions d'applications entrantes utilisant HTTP, les aspects de sécurité de la couche de transport (TLS) sont gérés automatiquement par Code Engine en dehors du code d'application. Le serveur HTTP de l'application doit s'occuper uniquement de la connectivité HTTP et non de la connectivité HTTPS. En particulier, Code Engine utilise Cloud Internet Services (CIS) dans IBM Cloud, qui est basé sur CloudFlare, comme système de prévention des intrusions (IPS) pour la protection DNS et DDOS sur la couche 4. La connexion TCP/IP établie sur l'IPS est détenue et gérée par Cloudflare. Pour plus d'informations, voir la documentation Cloudflare.
Les connexions Internet liées aux applications Code Engine sont automatiquement redirigées pour utiliser HTTPS.
Les connexions sortantes des applications vers d'autres applications Code Engine sont automatiquement protégées par TLS. Code Engine gère automatiquement cette connectivité, de sorte que le protocole (ou l'URL) utilisé est HTTP et non HTTPS.
Les connexions sortantes des applications vers des applications nonCode Engine , telles que l'Internet, utilisent HTTP ou HTTPS selon le protocole spécifié dans le code de l'application ou l'URL.
Les connexions sortantes provenant des travaux par lots utilisent le protocole HTTP ou HTTPS spécifié dans le code du travail ou l'URL. Ce comportement inclut les connexions entre les travaux par lots et les applications Code Engine .

Options de visibilité pour une application Code Engine

Avec Code Engine, vous pouvez déterminer le bon niveau de visibilité pour votre application en définissant les points de terminaison, ou les correspondances de domaine de système qui sont disponibles pour recevoir des requêtes.

Chaque application dispose d'un mappage de domaine de système interne qui est visible par tous les composants du même projet Code Engine, mais pas en dehors du projet. Outre le mappage de domaine de système interne, vous choisissez de rendre l'application visible sur l'Internet public ou sur le réseau privé IBM Cloud.

Pour une visibilité publique ou privée, l'application est exposée sur un point de terminaison HTTPS. Pour plus de détails sur le certificat TLS utilisé, voir Certificats TLS pour les projets Code Engine.

Vous pouvez déployer votre application avec les niveaux de visibilité suivants :

Visibilité des applications
Paramètre	Description
interne(projet)	Une application avec ce paramètre peut recevoir des demandes de composants dans le même projet Code Engine. La définition d'un point de terminaison interne (projet) signifie que votre application n'est pas accessible depuis l'internet public et que l'accès au réseau n'est possible qu'à partir d'autres composants Code Engine fonctionnant dans le même projet Code Engine. Ce noeud final est toujours activé.
public	Une application avec ce paramètre est exposée à l'Internet et à votre projet Code Engine . La définition d'un nœud final public signifie que votre application peut recevoir des demandes provenant de l'Internet public ou d'autres composants à l'intérieur de votre projet Code Engine . Ce paramètre est la valeur par défaut.
private	Une application avec ce paramètre est exposée au réseau privé IBM Cloud et à votre projet Code Engine . Définir un point de terminaison privé signifie que votre application n'est pas accessible depuis l'internet public et que l'accès au réseau n'est possible qu'à partir d'autres services IBM Cloud en utilisant des points de terminaison privés virtuels (VPE) ou des composants Code Engine qui s'exécutent dans le même projet.

Vous pouvez définir les paramètres de nœud final pour la visibilité d'une application à partir de la console ou avec l'interface de ligne de commande lorsque vous créez et déployez ou mettez à jour votre application.

Déploiement de votre application avec un nœud final public

Lorsque vous déployez une application, celle-ci est déployée par défaut de manière à pouvoir recevoir des requêtes de l'internet public ou des composants du même projet Code Engine. Dans ce cas, l'application est déployée avec un nœud final public.

Déploiement de votre application avec un noeud final privé

Vous pouvez définir la visibilité du nœud final pour votre application de sorte qu'elle soit déployée avec un nœud final privé. Définir un point de terminaison privé signifie que votre application n'est pas accessible depuis l'Internet public et que l'accès au réseau n'est possible que depuis d'autres services IBM Cloud à partir de points de terminaison privés virtuels (VPE) ou de composants Code Engine fonctionnant dans le même projet (cluster-local).

Par exemple, si votre solution se compose d'un composant qui s'exécute sur un cluster Kubernetes IBM Cloud Kubernetes Service dans votre propre nœud final privé virtuel et que vous souhaitez accéder à l'application Code Engine à partir du réseau privé IBM Cloud, vous pouvez définir la visibilité de l'application en mode privé. Lorsque la visibilité de l'application est réglée sur privé, l'application n'est pas accessible par l'internet public. L'application est toujours accessible à partir d'autres applications du projet.

Vous pouvez déployer votre application avec un nœud final privé pour que l'application soit uniquement exposée via le réseau privé IBM Cloud et ne soit pas exposée à l'Internet externe. L'application reste accessible par le biais de composants partagés depuis le réseau interne et le noeud final de l'application doit être sécurisé.

Avec l'interface de ligne de commande, définissez la visibilité du nœud final pour votre application de sorte qu'elle soit déployée avec un nœud final privé à l'aide de l'option --visibility=private sur la commande app create ou app update . Vous pouvez obtenir les URL disponibles pour votre application qui reflètent votre définition de nœud final à l'aide de la commande app get .

Dans la console, définissez la visibilité des points de terminaison pour votre application en utilisant le paramètre Endpoints lorsque vous créez votre application. Une fois votre application déployée, vous pouvez afficher et modifier ces paramètres de mappage de domaine système dans l'onglet Mappages de domaine de la page de votre application.

Pour plus d'informations sur la connexion sur les réseaux privés, voir Utilisation de nœuds finaux privés virtuels avec Code Engine.

Déploiement de votre application avec un nœud final de projet

Vous pouvez définir la visibilité du point de terminaison de votre application de manière à ce qu'elle soit déployée avec un point de terminaison interne (projet). La définition d'un point de terminaison réservé au projet signifie que votre application n'est pas accessible depuis l'internet public et que l'accès au réseau n'est possible qu'à partir d'autres composants Code Engine qui s'exécutent dans le même projet Code Engine. Ce noeud final est toujours activé. Les applications sont toujours accessibles par des composants partagés et doivent donc être sécurisées.

Par exemple, si votre solution consiste en plusieurs applications dans un projet, vous pouvez configurer votre solution de sorte que seule une de ces applications soit visible à partir de l'Internet afin qu'elle puisse gérer le trafic entrant. Cette application orientée vers le public peut déléguer le travail à d'autres applications de votre solution afin que ces autres applications n'aient pas besoin d'être visibles sur Internet.

Avec l'interface de ligne de commande, définissez la visibilité du nœud final pour votre application afin qu'elle soit déployée avec un nœud final de projet à l'aide de l'option --visibility=project sur la commande app create ou app update . Vous pouvez obtenir les URL disponibles pour votre application qui reflètent votre définition de nœud final à l'aide de la commande app get .

Options de déploiement d'une application Code Engine

Découvrez les options que vous pouvez spécifier lors du déploiement de votre application. Notez que les options peuvent varier entre la console et l'interface de ligne de commande.

Mémoire et UC

Lorsque vous déployez votre application, vous pouvez spécifier la quantité de mémoire et d'UC que votre application peut consommer. Ces quantités peuvent varier selon que votre application entraîne de nombreux calculs, nécessite beaucoup de mémoire ou est équilibrée.

Par défaut, 4 Go de mémoire et à 1 UC virtuelle (vCPU) sont affectés à votre application. Pour plus d'informations sur la sélection de la mémoire et de l'unité centrale, voir Combinaisons de mémoire et d'unité centrale prises en charge.

Déploiement de votre application avec des commandes et des arguments

Vous pouvez définir des commandes et des arguments pour votre application à utiliser lors de l'exécution.

Définissez des commandes et des arguments pour votre application en ajoutant les options --cmd et --arg à votre commande app create.

ibmcloud ce app create --name myapp --image icr.io/codeengine/hello --cmd /myapp --arg --debug

Pour plus d'informations sur l'utilisation de cmd et arg, voir Définition de commandes et d'arguments pour vos charges de travail Code Engine.

Création et exécution de votre application avec des variables d'environnement

Vous pouvez définir des variables d'environnement en tant que paires clé-valeur pouvant être utilisées par votre application lors de l'exécution.

Vous pouvez définir des variables d'environnement lorsque vous créez votre application ou lorsque vous mettez à jour une application existante à partir de la console ou via l'interface de ligne de commande.

Pour plus d'informations sur la définition de variables d'environnement, voir Utilisation de variables d'environnement.

Code Engine injecte automatiquement certaines variables d'environnement dans l'application. Pour plus d'informations sur les variables d'environnement injectées automatiquement, voir Variables d'environnement injectées automatiquement.

Création et exécution de votre application lors de l'utilisation de secrets et de mappes de configuration

Dans Code Engine, les secrets et les mappes de configuration peuvent être consommées par votre application à l'aide de variables d'environnement.

Les secrets et les mappes de configuration sont des paires clé-valeur. Lorsqu'elles sont mappées à des variables d'environnement, les relations NAME=VALUE sont définies de telle sorte que le nom de la variable d'environnement correspond à la "clé" de chaque entrée de ces mappes, et la valeur de la variable d'environnement est la "valeur" de cette clé.

Votre application peut utiliser des variables d'environnement pour référencer intégralement une mappe de configuration (ou un secret) ou référencer des clés individuelles dans une mappe de configuration (ou un secret).

Pour plus d'informations, voir Référencement de secrets à l'aide de variables d'environnement et Référencement de mappes de configuration à l'aide de variables d'environnement.

Remarques relatives aux quotas d'application

Lorsque vous utilisez des applications, des fonctions et des travaux par lots, ces ressources s'exécutent dans le contexte d'un projet Code Engine. Les quotas de ressources sont définis par projet et des limites s'appliquent aux applications, aux fonctions et aux travaux par lots.

Pour plus d'informations sur les limites dans Code Engine, voir Limites et quotas pour Code Engine.

Etapes suivantes

Maintenant que vous connaissez les concepts clés de l'utilisation des applications Code Engine, êtes-vous prêt à déployer et à utiliser des applications? Consultez

Pour plus d'informations sur l'utilisation des applications, voir