Kolla


    Kolla使用Docker容器和Anisble playbooks来实现这个目标。Kolla是开箱即用的,即使你是个新手也可以很快的使用kolla快速部署你的openstack集群。Kolla也允许你根据实际的需求来定制化的部署。

    kolla目前已经可以部署以下openstack项目

    可以部署的基础组件包括


    可以参照kolla官方文档https://github.com/openstack/kolla/blob/master/doc/quickstart.rst 进行部署。


    可以看下默认的多节点架构

    1. -network
    2. +[haproxy]
    3. +haproxy01
    4. +haproxy02

    配置文件管理

    每个openstack服务都运行在一个容器中,那kolla是怎么管理openstack的配置的呢? 我们拿nova-compute的配置管理来举例

    首先kolla会使用ansible为nova-compute生成一份配置文件放在/etc/kolla/nova-compute/目录下。

    1. #nova_custom_config默认是/etc/kolla/configs/nova
    2. #node_config_directory默认是 /etc/kolla
    3. - name: Copying over nova.conf
    4. merge_configs:
    5. vars:
    6. service_name: "{{ item }}"
    7. sources:
    8. - "{{ role_path }}/templates/nova.conf.j2"
    9. - "{{ node_custom_config }}/global.conf"
    10. - "{{ node_custom_config }}/database.conf"
    11. - "{{ node_custom_config }}/messaging.conf"
    12. - "{{ node_custom_config }}/nova.conf"
    13. - "{{ node_custom_config }}/nova/{{ item }}.conf"
    14. - "{{ node_custom_config }}/nova/{{ inventory_hostname }}/nova.conf"
    15. dest: "{{ node_config_directory }}/{{ item }}/nova.conf"
    16. with_items:
    17. - "nova-api"
    18. - "nova-compute"
    19. - "nova-conductor"
    20. - "nova-consoleauth"
    21. - "nova-novncproxy"
    22. - "nova-scheduler"
    23. - "nova-spicehtml5proxy"

    大家可能会注意到kolla使用merge_configs来完成配置文件的合并,那么merge_configs是干什么的呢?顾名思义,merge_configs就是把多个配置文件合成一个,kolla为什么要这样做呢?
    openstack配置选项非常多但是真正需要管理的则很少,对这部分选项kolla使用模版的方式管理,同时由于merge_configs的使用,使得用户可以非常方便的添加自己的定制化选项。比如你部署kolla在一台虚拟机上,你必须使用QEMU hypervisor来替代KVM hypervisor。那么你可以在/etc/kolla/config/nova/nova-compute.conf中添加以下配置

    merge_configs的代码在 ansible/action_plugins/merge_configs.py

    启动容器时/etc/kolla以docker卷的形式挂载到/var/lib/kolla/config_files目录下

    1. - name: Starting nova-libvirt container
    2. kolla_docker:
    3. common_options: "{{ docker_common_options }}"
    4. image: "{{ nova_libvirt_image_full }}"
    5. name: "nova_libvirt"
    6. pid_mode: "host"
    7. privileged: True
    8. volumes:
    9. - "{{ node_config_directory }}/nova-libvirt/:{{ container_config_directory }}/:ro"
    10. - "/etc/localtime:/etc/localtime:ro"
    11. - "/lib/modules:/lib/modules:ro"
    12. - "/run/:/run/"
    13. - "/dev:/dev"
    14. - "/sys/fs/cgroup:/sys/fs/cgroup"
    15. - "kolla_logs:/var/log/kolla/"
    16. - "libvirtd:/var/lib/libvirt"
    17. - "nova_libvirt_qemu:/etc/libvirt/qemu"
    18. when: inventory_hostname in groups['compute']

    容器启动脚本会根据nova-compute.json来将配置文件拷贝到/etc并设置合适的权限

    1. {
    2. "command": "nova-compute",
    3. "config_files": [
    4. {
    5. "source": "{{ container_config_directory }}/nova.conf",
    6. "dest": "/etc/nova/nova.conf",
    7. "owner": "nova",
    8. "perm": "0600"
    9. }{% if nova_backend == "rbd" %},
    10. {
    11. "source": "{{ container_config_directory }}/ceph.*",
    12. "dest": "/etc/ceph/",
    13. "owner": "nova",
    14. "perm": "0700"
    15. }{% endif %}
    16. ]
    17. }

    关于kolla配置文件的管理还可以参考

    nova-fake测试控制平台性能

    由于所有服务都运行在容器中,那么是不是我升级compute节点时,该节点的虚机都会进入关机状态呢,kolla使用super-privilege的容器来解决了这个问题具体可以参考kolla PTL的文章https://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/

    平滑升级


    查看log

    1. cd /var/lib/docker/volumes/kolla_logs/
    1. docker exec -it service_name bash

    root权限问题

    出于安全考虑很多kolla服务都是运行在非root下,进入容器后拿不到root权限,我们还以nova_compute为例,可以修改/etc/kolla/nova_compute/config.json改为以下

    然后在/etc/kolla/nova-compute添加nova.sudo

    1. nova ALL=(ALL) NOPASSWD: ALL

    重启容器后即可sudo到root用户下调试

    定制化build镜像

    参考


    优点

    • 配置管理灵活方便
    • 可以平滑升级
    • 部署简单
    • 环境隔离
    • 多种安装源
    • 支持的部署的服务多

    缺点

    • debug不方便