from the overall look, CloudFoundry is structured as follows:
this chart and use the below chart of each module are from Pat's PPT. Can be seen from the figure CloudFoundry mainly in the following several major components:
1, Router: As the name implies, Router component CloudFoundry is for all incoming Request for routing. The request to enter the Router There are two types: the first is from VMCClient or the STS, issued by the user CloudFoundry, managed instruction. For example: list of all your apps vmcapps, submit an apps and more. Such request will be routed to AppLife Management component, also known CloudController components go; second is outside of your deployed apps access request. This part of the requests will be routed to Appexecution, Or component called DEAs go. CloudFoundry systems all incoming requests will go through Router component, see here might be worried Router friends will become a single point, and thus become the bottleneck of the entire cloud. But CloudFoundry as a cloud system, the core of its design is to rely on a single point, the component parallel to the expansion, and can be replaced in order to ensure scalability, which is CloudFoundry, even all the cloud computing system design principles, will discuss later how to do CloudFoundry this point, the current long as we know, the system can deploy multiple Routers common process incoming requests, but not CloudFoundry Router upper realization LoadBalance range, CloudFoundry only guarantee that all request is stateless, so that the upper surface is very balanced selection annexed very large, for example, you can do via DNS, you can deploy the hardware LoadBalancer, or simply, get Taiwan ngnix as load balancers, are feasible.
Router component, the current version is a simple package nginx. Familiar ngnix friends should know that it can a socket file (. Sock file) as input and output. All installed CloudFoundry the Router component servers will be installed a nginx, which ngnix.conf file has the following configuration:
from an overall point of view, Router component is structured as follows:
outside httprequest into CloudFoundry server, nginx will first received the request, nginx through the sock to interact with router.rb, so really deal with the request is for Router components. router.rb which according to the incoming url, user name, password etc, logical judgment, to CloudController component or components DEA data fetch and return with niginx connected. sock documents returned. router.rb is carried out nginx logical package. CloudFoundry familiar friends certainly know, CloudFoundry assigned to each app a url to access, if the direct use VMware hosted by CloudFoundry.com, then the url of your app is probably xxx.cloudfoundry.com, either through the command to your app extends the number of instances, are accessed from this url, which is routed inside the url conversion achieved by the router.rb.
2, DEA (Droplet Execution Agency): First, what is to be resolved under the Droplet. Droplet in CloudFoundry is a concept which you submit to the source code, as well as supporting CloudFoundry good operating environment, coupled with some management scripts, such as Start / Stop all these small scripts compressed tar package good together. There is a concept called Stagingapp, refers to the production of the above description of the package, and then store it in a good process. CloudFoundry will automatically save the Droplet, until you start an app when a module is deployed DEA will come and collect a Droplet server's copy to run. So if you extend your app to 10 instances, then this will be copied Droplet was ten, so take 10 DEA servers running.
Below is DEA module architecture diagram:
Cloud Controller Module (will explain below) will send start / stop and other basic apps management request to the DEA, dea.rb receive these requests, and then from the inside to find a suitable NFS Droplet. Speaking in front with a Droplet actually run the script, and with the operating environment of the tar package, DEA just need to unzip it to take over, and that line the inside of the start script, you can make this app up and running. This, app can be accessed, and start up, in other words, there is this server has a port on standby, as long as there is request coming from the port, this app can receive and return the correct information. Then dea.rb to do remedial work: one to bring this information to tell Router modules. We mentioned earlier that all the requests are made into CloudFoundry Router module handles and forwards, including user access app request, an app up, you need to tell the router, make it according to the principles of loadbalance, the appropriate transfer request came , for instance to make this app began to live; 2, some of the statistical work, for example, make the user has deployed a new app tells CloudController, for quota control, etc.; 3, the operation information tells HealthManager module, real-time reporting The app's instance operation. Another DEA also responsible for most of the work on the Droplet queries, for example, if users want to query an app through CloudController the log information that DEA taken from the inside of the Droplet to log back and so on.
3, CloudController: CloudController is CloudFoundry management module. Its main tasks are:
a) additions and deletions to read on the apps;
b) start and stop the application;
c) Staging apps (the apps packaged into a droplet);
d) modifying the application runtime environment, including instance, mem, etc.;
e) management service, including service with the app binding, etc.;
f) Cloud environment management;
g) modify Cloud user information;
h) View Cloud Foundry, as well as log information for each app.
It seems a little complicated, but simply put, it is simple: to interact with VMC and STS server. Communicate with CloudFoundry VMC and STS uses a restful interface, on the other hand CloudController is a typical Rubyon Rails project, STS received from the VMC or JSON format, protocol, and then write CloudController Database, and updates to the control and management of the mold go the entire cloud. And other items, like ROR, CloudController all API from conf / routes.rb seen. Restful advantage of open interfaces and integration of third-party application development, enterprise private cloud using CloudFoundry deployment time, you can control these interfaces to automate the management of the entire Cloud environment. This part of the contents will be discussed in the second part.
Below is Cloud Controller architecture diagram:
drawing Health Manager and DEA is an external module, CCDatabase is CloudController Database, this is the place where HP can not do CloudFoundry. CloudController Database concurrency is not much, application-level database access is handled under the Service Module, this data inventory is Cloud's configuration information. Read operation starts mainly from the DEA, DEA as a basis for initialization; healthmanager modules and the expected state is read from this information, which is part of the data obtained from the DEA actual status information for comparison. NFS is more CloudController shared storage, CloudController One important task is StagingApps. Droplets' storage is only in a clustered environment. And CloudController run the cluster, in other words, that every one may be controlled by different CloudController Request processing, assuming a simple user scenario: we need to deploy an app to CloudFoundry in. We Qiaowan piece simple push command, VMC began to work in the finished one user authentication, check whether the number of deployed apps exceeds a predetermined amount, and asked a bunch of questions related to the app, you need to send four instructions:
1. Send a POST to the "apps", to create an app;
2. Send a PUT to "apps /: name / application", uploading app;
3. Send a GET to "apps /: name /", get app state to see if has been started;
4. If it does not, send a PUT to "apps /: name /", it starts.
If the first 2 and 4 by different Cloud Controller to deal with, but can not guarantee that they can find with a Droplet, then Step 4 will not find a corresponding Droplet because failed to start. How to ensure that this series is pointing Droplet command over all the same one? Use NFS, make CloudController shared storage is the easiest way. However, this method is not perfect security and other aspects. On October 12 on the VMwareCloud Forum, Pat told us the next version of CloudFoundry here will be a big adjustment, but that part of the code is open, I too inconvenient for in this evaluation.
4, HealthManager: do not complicated, simply, it is run from each DEA to get inside information and statistical analysis, reporting, and so on. Statistical data set with CloudController indicators to compare and provide Alert and so on. HealthManager module is not yet perfect, but CloudManage stack inside, automated health management, analysis is a very important area, and this can be extended a lot of places, combined OrchestrationEngine can make cloud self-management, self-warning; areas with BI technologies, statistical operations, rational allocation of resources. CloudFoundry is still evolving in this area.
5, Services: Cloud Foundry's Service module from source control point of view that this is an independent, Plugin modules to facilitate the integration of third-party services into their own CloudFoundry ecosystem. Github is seen in service projects with CloudFoundry Core vcap separate a repository, as vcap-service. Service Module design principles of which is to facilitate third-party service providers to provide services. In this regard CloudFoundry very successful from the point of view Github, has provided the following services: a) MongoDB; b) mysql; c) neo4j; d) PostgreSql; e) RabbitMQ; f) Redis; g) vBlob. Base classes are on the base folder. If you need to develop their own CloudFoundry third-party services, we need to inherit rewrite it inside the two basic classes: Node and Gateway; while inside some operations, such as: Provision, at the base of the provisioner.rb can add your own logic on the basis of the same There Service_Error and Service_Message so on. On how to write your own Service, ELC's blog will launch the corresponding article discusses in detail, not in the scope of this article inside, from the architecture to understand terms, just know that the relationship between services, knowing that a service and base through inheritance relationship between the transverse expansion, and CloudFoundry and apps call the Service is through the base to complete this simple framework approach can be.
6, NATS (Message bus): From the chart to see the total CloudFoundry in the center position of each module is a component called nats. CloudFoundry NATS by architect Derek developed a lightweight, supportive publish, subscribe mechanism messaging system. Github source address is: https://github.com/derekcollison/nats. Its core based EventMachine development, small amount of code, you can download it slowly study. CloudFoundry is a multi-module distributed system support module self-discovery, self-test errors and low coupling between modules. The core principle is based on the publish-subscribe messaging mechanism. Each server module for each category based on their message to MessageBus publish multiple message topic; while also interacting modules to their needs, according to the information content of a message needs to topic Subscribe to news. For example: a DEA CloudFoundry cluster is added, it needs to tell you roar about, to indicate that it is ready to serve, it will publish a theme is "dea.start" message:
@ hello_message_json included in the DEA's UUID, ip, port, version information, etc.
another example, CloudController need to start a Droplet of instance:
a) First, a DEA at boot time, will first be to their UUID news topics to subscribe.
other modules need to pass'' dea. # {uuid}. start "this theme to make it start sending messages, once the DEA receives a message, it will trigger process_dea_start (msg) this method to deal with the work needed to start .
b) Cloud Controller or any other module to send messages, so UUID as the DEA xxx start.
c) DEA module receives a message, it will trigger process_dea_start (msg) method. msg is a message sent from other modules, including: droplet_id, instance_index, service, runtime and other content, process_dea_start will start the DEA must obtain such information, and then a series of operations, for example, from NFS obtain Droplet, extract, modify the necessary environment configuration, run the startup script and so on. Etc. Everything is ready, then need to send a message to the Router, tell it to the Droplet is ready to serve the country, after a corresponding request remember it to deal with.
d) Router module at boot time have subscribed to "router.register" message topic.
front DEA received information sent, it will trigger register_droplet method to bind the Droplet. Start a Droplet of this instance is completed.
CloudFoundry we can see the whole core is a set of messaging systems, if you want to understand the ins and outs CloudFoundry, to track complex message mechanism inside it is a very good way. On the other hand, CloudFoundry is a message-based distributed systems, message-oriented architecture is its horizontal expansion nodes, components, characteristics of self-discovery and other cloud based.
Cloud Foundry architecture simple introduction to this, in fact, as the first open-source PaaS, CloudFoundry framework there are many places you can learn a lot of details of the deal is very subtle, these elements if it is possible to continue in subsequent articles discuss this topic in depth Although CloudFoundry, in fact, only tasted, explain the overall framework, the target is to make us have sufficient background knowledge to build enterprise with CloudFoundry internal private PaaS. In summary, the author learned from the structure of CloudFoundry things:
1, message-based multi-component structure of the cluster is to achieve a simple and effective manner. Messages can be decoupled between the cluster nodes, so that self-registration, since the discovery of these large-scale data center in a very important function to be realized;
2, the appropriate level of abstraction, the template model used to facilitate third-party developers can easily extend functionality in CloudFoundry. CloudFoundry the DEA and the Service layer abstraction layer processing are done, corresponding to enable developers to easily develop for the CloudFoundry Runtime and Service. For example, in CloudFoundry just launched, only supports Node.js, Java, Ruby, but third-party providers, the open source community quickly followed, as CloudFoundry added PHP, Python support. Thanks CloudFoundry compact DEA architecture design, how to develop new Runtime support in subsequent Bowen is discussed.
Second, the source REVIEW
I have always felt a deep understanding of technology, the best way is to read its source code, but is completely open source CloudFoundry PaaS platform, because just developed, small amount of code, the main authors of the code skill is also quite good, read very comfortable, very suitable for reading. And again have to commend it is fully based messaging architecture design, component scalability, third-party access, etc. have done very well, the reader can learn a lot of thoughtful things. I highly recommend you read about its source code. You can find on Github CloudFoundry all the code: https://github.com/cloudfoundry, you will see several different Repositories, they are:
1, vcap: Cloud Foundry's Core, Or called Kernel;
2, vcap-service: Cloud Foundry's Service components. Cloud Foundry The service is provided as a plug, which it is easy for third-party developers and design service;
3, vmc: VMware Cloud CLI. was a Ruby application, the CLI interact with Cloud Foundry. Mainly through the analysis of user input CLI, Restful request to send CloudFoundry;
4, vcap-java: If your app is java development, and the need to interact with Cloud Foundry, such as obtaining the current serviceserver ip address, etc., you may need this jar, inside our Java development framework has been used to support It is also CloudFoundry bottom of Restful request packaging;
5, vcap-java-client: Cloud Foundry's Restful API of the Java package, with the above items are not the same, it's just a simple read CloudFoundry information, and put as a JavaBean;
6, vcap-test: Cloud Foundry's test cases;
7, vcap-test-assets: Cloud Foundry Some apps examples.
没有评论:
发表评论