木精灵的技术博客

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

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

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

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

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

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

Docker是PaaS圈内开源的基于LXC的应用容器引擎，基于Go语言开发，遵从Apache2.0协议。最近一年来，Docker在云计算方面的热度持续升温，社区等活跃度也持续走高，使得大家对于Docker普遍持有积极态度。笔者在研究生期间，主要从事PaaS方面的研究与实践工作，具体的研究平台为开源的Cloud Foundry。最近Docker的火热，更是让自己处于对Docker的学习过程中，不能自拔。

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

本文是Jason Wilder对于常见的服务发现项目Zookeeper，Doozer，Etcd所写的一篇博客，其原文地址如下：Open-Source Service Discovery。 服务发现是大多数分布式系统以及面向服务架构（SOA）的一个核心组成部分。这个难题，简单来说，可以认为是：当一项服务存在于多个主机节点上时，client端如何决策获取相应正确的IP和port。 在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。但是

很多时候，当大家谈论起Docker，经常会提到Docker作为容器解决方案，在虚拟化资源方面存在不小优势。轻量级虚拟化技术的优点暂且不谈，从软件生命周期来看，Docker在打包软件、分发软件方面的能力同样出众。而后者很大程度上依赖于Docker的镜像技术。Docker镜像技术提供了一套标准，创造性地使用Dockerfile来规范化Docker化应用的制作流程，结果产生的Docker镜像便于传输与管理

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

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

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

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是一个开源的平台即服务产品，它提供开发者自由度去选择云平台，开发框架和应用服务。而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中有一个组件，名为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 v1版本中，router作为路由节点，转发所有进入Cloud Foundry的请求。由于开发语言为ruby，故router接受并处理并发请求的能力受到语言层的限制。虽然在v1版本中，router曾经有过一定的优化，采用lua脚本代替原先的ruby脚本，由lua来分析请求，使得一部分请求不再经过ruby代码，而直接去DEA访问应用，但是，效果依旧不是很理想。为了提高Cloud Foundry router的可用性，Cloud Foundry开源社区不久前推出了gorouter。g

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

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

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

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

第一部分：Docker镜像的基本知识1.1 什么是Docker镜像从整体的角度来讲，一个完整的Docker镜像可以支撑一个Docker容器的运行，在 Docker容器运行过程中主要提供文件系统视角。例如一个ubuntu:14.04的镜像，提供了一个基本的ubuntu:14.04的发行版，当然此 镜像是不包含操作系统Linux内核的。说到此，可能就需要注意一下，linux内核和ubuntu:14.04