OpenStack趟坑之rocky版

OpenStack可以说是我学linux来配置花费时间最长的软件,没有之一,由于其配置步骤较多,所以出错的几率也会增大。rocky版作为18年8月新出的版本,官方文档上也是有很多的不足。

配置keystone组件

配置数据库时,使用以下命令进行数据库用户授权:

MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
IDENTIFIED BY 'KEYSTONE_DBPASS';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
IDENTIFIED BY 'KEYSTONE_DBPASS';

配置/etc/keystone/keystone.conf完成后,使用su -s /bin/sh -c "keystone-manage db_sync" keystone 同步数据库后,回车后没有在屏幕报错,以为同步成功后的我执行了下一步,在最后验证时直接报http:500错误,查看/var/log/keystone/keystone.log 发现报错为: ACCESS denied,在连接数据库时权限被拒绝,这时候我们可以判断是数据库的用户授权的问题,这时候我们回到数据库加入了 以下命令(controller node 和compute node的IP地址):

MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'10.0.0.11' \
IDENTIFIED BY 'KEYSTONE_DBPASS';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'10.0.0.31' \
IDENTIFIED BY 'KEYSTONE_DBPASS';

刷新授权后,重新进行初始化数据库,查看日志发现INFO…,查看keystone数据库,发现数据已经同步,这时候执行初始化数据库的下一步操作,如果直接验证,会报http:400错误 ,重新执行以下命令就可以解决:

# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone
# keystone-manage credential_setup --keystone-user keystone --keystone-group keystone

# keystone-manage bootstrap --bootstrap-password ADMIN_PASS \
  --bootstrap-admin-url http://controller:5000/v3/ \
  --bootstrap-internal-url http://controller:5000/v3/ \
  --bootstrap-public-url http://controller:5000/v3/ \
  --bootstrap-region-id RegionOne

但不是所有机器都需要执行IP单独授权,只是单独的机器会出现问题。所以在同步数据后一定要去查看数据是否同步成功,这样会省去之后的很多麻烦。

keystone在验证时,有下面的命令:

$ openstack --os-auth-url http://controller:33573/v3 \
  --os-project-domain-name Default --os-user-domain-name Default \
  --os-project-name admin --os-username admin token issue

执行完成后报错,我们将controller的端口改成:5000就可以了。注:现在官方文档已改正。

nova组件

在最后dashboard执行时,发现我们的实例控制台不能出现,因为在验证nova时执行openstack compute service list ,回显为:

+----+--------------------+------------+----------+---------+-------+----------------------------+
| Id | Binary             | Host       | Zone     | Status  | State | Updated At                 |
+----+--------------------+------------+----------+---------+-------+----------------------------+
|  1 | nova-scheduler     | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  5 | nova-conductor     | controller | internal | enabled | up    | 2016-02-09T23:11:16.000000 |
|  8 | nova-compute       | compute1   | nova     | enabled | up    | 2016-02-09T23:11:20.000000 |
+----+--------------------+------------+----------+---------+-------+----------------------------+

而官方文档验证回显为:

$ openstack compute service list

+----+--------------------+------------+----------+---------+-------+----------------------------+
| Id | Binary             | Host       | Zone     | Status  | State | Updated At                 |
+----+--------------------+------------+----------+---------+-------+----------------------------+
|  1 | nova-consoleauth   | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  2 | nova-scheduler     | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  3 | nova-conductor     | controller | internal | enabled | up    | 2016-02-09T23:11:16.000000 |
|  4 | nova-compute       | compute1   | nova     | enabled | up    | 2016-02-09T23:11:20.000000 |
+----+--------------------+------------+----------+---------+-------+----------------------------+

我们查看controller node 文档时发现:

# systemctl start openstack-nova-api.service \
  openstack-nova-scheduler.service openstack-nova-conductor.service \
  openstack-nova-novncproxy.service

没有启动openstack-nova-consoleauth服务,在我们执行systemctl start openstack-nova-consoleauth后,刷新界面即可。

dashboard组件

在修改/etc/openstack-dashboard/local_settings 之后,重启httpd服务,发现服务起不来,看日志报错后发现是ALLOWED_HOSTS = ['one.example.com', 'two.example.com'] 出现的问题,修改为ALLOWED_HOSTS = ['*',] 重启httpd服务即可。

基本上也就这么多了,觉得最省时间的方法就是做完一步之后,验证之后在进行下一步,如果验证之后发现结果错误,就不要进行下一步了,解决完之后在进行下一步骤,因为之后的很多步骤都是依赖上一步的。

你可能感兴趣的:(OpenStack趟坑之rocky版)