How Applications Are Staged
Page last updated:
Cloud Foundry has used two architectures for managing application containers: Diego and Droplet Execution Agents (DEAs). For information about how DEA applications are staged, see the Staging Apps with DEAs section of the Droplet Execution Agent topic.
At the command line, the developer enters the directory containing her application and uses the Cloud Foundry Command Line Interface (cf CLI) to issue a push command.
The cf CLI tells the Cloud Controller to create a record for the application.
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.
Before uploading all the application files, the cf 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 cf 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.
The Cloud Controller stores the application package in the blobstore.
The cf CLI issues an app start command.
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
-bflag to build the droplet. The Task uses the instructions in the buildpack to stage the application.
The Diego Cell streams the output of the staging process so the developer can troubleshoot application staging problems.
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.
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.
Diego schedules the application as a Long Running Process on one or more Diego Cells.
The Diego Cells report the status of the application to the Cloud Controller.
See the Diego Architecture topic for more information.
At the command line, the developer enters the name of a Docker image in an accessible Docker Registry and uses the cf CLI to issue a push command.
The cf CLI tells the Cloud Controller to create a record for the Docker image.
The Cloud Controller issues a staging request to Diego, which then schedules a Cell to run the staging Task.
The Diego Cell streams the output of the staging process so the developer can troubleshoot staging problems.
The Task fetches the metadata associated with the Docker image and returns a portion of it to the Cloud Controller, which stores it in the Cloud Controller database (CCDB).
The Cloud Controller uses the Docker image metadata to construct a Long Running Process that runs the start command specified in the Dockerfile. The Cloud Controller also takes into account any user-specified overrides specified in the Dockerfile, such as custom environment variables.
The Cloud Controller submits the Long Running Process to Diego. Diego schedules the Long Running Process on one or more Diego Cells.
The Cloud Controller instructs Diego and the Gorouter to route traffic to the Docker image.