Openstack部署利器-Kolla回顾

原文作者: Cheney Dong
原文链接: http://cheneydc.me/2018/06/25/kolla-for-openstack/
许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议

优美的考拉^_^

部署好累

Openstack是一个非常庞大的项目，而且各个组件都是分布式的服务架构，一开始学习发现运行起来都是问题，想着各种办法部署，然而即使部署起来了也不一定配置正确，反复磨炼一阵能跑起来了，就不太关注部署了，研究代码，修改bug，不过等着上生产，发现最大的痛又是部署，代码反而没那么复杂了。
Openstack的组件众多，分布式的架构要求部署多节点，生产环境还要考虑各个服务的高可用，根据各个网络负载情况考虑是否独立各个服务网络，依赖基础服务众多，消息队列、数据库等，其中每一块感觉都是雷区啊，部署结束后升级也是非常大的难题，做足了方案也不一定敢动手啊，哈哈。
不过容器技术出来后解决了很多问题，而Kolla项目正式通过将Openstack中各个服务容器化的方式来进行部署的一个项目，通过容器的方式进行交付，这就大大简化了跨平台的问题，同时也使得升级成为了可能。

Kolla好么？

我认为Kolla是一个非常棒的项目了，不单单是因为它解决了部署的一些痛点，更重要的是Kolla的架构和实现方式，最直观的印象就是，Kolla非常简单，但是实现的很优雅。
Kolla的简洁和优并不是单纯因为用了容器，我认为Kolla使用使用的ansible才更让Kolla称得上是一个好项目

• 第一，ansible是一套自动化运维工具，当然还有很多其他的工具，虽然没有用过，但是从ansible本身来说我觉得ansible够简单，依赖少，没有使用agent的方式，直接使用ssh进行下发
• 第二，ansible的playbook方式以及role的架构，用过几次以后真的是太方便了，能够高度的定制化，而role的架构方式非常灵活，Kolla可以说把ansible的这点用到了极致，换句话说，只要熟悉了ansible的使用，Kolla的项目就等于说一览无遗了，这样简单又好用的才是真正的好项目啊。

Kolla实际上是分为两大块的，一部分，Kolla提供了生产环境级别的镜像，涵盖了Openstack用到的各个服务，另一部分是自动化的部署，也就是上面说的ansible部分。最开始两个部分是在一个项目中的（也就是Kolla），从O版本开始将两个部分独立开来，Kolla项目用来构建所有服务的镜像，Kolla-ansible用来执行自动化部署。除此之外，kolla考虑容器的部署，容器的管理也被纳入项目中，因此有了kolla-kubernetes，通过k8s来管理整个部署的容器集群。

构建镜像

以O版本代码为例，
构建镜像的流程主要在kolla项目中，构建镜像通过kolla-build命令执行，入口在
kolla/kolla/image/build.py 中：

978 def run_build():
979     """Build container images.
980 
981     :return: A 3-tuple containing bad, good, and unmatched container image
982     status dicts, or None if no images were built.
983     """
984     conf = cfg.ConfigOpts()
985     common_config.parse(conf, sys.argv[1:], prog='kolla-build')
986                                                                                                                                                                                        
987     if conf.debug:
988         LOG.setLevel(logging.DEBUG)
989 
990     kolla = KollaWorker(conf)
991     kolla.setup_working_dir()
992     kolla.find_dockerfiles()
993     kolla.create_dockerfiles()

最终的执行构建代码都是在上面这里，首先kolla = KollaWorker(conf)构建任务读取配置并初始化，随后设置setup_working_dir()来设置临时的工作目录，因为整个构建过程实际就是将各个服务的Dockerfile构建成相应的docker镜像，但是面对不同的平台和不同的配置，Kolla项目通过jinja2语法将Dockerfile进行了定制化，通过顶层的参数设置来下发到各个Dockerfile中，那么构建的时候生成真正的Dockerfile就在刚刚设置的工作目录中了，随后通过find_dockerfiles()找到临时目录中所有的Dockerfile模板，也就是Dockerfile.j2并通过create_dockerfiles()生成相应的Dockerfile。
主要流程其实就这么多，其他都是额外提供的功能啦，慢慢扩展开就可以了，不过构建镜像提供了非常多的选择，包括：

• 安装各个服务的方式（binary 或 source）
• 平台选择(ubuntu,centos 或 debina等)
• 如果只需要输出Dockerfile不去构建的话
• 可以通过参数template-only实现
• 构建成功后推送到本地仓库（--registry --push --tag --namespace 几个组合起来）

功能非常多，具体的选项参数有哪些可以查看kolla/kolla/common/config.py模块。

镜像结构

那这么多的镜像怎样构成的呢？大体分为四层：

• base
• openstack-base
• <service>-base
• <service>

Kolla镜像结构

1. base

所有的Kolla项目基本上使用了同一个base镜像作为基础，所有的dockerfile模板在kolla/docker中，base镜像中主要定义了镜像中一些基础的内容，如：

• 命令行提示符格式
• 指定软件包源
• 安装基础的软件

所以如果需要定制以上内容就可以去更改base的Dockerfile模板了。

2. openstack-base

如果是Openstack的服务，都会以openstack_base作为基础镜像，当然openstack-base也是在base基础上构建的，内容比较少，主要是安装了openstack比较通用的基础组件以及软件包，比如oslo*和*client等内容。

3. <service>-base

在openstack-base基础上就会构建各个服务组件的镜像了，以nova为例，nova本身有多个服务，如api、conductor、compute等，类似这样的服务，Kolla中又以openstack-base为基础做了一个<service>-base镜像，nova为例也就是nova-base镜像作为其他几个服务的基础镜像，主要处理几个服务通用的内容，安装通用的软件等。

4. <service>

最后是服务镜像本身，以<service>-base为基础镜像，进行服务的部署，配置等，并设定启动入口，以及服务必要的依赖。

容器的启动

虽然Kolla对所有的服务进行了容器化，但是并没有让他们各自放飞，所有的容器内部定义了基本相同的服务启动入口，这样不管什么样的服务，只要按照相同的规则和流程就可以统一的配置启动流程了。
在base镜像中就已经COPY了一个start.sh作为每一个容器的启动入口，并定义为kolla-start，脚本很短：

#!/bin/bash
set -o errexit

# Processing /var/lib/kolla/config_files/config.json as root.  This is necessary
# to permit certain files to be controlled by the root user which should
# not be writable by the dropped-privileged user, especially /run_command
sudo -E kolla_set_configs
CMD=$(cat /run_command)
ARGS=""

if [[ ! "${!KOLLA_SKIP_EXTEND_START[@]}" ]]; then
    # Run additional commands if present
    . kolla_extend_start
fi

echo "Running command: '${CMD}${ARGS:+ $ARGS}'"
exec ${CMD} ${ARGS}

kolla-start作为容器中服务启动的入口，实际执行的内容在run_command中，这个命令是由base中的set_config.py脚本根据读取的配置生成的：

332     LOG.info('Writing out command to execute')
333     LOG.debug("Command is: %s", config['command'])
334     # The value from the 'command' key will be written to '/run_command'
335     with open('/run_command', 'w+') as f:                                                                                                                                               
336         f.write(config['command'])   

具体的配置则是在使用kolla-ansible部署服务的时候，每一个服务通过一个叫config.json的文件设置的，部署时，这个文件会挂载到容器中，这样容器会得到真正执行的内容以及相关的配置，以此正确的启动容器中的服务，这样也一定程度提供一种从外部修改或控制容器内部服务的方法，用的时候非常方便。

部署过程

部署的部分是在kolla-ansible项目中，实际整个项目就是基于ansible的role架构展开的，项目封装了kolla-ansible命令行进行了额外功能的扩展，在项目中的kolla-ansible/tools/kolla-ansible这个地方定义了命令行，从里面可以看到所有参数，大部分内容就是原生的role，很简洁好用，如果看不懂的话就先去补补ansible的内容啦，所以没什么可以多说的了。
不过对于openstack的各个服务的部署，kolla-ansible提供了自动生成密码的脚本，安全性和便捷性得到了提高。
想到再补充吧，酱紫了……