1. 程式人生 > >Kolla 讓 OpenStack 部署更貼心

Kolla 讓 OpenStack 部署更貼心

目錄

Kolla 簡介

長久以來 OpenStack 部署難、 升級難的問題經常為人詬病,簡單高效的部署升級方案是所有 OpenStack 使用者(雲服務供應商、客戶、開發者)的共性剛需。Kolla 專案正是應需而生,它基於社群的最佳實踐,提出了可靠、可擴充套件的生產級別 OpenStack Service Containers 部署方案。

簡而言之,Kolla 就是一個充分運用容器特性,實現容器化部署 OpenStack 服務的 DevOps 工具

眾所周知,容器技術具有非常優秀的應用部署敏捷性和擴充套件性,其中又以 Docker 和 Kubernetes 作為構建容器化應用程式的主要標準,是最受歡迎的容器技術選型。為了適配多樣的應用場景,社群將 Kolla 專案解耦成為了三個元件。由 Kolla 繼續負責構建容器映象,由 Kolla-ansible/Kolla-kubernetes 負責容器的自動化部署與管理。三者間既互相配合又自成一家,鬆耦合的架構更有利於覆蓋使用者多方面的需求。

  • Kolla:容器映象構建
  • Kolla-ansible:容器部署
  • Kolla-kubernetes:容器部署與管理

Kolla 顯著的特點是「開箱即用」「簡易升級」,前者由編排工具提供自動化支撐,後者則完全是容器技術的功勞。Kolla 追求為每一個 OpenStack Service 都構建容器映象,將升級/回滾的粒度(隔離依賴關係集)降維到 Service 級別,實現了操作原子性。版本升級只需三步:

  1. Pull New Docker Image
  2. Stop Old Docker Container
  3. Start New Docker Container

即使升級失敗,也能夠立即 Start Old Docker Container 完成回滾。

從最新的 Kolla Queens Release 可以看出,Kolla 為實現「從升級到零宕機升級」的目標作出了努力,現已支援 Cinder 和 Keystone 專案的最小宕機時間升級,並不斷擴充套件至其他專案。

筆者認為,零宕機升級功能的釋出對 Kolla 而言具有里程碑式的意義,以往,Kolla 提供的升級服務因為具有時延性,所以並未真正觸碰到使用者的痛點,只能算是解決了使用者的癢點需求(在部署和升級上提供了便利)。如何在生產環境實現基礎設施管理平臺升級的同時保障使用者業務負載的連續性和可用性,才是使用者最深切的痛點。這樣有助於加深使用者和 OpenStack 社群的粘合度,緊隨社群發展,並不斷引入新的功能來壯大自身。現在的 Kolla 或許離實現這一目標已經不遠了。

除此之外,Kolla-ansible 還發布了支援「開發者模式」,這是一個值得 OpenStack 開發者們高興的訊息。

支援開發模式。這個對 OpenStack 的開發者很是方便。以住,開發者可能要通過 devstack 搭建完整的 OpenStack 來開發,但是部署複雜,難度高。現在 kolla-ansible 已經支援了開發模式。通過配置要開發環境的 dev_mode, 如 horizon_dev_mode: true, 那麼 horizon 容器內的程式碼會從物理機上掛載進去,開發者對程式碼修改後,就可以直接看到修改後的效果。十分方便。

from:
99Cloud 張雷(Kolla PTL)

在下面的內容中,我們以 Kolla & Kolla-ansible 的組合,主要分 3 步介紹如何輕鬆部署出一套 OpenStack 環境。

  1. 環境依賴準備
  2. 使用 Kolla 構建映象
  3. 使用 Kolla-ansible 部署 OpenStack

Kolla & Kolla-ansible 部署 OpenStack

部署環境

  • 平臺:VMware Workstations
  • 作業系統:CentOS 74,4C/8G
  • 雙網絡卡
    • Host 模式:eth0 192.168.1.13/24
    • Bridge 模式:eth1 DHCP
  • Kolla branch queens(6.0.0)
  • Kolla-ansible branch queens
  • OpenStack Queens

須知

  1. 建議最小化安裝 CentOS 7.4,並以 root 使用者完成所有操作
  2. 建議科學上網,因為有些包沒有國內映象
  3. 建議使用 eth0 進行 ssh 和訪問外網,因為 eth1 用作 External Network,被放到 network namespace qrouter-XXX 之後,網路連線會斷開
  4. 本文面向 Kolla 入門,採用 For development & All-In-One 部署方式
  5. Troubleshooting List 位於文末

準備作業系統基礎環境

安裝系統基礎環境依賴包

yum install epel-release -y
yum update -y
yum install python-pip python-devel libffi-devel gcc openssl-devel libselinux-python vim git wget -y

慣例開啟 NTP 時間同步服務

systemctl enable ntpd.service && systemctl start ntpd.service && systemctl status ntpd.service

慣例關閉防火牆服務

systemctl stop firewalld && systemctl disable firewalld && systemctl status firewalld

慣例禁用宿主機的 Libvirt 服務:大多數作業系統會預設啟動 Libvirt,但使用 Kolla 來部署 OpenStack 的話,Libvirt 應該在容器中執行並管理虛擬機器。所以宿主機的 Libvirt 需要被關閉,以免造成衝突。

systemctl stop libvirtd.service && systemctl disable libvirtd.service && systemctl status libvirtd.service

Tips:建議此處打上快照

準備 Python 基礎環境

安裝基礎依賴包

pip install -U pip
pip install -U ansible
pip install -U tox
pip install -U python-openstackclient
pip install -U docker
pip install -U jinja2

Tips:下列軟體包是版本問題的高發區,不妨提前檢視一番。

  • docker>=2.0
  • jinja 2>=2.10
  • ansible>= 2.0
  • 確保沒有安裝 docker-py

ps:較新的版本中使用 docker 庫代替 docker-py

修改 ansible 配置檔案

mkdir /etc/ansible
vim /etc/ansible/ansible.cfg
[defaults]
host_key_checking=False
pipelining=True
forks=100
deprecation_warnings=False

準備 Docker 基礎環境

安裝 Docker

curl -sSL https://get.docker.io | bash

開啟 Docker 的共享掛載功能:所謂共享掛載即同一個目錄或裝置可以掛載到多個不同的路徑並且能夠保持互相之間的共享可見性,類似於 mount --shared。在 OpenStack for Kolla 中,主要解決 Neutron 的 namespace 在不同 container 中得以保持實效性的問題。

mkdir /etc/systemd/system/docker.service.d
tee /etc/systemd/system/docker.service.d/kolla.conf << 'EOF'
[Service]
MountFlags=shared
EOF

啟動 Docker 服務

systemctl daemon-reload && systemctl enable docker && systemctl restart docker

安裝 kolla & kolla-ansible

Tips:這裡使用兩個沙盒環境進行原始碼安裝,所以建議在不同的終端內操作,避免混亂。

安裝 Kolla

  • 建立沙盒環境
virtualenv kolla_env
source kolla_env/bin/activate
  • 原始碼安裝
git clone https://github.com/openstack/kolla -b stable/queens
cd kolla
pip install -r requirements.txt -r test-requirements.txt -e .
  • 生成配置檔案
tox -egenconfig
mkdir /etc/kolla/
cp etc/kolla/kolla-build.conf /etc/kolla/

編輯 kolla-build.conf:控制 Kolla Image Build 的細則。

vim /etc/kolla/kolla-build.conf

[DEFAULT]
base = centos
install_type = source
namespace = kolla
push = false
# The Docker Images tag (string value)
tag = 6.0.0
  • base:使用 CentOS 做為 Base 映象
  • install_type:使用原始碼方式部署
  • tag:指定構建映象的 Tag 為 6.0.0(Kolla Queue 的版本號)

安裝 Kolla-ansible

  • 建立沙盒環境
virtualenv kolla-ansible_env
source kolla-ansible_env/bin/activate
  • 原始碼安裝
git clone https://github.com/openstack/kolla-ansible -b stable/queens
cd kolla-ansible
pip install -r requirements.txt -r test-requirements.txt -e .
  • 生成配置檔案
cp etc/kolla/globals.yml /etc/kolla/
cp etc/kolla/passwords.yml /etc/kolla/

編輯 passwords.yml:設定 OpenStack 服務的各種密碼,這裡僅設定管理員的登陸密碼。

vim /etc/kolla/passwords.yml

keystone_admin_password: fanguiju

編輯 globals.yml:這是最重要的配置檔案,用於控制 Kolla-ansible Deploy 的細則。

vim /etc/kolla/globals.yml

kolla_dev_mode: "yes"
network_interface: "eth0"
neutron_external_interface: "eth1"
kolla_internal_vip_address: "192.168.1.15"
kolla_base_distro: "centos"
kolla_install_type: "source"
docker_registry: ""
docker_namespace: "kolla"
openstack_logging_debug: "True"
enable_cinder: "no"
enable_heat: "no"
# Valid option is Docker repository tag
openstack_release: "6.0.0"
  • kolla_dev_mode: "yes":啟用開發者模式
  • openstack_release:需要與映象的 Tag 一致,否則部署時找不到映象。
  • network_interface:指定管理網介面
  • neutron_external_interface:指定外部網介面
  • kolla_internal_vip_address:指定 HAProxy 虛擬 IP,單點部署可以棄用 HAProxy enable_haproxy: "no"

NOTE:globals.yml 檔案的配置項,實際上大多是 Ansible 的自定義變數,可用於靈活配置 Playbook 的行為。

修改 Hypervisor Type:因為操作環境是 VMware 的虛擬機器,所以存在巢狀虛擬化不支援 KVM 的問題,如果你希望啟動 OpenStack 例項,那就需要啟用 QEMU(Default KVM)。

mkdir -p /etc/kolla/config/nova
cat << EOF > /etc/kolla/config/nova/nova-compute.conf
[libvirt]
virt_type=qemu
cpu_mode = none
EOF

Kolla Build Images

簡單的來理解 Kolla 元件的話,它就是一個自動化構建部署 OpenStack 服務所需要的映象的工具。其內含組織了大量的 Dockerfile,供構建映象時使用。

實際上,就單純的部署開發測試環境而言,是允許不使用 Kolla 元件的。Kolla-ansible 自身也實現了檢測和構建映象的策略。如果 Deploy 時,檢測到映象沒有 Ready,Kolla-ansible 就會從遠端倉庫 Pull 下來映象,然後再執行 Deploy。

不是這種方式的部署速度是比較慢的,而且 Pull 下來的映象也未必會包含有最新的 Commit,就更別提定製化映象需求了。所以,這裡還是建議使用 Kolla 在本地構建映象,甚至是搭建 Local Registry(本地容器倉庫)。
更多的 Building Container Images 詳情,請瀏覽:
https://docs.openstack.org/kolla/latest/admin/index.html#building-container-images

cd kolla/tools
./build.py -p default
  • 引數項 -p default 對應 kolla-build.conf 的 [profiles] Sections,default 型別表示僅構建核心專案的映象。
[profiles]

# From kolla
...

# Default images (list value)
default = chrony,cron,kolla-toolbox,fluentd,glance,haproxy,heat,horizon,keepalived,keystone,mariadb,memcached,neutron,nova-,openvswitch,rabbitmq

接下來有一段較長的映象構建時間,如果出現異常中斷,可重複執行。賴於 Docker 的 Build Cache 功能,能為重跑追回不少時間。

NOTE:但有些情況下,可能會把錯誤的配置引數 Cache 住,此時建議執行 Cleanup 操作之後再重跑:

# 從系統中移除部署的容器
tools/cleanup-containers

# 移除由於殘餘網路變化引發 docker 啟動的 neutron-agents 主機
tools/cleanup-host

# 從 Cache 中移除所有的 docker image
tools/cleanup-images

Build Successfully
這裡寫圖片描述

檢視映象列表
這裡寫圖片描述

從上圖可見,Kolla 構建的映象一般有四層,Docker 的映象分層結構更有利於抽象環境依賴集,降低依賴包重複率,提高映象傳輸率。有幾分 “程式碼複用” 的意味。

這裡寫圖片描述

  • base image:提供一個最基本的作業系統環境,幾乎是所有映象的基礎。
  • openstack-base image:所有 OpenStack 服務映象的基礎,安裝了 Service 層級的依賴集。
  • <project>-base image:某個專案的基礎,安裝了 Project 層級的依賴集。
  • <service> image:一個具體 Service 的特異依賴集,設定了服務啟動入口。

Kolla 中的 Dockerfile 檔案,是使用 Jinja2 語法來編寫的。使其具備 Jinja2 Template 的特性,更便於渲染變數。如果你有個性化的定製需求,可以通過修改相應的 Dockerfile.j2 實現。e.g.

vim /root/kolla/docker/nova/nova-api/Dockerfile.j2

Kolla-ansible Deploy OpenStack

可以把 Kolla-ansible 看作是 Kolla 對 Ansible 的封裝,實現了大量的 Play 和自定義模組。

Kolla-ansible 同樣通過提供一個完整的 Playbook 來實現指令碼自動化,在原始碼目錄 inventory 下還提供了 all-in-one 和 multihost 兩種主機清單。單點部署的話,一般不需要多做修改,直接使用 all-in-one 清單是個不錯的選擇。但如果你希望進行多節點部署,可以通過修改 multihost 清單中的主機分組來達到定製化分散式部署架構的目的。

Tips:多節點部署時,需要保證管理節點和各主機之間能夠使用 SSH 免密登陸。

cd kolla-ansible/
cp ansible/inventory/* ~

$ ll ~
-rw-r--r--   1 root root 8292 May 28 09:43 all-in-one
-rw-r--r--   1 root root 8766 May 28 09:43 multinode

在正式 Deploy 之前,還需要進行一些準備工作

Step 1. 自動生成隨機密碼來填充 passwords.yml 專案

kolla-genpwd

Step 2. 處理 bootstrap servers 所需要的依賴

cd kolla-ansible/tools
./kolla-ansible -i ~/all-in-one bootstrap-servers

Step 3. 部署環境預檢查

./kolla-ansible -i ~/all-in-one prechecks

Tips:做 prechecks 前需要完成 kolla-genpwd

正式開始 Deploy

./kolla-ansible -i ~/all-in-one deploy
  • 選項 -i 指定主機清單,這和 Ansible 的用法是一致的。

成功 Deploy 之後,檢視 Containers 狀態
這裡寫圖片描述

Tips:Horizon 通常是最後部署的一個。

NOTE

  1. 從上圖可見,Service Container 使用了 kolla_start 指令碼來啟動
  2. 因為 Kolla 預設使用的是 --net=host 網路,所以沒有必要做埠對映

檢驗 & 使用

生成 admin-openrc.sh 檔案:用於匯入 Keystone Auth 環境變數

./kolla-ansible post-deploy
ll /etc/kolla/admin-openrc.sh

初始化執行環境:會自動執行下列操作

  • Creating glance image.
  • Configuring neutron.
  • Generating ssh key.
  • Configuring nova public key and quotas.

NOTE:如果你希望 External Network 正常執行,還需要編輯 init-runonce 初始化指令碼中的網路配置,設定為 eth1 的網路元素。

# e.g. eth1 IP:172.16.0.10/24
# This EXT_NET_CIDR is your public network,that you want to connect to the internet via.
EXT_NET_CIDR='172.16.0.0/24'
EXT_NET_RANGE='start=172.16.0.100,end=172.16.0.200'
EXT_NET_GATEWAY='172.16.0.1'

這樣,Instance Floating IP 才能夠利用名稱空間 qrouter-XXXX 中的 iptables 進行 NAT 轉發,訪問外網。

source /etc/kolla/admin-openrc.sh
./init-runonce

啟動例項,驗證環境

openstack server create \
    --image cirros \
    --flavor m1.tiny \
    --key-name mykey \
    --network demo-net \
    demo1

這裡寫圖片描述

NOTE:如果你希望徹底清理完部署好的環境,只需執行下列指令。

kolla-ansible destroy -i all-in-one --yes-i-really-really-mean-it

最後

OpenStack 和容器的緊密聯絡已經成為了不可逆轉的趨勢。不誇張的說,擁抱容器,是 OpenStack 社群的求生之路。現在我們常見的 OpenStack 與容器的結合方式不外乎下列 3 種形式:

  • OpenStack On Container
  • Container On OpenStack
  • OpenStack & Container

Kolla 服務於其中的 OpenStack On Container。容器化的 OpenStack 允許使用者以快速、可靠甚至是無感的方式進行部署、升級、擴充套件,讓 OpenStack 的自動化整合與交付變得簡單。

這些優勢對於使用者而言,具有非常可觀的利好,因為在降低了雲基礎設施運維成本的同時,還能夠讓服務架構具有高度的靈活度。尤其是在 kubernetes 上部署 OpenStack,背靠 kubernetes 的自修復、快釋出特性,簡直相得益彰,為上層應用服務提供了優秀的彈性支撐。

現在已經有行業使用者交出了「用 Kolla 48 小時完成 300 個節點混合儲存與多網路區域的部署實踐」的優秀實踐案例。這要放到 Kolla 出現之前是令人感到不可思議的事情。從這個角度來看,Kolla 已經成為了 OpenStack 產品化的重要一環,它令 OpenStack 的落地實施變得簡單,為使用者帶來一次優秀的閉環體驗。

最後,筆者認為,Kolla 最終的使命或許是成為 OpenStack On Container 的一站式解決方案。實在是令人期待!

參考文件

Troubleshooting List

ERROR 1

Cannot uninstall 'requests'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

TS 1:因為 requests 包被系統環境依賴,不能解除安裝,也不需要解除安裝,跳過即可。

pip install -U python-openstackclient python-neutronclient  --ignore-installed requests

ERROR 2

https://packagecloud.io/grafana/stable/el/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 302 - Found

TS 2:網路不可達,請科學上網或隨緣安裝。

ERROR 3

TASK [neutron : Checking tenant network types] ****************************************************************************************fatal: [controller]: FAILED! => {"msg": "The conditional check 'item not in type_drivers' failed. The error was: An unhandled exception occurred while templating '{{ neutron_type_drivers.replace(' ', '').split(',') | reject('equalto', '') | list }}'. Error was a <class 'jinja2.exceptions.TemplateRuntimeError'>, original message: no test named 'equalto'\n\nThe error appears to have been in '/root/venv/share/kolla-ansible/ansible/roles/neutron/tasks/precheck.yml': line 41, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Checking tenant network types\n ^ here\n”}

TS 3:Jinja2 版本過低不支援 reject,需要高於 2.8。

ERROR 4:Deploy 過程中重複 Build 映象
這裡寫圖片描述
TS 4:kolla 和 kolla-ansible 指定的 Docker Image Tag 不一致。

映象分層示意圖

這裡寫圖片描述