<p>Docker的出现，对OpenStack产生了一定的影响，有些声音说：Docker会使得OpenStack遭受背弃。而事实却与之相反，我们看到两个社区发展的依然很好，Docker与OpenStack各有侧重，分别解决了不一样的问题，且两者的使用场景也不太一样。</p>    <p>什么是Kolla这个项目？</p>    <p>Kolla项目的产生，是由于OpenStack本身的复杂性，即模块太多与配置项太复杂，其中模块的问题是OpenStack自身数量已经很多，在此基础上其依赖的模块太非常之多，由于可选项的数量多导致其部署的复杂性，导致我们需要对OpenStack有非常深入的理解，才可以选择适宜的部署方案。</p>    <p>不仅如此，在利用现有的部署工具Fuel，其复杂程度与代码级同样达到了很复杂的量，同时还有openStack-ansible（rackspace主导），它下面的项目非常多，基本上OpenStack的一个模块就形成一个子项目。</p>    <p>另外，随着OpenStack逐渐成熟，常用的Puppet代码也已经变的复杂。因为部署复杂，所以运维也同样面临着各种挑战。</p>    <p>对此，Kolla项目被孵化出来，有效的解决了上述复杂度的困恼。Kolla本身的含义是“胶水”（希腊语），是把OpenStack和Docker有机融合在一起。Kolla提供出两个东西，一是生产级别的Docker镜像，另一个是基于Ansible的部署工具，这两个产出是可以分别独立开来的。</p>    <p><img src="https://simg.open-open.com/show/70b62d75f00da96793f74b9d4c871f85.jpg"></p>    <p>为什么是Docker？</p>    <p>首先，先剖析一下Docker本身的优点：</p>    <p>（1） <strong>固定性</strong> ：</p>    <p>可以直接把容器清掉并重新通过Image创建（全新且同原本一样）。</p>    <p>（2） <strong>便捷性</strong> ：</p>    <p>因为它的Image可以直接导出来，或者存在于Docker Registry服务中，所以可以带到另外的地方做部署，而且它的体积比较小，所以很方便便携（区别于使用puppet来部署，需要携带好多源）。</p>    <p>（3） <strong>速度快</strong> ：</p>    <p>Docker本身启动很快，基本是秒级的启动。</p>    <p>Docker社区非常庞大，通过各大公司进入到Docker社区里面做的一些贡献，我们可以看出包括（上层的产品）谷歌、Apache都有较好的应用且成长很快，同时，Docker技术经过三年的成长，已经开始在生产环境被使用，其成长非常迅速。</p>    <p>所有的事物都有两面性，Docker当然也有一些缺点。例如其验证不够，Docker从诞生到发展只有三年的时间，大家的验证量还不够多，且功能还在随着版本的增加而增加，所以说，Docker还是略新。</p>    <p>详解Kolla：</p>    <p>Kolla是把OpenStack部署在Docker容器里，提供快速部署的层级功能。</p>    <ul>     <li><strong>Kolla的目标</strong></li>    </ul>    <p>（1）利用Docker产生生产级别的镜像加速OpenStack部署。</p>    <p>（2）简化OpenStack部署和运维操作。</p>    <p>现阶段提供Ansible Playbooks进行部署，但由于对Kubernetes 的兴趣，可以把 OpenStack 运行在 kubernetes上，用其本身的特点保证云平台的灵活性和自动调度。</p>    <ul>     <li><strong>Kolla的基本原则</strong></li>    </ul>    <p>说到Kolla的一些基本原则，首先不得不提它的“Open”，Kolla不是被某一家公司所独占，其开发人员来自于各个公司，其中包括思科、英特尔、IBM等。其次还有Kolla所部署出来的集群基本上是一个“开箱即用”的状态。</p>    <p>例如在Kolla上直接使用100个节点的机器，可以实现“直接、批量地创建机器”。Kolla优化了一些功能参数，可以做到批量起动五、六百台机器在100个节点中，是没有问题的。</p>    <p>再有，Kolla在不同的环境里面，打破了“只能用OVS”的问题，Kolla可以是不限定的，可以供用户自由选择。</p>    <p>最后，Kolla本身项目开发的validation（验证），即保证Kolla代码的质量。也就是OpenStack的标准流程。在CI的测试中，包括构建所有的容器镜像，并进行部署，随后运行一个虚拟机，来检测Kolla是不是真的可以正常工作，不仅如此，在Newton周期里可以把多机节点附加进去，这样一来，测试Kolla能力会更大一些。</p>    <ul>     <li><strong>Kolla的功能</strong></li>    </ul>    <p>（1）在Liberty中，Kolla的功能如下：</p>    <p>首先所有服务HA都已具备，包括API、storage在L版都已经完成。不仅如此，Kolla支持多后端存储，比如是不是开启 Ceph 存储，如果是便可以自动将Ceph部署出来，并自动把Glance、Nova、Cinder配置好。</p>    <p>Kolla还具备既可以通过RDO打包，也可以从二进制包安装OpenStack，还支持从源代码安装，这样可以保持我们使用的，是OpenStack的最新代码。还有上述提到的Kolla被验证的基本原则中，其默认支持100个节点的部署。</p>    <p>另外，Kolla对物理机的依赖很小，宿主机只要装 kolla-py 和docker-engine中，便都可以部署OpenStack。</p>    <p>补充：在L版中，Kolla支持的服务是包含mariabd、rabbitmq、memcached等，并支持原子性升级。</p>    <p>（2）在刚刚发布的M版中，Kolla的功能如下：</p>    <p>针对安全性，所有在容器里面的服务都不是在root中运行的。并添加了upgrade actian，即OpenStack可以升级。同时增加了ELK，用来做日志的收集和展示。</p>    <p>补充：M版中，Kolla的部署时间大大缩短；使用了Namde volume 进行存储；使用官方的 qemu 源，使用了qemu 2.3 版本，有一定性能的提升；MariaDB增加了一个新的actian叫做 mariadb-recovery。</p>    <p>与此同时，Kolla社区是比较活跃的，各大公司在Kolla里面代码贡献数量非常多，且数量比较均等。</p>    <ul>     <li><strong>Kolla的结构</strong></li>    </ul>    <p>Kolla通过CD/CI后会生成Ansible和Image两个产出。宿主机上安装一个Docker Registry服务，并将镜像上传上去，便可以部署OpenStack，结构非常简单，且Kolla的代码量也很少。</p>    <p>在Image Dependency中，有一个base项会根据需要安装组建，Nova把所有的子服务拆开，以容器的方式运行。</p>    <p>同时还有Dockerfile本身的描述能力有限，只可顺序。Kolla增加了描述能力。可以增加一些变量和一些逻辑判断实现一些复杂功能。</p>    <p>同Kolla的功能描述，其支持多个版本，并支持两种安装方式。</p>    <p>Kolla的部署基本是基于社区的最佳实践，比如一个LoadBalance负载所有API服务，然后是消息队列及数据库，随后是调试器，这就是它的架构。Kolla的部署非常简单，基于Ansible，做了kolla-ansible脚本，这个脚本可以做一些与部署相关的工作，比如前期检查等。</p>    <p>第二是基于 Ansible Inventory，它是一个组的概念，通过它，我们可以知道哪个机器在运行哪个服务。现在支持单机的部署，其实单机跟多机是一样的，只是 Inventory 的文件内部不一样，不仅如此，还支持MariaDB和RabbitMQ集群，同样是自动创建的。</p>    <p>在第二点上，我们比较关心网络问题，因为Docker网络默认是用 Linux Bridge，如果需要在外面访问需要通过port map的方式，但OpenStack有Newton网络的模式，往往会非常慢，等于网络会有许多层。所以，我们选用最简单的：host网络，同在物理机起是一样的。</p>    <p>值得一提的是，它完全尊崇Docker的理念，一个容器一个进程。</p>    <ul>     <li><strong>Kolla的特性</strong></li>    </ul>    <p>第一，Kolla将所有东西都容器化了，包括libvirt和ovs这种比较复杂的应用进行容器化。</p>    <p>第二，严格遵守了一个容器只有一个进程的Docker原则，包括Neutron。这点在Docker1.10是做不到的，因为在里面会创建 namespace ，在其他容器中是看不到的。</p>    <p>第三，物理机不会受到任何“污染”，部署完成之后，如果不想使用了，可以直接把所有的container清楚掉，便可以重新回到原始的、干净的状态。</p>    <p>当然，在整个过程中也会遇到一些问题，比如Docker的timzone，在其他的部署方式下是遇不到的，只能把容器外的时区文件映射到容器里面来实现，否则的话如果改掉外面，容器内部的时区不变，会发生时间跳过几个小时的情况，这个时候Ceph会崩掉。</p>    <p>同时还有ulimit，因为一旦运行到容器里面，ulimit的数值不够大，导致它打开文件太多出错。还有Docker的storage有比较多的选择，现在看来devicemapper比较慢的。</p>    <p>值得一提的是：插件，Kolla缺少的是插件技术，因为OpenStack项目太多，而且每个项目有不同的插件(驱动)，实现起来不一样，不可能依靠Kolla社区来维护，如果真的实现的话，那么会大大加大它的灵活性，实现插件机制就是做集成，即将自身产品相集成。</p>    <p>还有它的配置文件，包括puppet、ansible部署时是把配置项变成上层的一个变量，Kolla与其不同，它是将原始配置文件写好，不会增加用户额外的学习成本，但这个机制暂时只能支持OpenStack的项目，使用对Apache的配置文件尚支持不了。</p>    <p>最后是监控问题，现在虽然有ELK做日志收集和展示，但是没有监控，所以周期内需要做监控的事情，比如zabbix等。</p>    <p>补充：OpenStack与Kolla的关系</p>    <p>OpenStack跟Kolla的关系包含两个项目：</p>    <p>第一个是nova Docker启虚拟机，它不是创建虚拟机而是一个容器，其中Magnum是在OpenStack中管理kubernetes的生命周期，随后通过API进行管理；</p>    <p>第二个项目是kuryr，因为Docker本身的网络是比较简单的，最早Docker是基于linux bridge来实现的，随后Docker推出了libnetwork机制，可以根据网络本身呈现多种实现，其中kuryr因为OpenStack Neutron顶层包括V*N，所以这个项目就是把Neutron引入到Docker的网络当中。</p>    <p> </p>    <p>来自： <a href="/misc/goto?guid=4959674628855507016" rel="nofollow">http://geek.csdn.net/news/detail/81443</a></p>    <p> </p>