Analysis of cloud_controller_ng architecture in Foundry Cloud

Label Foundry CloudCloud_controller_ngFramework
3391 people read comments(5) Collection Report

Cloud_controller_ng profile

Cloud_controller_ng is an important component in the Foundry V2 Cloud version. Where cloud_controller_ng is the meaning of next generation cloud_controller (NG), and cloud_controller_ng design is not compatible with the original old version of cloud_controller. The old version of the cloud_controller using MVC Rails framework to achieve, and cloud_controller_ng is used Sinatra framework to achieve, from the point of view, the more lightweight. The version of the cloud_controller_ng also added a lot of important concepts, such as app and service must be used space and organization, etc.. For the sake of simplicity, in order to replace the cloud_controller_ng ccng.

Cloud_controller_ng architecture diagram

The following is the author through the understanding of the CCNG source code, self described CCNG simple architecture.

Can be seen from the CCNG architecture diagram CCNG can be divided into the following modules:
  • DEA module is mainly responsible for the interaction with DEA components;
  • Stager module, mainly responsible for interaction with the staging part of the DEA component;
  • Blobstore module is mainly responsible for the creation of a blobstore storage, in order to Foundry Cloud storage applications required for static files;
  • HealthManager (HM) module, is mainly responsible for the interaction with HealthManager components;
  • CCDB module, responsible for the maintenance of cloud_controller database;
  • Collector_registrar module, is responsible for the registration of component components to the Collector component;
  • Router_registrar module, is responsible for the domain name registration controller cloud components to Router components;
  • The legacy_api section is responsible for taking over the RESTful request for info, bulk, CCNG, and services;
  • Other part.
Below will be mentioned from the above modules, and gradually analyze the CCNG architecture.

Stager cloud_controller_ng module

The function of the Stager module is responsible for the management of the application of the source and buildpack bundled package, and the final package in the form of droplet.

In the version of Foundry V1 Cloud, there is only one Stager component for a Foundry Cloud cloud platform. And in the Foundry V2 Cloud version, because there is no original independent Stager components, and Stager features similar to the staging module designed to be a sub module DEA. Therefore, if the Cloud version of Foundry V2 deployed a number of DEA, then the cloud platform will have more than one Staging module. It is because there are multiple staging module's sake, in the CCNG design has a interact with the staging of the module, can be tentatively called the stager module of CCNG, module of the maintained a stager Resource pools, i.e., stager_pool, and stager_pool to receive and distribute requests for staging tasks.

When there is a need to complete the staging task, you need to create a staging_request, the implementation of the method is located in: /cloud_controller_ng/lib/cloud_controller/app_stager_task.rb, the code is as follows:
Never stage if there # We is not a start request
Staging_request def
{: app_id = > @app.guid,
Task_id: = task_id,
Properties = > staging_task_properties (@app),
All URL generation should go to # blobstore_url_generator
Download_uri = > @blobstore_url_generator.app_package_download_url (@app),
Upload_uri = > @blobstore_url_generator.droplet_upload_url (@app),
Buildpack_cache_download_uri = > @blobstore_url_generator.buildpack_cache_download_url (@app),
Buildpack_cache_upload_uri = > @blobstore_url_generator.buildpack_cache_upload_url (@app),
Start_message: = start_app_message,
Admin_buildpacks: = admin_buildpacks
The structure of the request is very clear that the work done by staging, the corresponding work is as follows:
  • The application of ID to create the app_id;
  • Task_id: corresponding to the ID of staging_task;
  • The basic properties of properties: applications, such as the use of resources, the use of the environment, the use of services, etc.;
  • Download_uri: in the application of blobstore stored source app_package;
  • Upload_uri: after the final package into droplet, upload the URI used by the droplet;
  • Buildpack_cache_download_uri: in blobstore stored in the buildpack need to download URI app;
  • Buildpack_cache_upload_uri:buildpack upload uri;
  • Start_message: starts the basic information needed by the app, and ultimately by the start_app_message class DeaClient method to achieve;
  • Admin_buildpacks: provides admin_bulidpack download uri.
In addition to creating staging_request, but also need to find the right stager_pool from the stager to complete the staging task, to find the right stager_id, that is, to send staging_request to the staging.

DEA cloud_controller_ng module

The function of the DEA module is responsible for the communication between CCNG and DEA.

In DEA, the CCNG module can be roughly three parts: dea_client, dea_pool and dea_respondent.


Dea_client is mainly responsible for the DEA as a client, to achieve a request to send a request to the. When there is a request to reach CCNG, DEA need to get the information on the application of CCNG, CCNG are required to complete the request through the dea_client. For example: the need to start an application, the DEA to send a start request to dea_client; need to stop an application, the dea_client to send a stop request to the DEA, etc..


Dea_respondent is mainly responsible for the implementation of the request, as a responder, to complete the DEA initiative. This kind of request is mainly when the application of DEA in the exit, will be through the NATS CCNG to send applications to exit the message, so CCNG can do follow-up corresponding to the aftermath of the work.


Dea_pool is mainly responsible for the maintenance of all Cloud DEA in the resource pool Foundry. When Foundry Cloud has a new DEA start and start working, will be released to the CCNG through the advertise NATS information, and CCNG through the information sent to the part of the information to dea_pool in the DEA information. When there is a need to start the application, CCNG need to find the right DEA to complete the start work, this time by the dea_pool through the DEA resource usage and other important conditions to complete the DEAs screening, to find out the conditions of the DEA.

Blobstore cloud_controller_ng module

Blobstore module is mainly responsible for the maintenance of the storage of static files, this part of the paper is mainly divided into three parts:
  • Application source code
  • Application buildpack
  • Staged application, that is, droplet
Blobstore in the concrete implementation will take over a lot of work, such as: the file copy, the file URI creation, file compression, file fingerprint definition, etc..

HM cloud_controller_ng module

HM module is mainly responsible for the establishment of communication with health_manager, and the completion of the application of health monitoring. This part can also be divided into two parts, one is client, one is respondent:
  • Health_manager_client: is mainly responsible for the CCNG and health_manager to communicate with the client side, through the messagebus initialization, and through the messagebus to achieve find_crashes, find_flapping_indices, health_instances three functions.
  • Health_manager_respondent: is mainly responsible for receiving CCNG and health_manager communication process health_manager sent to the information, which contains, health_manager requires CCNG to start certain to have, to stop some applications, etc..
Among them about the HM module, the current CCNG contains two different forms of HM, an health_manager module, and the other for the hm_9000 module.

Above is the simple analysis of the cloud_controller_ng architecture.

About the author:

Sun Hongliang,DAOCLOUDSoftware engineer. In the past two years, the main research areas of PaaS related knowledge and technology in the field of cloud computing. Firmly believe that the technology of lightweight virtual container, will bring the depth of the impact of the PaaS field, and even determine the future direction of PaaS technology.

Reproduced please indicate the source.

This article is more out of my own understanding, in some places, there are some deficiencies and errors. I hope this article will be able to contact the Controller Cloud architecture of the people some help, if you are interested in this area, and have better ideas and suggestions, please contact me.

My email address:

Guess you're looking for
View comments
* the above user comments only represent their personal views, does not represent the views or position of the CSDN website
    personal data
    • Visit81816 times
    • Integral:One thousand three hundred and twenty-eight
    • Grade
    • Rank:18621st name
    • Original47
    • Reproduced:0
    • Translation:1
    • Comments:49
    Blog column
    Contact information
    Latest comments