准备工作

系统:Centos7

服务器:两台 物理机

配置:内存:188GB | 硬盘: 19T  | CPU: 39 core

部署步骤:

  • 环境准备:

更改主机名,此处有个坑,之前装时设置的域名是:openstack-master1-iuap-idc-yycloud.yonyouiuap.com, 结果导致rabbitmq服务启不来,网上查的是有两个原因,  一个可能是端口被占用, 另一个是主机名设置的问题, 此处设置为短名, openstack1和openstack2:

网络配置:

网卡一, 用于openstack自身容器服务及VIP对外服务:

网卡二, 用于在openstack上跑的云主机对外访问和远程访问云主机, 不用配置IP地址:

 

安装NTP服务

CentOS系统

在所有节点配置hosts文件:

 

在所有节点配置ssh密钥互通:

安装docker基础配置:

拷贝配置文件

生成密码

下载build好的镜像,建立私有仓库,这里,下载使用Kolla社区的pike版本镜像(免去在本地环境docker build的过程,大大加快安装时间)。Ocata版本是4.0.3, pike版本是5.0.1, 事实证明Ocata版本有Bug, 装完后会导致centos-source-cinder-api和centos-source-fluentd两个容器启动失败。

如果是在虚拟机里装kolla,希望可以虚拟机中再启动云主机,那么你需要把virt_type=qemu

配置Kolla

下面是我的配置,此处要注意,kolla_internal_vip_address是配置的没有使用的IP,如果配置的IP已经被使用的话会报错 :

定义节点cat multinode:

准备ceph磁盘

在2台虚拟机的节点上,除去系统盘还有有其它2块硬盘,sdb、sdc
这里我们将sdb做为osd节点,sdc为日志节点。Kolla对ceph的osd及日志盘的识别是通过卷标来实现的,
如osd的卷标为KOLLA_CEPH_OSD_BOOTSTRAP,
journal的卷标为KOLLA_CEPH_OSD_BOOTSTRAP_J

因为有三块盘,分别是sda, sdb, sdc,sda是系统盘, sdb做osd盘, sdc做journal盘

格式化所有osd的磁盘,这里我们用ansible统一执行,

格式所有journal的盘

下面是我用的初始化ceph磁盘的脚本,(openstack1和openstack2有两块磁盘, 分别是sdb和sdc(SSD),  其它3台openstack[3-5]分别有6块sata盘, 一块SSD盘):

 

 

新建/etc/kolla/config/ceph.conf,指定ceph的一些参数,如副本数:
[root@openstack1 lokolla]# cat /etc/kolla/config/ceph.conf
[global]
osd pool default size = 3
osd pool default min size = 2

开始安装

kolla自动检查配置基础环境:

 

  • 验证目标节点是否满足部署要求:

没有报错直接进行安装:

生成环境变量文件

  • 生成的脚本的路径:/etc/kolla/admin-openrc.sh

文件路径为
/etc/kolla/admin-openrc.sh

cp /etc/kolla/admin-openrc.sh /root/

source /root/admin-openrc.sh

安装OpenStackClient

 生成网络, 利用自动生成脚本(一个测试脚本,自动下载镜像,上传,创建网络,创建路由器……):

 

Error处理:

1. Docker Py

  • 问题:Error: 'module' object has no attribute 'Client'
  • 解决方法: Docker-Py版本的问题, 从2.0版本开始由Client更新为APIClient

部署技巧:

1)如果,在部署过程中失败了,亦或是变更了配置信息,需要重新部署,则先执行如下命令,清除掉已部署的Docker容器,即OpenStack服务。

2)除此外,还有一些小工具,在自己需要时,可以使用。

  • kolla-ansible prechecks:在执行部署命令之前,先检查环境是否正确;
  • tools/cleanup-containers:可用于从系统中移除部署的容器;
  • tools/cleanup-host:可用于移除由于网络变化引发的Docker启动的neutron-agents主机;
  • tools/cleanup-images:可用于从本地缓存中移除所有的docker image。

最后,可以使用docker ps –a命令查看到OpenStack 所有服务的容器。

2. No valid host was found. there are not enough hosts available.

创建虚机时报上面的错, 查看Log(nova-placement-api.log),log目录在宿主机/var/lib/docker/volumes/kolla_logs/_data/:

: libvirtError: internal error: qemu unexpectedly closed the monitor: 2017-11-10T14:18:30.341372Z qemu-kvm: -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/80f7f03e-7b9c-47aa-912f-08279c92d41e/console.log,logappend=off: Unable to open logfile /var/lib/nova/instances/80f7f03e-7b9c-47aa-912f-08279c92d41e/console.log: Permission denied

参考这篇文章: https://computingforgeeks.com/permission-denied-while-starting-instance-in-openstack/

配置文件中增加以下内容:

重启centos-source-nova-libvirt容器, 问题解决.

 

1. 用kolla安装openstack的N版,如果多节点部署,而且lbaas enble,则出现neutron_server一直是Restarting的状态,
看日志的报错是:ImportError: Plugin ‘neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2’ not found
解决思路:创建的neutorn-server的没有neutron-lbaas代码,neutron-base镜像里面应该也没有neutron-lbaas代码,
解决方法:
pass

2. 进入horizon后不能使用yum,运行yum的任何命令都卡死
解决思路:
yum也是用python写的,自己调试也比较得心应手,所以先调试了一会,发现是不能读取配置,在网上查询说可能是数据库连接不到,
重建数据库就好
解决方法:
rm -rf /var/lib/rpm/__db.00*

rpm -rebuilddb

3. 如果修改kolla部署的docker容器里面的配置文件,如horizon.conf,重启docker后文件还会变回原来的
解决思路:
应该是重启docker容器会从指定位置拷贝配置文件
解决方法:
docker重启会从/etc/kolla重新拷贝,如horizon容器,需要去宿主机的/etc/kolla/horizon里面修改,此目录下有三个文件config.json  horizon.conf  local_settings,其中config.json会指定重启docker都拷贝哪些文件

4.precheck时报错:

ERROR! Unexpected Exception, this is probably a bug: {{ neutron_tenant_network_types.replace(‘ ‘, ”).split(‘,’) | reject(‘equalto’, ”) | list }}: no test named ‘equalto’

分析:是jinja2版本的低问题,如下是版本信息:

解决,升级jinja2版本:

 错误:No module named ‘requests.packages.urllib3

解决方法:参考http://www.niuhp.com/,

经查阅各种资料发现主要是 requests 和 urllib3 的问题,而 requests 的版本需要为 2.6.0,因此我们需要按照如下方式安装

 

错误: TASK [ceph : Fetching Ceph keyrings] *******************************************
fatal: [controller01]: FAILED! => {“failed”: true, “msg”: “The conditional check ‘{{ (ceph_files_json.stdout | from_json).changed }}’ failed. The error was: No JSON object could be decoded”

参考:http://wangyaohua.cn/wordpress/?p=805

原因如下:
在我删除容器和镜像,并且清除了相关硬盘后,kolla生成的相关volume是没有删除的。其还存在于/var/lib/docker/volume下,而我之后的kolla-ansible destroy 会删除相关的容器,并根据删除的容器删除相关的卷。但是这些容器已经被我提前删完了,所以这volume是没有删除的。因此当再次构建kolla时,这些已经存在的volume会阻止ceph_mon的启动,会导致上述错误Ceph keyring无法获取而产生的一些错误。因此 删除掉docker volume ls下的卷。再次部署就能够成功的解决问题

删除卷:

docker volume rm $(docker volume ls -f dangling=true -q)

rabbitmq集群报错:

解决:

修改用户数限制:

 

报错:

解决:原因是docker新版本检查version时用docker –version, 而用docker version会输出过多内容。参考https://bugs.launchpad.net/kolla-ansible/+bug/1742869

vim /usr/share/kolla-ansible/ansible/roles/prechecks/tasks/service_checks.yml

将以下内容替换之:

 

错误:

kolla-ansible部署openstack时出现Waiting for virtual IP to appear的报错:

TASK [haproxy : Waiting for virtual IP to appear] ***********************************************************************
fatal: [vm1]: FAILED! => {“changed”: false, “elapsed”: 301, “failed”: true, “msg”: “Timeout when waiting for 172.168.215.111:3306”}

解决方法:

如果有多个keepalived集群运行在相同的2层网络,编辑 /etc/kolla/globals.yml 然后重新设置 keepalived_virtual_router_id的值.   keepalived_virtual_router_id 的范围应该在 0 到 255之间并且是唯一的.

 

虚拟机中测试kolla

需要注意的是如果是在虚拟机中测试kolla需要在宿主机上修改nova-compute的配置文件 为virt_type=qemu不然默认用的是kvm,会造成创建云主机失败。
vim /etc/kolla/nova-compute/nova.conf
新建/etc/kolla/config/nova.conf
[libvirt]
virt_type=qemu

重启这个容器。
docker restart nova_compute

openstack 服务配置的修改
# kolla-ansible -i multinode reconfigure
最终命令执行完,配置修改完毕。

注意。ESXi的虚拟机端口组要把混杂模式和伪传输打开,不然后br-ex的网络出不去

 

修改创建虚机时自动生成的novalocal的主机名为自定义主机名:

编辑/etc/kolla/nova-api/nova.conf, 在[DEFAULT]下添加:

dhcp_domain = yonyouiuap.com

重启nova-api服务

 

修改resolv.conf的默认search域:

编辑/etc/kolla/neutron-dhcp-agent/neutron.conf, 在[DEFAULT]下添加:

dns_domain = yonyouiuap.com.

重启所有centos-source-neutron-dhcp-agent服务

====2018.11.22日更新: 另一篇文章:

https://www.hanbert.cn/2017/10/03/Kolla%E5%A4%9A%E8%8A%82%E7%82%B9%E7%89%A9%E7%90%86%E6%9C%BA%E9%83%A8%E7%BD%B2OpenStack/

Kolla多节点物理机部署OpenStack

2014年下半年,OpenStack基金会已经意识到Docker对OpenStack可能造成的威胁,研究OpenStack和Docker如何并存迫在眉睫,在2015年的温哥华峰会上,推出了3个项目:

  • kolla:把OpenStack放到容器里面,部署OpenStack
  • Magnum: 在OpenStack平台上面部署容器,后来改成COE(Container Orchestration Engine)
  • Solum:利用Docker来实现CI(Continuous Integration)/CD(Continuous Delivery)

这就是当初基金会的设想,只不过经过2年的发展,目前就Kolla项目是最靠谱的。Magnum修改了自己的方向,并且带来的价值不大。Solum已经基本快要死掉了。

目前依据OpenStack的传统,Kolla项目被拆分成了三个项目:

  • Kolla:主要负责OpenStack各个组件Docker镜像的制作
  • Kolla-Ansible:负责容器的管理配置,即OpenStack的部署,以Ansible作为编排引擎
  • Kolla-Kubernetes:和上面功能一样,只不过是以Kubernetes作为编排引擎

Kolla项目自诞生以来,短短一年内投入生产环境,真正放到生产环境是在Mitaka版本。又经过了一年的完善,终于在Ocata版本,做到了一个很完善的地步。

Kolla的优势和使用场景,体现在如下几个方面:

  • 原子性的升级或者回退OpenStack部署;
  • 基于组件升级OpenStack;
  • 基于组件回退OpenStack;

Kolla的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image,通过Docker Image将升级的粒度减小到Service级别,从而使升级时,对OpenStack影响能达到最小,并且一旦升级失败,也很容易回滚。升级只需要三步:Pull新版本的容器镜像,停止老版本的容器服务,然后启动新版本容器。回滚也不需要重新安装包了,直接启动老版本容器服务就行,非常方便。

Kolla使用到的技术如下:

  • Docker
  • Ansible
  • Python
  • Docker-py
  • Jinja2

Note:
很多对Docker不熟悉人,以为把OpenStack放到Docker里,虚拟机也是跑在Docker里。其实这是误解。Kolla仅仅是把OpenStack各个服务的进程,放到Docker里而已。以前的vm怎么运行,现在还是怎么运行,没做任何的改变。

一、Kolla部署OpenStack的架构

如下图所看到,通过Kolla部署OpenStack能够实现,全组件HA(High Available),其中,像其他OpenStack部署项目一样,对于MySQL的HA方案,默认采用的均是Galera。

kolla-ansible/specs/ha.svg

二、前期准备

目前Kolla能够在Ubuntu和Centos两种Linux发行版上部署OpenStack,本次部署使用Centos7,OpenStack组件Nova,Cinder,Swift后端存储使用Ceph,Glance理论上后端存储也可以采用Ceph,但是采用Ceph作为后端存储的话,Glance的镜像格式必须是raw,目前主流镜像格式imgqcow2都需要转换为raw格式才能够正常使用,但是raw镜像不支持快照。可以自行搜索这些镜像格式之间的区别。具体基础环境要求如下:

  • 物理机最小配置:8 GB 内存,40 GB 存储
  • Centos7 操作系统,最小化安装,最好根据自己规划,在安装过程中及时更改主机名
  • 最少2块网卡,此处部署使用3块,其中一个网卡是万兆网卡
  • 数据盘与系统盘分离,至少1块数据盘,理想状态3块数据盘
  • 至少保证部署机有root登陆权限,其余节点可以视情况而定

Reference:

三、网络环境准备

本次部署,使用一台单独的48口交换机,因为采用了三个网卡,故在交换机上划分出了三个网段:

  • Admin Network:部署过程中各节点通信,部署完成后OpenStack各组件间通信,能够连接互联网
  • Public Network:给OpenStack平台上的VM提供Floating IP以使其能够正常远程SSH和连接网络,能够连接互联网
  • Storage Network:Ceph节点间通信和数据传输的网段,内网网段,与互联网隔离

本次部署三个网卡与三个网段的对应的情况如下:

  • em1:连接到Admin Network,提前在网卡上配置好IP地址,确保能够远程SSH,且能够连接互联网
  • em2:连接到Pubic Network,只需要把网上连接到相应Port上,网卡状态为UP即可,不需要配置IP
  • p5p2:连接到 Storage Network,万兆网卡,需要提前配置一个内网地址段IP确保各个节点间能通信

Note:

  • Public Network需要提前划分出一个地址段,预留足够的IP地址给OpenStack的VM使用
  • em2网卡一定不要配置IP地址
  • p5p2网卡不要配置GateWay,否则可能会与em1网卡的Gateway冲突,导致该主机不能够正常联网

四、部署规划

本次部署共12个节点,其中3个controller节点,分别命名为:controller1,controller2,controller3;9个compute节点,分别命名为:compute1~9;其中一台controller节点还承担Kolla部署机角色,具体角色划分如下:

  • Kolla部署机:controller1
  • OpenStack镜像本地源服务器:controller1
  • 3台controller节点:controller1~3
  • 9台compte节点:compute1~9
  • Ceph的OSD节点:controller1~3,compute1~9的所有的数据盘

五、配置免密登陆

这一过程不是必须的,但是为了方便操作,最好在各个节点之间实现免密登陆,以下过程在所有的节点上执行:

① 生成秘钥对,输入以下命令,然后一路回车:

1
[root@controller1 ~]# ssh-keygen -t rsa

② 将所有的公钥复制到authorized_keys文件中:

1
2
[root@controller1 ~]# cd ~/.ssh/
[root@controller1 ~]# vim authorized_keys

搜集每个节点上的id_rsa.pub文件内容,添加到authorized_keys文件中,然后保存退出。

③ 同样的过程,在剩余所有节点上执行一遍,然后修改hosts文件:

1
[root@controller1 ~]# vim /etc/hosts

输入每个主机的IP 主机名,然后退出保存。

④ 验证是否成功:

1
[root@controller1 ~]# ssh controller2

六、安装依赖包

以下过程在所有节点上都:

安装epel-releasepipgit

1
[root@controller1 ~]# yum install -y epel-release python-pip git

如果安装过程特别慢,可以考虑更换软件源,以下是Centos7更换阿里云源的方法:

1
2
3
4
cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
或者:
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

升级pip到最新版:

1
[root@controller1 ~]# pip install -U pip

如果pip下载包也比较慢,可以更换pip的源为豆瓣源或者阿里云源,以下以更换为阿里云源为例:

1
2
3
4
5
6
7
[root@controller1 ~]# mkdir -p ~/.pip
[root@controller1 ~]# vim ~/.pip/pip.conf
// 添加以下内容:
[global]
index-url = http://mirrors.aliyun.com/pypi/simple/
[install]
trusted-host=mirrors.aliyun.com

安装其他的一些依赖:

1
[root@controller1 ~]# yum install python-devel libffi-devel gcc openssl-devel libselinux-python

OpenStackRabbitMQCeph等都对节点间的时间差有一定的要求,如果时间差过大,可能导致服务不能够正常运行,为此,我们最好能够安装NTP服务,让每个节点自动进行时间同步:

1
2
3
[root@controller1 ~]# yum install ntp
[root@controller1 ~]# systemctl enable ntpd.service
[root@controller1 ~]# systemctl start ntpd.service

安装ansible,并升级到最新版:

1
2
[root@controller1 ~]# yum install ansible
[root@controller1 ~]# pip install -U ansible

停止libvirt组件,否则后面安装会失败:

1
2
[root@controller1 ~]# systemctl stop libvirtd.service
[root@controller1 ~]# systemctl disable libvirtd.service

安装最新版Docker,升级到最新版,然后检查Docker的版本:

1
2
3
[root@controller1 ~]# curl -sSL https://get.docker.io | bash
[root@controller1 ~]# pip install -U docker
[root@controller1 ~]# docker –version

如果由于网络原因,以上安装方法Docker不能够成功安装,可以使用下面的方法进行安装:

1
2
3
4
5
6
7
8
9
10
11
12
13
// 设置repo
[root@controller1 ~]# tee /etc/yum.repos.d/docker.repo << ‘EOF’
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF
// 安装Docker
[root@controller1 ~]# yum install docker-engine docker-engine-selinux
[root@controller1 ~]# pip install -U docker
[root@controller1 ~]# docker –version

Docker进行配置:

1
2
3
4
5
[root@controller1 ~]# mkdir /etc/systemd/system/docker.service.d
[root@controller1 ~]# tee /etc/systemd/system/docker.service.d/kolla.conf <<-‘EOF’
[Service]
MountFlags=shared
EOF

重新加载守护进程,并重启Docker服务:

1
2
3
4
[root@controller1 ~]# systemctl daemon-reload
[root@controller1 ~]# systemctl restart docker
// 设置docker开机自启
[root@controller1 ~]# systemctl enable docker

Docker配置访问私有仓库,修改ExecStart字段:

1
2
3
[root@controller1 ~]# vim /usr/lib/systemd/system/docker.service
#ExecStart=/usr/bin/dockerd
ExecStart=/usr/bin/dockerd –insecure-registry [SERVICE_IP]:4000

其中[SERVICE_IP]换成你部署的私有仓库所在主机的IP,本次部署在controller1上,所以用controller1IP
重启Docker服务:

1
2
[root@controller1 ~]# systemctl daemon-reload
[root@controller1 ~]# systemctl restart docker

七、配置Docker的私有仓库

限于国内网络环境的问题,如果直接在线安装很容易失败,所以我们非常有必要建立一个本地仓库。建立本地仓库所需要的OpenStack的各个组件的镜像,既可以通过Kolla进行build,也可以直接下载官网制作好的镜像。
运行Registry服务的容器,由于5000端口与keystone端口号冲突,所以我们需要修改其映射到本地4000端口上:

1
2
3
[root@controller1 ~]# docker run -d -v /opt/registry:/var/lib/registry -p 4000:5000 –restart=always –name registry registry:2
// 查看是否成功启动
[root@controller1 ~]# docker ps

运行以上命令后,会自动在线拉取registry:2的镜像,如果因为网络环境不能够正常下载,也可以在一个网络状况比较好的机器上先下载好,然后导出为.tar包,再在相应的机器上导入:

1
2
3
4
5
6
7
// 网络状况较好的机器上
[root@localhost ~]# docker pull registry:2
[root@localhost ~]# docker images
[root@localhost ~]# docker save -o registry_v2.tar registry:2
// 手动将 registry_v2.tar 包拷贝到目标机器上,然后导入
[root@controller1 ~]# docker load -i ./registry_v2.tar
[root@controller1 ~]# docker images

当前机器内有了本地镜像了以后,在运行docker run,启动registry容器:

1
2
3
[root@controller1 ~]# docker run -d -v /opt/registry:/var/lib/registry -p 4000:5000 –restart=always –name registry registry:2
// 查看是否正常启动
[root@controller1 ~]# docker ps

提前下载好官方的镜像包,本次使用:centos-source-registry-ocata.tar.gz,将其解压到:

1
tar -zxvf centos-source-registry-ocata.tar.gz -C /opt/registry/

在浏览器中输入:[SERVICE_IP]:4000/v2/_catalog,如果现实如下,则说明已经成功安装了本地仓库:
registry

Reference:

八、安装Kolla-ansible部署工具

此过程只需要在部署机上面执行,kolla-ansible既可以使用pip来安装,也可以通过git源码安装,本次通过源码安装:
下载源码包,一定要下载对应的版本,我们此次部署的是O版,所以下载O版的kolla-ansible:

1
2
[root@controller1 ~]# cd /opt
[root@controller1 ~]# git clone http://git.trystack.cn/openstack/kolla-ansible –b stable/ocata

安装kolla-ansible:

1
2
[root@controller1 ~]# cd kolla-ansible
[root@controller1 ~]# pip install ./

复制配置文件和inventory文件:

1
2
[root@controller1 ~]# cp -r etc/kolla /etc/kolla/
[root@controller1 ~]# cp -r ansible/inventory /home/inventory/

如果是在虚拟机里装kolla,希望可以启动再启动虚拟机,那么你需要把virt_type=qemu,默认是kvm:

1
2
3
4
5
6
[root@controller1 ~]# mkdir -p /etc/kolla/config/nova
[root@controller1 ~]# cat << EOF > /etc/kolla/config/nova/nova-compute.conf
[libvirt]
virt_type=qemu
cpu_mode = none
EOF

生成密码文件:

1
[root@controller1 ~]# kolla-genpwd

修改登录dashboard的admin用户的登录密码:

1
2
3
[root@controller1 ~]# vim /etc/kolla/passwords.yml
// 修改以下字段
keystone_admin_password: admin

九、开始部署

由于我们采用的是多节点物理机部署,在部署之前,我们需要修改globals.ymlmultinode两个配置文件。

① 修改globals.yml

1
[root@controller1 ~]# vim /etc/kolla/globalss.yml

给出以下样例,附带部分相关说明:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
###################
# Kolla options
###################
# Valid options are [ COPY_ONCE, COPY_ALWAYS ]
#config_strategy: “COPY_ALWAYS”
# Valid options are [ centos, oraclelinux, ubuntu ]
# 和我们使用的操作系统有关系,此处我们用的centos7,所以填写“centos”
kolla_base_distro: “centos”
# Valid options are [ binary, source ]
# 我们下载的官方镜像包是“source”类型的,如果是“binary”就改成“binary”
kolla_install_type: “source”
# Valid option is Docker repository tag
# 这个可以看看官方镜像包中软件的tag是多少,我们下载的O版对应:4.0.3
openstack_release: “4.0.3”
# Location of configuration overrides
#node_custom_config: “/etc/kolla/config”
# This should be a VIP, an unused IP on your network that will float between
# the hosts running keepalived for high-availability. When running an All-In-One
# without haproxy and keepalived, this should be the first IP on your
# ‘network_interface’ as set in the Networking section below.
#这个IP地址是和em1网卡在同一个网段,但是没有使用的地址,用来做HA的绑定地址
kolla_internal_vip_address: “xxx.xxx.xxx.xxx”
# This is the DNS name that maps to the kolla_internal_vip_address VIP. By
# default it is the same as kolla_internal_vip_address.
#kolla_internal_fqdn: “{{ kolla_internal_vip_address }}”
# This should be a VIP, an unused IP on your network that will float between
# the hosts running keepalived for high-availability. It defaults to the
# kolla_internal_vip_address, allowing internal and external communication to
# share the same address. Specify a kolla_external_vip_address to separate
# internal and external requests between two VIPs.
#kolla_external_vip_address: “{{ kolla_internal_vip_address }}”
# The Public address used to communicate with OpenStack as set in the public_url
# for the endpoints that will be created. This DNS name should map to
# kolla_external_vip_address.
#kolla_external_fqdn: “{{ kolla_external_vip_address }}”
####################
# Docker options
####################
# Below is an example of a private repository with authentication. Note the
# Docker registry password can also be set in the passwords.yml file.
#填写本地仓库的运行的服务器地址+端口号
docker_registry: “[SERVICE_IP]:4000”
#如果使用的是OpenStack官方的镜像包,此项必须为:“lokolla”
docker_namespace: “lokolla”
#docker_registry_username: “sam”
#docker_registry_password: “correcthorsebatterystaple”
###############################
# Neutron – Networking Options
###############################
# This interface is what all your api services will be bound to by default.
# Additionally, all vxlan/tunnel and storage network traffic will go over this
# interface by default. This interface must contain an IPv4 address.
# It is possible for hosts to have non-matching names of interfaces – these can
# be set in an inventory file per host or per group or stored separately, see
# http://docs.ansible.com/ansible/intro_inventory.html
# Yet another way to workaround the naming problem is to create a bond for the
# interface on all hosts and give the bond name here. Similar strategy can be
# followed for other types of interfaces.
#此处配置第一块网卡,也是其他未制定网卡的Interface的默认选项
network_interface: “em1”
# These can be adjusted for even more customization. The default is the same as
# the ‘network_interface’. These interfaces must contain an IPv4 address.
#kolla_external_vip_interface: “{{ network_interface }}”
#api_interface: “{{ network_interface }}”
#Ceph数据传输专用网卡,此项最好为万兆网卡,以提升总体性能
storage_interface: “p5p2”
cluster_interface: “p5p2”
#tunnel_interface: “{{ network_interface }}”
#dns_interface: “{{ network_interface }}”
# This is the raw interface given to neutron as its external network port. Even
# though an IP address can exist on this interface, it will be unusable in most
# configurations. It is recommended this interface not be configured with any IP
# addresses for that reason.
#floatingIP用来外转数据包的网卡,就是我们空出来,没有配置IP的那个网卡
neutron_external_interface: “em2”
# Valid options are [ openvswitch, linuxbridge ]
#neutron_plugin_agent: “openvswitch”
####################
# keepalived options
####################
# Arbitrary unique number from 0..255
#keepalived_virtual_router_id: “51”
####################
# TLS options
####################
# To provide encryption and authentication on the kolla_external_vip_interface,
# TLS can be enabled. When TLS is enabled, certificates must be provided to
# allow clients to perform authentication.
#kolla_enable_tls_external: “no”
#kolla_external_fqdn_cert: “{{ node_config_directory }}/certificates/haproxy.pem”
####################
# OpenStack options
####################
# Use these options to set the various log levels across all OpenStack projects
# Valid options are [ True, False ]
#openstack_logging_debug: “False”
# Valid options are [ novnc, spice ]
#nova_console: “novnc”
# OpenStack services can be enabled or disabled with these options
# 以下选项根据自己想要安装的OpenStack组件,把相应选项前的注释去掉即可
enable_aodh: “yes”
#enable_barbican: “no”
enable_ceilometer: “yes”
#enable_central_logging: “no”
enable_ceph: “yes”
#如果用ceph作为swift的后端存储,enable_ceph_rgw必须为yes
enable_ceph_rgw: “yes”
#enable_chrony: “no”
enable_cinder: “yes”
#enable_cinder_backend_hnas_iscsi: “no”
#enable_cinder_backend_hnas_nfs: “no”
#enable_cinder_backend_iscsi: “no”
#enable_cinder_backend_lvm: “no”
#enable_cinder_backend_nfs: “no”
#enable_cloudkitty: “no”
#enable_collectd: “no”
#enable_congress: “no”
#enable_designate: “no”
#enable_destroy_images: “no”
#enable_etcd: “no”
enable_freezer: “yes”
enable_gnocchi: “yes”
#enable_grafana: “no”
enable_heat: “yes”
enable_horizon: “yes”
#enable_horizon_cloudkitty: “{{ enable_cloudkitty | bool }}”
enable_horizon_freezer: {{ enable_freezer | bool }}
#enable_horizon_ironic: “{{ enable_ironic | bool }}”
#enable_horizon_karbor: “{{ enable_karbor | bool }}”
enable_horizon_magnum: {{ enable_magnum | bool }}
#enable_horizon_manila: “{{ enable_manila | bool }}”
#enable_horizon_mistral: “{{ enable_mistral | bool }}”
#enable_horizon_murano: “{{ enable_murano | bool }}”
enable_horizon_neutron_lbaas: {{ enable_neutron_lbaas | bool }}
enable_horizon_sahara: {{ enable_sahara | bool }}
#enable_horizon_searchlight: “{{ enable_searchlight | bool }}”
#enable_horizon_senlin: “{{ enable_senlin | bool }}”
#enable_horizon_solum: “{{ enable_solum | bool }}”
#enable_horizon_tacker: “{{ enable_tacker | bool }}”
#enable_horizon_trove: “{{ enable_trove | bool }}”
#enable_horizon_watcher: “{{ enable_watcher | bool }}”
#enable_influxdb: “no”
#enable_ironic: “no”
#enable_karbor: “no”
#enable_kuryr: “no”
enable_magnum: “yes”
#enable_manila: “no”
#enable_manila_backend_generic: “no”
#enable_manila_backend_hnas: “no”
#enable_mistral: “no”
enable_mongodb: “yes”
#enable_murano: “no”
#enable_multipathd: “no”
#enable_neutron_dvr: “yes”
#enable_neutron_lbaas: “yes”
#enable_neutron_fwaas: “yes”
#enable_neutron_qos: “yes”
#enable_neutron_agent_ha: “no”
#enable_neutron_vpnaas: “yes”
#enable_nova_serialconsole_proxy: “no”
#enable_octavia: “no”
#enable_panko: “no”
#enable_rally: “no”
enable_sahara: “yes”
#enable_searchlight: “no”
#enable_senlin: “no”
#enable_solum: “no”
#这个如果开启了enable_ceph_rgw_keystone, enable_swift必须为no,两者只能启用一个
#enable_swift: “no”
#enable_telegraf: “no”
#enable_tacker: “no”
#enable_tempest: “no”
#enable_trove: “no”
#enable_vmtp: “no”
#enable_watcher: “yes”
###################
# Ceph options
###################
# Ceph can be setup with a caching to improve performance. To use the cache you
# must provide separate disks than those for the OSDs
#ceph_enable_cache: “no”
# Valid options are [ forward, none, writeback ]
#ceph_cache_mode: “writeback”
# A requirement for using the erasure-coded pools is you must setup a cache tier
# Valid options are [ erasure, replicated ]
#ceph_pool_type: “replicated”
# Integrate ceph rados object gateway with openstack keystone
#和enable_swift两个只能选择一个为“yes”
enable_ceph_rgw_keystone: “yes”
##############################
# Keystone – Identity Options
##############################
# Valid options are [ uuid, fernet ]
#keystone_token_provider: ‘uuid’
# Interval to rotate fernet keys by (in seconds). Must be an interval of
# 60(1 min), 120(2 min), 180(3 min), 240(4 min), 300(5 min), 360(6 min),
# 600(10 min), 720(12 min), 900(15 min), 1200(20 min), 1800(30 min),
# 3600(1 hour), 7200(2 hour), 10800(3 hour), 14400(4 hour), 21600(6 hour),
# 28800(8 hour), 43200(12 hour), 86400(1 day), 604800(1 week).
#fernet_token_expiry: 86400
#########################
# Glance – Image Options
#########################
# Configure image backend.
# 此处我们选择glance后端为file,因为ceph作为后端的时候,只能使用raw的镜像
glance_backend_file: “yes”
glance_backend_ceph: “no”
#######################
# Ceilometer options
#######################
# Valid options are [ mongodb, mysql, gnocchi ]
# 此时我们用gnocchi作为ceilometer的数据库,也可以选用mongodb
ceilometer_database_type: “gnocchi”
# Valid options are [ mongodb, gnocchi, panko ]
# 此时我们用gnocchi作为ceilometer的数据库,也可以选用mongodb
ceilometer_event_type: “gnocchi”
#######################
# Barbican options
#######################
# Valid options are [ simple_crypto, p11_crypto ]
#barbican_crypto_plugin: “simple_crypto”
#barbican_library_path: “/usr/lib/libCryptoki2_64.so”
#######################
## Panko options
#######################
# Valid options are [ mongodb, mysql ]
#panko_database_type: “mysql”
#######################
# Gnocchi options
#######################
# Valid options are [ file, ceph ]
#gnocchi_backend_storage: “{{ ‘ceph’ if enable_ceph|bool else ‘file’ }}”
#################################
# Cinder – Block Storage Options
#################################
# Enable / disable Cinder backends
#用ceph作为cinder的后端存储
cinder_backend_ceph: {{ enable_ceph }}
#cinder_volume_group: “cinder-volumes”
#cinder_backup_driver: “nfs”
#cinder_backup_share: “”
#cinder_backup_mount_options_nfs: “”
#######################
# Designate options
#######################
# Valid options are [ bind9 ]
designate_backend: “bind9”
designate_ns_record: “sample.openstack.org”
#########################
# Nova – Compute Options
#########################
#用ceph作为nova的后端存储
nova_backend_ceph: {{ enable_ceph }}
##############################
# Horizon – Dashboard Options
##############################
#horizon_backend_database: “{{ enable_murano | bool }}”
#######################################
# Manila – Shared File Systems Options
#######################################
# HNAS backend configuration
#hnas_ip:
#hnas_user:
#hnas_password:
#hnas_evs_id:
#hnas_evs_ip:
#hnas_file_system_name:
##################################
# Swift – Object Storage Options
##################################
# Swift expects block devices to be available for storage. Two types of storage
# are supported: 1 – storage device with a special partition name and filesystem
# label, 2 – unpartitioned disk with a filesystem. The label of this filesystem
# is used to detect the disk which Swift will be using.
# Swift support two mathcing modes, valid options are [ prefix, strict ]
#swift_devices_match_mode: “strict”
# This parameter defines matching pattern: if “strict” mode was selected,
# for swift_devices_match_mode then swift_device_name should specify the name of
# the special swift partition for example: “KOLLA_SWIFT_DATA”, if “prefix” mode was
# selected then swift_devices_name should specify a pattern which would match to
# filesystems’ labels prepared for swift.
#swift_devices_name: “KOLLA_SWIFT_DATA”
################################################
# Tempest – The OpenStack Integration Test Suite
################################################
# following value must be set when enable tempest
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:
# tempest_image_alt_id: “{{ tempest_image_id }}”
# tempest_flavor_ref_alt_id: “{{ tempest_flavor_ref_id }}”

② 配置multinode文件,这个文件主要是指定物理节点的角色,供ansible使用:

1
[root@controller1 ~]# vim /home/inventory/multinode

给出如下样例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
# These initial groups are the only groups required to be modified. The
# additional groups are for more control of the environment.
[control]
# These hostname must be resolvable from your deployment host
controller1
controller2
controller3
# The above can also be specified as follows:
#control[01:03] ansible_user=kolla
# The network nodes are where your l3-agent and loadbalancers will run
# This can be the same as a host in the control group
[network]
controller1
controller2
controller3
[compute]
compute1
compute2
compute3
compute4
compute5
compute6
compute7
compute8
compute9
[monitoring]
controller1
# When compute nodes and control nodes use different interfaces,
# you can specify “api_interface” and other interfaces like below:
#compute01 neutron_external_interface=eth0 api_interface=em1 storage_interface=em1 tunnel_interface=em1
[storage]
controller1
controller2
controller3
compute1
compute2
compute3
compute4
compute5
compute6
compute7
compute8
compute9
# 以下剩余的部分不需要修改

③ 为安装Ceph准备OSD节点,在所有的存储节点上执行如下命令,此次我们以有两块数据盘 sdbsdc为例:
格式化sdb数据盘:

1
2
3
4
5
6
7
8
[root@controller1 ~]# parted /dev/sdb -s — mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1
[root@controller1 ~]# parted /dev/sdb print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 10.7GB 10.7GB KOLLA_CEPH_OSD_BOOTSTRAP

格式化sdc数据盘:

1
2
3
4
5
6
7
8
[root@controller1 ~]# parted /dev/sdc -s — mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1
[root@controller1 ~]# parted /dev/sdc print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sdc: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 10.7GB 10.7GB KOLLA_CEPH_OSD_BOOTSTRAP

④ 部署前检查,只需要在部署节点上执行如下命令:

1
[root@controller1 ~]# kolla-ansible prechecks -i /home/inventory/multinode

这时候,kolla会自动对配置文件,和当前机器的部署环境做检测,如果全是ok,那就可以开始部署,如果出现了fail可以根据相应的提示,查找问题并是修复,然后再检查一遍,如此循环,直到全部ok为止。预计执行大概需要半个小时,如果相看详细的输出日志,可以在命令后面加上-vvv

④ 开始部署,只需要在部署节点上执行如下命令:

1
[root@controller1 ~]# kolla-ansible deploy -i /home/inventory/multinode

这时候,kolla便开始自动从本地仓库中拉取相应的镜像,在/etc/kolla/目录下生成各个组件的配置文件,根据配置文件启动相应的组件的container并调用kolla_start脚本进行初始化,然后配置各个服务的endpoint地址,最终完成OpenStack的安装。首次执行需要拉取镜像,时间会比较长,以后每次重复执行不需要拉取镜像,大概运行时间为半个小时左右,如果想看详细的日志信息,可以在命令后面加上-vvv

⑤ 部署过程中如果遇到什么错误导致了fail,可以先看看输出信息,是否能够定位到具体的问题,如果可以则修复问题,如果没有什么头绪,可以直接重试运行上述命令,进行再次部署,基本可能会成功,如果问题重复出现,则需要好好看看输出日志,找找问题所在并修复。

⑥ 成功部署后,可以通过如下命令查看是否所有的container都在正常运行:

1
[root@controller1 ~]# docker ps -a

如果都正常,可以在浏览器中输入你再globals.yml制定的kolla_internal_vip_address的IP地址来访问dashboard。用户名为:admin,登陆密码为你再passwords.yml中制定的keystone_admin_password字段的值。

⑦ 如果想要增加组件,可以直接修改globals.yml文件中的配置项,然后运行④中的命令。

⑧ 如果想要重新部署,可以使用如下命令清理环境,然后再次运行④中的命令:

1
[root@controller1 ~]# kolla-ansible destroy -i /home/inventory/multinode

会有一个提示你确认的过程,只需要按照它的提示,输入相应的命令选项确认即可。

Note:
在执行destroy命令之前一定要确保,当前OpenStack平台上没有存储镜像,也没有相应的instancevolume,也没有swift的存储空间,总而言之,OpenStack上面除了配置选项外,不能存有任何额外的东西,否则会导致清理环境失败。这点一定要切记,很重要!!!

如果使用的Ceph储存,还需要删除相应的挂在盘并重新打上OSD标签,此处以有sdbsdc两块数据盘为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//查看当前
[root@controller1 ~]# df -h
……
/dev/sdb1 495G 41M 495G 1% /var/lib/ceph/osd/40d7390c-43d5-48f9-ad94-9cd59393b111
/dev/sdc1 495G 41M 495G 1% /var/lib/ceph/osd/2d4f594e-5212-4fcc-ada3-e9553f7c8050
……
//卸载这两块盘
[root@controller1 ~]# umount /dev/sdb1
[root@controller1 ~]# umount /dev/sdc1
//重新为两块盘打上OSD标签
[root@controller1 ~]# parted /dev/sdb -s — mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1
[root@controller1 ~]# parted /dev/sdc -s — mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1

此时部署环境已经准备好,再次运行④中的命令,进行部署,非常方便。

十、验证部署并初始化

部署完成后,我们需要进行验证,会在/etc/kolla目录下生成admin-openrc.sh文件:

1
[root@controller1 ~]# kolla-ansible post-deploy

安装OpenStack的client端:

1
[root@controller1 ~]# pip install python-openstackclient

编辑初始化脚本文件/usr/share/kolla-ansible/init-runonce

1
2
3
4
5
[root@controller1 ~]# vim /usr/share/kolla-ansible/init-runonce
// 修改一下部分
EXT_NET_CIDR=’192.168.12.0/24′
EXT_NET_RANGE=’start=192.168.12.30,end=192.168.12.40′
EXT_NET_GATEWAY=’192.168.12.1′

Note:
192.168.12.0只是一个示例网络,这个网络是给VM的floatingIP来用,就是我上面em2接的网络,这个网络需要可以通过路由器访问互联网,并且能够远程SSH。此处的IP地址请根据自己的实际情况修改。

运行初始化脚本,进行初始化:

1
2
3
[root@controller1 ~]# source /etc/kolla/admin-openrc.sh
[root@controller1 ~]# cd /usr/share/kolla-ansible
[root@controller1 ~]# ./init-runonce

Note:
上面这个初试化过程中需要从http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img下载一个测试镜像,限于网络原因,有可能下载很慢或者下载失败,我们可以手动用下载工作下载好,放到/usr/share/目录下,这样,脚本就会检测到已经下载完成,不会再进行下载,直接上传。

可以根据脚本最后运行完的提示运行如下命令,创建一个VM:

1
2
3
4
5
6
openstack server create \
–image cirros \
–flavor m1.tiny \
–key-name mykey \
–nic net-id=2ba93782-71e2-44d6-ad64-796c5853dcce \
demo1

登陆dashboard,正常使用OpenStack。

十一、附Docker常用命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// 列出当前宿主机上已有的镜像
[root@controller1 ~]# docker images
// 在docker index中搜索image
[root@controller1 ~]# docker search IMAGE_NAME
// 从docker registry server 中下拉image或repository,只写名字为从官方hub拉取
[root@controller1 ~]# docker pull [SERVICE_IP]:4000/mongo:latest
// 推送一个image或repository到registry
[root@controller1 ~]# docker push [SERVICE_IP]:4000/mongo:2014-10-27
// 从image启动一个container
[root@controller1 ~]# docker run [OPTIONS] IMAGE [COMMAND] [ARG…]
// 将一个container固化为一个新的image
[root@controller1 ~]# docker commit <container> [repo:tag]
// 开启/停止/重启container(start/stop/restart)
[root@controller1 ~]# docker start/stop/restart CONTAINER_ID
// 查看image或container的底层信息(inspect)
[root@controller1 ~]# docker inspect CONTAINER_ID
// 删除一个或多个container
[root@controller1 ~]# docker rm <container_id/contaner_name>
// 删除所有停止的容器
[root@controller1 ~]# docker rm $(docker ps -a -q)
// 删除一个或多个image
[root@controller1 ~]# docker rmi <image_id/image_name …>
// 查看容器的信息container
[root@controller1 ~]# docker ps -a
// 查看容器中正在运行的进程
[root@controller1 ~]# docker top CONTAINER_ID
// 查看容器的运行日志
[root@controller1 ~]# docker logs CONTAINER_ID
// 导出当前宿主机上已有的镜像
[root@controller1 ~]# docker save -o NAME.tar IMAGE_NAEM:TAG
// 导入已有的镜像tar包
[root@controller1 ~]# docker Load -i NAME.tar
// 以root权限登陆container内部
[root@controller1 ~]# docker exec -it -u root CONTAINER_ID /bin/bash

十二、参考资料

Reference:

 

参考: http://jqjiang.com/openstack/openstack_kolla/

https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

http://www.jinkit.com/openstack-dockerized/

 

 

 

Categories: 未分类

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *