在生产中使用金丝雀部署来进行测试

根据Nolio发布的DevOps最佳实践系列中的第一个demo,很多公司通过路由策略选择性地对部分用户发布新功能从而使用 “金丝雀部署(Canary Deployments)”来测试生产中的软件,并将这一方式作为其可持续交付的一部分。“金丝雀部署”是增量发布的一种类型,它的执行方式是在原有软件生产版本可用的情况下,同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。

继续阅读

Cloud Foundry中warden的架构与实现

在Cloud Foundry中,当应用开发者的应用由Cloud Foundry的组件DEA来运行时,应用的资源隔离与控制显得尤为重要,而warden的存在很好得解决了这个问题。

Cloud Foundry中warden项目的首要目的是提供一套简易的接口来管理隔离的环境,这些隔离的环境可以被称为“容器”,他们可以在CPU使用,内存使用,磁盘使用以及设备访问权限方面做相应的限制。

本文将从四个方面进行探讨分析warden的实现:

  1. warden的功能介绍及框架实现
  2. warden框架的对外接口及实现
  3. warden框架的内部模块及实现
  4. warden的运行示例

继续阅读

Cloud Foundry中DEA与warden通信完成应用端口监听

在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中gorouter对StickySession的支持

Cloud Foundry作为业界出众的PaaS平台,在应用的可扩展性方面做得非常优秀。

具体来讲,在一个应用需要横向伸展的时候,Cloud Foundry可以轻松地帮助用户做好伸展工作,也就是创建出一个应用的多个实例,多个实例地位相等,多个实例共同为用户服务,多个实例共同分担访问压力。

大致来说,可以认为是共同分担访问压力,但是也不是针对所有该应用的访问,都进行均衡,分发到不同的应用实例处。譬如:当Cloud Foundry的访问用户访问应用时,第一次的访问,gorouter会将请求分发到应用的某个实例处,但是如果该用户之后的访问都是有状态的,不希望之后的访问会被分发到该应用的其他实例处。针对以上这种情况,Cloud Foundry提供了自己的解决方案,使用StickySession的方式,保证请求依旧分发给指定的应用实例。

本文即分析Cloud Foundry中gorouter关于StickySession的实现方式。

继续阅读

Cloud Foundry中DEA启动应用实例时环境变量的使用

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

本文将从阐述Cloud Foundry中DEA如何为应用实例的启动配置环境变量。

继续阅读

Haproxy端口映射(client头中URL/HOST修改后转发)

CloudFoundry是对域名强依赖的云计算集群,没有域名的话几乎无法访问。但是域名备案等事宜所耗时间较长,在上线较为紧急的情况下,就需要实现直接通过“IP+端口”的形式,在公网访问CF集群上部署的APP。

解决方案

配置两层Haproxy,第一层的Haproxy与公网地址绑定。 对第一层的Haproxy进行配置,把外部通过IP+PORT访问的地址映射到后端第二层Haproxy,并把其访问的http Head修改,把Host字段改成能被Cloudfoundry接受的url字符串。 第二层Haproxy就跟CloudFoundry官方配置相同,作为负载均衡把流量导向下层多个gorouter。

继续阅读

Cloud Foundry中gorouter源码分析

在Cloud Foundry v1版本中,router作为路由节点,转发所有进入Cloud Foundry的请求。由于开发语言为ruby,故router接受并处理并发请求的能力受到语言层的限制。虽然在v1版本中,router曾经有过一定的优化,采用lua脚本代替原先的ruby脚本,由lua来分析请求,使得一部分请求不再经过ruby代码,而直接去DEA访问应用,但是,一旦router暴露在大量的访问请求下,性能依旧是不尽如人意.

为了提高Cloud Foundry router的可用性,Cloud Foundry开源社区不久前推出了gorouter。gorouter采用现阶段比较新颖的go作为编程语言,并重新设计了原有的组件架构。由于go语言本身的特性,gorouter处理并发请求的能力大大超过了router,甚至在同种实验环境下,性能是原先router的20倍左右。

由于gorouter的高性能,笔者也抱着期待的心态去接触go,当然还有gorouter。本文不会从go语言语法的角度入手gorouter,所以有一些go语言的基础再来看本文,是有必要的。本文主要是对gorouter的源码的简单解读,另外还包含一些笔者对gorouter的看法。

继续阅读

Cloud Foundry中collector组件的源码分析

在Cloud Foundry中有一个叫collector的组件,该组件的功能是通过消息总线发现在Cloud Foundry中注册过的各个组件的信息,然后通过varz和healthz接口来查询它们的信息并发送到指定的存储位置。

本文从collector的功能出发,主要讲述以上两个功能的源码实现。 发现注册组件

继续阅读

Cloud Foundry中syslog_aggregator的实现分析

在Cloud Foundry中,用来收集Cloud Foundry各组件日志信息的组件,名为syslog_aggregator。

syslog_aggregator可以做到方便的收集Cloud Foundry中所有组件的日志信息,并将这些信息进行初步处理,比如说:将不同月份产生的日志,进行分类存储;另外还对同一月份内产生的日志,将其通过不同的日期进行分类。这样的话,当Cloud Foundry平台的开发者,在运营该平台时需要查看Cloud Foundry中某一个组件产生的日志时,可以方便的查找到对应日期的日志。syslog_aggregator除了可以对日志进行分组件,分月份,分日期进行存储外,还提供一些对日志进行打包或剪枝的功能,比如:syslog_aggregator会将一定期限内的日志,进行压缩,以达到节省存储空间的功能;另外syslog_aggregator还会定期对日志进行清除,比如只保存一定期限时间长度的日志,当日志超过该时限,syslog_aggregator会将其清除。

以下是对syslog_aggregator实现的简单分析:

继续阅读