Packer: -Vagrant와 같은 오류시 파괴 없음

이것은 합리적으로 들립니다. -debug 플래그가 실제로 여기에서 올바른 접근 방식이라고 생각하지만 -debug 플래그는 다음과 같은 옵션을 허용해야합니다.

• 모든 단계를 거쳐
• 오류가 발생할 때까지 계속
• 정리 단계가 시작될 때까지 계속

오류가 발생할 때까지 계속하고 VM을 매우 유용하게 파괴하지 않는 옵션을 찾을 수 있습니다.

누군가가 이것을 구현하기 시작할 곳에 대한 포인터를 줄 수 있다면 이것을 옵션으로 추가하는 데 시간을 할애 할 수 있습니다

이것은 나에게도 매우 유용 할 것입니다.

@timmow 특정 플래그가 설정된 경우 아무것도하지 않도록 각 빌더의 인스턴스 생성 정리 단계를 수정해야 할 수 있습니다 (예 : https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go). # L122)

모든 단계를 검토하고 아무 조치도 취하지 않는 것이 적절한 위치를 파악하는 것은 일정량의 작업이 될 것입니다.

내가 방금 가진 아이디어는 정리 단계를 처리하기 전에 사용자 입력을 기다리는 플래그를 제공하는 것입니다. 그런 식으로 디버깅을 수행하고 예를 들어 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 커밋으로 해결되었지만 마스터 브랜치의 HEAD에 변경 사항이 표시되지 않습니다. 어디에서 왜 사라 졌습니까?

이것도 정말 필요합니다.

이 기능에 대한 희망이 있습니까? 2ed7c3f 또는 일부 변형을 병합하려면 어떻게해야합니까?

예,이 옵션을 사용할 수도 있습니다. 나는 그것이 저질러졌지만 사라진 것을 봅니다.

이것에 대한 업데이트가 있습니까?

나도 정말 좋아할 것입니다. 문제를 디버깅하는 데 얼마나 많은 시간을 낭비했는지 알 수 없으며 오류가 계속 발생하기 위해 긴 VM 생성 프로세스를 거쳐야합니다. VM을 유지하는 것은 큰 승리가 될 것입니다.

이 기능 (또는 유사한 기능)이 메인에 병합 될 때 ETA가 있습니까? Packer를 사용하여 Visual Studio가 기본 Vagrant 상자의 일부로 설치된 VM을 빌드하려고 시도하고 있으며 단계가 실패한 이유를 살펴보기 전에 VM을 파괴하지 않는 것이 정말로 필요합니다. --debug를 통해 각 단계를 확인하는 것은 허용되지 않습니다.

-debug 옵션은 제가 분석하려는 실패를 억제하기 때문에 이것에 대한 또 다른 투표입니다.

실패하기 전에 머신의 최종 상태를 디버깅하는 데 너무 많은 시간을 할애합니다. -debug 스위치는 그것을 자르지 않습니다. 정상적인 프로세스를 실행하고 실패 후 작업 폴더를 그대로 두어 로그 및 상태로 진단 할 수 있기를 바랍니다. 일종의 보존 작업 상태 전환을 기대합니다.

이 기능에 대한 또 다른 +1은 대단히 도움이 될 것입니다.

+1 최종 상태를 디버그하고 일부 프로비저닝 스크립트를 조정 한 다음 빌드를 다시 실행하여 디버그 단계에서 수동으로 Enter 키를 누르는 대신 프로세스가 수정되었는지 확인하는 것이 좋습니다.

이 기능에 대한 또 다른 + 1입니다. 무슨 일이 일어 났는지 아는 것이 좋을까요? 팀에서 아무도 대답하지 않았습니다. 아프지 않은 접시까지 한 걸음 나아가십시오. LOL! 저는 Packer를 처음 접했습니다. 나는 1.5 시간의 ISO 빌드 끝에 있었는데 이런 일이 일어났습니다. 테스트와 디버깅은 완전히 멋진 애플리케이션을 전체 스트림으로 가져 오는 데 가장 중요합니다.

여기서도 +1하면 헤드리스 이미지를 생성하므로 --debug를 사용하려면 수동 단계를 거쳐야하는 것은 좋지 않지만 결함이있는 이미지를 검사 할 수 있으면 좋을 것입니다.

: +1 : 저도이 기능을 갖고 싶어요

+1이 기능은 훌륭 할 것입니다!

# 1687과 관련이 있거나 중복되었을 수 있음

+1 @error 를 삭제하지 않고 VM을 그대로 둘 수 있다는 것은 매우 유용 할 것입니다. 우리의 설치 스크립트는 현재 시스템에서 상당히 길고 많은 단계를 거치고 있습니다 .. :(

+1 이것은 매우 유용합니다

Packer 로만 실패 할 때 프로비저닝 디버그를 돕기 위해 +1

+1 나는 같은 배에 있습니다. 프로비저닝 단계에서 Chef 오류가 발생하기 위해 Windows VM을 다시 만드는 데 엄청난 시간을 보냈으며 VM이 삭제 될 때 디버깅 할 방법이 없습니다. 실패 중에 모든 것을 삭제하지 않는 옵션이 있도록 두십시오.

이 문제가 2 년 동안 살아있는 것을 본 후에는이 문제가 해결 될 것이라는 희망이 없습니다. 나는 정말로 Packer를 좋아하려고 노력하고 있지만 실제로 결과를 사용하는 것보다 빌드 단계를 기다리는 데 더 많은 시간을 소비하게됩니다.

Pleeeeeaseeeeeee +1

+1

+1

+1

이것에 대한 주장이 무엇인지 궁금해서 Google을 통해이 문제를 발견했습니다. 기능이 존재하지 않았을 때 슬퍼했습니다.

안녕하세요, 개발자 여러분,이 스레드를 다시 방문하여 패커를 계속 효과적으로 사용할 수 있었지만이 버그는 시스템 개발을 심각하게 느리게합니다. 우리는 할 수 있지만 직원이 @mitchellh 문제에 대한 지침을 제공 할 수 있다면 진심으로 좋을 것입니다. 제가 올바른 방향을 제시 할 수 있다면 해결책을 제시 할 시간이있을 수도 있지만, 귀하의 답변이나 귀하의 팀원이 바라기를 기다릴 것입니다. 그래도 놀라운 도구에 감사드립니다. 나는 당신과 당신의 팀이 내가이 제품이 얼마나 멋진 지 알고 있기를 바랍니다.

내가 원했던 기능에 대한 모든 +1 이메일 알림에 지 쳤기 때문에 ;-), 코드베이스를 파헤 치고 초기 구현을 추가했습니다. 참고-이것은 아직 테스트되지 않았으며 제대로 작동하는지조차 모르겠습니다. 소스에서 빌드하려고하면 Packer가 github에서 자체 참조하는 흥미로운 문제가 발생하여이 코드가 제대로 빌드되지 않습니다. GoPath의 패커 소스 폴더를이 저장소를 다운로드 한 폴더에 임시로 연결해야합니다 (또는 풀 요청을 테스트하고 제출할 때까지 기다려야합니다).

https://github.com/jcoutch/packer

이것이 기본 행동이 아니라는 사실은 내 프랑스어를 용서한다면 완전히 미친 것입니다. 설치 스크립트에 오타가 있습니까? 글쎄, 당신의 모든 일을 편리하게 _ 파괴하고 당신의 인생의 그 시간을 결코 돌려주지 마십시오. 위에. 그리고 끝났습니다. 다시._

나는 _ 말 그대로 모든 사람이이 도구를 가장 단순한 예를 넘어서서 사용하는 것이 _ 사용할 때마다 _이 문제를 겪고 있다고 생각합니다. 분명히이 기능에 대한 엄청난 수요가 있지만 2 년 후에도 아직 구현되지 않았습니다.

절대적으로 비틀 거리다.

+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.

Pleeeease !! :-디

Ansible로 실행하려고하는데 작동하지 않고 KVM 게스트가 오류 후 사라졌기 때문에 무엇이 잘못되었는지 확인하기 위해 그곳으로 이동할 수 없습니다.

건배!

많이 필요합니다. 감사.

더 쉬운 검토를 위해 적절한 줄 끝이있는 @jcoutch 패치가 있습니다 : https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

이 패치는 전처리 기가 실패하는 경우에만 삭제를 방지하고 빌더 (프로 비 저너 포함)가 실패 할 때 아티팩트를 유지하지 않습니다.

편집 : 의도 인 것 같지만 실제로는 쉽게 해결할 수 있지만 실제로는 아무것도하지 않습니다.

예,이 스레드에 답장 할 기회가 없었습니다. 나는 마침내 시도했다
떨어지는 프로 비져로 내 변경 사항을 ... 나처럼 작동하지 않습니다.
예정된. 코드를 자세히 살펴보면 빌더가
프로비저닝 실패시 아티팩트 삭제 ... 코드 대신
수정되었습니다.

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 를 재정의하는 것이 괜찮다면 해결책입니다.)

-debug 모드에서 실패한 빌드에 대한 아티팩트 보존에 +1.

나는 패치와 함께 한동안 packer를 실행 해 왔으며 -debug 없이는 시작할 이유가 없었습니다. 더 광범위한 테스트를 위해 바이너리를 게시해야하는지 궁금합니다.

+1

방금 게시 한 링크가 패커 용이 아니라 다단계 용 패치라는 것을 알았습니다. -debug 로 실행할 때 패커가 오류시 일시 중지하는 수정 사항은 https://github.com/orivej/packer/tree/debug-on-error에 있습니다.

@orivej 비파괴 동작 패치를 테스트 https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

예, 하나의 커밋 orivej @ a713a46이 있습니다. 여전히 마스터에 깔끔하게 리베이스 할 수 있습니다.
또한 https://github.com/mitchellh/multistep/pull/5 에서 github.com/mitchellh/multistep 대한 패치가 필요합니다. 그렇지 않으면 패커가 마지막 단계를 파괴 한 후 일시 중지됩니다.

@orivej OSX 용 패치 바이너리가 있습니까? 젠투 리눅스 박스를 빌드 할 때 작은 오류로 인해 전체 빌드 프로세스를 다시 시작하는 것은 엄청나게 고통 스럽습니다 (시간 소모적). 실패 후 상자를로드하고 무엇이 잘못되었는지 알아낼 수있는 가능성은 나에게 필수입니다.

중단하는 대신 실패한 단계를 다시 시도하는 옵션을 추가했습니다. 성공하더라도 전체 빌드가 실패 할 수 있습니다. 그리고 내가 잘못하지 않았다면, 패커는 입력을 안정적으로 처리하지 않으며 사용자는 여러 번 응답해야 할 수도 있습니다.

이 변경 사항은 패치 된 다단계에 의존하지 않으며 브랜치 , 커밋에 있습니다.

여기에 바이너리를 업로드했습니다 : https://orivej-packer.s3.amazonaws.com/index.html (서브 트리 debug-on-error-2 ).

실패 후 상자를로드하고 무엇이 잘못되었는지 알아낼 수있는 가능성은 나에게 필수입니다.

내 패치는로드 할 수있는 상자를 보존하지 않지만 대신 빌드를 수동으로 종료 할 때까지 현재 상자를 그대로 두어 SSH에 접속하여 디버깅을 수행 할 수 있습니다 ( -debug packer 호출시) -debug 옵션).

피드백 주셔서 감사합니다, @orivej.

내 패치는로드 할 수있는 상자를 보존하지 않고 대신 빌드를 수동으로 종료 할 때까지 현재 상자를 그대로 두어 SSH에 접속하여 디버깅을 수행 할 수 있습니다 (-debug 옵션으로 packer를 호출 할 때).

--debug 하는 기본 패커 빌드가 환경이 파괴되기 전에 일시 중지되어 설명한대로 디버그 할 수있는 옵션을 제공합니다. 이를 위해 "headless": false 합니다. 패치 프로세스가 얼마나 다른가요?

• 패커는 모든 단계 후에 일시 중지하는 대신 단계가 실패한 후에 만 ​​일시 중지합니다.
• 실패한 단계 후 패커가 정리하기 전에 일시 중지됩니다. (가장 문제가 많은 프로비저닝 단계에서 정리를 수행하지 않기 때문에 왜 이것이 필요한지 기억하지 못합니다.)
• 패치의 두 번째 버전에서는 실패한 단계를 다시 시도 할 수 있습니다. (프로비저닝에 실패하면 모든 프로 비저 너가 다시 실행됩니다.)

방금 # 2608이 이전 버전의 packer에서 최신 내장 플러그인으로 플러그인의 우선 순위를 지정하는 불행한 결정을 내렸으므로, 내 packer 빌드 (또는 작성자가이 동작을 다시 고려하지 않는 한 향후 버전의 packer)를 사용하려면 모두 제거해야합니다. 이름이 packer- 시작하는 바이너리.

신뢰할 수없는 입력 처리도 # 2608의 아티팩트이므로 수정할 수 있는지 살펴 보겠습니다.

신뢰할 수없는 입력 처리는 기본 제공 플러그인의 추가 초기화, 특히 main.go setupStdin() 로 인해 발생합니다. 이 호출은 어차피 선언 된 목적을 달성 할 수없는 것 같기 때문에 영향없이 비활성화 할 수 있었고 바이너리를 다시 빌드했습니다.

오류 발생시 VM을 중지하거나 파괴하지 않고 단순히 packer를 종료 할 수 있다는 것은 매우 유용합니다. 이는 일반적으로 가장 많은 사용자 지정 논리를 포함하는 프로비저닝 구성 요소에서 특히 중요합니다. 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 프로세스가 실패하고 입력을받을 수 없을 때 packer -debug 정리를 건너 뛸 것입니다 (예 : /dev/null 에서 입력). 패커 실행 시퀀스는 모든 단계가 나중에 정리 될 수 있고 정리 될 수 있다는 생각을 바탕으로 작성되었으므로 갑작스러운 종료는 패커가 자체적으로 처리 할 수없는 상태로 시스템을 남겨 둡니다 (예 : 출력 디렉토리에 대해 불평 할 것임). 이미 존재 함), 따라서 프로세스를 반복 가능하게 만드는 방법을 알아야하지만 이것은 쉬울 것입니다.

@ 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 와 같은 것을 지원하여 해당 로그를 항상 다시 가져올 수 있도록 (특히 실패한 마지막 로그) 추가 단계를 피할 수 있다면 좋을 것입니다.

패커 빌드의 첫 번째 실패에서 일시 중지되는 orivej 이전 수정을 통합하면서 최신 패커 개발 릴리스를 컴파일하려는 목표를 공유하는 사람들을 위해 여기에 제가 취한 단계가 있습니다.

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 alive :)

@noose- 나는 앉아서 빌드를 보지 않습니다-사용자 입력을 위해 유지하고 싶지 않은 매우 오래 실행되는 섹션 (SQL 서버 설치와 같은)이 있습니다. 테스트 빌드를 시작하고 다시 돌아 오면 최소한의 노력으로 디버깅 할 수있는 것이 있습니다.

IMHO the -debug는 완전히 쓸모가 없습니다. 저는 복잡한 빌드를 실행하고 있으며 문제가 발생할 때까지 Enter 키를 수천 번 누르는 인내심이 없습니다.
이처럼 쉬운 기능을 구현하기가 왜 그렇게 어려운지 이해하지 못합니다.

@ henris42 이 맥락에서 -debug 의 쓸모가 없다는 것에 동의하지만, 그렇게 생각할 필요가없는 것처럼 보이면 풀 리퀘스트를 해보는 건 어떨까요?

@noose , Jenkins 작업에서 패커 빌드를 자동화합니다 (Git에서 구성 / 스크립트 및 Ansible 플레이 북을 가져옴). 이러한 방식으로 packer를 사용하면 대화 형 모드가 유용하지 않습니다. 실패 후 분석이 훨씬 더 유용합니다.
저는 이것이 DevOps 세계에서 일반적인 시나리오라고 생각합니다. :)

모든 사람이 이것을 필요로하는 것 같습니다. 이러한 AMI를 구축하면 오류가 발생하기 쉬우 며이 기능을 사용하면 문제 해결에 소요되는 시간이 줄어 듭니다.

@worstadmin에 동의합니다. Vagrant 상자를 구축하는 경우 여러 각도에서 문제를 해결할 수 있습니다 (예 : 가상 머신 유지, null 프로비저닝 도구 사용 등). 이슈.

https://github.com/mitchellh/packer/issues/1687 과 결합하면 좋을 것입니다.

또한 프로 비져 너의 오류를 무시하고 특히 이미지 개발의 초기 단계 등에서 계속하는 것이 도움이됩니다.

거의 3 년이 지난 지금도 거의 아무것도 없습니다. 나는 지난 며칠 동안 키보드에 머리를 박아 넣고 복잡한 윈도우 빌드를하는데 보냈다. 출력없이 powershell 스크립트의 실행이 임의로 실패하고 자동 정리로 인해 인스턴스로 이동할 수 없다. -debug를 활성화 한 상태에서 실행할 때 수동 입력을 요구하여 추가 된 "일시 중지"로 인해이 문제가 발생하지 않는 것 같습니다. 이걸 시뮬레이션하기 위해 powershell 스크립트에 수면을 추가하는 것이 의미가 있다고 생각할 것입니다.

거짓말조차하지 않고, 누군가가 심각하게 오류시 파괴 방지 기능을 최대한 빨리 만들고 공을 PR에 올릴 수 있다면 Paypal 누군가에게 $ 100의 현상금을 지급 할 것입니다. 특히 패커가 일반적으로 자동화를 염두에두고 사용된다는 점을 고려할 때 (CI / CD 등을 통해)이 기능이 필요합니다. 그래서 여기 내 긴 +1과 간청이 있습니다.

쉘 프로 비 저너에 대한

나는 오늘 거의 작동했지만 Go를 배우면서 구현을 찾기 위해 여러 파일을 통해 인터페이스를 쫓아 다시 메타 프로그래밍 지옥에 갈 것이라는 것을 알지 못했습니다.

이미 나에게 잘 어울리는 # 3885에서 나의 현재 제안을 확인하십시오!

@tmartinx :

Ansible로 실행하려고하는데 작동하지 않고 KVM 게스트가 오류 후 사라졌기 때문에 무엇이 잘못되었는지 확인하기 위해 그곳으로 이동할 수 없습니다.

# 3885가 포함 된 새로운 패커 릴리스가 나올 때까지 해결 방법 :

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

그런 다음 4 시간 동안 여전히 실행중인 VM에 ssh하고 주변을 살펴볼 수 있습니다.

대체 무슨 일이 일어나고 있는거야?

• Packer가 VMware '알 수없는 오류'를 감지했습니다.
• _Packer_가 VMWare의 로그 파일에서 자세한 정보를 확인하라고했습니다. 로그는 출력 디렉토리에 있어야합니다.
• 하지만 _Packer 자체 _는 출력 디렉토리를 삭제하므로 로그를 확인할 수 없습니다. ㅋ! 잘 했어, 패커, 너 비난 해!
• 분명히 다른 사람들의 똥 부리는 비슷한 상황에 처해 있습니다.
• 사람들은이 문제에 대해 _ 수년 동안 _ 겉보기에 매우 간단하고 쉽게 해결할 것을 요청 해 왔습니다.
• 그들 중 몇 명은이 문제를 스스로 해결하기로 결정했습니다. 그들의 패치가 HashiCorp에 의해 거부되었거나 실패한 것 같습니다.
• 어느 쪽이든 HashiCorp는 무선 침묵을 유지했습니다. 그들은 이것을 고치지 않을 것 같습니다.

미국 정부가 HashiCorp에 개그 명령을 내렸고이 문제를 고치지 말라고 말 했나요?

대체 설명을 내놓는 데 어려움을 겪고 있습니다.

HashiCorp의 도구가 전반적인 DevOpsy 작업에 적합한 선택이라는 인상을 받았지만 이제 다시 생각하고 있습니다. 진지하게. 우리 모두 여기서 명백한 것을 놓치고 있습니까, 아니면 HashiCorp가 단지 매우 그늘진 것입니까?

이 티켓이 닫힌 이유는 문제가 이미 해결 되었기 때문입니다.

명령 줄에 -on-error=ask 플래그를 추가 한 다음 오류가있는 경우 빌드 아티팩트를 삭제할지 여부를 묻는 메시지가 표시됩니다.

또한이 질문에 답하기 전에 VM에 ssh를 입력하고 둘러 볼 수 있습니다.

@ peterlindstrom234 , 이것은 이미 구현되었습니다. "-on-error = abort"를 사용할 수 있으며 패커는 오류 발생시 정리를 수행하지 않아야합니다.

좋아, 내 잘못이야. 그래도 이상하게 오래 걸렸습니다.

@ peterlindstrom234 미국 정부의 개그 명령 때문에 시간이 오래 걸렸습니다.