对于每个刚接触到OpenStack的新人而言,安装无疑是最困难的,同时这也客观上提升了你们学习OpenStack云计算的技术门槛。想想,本身3年前网上偶然接触到OpenStack时,一头茫然,手动搭建一个多节点环境时竟然用了3个星期。 时至今日,真是感触颇多,从某种角度而言,也很庆幸当时本身并未因困难而放弃OpenStack,不然,应该是去作其余领域了吧! 言归正传,我们就来数落数落部署OpenStack都有哪些方式吧。这里,咱们根据使用者群体的不一样类型来进行分类和概括: 我的使用方面 DevStack 无疑,在可预见的将来时间内,DevStack仍将是众多开发者们的首选安装方式或工具。该方式主要是经过配置参数,执行shell脚本来安装一个OpenStack的开发环境。 Github: https://github.com/openstack-dev/devstack Wiki: https://wiki.openstack.org/wiki/DevStack Rdo Rdo是由Red Hat开源的一款部署OpenStack的工具,同DevStack同样,支持单节点和多节点部署。但Rdo只支持CentOS系列的操做系统。须要注意的是,该项目并不属于OpenStack官方社区项目。 Docs:https://www.rdoproject.org/install/quickstart 手动部署 手动部署all-in-one、multi-node、multi-HA-node环境。 其余 企业、团体方面 Puppet Puppet由Ruby语言编写。应当说,Puppet是进入OpenStack自动化部署中的早期一批项目,历史还算悠久。目前,它的活跃开发群体们是Red hat、 Mirantis、UnitedStack等。 Red hat自从收购Ansible以后,现在仍然保持强势劲头在Puppet OpenStack项目中的Commit数量和质量,其技术实力不容小觑;Mirantis出品的Fuel部署工具中,大量的模块代码便使用的是 Puppet。就国内而言,UnitedStack是Puppet社区贡献和使用的最大用户。 Github: https://github.com/openstack/puppet-keystone Governance: Wiki: https://wiki.openstack.org/wiki/Puppet Ansible Ansible 是新近出现的自动化运维工具,已被Red Hat收购。基于Python开发,集合了众多运维工具(puppet、cfengine、chef、saltstack等)的优势,实现了批量系统配 置、批量程序部署、批量运行命令等功能,它一方面总结了Puppet的设计上的得失,另外一方面也改进了不少设计。好比是基于SSH方式工做,故而不须要在 被控端安装客户端。使得在和OpenStack结合上没有历史包袱,更加可以轻装上阵,将来发展潜力不容小觑号称是“你一直寻找的下一代Iaas”的 Zstack,使用到的部署工具也是基于Ansible。 Openstack-ansible项目,最先是由老牌Rackspace公司在Launchpad官网上注册。 在最新的Ansible OpenStack项目社区Commit贡献中,Rackspace也可谓是遥遥领先,而紧随其后的是Red Hat、国内九州云等公司。 Github:https://github.com/openstack/openstack-ansible SaltStack SaltStack 也是一款开源的自动化部署工具,基于Python开发,实现了批量系统配置、批量程序部署、批量运行命令等功能,和Ansible也是挺相近的。不一样之一 是,因为SaltStack的master和minion认证机制和工做方式,须要在被控端安装minion客户端,在加之其余缘由,天然和 Ansible相比,其优缺点便很明显了。 须要注意的是,使用Saltstack部署OpenStack,并不属于OpenStack社区项目。目前,主要仍是处于用户自研自用的阶段。据笔者所知,目前国内的携程应该是使用Saltstack部署OpenStack规模最大的用户。 Saltstack部署OpenStack示例:https://github.com/luckpenguin/saltstack_openstack Saltstack部署OpenStack模块: TripleO Tripleo 项目最先由HP于2013.4在launchpad上注册BP。用于完成OpenStack的安装与部署。TripleO全称“OpenStack On OpenStack”,意思即为“云上云”,能够简单理解为利用OpenStack来部署OpenStack,即首先基于V2P(和P2V相反,也就是指 把虚拟机的镜像迁移到物理机上)的理念事先准备好一些OpenStack节点(计算、存储、控制节点)的镜像,而后利用已有openstack环境的裸机 服务Ironic项目去部署裸机,软件安装部分的diskimage-builder,最后经过Heat项目和镜像内的DevOps工具(Puppet Or Chef)再在裸机上配置运行openstack。 和其余部署工具不一样的是,TripleO利用OpenStack原本的基础设施来部署OpenStack,基于Nova、 Neutron、Ironic和Heat,来自动化部署和伸缩OpenStack集群。 应 当确切的说,TripleO项目属于当前OpenStack社区主推的“Big Tent”开发模式下的big tent project(OpenStack下的项目分为三种,core project: nova/neutron等核心项目,big tent project: 非核心项目,但也被OpenStack 基金会接受;第三种就是其它项目,只是放在OpenStack下,可是社区尚未接受)。 在该项目的社区Commit贡献上,Red hat可谓是遥遥领先,而紧随其后的是IBM等公司。 Wiki:https://wiki.openstack.org/wiki/TripleO Kolla 在 国内一些互联网资料上,常看到关于kolla是TripleO项目的一部分这样的描述,实际上是不许确的。真实的是,Kolla项目起源于Tripleo项 目,时至今日,与它没有任何关系(虽然它们的目标都是作自动化部署,但走的道路却不一样)。比之于Tripleo和其余部署工具,Kolla走的是 docker容器部署路线。 kolla项目起源于TripleO项目,聚焦于使用docker容器部署OpenStack服务。该项目由 Cisco于2014年9月提出,是OpenStack的孵化项目。当前Kolla项目在Kollaglue repo提供了如下服务的docker镜像。 # docker search kollaglue Kolla的优点和使用场景,体如今以下几个方面: 原子性的升级或者回退OpenStack部署; 基于组件升级OpenStack; 基于组件回退OpenStack; 这里,咱们予以拆分来理解: Kolla 的最终目标是为OpenStack的每个服务都建立一个对应的Docker Image,经过Docker Image将升级的粒度减少到Service级别,从而使升级时,对OpenStack影响能达到最小,而且一旦升级失败,也很容易回滚。升级只须要三 步:Pull新版本的容器镜像,中止老版本的容器服务,而后启动新版本容器。回滚也不须要从新安装包了,直接启动老版本容器服务就行,很是方便。 Kolla是经过Docker Compose来部署OpenStack集群的,如今主要是针对裸机部署的,因此在部署Docker Container时,默认的网络配置都是Host模式。 首 先,只须要经过一个命令就能够把管理节点部署完成,这个命令是调用Docker Compose来部署OpenStack的全部服务,而后咱们能够在每个计算节点上经过Docker Compose安装计算节点须要的服务,就能部署一个OpenStack集群。由于Kolla的Docker Image粒度很小,它针对每一个OpenStack服务都有特定的Image,因此咱们也能够经过Docker Run来操做某个具体的OpenStack服务。 目前,我所在的公司九州云的一位同事近日得到提名成为Kolla项目Core。为OpenStack社区中增添了一份来自于中国的力量。 Fuel Fuel 是针对OpenStack生产环境目标 (非开源)设计的一个端到端”一键部署“的工具,大量采用了Python、Ruby和JavaScript等语言。其功能含盖自动的PXE方式的操做系统 安装,DHCP服务,Orchestration服务 和puppet 配置管理相关服务等,此外还有OpenStack关键业务健康检查和log 实时查看等很是好用的服务。 Fuel,这款让不少人即爱且痛的工具,在国内外都很盛名。爱的缘由是,它确实很棒;痛的缘由是,要想完全掌握 它,可不是一件容易事(各个模块集成度高、使用技术复杂)。既然提到Fuel,天然不能不提它的父母——Mirantis。Mirantis是一家技术实 力很是雄厚的OpenStack服务集成商,他是社区贡献排名前5名中惟一一个靠OpenStack软件和服务盈利的公司。同时,Fuel的版本节奏也很 快,平均每半年就能提供一个相对稳定的社区版。 从和笔者接触到的一些状况来看,国内研究、使用Fuel的我的、群体仍是为数很多的。很多国内OpenStack初创公司的安装包就是基于Fuel去修改的。