Cloud Controller Blobstore

This topic describes how Cloud Controllers and Diego interact with the Cloud Controller blobstore.

Overview

Cloud Foundry uses a blobstore to store the source code that developers push, stage, and run.

This topic references staging and treats all blobstores as generic object stores. For more information about staging, see How Apps Are Staged.

How Staging Uses the Blobstore

This section describes how staging buildpack apps uses the blobstore.

The following diagram illustrates how the staging process uses the blobstore:

The staging process for buildpack apps includes a developer and the following components: CF Command Line, Cloud Controller (CCNG), Blobstore, cc-uploader, Diego Cell (Staging), and Diego Cell (Running). Step 1 is CF Push from Developer to CF Command Line. Step 2 is Checksum source files from Developer to CF Command Line. Step 3 is Resource Match from CF Command Line to the CCNG. Step 4 is Check file existence from the CCNG to Blobstore. Step 5 is Upload unmatched files from CF Command Line to CCNG. Step 6 is Download cached files from Blobstore to CCNG. Step 7 is Upload complete package from CCNG to Blobstore. Step 8 is Download package and buildpack from Blobstore to Diego Cell (Staging). Step 9 is Upload droplet from Diego Cell (Staging) through cc-uploader, then CCNG, to the Blobstore. Step 10 is Download droplet from Blobstore to CCNG.

The process in which the staging process uses the blobstore is as follows:

  1. A developer runs cf push.

  2. The Cloud Foundry Command Line Interface (cf CLI) gathers local source code files and computes a checksum of each.

  3. The cf CLI matches resources to Cloud Controller and lists those files and their checksums.

  4. This step includes the following:

    1. Cloud Controller makes requests to the blobstore to find out which files it has cached.
    2. Cloud Controller assigns addresses to its cached files, so changes to a file result in it being stored as a different object.
    3. Cloud Controller computes which files it has and which it needs the cf CLI to upload.
    4. In response to the resource match request, Cloud Controller lists the files the cf CLI needs to upload.

  5. The cf CLI compresses and uploads the unmatched files to Cloud Controller.

  6. Cloud Controller downloads the matched files from the blobstore to its local disk.

  7. This step includes the following:

    1. Cloud Controller compresses the newly uploaded files with the downloaded cached files in a ZIP file.
    2. Cloud Controller uploads the complete package to the blobstore.

  8. The Diego Cell downloads the package and its buildpacks into a container and stages the app.

  9. This step includes the following:

    1. After the app has been staged, the Diego Cell uploads the complete droplet to cc-uploader.
    2. cc-uploader makes a multi-part upload request to upload the droplet to Cloud Controller.
    3. Cloud Controller enqueues an asyncronous job to upload the blobstore.

  10. This step includes the following:

    1. The Diego Cell attempts to download the droplet from Cloud Controller into the app container.
    2. Cloud Controller redirects the Diego Cell droplet download request to the blobstore.
    3. The Diego Cell downloads the app droplet from the blobstore and runs it.

Blobstore Load

The load that Cloud Controller generates on its blobstore is unique due to resource matching. Many blobstores that perform well under normal read, write, and delete load are overwhelmed by Cloud Controller’s heavy use of HEAD requests during resource matching.

Pushing an app with large number of files will cause Cloud Controller to check the blobstore for the existence of each file.

Parallel BOSH deployments of Diego Cells can also generate significant read load on the Cloud Controller blobstore as the cells perform evacuation. For more information, see the Evacuation section of the App Container Lifecycle topic.

How Cloud Controller Reaps Expired Packages, Droplets, and Buildpacks

As new droplets and packages are created, the oldest ones associated with an app are marked as “EXPIRED” if they exceed the configured limits for packages and droplets stored per app.

Nightly, starting at midnight, Cloud Controller runs a series of jobs to delete the data associated with expired packages, droplets, and buildpacks.

Enabling the native versioning feature on your blobstore will increase the number of resources stored and increase costs. For more information, see Using Versioning in the AWS documentation.

Blobstore Interaction Timeouts

Cloud Controller inherits its default blobstore operation timeouts from Excon. Excon defaults to 60-second read, write, and connect timeouts. For more information, see the excon repository on GitHub.

Create a pull request or raise an issue on the source for this page in GitHub