kolla综合
kolla简介：
kolla是openstack下面用于自动化部署的一个项目，它基于docker和ansible来实现，docker主要负责镜像制作，容器管理。而ansible主要负责环境的部署和管理。
准备：
安装kolla，ansible,docker,Jinja2及相关依赖
kolla镜像制作流程
规划：
1.基于什么操作系统制作？
2.采用源码安装，还是yum/apt包安装？
3.选择openstack的哪个版本（最低M版）
4.管理镜像仓库的容器registry绑定的ip以及映射的端口
镜像的依赖：
比如制作一个nova-api的容器镜像（假设基于centos,使用源码的方式安装包），首先需要制作一个centos-source-base的镜像，接着制作openstack-base的镜像，然后制作nova-base的镜像，最后制作nova-api的镜像。通过这种方式，既可以保证通用的包的版本一致，又可以解决包依赖冲突的问题。
neutron-server镜像的插件
插件将在构建镜像时添加到名为plugins-archive的tar文件并安装至指定的镜像
注意：仅适用于指定install type为source
按照以下格式，增加一下设置项至 /etc/kolla/kolla-build.conf
[<image>-plugin-<plugin-name>]指定安装插件的镜像，指定插件标识名称
例如在neutron-server添加neutron-lbaas和neutron-vpnaas
[neutron-server-plugin-networking-vpnaas]
type = url
location = http://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-9.0.0.tar.gz
[neutron-server-plugin-networking-lbaas]
type = url
location = http://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-9.0.0.tar.gz镜像制作的配置：
关于镜像制作的配置存放在/kolla/etc/kolla-build.conf里面，主要是每个容器源码安装的配置，至于使用yum/apt安装的方式，包的安装则由每个容器的Dockerfile来控制
制作镜像：
如果前面的都弄好，只需使用kolla-build相关命令就可以自动制作镜像并上传到镜像仓库，由于kolla使用镜像缓存，如果制作镜像出现中断，可以重复执行镜像制作的命令。
kolla部署流程
规划：
节点的规划和容器的分布由inventory控制，/usr/share/kolla/ansible/inventory目录下的all-in-one和multinode,如果你想单节点部署，你需要指定all-in-one，如果是多节点部署，你需要指定multinode。你可以根据实际需求修改all-in-one或multinode。
配置：
变量的配置
关于部署的很多变量存放在/usr/share/kolla/ansible/group_vars/all.yml(这里面的变量有一部份与/etc/kolla/globals.yml里面的配置冲突，这些冲突的配置项以globals.yml里面的配置为准)，使用这些变量值来替换playbook里面的对应的变量，控制playbook的最终结果。这些playbook主要分为4类default代表默认的一些配置，meta代表依赖于哪个playbook，task代表具体的部署任务，template代表模板，主要包含容器的配置文件，以及容器启动时的一些初始化操作，主要是拷贝配置文件和启动该容器对应的服务
节点的配置
各个角色节点安装好操作系统后，必须要安装docker以及添加配置，修改hostname,网卡配置，如果这里出现问题，下一步的检测会报错。值得注意的是，像将存储后端改成ceph，会对存储节点的磁盘进行些配置，但是检测貌似没有关于这方面的任务，如果采用kolla部署，肯定需要对检测的playbook进行完善。
注：这些操作我是手动执行的，然而kolla在3.0.0及以上的版本提供了deploy-bifrost，deploy-servers两个命令行参数来分别启用一个bifrost的容器和通过bifrost来对节点进行自动化的配置。至于效果怎么样，我没试过。
检测：
kolla提供了一个检测命令，可以对各个角色节点进行一些检测，主要是包版本检测：docker-py,Ansible;端口检测：所有容器配置的监听端口是否已经被占用；服务检测：这里检测的就比较杂了，比如libvirt是否在运行，如果运行就会报错，比如Docker版本是否满足要求等等，你可以查看/usr/share/kolla/ansible/roles/prechecks/tasks下面的playbook，知道所有的检测项。当检测出错时，你就需要根据出错的信息，对某些角色的节点进行些修改配置。
检测通过，下面的部署不一定成功，但检测没通过，下面的部署是肯定失败的。
部署：
如果上面的步骤没问题，只需执行kolla-ansible的相关命令就可以自动完成部署并启动相关容器以及容器里面对应的服务
清理：
在某些情况下，可能需要对环境中的容器，镜像，甚至节点上的所有关于kolla的配置，进行清理，可以使用kolla-ansible destory的子命令对环境清理
扩展：
kolla增加节点理论上很简单，只需要两步，一是修改对应的inventory，二是对待添加节点做好部署前的准备工作。由于资源的关系，并未做过相关的测试。
kolla开发流程
修改配置：
修改某个容器：
通过修改对应节点/etc/kolla/目录下对应的服务的配置文件，然后重启对应的容器，就可以修改相关配置
修改多个容器：
通过修改部署节点上/usr/share/kolla/ansible/roles相关目录下配置文件的模板和/etc/kolla/globals.yml,以及/usr/share/kolla/ansible/group_vars/all.yml,然后执行kolla-ansible的子命令reconfigure，可以修改相关容器的配置。
注意：这种方式会将所有容器的配置重新覆盖一次，所有容器都会重启一次
修改代码：
1.基于改动的容器生成新的镜像：
直接修改容器里面的代码，然后使用docker commit基于你改动的容器，重新制作一个镜像，指定一个合适的tag(即容器镜像的版本)，最后上传到镜像仓库。
缺点:由于docker分层存储的特性，每基于改动的容器进行一次commit，就会生成一层新的layer，layer无法删除，过多的layer会导致容器镜像的体积越来越庞大
2.基于Dockerfile重新制作的镜像：
由于采用源码的方式安装相关的第三方库，我们可以在git上维护相关的所有代码，在我们提交新的commit的时候，通过拉取新的源码，重新用Dockerfile制作镜像。一般来说Dockerfile都不需要变化。
3.直接以root用户登录到容器修改代码：
docker exec -u 0 -it <container_name> bash注意：当移除旧的容器，如果简单的执行docker run的相关命令启动一个新的容器会出错，原因是启动容器时会做些初始化的操作，由于涉及到文件的拷贝，所以会出现缺少相关文件的报错。而启动容器以及容器的初始化的操作由kolla_toolbox来执行，具体的由kolla_toolbox里的/usr/local/bin/kolla_start 和 /usr/local/bin/kolla_set_configs来控制。至于如何以新的容器镜像成功的启动一个新的容器，还需要测试。
环境升级：
可以通过修改/etc/kolla/global.yml里面openstack-release的参数，然后执行kolla-ansible upgrade的子命令升级环境.
注意：
1.如果在虚拟环境（virt_type: qemu）升级libvirt,可能会失败.
2.libvirt的升级还需要进一步验证。
回滚：
上游没有关于回滚的操作描述，不过回滚的流程跟升级差不多
kolla上游bug统计
Kolla 2.0.3
Importance: 29 Critical,15 High,4 Medium,2 Low,15 Undecided
Status: 7 New, 2 Incomplete, 9 Invalid, 4 Won’t Fix, 13 Confirmed, 2 Triaged, 2 In Progress, 14 Fix Committed, 12 Fix Released
Kolla 3.0.2
Importance: 11 Critical,16 High,2 Medium,24 Undecided
Status: 6 New, 2 Incomplete, 3 Invalid, 5 Confirmed, 4 Triaged, 4 In Progress, 26 Fix Committed, 3 Fix Released
附加
1.docker容器的健康检测
https://github.com/docker/docker/pull/23218/commits
https://blog.newrelic.com/2016/08/24/docker-health-check-instruction/
2.docker重新部署单个服务
比如：当我们对一个容器的镜像进行修改后，需要替换掉旧的容器，由于容器只有一个，不可能因此重新更新整个环境。
https://docs.docker.com/docker-cloud/apps/service-redeploy/