Migrating Cloud Foundry applications to Code Engine FAQ

Answers to common questions about migrating your Cloud Foundry applications to Code Engine.

Can I use a custom URL with Code Engine?

Yes! You can map your own custom URL to a Code Engine application by creating a custom domain mapping from the Code Engine console. You can also assign a custom URL through an internet service provider, such as IBM Cloud Internet Services. For more information about deploying an app with a custom domain through IBM Cloud Internet Services, see Configuring a highly available application. For more information about deploying an app with a custom domain through Cloudflare, see the Configuring a Custom Domain for Your IBM Cloud Code Engine Application blog.

My app contains a specific route, Can I use the same route?

You can use the same custom route or domain as long as you control it. If the route is from another source, for example, an IBM-provided route such as mybluemix.net, then you must use the domain that is provided by Code Engine or else map a new custom domain to your app.

Can I stop my app?

You cannot stop your app directly, but you can prevent your app from receiving traffic by setting its visibility to project and allowing it to scale to 0. For more information, see How can I stop my app from receiving traffic?

Why do I have so many app instances?

When you update your app, Code Engine automatically creates a new revision. When the revision is available, traffic is routed to the new instances. While the revision scales up and traffic is transferred to it, the original app instance continues to handle traffic. When the revision is scaled up and all traffic is routed to it, the original app is scaled down. Your app also automatically scales up and down as traffic requires. Check back later to be sure that your app is running the correct number of instances. For more information, see Configuring application scaling.

Why are my apps slow to respond?

Your application scales to zero by default and thus can be slower to respond while it scales back up. You can change this behavior by updating your application and setting the minimum scale to 1 in either the console or from the CLI.

For example, to set the minimum scale to 1 for an application called myapp from the CLI,

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

After the application updates, a single instance is always running. Be aware that charges might apply. For more information, see Pricing for Code Engine.

Can I route requests to a specific application instance?

No, this functionality is not currently supported. You can approximate this functionality by using Knative traffic splitting. For more information about using Knative with Code Engine, see Using Knative with Code Engine.

I use a global load balancer with my Cloud Foundry app. Can I migrate it to Code Engine?

Yes, you can update your global load balancer to point to your Code Engine app, if you can access the certificate chain and the corresponding private key. The following steps assume that you are using Cloud Internet Services (CIS); however, you can adapt these steps for your own global load balancer.

These steps use the console.

Create a domain mapping for your app. When you create your domain mapping, provide your private key and the full certificate chain of the domain(s). For more information, see Configuring custom domain mappings for your app. Wait until the domain mappings in all projects are showing a Ready state.
Open the details of each domain mapping and record the CNAME value, for example, custom.<your-random-id>.us-south.codeengine.appdomain.cloud or custom.<your-other-random-id>.us-east.codeengine.appdomain.cloud.
Navigate to the details page for each application and select Domain mappings tab and then, select No external system domain mapping in the system domain mappings section. This step ensures that your applications are only accessible through the custom domains when called from outside of this project.
In your Cloud Internet Services (CIS) instance, navigate to Reliability. > Global load balancers > Origin pools and edit the existing origin pools by changing the Origin address to the CNAME that you recorded earlier.

Your global load balancer is now pointing to your Code Engine app.

Does my app need to follow any specifications?

Your app must follow the 12-factor app methodology.

What types of workloads are available with Code Engine?

Code Engine supports two types of workloads: Applications and Batch Jobs.

An application, or app, runs your code to serve HTTP requests. In addition to traditional HTTP requests, IBM Cloud® Code Engine also supports applications that use WebSockets as their communications protocol. The number of running instances of an app are automatically scaled up or down (to zero) based on incoming requests and your configuration settings. An app contains one or more revisions. A revision represents an immutable version of the configuration properties of the app. Each update of an app configuration property creates a new revision of the app.

A job runs one or more instances of your executable code in parallel. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit. When you create a job, you can specify workload configuration information that is used each time that the job is run.

Determining the type of workloads that you want

Most Cloud Foundry applications can migrate to Code Engine. However, if your Cloud Foundry application does not wait for an incoming HTTP request, then jobs are probably the better choice. For more discussion and examples, see Planning for Code Engine.

I use manifest files. Are there similar options available with Code Engine?

If you use manifest files for your Cloud Foundry applications, map your manifest attributes to the corresponding Code Engine features or CLI option.

Table 1. Markdown coding for tables
Manifest attribute	Code Engine equivalent on the `ibmcloud ce app create` or `app update` commands
`command`	`--command` option
`disk_quota`	Implicitly set by Code Engine.
`docker`	Not needed in Code Engine.
`health-check-http-endpoint`	Not needed in Code Engine. By default a TCP probe is used to know when the application is healthy and ready.
`health-check-invocation-timeout`	Not needed in Code Engine.
`instances`	`--min-scale` and `--max-scale` options
`memory`	`--memory` option
`metadata`	Not currently supported.
`no-route`	With the `--cluster-local` option, the application is still accessible from other workloads within the project, but does not include an internet-facing accessible URL that associated with the application.
`path`	Not currently applicable.
`processes`	Not needed in Code Engine. The application can create additional processes at run time.
`random-route`	Not needed in Code Engine. Each project has a unique subdomain and since the application name is part of the URL, the URL is guaranteed to be unique.
`routes`	Custom routes are not currently supported, but you can use IBM Cloud Internet Service (CIS) or Cloudflare to front end your application with a custom domain.
`sidecars`	Not currently supported.
`stack`	Implicitly managed by Code Engine.
`timeout`	Not needed in Code Engine.
Environment variables	`-env` option
Services	See the `ibmcloud ce app bind` command.

Code Engine supports many options that are not available in Cloud Foundry, such as how autoscaling is managed. See Working with apps in Code Engine and Configuring application scaling.

I know how to deploy an app with Cloud Foundry. What do I need to know to deploy an app in Code Engine?

If you know how to deploy an app with Cloud Foundry, find what you need to know to deploy an app in Code Engine.

Push code

With Code Engine, you can build your code that is sourced in a Git repository or from a local system (CLI-only). Additionally, as with Cloud Foundry (cf push), you can build and deploy your app in a single step with both the CLI and the Code Engine console. For more information, see How do I make my code run as a Code Engine application component?.

Deployment context

Cloud Foundry requires an Org and a Space to push your code into an application. All Cloud Foundry users, by default receive an Org and Space that are created for them. However, to add new ones, you must set up an Org and Space target similar to the following example.

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

When you then deploy an app with Cloud Foundry, that Org and Space is targeted for the deployment.

Code Engine uses the concept of an IBM Cloud resource group and a Code Engine project.

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

These commands not only create a project, but "targets" it as well. All subsequent Code Engine commands run in the context of this project until a different project is targeted by using the project select command. For more information, see Managing projects.

Logs

Code Engine provides logs for apps, jobs, and builds to help you determine what happened when deployments do not run properly. You can find logs by running commands similar to the following examples.

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

You can also use the IBM Log Analysis service, which is available for more long-term persistence of log messages. For more information, see Viewing logs.

Creating a service

Creating an instance of a managed service is similar in Cloud Foundry and Code Engine.

To create a new service to use with your Cloud Foundry application, use the following command.

ibmcloud cf create-service cloudantNoSQLDB lite myNameCloudant

To create a new service to use with Code Engine applications,

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

Service binding

After you create your application, you can then "bind" your application to the service.

With Cloud Foundry, run the following command.

ibmcloud cf bind-service appName instanceName

With Code Engine,

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

The service instance credentials (coordinates) are injected into the app (or job) by using environment variables. The Cloud Foundry equivalent of VCAP_SERVICES in Code Engine is CE_SERVICES. For more information, see Integrating IBM Cloud service with service binding.

Updating an app or job

After you create your application or job, you can update properties of your workload by using the update command. For example, to update an application in Code Engine,

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

You can update any of the properties that are available when you create an application or job. For more information, see the following topics.

Runtime support

Code Engine supports many of the runtimes that Cloud Foundry supports. For a list of runtimes that are supported by Code Engine, see Cloud Native buildpacks. If you want to use a runtime that is not supported, for example, Swift or Liberty, you can package your app as a container image yourself and deploy that image in Code Engine without building the image directly from Code Engine.

Next steps

Just starting your migration? Check out Getting started.
Compare Cloud Foundry terminology with Code Engine.
Try out Code Engine with a local build tutorial.
Does your application use service bindings? Check out Migrating your service bindings.
Learn about scaling and traffic management.
Find Code Engine equivalents to Cloud Foundry commands.
Migrating Cloud Foundry applications to Code Engine FAQ (current page)

Other information

Find out about Code Engine pricing.
Try other Code Engine tutorials.
Explore other Code Engine topics.