不要看不知道道，器皿化 OpenStack 的10个益处
OpenStack上的许多难题，全是能够处理，只是处理起来很费力，器皿化，处理就显得很雅致。有强劲的Docker小区，你处理难题的方式，方法就更多。
1、升級
这个实际上大伙儿都可以以想起，器皿最大的特性，便是升級。公司应用OpenStack，最大的1个顾忌，便是升級。特别在OpenStack 1年两个版本号下，持续的有新的作用的要求的状况下，假如不可以升級，实际上是很痛楚。特别在公司的快速发展趋势的全过程中。
器皿化的OpenStack，升級有多么的简易呢？实际上便是删除器皿，换上新的器皿，客户基础是无认知的情况下进行。
升級子因此很艰难，有1个很实际的缘故，网上自然环境，很难仿真模拟，升級认证检测很难开展。当选用器皿化之后，大家很非常容易仿真模拟出1个网上自然环境，开展升級检测，升級不成功，回退。实际上这些都做的很好看。
2、灵便
之前厂商的处理计划方案，全是3个操纵连接点，假如我期待提升到5个操纵连接点，或把操纵连接点某个服务独立布署，那末这个基础是很难进行的每日任务。
之前厂商都厂商把OpenStack的各个服务放到虚似机里，这样布署灵便性提升很多。可是虚似机還是很重，应对顾客千百万化的要求，就有点束手无策。
举1个事例
公司基础连接点，我经营规模很小，将会就仅有几台设备，这时候候，我将会不必须操纵连接点高能用，我就必须1个操纵连接点，管理方法机柜测算连接点。
伴随着時间的发展趋势，期待扩张经营规模，操纵连接点变为高能用。
经营规模进1步扩张，我就必须把信息序列独立出来布署，处理特性的难题。
这类要求，很确实，OpenStack厂商也在勤奋考虑公司的这些要求，实际上Mirantis的Fuel，早已在许多水平，考虑了公司这类要求，但是成本很大。
针对器皿化的OpenStack，就变得很简易，不过便是调剂各个连接点的器皿遍布，编排的难题。操纵连接点是3个，還是5个，RabbitMQ放在甚么部位，压根就并不是难题。
3、配备管理方法
OpenStack以往应用最广的配备管理方法专用工具是Puppet，针对公司客户来讲，这个是很难操控的。实际上在中国，即使是互联网技术企业，负责Puppet的运维管理人员辞职，实际上全是很难招骋回家相应的人员。
针对OpenStack厂商来讲，要想彻底操控Puppet，還是很艰难的。更别说，要考虑各种各样灵便的要求。
配备管理方法专用工具，实际上Salt和Ansible，是Python开发设计，较为易用，但是在OpenStack的绿色生态圈里，比不上Puppet强劲，很难跨越Puppet。
器皿化后的OpenStack，配备管理方法专用工具，或编排的专用工具，就许多挑选，Ansible、Slat、Kuberes，全是能够适用。你就不必须受Ruby的折磨。
实际上这也是大大减少公司操控OpenStack难度。
4、实际操作系统软件厂商依靠
厂商都在宣传策划所谓沒有厂商关联。实际上你用了红帽的OpenStack，要想换到Ubuntu下，并不是不能能，实际上毫无疑问很痛楚。假如要换为Suse，难度就更高。
各种各样配备管理方法专用工具，实际上全是依靠发售版的检修口理。中国的金融机构实际上都应用Suse。可是小区的Puppet专用工具不适用Suse。或我期待玩的新项目，实际操作系统软件发售版沒有出示包，如何办？
器皿化的OpenStack。实际上基础理论上，能够跑在任何适用器皿的实际操作系统软件上。核心的版本号高，不过便是特性更好1点。实际上你只必须做点检测，便可以完成这类跨实际操作系统软件的布署。
器皿里，可使用RPM包，Deb包，也是能够跑源代码安裝，这样实际上针对实际操作系统软件厂商来讲，基础就没任何的依靠。不会受到制实际操作系统软件厂商。
5、手机软件依靠
OpenStack新项目的增多，手机软件相互之间依靠的难题，愈来愈比较严重。由于OpenStack许多新项目是必须应用外界新项目，比如Ceph，他的依靠极可能和OpenStack组件的依靠造成矛盾。
这类难题，能够处理，可是处理，没任何的实际意义和技术性含量，很让技术性人员抓狂。实际上发售版都在投入很多的活力去处理各个手机软件包的相互之间依靠的难题。
器皿化的OpenStack，很好的处理了这个难题。
6、布署時间
在生产制造自然环境中，布署時间1个小时，和1天，实际上差别不大，终究布署是1次性的工作中。针对检测来讲，就彻底不1样。假如我10分钟能够进行1次布署，能够检测认证的物品，和几个小时才可以进行1次的布署，差别還是很大的。
器皿化OpenStack，大大加速了布署的時间，一般10分钟，便可以进行1次详细作用的布署，认证OpenStack各种各样新作用的成本，就大大降低。
7、显得简易
OpenStack在公司的具体应用中，全是埋怨太繁杂，这实际上也是由于OpenStack，松藕合，作用强劲，另外也让客户觉得很繁杂。特别在出現不正确的情况下，很无可奈何。
器皿化后，客户觉得OpenStack各个组件，就相近积累木1样，构建起来，能够依据自身的要求，挑选哪一个控制模块。觉得自身是可控性的。你能够很便捷的装上某个控制模块，不令人满意，删除。身后的繁杂的逻辑性，小区早已帮你健全。
遇到难题，寻找协助，也显得简易许多。由于大伙儿器皿里的物品全是1样的，不过便是外面的配备文档。
也要是让公司觉得自身能够操控OpenStack，这样OpenStack才会很多的进到公司的IT系统软件。这个情况下，不管是选用外包還是自身运维管理。
8、测算连接点HA
假如完成测算连接点挂掉后，上面的虚似机全自动在其他连接点起动起来。这个难题处理的方法，实际上有许多，处理的难点，就在于我怎样分辨这台连接点真的挂掉。由于虚似机的转移的物品，是很大的，务必很当心。也很非常容易导致误判。
海云捷迅提出1个应用Consul的处理计划方案，便是1个器皿里做身心健康查验的组件，放到OpenStack测算连接点，相近peer-to-peer，相互之间查验。
当器皿化的OpenStack后，那末便可以运用器皿强劲小区，各种各样的完成方法，第1時间了解连接点无效。毫无疑问你也是可使用Consul来处理这个难题，更为立即。
9、监管和系统日志剖析
OpenStack1直都在健全自身的监管系统日志剖析。但是进展其实不太好。器皿化的OpenStack，遭遇的监管，系统日志的难题，和之前的OpenStack有很大差别。
但是迫不得已认可，器皿的全球里，这层面十分健全，太多挑选，能够协助你处理监管和系统日志剖析的难题。
能够运用强劲的Docker小区，来健全OpenStack薄弱点的地区。
10、自主创新
器皿化后的OpenStack，实际上带来许多出乎意料的自主创新和转变。许多之前很炫的定义，渐渐地走向实际。
OpenStack1个版本号的发售周期大约是分成B1、B2、B3，每一个环节大约45天，后续就公布RC，宣布版本号。
过去OpenStack企业全是直到1个版本号宣布公布后，开展装包，检测，认证，历经3个月和半年，宣布对外公布。那末这类公布周期，实际上早已有点跟不上OpenStack的脚步。比如Mitaka版本号公布的情况下，红帽的Liberty版本号才宣布对外公布。
能不可以保证，OpenStack1边开发设计，发售版也在同歩开展装包，检测呢？实际上在OpenStack发展趋势前期，有人提出这样的提议，但是对实际操作系统软件厂商来讲，成本太大，不肯意去做。
有了器皿化之后，彻底不必须依靠实际操作系统软件的装包，我能够依据自身的要求，开展build image，检测，这样我的商品的公布周期，就会大大减少。
总结
OpenStack上的许多难题，全是能够处理，只是处理起来很费力，器皿化，处理就显得很雅致。有强劲的Docker小区，你处理难题的方式，方法就更多。
