Packer: -像流浪汉一样不会破坏错误

听起来很合理。 我认为-debug标志确实是正确的方法，但也许-debug标志应允许以下选项：

• 一步一步走
• 继续直到出现错误
• 继续直到清理步骤开始

我会发现继续执行直到出现错误并且不破坏vm的选项非常有用

如果有人可以给我一些指导，从哪里开始寻求实现，那么我也许可以花一些时间将其添加为一种选择

这对我也将非常有用。

@timmow ，如果设置了某个标志（例如，https：

梳理所有步骤并找出不采取任何措施的适当位置将需要一定的工作量。

我刚刚想到的一个想法是提供一个标记，该标记将在处理任何清理步骤之前等待用户输入。 这样，您可以执行调试，例如，按Enter键，然后打包程序将负责清理。

如果我可以提供任何帮助，请随时在这里ping我。

在这里以FILO方式完成的fyi https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

您可能需要扩展基本运行器（debuggable_runner？）

最好在下方添加某种“跳过”功能，基本上可以跳过此--no-destroy-on-error类型配置的清理步骤。 它还可以在-debug模式下启用一些很酷的功能，例如按s以交互方式跳过。

与调试“暂停”类似，我认为像-pause-on-error这样的选项将是有益的。

嗨，我看到此问题已通过此提交https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08解决，但我看不到master分支的HEAD中的更改。 它在哪里以及为什么消失了？

我真的也需要这个。

有希望拥有此功能吗？ 合并2ed7c3f或它的某些变体需要做什么？

是的，我也可以使用此选项。 我看到它已提交，但随后消失了。

有什么更新吗？

我也真的很喜欢这个。 我无法告诉您，我花了多少时间尝试调试问题，并且不得不经过冗长的VM创建过程才能一次又一次地发现错误。 能够保留虚拟机将是一个巨大的胜利。

将这个（或类似功能）合并到主目录中时是否有ETA？ 尝试使用Packer构建带有安装在Visual Studio中的Visual Studio作为基本Vagrant框的一部分的VM，在有机会查看步骤失败的原因之前，我真的需要它不破坏VM。 必须通过--debug确认每个步骤都是不可接受的。

对此进行另一次投票，因为-debug选项抑制了我尝试分析的失败。

在调试机器的最终状态之前花了很多时间，才能对其进行调试。 -debug开关不能剪切它-我希望它通过正常过程运行，然后在发生故障后保持工作文件夹不变，以便我可以通过日志和状态进行诊断。 真的很期待某种保留工作状态的切换。

此功能的另一个+1，将非常有帮助。

+1遇到类似的问题，最好调试最终状态，调整一些配置脚本，然后再次运行构建以查看是否修复了该过程，而不是手动按Enter进行调试。

此功能的另一个+1。 很高兴知道这件事发生了什么？ 团队中没有人回答。 继续前进，直到它不会受伤。 大声笑！ 我是Packer的新手。 我在1.5个小时的ISO版本中处于末尾，而这确实发生了。 测试和调试对于使完整的应用程序完整流至关重要。

同样在这里+1，我们会无头创建图像，因此--debug需要手动单步执行对我们不利，但是能够检查有故障的图像会很棒。

：+1：我也喜欢这个功能

+1这个功能很棒！

与＃1687相关或重复

+1只是为了使VM保持原样而不删除@error，这将非常有用。 我们的安装脚本很长，与当前系统的步骤很多。.:(

+1这个将非常有用

+1仅在Packer失败时帮助调试配置

+1我在同一条船上。 我花了无数的时间重新创建Windows VM，只是在置备步骤中出现了Chef错误，并且在删除VM时无法调试。 请让我们提供一个选项，在故障期间不删除所有内容。

在看到这个问题已经存在了两年之后，我没有任何希望解决这个问题。 我真的很想喜欢Packer，但最终花费的时间比实际使用结果更多。

Pleeeeeaseeeeeeeee +1

+1

+1

+1

不知道这是什么意思，因此通过Google找到了这个问题。 当功能不存在时感到难过。

嗨，开发人员，我重新审视了这个线程，可以肯定地说，尽管我设法继续有效地使用打包程序，但这个错误严重地减慢了我们系统的开发速度。 我们可以做得到，但是如果工作人员可以在此问题上提供一些指导@mitchellh，那将是非常好的。 如果可以指出正确的方向，我什至可能有时间提出解决方案，但是我将等待您的答复或希望您的团队中的某个人。 谢谢你的神奇工具。 我绝对希望您和您的团队知道我认为这款产品有多棒。

由于我已经厌倦了我也想要;-)功能的所有+1电子邮件通知，因此我开始研究代码库并添加了初始实现。 注意-尚未进行测试...我什至不知道它是否可以正常工作。 如果您尝试从源代码构建它，我会遇到一个有趣的问题，Packer会从github自我引用自身，这将导致此代码无法正确构建。 您需要暂时将GoPath中的打包程序源文件夹链接到将此存储库下载到的文件夹（或等待我测试并提交拉取请求。）

https://github.com/jcoutch/packer

如果您不理解我的法语，那么这不是默认行为，这简直是疯了。 在您的安装脚本中输入了错字？ 好吧，让我们方便地_销毁您的所有工作，永不回馈您的一生。 过度。 还有。 再次。_

我想，实际上，每个人使用此工具进行除最简单示例之外的任何操作时，每一次使用它都会遇到此问题。 显然，对该功能有巨大的需求，但两年后仍未实现。

绝对惊人。

+1

伙计，那是个嘴的评论。 昨天心情不好，但是所有这些浪费的时间开始花费很多时间和金钱。

@jcoutch-您有可以共享的版本吗？

我的机器上装有OSX，只是没有机会测试它
工作了。 在我的业余时间从事此工作...我没什么可做的
最近备用。 更不用说，这是我第一次接触Go（相当
一种有趣的语言。）我将在本周末尝试对其进行测试，
如果一切看起来不错，我将提交拉取请求。 我也会尝试
我知道OSX和Windows的稳定性后，可以将它们发布给他人进行测试。

2015年9月23日，星期三，下午5：14，Rich Jones [email protected]写道：

伙计，那是个嘴的评论。 昨天心情不好，但是一直这样
浪费开始花费大量时间和金钱。

@jcouth-您有可以共享的版本吗？

-
直接回复此电子邮件或在GitHub上查看
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452。

！！ :-D

我正在尝试使用Ansible运行它，但是它不起作用，并且KVM guest虚拟机在错误发生后就消失了，因此，不可能去那里查看问题所在...

干杯!

非常需要。 谢谢。

这是@jcoutch补丁，带有正确的行尾以便于查看： https :

此修补程序仅在预处理器发生故障时才防止删除，当构建器（及其配置程序）发生故障时，它不会保留工件。

编辑：这似乎是意图，但实际上它什么也没做，尽管可以很容易地解决它。

是的，我没有机会回复此主题。 我终于尝试了
用下降的预备人员来完成我的更改...它不像我一样工作
预期的。 深入研究代码，看起来就像构建器的句柄
在配置失败时删除工件...而不是代码I
改性。

2015年10月3日，星期六，上午9:37 Orivej Desh [email protected]写道：

这是@jcoutch https://github.com/jcoutch补丁，带有正确的行
结尾以便于查看： orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

-
直接回复此电子邮件或在GitHub上查看
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481。

这里https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f是概念验证，它重新定义--debug ，以在第一次失败后仅停止一次。 它要求https://github.com/mitchellh/multistep/pull/5才能在第一次清除之前而不是在第二次清除之前停止。 ＃1687中提出了此行为。 （这不是概念证明，而是如果按照＃1687中的建议重新定义--debug可以的话，则是一个解决方案。）

+1以在-debug模式下保留失败的构建上的工件。

我已经使用补丁运行打包程序一段时间了，但是从来没有理由在没有-debug情况下启动它。 我想知道是否应该发布二进制文件以进行更广泛的测试。

+1

我刚刚注意到，我发布的链接是针对多步骤的补丁程序，而不是针对打包程序的补丁程序。 使用-debug运行时使打包程序因错误而暂停的修复程序位于https://github.com/orivej/packer/tree/debug-on-error

@orivej如果要测试您的无破坏行为补丁，应该从哪个补丁开始？ https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840吗？

是的，只有一次提交，即orivej @ a713a46。 仍然可以完全将其重新建立为master。
您还需要从https://github.com/mitchellh/multistep/pull/5获得github.com/mitchellh/multistep的补丁，否则打包程序将在破坏了最后一步后暂停。

@orivej您是否有OSX的修补二进制文件？ 在构建Gentoo Linux机器时由于一个小错误而重新启动整个构建过程非常麻烦（非常耗时）。 对于我来说，必须在发生故障后装入盒子并找出问题所在。

我添加了一个选项来重试失败的步骤，而不是中止操作，尽管即使成功，整个构建也可能会失败。 并且，如果我没有犯错，那么打包程序将无法可靠地处理输入，并且用户可能不得不多次响应。

此更改不依赖于修补的多步操作，而是驻留在分支，提交中。

我在这里上传了二进制文件： https : debug-on-error-2 ）。

对于我来说，必须在发生故障后装入盒子并找出问题所在。

我的补丁程序没有保留可装载的盒子，而是在您手动终止构建之前使当前盒子保持活动状态，以便您可以SSH进入它并执行调试（当使用-debug调用packer时） -debug选项）。

感谢您的反馈，@ orivej。

我的补丁程序没有保留可以加载的框，而是使当前框保持活动状态，直到您手动终止构建，以便可以SSH进入其中并执行调试（使用-debug选项调用packer时）。

注意，默认的打包器构建（带有--debug ）在环境被破坏之前暂停，从而为您提供了如所描述的对其进行调试的选项。 为此，我使用"headless": false 。 您的补丁程序有何不同？

• 它使打包程序仅在某个步骤失败后才暂停，而不是在每个步骤之后都暂停。
• 在失败的步骤之后，它在打包程序清理之前暂停。 （尽管我不记得为什么需要这样做，因为最有问题的配置步骤不会进行任何清理。）
• 修补程序的第二版允许重试失败的步骤。 （当供应失败时，将重新运行所有供应商。）

我刚刚注意到，＃2608做出了一个不幸的决定，将插件从旧版本的Packer优先考虑到较新的内置插件，因此要使用我的Packer版本（或Packer的未来版本，除非作者重新考虑此行为），您需要删除所有名称以packer-开头的二进制文件。

不可靠的输入处理也是＃2608的伪影，我看看是否可以解决。

输入处理不可靠是由内置插件的额外初始化引起的，尤其是main.go的setupStdin() main.go 。 由于此调用似乎仍然无法满足其声明的目的，因此我能够在没有影响的情况下将其禁用，并重建了我的二进制文件。

简单地能够退出打包程序而不会因错误而停止或破坏VM，将非常有用。 这在通常包含最自定义逻辑的供应组件中尤其重要。 能够通过SSH进入包装盒并重新运行原始脚本，或者尝试使用经过修改的脚本或配方进行测试，可以快速而有价值地洞悉是什么真正导致了错误以及如何修复。 进行整个打包程序构建非常耗时，即使是最简单的故障排除也需要它。

-debug标志很有用，但是它使该过程变得非常手工。 通常，运行无人值守的构建很有用，但是遇到错误时退出并使其处于允许调查原因并修复的状态。

：+1：无论-debug通过还是失败，都应该有一个选项使实例保持运行，以便您可以在实例上重播脚本/调试等。除非这以某种方式干扰了捕获AMI映像。

+1

+1 ..令我惊讶的是大约2.5年后，它是如此有用。 这将使我的生活变得更加轻松，对我的Packer构建进行故障排除。

通过在厨师客户端启动之前在实例上使用终止保护，我能够在AWS上克服这一问题。 这不是一个不错的选择，但是嘿，它可行。 任何其他选项：）

+500-为什么还没有此功能？

也许我们作为开发人员可以尝试弄脏我们的手，而不是抱怨？

功能请求再简单不过了。

• 读取新的命令行选项（ --no-destroy-on-error ）
• 在正确的位置添加一个不起眼的if 。 伪代码：

unless no_destroy_on_error # add this conditional <<<<<<<<<
   perform_cleanup
end

我会试一下。 而且，如果可行，我不会分享（主要是为了避免假设的要求/投诉）。 努力是一件好事。

@vemv ，我已经通过在https://github.com/orivej/packer/commits/debug-on-error-2上的两次提交基本上解决了这个问题

@orivej太棒了！ 我一直在计划添加--pause-on-error ，我认为这是最好的方法（当某个步骤失败后，请先等待击键，然后再进行清理，以允许用户登录并进行故障排除。）。

您可以使用您的代码打开PR，我们可以在那里讨论详细信息。
CC @cbednarski

@vemv我已经关注这个问题几年了。 我只能为自己说话，但我真的一点都不了解Go，至少不知道弄清楚代码可能会做什么。 我不愿意为Packer等广泛使用的东西编写代码，更不用说对其进行适当的测试了。

@orivej和@ rickard-von-essen，任何需要用户输入的内容都不适合我，因为我只在自动工具中使用Packer（例如Jenkins或TravisCI）； 我知道我也有很多其他人。 我认为我真正想要的是（1）可能会增加输出的详细程度，并且（2）只是让源计算机（无论是EC2，VMWare还是其他设备）运行，以便人类可以在工作失败。

当前，调试将在步骤之间暂停，要求您按Enter键才能继续，因此，只要您知道要失败的步骤，就只能将VM“保留”在此处以进行调试，但这显然不那么理想。 您确实希望模板经过每个步骤，以便您可以检查完全失败的状态。

只需添加我的：+1:。 我真的可以使用此功能。

@ jantman我将在进程失败并且无法获取输入时（例如，使用/dev/null输入）使packer -debug跳过清理。 请注意，打包程序的运行顺序是基于以下想法：每个步骤之后都可以清理，因此突然终止会使系统处于打包程序可能无法自行处理的状态（例如，它将抱怨输出目录已经存在），因此您应该期望找出如何使过程可重复的方法，但这很容易。

@ rickard-von-essen我将更新我的补丁（添加新的提供程序）并在今天晚些时候发出请求请求。

从@DarwinJS在https://github.com/mitchellh/packer/issues/3445#issue -148713866

我正在AWS上构建Windows框，并将ebs卷“ delete_on_termination”设置为false，因此在构建失败后，我可以[a]附加该卷，[b]启动实例，[c]查看它的日志，[d]关闭实例，[e]分离卷，[f]手动删除该卷。

我注意到c:\windows\temp<guid>.out文件包含我运行的Powershell配置程序的控制台输出。

获得此输出是我必须采取所有这些额外步骤来获取此信息的唯一原因。

如果Packer支持PACKER_CONSOLE_LOGS_COPY=$env:temp以便始终可以将这些日志带回（尤其是最后一个失败的日志），并且我可以避免执行额外的步骤，那将是很好的。

对于那些分享我的目标，即编译最新的packer开发版本，同时又集成了orivej的早期修复程序（在Packer构建首次失败时暂停）的人，这里是我采取的措施。

Complete "Setting up Go to work on Parker" steps 1-4 . ( see https://github.com/mitchellh/packer/blob/master/CONTRIBUTING.md )
git checkout master
git remote add fork https://github.com/orivej/packer
git fetch fork
git checkout -b debug-on-error fork/debug-on-error
git merge debug-on-error
make
run ./bin/packer build -debug template.json

我可以确认这对我有用，并且仅在出现错误时才暂停供应。

我无法成功合并https://github.com/orivej/packer/tree/debug-on-error-2。

我很好奇，我对Packer和git还是这个问题还很陌生； 人们还有其他方法来实现orivej的修复程序吗，然后是我所描述的方法？ 我可能会遗漏一些非常明显的东西，因此，如果是这种情况，请提示我。

只需检查此问题的状态即可。

是@orivej的更改解决了此问题，需要发出请求吗？ 还是仍然需要解决？

+1

这将非常有用，现在我正在使用带有sleep 1800的嵌入式外壳程序来保持vm的生命。
请尽快实施：）

Imho -debug正在做我们所有需要的工作。 在执行每个命令后，您需要按Enter键继续下一个命令。 不输入= vm live :)

@noose-我不坐下来观察构建-有一些运行时间很长的部分（例如安装SQL Server），我不想让它持续供用户输入。 我想开始一个测试版本，当我回到测试版本时，便可以轻松地进行调试。

恕我直言，-debug完全没有用。 我正在运行复杂的构建，我真的没有耐心按Enter键数千次，直到遇到问题为止。
我真的不明白为什么如此难以实现的功能如此难以实现。

@ henris42虽然我在这种情况下同意-debug的无用性，但如果看起来像是不费吹灰之力，那么为什么不按要求就放弃呢？

@noose ，我使Jenkins作业中的
我认为这是DevOps世界中的常见情况：）

似乎每个人都需要这个。 构建这些AMI容易出错，此功能将减少故障排除的时间

我同意@worstadmin。 在构建Vagrant盒子的情况下，您可以从多个角度解决问题（例如，保持虚拟机不动，使用null Provisioner进行尝试，等等），而Amazon映像是一个特殊品种，如果有这样的情况，则很难调试一个问题。

与https://github.com/mitchellh/packer/issues/1687结合使用，效果会很好。

此外，忽略供应者的错误并让其继续进行通常是有帮助的，特别是在映像开发的早期阶段等。

大约3年后...仍然几乎没有。 最近几天，我花了很大的力气在键盘上尝试做复杂的Windows构建，该构建任意随机地失败了无输出的Powershell脚本执行，并且由于自动清理，我无法跳入实例。 当我在启用-debug的情况下运行时，由于要求手动输入而引入的额外“暂停”似乎不会发生此问题。 您会认为这有意义，我只是在我的Powershell脚本中添加了大量睡眠来模拟这一点，但这没有帮助。

甚至不撒谎，如果有人可以认真地制作一个---不会破坏错误的功能，并为此争取到PR，我将向Paypal奖励100美元的赏金。 我（似乎还有数百个其他人）需要此功能，尤其是考虑到打包程序通常考虑到自动化（通过CI / CD / etc）使用时。 这就是我的长+1和辩护。

嘿，对于shell配置器可能有解决方法，不过我对其他配置器一无所知。 ：crying_cat_face：

我今天几乎可以正常工作了，但是学习Go我不知道我会进入元编程地狱，再次通过几个文件来追踪接口以找到实现:(

在＃3885上查看我当前的建议，对我来说已经很不错了！

@tmartinx ：

我正在尝试使用Ansible运行它，但是它不起作用，并且KVM guest虚拟机在错误发生后就消失了，因此，不可能去那里查看问题所在...

作为解决方法，直到有一个包含＃3885的新包装器版本：

    {
      "type": "shell",
      "inline": [
...
        "ansible-playbook ... || (echo \"*** FAILED WITH CODE $? *** Hit Ctrl-C to terminate\"; sleep 14400; exit 1)"
        ]
    }

然后，您有4个小时可以切换到仍在运行的VM中并四处闲逛。

这到底是怎么回事？

• Packer检测到VMware“未知错误”。
• _Packer_告诉我检查VMWare的日志文件以获取更多信息。 该日志应该位于输出目录中。
• 但是_Packer本身_删除了输出目录，因此我无法检查日志。 哈哈！ 好人，Packer，你这个混蛋！
• 显然，其他人的恶意攻击也遇到了类似的情况。
• 多年来，人们一直在要求看似非常简单，轻松的解决方案。
• 他们中的一些甚至决定尝试自己解决此问题。 似乎他们的补丁已被HashiCorp拒绝，或者只是失败了。
• 无论哪种方式，HashiCorp都保持无线电沉默。 看来他们永远都不会解决此问题。

我们是否可以得出结论，美国政府已下令堵截HashiCorp，并告诉他们不要解决此问题？

我很难提出其他解释。

我给人的印象是，HashiCorp的工具总体上是DevOpsy的好选择，但是现在我有了第二个想法。 说真的我们是否都在这里缺少明显的东西，还是HashiCorp只是超级阴暗？

关闭此票证的原因是因为该问题已得到解决。

在命令行中添加标志-on-error=ask ，然后如果出现错误，系统将提示您是否要删除构建工件。

此外，在回答此问题之前，您可以先进入虚拟机并四处闲逛。

@ peterlindstrom234 ，这已经实现。 您可以使用“ -on-error = abort”，并且发生错误时，打包程序不应该执行任何清除操作。

好吧，我的坏。 当然，它花了很长时间。

@ peterlindstrom234由于美国政府的堵截令花费了很长时间