Kolla 简介

长久以来 OpenStack 部署难、 升级难的问题经常为人诟病，简单高效的部署升级方案是所有 OpenStack 用户（云服务供应商、客户、开发者）的共性刚需。Kolla 项目正是应需而生，它基于社区的最佳实践，提出了可靠、可扩展的生产级别 OpenStack Service Containers 部署方案。

简而言之，Kolla 就是一个充分运用容器特性，实现容器化部署 OpenStack 服务的 DevOps 工具。

众所周知，容器技术具有非常优秀的应用部署敏捷性和扩展性，其中又以 Docker 和 Kubernetes 作为构建容器化应用程序的主要标准，是最受欢迎的容器技术选型。为了适配多样的应用场景，社区将 Kolla 项目解耦成为了三个组件。由 Kolla 继续负责构建容器镜像，由 Kolla-ansible 和 Kolla-kubernetes 负责容器的自动化部署与管理。三者间既互相配合又自成一家，松耦合的架构更有利于覆盖用户多方面的需求。

Kolla：容器镜像构建

Kolla-ansible：容器部署

Kolla-kubernetes：容器部署与管理

Kolla 显著的特点是「开箱即用」和「简易升级」，前者由编排工具提供自动化支撑，后者则完全是容器技术的功劳。Kolla 追求为每一个 OpenStack Service 都构建容器镜像，将升级/回滚的粒度（隔离依赖关系集）降维到 Service 级别，实现了操作原子性。版本升级只需三步：

Pull New Docker Image

Stop Old Docker Container

Start New Docker Container

即使升级失败，也能够立即 Start Old Docker Container 完成回滚。

从最新的 Kolla Queens Release 可以看出，Kolla 为实现「从升级到零宕机升级」的目标作出了努力，现已支持 Cinder 和 Keystone 项目的最小宕机时间升级，并不断扩展至其他项目。

笔者认为，零宕机升级功能的发布对 Kolla 而言具有里程碑式的意义，以往，Kolla 提供的升级服务因为具有时延性，只是解决了用户的痒点需求（在部署和升级上提供了便利）。如何在生产环境实现基础设施管理平台升级的同时保障用户业务负载的连续性和可用性，才是用户最深切的痛点。这样有助于加深用户和 OpenStack 社区的粘合度，紧随社区发展，并不断引入新的功能来壮大自身。现在的 Kolla 或许离实现这一目标已经不远了。

除此之外，Kolla-ansible 还发布了支持「开发者模式」，这是一个值得 OpenStack 开发者们高兴的消息。

支持开发模式。这个对 OpenStack 的开发者很是方便。以住，开发者可能要通过 devstack 搭建完整的 OpenStack 来开发，但是部署复杂，难度高。现在 kolla-ansible 已经支持了开发模式。通过配置要开发环境的 dev_mode, 如horizon_dev_mode:true, 那么 horizon 容器内的代码会从物理机上挂载进去，开发者对代码修改后，就可以直接看到修改后的效果。十分方便。

from 99Cloud 张雷（Kolla PTL）

虽然现在支持开发者模式的项目同样有限，但社区贡献者已经提交了 Blueprint，相信很快就能满足普遍需求。

在下面的内容中，我们以 Kolla & Kolla-ansible 的组合，主要分 3 个部分介绍如何轻松部署出一套 OpenStack 环境。

环境依赖准备

使用 Kolla 构建镜像

使用 Kolla-ansible 部署 OpenStack

部署 OpenStack

部署环境：

平台：VMware Workstations

操作系统：CentOS 74，4C/8G

双网卡（eth0 192.168.1.13/24，eth1 DHCP）

Kolla branch queens（6.0.0）

Kolla-ansible branch queens

OpenStack Queens

须知：

建议最小化安装 CentOS 7.4，并以 root 用户完成所有操作

建议科学上网，因为有些包没有国内镜像

建议使用 eth0 进行 ssh 和访问外网，因为 eth1 用作 External Network，被放到 network namespace qrouter-XXX 之后，网络连接会断开

本文面向 Kolla 入门，采用 For development & All-In-One 部署方式

Troubleshooting List 位于文末

准备操作系统基础环境

安装系统基础环境依赖包：

yum install epel-release -yyum update -yyum install python-pip python-devel libffi-devel gcc openssl-devel libselinux-python vim git wget -y

惯例开启 NTP 时间同步服务：

systemctl enable ntpd.service && systemctl start ntpd.service && systemctl status ntpd.service

惯例关闭防火墙服务：

systemctl stop firewalld && systemctl disable firewalld && systemctl status firewalld

惯例禁用宿主机的 Libvirt 服务：大多数操作系统会默认启动 Libvirt，但使用 Kolla 来部署 OpenStack 的话，Libvirt 应该在容器中运行并管理虚拟机。所以宿主机的 Libvirt 需要被关闭，以免造成冲突。

systemctl stop libvirtd.service && systemctl disable libvirtd.service && systemctl status libvirtd.service

Tips：建议此处打上快照

准备 Python 基础环境

安装基础依赖包：

pip install -U pippip install -U ansiblepip install -U toxpip install -U python-openstackclientpip install -U dockerpip install -U jinja2

Tips：下列软件包是版本问题的高发区，不妨提前查看一番。

docker>=2.0

jinja 2>=2.10

ansible>= 2.0

确保没有安装 docker-py

NOTE：较新的版本中使用 docker 库代替 docker-py

修改 ansible 配置文件：

mkdir /etc/ansiblevim /etc/ansible/ansible.cfg[defaults]host_key_checking=Falsepipelining=Trueforks=100deprecation_warnings=False

为了提高部署效率，这里调整了一些 Ansible 服务参数。

准备 Docker 基础环境

安装 Docker：

curl -sSL https://get.docker.io | bash

开启 Docker 的共享挂载功能：

mkdir /etc/systemd/system/docker.service.dtee /etc/systemd/system/docker.service.d/kolla.conf << 'EOF'[Service]MountFlags=sharedEOF

启动 Docker 服务：

systemctl daemon-reload && systemctl enable docker && systemctl restart docker

kolla & kolla-ansible

Tips：这里使用两个沙盒环境进行源码安装，所以建议在不同的终端内操作，避免混乱。

安装 Kolla：

创建沙盒环境

virtualenv kolla_envsource kolla_env/bin/activate

源码安装

git clone /openstack/kolla -b stable/queenscd kollapip install -r requirements.txt -r test-requirements.txt -e .

生成配置文件

tox -egenconfigmkdir /etc/kolla/cp etc/kolla/kolla-build.conf /etc/kolla/

编辑 kolla-build.conf：控制 Kolla Image Build 的细则。

vim /etc/kolla/kolla-build.conf[DEFAULT]base = centosinstall_type = sourcenamespace = kollapush = false# The Docker Images tag (string value)tag = 6.0.0

base：使用 CentOS 做为 Base 镜像

install_type：使用源码方式部署

tag：指定构建镜像的 Tag 为 6.0.0（Kolla Queue 的版本号）

安装 Kolla-ansible：

创建沙盒环境

virtualenv kolla-ansible_envsource kolla-ansible_env/bin/activate

源码安装

git clone /openstack/kolla-ansible -b stable/queenscd kolla-ansiblepip install -r requirements.txt -r test-requirements.txt -e .

生成配置文件

cp etc/kolla/globals.yml /etc/kolla/cp etc/kolla/passwords.yml /etc/kolla/

编辑 passwords.yml：设定 OpenStack 服务的各种密码，这里仅设定管理员的登陆密码。

vim /etc/kolla/passwords.ymlkeystone_admin_password: fanguiju

编辑 globals.yml：这是最重要的配置文件，用于控制 Kolla-ansible Deploy 的细则。

vim /etc/kolla/globals.ymlkolla_dev_mode: "yes"network_interface: "eth0"neutron_external_interface: "eth1"kolla_internal_vip_address: "192.168.1.15"kolla_base_distro: "centos"kolla_install_type: "source"docker_registry: ""docker_namespace: "kolla"openstack_logging_debug: "true"enable_cinder: "no"enable_heat: "no"# Valid option is Docker repository tagopenstack_release: "6.0.0"

kolla_dev_mode:"yes"：启用开发者模式

openstack_release：需要与镜像的 Tag 一致，否则部署时找不到镜像。

network_interface：指定管理网接口

neutron_external_interface：指定外部网接口

kolla_internal_vip_address：指定 HAProxy 虚拟 IP，单点部署可以弃用 HAProxyenable_haproxy:"no"。

NOTE：globals.yml 文件的配置项，实际上大多是 Ansible 的自定义变量，可用于灵活配置 Playbook 的行为。

修改 Hypervisor Type：因为操作环境是 VMware 的虚拟机，所以存在嵌套虚拟化不支持 KVM 的问题，如果你希望启动 OpenStack 实例，那就需要启用 QEMU（Default KVM）。

mkdir -p /etc/kolla/config/novacat << EOF > /etc/kolla/config/nova/nova-compute.conf[libvirt]virt_type=qemucpu_mode = noneEOF

Kolla Build Images

简单的来理解 Kolla 组件的话，它就是一个自动化构建部署 OpenStack 服务所需要的镜像的工具。其内含组织了大量的 Dockerfile，供构建镜像时使用。

实际上，就单纯的部署开发测试环境而言，是允许不使用 Kolla 组件的。Kolla-ansible 自身也实现了检测和构建镜像的策略。如果 Deploy 时，检测到镜像没有 Ready，Kolla-ansible 就会从远程仓库 Pull 下来镜像，然后再执行 Deploy。

不是这种方式的部署速度是比较慢的，而且 Pull 下来的镜像也未必会包含有最新的 Commit，就更别提定制化镜像需求了。所以，这里还是建议使用 Kolla 在本地构建镜像，甚至是搭建 Local Registry（本地容器仓库）。

cd kolla/tools./build.py -p default

参数项-pdefault对应 kolla-build.conf 的 [profiles] Sections，default 类型表示仅构建核心项目的镜像。

[profiles]...# Default images (list value)default = chrony,cron,kolla-toolbox,fluentd,glance,haproxy,heat,horizon,keepalived,keystone,mariadb,memcached,neutron,nova-,openvswitch,rabbitmq

接下来有一段较长的镜像构建时间，如果出现异常中断，可重复执行。赖于 Docker 的 Build Cache 功能，能为重跑追回不少时间。

NOTE：但有些情况下，可能会把错误的配置参数 Cache 住，此时建议执行 Cleanup 操作之后再重跑：

# 从系统中移除部署的容器tools/cleanup-containers# 移除由于残余网络变化引发 docker 启动的 neutron-agents 主机tools/cleanup-host# 从 Cache 中移除所有的 docker imagetools/cleanup-images

Build Successfully：

查看镜像列表：

从上图可见，Kolla 构建的镜像一般有四层，Docker 的镜像分层结构更有利于抽象环境依赖集，降低依赖包重复率，提高镜像传输率。有几分 “代码复用” 的意味。

base image：提供一个最基本的操作系统环境，几乎是所有镜像的基础。

openstack-base image：所有 OpenStack 服务镜像的基础，安装了 Service 层级的依赖集。

<project>-base image：某个项目的基础，安装了 Project 层级的依赖集。

<service>image：一个具体 Service 的特异依赖集，设置了服务启动入口。

Kolla 中的 Dockerfile 文件，是使用 Jinja2 语法来编写的。使其具备 Jinja2 Template 的特性，更便于渲染变量。如果你有个性化的定制需求，可以通过修改相应的 Dockerfile.j2 实现。e.g.

vim /root/kolla/docker/nova/nova-api/Dockerfile.j2

Kolla-ansible Deploy

可以把 Kolla-ansible 看作是 Kolla 对 Ansible 的封装，实现了大量的 Play 和自定义模块。

Kolla-ansible 同样通过提供一个完整的 Playbook 来实现脚本自动化，在源码目录 inventory 下还提供了 all-in-one 和 multihost 两种主机清单。单点部署的话，一般不需要多做修改，直接使用 all-in-one 清单是个不错的选择。但如果你希望进行多节点部署，可以通过修改 multihost 清单中的主机分组来达到定制化分布式部署架构的目的。

NOTE：进行多节点部署，还需要部署 Local Docker Register 服务器。

Tips：多节点部署时，需要保证管理节点和各主机之间能够使用 SSH 免密登陆。

cd kolla-ansible/cp ansible/inventory/* ~$ ll ~-rw-r--r-- 1 root root 8292 May 28 09:43 all-in-one-rw-r--r-- 1 root root 8766 May 28 09:43 multinode

在正式 Deploy 之前，还需要进行一些准备工作：

Step 1. 自动生成随机密码来填充 passwords.yml 项目

kolla-genpwd

Step 2. 处理 bootstrap servers 所需要的依赖

cd kolla-ansible/tools./kolla-ansible -i ~/all-in-one bootstrap-servers

选项-i指定主机清单，这和 Ansible 的用法是一致的。

Step 3. 部署环境预检查

./kolla-ansible -i ~/all-in-one prechecks

正式开始 Deploy：

./kolla-ansible -i ~/all-in-one deploy

成功 Deploy，查看 Containers 状态：

从上图可见，Service Container 使用了 kolla_start 脚本来启动

因为 Kolla 缺省使用的是--net=host网络，所以没有必要做端口映射

检验 & 使用

生成 admin-openrc.sh 文件：用于导入 Keystone Auth 环境变量

./kolla-ansible post-deployll /etc/kolla/admin-openrc.sh

初始化运行环境：会自动执行下列操作

Creating glance image.

Configuring neutron.

Generating ssh key.

Configuring nova public key and quotas.

NOTE：如果你希望 External Network 正常运行，还需要编辑 init-runonce 初始化脚本中的网络配置，设定为 eth1 的网络元素。

# e.g. eth1 IP：172.16.0.10/24# This EXT_NET_CIDR is your public network,that you want to connect to the internet via.EXT_NET_CIDR='172.16.0.0/24'EXT_NET_RANGE='start=172.16.0.100,end=172.16.0.200'EXT_NET_GATEWAY='172.16.0.1'

这样 Instance Floating IP 才能够利用命名空间 qrouter-XXXX 中的 iptables 进行 NAT 转发，访问外网。

source /etc/kolla/admin-openrc.sh./init-runonce

启动实例，验证环境：

openstack server create \--image cirros \--flavor m1.tiny \--key-name mykey \--network demo-net \demo1

查看实例列表：

NOTE：如果你希望彻底清理完部署好的环境，只需执行下列指令。

kolla-ansible destroy -i all-in-one --yes-i-really-really-mean-it

最后

OpenStack 和容器的紧密联系已经成为了不可逆转的趋势。不夸张的说，拥抱容器，是 OpenStack 社区的求生之路。现在我们常见的 OpenStack 与容器的结合方式不外乎下列 3 种形式：

OpenStack On Container

Container On OpenStack

OpenStack & Container

Kolla 服务于其中的 OpenStack On Container。容器化的 OpenStack 允许用户以快速、可靠甚至是无感的方式进行部署、升级、扩展，让 OpenStack 的自动化集成与交付变得简单。

这些优势对于用户而言，具有非常可观的利好，因为在降低了云基础设施运维成本的同时，还能够让服务架构具有高度的灵活度。尤其是在 kubernetes 上部署 OpenStack，背靠 kubernetes 的自修复、快发布特性，简直相得益彰，为上层应用服务提供了优秀的弹性支撑。

现在已经有行业用户交出了「用 Kolla 48 小时完成 300 个节点混合存储与多网络区域的部署实践」的实践案例。这要放到 Kolla 出现之前是令人感到不可思议的事情。从这个角度来看，Kolla 已经成为了 OpenStack 产品化的重要一环，它令 OpenStack 的落地实施变得简单，为用户带来一次良好的闭环体验。

最后，笔者认为，Kolla 最终的使命或许是成为 OpenStack On Container 的一站式解决方案。实在是令人期待！

Troubleshooting List

ERROR 1：

Cannot uninstall 'requests'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

TS 1：因为requests包被系统环境依赖，不能卸载，也不需要卸载，跳过即可。

pip install -U python-openstackclient python-neutronclient --ignore-installed requests

ERROR 2：

https://packagecloud.io/grafana/stable/el/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 302 - Found

TS 2：网络不可达，请科学上网或随缘安装。

ERROR 3：

TASK [neutron : Checking tenant network types] ****************************************************************************************fatal: [controller]: FAILED! => {"msg": "The conditional check 'item not in type_drivers' failed. The error was: An unhandled exception occurred while templating '{{ neutron_type_drivers.replace(' ', '').split(',') | reject('equalto', '') | list }}'. Error was a <class 'jinja2.exceptions.TemplateRuntimeError'>, original message: no test named 'equalto'\n\nThe error appears to have been in '/root/venv/share/kolla-ansible/ansible/roles/neutron/tasks/precheck.yml': line 41, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Checking tenant network types\n ^ here\n”}

TS 3：Jinja2 版本过低不支持 reject，需要高于 2.8。

ERROR 4：Deploy 过程中重复 Build 镜像

TS 4：kolla 和 kolla-ansible 指定的 Docker Image Tag 不一致。

＞＞关于作者：范桂飓，九州云（99Cloud）OpenStack 研发工程师，曾先后服务于 Windows Azure、Redhat OpenStack 与 Prophetech HyperMotion。云物互联公号主，现专注于探索云计算与边缘计算的深度结合应用场景。

＞＞关于『Linux宝库』：欢迎关注『Linux宝库』微信公众号，这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴，为开源爱好者和从业者点亮人生。

- END -

- 责任编辑：RAY MAN -

为开源爱好者和从业者点亮人生！

长按二维码关注我们