"Cloud Foundry" cloud Foundry Learning (v)--cloud Controller

Overview

Cloud Controller is responsible for managing the life cycle of the application. When a developer publishes an app to Cloud Foundry, it is published in cloud Controller, CC stores the original application section, creates a record to track the application's data, and informs the DEA to package and run the app. CC also holds information such as orgs, spaces, services, service instances, user roles, and so on.

Architecture

Cloud_controller_ng Frame composition

As you can see from the CCNG architecture diagram, CCNG can be divided into the following modules:

• DEA module, which is mainly responsible for interacting with DEA components;
• Stager module, which is mainly responsible for interacting with the staging part of the DEA component;
• The Blobstore module is primarily responsible for creating a blobstore storage for the static files required by the Cloud foundry storage application;
• Healthmanager (HM) module, which is mainly responsible for interacting with healthmanager components;
• CCDB module, responsible for maintaining the Cloud_controller database;
• Collector_registrar module, which is responsible for registering as component to collector components;
• The Router_registrar module is responsible for registering the domain name of the cloud controller component with the router component;
• LEGACY_API part, responsible for taking over CCNG's restful requests regarding info,bulk and services, etc.;
• Other parts.

Function:

Cloud Controller is the Cloudfoundry management module. The main tasks include:

A) Change the additions and deletions of the apps;

b) Start and stop the application (via DEA);

c) Stagingapps (pack apps into a droplet, through stager);

D) Modify the operating environment of the application, including instance, MEM, etc.;

e) Manage service, including service and app bindings, etc.;

f) cloud environment management;

g) Modify cloud user information (via UAA,ACM);

h) View Cloudfoundry, and log information for each app.

This may seem a bit complicated, but simply put, it can be simple: it's the server side that interacts with VMC and Sts. VMC and STS communicate with Cloudfoundry in a restful interface, while the cloud controller is a typical Ruby on Rails project that receives a JSON-formatted protocol from VMC or STS and then writes to the cloud Controllerdatabase, concurrent messages to each module to control the management of the entire cloud.

To deploy an app to Cloudfoundry, for example, after we hit the simple push command, VMC began to work, after a round of user authentication, to see if the number of apps deployed exceeded the predetermined amount, asked a bunch of related app questions, you need to send 4 instructions:

A) send a post to "apps" to create an app;

b) Send a put to "apps/:name/application", upload the app;

c) Send a get to "apps/:name/" to get the app status to see if it has been started;

D) If it does not start, send a put to "apps/:name/" to enable it to start.

The first version of Cloudcontroller is based on the Ruby on Rails, and in the new version, in order to be consistent with other cloudfoundry modules, and to make the architecture simpler, Cloudcontroller is rewritten with Sinatra. and added more modules to refine the work of Cloudcontroller.

Another important improvement is that the first version of Droplet is shared via NFS, but this brings security, performance issues, and two improvements in the new version:

A) Removal of NFS, using its own developed, simple blobstore to store droplet;

b) optimized for the Ruby project and saved the commonly used gems in the package cache. So when you package a Ruby project, you don't need to download the gem file on the public web, but you get it from the cache inside the Cloudfoundry, which accelerates the stage process considerably.

With the gradual maturation of cloudfoundry, the Rights management function has been greatly strengthened in the new version, and the concept of organization and user space has been added on the basis of the original user model.

The authentication of the user model is implemented by the UAA module, which can be integrated with the enterprise's existing authentication system, such as Ldap,cas, etc., authentication is realized by the ACM module.

An example is the process of a user accessing the Cloudcontroller API. We can see separately the role that UAA and ACM modules play in a set of authentication processes.

"Cloud Foundry" cloud Foundry Learning (v)--cloud Controller