ironic 理解裸机部署过程

最新推荐文章于 2023-09-05 21:46:03 发布

hNicholas

最新推荐文章于 2023-09-05 21:46:03 发布

阅读量1w

点赞数 3

分类专栏： OpenStack

OpenStack 专栏收录该内容

328 篇文章 59 订阅

订阅专栏

部署物理机跟部署虚拟机的概念在nova来看是一样，都是nova通过创建虚拟机的方式来触发，只是底层nova-scheduler和nova-compute的驱动不一样。虚拟机的底层驱动采用的libvirt的虚拟化技术，而物理机是采用Ironic技术，ironic可以看成一组Hypervisor API的集合，其功能与libvirt类似。

操作系统安装过程

Linux系统启动过程

bootloader（引导程序，常见的有GRUB、LILO）
kernel（内核）
ramdisk（虚拟内存盘）
initrd/initramfs （初始化内存磁盘镜像）

下面我们分别介绍每个概念：

引导加载程序是系统加电后运行的第一段软件代码。PC机中的引导加载程序由BIOS(其本质就是一段固件程序)和位于硬盘MBR（主引导记录，通常位于第一块硬盘的第一个扇区）中的OS BootLoader（比如，LILO和GRUB等）一起组成。BIOS在完成硬件检测和资源分配后，硬盘MBR中的BootLoader读到系统的RAM中，然后控制权交给OS BootLoader。
bootloader负责将kernel和ramdisk从硬盘读到内存中，然后跳转到内核的入口去运行。
kernel是Linux的内核，包含最基本的程序。
ramdisk是一种基于内存的虚拟文件系统，就好像你又有一个硬盘，你可以对它上面的文件添加修改删除等等操作。但是一掉电，就什么也没有了，无法保存。一般驱动程序放在这里面。
initrd是boot loader initialized RAM disk, 顾名思义，是在系统初始化引导时候用的ramdisk。也就是由启动加载器所初始化的RamDisk设备，它的作用是完善内核的模块机制，让内核的初始化流程更具弹性；内核以及initrd，都由 bootloader在机子启动后被加载至内存的指定位置，主要功能为按需加载模块以及按需改变根文件系统。initramfs与initrd功能类似，是initrd的改进版本，改进了initrd大小不可变等等缺点。

boot procedure

Linux boot process

为什么需要initrd?

在早期的Linux系统中，一般就只有软盘或者硬盘被用来作为Linux的根文件系统，因此很容易把这些设备的驱动程序集成到内核中。但是现在根文件系统可能保存在各种存储设备上，包括SCSI, SATA, U盘等等。因此把这些设备驱动程序全部编译到内核中显得不太方便，违背了“内核”的精神。在Linux内核模块自动加载机制中可以利用udevd可以实现内核模块的自动加载，因此我们希望根文件系统的设备驱动程序也能够实现自动加载。但是这里有一个矛盾，udevd是一个可执行文件，在根文件系统被挂载前，是不可能执行udevd的，但是如果udevd没有启动，那就无法自动加载根根据系统设备的驱动程序，同时也无法在/dev目录下建立相应的设备节点。

为了解决这个矛盾，于是出现了initrd(boot loader initialized RAM disk)。initrd是一个被压缩过的小型根目录，这个目录中包含了启动阶段中必须的驱动模块，可执行文件和启动脚本。包括上面提到的udevd，当系统启动的时候，bootload会把内核和initrd文件读到内存中，然后把initrd的起始地址告诉内核。内核在运行过程中会解压initrd，然后把initrd挂载为根目录，然后执行根目录中的/initrc脚本，可以在这个脚本中运行initrd中的udevd，让它来自动加载设备驱动程序以及在/dev目录下建立必要的设备节点。在udevd自动加载磁盘驱动程序之后，就可以mount真正的根目录，并切换到这个根目录中。

Linux启动一定要用initrd么？

如果把需要的功能全都编译到内核中(非模块方式)，只需要一个内核文件即可。initrd 能够减小启动内核的体积并增加灵活性，如果你的内核以模块方式支持某种文件系统(例如ext3, UFS)，而启动阶段的驱动模块放在这些文件系统上,内核是无法读取文件系统的，从而只能通过initrd的虚拟文件系统来装载这些模块。这里有些人会问: 既然内核此时不能读取文件系统，那内核的文件是怎么装入内存中的呢?答案很简单，Grub是file-system sensitive的，能够识别常见的文件系统。通用安装流程如下：

开机启动，BIOS完成硬件检测和资源分配，选择操作系统的启动（安装）模式（此时，内存是空白的）
然后根据相关的安装模式，寻找操作系统的引导程序（bootloader）（不同的模式，对应不同的引导程序当然也对应着不同的引导程序存在的位置）
引导程序加载文件系统初始化（initrd）程序和内核初始镜像（vmlinuz），完成操作系统安装前的初始化
操作系统开始安装相关的系统和应用程序。

PXE部署过程

PXE协议分为client和server两端，PXE client在网卡的ROM中，当计算机启动时，BIOS把PXE client调入内存执行，并显示出命令菜单，经用户选择后，PXE client将放置在远端的操作系统通过网络下载到本地运行。

安装流程如下：

客户机从自己的PXE网卡启动，向本网络中的DHCP服务器索取IP，并搜寻引导文件的位置
DHCP服务器返回分给客户机IP以及NBP(Network Bootstrap Program )文件的放置位置(该文件一般是放在一台TFTP服务器上)
客户机向本网络中的TFTP服务器索取NBP
客户机取得NBP后之执行该文件
根据NBP的执行结果，通过TFTP服务器加载内核和文件系统
安装操作系统

PXE过程图

流程小结：

客户端广播dhcp请求——服务器相应请求，建立链接——由dhcp和tftp配置得到ip还有引导程序所在地点——客户端下载引导程序并开始运行——引导程序读取系统镜像-安装操作系统

Ironic部署过程

部署流程

Bare Metal Deployment Steps 此图是Liberty版的官方裸机部署过程图，部署过程描述如下：

部署物理机的请求通过 Nova API 进入Nova；
Nova Scheduler 根据请求参数中的信息（指定的镜像和硬件模板等）选择合适的物理节点；
Nova 创建一个 spawn 任务，并调用 Ironic API 部署物理节点，Ironic 将此次任务中所需要的硬件资源保留，并更新数据库；
Ironic 与 OpenStack 的其他服务交互，从 Glance 服务获取部署物理节点所需的镜像资源，并调用 Neutron 服务为物理机创建网路端口；
Ironic 开始部署物理节点，PXE driver 准备 tftp bootloader，IPMI driver 设置物理机启动模式并将机器上电；
物理机启动后，通过 DHCP 获得 Ironic Conductor 的地址并尝试通过 tftp 协议从 Conductor 获取镜像，Conductor 将部署镜像部署到物理节点上后，通过 iSCSI 协议将物理节点的硬盘暴露出来，随后写入用户镜像，成功部署用户镜像后，物理节点的部署就完成了。

下面我们通过代码来分析Ironic的部署流程。

Ironic给物理机部署系统详解

配置

在/etc/nova/nova.conf中修改manager和driver，比如修改成如下：

[DEFAULT]  
scheduler_host_manager = nova.scheduler.ironic_host_manager.IronicHostManager  
compute_driver = nova.virt.ironic.driver.IronicDriver  
compute_manager = ironic.nova.compute.manager.ClusteredComputeManager  
[ironic]  
admin_username = ironic  
admin_password = unset  
admin_url = http://127.0.0.1:35357/v2.0  
admin_tenant_name = service

compute_manager的代码实现是在ironic项目里面。

部署流程

第一步, nova-api接收到nova boot的请求，通过消息队列到达nova-scheduler

第二步, nova-scheduler收到请求后，在scheduler_host_manager里面处理。nova-scheduler会使用flavor里面的额外属性extra_specs，像cpu_arch，baremetal:deploy_kernel_id，baremetal:deploy_ramdisk_id等过滤条件找到相匹配的物理节点，然后发送RPC消息到nova-computer。

第三步,nova-computer拿到消息调用指定的driver的spawn方法进行部署，即调用nova.virt.ironic.driver.IronicDriver.spawn()，该方法做了什么操作呢？我们来对代码进行分析（下面的代码只保留了主要的调用）。

 def spawn(self, context, instance, image_meta, injected_files,  
             admin_password, network_info=None, block_device_info=None):  

        #获取镜像信息 image_meta = objects.ImageMeta.from_dict(image_meta) ...... #调用ironic的node.get方法查询node的详细信息,锁定物理机，获取该物理机的套餐信息 node = self.ironicclient.call("node.get", node_uuid) flavor = instance.flavor #将套餐里面的baremetal:deploy_kernel_id和baremetal:deploy_ramdisk_id信息 #更新到driver_info，将image_source、root_gb、swap_mb、ephemeral_gb、 #ephemeral_format、preserve_ephemeral信息更新到instance_info中， #然后将driver_info和instance_info更新到ironic的node节点对应的属性上。 self._add_driver_fields(node, instance, image_meta, flavor) ....... # 验证是否可以部署，只有当deply和power都准备好了才能部署 validate_chk = self.ironicclient.call("node.validate", node_uuid) ..... # 准备部署 try: #将节点的虚拟网络接口和物理网络接口连接起来并调用ironic API #进行更新，以便neutron可以连接 self._plug_vifs(node, instance, network_info) self._start_firewall(instance, network_info) except Exception: .... # 配置驱动 onfigdrive_value = self._generate_configdrive( instance, node, network_info, extra_md=extra_md, files=injected_files) # 触发部署请求 try: #调用ironic API，设置provision_state的状态ACTIVE self.ironicclient.call("node.set_provision_state", node_uuid, ironic_states.ACTIVE, configdrive=configdrive_value) except Exception as e: .... #等待node provision_state为ATCTIVE timer = loopingcall.FixedIntervalLoopingCall(self._wait_for_active, self.ironicclient, instance) try: timer.start(interval=CONF.ironic.api_retry_interval).wait() except Exception: ...

nova-compute的spawn的步骤包括：

获取节点
配置网络信息
配置驱动信息
触发部署，设置ironic的provision_state为ACTIVE
然后等待ironic的node provision_state为ACTIVE就结束了。

第四步

ironic-api接收到了provision_state的设置请求，然后返回202的异步请求，那我们下来看下ironic在做什么？

首先，设置ironic node的provision_stat为ACTIVE相当于发了一个POST请求：PUT /v1/nodes/(node_uuid)/states/provision。那根据openstack的wsgi的框架，注册了app为ironic.api.app.VersionSelectorApplication的类为ironic的消息处理接口，那PUT /v1/nodes/(node_uuid)/states/provision的消息处理就在ironic.api.controllers.v1.node.NodeStatesController的provision方法。

@expose.expose(None, types.uuid_or_name, wtypes.text,
                   wtypes.text, status_code=http_client.ACCEPTED)
    def provision(self, node_ident, target, configdrive=None): .... if target == ir_states.ACTIVE: #RPC调用do_node_deploy方法 pecan.request.rpcapi.do_node_deploy(pecan.request.context, rpc_node.uuid, False, configdrive, topic) ...

然后RPC调用的ironic.condutor.manager.ConductorManager.do_node_deploy方法,在方法中会先检查电源和部署信息，其中部署信息检查指定的节点的属性是否包含驱动的要求，包括检查boot、镜像大小是否大于内存大小、解析根设备。检查完之后调用ironic.condutor.manager.do_node_deploy方法

def do_node_deploy(task, conductor_id, configdrive=None):
    """Prepare the environment and deploy a node.""" node = task.node ... try: try: if configdrive: _store_configdrive(node, configdrive) except exception.SwiftOperationError as e: with excutils.save_and_reraise_exception(): handle_failure( e, task, _LE('Error while uploading the configdrive for ' '%(node)s to Swift'), _('Failed to upload the configdrive to Swift. ' 'Error: %s')) try: #调用驱动的部署模块的prepare方法，不同驱动的动作不一样 #1. pxe_* 驱动使用的是iscsi_deploy.ISCSIDeploy.prepare， #然后调用pxe.PXEBoot.prepare_ramdisk()准备部署进行和环境，包括cache images、 update DHCP、 #switch pxe_config、set_boot_device等操作 #cache images 是从glance上取镜像缓存到condutor本地， #update DHCP指定bootfile文件地址为condutor #switch pxe_config将deploy mode设置成service mode #set_boot_device设置节点pxe启动 #2. agent_* 生成镜像swift_tmp_url加入节点的instance_info中 #然后调用pxe.PXEBoot.prepare_ramdisk()准备部署镜像和环境 task.driver.deploy.prepare(task) except Exception as e: ... try: #调用驱动的deploy方法，不同驱动动作不一样 #1. pxe_* 驱动调用iscsi_deploy.ISCSIDeploy.deploy（） #进行拉取用户镜像，然后重启物理机 #2. agent_*驱动，直接重启 new_state = task.driver.deploy.deploy(task) except Exception as e: ... # NOTE(deva): Some drivers may return states.DEPLOYWAIT # eg. if they are waiting for a callback if new_state == states.DEPLOYDONE: task.process_event('done') elif new_state == states.DEPLOYWAIT: task.process_event('wait') finally: node.save()

至此，ironic-conductor的动作完成，等待物理机进行上电。

值得说明的是，task是task_manager.TaskManager的一个对象，这个对象在初始化的时候将self.driver初始化了 self.driver = driver_factory.get_driver(driver_name or self.node.driver) driver_name是传入的参数，默认为空；这个self.node.driver指物理机使用的驱动，不同物理机使用的驱动可能不同，这是在注册物理机时指定的。

第五步

在上一步中已经设置好了启动方式和相关网络信和给机器上电了，那么下一步就是机器启动，进行部署了。下面以PXE和agent两种部署方式分别来说明。

情况一、使用PXE驱动部署

我们知道安装操作系统的通用流程是：首先，bios启动，选择操作系统的启动（安装）模式（此时，内存是空白的），然后根据相关的安装模式，寻找操作系统的引导程序（不同的模式，对应不同的引导程序当然也对应着不同的引导程序存在的位置），引导程序加载文件系统初始化程序（initrd）和内核初始镜像（vmlinuz），完成操作系统安装前的初始化；接着，操作系统开始安装相关的系统和应用程序。

PXE启动方式的过程为：

物理机上电后，BIOS把PXE client调入内存执行，客户端广播DHCP请求
DHCP服务器（neutron）给客户机分配IP并给定bootstrap文件的放置位置
客户机向本网络中的TFTP服务器索取bootstrap文件
客户机取得bootstrap文件后之执行该文件
根据bootstrap的执行结果，通过TFTP服务器(conductor)加载内核和文件系统
在内存中启动安装

启动后运行init启动脚本，那么init启动脚本是什么样子的。

首先，我们需要知道当前创建deploy-ironic的镜像，使用的diskimage-build命令，参考diskimage-builder/elements/deploy-ironic这个元素，最重要的是init.d/80-deploy-ironic这个脚本，这个脚本主要其实就是做以下几个步骤：

找到磁盘，以该磁盘启动iSCSI设备
Tftp获取到ironic准备的token文件
调用ironic的api接(POST v1/nodes/{node-id}/vendor_passthru/pass_deploy_info)
启动iSCSI设备, 开启socket端口 10000等待通知PXE结束
结束口停止iSCSI设备。

# 安装bootloader
function install_bootloader {
   #此处省略很多
   ...
}


#向Ironic Condutor发送消息，开启socket端口10000等待通知PXE结束
function do_vendor_passthru_and_wait { local data=$1 local vendor_passthru_name=$2 eval curl -i -X POST \ "$TOKEN_HEADER" \ "-H 'Accept: application/json'" \ "-H 'Content-Type: application/json'" \ -d "$data" \ "$IRONIC_API_URL/v1/nodes/$DEPLOYMENT_ID/vendor_passthru/$vendor_passthru_name" echo "Waiting for notice of complete" nc -l -p 10000 } readonly IRONIC_API_URL=$(get_kernel_parameter ironic_api_url) readonly IRONIC_BOOT_OPTION=$(get_kernel_parameter boot_option) readonly IRONIC_BOOT_MODE=$(get_kernel_parameter boot_mode) readonly ROOT_DEVICE=$(get_kernel_parameter root_device) if [ -z "$ISCSI_TARGET_IQN" ]; then err_msg "iscsi_target_iqn is not defined" troubleshoot fi #获取当前linux的本地硬盘 target_disk= if [[ $ROOT_DEVICE ]]; then target_disk="$(get_root_device)" else t=0 while ! target_disk=$(find_disk "$DISK"); do if [ $t -eq 60 ]; then break fi t=$(($t + 1)) sleep 1 done fi if [ -z "$target_disk" ]; then err_msg "Could not find disk to use." troubleshoot fi #将找到的本地磁盘作为iSCSI磁盘启动，暴露给Ironic Condutor echo "start iSCSI target on $target_disk" start_iscsi_target "$ISCSI_TARGET_IQN" "$target_disk" ALL if [ $? -ne 0 ]; then err_msg "Failed to start iscsi target." troubleshoot fi #获取到相关的token文件，从tftp服务器上获取，token文件在ironic在prepare阶段就生成好的。 if [ "$BOOT_METHOD" = "$VMEDIA_BOOT_TAG" ]; then TOKEN_FILE="$VMEDIA_DIR/token" if [ -f "$TOKEN_FILE" ]; then TOKEN_HEADER="-H 'X-Auth-Token: $(cat $TOKEN_FILE)'" else TOKEN_HEADER="" fi else TOKEN_FILE=token-$DEPLOYMENT_ID # Allow multiple versions of the tftp client if tftp -r $TOKEN_FILE -g $BOOT_SERVER || tftp $BOOT_SERVER -c get $TOKEN_FILE; then TOKEN_HEADER="-H 'X-Auth-Token: $(cat $TOKEN_FILE)'" else TOKEN_HEADER="" fi fi #向Ironic请求部署镜像，POST node的/vendor_passthru/pass_deploy_info请求 echo "Requesting Ironic API to deploy image" deploy_data="'{\"address\":\"$BOOT_IP_ADDRESS\",\"key\":\"$DEPLOYMENT_KEY\",\"iqn\":\"$ISCSI_TARGET_IQN\",\"error\":\"$FIRST_ERR_MSG\"}'" do_vendor_passthru_and_wait "$deploy_data" "pass_deploy_info" #部署镜像下载结束，停止iSCSI设备 echo "Stopping iSCSI target on $target_disk" stop_iscsi_target #如果是本地启动，安装bootloarder # If localboot is set, install a bootloader if [ "$IRONIC_BOOT_OPTION" = "local" ]; then echo "Installing bootloader" error_msg=$(install_bootloader) if [ $? -eq 0 ]; then status=SUCCEEDED else status=FAILED fi echo "Requesting Ironic API to complete the deploy" bootloader_install_data="'{\"address\":\"$BOOT_IP_ADDRESS\",\"status\":\"$status\",\"key\":\"$DEPLOYMENT_KEY\",\"error\":\"$error_msg\"}'" do_vendor_passthru_and_wait "$bootloader_install_data" "pass_bootloader_install_info" fi

下面我们来看一下node的/vendor_passthru/pass_deploy_info都干了什么？Ironic-api在接受到请求后，是在ironic.api.controllers.v1.node.NodeVendorPassthruController._default()方法处理的，这个方法将调用的方法转发到ironic.condutor.manager.CondutorManager.vendor_passthro()去处理,进而调用相应task.driver.vendor.pass_deploy_info()去处理，这里不同驱动不一样，可以根据源码查看到，比如使用pxe_ipmptoos驱动, 则是转发给ironic.drivers.modules.iscsi_deploy.VendorPassthru.pass_deploy_info()处理，其代码是

@base.passthru(['POST'])
    @task_manager.require_exclusive_lock
    def pass_deploy_info(self, task, **kwargs): """Continues the deployment of baremetal node over iSCSI. This method continues the deployment of the baremetal node over iSCSI from where the deployment ramdisk has left off. :param task: a TaskManager instance containing the node to act on. :param kwargs: kwargs for performing iscsi deployment. :raises: InvalidState """ node = task.node LOG.warning(_LW("The node %s is using the bash deploy ramdisk for " "its deployment. This deploy ramdisk has been " "deprecated. Please use the ironic-python-agent " "(IPA) ramdisk instead."), node.uuid) task.process_event('resume') #设置任务状态 LOG.debug('Continuing the deployment on node %s', node.uuid) is_whole_disk_image = node.driver_internal_info['is_whole_disk_image'] #继续部署的函数，连接到iSCSI设备，将用户镜像写到iSCSI设备上，退出删除iSCSI设备， #然后在Condutor上删除镜像文件 uuid_dict_returned = continue_deploy(task, **kwargs) root_uuid_or_disk_id = uuid_dict_returned.get( 'root uuid', uuid_dict_returned.get('disk identifier')) # save the node's root disk UUID so that another conductor could # rebuild the PXE config file. Due to a shortcoming in Nova objects, # we have to assign to node.driver_internal_info so the node knows it # has changed. driver_internal_info = node.driver_internal_info driver_internal_info['root_uuid_or_disk_id'] = root_uuid_or_disk_id node.driver_internal_info = driver_internal_info node.save() try: #再一次设置PXE引导，为准备进入用户系统做准备 task.driver.boot.prepare_instance(task) if deploy_utils.get_boot_option(node) == "local": if not is_whole_disk_image: LOG.debug('Installing the bootloader on node %s', node.uuid) deploy_utils.notify_ramdisk_to_proceed(kwargs['address']) task.process_event('wait') return except Exception as e: LOG.error(_LE('Deploy failed for instance %(instance)s. ' 'Error: %(error)s'), {'instance': node.instance_uuid, 'error': e}) msg = _('Failed to continue iSCSI deployment.') deploy_utils.set_failed_state(task, msg) else: #结束部署，通知ramdisk重启，将物理机设置为ative finish_deploy(task, kwargs.get('address'))

在continue_deploy函数中，先解析iscsi部署的信息，然后在进行分区、格式化、写入镜像到磁盘。然后调用prepare_instance在设置一遍PXE环境，为进入系统做准备，我们知道在instance_info上设置了ramdisk、kernel、image_source 3个镜像，其实就是内核、根文件系统、磁盘镜像。这里就是设置了ramdisk和kernel，磁盘镜像上面已经写到磁盘中去了，调用switch_pxe_config方法将当前的操作系统的启动项设置为ramdisk和kernel作为引导程序。最后向节点的10000发送一个‘done’通知节点关闭iSCSI设备，最后节点重启安装用户操作系统，至此部署结束。

在部署过程中，节点和驱动的信息都会被存入ironic数据库，以便后续管理。

情况二、使用agent驱动部署

在部署阶段的prepare阶段与PXE一样，但是由于创建的ramdisk不一样所以部署方式则不一样，在PXE中，开机执行的是一段init脚本，而在Agent开机执行的是IPA。

机器上电后，ramdisk在内存中执行，然后启动IPA，入口为cmd.agent.run()，然后调用ironic-python-agent.agent.run()，其代码如下

def run(self):
        """Run the Ironic Python Agent.""" # Get the UUID so we can heartbeat to Ironic. Raises LookupNodeError # if there is an issue (uncaught, restart agent) self.started_at = _time() #加载hardware manager # Cached hw managers at runtime, not load time. See bug 1490008. hardware.load_managers() if not self.standalone: # Inspection should be started before call to lookup, otherwise # lookup will fail due to unknown MAC. uuid = inspector.inspect() #利用Ironic API给Condutor发送lookup()请求，用户获取UUID，相当于自发现 content = self.api_client.lookup_node( hardware_info=hardware.dispatch_to_managers( 'list_hardware_info'), timeout=self.lookup_timeout, starting_interval=self.lookup_interval, node_uuid=uuid) self.node = content['node'] self.heartbeat_timeout = content['heartbeat_timeout'] wsgi = simple_server.make_server( self.listen_address[0], self.listen_address[1], self.api, server_class=simple_server.WSGIServer) #发送心跳包 if not self.standalone: # Don't start heartbeating until the server is listening self.heartbeater.start() try: wsgi.serve_forever() except BaseException: self.log.exception('shutting down') #部署完成后停止心跳包 if not self.standalone: self.heartbeater.stop()

其中self.api_client.lookup_node调用到ironic-python-api._do_lookup()，然后发送一个GET /{api_version}/drivers/{driver}/vendor_passthru/lookup请求。 Condutor API在接受到lookup请求后调用指定驱动的lookup函数处理，返回节点UUID。

IPA收到UUID后调用Ironic-API发送Heartbeat请求（/{api_version}/nodes/{uuid}/vendor_passthru/heartbeat）,Ironic-API把消息路由给节点的驱动heartbeat函数处理。Ironic-Condutor周期执行该函数，每隔一段时间执行该函数检查IPA部署是否完成，如果完成则进入之后的动作.目前agent*驱动使用的是ironic.drivers.modouls.agent.AgentVendorInterface类实现的接口，代码如下。

@base.passthru(['POST'])
    def heartbeat(self, task, **kwargs): """Method for agent to periodically check in. The agent should be sending its agent_url (so Ironic can talk back) as a kwarg. kwargs should have the following format:: { 'agent_url': 'http://AGENT_HOST:AGENT_PORT' } AGENT_PORT defaults to 9999. """ node = task.node driver_internal_info = node.driver_internal_info LOG.debug( 'Heartbeat from %(node)s, last heartbeat at %(heartbeat)s.', {'node': node.uuid, 'heartbeat': driver_internal_info.get('agent_last_heartbeat')}) driver_internal_info['agent_last_heartbeat'] = int(_time()) try: driver_internal_info['agent_url'] = kwargs['agent_url'] except KeyError: raise exception.MissingParameterValue(_('For heartbeat operation, ' '"agent_url" must be ' 'specified.')) node.driver_internal_info = driver_internal_info node.save() # Async call backs don't set error state on their own # TODO(jimrollenhagen) improve error messages here msg = _('Failed checking if deploy is done.') try: if node.maintenance: # this shouldn't happen often, but skip the rest if it does. LOG.debug('Heartbeat from node %(node)s in maintenance mode; ' 'not taking any action.', {'node': node.uuid}) return elif (node.provision_state == states.DEPLOYWAIT and not self.deploy_has_started(task)): msg = _('Node failed to get image for deploy.') self.continue_deploy(task, **kwargs) #调用continue_deploy函数，下载镜像 elif (node.provision_state == states.DEPLOYWAIT and self.deploy_is_done(task)): #查看IPA执行下载镜像是否结束 msg = _('Node failed to move to active state.') self.reboot_to_instance(task, **kwargs) #如果镜像已经下载完成，即部署完成，设置从disk启动，重启进入用户系统， elif (node.provision_state == states.DEPLOYWAIT and self.deploy_has_started(task)): node.touch_provisioning() #更新数据库，将节点的设置为alive # TODO(lucasagomes): CLEANING here for backwards compat # with previous code, otherwise nodes in CLEANING when this # is deployed would fail. Should be removed once the Mitaka # release starts. elif node.provision_state in (states.CLEANWAIT, states.CLEANING): node.touch_provisioning() if not node.clean_step: LOG.debug('Node %s just booted to start cleaning.', node.uuid) msg = _('Node failed to start the next cleaning step.') manager.set_node_cleaning_steps(task) self._notify_conductor_resume_clean(task) else: msg = _('Node failed to check cleaning progress.') self.continue_cleaning(task, **kwargs) except Exception as e: err_info = {'node': node.uuid, 'msg': msg, 'e': e} last_error = _('Asynchronous exception for node %(node)s: ' '%(msg)s exception: %(e)s') % err_info LOG.exception(last_error) if node.provision_state in (states.CLEANING, states.CLEANWAIT): manager.cleaning_error_handler(task, last_error) elif node.provision_state in (states.DEPLOYING, states.DEPLOYWAIT): deploy_utils.set_failed_state(task, last_error)

根据上面bearthead函数，首先根据当前节点的状态node.provision_state==DEPLOYWAIT，调用continue_deploy()函数进行部署.

@task_manager.require_exclusive_lock
    def continue_deploy(self, task, **kwargs): task.process_event('resume') node = task.node image_source = node.instance_info.get('image_source') LOG.debug('Continuing deploy for node %(node)s with image %(img)s', {'node': node.uuid, 'img': image_source}) image_info = { 'id': image_source.split('/')[-1], 'urls': [node.instance_info['image_url']], 'checksum': node.instance_info['image_checksum'], # NOTE(comstud): Older versions of ironic do not set # 'disk_format' nor 'container_format', so we use .get() # to maintain backwards compatibility in case code was # upgraded in the middle of a build request. 'disk_format': node.instance_info.get('image_disk_format'), 'container_format': node.instance_info.get( 'image_container_format') } #通知IPA下载swift上的镜像，并写入本地磁盘 # Tell the client to download and write the image with the given args self._client.prepare_image(node, image_info) task.process_event('wait')

Condutor然后依次调用：

deploy_is_done()检查IPA执行下载镜像是否结束，
如果镜像已经下载完成，即部署完成，设置从disk启动，重启进入用户系统reboot_to_instance()
然后调用node.touch_provisioning() 更新数据库，将节点的设置为alive

至此，使用agent方式进行部署操作系统的过程到处结束。

hNicholas

关注

3
点赞
踩
10

收藏

觉得还不错? 一键收藏
1
评论
ironic 理解裸机部署过程

部署物理机跟部署虚拟机的概念在nova来看是一样，都是nova通过创建虚拟机的方式来触发，只是底层nova-scheduler和nova-compute的驱动不一样。虚拟机的底层驱动采用的libvirt的虚拟化技术，而物理机是采用Ironic技术，ironic可以看成一组Hypervisor API的集合，其功能与libvirt类似。操作系统安装过程Linux系统启动过程bootloader（引导...
复制链接

扫一扫