Bluemix Cloud Foundry runtimes and application staging

Runtimes and buildpacks

IBM Bluemix Cloud Foundry runtimes are based on Cloud Foundry buildpacks. Understanding buildpacks, how they are selected and managing settings and defaults of buildpacks is important to deploying Cloud Foundry applications on Bluemix.

Cloud Foundry components

In a Cloud Foundry based PaaS environment there are a number of components that coordinate the deployment, management and access to applications. Applications run inside containers that are hosted on Diego Cells. The deployment of applications is coordinated through the Cloud Controller. Incoming traffic goes to the Router which forwards traffic to the appropriate component in the environment.

Application staging and deployment

The process of taking an application from the code assets and supporting artifacts to a running application is called the staging process. The following steps are followed to stage and deploy an application:

  1. At the command line, the developer enters the directory containing her application and uses the Bluemix Command Line Interface (bx CLI) to issue a push command.
  2. The bx CLI tells the Cloud Controller to create a record for the application.
  3. The Cloud Controller stores the application metadata. Application metadata can include the app name, number of instances the user specified, and the buildpack, and other information about the application.
  4. Before uploading all the application files, the bx CLI issues a resource match request to the Cloud Controller to determine if any of the application files already exist in the resource cache. When the application files are uploaded, the bx CLI omits files that exist in the resource cache by supplying the result of the resource match request. The uploaded application files are combined with the files from the resource cache to create the application package.
  5. The Cloud Controller stores the application package in the blobstore.
  6. The bx CLI issues an app start command.
  7. The Cloud Controller issues a staging request to Diego, which then schedules a Cell to run the staging Task. The Task downloads buildpacks and if present, the app’s buildpack cache. It then uses the buildpack that is detected automatically or specified with the -b flag to build the droplet. The Task uses the instructions in the buildpack to stage the application.
  8. The Diego Cell streams the output of the staging process so the developer can troubleshoot application staging problems.
  9. The Task packages the resulting staged application into a tarball called a “droplet” and the Diego Cell stores it in the blobstore. The Task also uploads the buildpack cache to the blobstore for use the next time the application is staged.
  10. The Diego Bulletin Board System reports to the Cloud Controller that staging is complete. Staging must complete within 15 minutes or the staging is considered failed. Apps are given a minimum of 1GB memory to stage, even if the requested running memory is smaller.
  11. Diego schedules the application as a Long Running Process on one or more Diego Cells.
  12. The Diego Cells report the status of the application to the Cloud Controller.

Related links

Supported Buildpacks

Troubleshooting Runtimes

Cloud Foundry components

How applications are staged