1、容器化Openstack

      在对Openstack进行升级或降级时，通常有两种方式可供选择，即基于Packages的管理方式，或基于Images的管理方式。容器化Openstack的主要目的，便在于优化基于镜像的Openstack管理方式。容器化Openstack的管理方案解决了当前主流Openstack部署系统中最两人头疼的Openstack可用性和管理维护难题。

2、问题描述

      当前主流的Openstack部署管理系统或者使用基于Package的升级方式，或者使用基于Images的升级方式。TripleO采用的便是基于镜像的升级管理方式，TripleO在升级Openstack时，其会构建整个磁盘系统并重新对其进行部署，而不是仅构建组成Openstack部分服务，TripleO的这种升级方式显得过于臃肿，并存在很大的可用性缺陷。此外，在TripleO的镜像处理过程中，还需关闭运行中的虚拟机。不过，基于镜像的管理方式却是提供了管理维护的原子性，因为通过系统镜像的重新制作，所有与服务相关的软件更新和升级只需一个完整的步骤即可实现，即升级操作的原子性。
      对于其他基于Package的部署管理系统而言，由于各种零散软件包的存在，Openstack的升级过程通常需要针对一个或多个软件包分别实现，这是一个极为痛苦的过程。基于Package的升级过程通常会因为各种各样的原因失败，但是又没法退出已失败的变更。在Openstack的部署和管理维护中，通常我们希望一次性便可升级全部与服务相关的软件，如果升级不成功，则再通过一次性的操作即可回退到升级前的状态，但是基于Package的方式显然不能满足这种原子性的操作。
       要解决基于Package的非原子性操作和类似TripleO基于全镜像方式所带来的问题，容器可用来实现基于镜像的管理方式，采用容器化的Openstack部署方式，不仅可以实现实际操作的原子性，还可将升级过程对Openstack服务的影响降至最低。粗略的Nova计算节点升级测试表明[1]，在基于容器化的镜像管理方式升级过程中，服务仅有接近10s的不可用时间，而且在升级过程中无需关闭虚拟机。

3、容器化Openstack的用处

1.原子性升级或回退整个Openstack集群。终端用户可以通过这种方式将当前运行的软件版本升级为上游社区最新发行的版本，而在升级过程中服务不会终止较长时间。
2.基于服务组件的Openstack升级。用户通过这种方式对Openstack进行细粒度的服务组件升级，以限制升级失败可能造成的影响。
3.基于服务组件的Openstack回退。用户在经历了升级失败之后，通过这种方式可以很方便的回退到已知的升级前正常运行版本。

4、建议改进

基于容器的Openstack部署方式可通过树形结构来呈现，树形结构中的节点代表容器集，而每个叶子节点代表一个容器。

一、容器集应该具有如下的全部属性

1.容器集有一个或多个容器子集构成，后者由一个或多个独立容器构成；
2.一个容器集提供一个独立的逻辑服务，如Nova服务、Neutron服务等；
3.容器集被当成统一的单元进行管理，如startup、shutdown等操作时容器集被看成一个Unit进行处理；
4.每个容器集都被看成一个Unit进行Launch；
5.一个包含多个容器子集的容器集仍然被当成一个Unit进行处理；
6.对某个容器集的管理不是原子性的；
7.每个容器集均为服务高可用监控提供接口。

二、容器应该具有如下全部属性

1.可对单个容器进行原子性的升级和回退；
2.每个容器都包含有单向递增的版本号以便在与其他容器比较时识别出容器的年龄；
3.每个容器应该独立实现单一任务；
4.每个容器应该能够对自身健康情况进行检查；
5.容器存在一个能回收已退出子进程的PID 1；
6.无需对主机进行访问的容器可能不会存在任何权限；
7.对于需要访问主机的容器，可能存在超级权限。需要使用超级权限才能访问的主机对象如下：
  主机网络命名空间；
  主机UUID命名空间；
  主机IPC命名空间；
  主机持久性共享文件系统。

三、顶层容器集包含以下部分

1.database control.包括：galera/mariadb/mongodb
2.messaging control.包括：rabbitmq
3.high availability control.包括：HAProxy/keepalived
4.OpenStack interface.包括：keystone/glance-api/nova-api/ceilometer-api/heat-api
5.OpenStack control.包括：glance-controller(glance-registry)/nova-controller(nova-conductor/nova-scheduler/metadata-service)/cinder-controller/ neutron-controller(neutron-server)/ceilometer-controller(ceilometer-alarm/ceilometer-base/ceilometer-central/ ceilometer-collector/ceilometer-notification)/heat-controller(heat-engine)
6.OpenStack compute operation.包括：nova-compute/nova-libvirt/neutron-agents-linux-bridge/neutron-agents-ovs
7.OpenStack network operation.包括：dhcp-agent/l3-agent/metadata-agent/lbaas-agent/fwaas-agent
8.OpenStack storage operation.包括：Cinder/Swift(swift-account/swift-base/swift-container/swift-object/swift-proxy-server)

四、实现方法及建议

1.为了实现预期的目标，需要允许超级权限容器的存在，在docker中使用--privileged=true创建的容器被定义为超级权限容器，超级权限容器在launch时使用-v参数挂载主机文件系统，并通过--ipc=host, --pid=host, or --net=host标志共享主机全部命名空间。
2.由于使用了--net=host来共享主机网络命名空间，因此在Dockerfile中不会使用到EXPOSE操作。使用--net=host的主要动机在于这种方法的简单性，而不使用EXPOSE操作的原因，在于docker-proxy在转发或返回每个数据包时都有20ms的延时。如果期望使用EXPOSE功能，则可以参考Openstack的默认端口列表将其添加会
回每个Dockerfile文件中。
3.在launch容器时，--restart=always标志的使用可为每个容器提供某些高可用功能的测量，并确保容器按当前设计正常运转。
4.主机上应该可以运行特定的工具并监控容器健康状况，如果容器未能通过健康检查，则主机工具将重启容器。
5.Docker容器编排引擎需要被实现，除了在单节点上进行简单的容器编排之外，因为容器被设计为可在多节点上运行，因此编排工具也应该能够应对多节点情况。
6.部署工具应能够利用key-value键值对集合作为输入，并将其转化到输入环境中以传递给Docker，key-value对可以是文件，也可以是环境变量。
7.独立容器中的日志可通过某些一致方法进行提取。