我们正在使用Packer为Azure比例集构建一个自定义的centos7图像。其中一部分包括我们创建的自定义rpm，它从源代码构建git(不能使用社区repos，所以我们自己创建)，并将其安装到/usr/local/bin目录下。在正常情况下，这个包工作得很好。所有的东西都安装到正确的位置，我们就可以使用新版本的git了。
当我们通过Packer运行东西时，我们通过ansible安装它，然后最后Packer执行解除配置步骤，捕获图像并将其放入azure共享图片库中，然后我们将其用于我们的azure比例集。
Scale set使用映像来创建几个实例，我们已经启动并运行了。问题是，突然间，/usr/local/目录似乎被重置为默认值。在/usr/local/bin中再也没有任何东西了，而且，一些(不是全部)我们作为构建git的依赖而安装的包(比如gcc)也消失了。我们的git rpm仍然被列为已安装，但是gcc没有。
/usr/bin/似乎很好(除了缺少gcc，尽管我们现在不需要它，但它似乎仍然令人担忧)，所以我们可能只是将它安装在那里，但我仍然想知道是否发生了一些疯狂的事情，以及我是否应该在将来看到/usr/local/似乎是安装它的逻辑位置。
TL;博士:
- packer获得base centos7图像
- 添加自定义git包
- git安装到/usr/local/bin(它工作了!git是可用的)
- 用waagent和通用 解除供应
- packer捕获图像并上传
- azure scale set使用image创建新实例
- /usr/local/返回到原始状态?(因此git丢失了?)
- ? ?
packer azure arm docs
waagent资源供应工具文档
我明白了。
结果是(至少在1.7.2版本中)Packer不一定对与共享图库版本相关的azure臂进行幂等操作，即使使用——force标志。
我们创建了团体形象版本之前我们已经git包完全正常工作和安装,所以基础上创建的图像没有/usr/local/bin/修改。
当我们运行带有强制标志的Packer构建时，它删除并重新创建基本映像，但是它运行一个带有SIG映像版本配置信息的PUT调用，这就是说它将"创建或更新";如果它遵循约定(除非您设置了一些打包器日志变量并将详细日志输出到文件或其他东西，否则您无法看到此内容)。
因此，当基本映像被更新为git正确设置的映像时，SIG版本认为使用的是与以前相同的基本映像(名称相同，没有唯一标识符)，因此就其而言，配置没有改变，不需要发生任何事情。在我们删除旧版本或制作新版本后，它根据我们制作的基本映像正确地启动了一个VM，并且所有内容都在应有的位置。
我绝对认为——force应该从头到尾都是幂等操作，我不确定这是否会在未来的版本中修复(在写这篇文章的时候，他们是1.7.6)，但也许我会在检查完后更新。