Migration des applications Cloud Foundry vers la foire aux questions Code Engine

Réponses aux questions courantes sur la migration de vos applications Cloud Foundry vers Code Engine.

Puis-je utiliser une URL personnalisée avec Code Engine ?

Oui. Vous pouvez associer votre propre URL à une application Code Engine en créant un mappage de domaine personnalisé à partir de la console Code Engine. Vous pouvez également attribuer une adresse personnalisée URL par l'intermédiaire d'un fournisseur d'accès à Internet, par exemple IBM Cloud Internet Services. Pour plus d'informations sur le déploiement d'une application avec un domaine personnalisé via IBM Cloud Internet Services, voir Configuration d'une application hautement disponible. Pour plus d'informations sur le déploiement d'une application avec un domaine personnalisé via Cloud Internet Services (CIS), voir Obtention d'un domaine personnalisé, de son certificat TLS et de sa clé privée.

Mon application contient une route spécifique. Puis-je utiliser la même route?

Vous pouvez utiliser la même route ou le même domaine personnalisé tant que vous le contrôlez. Si la route provient d'une autre source, par exemple une route fournie par IBM, telle que mybluemix.net, vous devez utiliser le domaine fourni par Code Engine ou mapper un nouveau domaine personnalisé à votre application.

Puis-je arrêter mon application?

Vous ne pouvez pas arrêter votre application directement, mais vous pouvez empêcher votre application de recevoir du trafic en définissant sa visibilité sur project et en lui permettant de passer à 0. Pour plus d'informations, voir Comment puis-je empêcher mon application de recevoir du trafic?

Pourquoi ai-je autant d'instances d'application?

Lorsque vous mettez à jour votre application, Code Engine crée automatiquement une nouvelle révision. Lorsque la révision est disponible, le trafic est acheminé vers les nouvelles instances. Pendant que la révision augmente et que le trafic y est transféré, l'instance d'application d'origine continue de gérer le trafic. Lorsque la révision est mise à l'échelle et que tout le trafic y est acheminé, l'application d'origine est réduite. Votre application est également automatiquement mise à l'échelle selon les besoins du trafic. Revenez ultérieurement pour vous assurer que votre application exécute le nombre correct d'instances. Pour plus d'informations, voir Configuration de la mise à l'échelle d'application.

Pourquoi mes applications sont-elles lentes à répondre ?

Votre application passe à zéro par défaut et peut donc être plus lente à répondre lorsqu'elle repasse à l'échelle supérieure. Vous pouvez modifier ce comportement en mettant à jour votre application et en définissant la mise à l'échelle minimale sur 1dans la console ou depuis l'interface de ligne de commande.

Par exemple, pour définir la mise à l'échelle minimale sur 1pour une application appeléemyapp à partir de l'interface de ligne de commande,

ibmcloud ce app update --name myapp --min-scale 1

Une fois l'application mise à jour, une seule instance est toujours en cours d'exécution. Sachez que des frais peuvent s'appliquer. Pour plus d'informations, voir Tarification de Code Engine.

Puis-je acheminer des demandes vers une instance d'application spécifique ?

Non, cette fonctionnalité n'est pas actuellement prise en charge. Vous pouvez approximer cette fonctionnalité en utilisant le fractionnement du trafic Knative. Pour plus d'informations sur l'utilisation de Knative avec Code Engine, voir Utilisation de Knative avec Code Engine.

J'utilise un équilibreur de charge global avec mon application Cloud Foundry. Puis-je le migrer vers Code Engine?

Oui, vous pouvez mettre à jour votre équilibreur de charge global pour qu'il pointe vers votre application Code Engine, si vous pouvez accéder à la chaîne de certificats et à la clé privée correspondante. Les étapes suivantes supposent que vous utilisez Cloud Internet Services (CIS); toutefois, vous pouvez adapter ces étapes pour votre propre équilibreur de charge global.

Ces étapes utilisent la console.

  1. Créez un mappage de domaine pour votre application. Lorsque vous créez votre mappage de domaine, fournissez votre clé privée et la chaîne de certificats complète du ou des domaines. Pour plus d'informations, voir Configuration de mappages de domaines personnalisés pour votre application. Attendez que les mappages de domaine de tous les projets affichent l'état Ready.

  2. Ouvrez les détails de chaque mappage de domaine et enregistrez la valeur CNAME, par exemple, custom.<your-random-id>.us-south.codeengine.appdomain.cloud ou custom.<your-other-random-id>.us-east.codeengine.appdomain.cloud.

  3. Accédez à la page des détails de chaque application et sélectionnez l'onglet Mappages de domaine, puis sélectionnez No external system domain mapping dans la section des mappages de domaine système. Cette étape garantit que vos applications ne sont accessibles que via les domaines personnalisés lorsqu'elles sont appelées depuis l'extérieur de ce projet.

  4. Dans votre instance Cloud Internet Services (CIS), accédez à Reliability. > Equilibreurs de charge globaux > Pools d'origines et éditez les pools d'origines existants en remplaçant l'adresse d'origine par l'adresse CNAME que vous avez enregistrée précédemment.

Votre équilibreur de charge global pointe maintenant vers votre application Code Engine.

Mon application a-t-elle besoin de suivre des spécifications?

Votre application doit suivre la méthodologie de l'application à 12 facteurs.

Quels types de charges de travail sont disponibles avec Code Engine ?

Code Engine prend en charge deux types de charges de travail : les applications et les travaux par lots.

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.

Un job exécute une ou plusieurs instances de votre code exécutable en parallèle. Contrairement aux applications qui gèrent les demandes HTTP, les travaux sont conçus pour s'exécuter une seule fois et prendre fin. Lorsque vous créez un travail, vous pouvez spécifier les informations de configuration de charge de travail qui sont utilisées à chaque fois que le travail est exécuté.

Détermination du type de charges de travail que vous souhaitez

La plupart des applications de Cloud Foundry peuvent migrer vers Code Engine. Cependant, si votre application Cloud Foundry n'attend pas une requête HTTP entrante, alors l'option des travaux est probablement le meilleur choix à faire. Pour plus d'informations et exemples, voir laPlanification de Code Engine.

J'utilise des fichiers manifestes. Existe-t-il des options similaires avec Code Engine ?

Si vous utilisez des fichiers manifestes pour vos applications Cloud Foundry, mappez vos attributs de manifeste aux fonctions Code Engine ou à l'option de l'interface de ligne de commande correspondantes.

CodageMarkdown pour les tableaux
Attribut de manifeste Code Engine équivalent sur les commandesibmcloud ce app create ouapp update
command Option --command
disk_quota Implicitement défini par Code Engine.
docker Pas nécessaire dans Code Engine.
health-check-http-endpoint Pas nécessaire dans Code Engine. Par défaut, une analyse TCP est utilisée pour savoir quand l'application est saine et prête.
health-check-invocation-timeout Pas nécessaire dans Code Engine.
instances Options --min-scale et --max-scale
memory Option --memory
metadata Non pris en charge actuellement.
no-route Avec l'option --cluster-local, l'application est toujours accessible à partir d'autres charges de travail au sein du projet, mais ne comprend pas de site Internet URL associé à l'application.
path Non applicable actuellement.
processes Pas nécessaire dans Code Engine. L'application peut créer des processus supplémentaires au moment de l'exécution.
random-route Pas nécessaire dans Code Engine. Chaque projet a un sous-domaine unique et puisque le nom de l'application fait partie de l'URL, l'URL est ainsi garantie d'être unique.
routes Les routes personnalisées ne sont actuellement pas prises en charge, mais vous pouvez utiliser IBM Cloud Internet Service(CIS)ou Cloudflare pour faire front à votre application avec un domaine personnalisé.
sidecars Non pris en charge actuellement.
stack Implicitement géré par Code Engine.
timeout Pas nécessaire dans Code Engine.
Variables d'environnement Option -env
services Voir la commande ibmcloud ce app bind.

Code Engine prend en charge de nombreuses options qui ne sont pas disponibles dans Cloud Foundry, telles que la gestion des mises à l'échelle automatique. Voir Travailler avec des applications dans Code Engine et Configuration de la mise à l'échelle d'application.

Je sais comment déployer une application avec Cloud Foundry. Que dois-je savoir pour déployer une application dans Code Engine ?

Si vous savez déployer une application avec Cloud Foundry, vous trouverez ce que vous devez savoir pour déployer une application dans Code Engine.

code push

Avec Code Engine, vous pouvez générer votre code qui provient d'un référentiel Git ou d'un système local (CLI uniquement). De plus, comme dans le cas de Cloud Foundry (cf push), vous pouvez générer et déployer votre application en une seule étape à l'aide de l'interface de ligne de commande et de la console Code Engine. Pour plus d'informations, voir Comment puis-je faire fonctionner mon code en tant que composant d'application Code Engine ?

Contexte de déploiement

Cloud Foundry a besoin d'un Org et d'un Space pour insérer votre code dans une application. Tous les utilisateurs de Foundry Cloud reçoivent par défaut un Org et un Space qui sont créés pour eux. Toutefois, pour en ajouter de nouvelles, vous devez configurer une cible Org et Space similaire à l'exemple suivant.

ibmcloud cf create-org MyOrg
ibmcloud target -o <ORGNAME>
ibmcloud target -s dev

Lorsque vous déployez une application avec Cloud Foundry, Org et Space sont ciblés pour le déploiement.

Code Engine utilise le concept d'un groupe de ressources IBM Cloud et d'un projet Code Engine.

ibmcloud target -g <RESOURCE-GROUP>
ibmcloud ce project create --name <PROJECTNAME>

Ces commandes créent non seulement un projet, mais aussi des "cibles". Toutes les commandes Code Engine suivantes s'exécutent dans le contexte de ce projet jusqu'à ce qu'un autre projet soit ciblé à l'aide de la commande project select. Pour plus d'informations, voir laGestion des projets.

Journaux

Code Engine fournit des journaux pour les applications, les travaux et les générations pour vous aider à déterminer ce qu'il s'est passé lorsque les déploiements ne se sont pas exécutés correctement. Vous pouvez trouver des journaux en exécutant des commandes similaires aux exemples suivants.

ibmcloud ce app logs -n <APPNAME>
ibmcloud ce jobrun logs -n <JOBRUN-NAME>
ibmcloud ce buildrun logs -n <BUILDRUN_NAME>

Vous pouvez également utiliser le service IBM Cloud Logs, qui est disponible pour une persistance à plus long terme des messages de journal. Pour plus d'informations, voir Affichage des journaux.

Création d'un service

La création d'une instance d'un service géré est similaire à Cloud Foundry et Code Engine.

Pour créer un nouveau service à utiliser avec votre application Cloud Foundry, utilisez la commande suivante.

ibmcloud cf create-service cloudantNoSQLDB lite myNameCloudant

Pour créer un service à utiliser avec les applications Code Engine,

ibmcloud resource service-instance-create myNameCOS cloud-object-storage lite global

Liaison de service

Une fois votre application créée, vous pouvez "lier" votre application au service.

Avec Cloud Foundry, exécutez la commande suivante.

ibmcloud cf bind-service appName instanceName

Avec Code Engine,

ibmcloud ce app bind --name appName --service-instance instanceName

Les données d'identification de l'instance de service (coordonnées) sont injectées dans l'application (ou le travail) à l'aide de variables d'environnement. L'équivalent Cloud Foundry deVCAP_SERVICES dans Code Engine est CE_SERVICES. Pour plus d'informations, voir Intégration du service IBM Cloud avec la liaison de service.

Mise à jour d'une application ou d'un travail

Après avoir créé votre application ou votre travail, vous pouvez mettre à jour les propriétés de votre charge de travail à l'aide de la commande de mise à jour. Par exemple, pour mettre à jour une application dans Code Engine,

ibmcloud ce app update --name <APPNAME> ...

Vous pouvez mettre à jour les propriétés disponibles lorsque vous créez une application ou un travail. Pour plus d'informations, reportez-vous aux rubriques suivantes.

Prise en charge de l'environnement d'exécution

Code Engine prend en charge la plupart des moteurs d'exécution que Cloud Foundry prend en charge. Pour obtenir la liste des environnements d'exécution pris en charge par Code Engine, voir packs de construction Cloud Native. Si vous souhaitez utiliser un moteur d'exécution qui n'est pas pris en charge, par exemple, Swift ou Liberty, vous pouvez conditionner vous-même votre application en tant qu'image de conteneur et déployer cette image dans Code Engine sans construire l'image directement à partir de Code Engine.

Etapes suivantes

  1. Vous commencez juste votre migration ? Consultez Mise en route.
  2. Comparer la terminologie de Cloud Foundry avec Code Engine.
  3. Essayez Code Engine avec un tutoriel de génération local.
  4. Votre application utilise-t-elle des liaisons de service ? Consultez Migration de vos liaisons de service.
  5. En savoir plus sur la mise à l'échelle et gestion du trafic.
  6. Recherchez Code Engine équivalents à des commandes de Cloud Foundry.
  7. Migration des applications Cloud Foundry vers la foire aux questions Code Engine (page actuelle)

Autres informations