云原生｜Packer插件开发在项目中应用

本文主要是介绍云原生｜Packer插件开发在项目中应用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：李冠军神州数码云基地高级后端开发工程师

云时代我们可以在各云厂商控制台点一点，实例就生成了，但是这个点还是需要自己去点，如果把这些动作写成代码，直接运行，一切就完成了。

这就是Packer的作用，可以构建一个可以马上部署的云服务器镜像，可以在代码中定义基础镜像，预装哪些软件，装完后再生成一个镜像，然后就可以直接使用这个镜像生成实例了，实例启动后，一切险准备就绪，也不用执行什么初始化脚本，代码就可以在多个云平台上使用。

想要通过Packer构建不同云平台的镜像，这就需要安装不同云平台的Packer插件，当然一些云平台还不支持此工具，而这个时候就需要我们针对云平台进行packer插件的开发了。

Packer插件开发的本质上是通过调用云平台API来进行云资源的操作，如何进行Packer插件开发这里就不再赘述了，这里是官方文档-Packer 插件开发文档。

这里说一下我们实际的项目应用。

我们根据客户需求开发了一版针对移动合营云云平台的Packer插件（packer-plugin-hecloud）

插件基于Pakcer官方插件模板包，结合云平台SDK包调用云资源服务接口，进行镜像创建相关操作。

项目案例分享

一、Packer插件实例

实现Packer插件必须由Go语言实现

实现插件所需要做的是：

packer-plugin所需接口的实现
使用packer-plugin-sdk中提供的服务器提供服务

Packer核心和 SDK 会处理服务器内部的所有通信细节

必须使用官方提供的两个包来实现服务器和接口

"github.com/hashicorp/packer-plugin-sdk/plugin" //包含官方提供插件的代码。这处理所有进程间通信。
"github.com/hashicorp/packer-plugin-sdk/packer" //包含必须为任何插件实现的所有接口

下图使用了其中上述之一http://github.com/hashicorp/packer-plugin-sdk/plugin

上图代码中

plugin.NewSet(): 调用处理与 Packer 核心通信和通过 RPC 为组件提供服务的所有细节。只要注册的结构实现了组件接口之一，Packer 现在就可以启动此插件并使用它。

ecsbuilder.Builder实现了"http://github.com/hashicorp/packer-plugin-sdk/packer"，并通过pps.Run()提供服务

下面我们看一下builder目录中的代码

核心文件在/builder/ecs/builder.go中

上图所示：

builder.go中的 Run()方法是实际执行自定义打包镜像的过程
同级目录下的以step开头的文件，都实现了官方包http://github.com/hashicorp/packer-plugin-sdk/multistep中的Step interface，都属于打包步骤
每个步骤一个文件，传入不同的配置参数，去调用云平台SDK包去实现相对应的操作
最后由Builder执行Run()来进行打包操作

//打包镜像全步骤

目录都为同级builder/ecs/

step_load_zones.go中的StepLoadAZ用户加载可用区，listZones()方法调用云平台接口os-availability-zone
step_load_flavor.g中的StepLoadFlavor用户加载Flavor ，比如：s6.large.2
step_key_pair.go中的StepKeyPair 创建临时密钥对
step_source_image_info.go 设置source_image
step_create_volume.go 创建volume并记录volume_id
step_run_source_server.go ，根据配置以及source_image、flavor创建服务，并生成Server ID ，须在云平台已经开通弹性云服务
step_get_password.go 在使用winrm的情况下并且未设密码的情况下，自动生成密码
step_allocate_ip.go创建并分配IP，根据参数是否设置来分配，如下图

将浮动ip和实例端口相关联

step_connect.go通过ssh communicator服务建立连接
step_provision，官方步骤-打包过程Provision配置器处理，配置器配置的相关命令操作，如下图

step_cleanup_temp_keys-官方步骤清理临时密钥
step_stop_server 将创建的服务停掉
step_create_image根据当前服务实例创建镜像
step_add_image_members为新建镜像添加用户，未设置直接返回
step_update_image_mindisk更新磁盘镜像

上述步骤为实际执行过程的全步骤

//执行和返回过程

执行在b.runner.Run(ctx, state)这一步进行

如图示，执行后续根据错误返回err信息，未生成镜像返回nil，成功生成镜像，返回镜像相关信息

打包成功示意图：

以上就是Packer插件开发的代码实际流程。

二、兼容性问题

这里说一下项目交付后遇到的一个问题，就是Packer v1.7.0以下的版本云平台插件需要做兼容处理。

由于项目开发阶段，客户没有要求Packer版本等事宜，上述插件是在Packer v1.8.0的基础上开发的。

然而客户生产环境Packer版本是v1.6.6，可能因为版本导致了一些兼容性的问题。

在当前的测试环境，将Packer版本切换到v1.6.6，并执行打包命令

脚本配置如下：

报错如下：

将Packer版本切换到v1.8.0及更高版本，执行打包命令 packer build ，发现能够正常执行打包。

故推测该问题由于低版本Packer打包调用高版本hecloud-ecs插件导致。

packer-plugin的开发，这里需要packer官方包packer-plugin-sdk

而官方在v1.7.x之前的packer-plugin开发的文档是没有找到的

由于客户Pakcer版本是v1.6.6，这里看了一下Packer的源码v1.6.6版，发现packer-plugin-sdk在当前项目目录下，也就是 http://github.com/hashicorp/packer/packer-plugin-sdk，进入后发现，Packer v1.7.0之前的版本，插件也要使用v1.7.0之前版本的插件开发工具包来保证API兼容性。

把Packer源码切换到v1.7.0版，发现http://github.com/hashicorp/packer/packer-plugin-sdk 不存在了，变成了一个独立的Repo：http://github.com/hashicorp/packer-plugin-sdk。

由于我们的移动云插件是基于v1.8.0开发的，也就是基于独立Repo：http://github.com/hashicorp/packer-plugin-sdk，而v1.7.0之前的插件开发是需要基于http://github.com/hashicorp/packer/packer-plugin-sdk。问题初步判定是packer-plugin-sdk版本的问题。

接下来解决问题，将当前插件版本的独立Repo sdk依赖，切换到依赖pakcer v1.6.6项目内置的sdk。