• 不只是安装,Kolla 让 OpenStack 运维变简单


    使用 kolla 部署的 OpenStack 环境和传统直接安装的环境相比较,因为使用了全容器化部署,基本操作上有很大不同。对于初学者,操作变得更清晰和更简单了,但是如果你已经有了一定的经验,可能反而会不习惯。

    本篇文章就以“创建实例”这个最简单的任务,带你掌握最基本最常用的操作。

    概述

    上一篇文章中,我们把环境搭建完成,登录之后就结束了。今天的任务就是初步验证环境的可用性,最直接的办法莫过于创建一个虚拟机了。

    这不是一个零基础的 OpenStack 教程,以下内容假定读者已有一定的基本操作经验。

    准备工作

    首先,为了能够启动一个虚机,至少需要完成下面的准备工作:

    • 新建镜像
    • 新建规格
    • 新建网络

    这些操作都将在 dashboard 上完成,不涉及后台,所以和其它环境并没有什么不同。

    新建镜像

    首先下载一个专门用来测试的迷你 Linux 系统镜像,CirrOS,进入下载页面 后选择最新的 0.4.0 版本:

    选择最新的版本

    针对不同的 CPU 架构和使用场景,有不同的镜像格式:

    注意选择正确的架构和格式

    点击直接下载最新的 64 位版本 cirros-0.4.0-x86_64-disk.img,镜像的文件格式是 qcow2

    qcow2 是镜像的格式,有时保存为 .img 后缀,可用 file 命令查看。

     $ file cirros-0.4.0-x86_64-disk.img 
     cirros-0.4.0-x86_64-disk.img: QEMU QCOW Image (v3), 46137344 bytes
    

    新建规格

    因为我们在 VirtualBox 虚机中部署的 All-In-One 环境,本身也没有多少资源可用了,CirrOS 系统也不需要很多内存,我们就创建一个迷你的规格,

    • 1 vCPU
    • 512 MB 内存
    • 1 GB 存储

    满足测试即可。

    新建网络

    Kolla 部署环境时,已经默认配置了 VxLAN 类型的隧道网络,我们直接创建租户网络即可。

    创建租户网络

    还记得我们安装系统时的第 2 块网卡么,那是专门给 Neutron 的外部网络准备的,本次实验我们暂时还用不到。

    新建实例

    然后开始新建实例,如果不出意外会遇到如下错误:

    虚机创建错误

    创建失败~~ 接下来让我们去后台检查并解决。

    这里有可能会遇到另一个问题,错误日志会显示消息超时,错误原因是 nova-scheduler 服务在系统重启后有一定几率会启动失败,请参考下面的指导,重启服务即可。

    检查服务状态

    在平常部署的环境里,OpenStack 的各个服务安装后会在系统里注册为后台服务,我们查看服务的命令是和操作系统相关,例如:

    $ systemctl status openstack-nova-api
    

    使用了 kolla 部署的环境,所有的服务都是在 docker 容器中启动的,我们直接查看容器的状态就可以了:

    $ sudo docker ps
    

    docker ps

    可以看到每个服务都对应到一个容器。比如 nova 有几个子服务,nova-apinova-compute 等,都是独立的容器。正如我前面说的,相对于以为的环境,对新手来说,到底一套 OpenStack 系统有哪些服务在运行,可能还不那么清楚,现在看上去一目了然。

    注意,服务名是减号 - 连接,而容器的名字是用下划线 _ 连接

    大部分情况下,容器内的服务出现问题,导致容器状态异常的情况下,它们都会自动重启。当然,也可能会有启动不了的情况。这时候,使用 docker ps 命令只会显示已经启动的容器,不能代表大家都正常,必须加上 -a 选项,列出所有容器:

    $ sudo docker ps -a
    
    

    各个容器看上去没什么异常,我们去检查一下服务的日志。

    查日志

    传统的安装方式中,每个服务在 /var/log 目录下有各自的日志文件保存路径,例如 /var/log/nova

    现在每个服务都是一个容器,我们自然会想到登入到容器里面,查看相应的日志文件:

    [kolla@control01 ~]$ sudo docker exec -it nova_compute bash
    (nova-compute)[nova@control01 /]$ cd /var/log/nova/
    (nova-compute)[nova@control01 /var/log/nova]$ ls
    (nova-compute)[nova@control01 /var/log/nova]$     <-- 空的
    

    竟然是空的!不过不用着急。我们不妨先思考下如果日志文件真的保存在容器中会怎样?

    一个问题,或者说一个业务流程,往往会涉及到多个服务,也就是说,日常在排查问题时,需要查看多个日志文件。所以可以想见,像这样每个容器逐个进去查看文件,会非常地不方便。

    另外,容器的特点之一,就是希望它是无状态的,我们可能随时会重新创建一个容器,如果日志只是简单地存在容器里,那么每次重建容器,日志内容也就丢失了。这里你可能会想到,用 docker volume 不就解决问题了么。

    事实上,kolla 做的更好。它用了更专业日志收集工具 Fluentd 来汇总所有服务产生的日志。具体的技术细节我们以后有空再深入研究。

    现在我们只需要知道,所有的日志文件在容器外面就可以查看,它们集中存放在 /var/log/kolla/ 目录中。

    这里虚机创建失败的问题,我们可以查看 nova-compute 日志:

    vi /var/log/kolla/nova/nova-compute.log
    

    nova-compute 日志

    从错误提示可以看到,是因为 kvm 的问题,我们使用的是虚拟机,所以没法支持这个特性,必须修改一下,使用纯软件的(即 qemu)虚拟化。

    在虚拟机中创建虚机还可以通过开启 KVM 嵌套虚拟化的特性来实现,但是 VirtualBox 貌似不支持。

    修改配置(错误的方式)

    配置文件在容器中的位置和我们平常环境中的并无不同:

    [root@control01 ~]# docker exec -it nova_compute bash
    (nova-compute)[nova@control01 /]$ cd /etc/nova/
    (nova-compute)[nova@control01 /etc/nova]$ ls
    api-paste.ini  nova.conf  policy.json  release  rootwrap.conf
    

    我们先按照常规方法修改,将下面的 kvm 修改为 qemu 后保存退出:

    (nova-compute)[nova@control01 /]$ cd /etc/nova/
    (nova-compute)[nova@control01 /etc/nova]$ vi nova.conf 
    
    [libvirt]
    connection_uri = qemu+tcp://10.10.10.1/system
    virt_type = kvm
    

    改完配置之后的问题是,如何重启服务让修改生效呢?

    重启服务

    如果你对 docker 比较熟悉的话,应该知道容器里面是没有 systemd 的,服务都是在前台运行。所以不能用下面的命令:

    $ sudo systemctl restart openstack-nova-compute
    

    那怎么去重启服务呢?

    其实非常简单,直接重启容器就可以了!

    $ sudo docker restart nova_compute
    

    不过,重启完容器之后,如果你细心点再去看一看,会发现刚才的修改消失了!

    如果配置有问题,容器启动可能会失败,可以刷几次 docker ps 命令确保容器的状态成功。

    修改配置(正确的姿势)

    如果是对 docker 有所理解的话,其实上面直接在容器内修改配置的时候就应该有疑义。如果配置信息仅仅是保存在容器内的话,那容器重建怎么办?

    所以这里的问题和日志文件是类似的,我们首先想到的肯定还是 docker volume 来实现。不过现在的现象显然也不太对劲:如果配置文件是存储在 volume 中,修改为什么会在容器重启后失效呢?

    实际上,kolla 确实使用 volume 挂载了配置文件,但是并没有直接挂载到对应的位置,其中又添加了一次处理,我们先来看宿主机上配置文件所在的位置:

    [root@control01 ~]# cd /etc/kolla/nova-compute
    [root@control01 nova-compute]# ls
    config.json  nova.conf
    

    注意到其中的 config.json 在容器里面是看不到的,而 nova.conf 和容器内的是一致的。
    kolla 的大致处理流程是这样的:

    1. 把这个目录挂载到容器的 /var/lib/kolla/config_files 目录
    2. 在容器的启动脚本中加了处理配置的脚本:kolla_set_configs
    3. kolla_set_configs 根据 /var/lib/kolla/config_files/config.json 中的配置来处理配置文件

    现在看一下 config.json 中的内容,是不是很好理解了:

    {
        "command": "nova-compute",
        "config_files": [
            {
                "source": "/var/lib/kolla/config_files/nova.conf",
                "dest": "/etc/nova/nova.conf",
                "owner": "nova",
                "perm": "0600"
            }
        ],
    }
    

    在宿主机下更改 /etc/kolla/nova-compute/nova.conf,并再次重启容器,再次创建虚机。这次应该没有问题了。

    总结

    查服务:

    docker ps -a
    

    查日志:

    cd /var/log/kolla
    

    改配置:

    cd /etc/kolla/<service_name>
    

    重启服务:

    docker restart <container_name>
    

    只需要记住这几个常用的操作命令就可以了,相较于之前需要记忆每个服务不同的名字,是不是方便了很多呢?


    更详细的操作过程可以去 B站看视频

    如果看完本文对你有帮助,请 关注点赞分享 来一波。

    谢谢!

  • 相关阅读:
    vim常用命令
    转:CRF++总结1
    转:CRF++总结2
    并查集算法程序
    CRF++使用小结(转)
    并查集算法程序
    C#winform 画图
    转:字符识别
    转:A Survey On Relation Extraction
    转:生产计划问题
  • 原文地址:https://www.cnblogs.com/davyyy/p/12175611.html
Copyright © 2020-2023  润新知