| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2024-10-09 |
code engine, tutorial, build, source, application, buildpack, access, build run, image, cloud foundry |
codeengine |
{{site.data.keyword.attribute-definition-list}}
{: #migrate-cf-ce-terms}
Before you get started with deploying apps in {{site.data.keyword.codeengineshort}}, learn the basics about {{site.data.keyword.codeengineshort}}. The following table describes some high-level terminology differences between Cloud Foundry and {{site.data.keyword.codeengineshort}}.
| Cloud Foundry | {{site.data.keyword.codeengineshort}} | Description |
|---|---|---|
Org and Space |
Resource group and projects | A grouping of workloads. The specific choice of which workload goes into each grouping is defined by the user. "Resource groups" are an {{site.data.keyword.cloud_notm}} concept, while "projects" are {{site.data.keyword.codeengineshort}} specific. Projects provide a level of isolation between workloads. See Managing projects. |
| Application | Application (app) | A workload that responds to HTTP requests from a REST API, a web page request, or an event, for example. {{site.data.keyword.codeengineshort}} requires that applications include the HTTP server as part of the code. Applications automatically scale (up and down) based on the incoming load. You can configure the minimum and maximum scale if needed. By default, the application listens on port 8080. You can override this behavior by using the console or with the CLI --port option. See Working with apps in {{site.data.keyword.codeengineshort}}. |
| N/A | Job or batch job | 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. See Working with jobs and job runs. |
cf push |
Build and deploy | Process of building a container image from source code and deploying an app in a single step. You can build code based on a Dockerfile or that use a Paketo buildpack. You can build from a single step in the CLI as well as from the {{site.data.keyword.codeengineshort}} console. See Planning your build. |
| Service binding | Service binding | Attach a workload to an {{site.data.keyword.cloud_notm}} managed service. The credentials and connection information is exposed to the workload through environment variables. The VCAP_SERVICES environment variable in Cloud Foundry is called CE_SERVICES in {{site.data.keyword.codeengineshort}}. See Integrating {{site.data.keyword.cloud_notm}} services with service bind. |
| Routes and domains | Custom domain mapping | Define and manage external URLs to your workloads. {{site.data.keyword.codeengineshort}} provides support for custom domains mappings from the console. You can also add custom domains through {{site.data.keyword.cis_full_notm}} or any other domain provider of your choice. |
| {: caption="Terminology" caption-side="bottom"} |
For more terms and capabilities for {{site.data.keyword.codeengineshort}}, see Learn about {{site.data.keyword.codeengineshort}}.
{: #migrate-cf-ce-next-terms}
- Just starting your migration? Check out Getting started.
- Compare Cloud Foundry terminology with {{site.data.keyword.codeengineshort}} (current page)
- Try out {{site.data.keyword.codeengineshort}} with a local build tutorial.
- Does your application use service bindings? Check out Migrating your service bindings.
- Learn about scaling and traffic management.
- Find {{site.data.keyword.codeengineshort}} equivalents to Cloud Foundry commands.
- Still have questions? Try the Migrating Cloud Foundry applications to {{site.data.keyword.codeengineshort}} FAQ.
Other information
- Find out about {{site.data.keyword.codeengineshort}} pricing.
- Try other {{site.data.keyword.codeengineshort}} tutorials{: external}.
- Explore other {{site.data.keyword.codeengineshort}} topics.