使用 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
可以看到每個服務都對應到一個容器。比如 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 的大致處理流程是這樣的：
- 把這個目錄掛載到容器的
/var/lib/kolla/config_files目錄 - 在容器的啟動腳本中加了處理配置的腳本：
kolla_set_configs 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站看視頻
如果看完本文對你有幫助，請 關注、點贊、 分享 來一波。
謝謝！