木精灵的技术博客

前一阶段，在做Iron Foundry和Cloud Foundry的实验室工作，在成功完成Iron Foundry和Cloud Foundry的通信以后，特意去深入了解Iron Foundry和Cloud Foundry的源码区别。于是在github官网将Cloud Foundry的vcap和Iron Foundry的vcap的源码做了一回对比。由于对比程度比较浅层次，所以肯定会有疏漏的地

本文中cloud_controller_ng的架构出发，并进行了简单的解析。cloud_controller_ng是Cloud Foundry v2版本中的一个重要组件。其中cloud_controller_ng是cloud_controller的next generation（ng）的含义，而cloud_controller_ng的设计不兼容原先老版的cloud_controller。老版本的cloud_controller采用Rails的MVC框架来实现，而cloud_controller_ng则采用S

在Cloud Foundry中有一个叫collector的组件，该组件的功能是通过消息总线发现在Cloud Foundry中注册过的各个组件的信息，然后通过varz和healthz接口来查询它们的信息，最后再将各个组件收集过来的数据发送到指定的存储位置。本文从collector的功能出发，主要讲述以上三个功能的源码实现。

Cloud Foundry中所有的应用都运行在一个称为DEA的组件中，DEA的全称是Droplet Execution Agent。DEA的主要功能可以分为两个部分：运行所有的应用，监控所有的应用。本文主要讲解Cloud Foundry v1版本中DEA如何启动一个应用，以及DEA如何监控应用的资源使用。虽然DEA两个功能的实现远不止这么多，但是笔者认为启动应用和监控应用资源是DEA的精髓所在，很多其他的内容都是在这两个点上进行封装或者强化。

在Cloud Foundry v1版本中，router作为路由节点，转发所有进入Cloud Foundry的请求。由于开发语言为ruby，故router接受并处理并发请求的能力受到语言层的限制。虽然在v1版本中，router曾经有过一定的优化，采用lua脚本代替原先的ruby脚本，由lua来分析请求，使得一部分请求不再经过ruby代码，而直接去DEA访问应用，但是，效果依旧不是很理想。为了提高Cloud Foundry router的可用性，Cloud Foundry开源社区不久前推出了gorouter。g

在Cloud Foundry v2版本中，该平台使用warden技术来实现用户应用实例运行的资源控制与隔离。在网络方面，warden container技术创建出一块虚拟网卡，专门供warden container内部使用，另外为warden container内部的虚拟网卡在warden server所在的宿主机上也配对了一块虚拟网卡，充当container的外部网关。仅仅创建出两块虚拟网卡，原则上可以保证物理上的“连通”，但是却很难做到网络间通信的“联通”，故在物理资源以及虚拟物理资源完备的情况，wa

本文从Cloud Foundry中warden container入手，探讨warden container的安全性。主要集中在多租户container之间，container与云平台之间可能存在的安全问题。

在Cloud Foundry v2，DEA为一个用户应用运行的控制模块，而应用的真正运行都是依附于warden。更具体的来说，是DEA接收到Cloud Controller的请求；DEA发送请求给warden server；warden server创建warden container并将用户应用droplet等环境配置好；DEA发送应用启动请求至warden serve；最后warden container执行启动脚本启动应用。本文主要具体描述，DEA如何与warden交互，以保证最终用户的应用可以成功

在Cloud Foundry中，当应用开发者的应用由Cloud Foundry的组件DEA来运行时，应用的资源隔离与控制显得尤为重要，而warden的存在很好得解决了这个问题。Cloud Foundry中warden项目的首要目的是提供一套简易的接口来管理隔离的环境，这些隔离的环境可以被称为“容器”，他们可以在CPU使用，内存使用，磁盘使用以及设备访问权限方面做相应的限制。本文从warden架构入手，简要的介绍了warden client，warden server以及warden container的

在Cloud Foundry中，用户可以vmc create-service创建一个service instance，但是常规情况下，用户不能手动地进一步对service instance进行设计。以MySQL为例，用户可以创建一个MySQL instance，但是一般情况下，用户不能直接对整个MySQL的database进行schema设计，或者进行增删改查的操作。对于MySQL service

Cloud Foundry中有一个组件，名为Stager，它主要负责的工作就是将用户部署进Cloud Foundry的源代码打包成一个DEA可以解压执行的droplet。 关于droplet的制作，Cloud Foundry v1中一个完整的流程为：1.用户将应用源代码上传至Cloud Controller；2.Cloud Controller通过NATS发送请求至Stager，要求制作dropet；3.Stager从Cloud Controller下载压缩后的应用源码，并解压；4.Stager将解压后的

在Cloud Foundry v2中，当应用用户需要启动应用的实例时，用户通过cf CLI向cloud controller发送请求，而cloud controller通过NATS向DEA转发启动请求。真正执行启动的事，是由DEA来完成，DEA主要做的工作为启动一个warden container, 并将droplet等内容拷贝进入container内部，最后配置完指定的环境变量，在这些环境变量下启动应用的启动脚本。 本文将从阐述Cloud Foundry中DEA如何为应用实例的启动配置环

Cloud Foundry作为业界出众的PaaS平台，在应用的可扩展性方面做得非常优秀。 具体来讲，在一个应用需要横向伸展的时候，Cloud Foundry可以轻松地帮助用户做好伸展工作，也就是创建出一个应用的多个实例，多个实例地位相等，多个实例共同为用户服务，多个实例共同分担访问压力。 大致来说，可以认为是共同分担访问压力，但是也不是针对所有该应用的访问，都进行均衡，分发到不同的应用实例处。譬如：当Cloud Foundry的访问用户访问应用时，第一次的访问，goroute

在Cloud Foundry中，应用在DEA上运行，而应用在自身的生命周期中，自身的文件目录也会随着不同的周期，做出不同的变化。        本文将从创建一个应用（start an app），停止一个应用（stop an app），删除一个应用（delete an app），重启一个应用（restart an app），应用crash，关闭dea，启动dea，dea异常退出后重启，这几个

在上篇中谈到了micro Iron Foundry和micro Cloud Foundry的安装事宜，那紧接着自然是安装Iron Foundry和Cloud Foundry，和了解熟悉这两者。Requirements首先需要了解的还是安装的一些前提条件。这次的安装环境貌似要比上次宽松不少，这里需要两台机器（物理机，虚拟机均可，这里不涉及nested VMs和VT支持的问题，而笔者是

熟悉Cloud Foundry的技术人员，肯定对cloud_controller不陌生。cloud_controller作为Cloud Foundry的管理模块，一方面管理用户的RESTful请求，另一方面将一些重要的配置性信息持久化，存入cloud_controller节点处的数据库。       关于cloud_controller节点处的数据库，深入一些了解Cloud Foundry，就

8月的下半月和9月初，都在折腾micro Cloud Foundry和micro Iron Foundry。还真是“折腾”二字，现在就从刚开始接触这两者谈起，直至成功安装完毕。        在这里，就不再赘言Cloud Foundry了，还是先说一下Iron Foundry吧。在我看来，Iron Foundry就是一个为了使 .net 框架的应用可以在Cloud Foundry上push的D

本报告从两个方面讲述Cloud Foundry中的组件Service Gateway：Service Gateway的功能和Service Gateway的通信机制。 1. Service Gateway的功能Service Gateway 在CloudFoundry中的作用主要是：接收Cloud Foundry中的控制器Cloud Controller发来的请求，并根据请求类型，对S

最近由于实验室工作的需要，有一些时间在做Cloud Foundry上对于著名的报表引擎JasperReports的支持。关于官方的讲述可以参考地址：http://blog.cloudfoundry.com/2012/01/12/java-reporting-engine-is-now-available-on-cloud-foundry-via-jasperreports/

Cloud Foundry是一个开源的平台即服务产品，它提供开发者自由度去选择云平台，开发框架和应用服务。而Cloud Foundry中，服务则是体现了应用程序的高级功能，正是由于服务Service的存在，用户得以加速应用部署和简化应用管理。首先，还是简要的介绍一下Cloud Foundry的Service。        目前Cloud Foundry的Service主要包括三方面：1.数据

目前，CloudFoundry已经集成了很多第三方的中间件服务，并且提供了用户添加自定义服务的接口。随着Cloud Foundry的发展，开发者势必会将更多的服务集成进Cloud Foundry，以供app使用，也扩展了app的功能。本部分主要描述通用service集成进入Cloud Foundry所需要做的设计以及实现。 1. service概念的对应将通用的service类型集

Cloud Foundry支持的现有服务中，大多数都属于传统的关系型数据库以及NoSQL数据库。在这两类数据库服务中，提供service服务，相当于由数据库server提供数据存储的服务，换言之，也就是由数据库server端创建database，然后将该database转交给Cloud Foundry的app应用使用。JasperReports service的实现首先需要完成JasperReportsservice中的数据表现形式以及存储形式。由于在上一部分以及抽象归纳出JasperReports se

Cloud Foundry作为业界最出色的PaaS平台之一，给广大的互联网开发者和消费者提供出色的体验。自Cloud Foundry开源以来，有关Cloud Foundry的研究越来越多，这也很好的支持着Cloud Foundry的生态系统。但是作为一个平台，Cloud Foundry仍然会存在一些可靠性，扩展性方面的不足，这也吸引着众多的Cloud Foundry爱好者对其进行更多更深入的研究。

Cloud Foundry中，用来收集Cloud Foundry各组件日志信息的组件，名为syslog_aggregator。syslog_aggregator可以做到方便的收集Cloud Foundry中所有组件的日志信息，并将这些信息进行初步处理。syslog_aggregator组件主要包括monit模块，日志管理模块。

/dea_ng/lib/dea/ 目录下各文件的作用简介bootstrap.rb：主要负责配置dea_ng其他的模块，另外还负责将这些模块启动工作，主要的模块有nats,logging,loggregator,droplet_registry ,instance_registry,staging_task_registry,instance_manager ,snapshot ,resourc