此文是根据东网科技张智博在Rancher官方技术交流群中所做的在线技术分享整理而成，主要内容为OpenStack与Rancher融合的新玩法。
前段时间的OpenStack China Days大会上， Rancher CEO 梁胜博士特意分享一个关于 OpenStack与Rancher结合的议题，今天我就对此话题稍微展开讲一下「玩转Rancher与OpenStack」。
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是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里面体验一下。1. Host必须开启KVM，可以使用这个命令查看一下 egrep -c '(vmx|svm)' /proc/cpuinfo，返回是0说明没开启，各种OS开启KVM可Google之。2. 计算节点的libvirtd进程不能在运行在base OS中。3. 各个节点需要两块网卡，一块用于API通信，一块用于Neutron网络，网络需要提前配置好。4. 部署的过程需要拉取很多镜像，需要耐心的等待。
