在Cloud Foundry中,当应用开发者的应用由Cloud Foundry的组件DEA来运行时,应用的资源隔离与控制显得尤为重要,而warden的存在很好得解决了这个问题。
Cloud Foundry中warden项目的首要目的是提供一套简易的接口来管理隔离的环境,这些隔离的环境可以被称为“容器”,他们可以在CPU使用,内存使用,磁盘使用以及设备访问权限方面做相应的限制。
本文将从四个方面进行探讨分析warden的实现:
- warden的功能介绍及框架实现
- warden框架的对外接口及实现
- warden框架的内部模块及实现
- warden的运行示例
warden的功能介绍及框架实现
warden功能介绍
warden框架实现
- warden:在Cloud Foundry中实现应用资源隔离与控制的框架,其中包括,warden_client、warden_server、warden_protocol和warden container;
- warden server:warden框架中server端的实现,主要负责接收client端请求,以及请求的处理执行;
- warden client:warden框架中client端的实现,被Cloud Foundry中被dea_ng组件调用,实现给warden_server发送具体请求;
- warden protocol:warden框架中定义warden_client与warden_server通信时的消息请求协议;
- warden container:warden框架中管理与运行应用程序的容器,资源的隔离与限制以容器为单位。
warden框架的对外接口及实现
虽然warden模块是Cloud Foundry中不可或缺的一部分,但是如果不借助Cloud Foundry的话,warden依然可以用来管理warden container,并在container内部运行应用程序等。
若warden运行在Cloud Foundry内部,则dea_ng组件内嵌warden_client,并以warden_client与warden_server建立通信,分发应用的管理请求;若warden单独存在,则可以通过warden的REPL(Read-Eval-Print Loop)命令行工具瑞与warden_server进行通信,用户通过命令行发起container的管理请求。本章将以以上两个方式阐述warden框架的对外接口及实现。
warden与dea_ng通信
warden在Cloud Foundry中的使用,几乎完全是和dea_ng一起捆绑使用。在部署dea_ng时,不论Cloud Foundry集群中安装了多个dea_ng组件,每个dea_ng组件所在的节点上都会安装一个warden,由此可见warden与dea_ng的存在为一一对应关系。
以下是warden与dea_ng的交互示意图:
由以上示意图可知,从dea_ng接受请求,分发container请求,主要分为以下几个步骤:
- dea_ng通过消息中间件NATS获取app的管理请求;
- dea_ng根据请求类型,并通过Warden::Protocol协议创建出相对应的container请求;
- dea_ng通过已经和warden_server建立连接的waren_client发送container请求。
warden与REPL命令行交互
warden也可以单独安装在某个机器上,当需要管理warden时,可以通过REPL命令行的方式,启动一个进程,创建warden_client,并负责接收用户在命令行输入的warden container管理命令,然后通过warden_client给warden_server发送请求。
从上可知,REPL和dea_ng与warden的通信方式几乎相同,区别仅仅在两者的使用方式。以下是warden与repl命令行交互的示意图:
warden框架的内部模块及实现
上文已经提及warden框架为C/S架构,抽象而言,它的运行包括:1.通过warden_client给warden_server发送container request;2.由warden_server接收请求并处理;3.warden_server针对warden container执行请求。
以下是warden框架的简单示意图:
warden_server的框架实现
warden_server的主要功能为接收warden_client的请求,并分发处理。warden_server的具体实现为,通过EventMachine启动一个server,并监听本地的一个unix domain socket文件,最终将所有接收到的请求转发给ClientConnection句柄来处理。ClientConnection首先从监听的sock文件中读取数据,然后从读出的数据中读取请求,随后辨别请求的类型,最后通过请求的类型,执行相应的操作。如果请求针对某一个具体的warden container,则需要从container注册过的registry中先找出相应的warden container,随后对该warden container执行相应的shell 脚本。
warden_server在disptach请求的时候,主要是完成对请求的分发。请求类型主要可以分为两类,一类为针对容器内部的具体操作,比如针对创建warden container请求执行新建container操作,对指定container执行运行某任务的操作,对指定container执行销毁操作等:;另一类为容器信息的获取,比如对warden container的ping操作,获取所有的container hanles信息,对warden执行echo命令等。以下阐述warden_server的请求类型。
warden container的实现
warden_server主要负责管理warden container的管理,包括创建,设置,销毁等。当warden container创建完毕并且设置完毕后,由warden container负责自身的运行。运行在warden container内部的应用程序,由于warden container提供资源隔离和控制的环境,从而实现应用程序的资源隔离与限制。
warden的资源隔离与限制是整个Cloud Foundry的核心,其中warden container的资源隔离与限制主要通过Linux内核的cgroup机制,quota以及tc(traffic controller)来实现。
warden container的文件结构
warden container的生命周期
warden container的生命周期主要包括,创建、使用、删除这三个流程,其中在使用过程中会涉及众多有关warden container的具体操作。
随后是warden container的使用。warden container的使用包括两种情况,一种情况是用户请求通过warden_client,然后经过warden_server进行管理,比如用户对warden container进行配置资源限制,用户给warden container内部传输文件等;另一种情况是当warden container内部运行着web应用时,warden container外部用户通过应用提供的服务访问内部应用。在第一种情况中,都是通过warden container 内部的washd进程fork出shell进程,而用户命令通过wsh传输给wshd,wshd又将命令交由shell执行。
在warden container的生命周期中还包括其自身的删除。删除过程中,首先让wshd给container内部所有进程发送一个pkill -TERM请求,并等待进程的结束,若没有结束,则直接杀死进程,随后wshd进程退出,并清除container文件目录。
warden container的网络配置
warden container的网络配置如下图:
以上便是warden架构的简要介绍。
关于作者:
孙宏亮,DAOCLOUD软件工程师。两年来在云计算方面主要研究PaaS领域的相关知识与技术。坚信轻量级虚拟化容器的技术,会给PaaS领域带来深度影响,甚至决定未来PaaS技术的走向。
转载请注明出处。
本文更多出于我本人的理解,肯定在一些地方存在不足和错误。希望本文能够对接触warden架构与实现的人有些帮助,如果你对这方面感兴趣,并有更好的想法和建议,也请联系我。