Packer: --لا تدمر على خطأ مثل Vagrant

هذا يبدو معقولا. أعتقد أن علامة -debug هي بالفعل الطريقة الصحيحة هنا ، ولكن ربما يجب أن تسمح علامة -debug بخيارات مثل:

• خطوة من خلال كل خطوة
• استمر حتى ظهور خطأ
• استمر حتى تبدأ خطوات التنظيف

سأجد خيار الاستمرار حتى حدوث خطأ وعدم تدمير جهاز VM مفيدًا للغاية

إذا كان بإمكان شخص ما إعطائي بعض المؤشرات حول مكان البدء في البحث عن تنفيذ ذلك ، فقد أتمكن من تخصيص بعض الوقت لإضافة هذا كخيار

سيكون هذا مفيدًا جدًا بالنسبة لي أيضًا.

timmow ، قد تحتاج إلى تعديل خطوة تنظيف إنشاء مثيل كل باني حتى لا تفعل شيئًا إذا تم تعيين علامة معينة (على سبيل المثال https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go # L122)

سيكون قدرًا معينًا من العمل لتمشيط جميع الخطوات ومعرفة المكان المناسب لعدم اتخاذ أي إجراء.

كانت الفكرة التي خطرت لي للتو هي إعطاء علامة تنتظر إدخال المستخدم قبل معالجة أي خطوة تنظيف. بهذه الطريقة يمكنك إجراء تصحيح الأخطاء ، والضغط على Enter على سبيل المثال ، وسيتولى Packer التنظيف.

لا تتردد في الاتصال بي هنا إذا كان بإمكاني تقديم أي مساعدة.

لمعلوماتك التي تم إجراؤها بطريقة FILO هنا 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 سيكون بمثابة فوز كبير.

هل هناك ETA عندما يتم دمج هذه (أو وظيفة مشابهة) في main؟ محاولة استخدام Packer لإنشاء جهاز افتراضي مع تثبيت Visual Studio كجزء من صندوق Vagrant الأساسي ، وأنا حقًا في حاجة إليه لعدم تدمير الجهاز الظاهري قبل أن تتاح لي الفرصة للنظر في سبب فشل الخطوات. إن الاضطرار إلى الإقرار بكل خطوة عبر --debug أمر غير مقبول.

تصويت آخر لهذا الخيار ، لأن الخيار -debug يمنع الفشل الذي أحاول تحليله.

تهب الكثير من الوقت في محاولة تصحيح الحالة النهائية للجهاز قبل أن تفشل. لا يقطعها مفتاح -debug - أريد تشغيله من خلال العملية العادية ثم ترك مجلد العمل في لباقة بعد الفشل حتى أتمكن من التشخيص بالسجلات والحالة. أتطلع حقًا إلى نوع من الحفاظ على تبديل حالة العمل.

إجراء +1 آخر لهذه الميزة ، سيكون مفيدًا للغاية.

+1 مواجهة مشكلات مماثلة حيث سيكون من الجيد تصحيح أخطاء الحالة النهائية وتعديل بعض البرامج النصية للتزويد ثم تشغيل البنية مرة أخرى لمعرفة ما إذا كان ذلك قد أدى إلى إصلاح العملية ، بدلاً من الضغط يدويًا على إدخال في خطوة التصحيح.

+ 1 آخر لهذه الميزة. سيكون من الجيد معرفة ما حدث لهذا؟ لم يرد أحد من الفريق. المضي قدما تصعد إلى اللوحة لا تؤذي. هههه! أنا جديد تمامًا على باكر. كنت في نهاية إصدار ISO لمدة 1.5 ساعة وحدث هذا. يجب أن يكون الاختبار وتصحيح الأخطاء أمرًا بالغ الأهمية لجلب التدفق الكامل للتطبيق الرائع تمامًا.

+1 هنا أيضًا ، نقوم بإنشاء صورنا بدون رأس ، لذا فإن وجود - يتطلب تصحيح الأخطاء يدويًا لا يفيدنا ، ولكن القدرة على فحص الصورة المعيبة سيكون أمرًا رائعًا.

: +1: أحب هذه الميزة أيضًا

+1 ستكون هذه الميزة رائعة!

ذات صلة أو ربما تتكرر بواسطة # 1687

+1 لمجرد أن تكون قادرًا على ترك الجهاز الظاهري كما هو دون حذف @ error ، فسيكون ذلك مفيدًا للغاية. نصوص التثبيت لدينا طويلة جدًا ، والكثير والكثير من الخطوات مع النظام الحالي .. :(

1+ هذا سيكون مفيدًا جدًا

+1 للمساعدة في تصحيح أخطاء التوفير عند الإخفاق فقط مع Packer

+1 أنا في نفس القارب. لقد أمضيت ساعات لا حصر لها في إعادة إنشاء أجهزة Windows الافتراضية ، فقط لوجود خطأ Chef في خطوة التزويد ، ولا توجد طريقة لتصحيح أخطاء الجهاز الظاهري عند حذفه. فقط يرجى السماح بوجود خيار لعدم حذف كل شيء أثناء الفشل.

بعد رؤية أن هذه المشكلة ظلت على قيد الحياة لمدة عامين ، ليس لدي أي أمل في أن يتم إصلاح ذلك. أحاول حقًا الإعجاب بـ Packer ، لكن انتهى بي الأمر بقضاء المزيد من الوقت في انتظار خطوة الإنشاء بدلاً من استخدام النتائج فعليًا.

Pleeeeeaseeeeeee +1

+1

+1

+1

تساءلت ما هي الحجة لهذا ، وجدت هذه المشكلة عبر جوجل. حزنت عندما لم تكن الميزة موجودة.

مرحبًا بالمطورين ، لقد أعدت النظر في هذا الموضوع وأقول أنه آمن بينما تمكنت من الاستمرار في استخدام Packer بشكل فعال ، فإن هذا الخطأ الوحيد يبطئ بشكل خطير تطوير أنظمتنا. يمكننا القيام بذلك ، ولكن سيكون من الجيد بصدق أن يقدم الموظف بعض الإرشادات حول هذه المشكلة @ mitchellh. قد يكون لدي الوقت حتى للمساهمة في حل إذا كان من الممكن توجيهي في الاتجاه الصحيح ، لكني سأنتظر ردك أو شخص ما في فريقك على أمل. شكرا على الأداة الرائعة بالرغم من ذلك. بالتأكيد أريدك أنت وفريقك أن تعرفوا مدى روعة هذا المنتج على ما أعتقد.

نظرًا لأنني تعبت من جميع إشعارات البريد الإلكتروني +1 لميزة أردتها أيضًا ؛-) ، بدأت في البحث في قاعدة التعليمات البرمجية وأضفت تنفيذًا أوليًا. ملاحظة - لم يتم اختبار هذا حتى الآن ... ولا أعرف حتى ما إذا كان سيعمل بشكل صحيح. إذا حاولت إنشائه من المصدر ، فقد واجهت مشكلة مثيرة للاهتمام مع Packer للإشارة الذاتية نفسها من github ، مما سيؤدي إلى عدم إنشاء هذا الكود بشكل صحيح. ستحتاج إلى ربط مجلد مصدر الحزم مؤقتًا في GoPath بالمجلد الذي قمت بتنزيل الريبو إليه (أو انتظر حتى أقوم باختبار وإرسال طلب سحب.)

https://github.com/jcoutch/packer

حقيقة أن هذا ليس السلوك الافتراضي ، إذا كنت ستعذر عن لغتي الفرنسية ، هو أمر مجنون تمامًا. ارتكبت خطأ مطبعي في نص التثبيت الخاص بك؟ حسنًا ، دعنا ببساطة - ندمر كل عملك ولن نعيد لك تلك الساعة من حياتك أبدًا. على. وأكثر. مرة أخرى._

أتخيل أن - حرفياً كل شخص - يستخدم هذه الأداة لأي شيء يتجاوز أبسط الأمثلة يواجه هذه المشكلة _في كل مرة يستخدمونها_. من الواضح أن هناك طلبًا كبيرًا على هذه الميزة ، ومع ذلك لم يتم تنفيذها بعد ، بعد عامين.

مذهل للغاية.

+1

يا رجل ، كان هذا تعليقًا سخيفًا. الحالة المزاجية السيئة بالأمس ، ولكن كل هذا الوقت بدأ يكلف الكثير من الوقت والمال.

jcoutch - هل لديك تصميم يمكنك مشاركته؟

لدي نظام OSX على جهازي ، ولم تتح لي الفرصة لاختبار ما إذا كان
يعمل حتى الان. أعمل على هذا في وقت فراغي ... الذي لم يكن لدي الكثير لأفعله
قطع في الآونة الأخيرة. ناهيك عن أن هذه هي تجربتي الأولى مع Go (تمامًا
لغة مثيرة للاهتمام.) سأحاول اختبارها بحلول نهاية هذا الأسبوع ،
وإذا كان كل شيء يبدو جيدًا ، فسأرسل طلب سحب. سأحاول أيضا
ما بعد OSX و Windows يبني للآخرين للاختبار بمجرد أن أعرف أنه مستقر.

في يوم الأربعاء ، 23 سبتمبر ، 2015 ، 5:14 مساءً كتب Rich Jones [email protected] :

يا رجل ، كان هذا تعليقًا سخيفًا. مزاج سيء أمس ، لكن كل هذا الوقت
بدأ الهزال يكلف الكثير من الوقت والمال.

jcouth - هل لديك تصميم يمكنك مشاركته؟

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

بلييز !! :-د

أحاول تشغيله باستخدام Ansible ولكنه لا يعمل وذهب ضيف KVM بعد الخطأ ، لذلك لا يمكن الذهاب إلى هناك لمعرفة الخطأ ...

في صحتك!

هناك حاجة ماسة. شكر.

إليك تصحيح jcoutch مع نهايات الأسطر المناسبة لمراجعة أسهل: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

يمنع هذا التصحيح الحذف فقط في حالة فشل المعالجات التمهيدية ، ولا يحتفظ بالعناصر الأثرية عند فشل المنشئ (مع مزوديه).

تحرير: يبدو أن هذا هو الهدف ، لكنه في الواقع لا يفعل شيئًا ، على الرغم من أنه يمكن إصلاحه بسهولة لتحقيقه.

نعم ، لم تتح لي الفرصة للرد على هذا الموضوع. حاولت أخيرًا
خارج التغييرات التي أجريتها باستخدام مزود احتياطي ساقط ... لا يعمل مثلي
مقصود. بالنظر بشكل أعمق إلى الكود ، يبدو أن منشئ المقابض
حذف القطع الأثرية عند فشل التزويد ... بدلاً من الكود الأول
تم التعديل.

في السبت ، 3 أكتوبر 2015 ، 9:37 صباحًا كتب Orivej Desh [email protected] :

هنا jcoutch https://github.com/jcoutch patch بخط مناسب
نهايات لمراجعة أسهل: 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. (هذا ليس إثباتًا للمفهوم ولكنه حل إذا كان إعادة تعريف --debug كما هو مقترح في # 1687 أمرًا مقبولاً.)

+1 للاحتفاظ بالقطع الأثرية في بناء فاشل في وضع -debug.

لقد كنت أقوم بتشغيل packer لفترة من الوقت مع التصحيح ، ولم يكن لدي سبب لبدء تشغيله بدون -debug . أتساءل عما إذا كان ينبغي أن أنشر ثنائيات لاختبار أوسع.

+1

لقد لاحظت للتو أن الرابط الذي نشرته كان عبارة عن تصحيح متعدد الخطوات ، وليس للتعبئة. الإصلاح الذي يجعل Packer يتوقف مؤقتًا عند الخطأ عند التشغيل بـ -debug على https://github.com/orivej/packer/tree/debug-on-error

orivej ما هو التصحيح الذي يجب أن أبدأ به إذا كنت أرغب في اختبار رقعة سلوك عدم التدمير؟ https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ؟

نعم ، هناك التزام واحد ، orivej @ a713a46. لا يزال من الممكن إعادة تأسيسه بشكل نظيف على المستوى الرئيسي.
تحتاج أيضًا إلى تصحيح لـ github.com/mitchellh/multistep من https://github.com/mitchellh/multistep/pull/5 ، أو سيتوقف packer مؤقتًا بعد تدمير الخطوة الأخيرة.

orivej هل لديك ثنائي مصحح لـ OSX؟ إعادة تشغيل عملية الإنشاء بأكملها بسبب خطأ بسيط عند إنشاء صندوق Gentoo Linux أمر مؤلم للغاية (يستغرق وقتًا طويلاً). امتلاك إمكانية تحميل الصندوق بعد الفشل ومعرفة الخطأ أمر لا بد منه.

أضفت خيارًا لإعادة محاولة الخطوة الفاشلة بدلاً من الإجهاض ، على الرغم من أن هذا قد يفشل بشكل عام حتى إذا نجح ذلك ؛ وإذا لم أخطئ ، فلن يقوم برنامج Packer بمعالجة المدخلات بشكل موثوق ، وقد يضطر المستخدم إلى الرد عدة مرات.

لا يعتمد هذا التغيير على خطوات متعددة مصححة ويعيش في فرع ، يلتزم .

لقد قمت بتحميل ثنائيات هنا: https://orivej-packer.s3.amazonaws.com/index.html (الشجرة الفرعية debug-on-error-2 ).

امتلاك إمكانية تحميل الصندوق بعد الفشل ومعرفة الخطأ أمر لا بد منه.

لا يحتفظ التصحيح الخاص بي بالمربع الذي يمكن تحميله ، ولكنه بدلاً من ذلك يترك المربع الحالي على قيد الحياة حتى تقوم بإنهاء الإنشاء يدويًا ، بحيث يمكنك SSH فيه وإجراء تصحيح الأخطاء (عند استدعاء packer بـ -debug option).

شكرا لملاحظاتك ،orivej.

لا يحتفظ التصحيح الخاص بي بالمربع الذي يمكن تحميله ، ولكنه بدلاً من ذلك يترك المربع الحالي على قيد الحياة حتى تقوم بإنهاء الإنشاء يدويًا ، بحيث يمكنك SSH فيه وإجراء تصحيح الأخطاء (عند استدعاء packer مع خيار -debug).

لاحظت أن إنشاء الحزم الافتراضي ، مع --debug ، يتوقف مؤقتًا قبل أن يتم تدمير البيئة مما يمنحك خيار تصحيحه كما وصفته. للقيام بذلك ، استخدم "headless": false . ما مدى اختلاف العملية مع التصحيح الخاص بك؟

• لا يتوقف برنامج Packer مؤقتًا إلا بعد فشل إحدى الخطوات ، بدلاً من التوقف مؤقتًا بعد كل خطوة.
• يتوقف مؤقتًا قبل أن يقوم باكر بالتنظيف بعد الخطوة الفاشلة. (على الرغم من أنني لا أتذكر لماذا احتجت إلى ذلك ، نظرًا لأن خطوة التوفير الأكثر إشكالية لا تؤدي إلى أي تنظيف.)
• يسمح الإصدار الثاني من التصحيح بإعادة محاولة الخطوة الفاشلة. (عند فشل التوفير ، يؤدي هذا إلى إعادة تشغيل جميع الموفرين.)

لقد لاحظت للتو أن # 2608 اتخذ قرارًا مؤسفًا لإعطاء الأولوية للمكونات الإضافية من الإصدار الأقدم من Packer إلى الإضافات المضمنة الأحدث ، لذلك لاستخدام تصميمي من Packer (أو الإصدارات المستقبلية من Packer ، ما لم يعيد المؤلفون النظر في هذا السلوك) ، فأنت بحاجة إلى إزالة الكل الثنائيات التي تبدأ أسماؤها بـ packer- .

تعتبر معالجة المدخلات غير الموثوق بها أيضًا من القطع الأثرية # 2608 ، وسأرى ما إذا كان بإمكاني إصلاحها.

تنتج معالجة الإدخال غير الموثوق بها عن التهيئة الإضافية للمكونات الإضافية المضمنة ، على وجه الخصوص بواسطة setupStdin() في main.go . نظرًا لأن هذه المكالمة تبدو غير قادرة على خدمة الغرض المعلن على أي حال ، فقد تمكنت من تعطيلها دون تداعيات ، وإعادة بناء ثنائياتي.

إن مجرد القدرة على الخروج من الحزم دون إيقاف الجهاز الظاهري أو تدميره عند حدوث خطأ ، سيكون مفيدًا للغاية. هذا مهم بشكل خاص في مكونات التوفير التي تحتوي عادةً على المنطق الأكثر تخصيصًا. يمكن أن توفر القدرة على SSH في صندوق وإعادة تشغيل النص الأصلي أو تجربة برنامج نصي أو وصفة معدلة للاختبار رؤى سريعة وقيمة حول سبب الخطأ بالفعل وما هو الإصلاح. يستغرق إنشاء حزمة كاملة وقتًا طويلاً جدًا لطلبه حتى لأبسط عملية استكشاف الأخطاء وإصلاحها.

تعتبر علامة -debug مفيدة ، ولكنها تجعل العملية يدوية بدرجة كبيرة. في كثير من الأحيان ، يكون من المفيد تشغيل بنية غير مراقبة ، ولكن اجعلها تخرج عندما تواجه خطأ وترك النظام في حالة تسمح بالتحقيق في السبب والإصلاح.

: +1: بغض النظر عما إذا كان -debug يمر أو يفشل ، يجب أن يكون هناك خيار للحفاظ على تشغيل المثيل حتى تتمكن من إعادة تشغيل البرامج النصية / تصحيح الأخطاء على المثيل وما إلى ذلك ما لم يتداخل هذا بطريقة ما مع التقاط صورة AMI.

+1

+1 .. أنا مندهش من أن هذا سيكون بعد حوالي 2.5 سنة لأنه سيكون مفيدًا جدًا. هذا سيجعل حياتي أسهل كثيرًا في استكشاف أخطاء بنية Packer الخاصة بي.

لقد تمكنت من التغلب على ذلك على AWS باستخدام حماية الإنهاء في المثيل قبل أن يبدأ chef-client. إنه ليس خيارًا لائقًا ولكنه يعمل. أي خيارات أخرى :)

+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 لقد كنت

orivej و @ rickard-von-essen ، أي شيء يتطلب إدخال المستخدم لا يناسبني حقًا ، لأنني لا أستخدم سوى Packer في الأدوات الآلية (مثل Jenkins أو TravisCI) ؛ أعلم أن هناك الكثير من الأشخاص الآخرين في منصبي أيضًا. أعتقد أن ما أريده حقًا هو شيء (1) ربما يزيد من الإسهاب في الإخراج ، و (2) يترك الجهاز المصدر (سواء كان EC2 أو VMWare أو أيًا كان) يعمل حتى يتمكن الإنسان من فحصه بعد فشلت الوظيفة.

سيتوقف تصحيح الأخطاء حاليًا بين الخطوات ، مما يتطلب منك الضغط على مفتاح الإدخال للمتابعة ، وطالما أنك تعرف الخطوة التي توشك على الفشل فيها ، يمكنك فقط "الاحتفاظ" بالجهاز الظاهري هناك لأغراض التصحيح ولكن من الواضح أن هذا ليس جيدًا. تريد حقًا أن يمر القالب بكل خطوة حتى تتمكن من فحص الحالة الفاشلة بالكامل.

فقط أضيف: +1 :. يمكنني حقا استخدام هذه الميزة.

jantman سأقوم بعمل packer -debug تخطي التنظيف عندما تفشل العملية ولا يمكنني الحصول على المدخلات (على سبيل المثال مع الإدخال من /dev/null ). لاحظ أن تسلسل تشغيل الحزم مبني على فكرة أن كل خطوة يمكن تنظيفها بعد ذلك وسيتم تنظيفها بعد ذلك ، لذا فإن الإنهاء المفاجئ سيترك النظام في حالة قد لا يتمكن برنامج التجميع من التعامل معها بمفرده (على سبيل المثال ، سوف يشتكي من دليل الإخراج هذا موجود بالفعل) ، لذلك يجب أن تتوقع أن تكتشف كيفية جعل عمليتك قابلة للتكرار ، ولكن من المحتمل أن يكون ذلك سهلاً.

@ rickard-von-essen سوف أقوم بتحديث التصحيح الخاص بي (إضافة موفرين جدد) وتقديم طلب سحب لاحقًا اليوم.

من @ DarwinJS في https://github.com/mitchellh/packer/issues/3445#issue -148713866

أقوم بإنشاء مربعات Windows على AWS وضبط مجلد ebs "delete_on_termination" على false ، لذا بعد فشل بناء يمكنني [أ] إرفاق وحدة التخزين ، [ب] تمهيد مثيل ، [ج] إلقاء نظرة على سجلاتها ، [د] قم بإغلاق المثيل ، [e] افصل وحدة التخزين ، [f] احذف وحدة التخزين يدويًا.

لاحظت أن ملفات c:\windows\temp<guid>.out تحتوي على ناتج وحدة التحكم لمزودي باورشيل الذي أقوم بتشغيله.

الحصول على هذا الناتج هو السبب الوحيد الذي يجب أن أتخذ كل هذه الخطوات الإضافية للحصول على هذه المعلومات.

سيكون رائعًا إذا دعمت شركة 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 and git وهذه المشكلة ؛ هل هناك طريقة أخرى يستخدمها الناس لإصلاحات orivej فكيف وصفتها؟ قد أفتقد شيئًا واضحًا جدًا ، لذا يرجى توضيح ذلك إذا كان هذا هو الحال.

مجرد التحقق من حالة هذه القضية.

هل هي أن تغييرات orivej تعالج هذه المشكلة ويلزم إجراء طلب سحب؟ أم أن هذا لا يزال بحاجة إلى معالجة؟

+1

سيكون مفيدًا حقًا ، في الوقت الحالي ، أستخدم غلافًا مضمنًا مع sleep 1800 لإبقاء جهاز vm حيًا.
الرجاء تنفيذ في اسرع وقت ممكن :)

يقوم Imho -debug بما نحتاج إليه جميعًا. بعد كل أمر ، تحتاج إلى الضغط على Enter لمتابعة الأمر التالي. لا دخول = vm على قيد الحياة :)

@ noose - لا أجلس

IMHO -debug عديم الفائدة تمامًا. أنا أقوم بتشغيل تصميمات معقدة ، وأنا حقًا لا أتحلى بالصبر على الضغط على إدخال ألف مرة حتى أصل إلى المشكلة.
لا أفهم حقًا سبب صعوبة تنفيذ ميزة لا تتطلب تفكيرًا مثل هذه.

@ henris42 بينما أتفق معك على عدم جدوى -debug في هذا السياق ، إذا بدا الأمر وكأنه لا يحتاج إلى تفكير ، فلماذا لا تفكر في طلب سحب؟

noose ، أقوم بأتمتة بناء الحزم في مهمة Jenkins (التي تسحب من Git config / scripts و Ansible playbooks). باستخدام packer بهذه الطريقة ، لا يكون الوضع التفاعلي مفيدًا ؛ إنها مفيدة أكثر بكثير من تحليل ما بعد الفشل.
أعتقد أن هذا سيناريو شائع في عالم DevOps :)

يبدو أن الجميع يحتاج هذا. يعد إنشاء AMI هذه عرضة للخطأ وستجعل هذه الميزة تستغرق وقتًا أقل في استكشاف الأخطاء وإصلاحها

أنا أتفق معworstadmin. في حالة إنشاء مربعات Vagrant ، يمكنك معالجة المشكلة من زوايا متعددة (على سبيل المثال ، احتفظ بالجهاز الافتراضي ، وجرب الأشياء باستخدام مزود الخدمة الفارغ ، وما إلى ذلك) ، في حين أن صور Amazon هي سلالة خاصة ومرهقة للغاية عند تصحيحها قضية.

بالاشتراك مع https://github.com/mitchellh/packer/issues/1687 ، سيكون هذا رائعًا.

بالإضافة إلى ذلك ، غالبًا ما يكون من المفيد تجاهل الأخطاء من مقدمي الخدمة والسماح لها بالاستمرار ، خاصة أثناء المرحلة المبكرة من تطوير الصورة ، إلخ.

بعد ثلاث سنوات تقريبًا ... وما زلت لا شيء تقريبًا. لقد أمضيت الأيام القليلة الماضية في تحطيم رأسي على لوحة مفاتيح في محاولة للقيام ببنيات نوافذ معقدة تفشل بشكل تعسفي وعشوائي في تنفيذ نصوص powerhell بدون إخراج وبسبب التنظيف التلقائي لا يمكنني القفز على المثيل. عندما أقوم بالتشغيل مع تمكين -debug ، يبدو أن "التوقفات المؤقتة" الإضافية المقدمة من خلال طلب الإدخال اليدوي تتسبب في عدم حدوث هذه المشكلة. وهو ما تعتقد أنه سيكون منطقيًا ، فأنا أضفت الكثير من فترات النوم إلى نصوص powerhell لمحاكاة هذا ، وهذا لا يساعد.

ولا حتى الكذب ، سأحصل على Paypal لشخص ما مكافأة قدرها 100 دولار إذا كان بإمكان شخص ما أن يصنع بجدية ميزة عدم التدمير عند الخطأ في أسرع وقت ممكن والحصول على الكرة تتدحرج على العلاقات العامة لهذا الغرض. أنا (ويبدو أن المئات من الآخرين) أحتاج إلى هذه الميزة ، خاصة عند التفكير في أن الحزم يستخدم عادةً مع وضع الأتمتة في الاعتبار (عبر CI / CD / إلخ). هذا هو بلدي طويل +1 والنداء.

مرحبًا ، قد يكون هناك حل بديل لمزود shell ، ولكن ليس لدي أي فكرة عن موفري الخدمات الآخرين. : crying_cat_face:

لقد عملت تقريبًا اليوم ، ومع ذلك ، تعلمت في Go لم أكن أعرف أنني سأصل إلى الجحيم metaprogramming مرة أخرى مطاردة الواجهة من خلال عدة ملفات للعثور على التنفيذ :(

تحقق من اقتراحي الحالي في # 3885 والذي يبدو جيدًا بالفعل بالنسبة لي!

tmartinx :

أحاول تشغيله باستخدام Ansible ولكنه لا يعمل وذهب ضيف KVM بعد الخطأ ، لذلك لا يمكن الذهاب إلى هناك لمعرفة الخطأ ...

كحل بديل حتى يتوفر إصدار جديد من Packer يحتوي على # 3885:

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

لديك بعد ذلك 4 ساعات للدخول في جهاز VM الذي لا يزال قيد التشغيل والتنقل.

ما يجري بحق الجحيم هنا؟

• اكتشف باكر "خطأ غير معروف" في برنامج VMware.
• _Packer_ أخبرني أن أتحقق من ملف سجل VMWare لمزيد من المعلومات. من المفترض أن يكون السجل في دليل الإخراج.
• لكن _Packer نفسه_ يحذف دليل الإخراج ، لذلك لا يمكنني التحقق من السجل. هاها! جيد ، باكر ، أنت الوغد!
• لقد واجه الكثير من الأشخاص الآخرين موقفًا مشابهًا ، كما هو واضح.
• ظل الناس يطلبون إصلاحًا يبدو بسيطًا للغاية ولا يحتاج إلى تفكير لهذه المشكلة _ لسنوات _ الآن.
• قرر اثنان منهم محاولة إصلاح هذا بأنفسهم. يبدو أن تصحيحاتهم قد تم رفضها من قبل HashiCorp ، أو ربما لم ينجحوا.
• في كلتا الحالتين ، حافظت HashiCorp على صمت الراديو. يبدو أنهم لن يصلحوا هذا أبدًا.

هل نستنتج أن حكومة الولايات المتحدة قد أمرت بإسكات HashiCorp وطلبت منهم عدم إصلاح هذا ، أو شيء من هذا القبيل؟

أواجه صعوبة في الخروج بتفسيرات بديلة.

كان لدي انطباع بأن أدوات HashiCorp هي خيار جيد لأشياء DevOpsy بشكل عام ، ولكن لدي الآن أفكار أخرى. بجدية. هل نفتقد جميعًا شيئًا واضحًا هنا ، أم أن HashiCorp مجرد ظليل للغاية؟

سبب إغلاق هذه التذكرة هو أنه تم إصلاح المشكلة بالفعل.

أضف العلم -on-error=ask إلى سطر الأوامر ، ثم إذا كان هناك خطأ ، فستتم مطالبتك بما إذا كنت تريد حذف عناصر البناء أم لا.

علاوة على ذلك ، قبل الإجابة على هذا السؤال ، يمكنك الانتقال إلى VM والتعمق فيه.

@ peterlindstrom234 ، تم تنفيذ هذا بالفعل. يمكنك استخدام "-on-error = abort" ولا ينبغي لبرنامج Packer إجراء أي تنظيف عند حدوث خطأ.

حسنًا ، يا سيئ. من المؤكد أن الأمر استغرق وقتًا طويلاً بشكل غريب.

@ peterlindstrom234 استغرق الأمر وقتًا طويلاً بسبب أمر gag بين الحكومة الأمريكية