转载自:http://blog.csdn.net/hackerain/article/details/8664261
哈,又回来了!
公司同事说不要只停留在逻辑层,你要对跑在你程序底下的数据流也要非常的清楚。但是这里还是先介绍一下逻辑层,在代码的角度看是如何实现这个功能的,关于底层的数据流,还需要哦酝酿一段时间,之后会再总结一篇底层数据流的文章,真难为我了!
一、什么是安全组
安全组,翻译成英文是 security group。安全组是一些规则的集合,用来对虚拟机的访问流量加以限制,这反映到底层,就是使用iptables,给虚拟机所在的宿主机添加iptables规则。
可以定义n个安全组,每个安全组可以有n个规则,可以给每个实例绑定n个安全组,nova中总是有一个default安全组,这个是不能被删除的。创建实例的时候,如果不指定安全组,会默认使用这个default安全组。
现在nova中安全组应该会移到quantum中,并且会增加对虚拟机外出流量的控制。现在nova中的安全组只是对进入虚拟机的流量加以控制,对虚拟机外出流量没有加以限制。
关于security group的详细使用,见这里
二、整体架构
Security Group在nova中是通过扩展的形式实现的,关于Nova API的扩展又是一大篇的文章才能介绍的清楚,这里就不说了。其实感觉到REST API是整个openstack项目中非常重要的组成部分,只有理解了REST API才能更好的掌握openstack。真是长见识了,原来API还可以是这样。
nova 中的API扩展机制非常的好,可以让开发人员很方便的定制自己想要的功能,只要添加一个文件到那个目录中,工作就完成了80%了吧。
安全组就是这样一个扩展,位于nova/api/openstack/compute/contrib/security_groups.py中,还是先来看一下实现它的静态类图吧:
每一个扩展文件中都必须有一个和文件名同名的类,比如这里的类就是Security_groups,这个类就是把REST API需要的controller和wsgi_action聚合在一起,加载扩展的时候,就是加载的这个类,controller和wsgi_action中定义了对资源的各种操作,controller定义了show, create, index, delete等等操作,action定义了一些除了CIDR之外的额外的操作:
SecurityGroupController类定义了security group的操作,也即对安全组,这个“组”的增删查改操作。
SecurityGroupRulesController类定义了对组中的规则的操作。
ServerSecurityGroupController类定义了对和实例绑定的安全组的查询操作。
SecurityGroupActionController类中定义了把实例从安全组中添加/删除。
nova中有两个非常重要的组件,一个是db,一个是message queue,db用来记录各种状态,message queue用来在各个服务和各个节点之间传递消息,这种机制,在这里可以得到非常好的体现。这些操作被封装成为了一个类:SecurityGroupAPI,定义在了compute/api.py中,看代码,在E版中这些代码是和compute.API混在一起的,到了F版将和Security Group相关的代码抽取出来,封装成了SecurityGroupAPI,这个类主要是封装了对db的操作和rpc的操作。
安全组在架构上的实现想想其实也很简单,也没什么架构,基本上openstack中所有的组件都是这一个模式,db记录状态,然后发送rpc消息,调用一个第三方包去做xxx工作,然后再用db记录状态。
compute_rpcapi.SecurityGroupAPI是用来发送cast/call消息的,主要是用来在安全组更新之后刷新规则。
三、进一步深入
在由API层发送rpc消息之后,API层的工作就算做完了,接下来就到了compute.ComputeManager中了,他们之间的依赖关系如下图:
ComputerManager中有一个driver,都知道这个driver默认的就是libvirt,还有就是init_host()方法比较重要,每个Manager都有这样一个方法,是相对应的服务在启动的时候调用的,用来进行一些初始化,主要做的工作是对网络进行初始化,建立一些初始的chain和rule,这在下一篇文章中会详细讲到。
最下面的是linux_net,这可以说是最接近底层的代码层了,在它里面封装了对Iptables的各种抽象,具体看下类图:
OK,就暂时深入到这里吧。
四、功能测试