摘要：本次分享給大家帶來與能夠融合使用的一些玩法。計算節點的進程不能在運行在中。部署的過程需要拉取很多鏡像，需要耐心的等待。之前的計劃應該是在版會添加的支持，差不多就是今年月份左右。

OpenStack是開源Iaas云的事實標準，功能大而全，除了能管理虛機同時也能管理容器，OpenStack項目中的Magnum、Kuryr、Kolla、Murano、Nova-docker等都是與容器場景很不錯的結合點；而Rancher不同，Rancher是為容器而生，只是順道做了一些VM的管理工作，與OpenStack不同的是針對VM的管理，Rancher并不是對標AWS，Rancher相對來說要精簡很多，當然Rancher對容器的掌控要遠強于OpenStack。本次分享給大家帶來Rancher與OpenStack能夠融合使用的一些玩法。

我會分為幾個場景來講解一下，這樣對OpenStack不是太了解的朋友而言可以更直觀一些。

這種結合是最先能想到的，可以說是順理成章的需求。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模式放進來。

玩過OpenStack的朋友都深知其復雜性，對于一個新手來說，剛上來部署OpenStack來個三天三夜不是什么新鮮事。OpenStack的快速部署需求引出了一些開源項目和商用產品，諸如openstack-ansible、kolla、fuel、magicstack等等。

在這其中kolla的理念比較特殊，它立志于以容器方式部署openstack服務，從而能夠實現快速部署甚至滾動升級降級等特性。 Rancher本身就是管理容器的利器，完全可以把openstack當做Catalog中的一個應用來部署，這個服務Rancher也已經開始支持https://github.com/rancher/op...，目前實現也比較初級不支持controller的HA，可以將其加到Catalog里面體驗一下。

有幾點注意事項：

Host必須開啟KVM，可以使用這個命令查看一下 egrep -c ‘(vmx|svm)’ /proc/cpuinfo，返回是0說明沒開啟，各種OS開啟KVM可Google之。

計算節點的libvirtd進程不能在運行在base OS中。

各個節點需要兩塊網卡，一塊用于API通信，一塊用于Neutron網絡，網絡需要提前配置好。

部署的過程需要拉取很多鏡像，需要耐心的等待。

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 是可以計算出來的，有一個公式可以計算，小于這個值也可以，但是這樣傳輸效率就太低。