Architecture of CloudFoundry(文档翻译)

下面的内容从摘要自CF的官网：http://docs.cloudfoundry.com/docs/running/architecture/

• Cloud Controller-管理着一个数据库，表中记录orgs, spaces, apps, services, service instances, user roles, and more。
• Droplet Execution Agent-管理应用实例的生命周期，跟踪启动了的实例，广播状态消息。
• Health Manager-监控应用，比对它们的实际状态与盼望的状态，不一致时指导Cloud controller做出处理。
• Messaging(NATS)-轻量级消息框架，基于发布-订阅及分布式。
• (Go)Router-接收外部请求，并负责路由到相应的模块(一般为cloud-controller或DEA节点上的运行应用)。
• Services-应用的外部依赖，比如数据库，或者第三方SaaS上的帐户。
• Stacks-预制文件，包含了一个操作系统，用于支持应用的某种特性。
• User Account and Authentication(UAA) Server-用于标准管理的服务
• Warden-提供API用于管理环境隔离与资源控制。

--下面针对这些模块逐个进行进一步的描述--

Cloud Controller

Ruby编写；提供REST API接入(管理客户端接入)；包含一个数据库用于管理orgs, spaces, apps, services, service instances, user roles。

 

Database(CC_DB)

使用Postgres 。对象-关系数据库。

 

Blob Store

大块数据存储，CC管理的大块数据包括：

resources(资源)- 上传到CC的文件，使用SHA进行计算散列码用于唯一标识文件。对于已经存在的文件，不需要下次上传时重传。

app packages(应用包)- 还没有打包(unstaged)的应用的文件。

droplets- app packages经过打包以后(执行对应的buildpack)，生成的准备执行的包。

--块存储的框架是使用ruby gem Fog ，它可以使用Amazon S3或者NFS-mounted文件系统。

 

NATS Messaging

CC与其它模块间的通信是使用NATS。如执行下面的消息传递：

• 运行应用前，命令DEAstage这个应用（processing a buildpack the app，命令DEA执行一个buildpack）。
• 命令DEA启动或停止应用。
• 接收HealthManager返回的应用的信息
• Subscribes to Service Gateways that advertise available services（订阅）当有可用的服务时接收通知。
• Instructs Service Gateways to handle provisioning, unprovision, bind and unbind operations for services

Testing

rspec 命令用于跑测试集，默认使用sqlite3数据库，也可以使用环境变量：DB_CONNECTION ，来替换为postgres and mysql。

DB_CONNECTION="postgres://postgres@localhost:5432/ccng" rspec
DB_CONNECTION="mysql2://root:password@localhost:3306/ccng" rspec

 

Logs

使用Steno 来管理日志。Each log entry includes a “source” field to designate which module in the code the entry originates from. Some of the possible sources are cc.app, cc.app_stager, cc.dea.client and cc.healthmanager.client.

 

Configuration

使用YAML来编写CC的配置文件，config/cloud_controller.yml. Some of the keys that are read from this configuration file are:

• logging - a steno configuration hash。
• bulk_api - basic auth credentials(证书) for the application state bulk API. In Cloud Foundry, this endpoint is used by the health manager to retrieve the expected state of every user application.
• uaa - URL and credentials for connecting to the UAA, Cloud Foundry's OAuth 2.0 server.

 

Droplet Execution Agent(DEA)

DEA核心功能：

• Manage Warden Containers- DEA负责打包应用，并且将应用跑在Warden Container上。
• Stage Applications-  当新的应用或者应用的新版本被push到CF时，CoudController负责从DEA池中取出一个可用的DEA进行打包。打包的过程就是使用相对应的buildpack来执行，产生的就是droplet。
• 运行Droplets- DEA管理着每一个在其上运行的应用的生命周期，听众CC的启动与停止应用命令，并监控应用的运用状态，定时通过NATs广播给HealthMnager。

Directory Server目录服务器

当DEA接收到访问目录或文件的请求时，会把请求转换为到目录服务器的URL，这个URL由DEA sign，目录服务器会先验证它的正确性。

目录服务器的行为可通过DEAF的dea.yml文件来配置。目录服务器是由go语言编写，在DEA源码的/go目录下。它替代了旧版本里DEA内置的目录服务器。

 

DEA健康检查

DEA定时检查运行应用的健康情况。检查方式如：如果应用有一个URL地址，那DEA就定时去连接这个URL的端口，如果连接被接收，DEA就认为这个应用的状态为"Running"；如果没有URL，DEA就查询进程表，查找应用对应的PID，如果PID在就是"Running"。

DEA也会检查 应用的AppState对象。

 

Usage

运行DEA：$bin/dea config/dea.yml   传入配置文件

 

DEA Configration

DEA的行为是通过dea.yml来配置的，yml文件里的几个配置项如下：

• logging- A Steno configuration.
• nats_uri — A URI of the form nats://host:port that the DEA will use to connect to NATS
• warden_socket — The path to a unix domain socket that the DEA will use to communicate to a warden server.

详细的配置项可看DEA的源码：DEA

下面是一个配置的示例

# See src/lib/dea/config.rb for optional config values.

# Base directory for dea, application directories, dea temp files, etc. are all relative to this.
base_dir: /tmp/dea_ng

logging:
  level: debug

resources:
  memory_mb: 2048
  memory_overcommit_factor: 2
  disk_mb: 2048
  disk_overcommit_factor: 2

nats_uri: nats://localhost:4222/

pid_filename: /tmp/dea_ng.pid

warden_socket: /tmp/warden.sock

evacuation_delay_secs: 10

index: 0

staging:
  enabled: true
  platform_config:
    cache: /var/vcap/data/stager/package_cache/ruby
  environment:
    PATH: /usr/local/ruby/bin
    BUILDPACK_CACHE: /var/vcap/packages/buildpack_cache
  memory_limit_mb: 1024
  disk_limit_mb: 2048
  max_staging_duration: 900 # 15 minutes

dea_ruby: /usr/bin/ruby

# For Go-based directory server
directory_server:
  v1_port: 4385
  v2_port: 5678
  file_api_port: 1234
  streaming_timeout: 10
  logging:
    level: info

stacks:
  - lucid64

# Hook scripts for droplet start/stop
# hooks:
#   before_start: path/to/script
#   after_start: path/to/script
#   before_stop: path/to/script
#   after_stop: path/to/script
## <a id='run-standalone'></a>Running the DEA Standalone ##

 DEA运行作为一个标准模块。This section has instructions for doing so on Vagrant 1.1x.

Refer to the Vagrant documentation for instructions on installing Vagrant.

 

下面是本机安装部署DEA，运行在Vagrant

$ git clone http://github.com/cloudfoundry/dea_ng
$ bundle install

# check that your version of vagrant is 1.1 or greater
$ vagrant --version

# create your test VM
$ rake test_vm

 

# initialize the test VM
$ vagrant up

# shell into the VM
$ vagrant ssh

# start warden
$ cd /warden/warden
$ bundle install
$ rvmsudo bundle exec rake warden:start[config/test_vm.yml] > /tmp/warden.log &

# start the DEA's dependencies
$ cd /vagrant
$ bundle install
$ git submodule update --init
$ foreman start > /tmp/foreman.log &

# run the dea tests
$ bundle exec rspec

 

 

Staging

有文章描述DEA的打包过程：How Applicatoins Are Staged 。中文翻译

在这个过程中，会有如下的消息发布到NATS：

• staging.advertise — Stagers (now DEA's) broadcast their capacity/capability

• staging.locate — Stagers respond to any message on this subject with a staging.advertise message (CC uses this to bootstrap)

• staging.<uuid>.start — Stagers respond to requests on this subject to stage applicationss

• staging — Stagers (in a queue group) respond to requests to stage an application (old protocol)

Logs

The DEA's logging is handled by Steno. The DEA can be configured to log to a file, a syslog server or both. If neither is provided, it will log to its stdout. The logging level specifies the verbosity of the logs (e.g. warn, info, debug).

 

NATS

http://docs.cloudfoundry.com/docs/running/architecture/messaging-nats.html

 

Services

添加services到CF的两种方式： Managed Services and User-provided Service Instances，前者是CF已经提供的可根据API调用获取服务实例，后者是一种扩展机制。

 

Managed Services

CF内置的服务实现了指定的API，CC是它的客户端，称为Service Broker API。与CC API不是一个概念；常说的“Cloud Foundry v2”就CC的版本，而不是这个。

Service Brokers是指那些实现了Service Broker API的服务模块，以前被称为Service Gateway。

 

Service Broker会向CF注册自己提供的服务，CF调用它是通过下面五个方法进行： fetch catalog, provision (create), bind, unbind, and deprovision (delete)，What a broker does with each call can vary between services; 

provision(供应) -预订服务上的资源

bind(绑定)-传递应用要获取服务的必要信息。

预订的资源被称为服务实例，服务实例的表现形式是由服务服务本身决定的，比如单个数据库的多租房方式；专门的集群，或者只是一个WEB应用的帐户。

 

Service Arthitecture服务框架

服务实现由开发者或厂商提供，实现Service Broker API，实现可以是一个单应用，也可以是通过HTTP请求已经存在的服务。几种常见的开发模型：

•  Entire service packaged(整个包) and deployed by BOSH alongside Cloud Foundry
• Broker的包由BOSH搞到CF上，剩下的以其它形态部署。
• Broker(及可先的服务)作为应用存在于CF的用户空间-Broker (and optionally service) pushed as an application to Cloud Foundry user space
• 整个服务，包括broker，部署与维护在CF之外-Entire service, including broker, deployed and maintained outside of Cloud Foundry by other means

 Service Broker API

可前是V2。V2API

 

Developing a Service Broker

 

1. 开发环境- 需要一个安装CF，对CF实例要有admin权限，可以部署一个全新的CF，通过 Both Lite 。
2. Documentation - Read the following docs:

• v2 Service Broker API
• Catalog Metadata
• Managing Service Brokers on CF
• Using Services

Examples - Refer to the example service brokers below as a starting point for developing your broker.

Ruby

1. GitHub repository service - this is designed to be an easy-to-read example of a service broker, with complete documentation, and comes with a demo app that uses the service. The broker can either be deployed as an application on CF or hosted anywhere. The service itself (GitHub) is separate from the broker.
2. MySQL database service - this broker and its accompanying MySQL server are designed to be deployed together as a BOSH release. BOSH is responsible for deployment and operation of all of the processes necessary for the service. The broker code can be found here.

Java

1. Spring Service Broker - this repo provides a template for building service brokers in Spring, and includes an example implementation for MongoDB.
2. MySQL Java Broker - a Java port of the Ruby MySQL broker above.

User-provided Service Instances

Both operators and developers frequently ask how applications pushed to their Cloud Foundry instances can bind with external services, such as Oracle, which they operate themselves or are outside of Cloud Foundry's control. User-provided Service Instances enable developers to use external services with their applications using familiar workflows.