云原生｜还不知道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" //包含必须为任何插件实现的所有接口

上图代码中

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

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

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

上图所示：

• builder.go中的 Run()方法是实际执行自定义打包镜像的过程

• 同级目录下的以step开头的文件，都实现了官方包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 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

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

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

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

删除项目下go.mod：rm -f go.mod

指定packer依赖版本：go get github.com/hashicorp/packer@v1.6.6

项目内替换依赖项：搜索 hashicorp/packer-plugin-sdk 全部替换为 hashicorp/packer/packer-plugin-sdk

下载其余依赖：go mod tidy

重新编译：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o packer-plugin-hecloud

编译成功后将packer-plugin-hecloud 放入 /usr/local/bin下

再次测试打包  packer build

能够成功运行打包程序，问题解决。

总结一下，这个问题是由Pakcer版本引起的，Packer在v1.7.0把用于插件开发的packer-plugin-sdk，由当前项目下独立了出去，低版本Packer在执行调用对应云平台打包插件时，需要对应云平台插件做低版本兼容。