cloudFoundry源码学习

cloud foundry之vmc代码解读

vmc其实是使用ruby来实现的一整套的cli命令转化为http restful请求的对应工具。

其代码位于：https://https://www.360docs.net/doc/ff19018301.html,/cloudfoundry/vmc

git clone回来代码之后，下面对代码进行半瓶水解析法解析。

入口

bin/vmc

引用了$github/vmc/lib/cli

直接运行VMC::Cli::Runner.run

位于：lib/cli/runner.rb

看上去run会被执行。

进入到parse_command!方法中

以push为例：

when 'push'

usage('vmc push [appname] [--path PA TH] [--url URL] [--instances N] [--mem] [--runtime RUNTIME] [--no-start]')

if @args.size == 1

set_cmd(:apps, :push, 1)

else

set_cmd(:apps, :push, 0)

end

进入到set_cmd中设置变量

module Cli

:Runner

module Command

:Apps

然后

cmd = VMC::Cli::Command.const_get(@namespace.to_s.capitalize)

cmd.new(@options).send(@action, *@args.collect(&:dup))

最终

VMC::Cli::Command::Apps.new().send(push)

（在ruby语法中，此处send方法是一个关键词，表示callMethod)

于是来到了lib/cli/commands/apps.rb

def push(appname=nil)

def do_push(appname=nil)

upload_app_bits(appname, @application)

def upload_app_bits(appname, path)

client.upload_app(appname, file, appcloud_resources)

lib/vmc/clinet.rb

def upload_app

http_post(path(VMC::APPS_PA TH, name, "application"), upload_data)

def http_post(path, body, content_type=nil)

def request(method, path, content_type = nil, payload = nil, headers = {})

perform_http_request

RestClient::Request.execute(req)

于是就没有了（RestClient是ruby中一个rest库）。

cloud foundry之cloud_controller代码解读

cloud_controller是其管理界面的http rest api入口。

补课rails

Rails基于MVC（模型- 视图- 控制器）设计模式。从视图中的Ajax应用，到控制器中的访问请求和反馈，到封装数据库的模型，Rails 为你提供一个纯Ruby的开发环境。

习惯约定大于配置：

model类位置app/models/xxx.rb

controller位置app/controllers/xxx_controller.rc

help位置app/helpers/xxx_helpers.rb

view位置app/views/xxx

对应布局app/views/layouts/xxx.rhtml xxx.rxml

开始cloud_controller

https://https://www.360docs.net/doc/ff19018301.html,/cloudfoundry/cloud_controller

里面有两个项目，一个是cloud controller另一个是health_manager，今天要研究的是前者，下节说后者。

入口

bin/cloud_controller -> config/boot.rb

cloud_controller必需要求ruby1.9以上，因为其中有一个fiber需要ruby支持（传说中的Coroutine）。

如果没有配置cloud_controller使用nginx，则会启用Thin去启动Rack。（Thin是ruby内置的network server，Rack: a Ruby Webserver Interface）

app

以vmc push举例：

vmc push的关键一请求：post apps

对应app/controllers/apps_controller.rb

def create

update_app_from_params(app)

检查各种参数并赋值

app.save! (app使用了ActiveRecord::Base，ActiveRecord是ruby用来做orm的东东，具体可以认为save!就是入库了)

stage_app(app)

去nats注册：result = client.stage(request, AppConfig[:staging][:max_staging_runtime])

关键点

cloud_controller接收到请求记录到db:postgresql/sqlite(cloud_controller.yml中定义)。

请求同时发送到nats等进一步处理。

vmc push所做的事情

1．发一个POST到”apps”，创建一个app; (本文只做了这一步的分析)

2．发一个PUT到”apps/:name/application”，上传app;

3．发一个GET到”apps/:name/”，取得app状态，看看是否已经启动；

cloud foundry之warden代码解读-part1

warden是其核心部分的资源管理容器，完成了各种资源分配的事情。

代码位置在：https://https://www.360docs.net/doc/ff19018301.html,/cloudfoundry/warden

这一部分也是我最想了解细节的地方，因为在一个paas平台中，资源的隔离才是最有价值的部分。

基础知识

rv = unshare(CLONE_NEWNS);

unshare这个调用，可以把挂载的文件系统设置成只在新的挂载命名空间（mount namespace）中可见。

execvp(argv[0], argv);

execvp()会从PATH 环境变量所指的目录中查找符合参数file 的文件名，找到后便执行该文件，然后将第二个参数argv传给该欲执行的文件。

shopt -s nullglob

设置shell环境变量nullglob的值为on，nullglob为on时对于通配符匹配时，若匹配不到时为空（相对应的为通配符本身）。

int stat(const char *restrict pathname, struct stat *restrict buf);

提供文件名字，获取文件对应属性。

build-essential软件包

作用是提供编译程序必须软件包的列表信息，也就是说编译程序有了这个软件包，它才知道头文件在哪，才知道库函数在哪，还会下载依赖的软件包，最后才组成一个开发环境。

工具debootstrap

可以用于在系统的某个目录中安装一套基本系统，这个基本系统除了一些配置项外，与ubuntu安装程序在安装的第一阶段安装的内容基本相同。这项功能有许多有趣的功能，例如，你可以从某个定制版本的ubuntu Live光盘上通过这个命令快速的在硬盘上安装ubuntu而不需要ubuntu的安装程序，也可以把创建在硬盘上的基本系统目录作为某些涉及系统安全性服务的chroot运行环境，通过chroot进入该目录并调试和运行一些可能修改系统配置的应用程序，作为定制小型系统模板等等。

aufs

一种文件格式，可以mount到目录，同时控制只读和读写。

overlayfs

另一种文件格式，在ubuntu 11.04后开始替代aufs作为官方livecd的文件格式。

cloud foundry之warden代码解读-part2

代码结构

|-- em-warden-client 基于eventmachine的client 依赖warden-client与warden-protocol 通过unix socket来通讯

|-- warden 巨复杂的warden实现，大部分是shell脚本+ruby，还有两个c实现。

|-- warden-client 客户端驱动，提供与warden的阻塞式通讯client。依赖warden-protocol。其

中的V1.rb对各自command进行解析之后的处理。这里有一个v1mode的概念，v1mode 使用字符串，转为pb后与其他的一起使用protobuf。

`-- warden-protocol 依赖beefcake(protobuf library for Ruby)。protocol下有所有支持的pb生成格式。

小坑：ruby中的send方法

send其实就是动态地根据名字调用函数，传递后面的内容作为调用参数，api函数原型为：obj.send(symbol [, args...]) => obj

在V1.rb中，所能的convert_xxxx_request方法都是这样被调用到的。

专注warden实现

src下四个C程序：

|-- clone 用来快速复制一个环境夹杂一堆的shell在其中运行

|-- iomux 分成两个部分：iomux-spawn把子进程的pid写到stdout来标示它已经做好准备接收连接。在尝试连接之后一直等待。iomux-link是用来根据pid重新link到其上去。

|-- oom 通过eventfd得到内存不够的通知

`-- repquota 报告quota使用情况

四个c程序将在编译后复制到root/linux/skeleton/bin中

其他目录：

|-- bin 下面有两个脚本文件，用来启动和进入命令行的

|-- config 下面有一个配置文件，定义了linux下的配置

|-- lib 所有的ruby代码

|-- root 各种shell脚本，操作cgroup之类的

启动warden

环境：

chenzhen@ubuntu-chenzhen:~/warden/warden$ lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 12.04 LTS

Release: 12.04

Codename: precise

$cd warden/warden

$sudo bundle exec rake setup[config/linux.yml]

$sudo bundle exec rake warden:start[config/linux.yml]

$ctrl+z

$bg

$sudo bundle exec bin/warden-repl

$ping

...pong

调用过程：

bin/warden-repl >> lib/warden/repl.rb >> Warden::Client >> warden.sock >> lib/warden/server.rb << Warden::Server.run! << Rakefile

处理调用：

server.rb > ClientConnection > receive_request > process(request) > process_container_request(request, container) > base.rb > dispatch(request, &blk) > send(do_method, request, response, &blk) -> linux.rb > do_xxx > shell script

clone.c分析：

src/clone/clone.c: main ->

console.c: openpty ->

clone.c: daemonize ->

barrier.c: barrier_open ->

clone.c: run("./hook-parent-before-clone.sh"); ->

clone.c: parent_clone_child ->

clone.c: pid = clone(start, stack, flags, h); ->

clone.c: start() ->

console_mount(&h->console, "dev/console"); ->

pivot_root ->

clone.c: run("./hook-parent-after-clone.sh"); ->

clone.c: barrier_signal(&h->barrier_parent); ->

clone.c: barrier_wait(&h->barrier_child);

cloud foundry之warden代码解读-part3

根据part2里提到的过程，本节以create命令为例进行追踪。

调用过程：

bin/warden-repl >> lib/warden/repl.rb >> Warden::Client >> warden.sock >> lib/warden/server.rb << Warden::Server.run! << Rakefile

处理调用：

server.rb > ClientConnection > receive_request > process(request) > process_container_request(request, container) > base.rb > dispatch(request, &blk) > send(do_method, request, response, &blk) -> linux.rb > do_xxx > shell script

过程放大

一、进入repl命令行

1.1 名词bundle：主要用于管理Ruby应用程序的依赖关系，并按照此依赖关系安装所需的Gems。当运行bundle install命令来安装Gems时，bundler会使用当前目录下的名为Gemfile 的文件来处理依赖关系。

gem：就是ruby的软件包，一个gem就是一个ruby软件。

Gemfile：定义了各种依赖情况，bundler命令必须在存在此文件的目录下执行。

Gemfile.lock：记录本机目前所有依赖的gem命令和版本。

rake：编译工具，类似java的ant。

Rakefile：rake命令所定义的配置任务文件，类似ant.xml。

1.2 进入#sudo bundle exec bin/warden-repl

使用bundle exec来保证项目依赖的gem版本。在bin目录下有warden-repl脚本（ruby），这将会执行lib/warden/repl.rb文件，先会使用Warden:Client发起对warden.sock的连接，然后在start方法中对命令行模式的交互进行反馈。

二、输入create

当输入create时，repl.rb执行到process_line中的respond_to的判断：

2.1 respond_to?if respond_to? words[0].to_sym。。。

这种写法的意思是，当前对象中是否有方法名为words[0].to_sym变量值的方法。

2.2 createrepl.rb果断有这个create方法，然后talk_to_warden。就进入了client写的过程了。

三、warden收到create的响应

3.1 warden server的启动早在part2中，使用了命令：

sudo bundle exec rake warden:start[config/linux.yml]

就已经启动了warden。

这将使在bundle定义的环境下，执行warden/warden/Rakefile里写好的任务：Warden::Server.run!。

3.2 warden server的响应在lib/warden/server.rb中，run!方法下，使用了EM的start_unix_domain_server的方法启动了一个unixsock，第二个参数ClientConnection定义了接收到东西怎么处理。

ClientConnection中的process方法具体处理了create：

when Protocol::CreateRequest

container = Server.container_klass.new

container.register_connection(self)

response = container.dispatch(request)

container_klass为配置中的Warden::Container::Linux。

最终，将会执行linux.rb中的do_create方法。

四、shell脚本中的猫腻

warden/root/linux中，有大量的sh脚本，里面通过一系列的命令，完成了基础环境的搭建，非常值得一读。

4.1 linux/base/setup.sh这个脚本在运行安装warden时会被执行，按照执行过程：

1）分析本机最近的apt源地址。

2）debootstrap到/tmp/warden中

3）debootstrap的作用见前面的文章，主要是可以用于在系统的某个目录中安装一套基本系统. https://www.360docs.net/doc/ff19018301.html,/architecture/cloud-foundry-warden-part1.html

4）使用chroot将子系统中的缺失软件安装好

4.2 base.rb的dispatch create过程1）拼接before_create

2）执行linux.rb中的features/quota.rb的before_create方法

2.5）执行base中的before_create方法，产生一个十六进制的handle值（也就是每个contaner 的标识）

3）setquota

4）linux.rb do_create

4.3 linux.rb的do_create过程1）create.sh脚本的执行：传入目录，检查是否存在；unshare -m setup.sh。

2）unshare的作用是在指定的环境下执行程序setup.sh，不影响上一级环境。

3）此处的setup.sh与base/setup.sh相比，没有了debootstrap的过程。

4）setup.sh中设置了cgroup、磁盘挂载、限额、网络。

5）紧接着如果需要会执行hook-parent-before-clone.sh

6）修改limits.conf的参数

7）执行start.sh：建立子网，打通两条ssh通道。

8）完成create

五、交互演示

$ sudo bundle exec bin/warden-repl

warden> list

["16bp35aue5i"]

warden> stop 16bp35aue5i

"ok"

warden> list

["16bp35aue5i"]

warden> destroy 16bp35aue5i

"ok"

warden> list

nil

warden> create

16bp35aue5j

warden> info 16bp35aue5j

{"state"=>"active",

"host_ip"=>"10.254.0.5",

"container_ip"=>"10.254.0.6",

"container_path"=>"/tmp/warden/containers/16bp35aue5j",

"memory_stat"=>

,

"cpu_stat"=>

,

"disk_stat"=>

}

warden> spawn 16bp35aue5j w

2

warden> link 16bp35aue5j 2

exit status: 0

stdout:

03:18:51 up 29 days, 14:51, 0 users, load average: 0.00, 0.04, 0.05

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHA T

stderr:

cloud foundry之dea代码解读

cloudfoundry是vmvare推出来的开源PaaS平台，dea（DropletExecution Agent）是其应用运行的环境，一个DEA可以启动多个应用。

代码位置在：https://https://www.360docs.net/doc/ff19018301.html,/cloudfoundry/dea

这一部分也是我最想了解细节的地方，因为在一个paas平台中，资源的隔离才是最有价值的部分。

历史

初始版的dea基本不控制系统资源，然后基于cgroup搞了一个warden（真正的资源隔离是它，下节再述），程序运行容器。cf希望warden运行在多个平台上，所以没有直接使用LXC。代码

代码入口在lib/dea.rb:

EM.epoll

EM.run {

agent = DEA::Agent.new(config)

agent.run()

}

EM是ruby有名的eventmachine，是一个事件驱动网络框架，从java程序员的角度，可以理解有点像mina，也可以认为有点像erlang的gen_server。

然后进到lib/dea/agent.rb:

NA TS.start(:uri => @nats_uri) do ...

里面注册了各种各样的收到对应消息干什么活的定义，我们来看其中几条线：

1. 收到update:

NA TS.subscribe('dea.update') { |msg| process_dea_update(msg) }

上一句是说收到update的指令，process_dea_update里面关键的一句：

register_instance_with_router(instance, :uris => (uris - current_uris))

通过NATS告诉router，新的app来了。

2.收到start:

NA TS.subscribe("dea.#{uuid}.start") { |msg| process_dea_start(msg) }

在process_dea_start里面：

start_operation = lambda do... 把app下载回来，修改好权限什么的。

下面用了fiber（它是ruby里的协程，用来达到异步线程的效果，但是开销要比线程低）：f = Fiber.new do..

f.resume

在协程中，最关键的调用：

stage_app_dir(bits_file, bits_uri, sha1, tgz_file, instance_dir, runtime)

bind_local_runtime(instance_dir, runtime)

startup_contents.gsub!('%VCAP_LOCAL_RUNTIME%', runtime['executable']) // 替换运行时路径

File.open(startup, 'w') { |f| f.write(new_startup) } #写入运行的脚本

一切就绪之后，调用先前准备好的lambda:

start_operation.call

然后去运行各种shell命令，包括启动应用。

cloud foundry之router代码解读

cloudfoundry是vmvare推出来的开源PaaS平台，router是其所有请求的入口路由，其与nginx 进行配合完成各种情况情况下的转发。

代码位置在：https://https://www.360docs.net/doc/ff19018301.html,/cloudfoundry/router

历史

第一版的router直接通过unix sock将http request通过nginx的proxy 发到了router.rb中处理，第二版的时候，因为ruby直接处理请求性能不行，换成了lua脚本来接收请求，再由ruby程序将结果返回。

目录结构

router代码不多，共有下面的一些主要目录。

.

├──bin

│└──router （启用router server的脚本）

├──config

│├──router2.yml

│└──router.yml （配置文件，指定了服务的端口和消息队列pid等）

├──ext

│└──nginx

│├──tablesave.lua

│└──uls.lua （这两个lua脚本供nginx conf使用，实现用户第一次访问时生成一个cookies，lua让其去同一个地方）

├──Gemfile

├──Gemfile.lock

├──lib

│├──router

││├──const.rb

││├──router.rb

││└──router_uls_server.rb （基于一个简单的web框架(Sinatra)开发的一些http api）│└──router.rb（负责整体启动router的http server）

├──LICENSE

├──NOTICE

├──Rakefile

├──README

└──spec

├──functional

│├──router_spec.rb

│└──spec_helper.rb

├──integration

│├──router_spec.rb

│└──spec_helper.rb

├──lib

│├──nats_timeout.rb

│└──spec_helper.rb

├──Rakefile

├──spec_helper.rb

└──unit

└──router_spec.rb

nginx的关键配置

nginx对接的配置在https://https://www.360docs.net/doc/ff19018301.html,/cloudfoundry/vcap/blob/master/dev_setup/cookbooks/nginx/templates/default/r outer-nginx.conf.erb，是动态生成的，在安装时决定。

其中，关键的内容是：

#定义lua运行的环境

lua_package_path "/?.lua;;";

lua_package_cpath "/?.so;;";

#upstream定义到nls服务上

upstream router_status {

server :;

}

其中，根据health_monitor的值穿插了subrequest去query /vcapuls的subrequest，而/vcapuls 是接到router.sock的。

简单地说，第二版的变化在于，大量的业务请求在health_moniter确定之后，变成了nginx 直连下属业务，而不再经过router了。

学到什么

1.nginx_lua相当好用，还得感谢之前的老同事agentzh他们的贡献;

2.router用http这么来回的搞感觉不如tcp来得靠谱。