Internal process of deployment in Cloud Foundry

As of now we have learnt what is Pivotal Cloud Foundry and how to create application and push it into Pivotal Cloud Foundry. Now, we will look at what is the internal mechanism of an application deployment in Pivotal Cloud Foundry or we can also say that what is the cf push sequence mechanism.
As we already know, we need to use cf push command from CF CLI to push/deploy application into Pivotal Cloud Foundry. But most of them doesn’t know the internal process of pushing an application into Pivotal. Take a look at below sequence diagram to understand more about the deployment process of an application in Pivotal.

As shown in the image, there are few important stages which we will come as part of the application push is,

CLI

Cloud Controller

Blob Store

CC_DB

Cell (Staging/Running)

As shown in the above diagram, 12 steps are running internally to deploy an application into Pivotal Cloud Foundry. From step 1 to step 7 is part of Staging and 1 to 9 steps will part of Droplet of the application. Diego will be the responsible for running Droplet. Will look at each and individual steps which are show in above diagram,

  1. As shown in the image CF PUSH is the initial command which we need to issue from CLI to start to push application into Pivotal Cloud Foundry.
  2. Cloud Controller is the responsible for taking all the requests coming from CLI and similarly CF PUSH will come to Cloud Controller and create application which we are trying to push.
  3. Cloud Controller will send application METADATA to store into CC_DB (Internal Cloud Controller Database). METADATA is nothing but, application name, memory, buildpack and high level information.
  4. Application source files and other files related to pushing application jar/war will send to Cloud Controller.
  5. The RAW source code and application files are stores in the Cloud Controller database in the format of BLOB or Binary in Blob Store.
  6. Having all these application information in  place, Cloud Controller initiates the application startup process inside the container. So application start command is invoked and all the application startup events are triggered.
  7. With the help of Auctioner, try to identify which is the available CELL to stage the application. This CELL is also called as Staging Cell. As on when we issue the cf stage command, still this step will be executed internally.
  8. Streaming out put of the application staging will be send back to Command Line Interface (CLI) either it is success or any issues.
  9. After streaming out the application, Diego creates a TAR image of running application and stores in the format of BLOB. This is also called as droplet. Taking and running Droplet is the responsibility of Diego.
  10. After completed application staging, it report back to the Cloud Controller with the output information.
  11. Another Auctioner will happen to run the staged application. This auction will get identify the Running cell to run the application.
  12. Return the report of the running application back to the CLI (Command Line Interface)
What is the difference between Staging and Restart?
As shown in the image, staging will be in between 2 to 8 steps and 9 to 12 is the restart. Restart will work on top of already staged application