木精灵的技术博客

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

本文从Docker的源代码出发，简要介绍了Docker作为一个后台进程启动过程中运行的流程。

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

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

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

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

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

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

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

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将解压后的

在上文Docker源码分析之——Docker Daemon启动 中，介绍了Docker Daemon进程的启动。Docker Daemon可以认为是一个Docker作为Server的运行载体，而真正发送关于docker container操作的请求的载体，在于Docker Client。本文从Docker源码的角度，分析Docker Client启动与执行请求的过程。