Packer File Provisioner路径问题：AWS构建AMI文件复制失败

我之前也碰到过几乎一模一样的问题！核心确实是Packer处理相对路径的逻辑在子文件夹场景下容易踩坑，咱们一步步理清楚问题出在哪，以及怎么解决：

Packer解析File Provisioner里的source路径时，默认是基于你执行packer build命令的工作目录，而不是基于Packer模板文件所在的packer子文件夹。举个具体的例子：

• 你的模板路径是app/packer/template.json
• 你在app/目录下执行packer build packer/template.json
• 如果模板里写了"source": "./files/script.sh"，Packer会去app/files/script.sh找文件，而不是你预期的app/packer/files/script.sh——这就是报错的核心原因！

1. 用Packer内置变量{{template_dir}}（最推荐） #

这个变量会自动指向你的Packer模板文件所在的目录，不管你在哪里执行packer build，路径都不会出错。比如你的模板在app/packer/下，{{template_dir}}就等价于app/packer/。

配置示例：

{
  "type": "file",
  "source": "{{template_dir}}/files/setup.sh",
  "destination": "/tmp/setup.sh"
}

2. 固定执行packer build的工作目录 #

每次都进入packer子文件夹执行构建命令：

cd app/packer/
packer build template.json

这时模板里的相对路径会基于app/packer/解析，比如"./files/setup.sh"就能正确找到文件。但这种方式如果你的构建依赖应用根目录的文件，可能会引入新的路径问题，灵活性不如第一种方法。

3. 用绝对路径（临时排查用，不推荐生产） #

直接写死文件的绝对路径，比如：

{
  "type": "file",
  "source": "/home/your-user/app/packer/files/setup.sh",
  "destination": "/tmp/setup.sh"
}

这种方式移植性差，换机器或目录就得改路径，只适合临时验证问题。

可以在模板里加一个Shell Provisioner，打印Packer的工作目录和模板路径，帮你快速定位问题：

{
  "type": "shell",
  "inline": [
    "echo 'Packer执行命令的工作目录：' $PWD",
    "echo '模板所在目录：' {{template_dir}}",
    "ls -la {{template_dir}}/files"
  ]
}

执行构建后看输出，就能直观看到路径是否匹配你的预期。

内容的提问来源于stack exchange，提问作者MC Tevez