Using buildpacks in IBM Cloud Private Cloud Foundry
By default, IBM® Cloud Private Cloud Foundry contains buildpacks that are supported by IBM. You can use the buildpacks to deploy your applications to the cloud.
About the buildpacks
Cloud Foundry buildpacks provide the runtime support for applications in the Cloud Foundry environment. When you deploy an application to the cloud, it starts a buildpack that supports your application type. IBM Cloud Private Cloud Foundry provides buildpack support for Java™ EE, Node.js, ASP.Net, Swift, and other application types.
You can use the buildpacks that are included with IBM Cloud Private Cloud Foundry to deploy applications and bind them to user-provided services. The following Cloud Foundry buildpacks are available for both IBM Cloud and IBM Cloud Private. Buildpacks in IBM Cloud Private work differently than in IBM Cloud depending on how Cloud Foundry is configured.
A new cflinuxfs3 stack is available. cflinuxfs2 is the default stack for use with buildpacks, but cflinuxfs3 is now available.
- cflinuxfs2 creates an application environment when it is combined with a buildpack that is based on Ubuntu Trusty
- cflinuxfs3 creates an application environment when it is combined with a buildpack that is based on Ubuntu Xenial
The following buildpacks do not work with cflinuxfs3:
- Swift
- dotNET
- Docker containers
Available buildpacks
You can use Liberty for Java, SDK for Node.js, Runtime for Swift, or ASP.NET core buildpacks to deploy your applications to the cloud with the following procedure. Or, you can start to work with user-provided services by using the starter applications for the following buildpacks:
Installing and updating buildpacks
Buildpacks are included with IBM Cloud Private Cloud Foundry. For more information about buildpack installation and updates, see Administering buildpacks in IBM Cloud Private Cloud Foundry.
General procedure for deploying an application with buildpacks
Deploy an application to your IBM Cloud Private Cloud Foundry instance with buildpacks
-
Point your Cloud Foundry CLI to your environment by using the API endpoint or target URL for your instance of IBM Cloud Private Cloud Foundry.
cf api <API endpoint of IBM Cloud Private Cloud Foundry>Note: For more information about identifying your API endpoint or target URL, see Using
bluemix_env_domainto find your API endpoint and Login endpoint. -
Use the cf command line to log in to Cloud Foundry.
cf login -
From within your application directory, push your application.
cf push -
Deploying your application can take a few minutes. When deployment completes, you see a message that your app is running. View your app at the URL that is listed in the output of the push command, or view both the app deployment status and the URL by running the following command:
cf app <Your-App-Name>
Tip: You can troubleshoot errors in the deployment process by using the cf logs <Your-App-Name> --recent command.
Environment variables for buildpacks in IBM Cloud Private Cloud Foundry
Since you can configure IBM Cloud Private Cloud Foundry differently in comparison to IBM Cloud, some environment variables might work differently and require you to manually configure them.
Using bluemix_env_domain to find your API endpoint and login endpoint
When you install Cloud Foundry, the administrator defines the bluemix_env_domain variable. This variable is used to define your API endpoint or target URL and can be adapted to define the login endpoint for your instance of IBM Cloud
Private Cloud Foundry.
For example, if your bluemix_env_domain is defined as local.bluemix.net, your target URL or API endpoint would be https://api.local.bluemix.net. Your login endpoint for your environment domain would be https://login.local.bluemix.net/UAALoginServerWAR.
A login endpoint URL always includes login. before bluemix_env_domain and ends with /UAALoginServerWAR. An API endpoint or target URL includes api. before the bluemix_env_domain.
To learn more about how to install Cloud Foundry and configure IBM Cloud Private, see Installing IBM Cloud Private Cloud Foundry platform overview.
PORT
Running Node.js apps locally before deploying to IBM Cloud Private Cloud Foundry
Before you deploy your application or when you debug your application, you might want to run itn locally. When you use a buildpack, the Cloud Foundry environment allocates a port, and passes that information to the application in the PORT environment variable. To run the application in Cloud Foundry, the application must be coded to bind to the PORT environment variable. However, when you run an application locally, this environment variable might not be set. You need
to code your application to bind to a default port if it does not find the PORT environment variable.
When you work with the Node.js starter application, you set the PORT environment variable to 3000. For more information about running Node.js applications locally, see the Working with user-provided services and the Node.js starter app tutorial and IBM Cloud documentation on how to Run the Node.js application locally .
Related links
To learn more about user-provided services, service broker provided services, administering buildpacks, and the starter applications for IBM Cloud Private Cloud Foundry, see the following topics:
- Administering buildpacks in IBM Cloud Private Cloud Foundry
- Working with user-provided services in IBM Cloud Private Cloud Foundry
- Managing Liberty and Node.js apps in IBM Cloud Private Cloud Foundry
- Working with services provided by a service broker in IBM Cloud Private Cloud Foundry
See the following links to learn more about the buildpacks on IBM Cloud: