Not just install, Kolla make OpenStack operation and maintenance becomes simple

OpenStack kolla deployed using conventional direct installation environment and the environment in comparison, since the full deployment of the container, the basic operation is quite different. For starters, the operation becomes clearer and simpler, but if you already have some experience, but will probably not used to.

This article on the "Create an instance of" the most simple tasks take you to master the most basic and common operations.

Outline

In the last article , we set up the environment to complete, after logging ends. Today's task is to verify the availability of preliminary environment, the most direct way than to create a virtual machine.

This is not a zero-based OpenStack course, the following assumes that the reader has some basic experience.

Ready to work

First, in order to be able to start a virtual machine, at least need to complete the following preparations:

• New Mirror
• New Specification
• New Network

These actions will be in dashboarda complete, it does not involve the background, and other environments are no different.

New Mirror

First, download a mini Linux system image designed to test, CirrOSto enter download page selection of the latest 0.4.0version:

For different CPU architectures and usage scenarios, there are different image formats:

Click Download the latest 64-bit version cirros-0.4.0-x86_64-disk.img , image file formatqcow2

qcow2Is mirrored format, sometimes saved as a .imgsuffix, you can filecommand.

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

New Specification

Because the All-In-One environment, we deploy the virtual machine in VirtualBox itself is not much resources are available, the CirrOSsystem does not need a lot of memory, we will create a mini-specifications,

• 1 vCPU
• 512 MB of RAM
• 1 GB storage

To meet the test.

New Network

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

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

新建实例

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

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

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

检查服务状态

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

$ systemctl status openstack-nova-api

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

$ sudo docker ps

可以看到每个服务都对应到一个容器。比如 nova 有几个子服务，nova-api，nova-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

从错误提示可以看到，是因为 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>

Just remember these common operations command on it, you need to remember different names for each service compared to before, it is not convenient for a lot of it?

---

More detailed operation of the process can go to the B station to see the video

If after reading this article help you, please attention , thumbs up , share to wave.

Thank you!