cloud foundry warden容器

现在的cloud foundry dea中所使用的主要还是warden容器，虽然docker容器也有人在研究，但是我们所使用的容器是warden，这里我们简单的记录一下我所学到的warden容器。

 在cloud foundry中，应用是跑在dea组件中的，但是cloud foundry的dea自身并没有提供资源隔离和控制的机制，所以，在cloud foundry的v2版本中，就加入了warden容器这个概念，用来实现资源的隔离和控制。warden的首要目的是提供一套简易的接口来管理隔离环境，这些隔离的环境就被称为容器，他们可以在使用CPU，内存等方面做了一定的限制。

warden专门接受来自DEA组件发送的关于应用的管理请求，在处理这部分管理请求时，借助轻量级虚拟化技术，将宿主机操作系统进行虚拟化，在容器内部执行请求的具体内容。warden容器保证各个应用之间相互不受影响，相互之间资源是隔离的。每个应用有他们的资源上限，否则如果没有warden容器的封装，很容易出现各个应用程序之间相互争抢资源的情况，降低系统的靠卡性和安全性。那么这些资源都是哪些呢？主要是内存，网络带宽和磁盘。

对于warden的一些API命令，有很多，我们还没有进入到容器中尝试过，这里先记录一下，真正进去的时候，我们再不断的尝试。主要命令：copy in， copy out, create, destroy, echo, error, info, limit_bandwidth, limit_disk, limit_memory, limit_cpu, link, list, message, net in, net out, ping, run, spawn, stop, stream. 

每个warden容器的框架一般包括这几个方面，从源代码中就可以看到。

warden：

warden server：服务器端的实现，主要负责接收客户端的请求，以及请求的处理。

warden client：客户端，被cf中的dea_ng组件调用，通常用来给server端发送具体请求。

warden protocol：client和server之间通信的消息请求协议。

warden container：管理和运行应用程序的容器，资源的隔离与限制以容器为单位。

总的思路呢就是用户或者cf通过client来连接server，然后server根据你们的请求创建，销毁或者获取container。不同的是cf中dea和warden是一一对应的，有一个dea就有一个warden，每当cf需要获取有关的warden的信息的时候，都会通过NATS组件去向dea组件发送一个消息，dea就去找warden client，按照warden protocol，写自己的请求，发送给server，server然后进行一定的操作。这是在cf中的使用方式。但是warden并不是只为cf设计的，脱离cf一样可以使用，只不过访问方式不再是通过dea了，因为离开cf就没有dea了。warden可以单独安装在某个机器上，当需要管理warden时，可以通过REPL命令的方式，启动一个进程，创建warden client，在命令行输入命令，管理container。

最后说一下关于cf中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执行。 这段是直接复制的别人的，还没有做，不懂，要试验了才知道。