OpenStack是开源Iaas云的事实标准，功能大而全，除了能管理虚机同时也能管理容器，OpenStack项目中的Magnum、Kuryr、Kolla、Murano、Nova-docker等都是与容器场景很不错的结合点；而Rancher不同，Rancher是为容器而生，只是顺道做了一些VM的管理工作，与OpenStack不同的是针对VM的管理，Rancher并不是对标AWS，Rancher相对来说要精简很多，当然Rancher对容器的掌控要远强于OpenStack。本次分享给大家带来Rancher与OpenStack能够融合使用的一些玩法。
我会分为几个场景来讲解一下，这样对OpenStack不是太了解的朋友而言可以更直观一些。
场景一：使用OpenStack的VM来提供Rancher Host
这种结合是最先能想到的，可以说是顺理成章的需求。Rancher添加以OpenStack的VM为Host资源，我觉得主要有两种方式：custom host方式和docker-machine driver方式。
第一种方式，我们都知道Rancher在Add Host时可以用在目标主机执行一条shell的方式来添加host，而OpenStack在创建VM的时候可以在注入一个执行脚本，这个脚本会在VM创建完毕后在VM的OS内部执行，所以我们就可以利用这些特性：
这样VM在创建完毕后会自动成为Rancher的一个Host资源，这里一点小建议就是VM的镜像最好是自带Docker，这样可以注入的脚本中省去安装Docker Engine的过程，可以大幅提升速度。
第二种方式就是利用docker-machine driver，而且openstack driver也是docker-machine的官方驱动之一，不过这个driver的参数确实太多，易用性上差很多。除了使用openstack driver，其实我们完全可以使用generic driver，openstack对主机秘钥有很好的管理，所以我们完全可以使用openstack和Rancher的api，利用generic driver来简化openstack driver的复杂性，当然前提是VM的镜像最好还是自带Docker Engine：
说完Host资源，我们看看存储方面。OpenStack对存储的支持区分的比较细，对象存储、块存储、文件系统都有各自的项目来支持，如swift、cinder、manila等，存储系统对接的不仅仅是Rancher，Docker Engine本身也要处理好一些优化细节。
对于对象存储Swift，可以作为Docker registry的backend存储，我们可以registry服务部署到VM上，然后镜像的存储放在swift上。另外，目前convoy backup可以备份到AWS S3上，对于国内用户来说比较麻烦，实际上完全可以备份到swift上，当然需要在convoy上添加这个驱动的支持，或者可以把swift配置成S3的接口，这样也可以和convoy结合起来使用。
对于块存储Cinder，更多的结合场景在Docker Engine上，Docker有很多种storage driver，也就是我们熟知的rootfs可以有多种形式，常用的有aufs、devicemapper、overlayfs等，通常VM的flavor根磁盘都比较小，所以我们需要用cinder创建一块盘来挂载到/var/lib/docker上或者直接指定这块盘为devicemapper对应的设备。
对于文件系统manila，manila本身能够创建一个对外的NFS服务，也可以创建一个glusterfs集群服务，这样也可以和convoy能够有很好的集成。目前相对对象存储和块存储 ，Manila的成熟度还不是太高。
计算存储之后便是网络，我们都知道Rancher中Cattle的网络使用ipsec，ipsec本身就是一种overlay技术，而OpenStack的Neutron很多也会使用GRE/VXLAN之类的overlay网络，这样容器之间的网络通信就变成overlay嵌套overlay，性能上必然打打折扣，所以OpenStack与Rancher结合使用时，强烈建议Neutron使用vlan网络。
当然可能由于各种环境因素必须在neutron中使用overlay，此时VM的网卡的mtu需要设置成1400或者1450，那么同样需要对Docker容器的mtu做设置，否则容器内一些应用层的协议（HTTP）将会无法正常使用。DOCKER_OPTS=”$DOCKER_OPTS –mtu=1400″
场景二：构建容器与虚机的混合网络
上一场景所提到的嵌套overlay的问题，是在OpenStack中使用Docker集群的普遍问题，如下图所描述：
这种性能的损耗是巨大的，繁荣的OpenStack社区孵化的一个子项目Kuryr就是解决这个需求场景的。Kuryr本质上就是把容器内namespace的port与neutron port绑定，这个neutron port根据不同neutron-plugin-agent略有不同：
最终可以实现容器和容器之间组网，容器和虚机之间组网等模式，Neutron会作为IPAM存在，我们可以随意地定义网络：
这样我们可以把很多Neutron的特性带入到容器网络中，诸如安全组、浮动ip、Qos、Lbaas、Fwaas等等。
目前Kuryr只支持CNM(libnetwork)，在OpenStack N版的release周期中会放出对CNI（主要是Kubernetes）的支持，届时Rancher 1.2也将会支持CNI，这样两者可以有一个很好的结合，后期可长期关注这个方向。
场景三：使用Murano来快速部署Rancher
Murano是OpenStack的应用市场，将应用基于Murano约定的打包标准打包后放入应用市场，用户就可以在OpenStack中快速部署该应用，这个理念非常类似Rancher的Catalog，只不过它是基于VM的。如果需要在OpenStack中快速部署一套简单的Rancher环境，那么使用Murano是个不错的选择。
我们可以在OpenStack Horizon上用拖拖拽拽的方式创建Rancher环境：
最终通过Murano的编排，创建了Rancher服务环境 ，并自动生成部署图：
这种主要是方便、快速创建一套Rancher环境，我目前只是做了个demo，如果更完善还需要把Rancher的HA模式放进来。
场景四：利用Rancher Catalog快速部署OpenStack
玩过OpenStack的朋友都深知其复杂性，对于一个新手来说，刚上来部署OpenStack来个三天三夜不是什么新鲜事。OpenStack的快速部署需求引出了一些开源项目和商用产品，诸如openstack-ansible、kolla、fuel、magicstack等等。
在这其中kolla的理念比较特殊，它立志于以容器方式部署openstack服务，从而能够实现快速部署甚至滚动升级降级等特性。 Rancher本身就是管理容器的利器，完全可以把openstack当做Catalog中的一个应用来部署，这个服务Rancher也已经开始支持https://github.com/rancher/openstack-catalog，目前实现也比较初级不支持controller的HA，可以将其加到Catalog里面体验一下。
有几点注意事项：
- Host必须开启KVM，可以使用这个命令查看一下
egrep -c ‘(vmx|svm)’ /proc/cpuinfo，返回是0说明没开启，各种OS开启KVM可Google之。 - 计算节点的libvirtd进程不能在运行在base OS中。
- 各个节点需要两块网卡，一块用于API通信，一块用于Neutron网络，网络需要提前配置好。
- 部署的过程需要拉取很多镜像，需要耐心的等待。
Q & A
Q：
Rancher现在只有IPSec 这种网络方案吗？性能会有问题吗？
A：
Rancher-net组件目前只支持ipsec。ipsec网络本身是overlay网络，同时还有密钥加密，所以性能上会差一点。不过在Rancher 1.2的发布计划中，会支持CNI，这样我们可以把calico weave等网络组件集成进来，用户可以根据自己的实际业务场景 选择不同的网络组件，Rancher对CNI的支持已经开始开发了。
Q：
Kuryr现在可以对接Rancher吗？
A：
Kuryr 现在暂时不可以，Kuryr目前也是在支持CNI的迭代中，需要等Rancher和Kuryr都完毕后，两面就可以打通了。Kuryr之前的计划应该是在OpenStack N版会添加CNI的支持，差不多就是今年10月份左右。
Q：
【当然可能由于各种环境因素必须在Neutron中使用overlay，此时VM的网卡的mtu需要设置成1400或者1450，那么同样需要对docker容器的mtu做设置，否则容器内一些应用层的协议（HTTP）将会无法正常使用。】关于这一点，是明确要求1400或1450还是说可以小于1400即可？因为强制只能是这两个值应该有点特别原因吧？
A：
特别的原因就是GRE/VXLAN的包头太大了，设置mtu拆包的时候不能用默认的1500 否则数据包就是无法识别了。1400/1450 是可以计算出来的，有一个公式可以计算，小于这个值也可以，但是这样传输效率就太低。
原文来源：Rancher Labs