nova

一、 首先修改nova的配置文件。文件位置 /etc/nova/nova.conf 将inject_password改为True 二、 重启nova服务：systemctl restart openstack-nova-* 三、 在创建虚拟机时加入如下脚本，配置驱动必须勾选 !/bin/sh passwd root<<EOF test test EOF 四、 创建虚拟机实例后就能使用root登录 五、 下图为注入成功与注入失败不同情况 六、 测试发现第一步未修改配置文件也可以成功注入，大家可以自己测试 原文：http://blog.51cto.com/dingtongxue1990/2132304

nova安装 1、首先创建nova数据库，并且赋予数据库权限 mysql -u root -p123456 CREATE DATABASE nova_api; CREATE DATABASE nova; CREATE DATABASE nova_cell0; GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'*' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'*' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'*' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'%' IDENTIFIED BY '123456'; source admin-openrc 2、创建nova用户

1、概要 2、分析 3、代码跟踪 通过上面代码跟踪，发现nova-cert是通过nova.cmd.cert.py文件中的main（）函数，来启动二进制服务命令的。这里先提一句，service在nova中分两种，一个是wsgi service，接收处理restAPI请求，例如nova-api。另一个是rpc service，来处理RPC request。这里的service.Service创建的是rpc service。 3.2主代码nova.service、oslo_service.service代码跟踪 3.2.1nova.service.Service.create函数 service.Service.create()是一个类方法，最后实现的是实例化了Service类。 3.2.2service.serve(server)方法 3.2.2.1第一层调用点，即在nova代码中的调用 这里就是service.serve()函数的定义点。具体又调了service.launch()函数，service是oslo_service模块下的service。以下代码进入了oslo的代码库。（对于小白，oslo理解成openstack liberary，即openstack的代码共用库） 3.2.2.2oslo_service代码内部service.py分析 这里找到了在nova.service

OpenStack Nova OpenStack 中的 Nova 负责维护和管理云环境的计算资源 Nova 在现有 Linux 服务器上作为一组守护线程来提供服务 Nova 由多个服务器进程组成，每个进程执行不同的功能 面向用户的界面是 REST API ，而 Nova 组件内部通过 RPC 消息传递机制进行通信 需要以下额外的服务来实现基本功能： Keystone ：为所有的 OpenStack 服务提供认证 (identity and authentication) Glance ：提供计算镜像仓库 (compute image repository)，所有的计算实例均由计算镜像启动 Neutron ：负责配置计算实例在启动时连接到的虚拟或物理网络 Placement ：跟踪云中可用资源的清单，并帮助选择创建虚拟机时资源的提供者 API nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。当客户需要执行虚拟机相关的操作时，能且只能向 nova-api 发送 REST 请求 nova-api service 接收和响应 end user 的 API 调用 nova-api-metadata service 接收来自实例的源数据请求 通常只在安装有 nova-network 服务的多主机模式下使用 compute core nova

1，将节点上所有实例迁移都其他节点 2，停止节点服务 2，进入数据库，use nova； MariaDB [nova]> select * from nova.services; +---------------------+---------------------+------------+-----+----------------------+--------------------+-------------+--------------+----------+---------+-----------------+---------------------+-------------+---------+--------------------------------------+ | created_at | updated_at | deleted_at | id | host | binary | topic | report_count | disabled | deleted | disabled_reason | last_seen_up | forced_down | version | uuid | +---------------------+---------------------+------------+-----+--------------

8774是nova的端口号，所以我就逐一查看nova的日志文件。 tail -f /var/log/nova/nova-conductor.log 2019-06-13 08:24:53.559 4448 ERROR oslo.messaging._drivers.impl_ 2019-06-13 08:24:53.559 4448 ERROR oslo.messaging._drivers.impl_ rabbit DuplicateMessageError: Found duplicate message(98b 发现是rabbit的问题，所以重启rabbitmq服务即可。 systemctl restart rabbitmq-server.service 碰到问题的时候一定要查看日志文件，具体问题具体解决。

API 前端服务 每个 OpenStack 组件可能包含若干子服务，其中必定有一个 API 服务负责接收客户请求。 以 Nova 为例 nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。 当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。 这里的客户包括终端用户、命令行和 OpenStack 其他组件。 设计 API 前端服务的好处在于： 1、对外提供统一接口，隐藏实现细节 2、API 提供 REST 标准调用服务，便于与第三方系统集成 3、可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程 Scheduler 调度服务 对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。 以 Nova 为例 Nova 有多个计算节点。 当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。 调度服务好比是开发团队中的项目经理，当接到新的开发任务后，项目经理会评估任务的难度，考察团队成员目前的工作负荷和技能水平，然后将任务分配给最合适的开发人员。 除了 Nova，块服务组件 Cinder 也有 scheduler 子服务。 Worker

openstack维持了六个月发布版本的周期。10月16日Openstack将发布Juno版本，包含几个新的项目以及大量新的特性。本文不做全面介绍，对新功能只是浅尝辄止。 Nova 作为Openstack的核心功能，Nova需要保持稳定。但这并不意味着更新缓慢，在Juno版本中有重大的变化。 NFV：Network Function Virtualization网络功能虚拟化是一个非常重要的概念，可以发现有很多个体开发者和大量公司在讨论NFV Live Upgrades:在线升级在Icehouse中首次介绍，但仍然有点麻烦。在Juno中将发现在线升级有重大提升。 Ceilometer Ceilometer是openstack的计量测量组件。 Speed：在过去的几个开发周期中，Ceilometer开发团队意识到该项目中几个拙劣的设计，而在本开发周期花费了大量时间去偿还技术债务以提升Ceilometer的性能。因此你将发现Ceilometer将变得更有效，更快。 Heat Heat是openstack的编排组件，用来自动创建或者拆卸基础设施以响应时间或者改编事件。 Rollback：在前面版本中，如果Heat部署失败，不会回退，并且需要手工删除。在Juno中很容易回退文件部署，保证所有的碎片都被清除。 Create resouces without being admin

#openstack 群集配置 pacemaker+haproxy ##openstack 群集 pacemaker+haproxy #关闭selinux、防火墙 #关闭selinux、防火墙 systemctl stop firewalld.service systemctl disable firewalld.service firewall-cmd --state sed -i '/^SELINUX=.*/c SELINUX=disabled' /etc/selinux/config sed -i 's/^SELINUXTYPE=.*/SELINUXTYPE=disabled/g' /etc/selinux/config grep --color=auto '^SELINUX' /etc/selinux/config setenforce 0 #时间同步 #设置hostname, 每个节点分别设置 #时间同步 yum install -y ntp systemctl enable ntpd && systemctl restart ntpd timedatectl set-timezone Asia/Shanghai /usr/sbin/ntpdate ntp6.aliyun.com echo "*/3 * * * * /usr/sbin/ntpdate ntp6

随着云技术以及容器技术的崛起，人肉运维的时代结束了 2018年为了解决日常运维中的痛点以及更高效的推进运维工作，我们自研并完善了几个工具系统，这些系统无一例外的帮我们节约了时间，提高了效率，这篇文章将分享介绍一下这些工具系统 系统介绍 CMDB CMDB配置管理数据库，主要用来记录我们管理维护的软硬件信息，包含实体的服务器，交换机以及虚拟的项目、服务、环境等所有需要管理维护的信息，通俗一点理解就是之前我们可能一个excel表格记录了我们维护的所有项目，项目所用的服务器资源，服务器的配置等等信息，都可以录入到CMDB系统里统一维护管理 CMDB系统是其他很多系统的基石，要给所有用到基础信息的第三方系统提供API以查询或修改数据，例如提供项目对应的服务器信息给持续部署工具推送代码到项目服务器上，所以CMDB系统的数据准确性非常重要，同时只在一个地方维护基础信息能够让整个运维系统更可控，更高效，减少出错 我们CMDB系统上线时间比较久，之前仅是用来替代Excel表格维护信息用，今年为他增加了API，提供给第三方系统获取基础数据，API认证采用了JWT，关于API认证这篇文章有更多的介绍： Django+JWT实现Token认证 varian varian是我们内部开发的一个模块化的持续集成工具，主要负责项目从源代码到最终可部署程序的这个过程，现在有大部分项目已经是Docker部署了