Shulou(Shulou.com)06/01 Report--

This article shows you what the role of the various components of CloudFoundry is, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Router

Router is the traffic entrance of the entire platform, which is responsible for distributing all requests to the corresponding components, including requests from external users for app and management requests within the platform.

Router is a vital component of the PaaS platform. It maintains a routing table in memory and records the corresponding relationship between domain names and instances. The so-called automatic instance migration depends on this routing table. When an instance goes down, it is removed from the routing table. When a new instance is created, it is added to the routing table.

Router in CloudFoundry1.0 is implemented in nginx+lua embedded script, 2.0 is rewritten in golang, renamed to gorouter, performance has been improved, and claims to try to solve websocket requests and tcp requests (although this in the author's view is useless), its code in https://github.com/cloudfoundry/gorouter, you can study.

Authentication

This block contains two components, one is Login Server, responsible for login, the other is OAuth3 Server (UAA), UAA is a Java project, if you want to find an open source OAuth3 solution, you can try UAA

Cloud Controller

Cloud Controller is responsible for managing the entire lifecycle of app. When users deal with CloudFoundry Server through the command line tool cf, they actually mainly interact with Cloud Controller.

The user sends the app push to Cloud Controller,Cloud Controller and stores it in Blob Store, creates a record for the app in the database, stores its meta information, and specifies a DEA node to complete the packaging action, producing a droplet (a package containing Runtime that can be warden run on any dea node). After the packaging is completed, the droplet is passed back to Cloud Controller and still stored in Blob Store, and then Cloud Controller according to the number of instances required by the user Schedule the corresponding DEA node deployment to run the droplet. In addition, Cloud Controller maintains user organization relationships org, space, as well as services, service instances, and so on.

Health Manager

Health Manager was originally written in Ruby, and later wrote a version in golang, called HM9000,HM9000, which has four core functions:

Monitor the actual running status of app (such as running, stopped, crashed, etc.), version, number of instances, etc. DEA will continue to send heartbeats to report the instance information under its jurisdiction. If an instance dies, it will immediately send a "droplet.exited" message, and HM9000 will update the actual running data of app accordingly.

HM9000 obtains the expected state, version and number of instances of app through dump Cloud Controller database.

HM9000 continuously compares the actual running state and expected state of app. If it is found that the number of running instances of app is less than the required number of instances, it will issue a command to Cloud Controller, requiring the corresponding number of instances to be started. HM9000 itself will not ask DEA to do anything. It just collects data, compares it, collects data, compares it again.

Users can control the start and stop status of each instance of app through the cf command line tool. If the state of app changes, HM9000 will order Cloud Controller to make adjustments accordingly.

In the final analysis, HM9000 is a basic component to ensure the availability of app. When the app runtime exceeds the assigned quota, or exits abnormally, or the entire DEA node is down, HM9000 will detect it, and then command Cloud Controller to migrate the instance. The code of HM9000 is here: https://github.com/cloudfoundry/hm9000, interested students can study it.

Application Execution (DEA)

DEA, or Droplet Execution Agent, is deployed on all physical nodes, manages app instances, and broadcasts status information. For example, if we create an app, the instance creation command will eventually be sent to DEA,DEA to call the API of warden to create container. If a user wants to delete an app, the instance termination command will eventually be issued to the API of DEA,DEA calling warden to destroy the corresponding container.

When CloudFoundry was first launched, Droplet included simple commands such as start and stop of the application. User applications can access the file system at will, or they can run full of CPU, memory and disk in the intranet without hindrance. Every destructive operation you can think of can be done. It's terrible. CloudFoundry obviously won't let this happen for long, and now they've developed Warden, a container for running programs. This container provides an isolated environment, Droplet can only get limited CPU, memory, disk access, network access, there is no way to destroy it.

The implementation of Warden on Linux is to divide the resources of the Linux kernel into several namespace, and the underlying mechanism is CGROUP. This design has better performance, faster startup and sufficient security than the virtual machine. On the network side, each Warden instance has a virtual network interface, each interface has an IP, and the DEA has a subnet, and these network interfaces are connected to this subnet. Security can be ensured through iptables. On the disk side, each warden instance has its own filesystem. These filesystem are implemented using aufs. Aufs can share read-only content between warden, distinguish write-only content, and improve the utilization of disk space. Because aufs can only read and write on files of a fixed size, there is no possibility that the disk will be full.

LXC is another Linux Container. So why not use it and develop Warden instead. Because the implementation of LXC is tied to Linux, CloudFoundry wants warden to run on different platforms, not just Linux. In addition, Warden provides a Daemon and several Api to operate, LXC provides system tools. And the most important thing is that LXC is so large that Warden only needs a little bit of it, and less code is easy to debug.

Service Brokers

When app runs, it usually depends on some external services, such as database service, cache service, SMS service and so on. Service Broker is a way for app to access services. For example, if we want to access the MySQL service, we only need to implement the Service Broker API required by CloudFoundry. But the reality is that before we use CloudFoundry, MySQL services have been serviced and produced by DBA, which is very convenient to use. Is it necessary to implement its Service Broker API and play cards according to the rules of CloudFoundry? The author does not think it is necessary. App can still do it the way it used to access the MySQL service, without any problems.

Message Bus

CloudFoundry uses NATS as the medium of communication between internal components. NATS is a lightweight distributed message queuing system based on pub-sub mechanism, which is the cornerstone of loose coupling of the whole system.

Let's take registering a route with router as an example to illustrate the role of NATS. No matter the requests made by external users to applications on the platform or to internal components (such as Cloud Controller, UAA) are forwarded through router, in order to enable router to forward, you need to register routing with router first. The general logic implementation is as follows:

When router starts, it subscribes to the router.register channel and sends data to the router.start channel on a regular basis.

Other components that need to register with router will subscribe to the router.start channel at startup. As soon as the message is received, the information that needs to be registered (such as ip, port, etc.) is collected immediately, and then the message is sent to router.register, the channel.

Router updates routing information as soon as it receives the router.register message

The above processes are constantly cycled to keep the status of router up to date

Logging and Statistics

Metrics Collector collects monitoring data from various modules, and operation and maintenance engineers can monitor CloudFoundry accordingly, find problems and deal with them in time. The hardware monitoring of the physical machine can be done by some traditional monitoring systems, such as zabbix.

Log is a big topic, and CloudFoundry provides Log Aggregator to collect app log. We can also type log directly through the network through other means, such as syslog, scribe and so on.

The above is what the functions of the various components of CloudFoundry are, have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.