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

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

أعد عرض هذا الأمر مرة أخرى حيث تم طرحه في https://github.com/kubernetes/charts/pull/5919

نسخ أجزاء من تعليقي الأخير:

نختار على وجه التحديد الاحتفاظ بالإصدار الثانوي من المخطط الخاص بنا متماشياً مع إصدار التطبيق الثانوي (على الرغم من أن أرقام إصدارات التصحيح يمكن أن تنحرف عن بعضها البعض).

هذا لأننا قد نضيف علامة جديدة إلى إصدار جديد من cert-manager ، ومن خلال إضافة دعم لها في مخطط Helm قد يكسر التوافق مع الإصدارات القديمة من cert-manager ، لأنها لا تدعم العلامة. هذا سؤال أساسي جدًا حول إصدار مخطط Helm بشكل عام IMO ، وهو سؤال ليس لدينا قصة جيدة له.

أعلم أنه لا يوصى بمحاولة محاذاة appVersion مع إصدار المخطط ، ولكن بهذه الطريقة ، يعرف المستخدم أنه يمكنه استخدام إصدار مخطط Helm 0.3.x مع أي من إصدار cert-manager 0.3.x ، وإصدار المخطط 0.4.x مع cert -مدير 0.4.x. يتم تحديد التوافق ضمن الإصدار الثانوي.

/ إزالة دورة الحياة التي لا معنى لها

أود إحضار هذا احتياطيًا للمناقشة.

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

نسخ اقتراحي الأصلي المشار إليه أعلاه:

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

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

عند تطوير تطبيقاتنا الداخلية ، فإن التطبيق نفسه يتغير كثيرًا أكثر من الرسم البياني الذي ينشره. عادةً ما يكون أمر النشر المستمر هو helm upgrade مع ما لا يزيد عن --set imageTag=<new_version> (من الواضح أنه يُستخدم في مكان آخر في المخطط لتعيين إصدار الحاوية) إذا استبدلنا ذلك بـ --app-version فإنه سيعطي لنا نقطة مرئية أخرى في helm ls لمعرفة إصدارات الكود التي يتم نشرها جنبًا إلى جنب مع إصدار المخطط الذي تم نشره.

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

أي خبر عن هذا؟

شكرا

أي تحديث على هذا. يبدو أن العلاقات العامة من Eraac تقوم بما هو مطلوب. كما ذكر @ TD-4242 ، نقوم أيضًا بتشغيل helm upgrade --set imageTag=<imagetag> ، لكن هذا لا يُحدِّث APP VERSION المدرج في الناتج helm ls . ستسمح لنا القدرة على --set app-version أو --set version بتشغيل helm upgrade بحيث يعرض helm ls الإصدار الذي تم نشره بشكل صحيح.

أي تحديثات؟

وقت Aaaaany قريبا سيكون جميل!

وسيكون من المفيد جدا

نحب أيضًا القدرة على تعيين إصدار التطبيق في وقت التثبيت حيث نستخدم المخططات الشائعة لنشر التطبيقات

+1

+1

سوف يكون مساعد جدا

يطلب نفس الشيء

الرجاء إيقاف البريد العشوائي باستخدام +1. يوجد بالفعل PR (https://github.com/helm/helm/pull/4961) ويناقش الناس الاقتراح. كان الرد الأخير حتى قبل يومين.

مرحبا filipre

يوجد بالفعل PR (# 4961) ويناقش الناس الاقتراح.

وفقًا لذلك العلاقات العامة ، تم نقل هذا هنا:
https://github.com/helm/helm/pull/5492
هذه هي أحدث العلاقات العامة للرقم 4961 ويبدو أننا إذا كنا ننتظر دمج المراجعة ...

filipre هل يمكنك أن تقول من فضلك: ماذا يحدث للعلاقات العامة؟ يبدو أن العلاقات العامة لا تتحرك نصف الشهر

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

أوافق ، أعتقد أيضًا أن هذا سيكون مفيدًا جدًا. أي تحديثات؟

راجع https://github.com/helm/helm/pull/5492#issuecomment -509662190.

فقط اضغط على هذه المشكلة الآن عندما أدركت أن هذا سيكون مشكلة أثناء كتابة مخطط Helm الذي نخطط لإعادة استخدامه للعديد من التطبيقات. نظرًا لعدم إحراز تقدم في حل هذه المشكلة بطريقة بسيطة (على سبيل المثال ، مع الإشارة إلى تعيين إصدار التطبيق عند التثبيت) ، فقد توصلت إلى بديل يجب أن يعمل في الوقت الحالي. إنه أمر بسيط للغاية حقًا - ما عليك سوى إجراء helm fetch أولاً باستخدام خيار untar ، ثم helm package --app-version بعلامة

إنها ليست مثالية ، ولكن النتيجة النهائية في helm list صحيحة ، ومن السهل جدًا القيام بذلك على خادم CI. أتمنى أن يكون لديك --app-version متاحًا على helm install و helm upgrade بالرغم من ذلك.

كان ملخص المناقشة في # 5492 هو أن الأمر الذي يلف منطق helm package و helm install سيحل حالة الاستخدام التي تم وصفها في الأصل في هذه المشكلة.

بمعنى آخر ، يمكنك حل هذه المشكلة عن طريق تشغيل ما يلي:

$ helm package myapp --app-version 1.0.0
$ helm install myapp-1.0.0.tgz

(نقل التعليق من العلاقات العامة المغلقة مؤخرًا هنا - لذلك لا ينتهي به الأمر في نيرفانا)

إليك 2 سنتي على هذا:
بافتراض أن لدينا قيادة chart version X تنشر خدمة بـ appVersion Y .

يتم استخدام مخطط الدفة لوصف البنية التحتية داخل Kubernetes على chart version X والتي تُستخدم لاستضافة خدمة appVersion Y .

أثناء التطوير الأولي ، سيتغير كل من X و Y بانتظام. ومع ذلك ، في مرحلة ما ، سيكون X أكثر أو أقل استقرارًا وسيستمر Y في التغيير (ما لم يكن لدى Y بعض المتطلبات الجديدة للبنية التحتية ، والتي تحدث غالبًا أقل بكثير في دورة تطوير Y ).

من خلال النهج المقترح في هذه التذكرة ، يمكن للمرء أن يأخذ حزمة مخطط دفة ثابتة في الإصدار X لنشر appVersion Y ، Y+1 ، Y+N ، إلخ.

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

ملخص:

يعمل هذا النهج بالتأكيد ، ولكنه ينتج عنه أيضًا الكثير من حزم Helm غير الضرورية حيث تم تغيير AppVersion :
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

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

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

حيث قيل أن Charts.yaml يجب أن يكون غير قابل للتغيير ، أنا أزعم أن أداة النشر يجب أن تكون كذلك.

_لخص أفكاري من https://github.com/helm/helm/pull/5492#issuecomment -520029902_

توجد مشكلة في كيفية تفسير المجتمع للحزمة والرسم البياني والإصدارات. BenjaminSchiborr ، آمل أن يكون هذا منطقيًا بالنسبة لك.

الرسم البياني - هو رمز مصدر لإصدارك. مثل شفرة المصدر لتطبيقك. يتكون من قوالب وملفات كود.
الحزمة - هو بناء الإصدار الخاص بك ، الأداة. مثل ثنائي ، مبني من شفرة المصدر الخاصة بك. يتكون من إصدارات الإنتاج الثابتة: كل من إصدار المخطط وإصدار التطبيق.
الإصدار - هو بناء ، تم نشره بالتكوين المحدد.

لا توجد طريقة يمكنك من خلالها إصدار بيان خارج الرسم البياني . انها فقط لا تعمل بهذه الطريقة!

قبل نشر تطبيقك على المنصة ، يجب أن يكون لديك مخطط. بعد ذلك ، تحتاج إلى حزم تطبيقك بمخطط ، وإصلاح كلا الإصدارين ، باستخدام helm package . سينتج عن ذلك حزمة قابلة للنشر في أي مرحلة. بعد ذلك ، تقوم بتثبيت هذه الحزمة ، على سبيل المثال ، مرحلة QA ، والترويج لها على UA ثم على الإنتاج ، باستخدام helm install .

إنها الطريقة التي يعمل بها أي برنامج موجه نحو الحزمة.

الارتباك

يحتاج helm install إلى مصدر يجب تثبيته. يمكن أن يكون المصدر:

1. اسم الحزمة ، متاح من التسجيل
2. مسار ملف الحزمة ، إذا تم تنزيل الحزمة أو إنشاؤها بالفعل
3. عنوان URL للحزمة ، إذا كان متاحًا باستخدام HTTP
4. مسار دليل الرسم البياني

النهج الرابع يبدو وكأنه خروف أسود هنا ، ألا تعتقد ذلك؟ هذا هو السبب في أن ppl يخلطون بين الحزمة والرسم البياني. وهذا هو أصل المشاكل.

منطق

هناك نوعان من التطبيقات في البرية:

كبير / متوسط - هذا هو المكان الذي يتوفر لدينا فيه الوقت والمال والموارد لإعداد تدفقات مفصلة ومحددة لتحسين الاستبطان وضمانات الجودة.
صغير - خدمة

مع المشاريع الصغيرة ، ليس لديك وقت أو تحتاج إلى إنشاء أو التعامل مع التغليف. تريد كتابة بعض ملفات القوالب ونشرها بأمر واحد !

هذا هو السبب في أن helm install يسمح بهذا الاستخدام ، مثل helm package & helm install . لكنه لا يوفر إمكانات كاملة helm package ، مثل --app-version .

يمكن أن يكون helm install helm package & helm install ، لكنه سيجعل helm install فوضى ، جحيم للدعم والاختبار والقيام بالممارسات الجيدة.

الاقتراح 1

بسّط helm install . يجب أن يسمح بتوفير الحزم فقط ، لتبسيط قاعدة التعليمات البرمجية والاختبارات وجعلها برأي ، لتبسيط فهم helm .

الاقتراح 2 - helm run

تقديم أمر جديد: helm run . أمر يجب أن يعمل فقط . مثالي للتطبيقات الصغيرة. أو ربما متوسطة وكبيرة.

يجب أن تجمع بين helm package و helm install ، مما يوفر إمكانيات من كلا الأمرين ، باستثناء الأوامر التي لا معنى لها في حالة الاستخدام هذه.

ينشئ helm package تصميمًا ، كما يفعله go build . يسمح go run ببدء تشغيل التطبيق بدون عملية الإنشاء ، لذا يبدو أن helm run يبدو كاسم ثابت هنا.

أشياء إضافية يجب وضعها في الاعتبار:

• هل يجب استخدام upgrade --install بدلاً من ذلك؟
• هل يجب تمكين --atomic افتراضيًا؟

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

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

أنا بخير إذا كانت هناك ميزة طويلة المدى لهذا الأمر. أنا فقط لا أراه.

BenjaminSchiborr حسنًا ، اسمحوا لي أن

يمكنك الحصول على مخططك (== البنية التحتية) ، الذي يحتوي على إصدار X .
يمكنك الحصول على التطبيق الخاص بك ، الإصدار Y .

كيف يعمل helm الآن ، فهو يربط معًا إصدارات البنية التحتية والتطبيق في الخطوة helm package . بعد ذلك ، تحتاج إلى ربطه بمساحة اسم k8s ، لإنتاج Release.

إذن الصيغة هي: package(infra + app) + k8s = Release

ما تريده حقًا ، هو تخطي هذه الخطوة الوسطى وربط جميع المكونات الثلاثة معًا في خطوة واحدة - الإصدار. مثل هذا: infra + app + k8s = Release . هل انا صائب؟

هذا ما سيفعله helm run ظاهريًا. تحت غطاء المحرك ، سيكون هو نفسه.

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

اسمحوا لي أن أحاول وصف كيفية استخدامها وسيكون من الرائع رؤيتها من وجهة نظرك.

تم إنشاء Helm نفسها لتجريد قوالب k8s ونشرها ، وربط التطبيق والبنية التحتية معًا ، مع تبعياتها: بدلاً من إعادة كتابة القوالب يدويًا ، وتطبيقها على K8s ثم توفير علامة صورة جديدة ، فأنت بحاجة إلى أمر واحد فقط - helm upgrade . مثل حزمة MSI أو deb.

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

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

إذا كانت مشكلتك أن لديك الكثير من الحزم في الريبو ، فإنني أقترح استخدام الأدوات بدلاً من المستودعات. أفعل ذلك على هذا النحو في CI: أنشئ التطبيق ، وأرسله إلى سجل عامل الميناء ، وأنشئ الحزمة ، واحفظها كقطعة أثرية للإصدار. تدعم خطوط أنابيب CircleCI و Travis و Azure إنشاء الملفات المرفقة للإنشاء كقطع أثرية. يمكنك أن تفعل الشيء نفسه؟

ربما أفتقد وجهة نظر هيلم. ربما فات هيلم نقطة هنا. أعتقد أن هذه البطاقة تدور حول تقييم ذلك بالضبط. وشخصيًا - أيضًا حول توسيع أفقي :)

لكن نعم ، بطريقة مجردة ما تقوله صحيح. لا أريد أن يكون إصدار البرنامج مقترنًا بحزمة / إصدار الدفة ، لذلك فهو في الأساس infra + app + k8s = Release . تمامًا كما لا أريد أن تكون خصائص إصدار البرنامج الخاص بي مرتبطة بحزمة / إصدار دفتري (بصرف النظر عن ربما الافتراضي العاقل الذي يمكنني تجاوزه).

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

هل يمكنك التفصيل في؟

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

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

(تبدو خطوط الأنابيب الخاصة بي عمومًا مماثلة لخطوطك: إنشاء تطبيق -> صورة Docker (ينتج عنها إصدار appVersion) -> مخطط الحزم (مع إصدار appVersion المحدّث) -> الدفع إلى المستودع؟

أعتقد أن هذه البطاقة تدور حول تقييم ذلك بالضبط.

بالتأكيد! في رأيي ، لدينا بالفعل مستويات كثيرة جدًا من التجريد ، لذا فإن امتلاكك لقيادة هنا يربك قليلاً 😄 أيضًا ، هناك مشغلات k8s هنا ، والتي تم إنشاؤها لبعض (ربما معظمها؟) من المشكلات التي يحلها Helm. لكن هذا موضوع لوقت آخر ، هيه.

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

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

نفس المشكلة التي نواجهها مع عامل الإرساء: كل بناء يولد صورة عامل إرساء جديدة ، والتي تدخل في سجل عامل الإرساء. نحتاج إلى حفظه ، كيف يفترض بنا أن ننشره إذا لم نكن نمتلكه؟

بالطبع يمكننا docker save لتوفير مساحة على التسجيل والاكتساح لاحقًا في سياسة الاحتفاظ بعناصر البناء. ولكن حتى نتمكن من helm package والاحتفاظ به كملف.

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

التطبيق نفسه لا معنى له في بيئة k8s بدون بنية تحتية .

ماذا لو كان تطبيقك يعتمد على بعض البنية التحتية؟ المثال الأساسي - configmap.

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

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

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

لدينا بالفعل مستويات كثيرة جدًا من التجريد
كل غمزة لطيفة وبسيطة

أعتقد أن نقطتك الأخيرة مقنعة للغاية:

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

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

لكن الدفة وحدها ، نعم ، مشكلة 100٪. أعتقد أن هذا هو السبب في أن الفكرة كانت السماح صراحةً بتجاوز الإصدار appVersion وعدم السماح به افتراضيًا.

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

في النهاية ، سيكون إصدار المخطط بمثابة إصدار "ممتاز":

• أي تغيير (بغض النظر عما إذا كان قد تم تغيير التطبيق أو البنية التحتية ، أي الرسم البياني) سينتج عنه إصدار مخطط جديد ، أي أن إصدار التطبيق الجديد يعني أن إصدار المخطط قد تغير أيضًا
• لا يعني إصدار المخطط الجديد أن إصدار التطبيق قد تغير

لأغراض التوثيق (وربما الأفكار الفاخرة الأخرى) يمكنك تقديم نسخة أخرى من "الرسم البياني فقط" بنفسك والتي ستشير فقط إلى تعريف المخطط نفسه.

تضمين التغريدة
نعم! هذه هي الطريقة التي من المفترض أن يعمل بها هيلم ، بناءً على قرارات التصميم المعمارية الحالية. كما اراه.

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

تضمين التغريدة

ومع ذلك ، قد لا يكون هذا هو الحال بالنسبة لكثير من الناس

بالتأكيد! حتى k8s كاملة ، يمكن أن يكون النقل بالحاويات أكثر من اللازم.

اسمحوا لي أن أحاول تقسيمها من منظور آخر قليلاً ، محاولة العثور على رأس المشكلة تم إنشاؤه من أجل:

• مثيل البنية التحتية هو كيفية عمل المنتج بالكامل: مثيلات SaaS ، وتجمعات VM ، وإعدادات k8s ، وإصدارات التطبيقات (بما في ذلك قواعد البيانات ، وأدوات المراقبة ، وأجهزة التوجيه ، والسيارات الجانبية ، وطبعات تطبيقات المنتج)
• يحتاج مثيل البنية التحتية إلى مصدر واحد للحقيقة. الآن لدينا مرافق مثل Terraform.
• أشياء كثيرة جدًا في مجلد واحد = صعب. نحن بحاجة إلى تحللها. مرحبًا وحدات Terraform.
• النظام الأساسي والتطبيق في مجلد واحد = صعب. نحن بحاجة إلى التحلل. مرحبا منصة وحاويات. خطوات K8s.
  
  
  
  1. لذلك ، يمكن لوحدات Terraform إدارة النظام الأساسي ، بما في ذلك إنشاء طبقة حاويات فارغة وجاهزة للاستخدام
  
  
  2. تدير K8s الحاويات ، مما يسمح بإنشاء موارد أساسية باستخدام YAML
  
  
• العديد من ملفات YAML للعديد من تطبيقات K8s (بما في ذلك قواعد البيانات والأشياء) = صعب. قسّمه إلى مجلد لكل تطبيق.
  
  
  
  1. إذن لدينا بعض المجلدات مثل PostgreSQL و Redis و MyPetShop. يحتوي كل منها على ملفات YAML للمصادر التي لدينا. ويحتاج إلى تعيين إصدارات التطبيق الخاصة به ليتم تطبيقها في K8s.
  
  
• Hello Helm - أداة تسمح بإعداد هذه المجلدات (تسمى الرسوم البيانية) ، ولكن المزيد: قم بتطبيقها معًا ، التراجع.
• يبدو الرسم البياني صلبًا. دعونا نعيد استخدامه من خلال دعم المتغيرات. الآن المخطط ليس بنية أساسية ، ولكنه قالب بنية أساسية.
• يبدو الرسم البياني رائعًا. دعونا نشاركها مع الأصدقاء. في كل مرة نقوم فيها بتحديث المخطط ، نحتاج إلى دفعه إلى ملف الريبو باستخدام الفهرس.

لذلك ، إنه شعور رائع وكل شيء ، بدون حزم على الإطلاق. لذلك ، تحتاج إلى تطبيق هذا المخطط ، ثم تقديم إصدار التطبيق. ويجب أن يكون عليه.

ولكن تظهر المشكلة: لا أحد يريد أن يتذكر الرسم البياني المطلوب لإصدار التطبيق. الرسم البياني الذي يتم تحديثه لتوفير قيمة تكوين جديدة لإصدار التطبيق.

في نهاية اليوم ، كل ما نريده هو "إعداد الإصدار 1.4.2 من myApp باعتباره تطبيق K8s" ، والذي يزيل جميع المخاطر والتبعيات والتغييرات في قطعة أثرية واحدة - مثبت التطبيق ، وهو apps versions + hooks + setup logic + infrastructure to connect it all . هذا هو السبب في أن لدينا أشياء مثل MSI و Deb و RPM وحتى NPM و Go mod و Pip و Gem.

هذا هو المكان الذي يأتي فيه Package على الساحة. والحزمة ، بحكم تعريفها ، تحتاج إلى إنشائها كإصدار قابل للتثبيت ، ضمن تدفق CI / CD. حتى نتمكن من إرسالها إلى التسجيل و / أو الإعداد على نظامنا (مجموعة k8s).

ولا يوجد مشروع آخر مختلف. عندما نخطط helm install مباشرة ، بدون حزمة ، فإننا نفعل نفس الشيء. ولكن بدلاً من إنشاء الحزمة ، نقوم بإنشائها في خطوة مختلفة. بدلاً من بنائه على عملية إنشاء التطبيق ، نقوم ببنائه في خطوة الإصدار. ما زلنا نربط البنية التحتية وإصدارات التطبيقات معًا . ضمنيًا .

الشيء المضحك هو:

• تم تحديث التبعية = تحديث إصدار قالب البنية التحتية (مخطط)
• تم تحديث التطبيق = إنشاء مجموعة فرعية من قالب البنية التحتية (مخطط) - حزمة ، بإصدارها الخاص

ومع ذلك ، يجب توقع مشغلي k8s بشأن المشكلات الحالية ، لذلك يجب أن يكون هناك أداة واحدة فقط ، والتي يجب أن تعمل مثل المشغلين ، ولكنها توفر عملية تحرير سهلة ، كما تفعل الدفة.

أي أفكار؟ قد نبتكر شيئًا جديدًا هنا ، لكن أفضل

ما تصفه منطقيًا جدًا للتطبيقات التي من المفترض أن يستخدمها أشخاص آخرون في البنية التحتية ولا يمكنك التحكم فيها. ومع ذلك ، في سيناريوهات المؤسسة ، يصبح إنشاء الحزم عملاً مشغولاً: قد يكون لدينا العشرات من الخدمات المصغرة لملفات تعريف الارتباط ، والتي يتم نشرها في البيئات المشتركة أو بيئات قطع ملفات تعريف الارتباط ، وبحكم تعريف خط أنابيب CI / CD الذي يعيش في الريبو نفسه (فكر في ذلك) azure-pipelines.yaml) ، فإن "إصدار الحزمة" هو مجرد بناء تم إنتاجه من إصدار معين من الفرع الرئيسي. بمعنى ، لا أحتاج حقًا إلى تخزين "الحزمة" في أي مكان - سينتج التصميم الخاص بي نفس الحزمة ، مع نفس البتات ونفس المتغيرات المستخدمة في configmaps ، وما إلى ذلك. في سيناريوهات مثل هذه ، سأقوم بتدوير مخطط الدفة فقط عندما تغييرات الخدمة بالأشعة تحت الحمراء ، والتي نادرًا ما تحدث. Helm في هذه الصورة لأن 1) يجب أن أستخدمه بالفعل لنشر بعض أجزاء من الأشعة تحت الحمراء (على سبيل المثال ، nginx) ، 2) لست مضطرًا لإعادة اختراع العجلة باستخدام قالب k8s yaml.

تضمين التغريدة

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

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

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

على أي حال ، أعتقد أننا سلكنا الطريق الخطأ. هل يستخدم أي شخص الدفة ثم يقوم بتحديث الصورة يدويًا؟ أعتقد أن لدينا 3 حالات استخدام عامة:

1. helm package chart -> helm install package
2. helm install chart
3. helm install -> kubectl set image

wasker أيهما لك؟ أعتقد ، ليس الثالث. حتى لو كان فصلًا حقيقيًا عن تكوين البنية التحتية وإصدار التطبيقات ، فسيكون التعامل معه أمرًا سيئًا. نظرًا لأنه يعني ، عندما تحتاج إلى تحديث البنية التحتية ، ستفقد جميع الإصدارات. ستحتاج إلى تحديثه في المخطط يدويًا أو في kubectl set image لكل عملية نشر.

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

وإذا عرضته على golang ، فإن هذه الممارسة تبدو مثل إرسال كود المصدر وتشغيله كـ go run في عامل الإرساء ، بدلاً من بنائه واستخدام الثنائي.

لذا ، فإن السبب الحقيقي لتخطي خطوة التغليف هو تبسيط الصورة الكاملة للمهندس. هل هو كذلك ؟

هذا هو المكان الذي يمكننا أن نبدأ فيه الحديث. هنا https://github.com/helm/helm/issues/3555#issuecomment -529022699 هو اقتراحي. أضف helm run وصممه كـ go run .

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

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

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

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

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

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

ومع ذلك ، فإن الحجج التي تم إجراؤها لإعادة تجميع مخطط Helm بإصدار جديد من التطبيق واستخدام إصدار المخطط كنوع من "الإصدار المتميز" مقنعة (وهي ميزة وجود إصدار تطبيق متوافق يتم نشره مع مخطط - بشرط ألا يكون إصدار التطبيق قابلاً للتخصيص عبر القيم).

سؤالي هو - _لماذا لا يدعم كلا النهجين؟ _ هناك إيجابيات وسلبيات لكل نهج. بشكل أساسي ، يؤدي عدم دعم هذا إلى جعل بعض مهام سير العمل الصالحة تمامًا أكثر صعوبة. على سبيل المثال ، استخدام Flux CD و Helm Operator. إذا كان لديك مخطط Helm مشترك (على سبيل المثال ، لأن لديك نوعًا معينًا من الخدمة تقوم بنشر العديد منها ويشترك في العديد من الخصائص نفسها) ، فلكي تحصل على ناتج مفيد helm list يجب أن يكون لديك خوذة جديدة مخطط لكل تطبيق ، ويحتاج كل إصدار أيضًا إلى مخطط Helm خاص به. يؤدي هذا وحده إلى تعقيد خطوط الأنابيب ، لأنه إذا كان من الممكن مشاركة المخطط ، فقد يكون له خط أنابيب خاص به يعمل فقط عند تحديث المخطط ، ولن تحتاج خطوط أنابيب التطبيق حتى إلى تشغيل أمر Helm واحد (بشرط دعم Flux CD المضافة لـ علامة إصدار تطبيق جديد عند التثبيت / الترقية).

سؤالي هو - لماذا لا تدعم كلا النهجين؟

هذا بالضبط ما أفكر فيه.

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

ومع ذلك ، هناك حجة تجاه وجود مخطط هيلم نفسه باعتباره "الإصدار الممتاز" الوصفي.

عودة إلى وجهة نظر seeruk : لماذا لا تدعم كليهما؟

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

كيف أشاهد Helm

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

يثبت Helm الرسوم البيانية في Kubernetes ، مما يؤدي إلى إنشاء إصدار جديد لكل تثبيت. وللعثور على مخططات جديدة ، يمكنك البحث في مستودعات مخططات Helm.

بالنسبة إلى السياق ، تنص مستندات الدفة الثابتة الحالية أيضًا على ما يلي:

الرسم البياني هو حزمة هيلم. يحتوي على جميع تعريفات الموارد اللازمة لتشغيل تطبيق أو أداة أو خدمة داخل مجموعة Kubernetes. فكر في الأمر مثل Kubernetes المكافئ لصيغة Homebrew أو Apt dpkg أو ملف Yum RPM.

حتى الآن هناك بعض الالتباس! تقول مستندات Helm بوضوح أن "المخطط هو حزمة خوذة" ، ولكن إذا كان هذا هو الحال ، فلماذا على الأرض يقبل helm install إعادة شراء المخططات غير المعبأة؟

هذا السلوك هو الذي أثر في وجهة نظري الحالية حول ماهية الدفة وكيف من المفترض أن تعمل:

يعمل Helm كرسام خرائط بين بنية _ما _ الذي يدخل في العنقود و _ ما خصائص _ هذه الأشياء.

لذا فإن السؤال المطروح الآن هو: "ما الذي ينشره هيلم؟"

ما هو نشر هيلم؟

عندما أقوم بتشغيل helm install release-name ./local_chart أتوقع أن تقوم الدفة بعرض جميع قوالب المخططات محليًا بالقيم المحددة (إما من خلال الإعدادات الافتراضية أو التجاوزات) ودفع الإصدارات المعروضة إلى Kubernetes. أتوقع أيضًا أن يحتفظ Helm بكائنات Kubernetes التي تم نشرها مسبقًا في حالة التراجع. هذا المفهوم من "مجموعة من القوالب المقدمة" (الذي يحتوي على بعض الفوقية) هو بيان وهو عبارة عن حزمة. يجب أن تكون كل تعريفات الموارد هذه (حتى لو لم تتغير) في الحالة الموضحة في الحزمة حتى يكون الإصدار موجودًا (أو يمكن الرجوع إليه).

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

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

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

ما هو النمط الذي يجب استخدامه؟

هذا رأي بالفعل من قبل هيلم: الحزم .

بالنظر إلى أن هذا النمط هو النمط --appVersion . ربما تكون الإجابة عن "سبب" هذا أكثر أهمية من أي شيء آخر ، لذا اسمحوا لي أن أختتم مساهمتي بهذه الإجابة.

لماذا دعم --appVersion؟

دعنا نلقي نظرة على حالة خاصة للنشر:

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

ما هي هذه الشركة لتفعل؟

1. قم بعمل مخططين للدورة منفصلان متطابقان تقريبًا يختلفان فقط في appVersion ؟
2. هل تريد استخدام مخطط دفة واحد ولكن يتم تحديث appVersion باستمرار بين إصدارات التطبيقات الرئيسية؟
3. هل تريد تجاوز appVersion بعلامة (غير مدعومة حاليًا) تؤدي إلى خطأ مطور محتمل في سطر الأوامر؟
4. Rescope appVersion من Chart.yaml و إلى values.yaml ؟

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

يحتوي الاقتراح 2 على مصاريف أقل من الاقتراح 1 ولكنه يقدم تنوعًا كبيرًا في الرسم البياني. ماذا يحدث إذا ذهبت إلى تشغيل helm install release-name https://remote-repo.com/chart وكان أحدث إصدار من المخطط هو الإصدار الخاطئ من التطبيق؟ عذرًا. ربما ليس أفضل نهج.

الاقتراح 3 هو ما نناقشه حاليًا. أنا شخصياً لا أحب الخيار ولكن فقط لأنني أشعر أنه الحل الخاطئ للمشكلة. هل تجعل التطبيق قابل للتكوين؟ بالتأكيد. ولكن لديها أيضًا نفس المشكلة التي تواجهها عند تشغيل helm install release-name https://remote-repo/chart : البيانات الوصفية سريعة الزوال ويتم الاحتفاظ بها بواسطة Helm فقط.

لقد صدمت حقًا لأن أحداً لم يقدم الاقتراح 4 أو شيء من هذا القبيل حتى الآن. إنه يضع appVersion في حالة يمكن تجاوزها (تمكين شيء يشبه helm run ) ، ويمكن احتوائه في الحزمة التي تم إنشاؤها بواسطة helm package ، ويفكك بالفعل مفهوم إصدار التطبيق من إصدار مخطط مع الاحتفاظ بمفهوم appVersion مقترنًا بنشر الدفة (يجب أن يكون appVersion في مكان ما صحيح؟).

آمل أن يكون هذا كان مفيدا. 👀 هذا العلاقات العامة.

jrkarnes : بمعنى 4) تم اقتراحه بالفعل ويستخدم كحل بديل من قبل العديد من الأشخاص (انظر هنا https://github.com/helm/helm/pull/5492#issuecomment-517255692). يمكنك استخدام شيء مثل هذا في قوالب المخططات الخاصة بك:

{{ default .Values.appVersion .Chart.AppVersion }}

سيسمح لك هذا باستخدام appVersion في Charts.yaml كإعداد افتراضي وتجاوزه بشيء في Values.yaml (والذي يمكن تجاوزه أثناء مكالمات التثبيت / الترقية). الجانب السلبي هو أنه عند القيام على سبيل المثال helm ls فإنه سيظهر لك إما لا أو أن appVersion غير صحيح.

BenjaminSchiborr شكرًا helm لفترة محدودة جدًا ، لذا فإن أي معرفة هي معرفة جيدة في هذا الوقت بالنسبة لي.

أعتقد أن اقتراحي الرابع قد أسيء فهمه قليلاً. بدلاً من الحصول على شيء مثل {{ default .Values.appVersion .Chart.AppVersion}} يمكنك استخدام {{ .Values.Helm.AppVersion}} و values.yaml يحمل appVersion بدلاً من Chart.yaml

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

الاستدلال وراء ذلك سهل: كل شيء جزء من البنية التحتية. لذلك ، يوجد أدناه إصدار. لماذا نسختين؟

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

سأفكر في الأمر أكثر من ذلك بقليل

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

الاستدلال وراء ذلك سهل: كل شيء جزء من البنية التحتية. لذلك ، يوجد أدناه إصدار. لماذا نسختين؟

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

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

عكس ذلك قابل للتطبيق أيضًا وهو بالفعل موضوع نقاش في هذا العلاقات العامة.

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

سأفكر في الأمر أكثر من ذلك بقليل

بدلاً من التفكير في حالة جانبية أو عرض ، فكر في أشياء مثل MySql الذي يحتوي على ثلاثة إصدارات محرك مستخدمة ومدعومة على نطاق واسع: [5.6, 5.7, 8.0] . لنشر مثيل mysql في مجموعة ، سيكون لديك دائمًا:

• جراب (مجموعات) تقوم بتشغيل مثيل MySql للإصدار المختار
• خدمة تسمح بدقة kube-dns للحجرة (أو البودات إذا كانت تعمل في HA)
• PV (s) للكبسولات لكتابة بياناتها مع PVC (s) المصاحبة

يجب أن يكون مخطط نشر MySql 5.6 أو 5.7 أو 8.0 هو نفسه نسبيًا لجميع إصدارات المحرك (التطبيق). الاختلاف الحقيقي الوحيد هو إصدار التطبيق وصورة عامل الإرساء (والتي من المحتمل أن يتم تمييزها بشكل دلالي وفقًا لإصدار المحرك).

أرى ما تقصده بشأن التساؤل عن "الحاجة" إلى إصدار التطبيق. أعتقد أن هذا يعود إلى راحة المطور أو العمليات عند تشغيل helm ls أو helm inspect .

+1 إلى jrkarnes آخر مشاركة. هناك قيمة كبيرة في الاحتفاظ بإصدارات الرسم البياني والتطبيق كمفاهيم منفصلة على وجه التحديد لأن إصدار المخطط هو "إصدار البنية التحتية".

إذا قمت بنشر المخطط ليستخدمه الآخرون ، فإنه يصبح جزءًا من البنية التحتية للمشاريع التي تعتمد عليه. ومع ذلك ، إذا لم أنوي أبدًا أن يستهلك الآخرون طلبي ، فكل ما يهمني هو إعادة إصدار المخطط الخاص بي من وقت لآخر ، عندما يتغير المخطط نفسه ، ولكن بخلاف ذلك ، أحتاج فقط إلى أن يكون إصدار تطبيقي متوافقًا مع CI / إخراج القرص المضغوط. في هذه النكهة من مخطط الاستخدام ، نادرًا ما يكون عدد الدورات نسبيًا ، ومع ذلك فإن إصدار التطبيق يعمل على كل تكرار CI. يحافظ الريبو الكودي الخاص بي على العلاقة بين الكود وإصدار الأشعة السفلية القابلة للتطبيق لتشغيل هذا الإصدار من التعليمات البرمجية. وبعبارة أخرى ، بدلاً من التراجع عن النشر باستخدام helm install last-known-good-chart-version ، أقوم ببساطة بإعادة تشغيل خط أنابيب القرص المضغوط الخاص بي باستخدام مؤشر إلى آخر معرف التزام جيد معروف.

iorlas لقد قرأت helm run وليس لدي مشاكل في ذلك. على الرغم من أنني أعتقد أنه ليس من الضروري أن يكون لديك تقسيم التثبيت / التشغيل ، إلا أنه إذا كان ذلك يجعل عقل المشرفين على القيادة مرتاحًا بشأن جعل إصدار التطبيق قابل للتغيير ، فأنا موافق على ذلك. :)

iorlas هل

لا أعتقد أنني أفهم كيفية عمل الوظائف البديلة التي تتضمن {{ default .Values.appVersion .Chart.AppVersion}} . أتلقى هذا الخطأ:

خطأ: خطأ في تحويل YAML إلى JSON: yaml: مفتاح مخطط غير صالح: واجهة الخريطة [الواجهة {}] {} {". Values.appVersion | الافتراضي \" 0.0.1 \ "": الواجهة {} (لا شيء)} [

هذا هو مخطط بياني. yaml:

name: demo-helm
version: 0.0.1
appVersion: {{ .Values.appVersion | default "0.0.1" }}
home: http://example.com
description: Demo Helm

IRobL تحتاج إلى وضع هذا المقتطف في templates/deployment.yaml ، حيث يتم استخدام الإصدار. لا يتم التعامل مع ملفات مثل values.yaml كقوالب.

jrkarnes أنا لست helm و packages .

نحن نستخدم النهج الذي وصفته:

• Helm Chart هو جزء من مستودع التطبيقات
• ينتج عن بناء التطبيق :
  
  
  
  • صورة عامل ميناء -> سجل عامل ميناء
  
  
  • ملفات ثابتة -> خدمة CDN
  
  
  • حزمة Helm -> تخزين CI
  
  
• لذا ، فإن حزمة Helm هي الأداة الرئيسية التي تربط جميع عناصر التطبيق معًا
• عند النشر ، قالت الحزمة install

المخاوف الحالية:

• تعقيد عملية البناء.
  
  
  
  • بدلاً من صورة عامل الإرساء والملفات الثابتة ، يتم إنشاء ملف إضافي ( helm package )
  
  
  • ما هي الأسباب الرئيسية التي تجعلنا نحتاج إلى أي شيء بجانب الملف الناتج go build / make install ؟
  
  
  • ما هي تكلفة؟
  
  
  • لماذا التقديم؟
  
  
  • متى يتم التقديم؟
  
  
• مدة البناء
  
  
  
  • حتى لو لم نكن بحاجة إلى نشره ، فإننا ما زلنا نهدر بعض الوقت والمال. 2-5 ثواني. ليس كثيرًا ، لكن العمل الذي لا معنى له لا معنى له.
  
  
• تعقيد تحديثات قالب البنية التحتية
  
  
  
  • عند تحديث المخطط ، يجب تحديث القيم أيضًا
  
  
  • الرسم البياني هو ريبو واحد ، والقيم هي أخرى ، وكل تحديث للقيم يعني القليل من الصداع
  
  

يمكن أن تؤدي إعادة التقييم هذه إلى تبسيطات وأفكار إضافية. سوف نرى :)
سأرسل تحديثًا أقرب إلى يوم الجمعة المقبل.

آه ، فهمت لماذا لن تنجح هذه الحيلة الآن بعد أن أشرت إلى ذلك من أجلي ، شكرًا. هذه خدعة أعتقد أنها تعمل بشكل جيد للعديد من الأشخاص الذين يستخدمون Helm 2.x بافتراض أنك مرتاح في تغليف أداة الدفة بهذه الأنواع من القطع العلوية:

APP_VERSION=0.0.7
sed -i.bak "s/^appVersion:.*\\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/

IRobL

بشكل عام ، إذا كنت تغلف عملية نشر بـ sed ، فهذا يعني أن محرك القالب لا يقوم بما تريده ، وهذا هو الهدف الكامل من هذه المناقشة.

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

إنها ممارسة سيئة لشيء كهذا وأود أن أحثك ​​على الابتعاد عنه إذا كان ذلك ممكنًا.

في 7 تشرين الأول (أكتوبر) 2019 ، الساعة 3:33 مساءً ، كتب IRobL [email protected] :

آه ، فهمت لماذا لن تنجح هذه الحيلة الآن بعد أن أشرت إلى ذلك من أجلي ، شكرًا. هذه خدعة أعتقد أنها تعمل بشكل جيد للعديد من الأشخاص الذين يستخدمون Helm 2.x بافتراض أنك مرتاح في تغليف أداة الدفة بهذه الأنواع من القطع العلوية:

APP_VERSION = 0.0.7
sed -i.bak "s / ^ a pp الإصدار :. * \\ $ / app الإصدار: $ APP_VERSION /" helm / Chart.yaml
تثبيت الدفة - name helm_demo helm /
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

jrkarnes ، عندما تقول ممارسة سيئة ، هل تقول أن الحاجة إلى التفاف الأمر helm بالبرمجة أمر غير مرغوب فيه؟ إذا كان الأمر كذلك فأنا أوافق تمامًا. أنا لا أقول أنني ضد إضافة علامة --app-version على الإطلاق ؛ على العكس من ذلك ، أعتقد أن ذلك سيكون إضافة مريحة للغاية للقيادة. استنادًا إلى هذا العلاقات العامة بشكل واضح ، فأنا لست الشخص الوحيد الذي يستخدم الدفة الذي يريد الحفاظ على متغير appVersion متسقًا مع البنية الفعلية التي يتم نشرها. تصادف أنني أقوم بتطوير مكتبة خطوط أنابيب قابلة لإعادة الاستخدام والتي تضم أدوات بناء مختلفة معًا لإنتاج بنيات قابلة للتكرار - هذه ممارسة شائعة لمؤسسات التكنولوجيا الكبيرة. في حالة الاستخدام الخاصة بي ، تنشئ مكتبة خطوط الأنابيب حاويات عامل الإرساء وتنشرها وتنشرها في النهاية عبر الدفة من خط أنابيب بناء التطبيق (على سبيل المثال ، ضع في اعتبارك إصدار التطبيق 1.0.1-pr-3.1 للبناء الأول للعلاقات العامة الثالثة من أحد التطبيقات ، والذي من المحتمل أن يكون إصدارًا مسبقًا للإصدار 1.0.1).

حتى بعد عمل هذه المسألة حولها في مكتبة خط أنابيب بناء شركتي، وأود بالتأكيد يشعرون بمزيد من الراحة وجود --app-version التبديل بنيت في الحلم. يبدو وكأنه طريقة أكثر مرونة للتعامل مع عمليات النشر. أعني ، لماذا يتعين على النظام الخارجي أو المهندس الدخول في ملف المخطط وتحديث yaml قبل كل عملية نشر إذا كان من الممكن أتمتة بواسطة نظام أساسي لا يمكنه العبث بالأرقام عن طريق الخطأ؟ من وجهة نظري ، يجب أن تتخلى مؤسستي عن وظيفة appVersion بالكامل ، أو أن تتم إضافة حل "قذرة" sed إلى كود مكتبة خطوط الأنابيب لدينا ، لذلك اعتقدت أنني سأشاركها من أجل أي شخص آخر كان يحل هذه المشكلة.

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

لهذا السبب لم يتم حل هذا العلاقات العامة بهذه السهولة. منذ ذلك الحين ، الإصلاح واضح ، لكنه لا يتماشى مع تصميم هيلم. لهذا السبب يتم توفير القليل من الحلول المؤقتة.

وأنت محق بشأن العلم app-version . يجب عليك توفيرها ، ثم يجب على هيلم التعامل مع كل شيء بمفرده.

هل أستطيع ان أسألك سؤال؟ كيف تستخدم هيلم في منتجك؟ عندما تستخدم helm install ؟ كيف بالضبط تستخدمه؟ هل فكرت في استخدام helm package ؟

لقد ألقيت نظرة أخرى على helm package الليلة الماضية. لم يتم بيعها حقًا. sed موجودًا منذ فترة طويلة جدًا وهو مستقر جدًا. كل هذه الأوامر الفرعية tiller / package / install هي جديدة نسبيًا وأقل استقرارًا. للمساعدة في توضيح وجهة نظري ، منذ شهور ، قررت "التأكد من أن أداة الحراثة يمكن أن تنجح" على الرغم من أنني رأيت البرنامج الإضافي لشخص ما تجاوز الحاجة إلى Tiller. نظرت إلى المكون الإضافي على أنه شيء يجب أن يكون أقل شيوعًا ، لكنني كنت أركل نفسي منذ ذلك الحين. لو وثقت في المكون الإضافي ، لكنت سأكون في وضع أفضل بكثير مما أنا عليه الآن. أكد المسؤولون عن الصيانة في Helm أنهم يوافقون على أنه كان تصميمًا غير قابل للاستمرار وسيزول في الإصدارات المستقبلية.

أعتقد أنه سيكون من الخطأ من جانبي استخدام helm package للقيام بهذه العملية البسيطة. ما هي حالة استخدامك لـ package أي حال؟ أشعر كما لو أن المفهوم الكامل لـ helm package يخطئ نقطة إصدارات الويب 2.0 / التحكم في الإصدار عن طريق التعبئة في ملف zip ثنائي في المقام الأول عندما تستفيد مجموعات التكنولوجيا الحديثة من قوة وضع العلامات لتحقيق نفس العملية ولكن بطريقة أصغر حجماً وأكثر قابلية للتدقيق.

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

IRobL

عندما تقول تدريبًا سيئًا ، هل تقول أن الحاجة إلى التفاف أمر القيادة مع البرمجة النصية أمر غير مرغوب فيه؟

نعم. هذا بالضبط.

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

هذا هو بالضبط ما نقوم به أيضًا.

حتى بعد حل هذه المشكلة في مكتبة خطوط الأنابيب الخاصة بشركتي ، سأشعر بالتأكيد براحة أكبر لوجود مفتاح إصدار -app مدمج في Helm

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

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

FWIW ، Tiller لن يكون شيئًا في Helm 3. لقد أشرت إلى هذا لاحقًا في رسالتك ؛ مع ذلك ، أنا أكرر هذا فقط لأنه يظهر أن بناء جملة helm package الخاص بإنشاء "kubernetes binary" وشحنه إلى Tiller ربما يكون ممارسة سيئة.

أعتقد أنه سيكون من الخطأ من جانبي استخدام حزمة الدفة للقيام بهذه العملية البسيطة. ما هي حالة استخدامك للحزمة على أي حال؟

ربما يمكنني الدفاع عن فريق هيلم في هذا الشأن. كان الإحساس الذي أتخذه وراء الدفة طريقة لجعل مطوري التطبيقات يحددون كيفية تشغيل تطبيقاتهم بشكل صحيح من داخل Kubernetes. لهذا السبب يقوم موفرو التطبيقات بتشغيل مستودعات Helm الخاصة بهم والتي يمكنك إضافتها لتنزيل إصدار معين من نشرهم. ربما رأى فريق Helm أن كود التطبيق ورمز البنية التحتية متشابكان لأن فرق الإنتاج المستهدفة المقصودة لن تستخدم Helm في تدفقات العمل اليومية كما نفعل في CI / CD. مثال: نحن نستخدم helm upgrade 130 مرة في اليوم في المتوسط. لا أعتقد أن هذا كان الاستخدام المقصود على الإطلاق.

ربما كان من الأكثر شيوعًا أن يقول الناس ، "أريد فقط تثبيت mysql في kubernetes" وكانت الدفة طريقة سهلة (نسبيًا) للقيام بذلك للأشخاص الذين يعرفون القليل عن kubernetes وكانوا يلعبون بها.

وبالتالي ، فإن helm package كان من المفترض أن يستهلكها هذا الجمهور في النهاية. ترى الأداة بالتأكيد المزيد من الاستخدام في المجالات التي لم يعتقد الفريق (على ما أعتقد) أنها ستلتقط الأداة ، أو لم يقصد استخدامها أبدًا بالطريقة التي هم عليها.

أعتقد أن استخدامي يتبع فلسفة Unix عن كثب لاتخاذ قرار بشأن استخدام أداة لتحقيق أفضل أداء ، ثم التبديل إلى أدوات أخرى (إلخ. sed) عند الاقتضاء.

أنا أعامل Helm بشكل أساسي مثل awk مع مجموعة من kubectl apply -f s بعد ذلك. من الأنظف أن يكون لديك أداة آلية تعتني بالقيم لتجنب الخطأ البشري.

يبدو أنك وأنا نمتلك الكثير من نفس القيم وقد نفعل الكثير من الأشياء المماثلة.

IRobL

الحارث

بالنسبة لي ، tiller غير مقبول. نظرًا لأنه يضيف نقطة تعرض أخرى ، فإن مخاطر الأمان الإضافية ، والأهم من ذلك ، لا يفعل شيئًا سوى إنشاء طريقة أخرى لتطبيق ملفات yaml ، ولكن باستخدام واجهة برمجة تطبيقات مختلفة. تم تصميم Tiller لتأمين ومحاذاة عملية تطبيق حزم Helm ، ولكن مع وجود العديد من المخاطر والبرامج الإضافية (والإصدارات!). لهذا السبب لا يستخدمه Helm the 3rd.

أعتقد أنه سيكون من الخطأ من جانبي استخدام حزمة الدفة للقيام بهذه العملية البسيطة.

أعتقد أنك أضعت فكرتي. دعني احاول مجددا. لماذا صنع sed ؟ لتحويل دفق البيانات. يجب أن يجرد مشكلة التحولات ، مما يمنحك واجهة برمجة التطبيقات (API) والنتيجة لأي مدخلات معينة.

ماذا لو أنشأت برنامجًا نصيًا ، حيث لا يعمل الأمر sed (على سبيل المثال ، لديك خطأ في regex)؟ لذلك توصلت إلى استنتاج ، إنه لا يعمل. هل ستحاول فهم سبب عدم عمل sed من تلقاء نفسه ، أم أنك ستضيف أنبوبًا إضافيًا واحدًا مع البرنامج النصي perl؟

ينطبق الشيء نفسه مع كل حل: يجب أن يوفر واجهة برمجة التطبيقات (API) ، وأخذ المدخلات وتقديم المخرجات ، واستخراج مشكلة واحدة بعيدًا. كما تعلم ، أسلوب يونكس.

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

تضمين التغريدة

نعم ، كلانا يقترب من الدفة مع وضع اهتمامات مماثلة في الاعتبار. لم أكن أدرك حقًا أن جذر الأمر package كان متشابكًا مع الأخطاء التي رصفها الحارث ، شكرًا لمشاركتك هذه الأفكار معي!

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

ما هي منصة البناء الخاصة بك بالمناسبة؟ رمز خط الأنابيب الذي أكتبه مكتوبًا لـ Jenkins كمكتبة عالمية لخطوط الأنابيب.

IRobL المشكلة الأساسية هي: أنك تنظر إلى Helm على أنه برنامج نصي للنشر. لكن هيلم ليس كذلك. هيلم طبقة تجريدية. تأخذ Helm جميع القطع الأثرية الخاصة بك وتطبق كوحدة عمل واحدة على K8s كمنصة.

هيلم هو عامل تعبئة. تم تصميم Helm لتسهيل النشر. يقوم بإنشاء "مثبت" من الأدوات الخاصة بك ، بحيث يمكنك "تثبيته" على نظام التشغيل الخاص بك - K8s.

app-version in install ليس له علاقة بالديون التقنية. ليست هناك حاجة على الإطلاق عندما تريد install أو upgrade عليه. نفس الشيء هو Chart.yml . لا ينبغي تغييره على الإطلاق ، لأنه ملف تكوين افتراضي ، يحتوي على نسخة من المخطط الفعلي ، لكن الرسم البياني ليس هو برنامجك. أنت فقط تستخدمه بشكل خاطئ.

من هذا المنطلق ، لماذا لا تفكر في استخدام package ؟ تبدو معقدة للغاية بالنسبة لك أم ماذا؟

لقد خرجت من الحلقة بشأن هذه المشكلة لبعض الوقت ، لكنني رأيت هذا النوع من النقاط يزداد عدة مرات:

هيلم هو عامل تعبئة. تم تصميم Helm لتسهيل النشر. يقوم بإنشاء "مثبت" من الأدوات الخاصة بك ، بحيث يمكنك "تثبيته" على نظام التشغيل الخاص بك - K8s.

في الأساس ، لا يقوم Helm _ بأي شكل من الأشكال _ بإنشاء مُثبِّت. لا يخلق "ثنائي". لا يُنشئ شيئًا مشابهًا لملف ".deb" أو ملف مشابه. يقوم بإنشاء أرشيف لبعض قوالب بيانات Kubernetes ، مع بعض القيم الافتراضية و / أو المحددة مسبقًا. برنامجك الفعلي لا يعيش في مخطط Helm. لم يتم تعبئتها معها. ليس مضمونًا أن يكون غير قابل للتغيير.

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

هذا هو السبب الأساسي (IMO على الأقل) لتوفر --app-version في helm install و helm upgrade . لماذا يجب عليك حزم الرسم البياني الخاص بك مرة أخرى إذا لم يتغير شيء حرفيًا؟

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

ألق نظرة على Flux على سبيل المثال ، وكيف يعمل Helm Operator. يمكنك جعله يقوم تلقائيًا بتحديث قيمة علامة الصورة - هذا لا يحدّث المخطط ، فقط علامة الصورة التي يتم نشرها.

يقوم بإنشاء أرشيف لبعض قوالب بيانات Kubernetes ، مع بعض القيم الافتراضية و / أو المحددة مسبقًا.

لكن ملف deb هو نفس مجموعة ملفات التكوين والأوامر والبيانات و / أو القيم المحددة مسبقًا. مثل مثبّت MSI أو حتى ، وهو الأقرب ، يبني في نظام حزمة الخروج gento. أيضا ، نفس عبوات المشروب.

إذن ما هو Helm إن لم يكن مدير حزم لـ K8s؟ ما هو الفرق الذي تراه؟

ليس مضمونًا أن يكون غير قابل للتغيير.

ولم لا؟ إذا قمت بتغيير الحزمة بعد إنشاء الحزمة ، فهذا خطأ. إذا قمت بتوفير خيارات إضافية أثناء عملية install/upgrade ، فهذا يعني ، كما هو الحال في جميع أنظمة التعبئة والتغليف.

أرى مخطط Helm كوصف إصدار لبيانات Kubernetes

لديك بالفعل واحدة - GIT. لذا ، لماذا تحتاج إلى خوذة؟

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

في هذا التصميم ، لا يجب التعامل مع appVersion كسمة لبناء Helm Package. يجب معاملته كمعامل تكوين ، في القيم.

ألق نظرة على Flux على سبيل المثال ، وكيف يعمل Helm Operator. يمكنك جعله يقوم تلقائيًا بتحديث قيمة علامة الصورة - هذا لا يحدّث المخطط ، فقط علامة الصورة التي يتم نشرها.

في هذه الحالة ، ستفقد اقتران بيانات البنية التحتية للتطبيق وإصدار التطبيق. منذ ذلك الحين ، لن يؤدي تغيير علامة الصورة إلى ترقية جديدة للقيادة (صححني إذا كان رجال Flux يفعلون ذلك بطريقة أخرى). في هذه الحالة ، سيكون لديك Helm كقالب تكوين. في هذه الحالة ، لا تحتاج إلى --app-version على الإطلاق.

لكن ملف deb هو نفس مجموعة ملفات التكوين والأوامر والبيانات و / أو القيم المحددة مسبقًا. مثل مثبّت MSI أو حتى ، وهو الأقرب ، يبني في نظام حزمة الخروج gento. أيضا ، نفس عبوات المشروب.

وصفك هنا لحزم .deb و .msi يفتقد مكون رئيسي واحد - الشيء الفعلي الذي يتم تثبيته. إذا نظرت إلى محتويات ملف .deb ، ستجد البرنامج المبني - _THE_ البرنامج الذي سيتم تثبيته. بشكل عام (دائمًا في حالة .deb ؟) ، يكون التطبيق الجاري نشره مرتبطًا بشكل جوهري ، وجزء من هذه الحزمة (ليس هو الحال مع الشراب).

تختلف عبوات التخمير ، ولا يمكن مقارنتها حقًا بنفس الطريقة. يعتبر Brew في الواقع أكثر تشابهًا مع Helm حاليًا ، حيث إنه مجرد إرشادات حول كيفية تثبيته ، ومن أين يجب تنزيل المصدر / الحزمة.

لأكون واضحا تماما هنا ؛ مخطط Helm _ غير مرتبط جوهريًا بإصدار تطبيق معين _ ولا يحتوي على الأداة التي يتم نشرها (أي صورة Docker). إنه يحتوي فقط على مرجع له ، ويمكن أن تتغير القيمة الكامنة وراء هذا المرجع (على سبيل المثال ، يمكنك الدفع إلى نفس علامة Docker ، إذا كنت ترغب في ذلك). لذلك ، بغض النظر عن أي شيء ، فإن Helm Chart ليس إصدارًا مُعبأًا من تطبيق ، ولا يرتبط ارتباطًا صارمًا بإصدار معين من التطبيق أيضًا.

ما عليك سوى إلقاء نظرة على إعادة شراء المخططات الثابتة للحصول على مثال. كم عدد التطبيقات التي تتيح لك تجاوز الصورة المستخدمة عبر القيم؟ (كثيرا_)

إذن ما هو Helm إن لم يكن مدير حزم لـ K8s؟ ما هو الفرق الذي تراه؟

إنها أداة تسهل تشكيل نماذج Kubernetes ، وتوزعها وتثبيتها بسهولة. المفتاح هنا هو أن هذا هو كل ما تتعامل معه هيلم - قوائم Kubernetes.

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

المضاعفات الرئيسية التي أراها هي أن هناك حالتا استخدام:

• نشر تطبيقات الطرف الثالث.
• نشر تطبيقات الطرف الأول.

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

في حالة تطبيقات الطرف الأول ، قد يكون لديك طريقة قياسية لنشر فئة من التطبيقات. في آيسلولي ، على سبيل المثال ، نكتب وننشر خدمات Go لدينا جميعًا بنفس الطريقة تقريبًا. لتحقيق هذه الغاية ، نحن قادرون بالفعل على استخدام مخطط واحد الآن لجميع خدمات Go الخاصة بنا المنتشرة في Kubernetes (نستخدم الحل البديل helm package الآن). إذا تغير النهج الذي نتخذه لنشر تطبيقاتنا الخاصة ، فسنقوم بتحديث المخطط. نقوم بإصدار مخططنا باستخدام SemVer ، لذلك لن يتأثر التطبيق الذي لم يتم تحديثه حتى نرغب في تحديثه.

فقط في هذه المذكرة ؛ تم آخر تحديث لمخططنا go-service منذ حوالي شهر. خلال ذلك الوقت ، من المحتمل أن يكون لدينا عشرات إلى مئات من عمليات النشر - كل ذلك دون تغيير هذا المخطط.

في حالة واحدة ، أنت فقط تريد البساطة. في الحالة الأخرى تريد السيطرة ، وسهولة الإدارة.

في هذه الحالة ، ستفقد اقتران بيانات البنية التحتية للتطبيق وإصدار التطبيق. منذ ذلك الحين ، لن يؤدي تغيير علامة الصورة إلى ترقية جديدة للقيادة (صححني إذا كان رجال Flux يفعلون ذلك بطريقة أخرى). في هذه الحالة ، سيكون لديك Helm كقالب تكوين. في هذه الحالة ، لن تحتاج إلى إصدار -app على الإطلاق.

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

helm list أمر مفيد. لا تزال القدرة على معرفة إصدارات التطبيق التي تم نشرها مفيدة بالفعل. بالنسبة لتطبيقاتنا المثبتة حاليًا عبر Helm باستخدام نهج helm package قمنا فقط بتعيين إصدار التطبيق (عبر --app-version على helm package ) بحيث يكون ناتج helm list هو مفيد. لهذا السبب إذا تمكنا من تعيينه على helm install|upgrade فسيكون الأمر أسهل بالنسبة لنا. لن نضطر إلى إحضار المخطط وإعادة تجميعه فقط لتغيير الإصدار.

في الواقع ، ربما يكون helm list والتعامل مع عمليات التراجع هي الأسباب الوحيدة لاستخدام Helm على الإطلاق لبرامج الطرف الأول.

يفتقد وصفك هنا لحزم .deb و .msi مكون رئيسي واحد - الشيء الفعلي الذي يتم تثبيته.

"التثبيت" هو عملية إعداد التسهيلات الضرورية (المجلدات ، التكوينات ، الثنائيات ، جلب db ، تحديث / ترحيل البيانات) على النظام الأساسي الهدف.

تتولى deb كل ذلك. وكذلك الحال بالنسبة لمجموعة هيلم. ماذا تقصد بأن حزمة هيلم ليست "مثبتة بالفعل"؟

إذا نظرت إلى محتويات ملف .deb ، ستجد البرنامج المدمج - البرنامج الذي سيتم تثبيته.

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

يعتبر Brew في الواقع أكثر تشابهًا مع Helm حاليًا ، حيث إنه مجرد إرشادات حول كيفية تثبيته ، ومن أين يجب تنزيل المصدر / الحزمة.

بالضبط. هل تحاول إقناعي أن Brew ليس مدير حزم؟

لأكون واضحا تماما هنا ؛ مخطط Helm _ ليس مرتبطًا جوهريًا بإصدار تطبيق معين ...
كم عدد التطبيقات التي تتيح لك تجاوز الصورة المستخدمة عبر القيم؟ (كثيرا)

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

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

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

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

نعم ، هذه هي النقطة المركزية: هل هو مرغوب فيه لأي منتج؟

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

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

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

نشر تطبيقات الطرف الثالث.

سأكون سعيدًا جدًا إذا كان بإمكاني تثبيت أي إصدار من PSQL / MySQL باستخدام مخطط Helm فقط. سيكون من الأسهل بكثير الحفاظ على المشاريع القديمة ، وإدخال البنية التحتية للمبتدئين. سيكون من الأسهل أن يتم إعلامك بتحديثات المخطط. لماذا لدينا الكثير من ملفات tar.gz لكل إصدار للثنائيات ، ولكن لا يمكننا الحصول على نفس مجموعة ملفات tar.gz لحزم Helm؟

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

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

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

عادةً ما أرغب في تقديم PR ولا يبدو أنني أشتكي من شيء ما ، لكنني لست متأكدًا مما يحدث مع تغييرات التوثيق 3.0.

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

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

"التثبيت" هو عملية إعداد التسهيلات الضرورية (المجلدات ، التكوينات ، الثنائيات ، جلب db ، تحديث / ترحيل البيانات) على النظام الأساسي الهدف.

تتولى deb كل ذلك. وكذلك الحال بالنسبة لمجموعة هيلم. ماذا تقصد بأن حزمة هيلم ليست "مثبتة بالفعل"؟

لا أقصد أن مخطط Helm نفسه غير مثبت - كل ما أقوله هو أن مخطط Helm لا يحتوي على التطبيق الفعلي الذي تنشره. لا يتم تجميع صورة Docker في مخطط Helm. تم سحبه بواسطة Kubernetes من بعض المصادر الخارجية.

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

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

إذا كان لديك مثال على جزء من برنامج Linux تم تجميعه في .deb حيث يذهب .deb ويقوم بتنزيل البرنامج لتثبيته كجزء من عملية تثبيت ملف .deb ، إذن أود حقًا أن أراه - لأنه شيء لم أجده حرفيًا من قبل في سنوات عديدة من استخدام Linux.

بالضبط. هل تحاول إقناعي أن Brew ليس مدير حزم؟

لا. كل ما أقوله هو أنه مثل Helm ، فإن النصوص المقدمة لتثبيت البرنامج عبر Brew هي مجرد نصوص. يتم إنشاء التطبيقات وحزمها وتوزيعها بشكل منفصل ويتم سحبها بواسطة تلك البرامج النصية. هذا لا يجعل Brew أي أقل من مدير الحزم ، تمامًا مثل ما قلته لا يجعل Helm أقل من مدير حزم Kubernetes. ليس هذا هو الهدف من هذه المشكلة على الرغم من أننا لا نناقش ما إذا كان Helm مدير حزم أم لا ، فنحن نحاول تحديد ما إذا كان يجب إضافة علامة --app-version إلى helm install|upgrade لتسهيل حالة الاستخدام الشائعة.

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

أعتذر ، أنا غير واضح ما تعنيه بهذا. ما الذي عفا عليه الزمن / معقد / يصعب إدارته؟

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

حسنًا ، مرة أخرى ، يتمثل الاختلاف في الأساس في أن كل تلك الأشياء التي ذكرتها مرتبطة ارتباطًا جوهريًا. أنت بحاجة إلى كل التعليمات البرمجية المصدر لتشغيل التطبيق - وليس فقط ما تغير. أنت لا تحزم ملف Dockerfile ، لذا لست متأكدًا مما تدور حوله هذه النقطة - ولكنك غالبًا ما تستخدم نفس ملف Docker دون تغييره لإنشاء إصدارات جديدة من الصور (أعني ، لماذا تهتم بالأتمتة إذا كان عليك تغيير شيء يدويًا كل الوقت ، أليس كذلك؟). مع كل هذا النوع من الأشياء ، أنت تنشئ شيئًا يلخص كل ما تحتاجه ، بحيث يمكن نشره بمعزل عن غيره. لذا يمكنك القيام بأشياء مثل تدوير عقدة جديدة ، ونشرها بنفس الطريقة التي تفعل بها مع عقدة موجودة ، وما إلى ذلك.

هناك _lot_ من الامتيازات ، كما أنا متأكد من أنك تعلم بالفعل ، تزيد عن استخدام التحميل القديم عبر FTP.

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

لا يتم تجميع صورة Docker في مخطط Helm

في الواقع ، أتمنى أن يكون الأمر على هذا النحو. لكنها ليست الآن. رؤيتي هي أن K8s سوف / يجب أن تكون منصة ، والتي ستدمج Helm (لذلك لن يكون هناك Helm) كواجهة برمجة تطبيقات لتثبيت الحزم: ستحتاج إلى حزم الأشياء الخاصة بك في الأرشيف وتثبيتها. العودة إلى بساطة ملفات deb ، ولكن مع عزل مناسب وموارد k8s كمواطنين من الدرجة الأولى.

ملف .deb هو أرشيف AR
يمكنك استخراجه وإلقاء نظرة على المحتويات
وهي في النهاية عبارة عن بعض البيانات الوصفية
وبعض الملفات

مثل .... حزمة هيلم!

إذا كان لديك ... deb حيث ينتقل ملف .deb ويقوم بتنزيل البرنامج لتثبيته كجزء من عملية تثبيت ملف .deb ...
هذا مثل تثبيت برنامج التثبيت. ...

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

• يحتوي Brew على YAML كحزمة ، ولكنه يجلب الثنائيات من التخزين البعيد
• Emerge (gentoo) له euild كتعريف ، والذي يقوم بتنزيل حتى نسخ git

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

لكن من فضلك ، لا تفوت النقطة الرئيسية: لا يهم ! حتى الحزمة الفارغة ، التي تحتوي على مرجع فقط ، هي حزمة. ربما تقبل مصطلح آخر ، المثبت؟

أنا أقول إنه مثل Helm ، فإن النصوص المقدمة لتثبيت البرنامج عبر Brew هي مجرد نصوص
يتم إنشاء التطبيقات وحزمها وتوزيعها بشكل منفصل ويتم سحبها بواسطة تلك البرامج النصية

ولدينا جميعًا نفس خط الأنابيب - لبناء صورة عامل ميناء.

نحن نحاول تحديد ما إذا كان يجب إضافة علامة --app-version إلى helm install | الترقية لتسهيل حالة الاستخدام الشائعة.

هذا مفتاح. لكن كيف يمكننا أن نقرر؟ يجب أن نسأل سؤالين:

• هل هو ممكن؟ نعم
• هل هو الشيء الصحيح لفعله؟ نعم؟ رقم؟

إذا كان هناك أشخاص يقومون بشيء ما ، فهل هذا يعني أنه أمر جيد؟ من أجل إحراز تقدم ، نحتاج إلى التشكيك في كل شيء.

أعتذر ، أنا غير واضح ما تعنيه بهذا. ما الذي عفا عليه الزمن / معقد / يصعب إدارته؟

دع المشروع على Brew ، نظرًا لأن Brew قريب جدًا من Helm وقد تم استخدامه على نطاق واسع بالفعل. يمكنك المشروع على Gentroo Ebuilds أو deb ، الصورة لن تتغير.

• عفا عليها الزمن. متى كانت آخر مرة اضطررت فيها إلى تثبيت MySQL / PSQL يدويًا؟ لماذا انتقلنا منها؟ هذه الأسباب ، برعم.
• مركب. هذا هو أحد "الأسباب": تحتاج إلى إعداد البنية التحتية بشكل مستقل ، وتحتاج إلى معرفة أيها يعمل بشكل أفضل مع إصدارات البرامج. ستحتاج أحيانًا إلى تخصيص البنية الأساسية لتشغيل إصدار برنامج معين. لماذا تهتم؟ لماذا لا تفوض السؤال كله؟
• من الصعب إدارتها. ستحتاج إلى إدارة كلٍ من البنية الأساسية وإصدارات التطبيق عندما لا يكون لديك سوى قطعة أثرية واحدة. لماذا تجعل حياتك أصعب؟

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

حسنًا ، مرة أخرى ، يتمثل الاختلاف في الأساس في أن كل تلك الأشياء التي ذكرتها مرتبطة ارتباطًا جوهريًا.

ليس دائما. على سبيل المثال ، يمكن أن تحتوي صورة عامل الإرساء على SSR BE والإشارة إلى CDN.

Dockerfile ، لذلك لست متأكدًا مما تدور حوله هذه النقطة - ولكنك غالبًا ما تستخدم نفس Dockerfile دون تغييره لإنشاء إصدارات جديدة من الصور (أعني ، لماذا تهتم بالأتمتة إذا كان عليك تغيير شيء ما يدويًا في كل مرة ، أليس كذلك؟).

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

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

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

في النهاية ، ليس هناك فرق كبير في كلتا الحالتين.

أعتقد ، هو كذلك. ربما لا يتعلق الأمر بالكثير من الصفقات في قاعدة البيانات ، لكنه سيؤثر على تطور النقل بالحاويات.

لا يتم تجميع صورة Docker في مخطط Helm

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

بالعودة إلى أرض الأمثلة ، لنفترض أن لديك تطبيقًا قمت بإصداره داخليًا كـ 1.9.9 يعمل على مخطط تم إصداره في 1.2.5 . حتى لا يكون هناك أي لبس ، فإن صورة Docker لحاوية التطبيق هي fakeshaA .

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

قبل تغيير المخطط ، لديك Artifact A ربط إصدار التطبيق 1.9.9 بإصدار البنية التحتية 1.2.5 . الآن قمت بتغيير الرسم البياني ... _ your Helm Chart هو الآن v. 1.3.0 _ وستنتج قطعة أثرية تربط 1.9.9 بإصدار البنية التحتية 1.3.0 . سنسمي هذا Artifact B

عندما يتم نشر الكود لـ 2.0.0 مع صورة Docker sha fakeShaB ، ستقوم بإنشاء قطعة أثرية أخرى تربط 2.0.0 بالإصدار أدناه 1.3.0 . هذا هو Artifact C

لنفترض الآن أنه اتضح أن هناك مشكلة لا تفهمها تمامًا مع الإصدار 2.0.0 وعليك التراجع. يمكنك التراجع باستخدام Artifact B ... لكن هذا لا يحل المشكلة لذا يمكنك التراجع مرة أخرى إلى Artifact A ويتم حل المشكلة.

المشكلة الوحيدة التي تواجهها هي ما إذا كان Docker Registry الذي تشير إليه القطع الأثرية لا يزال يحتوي على الصورة المشار إليها في تلك القطع الأثرية أم لا.

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

iorlas :

دعنا نضع جانبًا المقارنات .deb . أعتقد أن الأمر يتعلق بنا فقط.

ليس دائما. على سبيل المثال ، يمكن أن تحتوي صورة عامل الإرساء على SSR BE والإشارة إلى CDN.

هذا حقيقي جدأ. المزيد عن ذلك لاحقًا بالرغم من ذلك.

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

يمكنك فعل ذلك ، ولكن هذا لأن المنتج في نهاية عملية الإنشاء (أي صورة Docker) يعتمد على _ كلاهما _ ملف Docker والشيء الذي تضعه فيه. لا يمكن للصورة أن توجد بدون هذين المكونين.

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

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

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

في الواقع ، أتمنى أن يكون الأمر على هذا النحو. لكنها ليست الآن.

إذا كان هذا هو الحال ، وقام مخطط Helm بالفعل بتجميع كل ما تم نشره (لقد ذكرت CDN سابقًا ، لكنك لم تنشر ذلك إلى Kubernetes بعد ذلك ، لذلك لن يتم عرضه في المخطط الخاص بك حتى الآن) ، إذن أعتقد ذلك هذه المحادثة لن تحدث. مخطط Helm _ سيكون مرتبطًا بشكل جوهري بإصدار التطبيق الجاري نشره - تمامًا مثل إنشاء صورة Docker. لإنشاء مخطط Helm في هذا السيناريو ، ستتم مطالبتك بإعادة بنائه عندما يتغير تطبيقك ، وعند هذه النقطة ليس هناك شك. لا يمكنك استخدام Helm بالطريقة التي أستخدمها بها اليوم - سيكون الأمر أكثر وضوحًا بهذه الطريقة.

هذا ليس الواقع بالرغم من ذلك. إنها ليست الطريقة التي يعمل بها هيلم ، ولا أعلم أنه سينتهي به الأمر في النهاية أيضًا. لكن لا تقل أبدا ، أليس كذلك؟

jrkarnes :

لم يتم حزم الصورة نفسها ، ولكن المرجع (اقرأ كـ: دبوس).

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

بالتأكيد ، يمكننا أن نكون متحذلقين وننشغل بما إذا كانت الصورة الحرفية ذات الأحجام المختلفة (من ميغابايت إلى الجيجابايت) مدرجة في الأداة الفنية لحزمة الدفة (المفسد: ليست كذلك) ،

لا أعتقد أننا متحذلق بشأن أي شيء - كما أشرت بالفعل ، سيكون من الخطأ من الناحية الواقعية القول إن صورة Docker معبأة داخل مخطط Helm "مبني".

"تم تضمين إصدار معين من رمز التطبيق في حزمة الدفة" لا يزال صحيحًا بشكل أساسي.

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

بالعودة إلى أرض الأمثلة ، [...] وتحل المشكلة.

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

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

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

مرة أخرى ، كما قلت لـ iorlas ، السؤال هو ، هل يجب أن يتكيف هيلم؟ ما هو سبب عدم تمكين حالة الاستخدام هذه؟ إذا كان السبب هو "لأنه ليس كذلك حاليًا" فهذا سبب سيئ جدًا إذا سألتني. لا يبدو أن أيًا من هذه المناقشة قد أجاب حتى الآن على هذا السؤال.

... يعتمد المنتج في نهاية عملية الإنشاء (أي صورة Docker) على كل من Dockerfile والشيء الذي تضعه فيه. ... لا يمكن أن توجد صورة بدون هذين المكونين.

لذا ... تحتاج حزمة Helm إلى إصدار المخطط والتطبيق (= صورة Docker) ولا يمكن أن توجد بدونها.

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

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

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

لكني أحاول فقط توضيح وجهة نظري أنها ليست مرتبطة على الإطلاق.

نعم نعم! هذا لطيف حقًا لدينا شركاؤنا مستعدون لمناقشة كل شيء بالتفاصيل. بدونك ، بدون الإسقاطات والتأكيدات ، لن نعيش نبتة مستقبلية 😃

لا أعتقد أن هذا ادعاء جريء ، إنه يحدث - إنها حقيقة بالفعل. ... لذلك كما قلت من قبل ، كل هذا يعود إلى ؛ هل يريد مشرفو Helm تمكين حالة الاستخدام هذه أم لا - لا يوجد شيء آخر لها.

حقيقة. من أجل إجراء مثل هذا التغيير وقبوله ، يجب تقييمه: هل من الصواب القيام به ؟

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

لذلك ، أنا لست ضد هذا النهج. أرى كيف يمكن أن يعيش (انظر اقتراحي بـ helm run ). ولكن في حين أن لدينا فرصة للقيام بالتدخل ، وربما إصلاح الصناعة بأكملها بينما لم يفت الأوان بعد ، فإنني سأقيم كل استخدام ، وأناقش أي عيوب ومشكلات.

لإنشاء مخطط Helm في هذا السيناريو ، سيُطلب منك إعادة بنائه عندما يتغير تطبيقك

نعم. حتى الآن يمكن أن يكون الأمر كذلك. لدينا خط أنابيب واحد حيث بدلاً من push نقوم بعمل save / load لصورة عامل الإرساء. وهي تعمل بشكل جيد. لا أشعر برغبة في ذلك الآن ، لكنها في الأساس طريقة أنظف كثيرًا. تكمن المشكلة في أن K8s ستظل بحاجة إلى تسجيل عامل ميناء بعيد كحافلة لنقل صورة عامل الإرساء "المبدئ".

دعونا نحصر تركيزنا ، يا رفاق

سيكون مخطط Helm مرتبطًا بشكل جوهري بإصدار التطبيق الجاري نشره - تمامًا مثل إنشاء صورة Docker.

هذا هو الاختلاف الرئيسي هنا. و seeruk هو مسمر. ويمكننا التركيز عليه. اسمحوا لي أن أعيد صياغتها في الحقائق:

1. صورة Docker غير مرتبطة بحزمة Helm. فقط بالإشارة إليه.
2. هذا يعطي فرصة لتحرير هذه المسارات بشكل مستقل.

الأسئلة الرئيسية:

1. ما هي مخاطر النهج المستقل؟ (على سبيل المثال ، ماذا لو استخدمه بعض المطورين ، ما الحجج التي سنقولها ضده)
2. كيف يحل نهج التعبئة والتغليف ذلك؟
3. ما هي تكلفة؟
4. كيف نرى مستقبل النقل بالحاويات في هذا السؤال بالذات؟

seeruk :

مرة أخرى ، كما قلت لـ iorlas ، السؤال هو ، هل يجب أن يتكيف هيلم؟ ما هو سبب عدم تمكين حالة الاستخدام هذه؟ إذا كان السبب هو "لأنه ليس كذلك حاليًا" فهذا سبب سيئ جدًا إذا سألتني. لا يبدو أن أيًا من هذه المناقشة قد أجاب حتى الآن على هذا السؤال.

أنت تقدم الكثير من التوضيحات والنقاط الرائعة. أنا شخصياً أعتقد أن هيلم يجب أن يتكيف. CI / CD هو مستقبل كيفية بناء البرامج ، وبصراحة مع التعاملات مثل --atomic خوذة بالفعل أكثر مرونة كأداة نشر موثوقة. على الرغم من أن هذه المشكلة قديمة جدًا ، لذا أعتقد أن دمج العلاقات العامة ليس "الخطوة التالية" في العملية.

هل يمكن إنشاء مكون إضافي ، على سبيل المثال helm-ci-cd لهذه الميزة الخاصة --app-version (ربما يمكن لـ jrkarnes التحدث إلى هذا كمساهم في العلاقات العامة)؟ أعتقد أن احتياجات المجتمع حول إخراج Tiller لم يتم الاعتراف بها حقًا إلا بعد إقلاع هذا المكون الإضافي. هناك العديد من المشكلات الأخرى المتعلقة بـ Helm والتي يمكن تجاوزها بسهولة والتي قد تكون مرشحة جيدة أخرى مقابل helm-ci-cd تبدو ثنائية install/ upgrade التي تم توحيدها بالفعل بواسطة CI / CD ppl.

حتى لو لم يكن المحول --app-version قيمة مضافة مباشرة للمستخدمين النهائيين الذين يحاولون تثبيت تطبيق k8s دون الحاجة إلى إلقاء نظرة على ملفات القوالب (والتي ، بالمناسبة ، لم تنجح أبدًا في تحقيقها أنا بسبب الحاجة إلى إضافة سياسات الشبكة لتكون متوافقة مع البنية التحتية لعملي k8s) لا يزال المستخدم النهائي يحصل على قيمة أكبر لأن الشخص الذي أنشأ هذا المخطط كان لديه وقت أسهل في القيام بذلك بسبب ميزات helm ci / cd التي تجعل البناء مستقرًا وبرامج موثوقة أسهل.

لقد قرأنا للتو في Chart.yaml مع groovy ثم قمنا بتعيين إصدار التطبيق والكتابة فوق الملف أثناء وقت النشر. ثم قم بترقية الدفة. سيكون من الرائع لو كانت جزءًا من دفة القيادة لكنني لن أعتمد عليها.

وجدت هذا عبر Google'ing. نفس القارب في الواقع.

إذا كان verison: هو إصدار المخطط ، فهذا يعني أن هذا الإصدار يتغير عندما تتغير YAMLs في المخطط. نظرًا لأن المخطط عبارة عن قالب به قيم قابلة للتكوين ، فمن الآمن افتراض أنه يمكنك استخدام الرسم البياني 1.3 لنشر تطبيقات من إصدارات متعددة ، 1.2 ، 1.3 ، 1.6 ، 1.8 ، إلخ ، دون كل تعديل لملفات YAML في المخطط.

يتوفر الآن appVersion: مشفرًا بشكل ثابت داخل Chart.yaml - مما يجبرك على تحرير ملف مخطط من أجل تحديث (وإظهار) إصدار التطبيق المنشور.

هناك بالتأكيد حاجة لخيار --app-version CLI يمكننا استخدامه داخل قوالب الرسم البياني للإشارة إلى إصدار _application_ لنشر إصدارات مختلفة بنفس الرسم البياني version: 1.3.0 .

تضمين التغريدة

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

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

لقد قلتها أكثر في المناقشة وأعتقد أنها تستحق التكرار:

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

مخطط رأس الطرف الأول (أحب استخدام MySQL لذلك سأستمر في استخدامه) بدون تكوين يجب أن يقوم بتثبيت مورد في مجموعة كما وصفه منشئ المخطط وقصده . بالنظر إلى الرسم البياني الفعلي لـ mysql ، هناك

• image (الافتراضي mysql )
• imageTag (الافتراضي 5.7.14 )

ثم ، في ملفهم Chart.yaml :

apiVersion: v1
name: mysql
version: 1.4.0
appVersion: 5.7.27

لاحظ أن appVersion و imageTag الافتراضي غير متطابقين . إذا قمت بتشغيل helm list فسوف أحصل على تقرير يفيد بأن "إصدار التطبيق" (قراءة ؛ إصدار المحرك) هو حالة _ لا تعكس إصدار التطبيق الفعلي المثبت في المجموعة _.

لا تحتاج في أي مكان هناك إلى رسم بياني وإصدار تطبيق ليتم ربطهما بشكل صارم (تمامًا كما هو الحال في الوقت الحالي ، لست بحاجة إلى أن يكونا كذلك).

هذا صحيح؛ وفي رأيي ، عيب في التصميم.

مرة أخرى ، كما قلت لـ iorlas ، السؤال هو ، هل يجب أن يتكيف هيلم؟

نعم. سأتناول بعض الاقتراحات في لحظة.

IRobL

هل سيكون إنشاء مكون إضافي ، على سبيل المثال helm-ci-cd ممكنًا لهذه الميزة الخاصة بإصدار التطبيق (

أنت تجيب على سؤالك بـ:

حتى إذا لم يكن رمز التبديل --app-version عبارة عن قيمة مضافة مباشرة للمستخدمين النهائيين الذين يحاولون تثبيت تطبيق k8s دون الحاجة إلى إلقاء نظرة على ملفات القوالب ، فلا يزال المستخدم النهائي يحصل على قيمة أكبر لأن الشخص الذي لقد كان من الأسهل في إنشاء هذا المخطط القيام بذلك بسبب ميزات helm ci / cd التي تجعل بناء برامج مستقرة وموثوقة أسهل.

إذا كان علينا القيام بذلك كمكوِّن إضافي لتصحيح الوظيفة ، فسأدافع عن هذا النهج ؛ ومع ذلك ، أعتقد أن هذا يعالج المشكلة الخاطئة. كما قلت سابقًا لـ seeruk ، أعتقد أن امتلاك appVersion خاصية جوهرية في ملف Chart.yaml غير القابل للتغيير هو عيب في التصميم. appVersion هي خاصية لـ image التي يتم تثبيتها في الكتلة من خلال المخطط ، وهي مشتقة بطريقة ما من الصورة المشار إليها بـ tag .

عند التفكير في مكون إضافي helm-ci ، ما الميزات أو الوظائف الإضافية الأخرى التي تتوقع أن تكون هناك؟ لا أعتقد أن مجرد تبديل appVersion من خصائص Chart.yaml غير القابلة للتغيير يكفي لقيمة مضافة لضمان كونه مكونًا إضافيًا.

IRobL و seeruk معًا:

أعتقد أن آرائنا المختلفة تأتي من من نراه هو المستخدم النهائي الأكثر شيوعًا للدفة. إذا كان من المفترض للمستخدم النهائي أن يكون شخص لا تنوي أن تفعل الكثير من التكوين أو حفر في قوالب، ثم helm ls قد لا تكون مفيدة بشكل خاص والنقطة هي موضع نقاش.

ومع ذلك ... إذا كنت تستخدم helm كأداة إدارية ومساعد لإدارة مجموعة أو إذا كنت تستخدم Helm في سياق CI / CD ، فإن مفتاح التبديل --appVersion ينتهي بكثرة أكثر فائدة وبالتالي نقطة اهتمام (وتكوين) ،

في عالم مثالي ، أود أن أؤكد أن appVersion يجب أن يكون خاصية مشتقة وأن تأتي من بيانات وصفية لصورة docker ؛ هذا ليس من الممكن أن تقوم به الدفة ، بسبب عدم وجود خلاف.

لما قلته عنه

نعم. سأتناول بعض الاقتراحات في لحظة ...
... عند التفكير في مكون إضافي helm-ci ، ما الميزات أو الوظائف الإضافية الأخرى التي تتوقع وجودها؟

لدي قائمة شخصية قد تكون نقطة انطلاق جيدة:

• تشغيل helm في الوضع CICD لن يقارن _فقط_ حالة الحزم التي تم إصدارها مسبقًا مقابل ما يتم تطبيقه حاليًا. . بدلاً من ذلك ، سيتم تطبيق كل عملية نشر لإصدار بشكل كامل على كل بيان تم تصميمه وفقًا لنموذج عند تشغيل upgrade .
• يجب أن يلف helm-cicd أوامر kubernetes الأساسية. لا يمكنني حساب عدد المرات التي حاولت فيها تشغيل helm describe أو helm logs .
• يجب أن يسمح لي helm-cicd بمعرفة نتائج الأوامر عند تشغيلها بواسطة مستخدم مختلف. إذا كنا نستخدم RBAC ، أود أن أرى ما يحدث عندما يحاول مستخدم غير مصدق القيام بشيء ما.
• يجب أن يتمكن helm-cicd من تحليل مساحة الاسم إلى مجموعة من البيانات لتحريرها لاحقًا.
• يجب أن يكون helm-cicd قادرًا على _transplant_ إصدارًا في مساحة اسم.

هؤلاء هم الكبار ... لكن مناقشة مكون إضافي كامل helm-ci خارج نطاق هذا العدد / العلاقات العامة (حاليًا).

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

مشغول جدًا في وقتي الآن ، لكن أريد أن أصحح لك بعض النقاط. تضمين التغريدة

أعتقد أن وجود appVersion يكون خاصية جوهرية في ملف Chart.yaml الثابت هو عيب في التصميم

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

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

_لماذا أعتقد أنه مصمم على هذا النحو؟ تم تعيين نفس helm list لعرض إصدارات الحزم المثبتة الحالية.

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

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

مرة أخرى ، كما قلت لـ iorlas ، السؤال هو ، هل يجب أن يتكيف هيلم؟
نعم. سأتناول بعض الاقتراحات في لحظة.

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

في عالم مثالي ، أود أن أزعم أن appVersion يجب أن يكون خاصية مشتقة وأن يأتي من البيانات الوصفية لصور عامل الإرساء ؛ هذا ليس من الممكن أن تقوم به الدفة ، بسبب عدم وجود خلاف.

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

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

لدي قائمة شخصية قد تكون نقطة انطلاق جيدة

أعتقد أن لديك العديد من الاقتراحات ، لكنها تشعر أنها تعيش شوكة هيلم أكثر ، بدلاً من بعض المكونات الإضافية البرية. أود أن أقول أنه لا علاقة له بـ CI of CD حصريًا. سأجادل بعدم إنشاء مثل هذا الشوكة / المكون الإضافي ، لكنني سأناقش الحلول المناسبة والتوصل إليها. لا أحد يحتاج إلى 3 مفترقات Helm ، مع الأخذ في الاعتبار أن المجتمع الحالي ليس بهذه الضخامة في الوقت الحالي.

يرجى الانتباه!

حسنًا ، لقد فكرنا كثيرًا هناك وهناك. أعتقد أن أفضل سيناريو هو الحصول على:

• القدرة على تغيير إصدار التطبيق ، دون الحاجة إلى إنشاء حزم أولاً
• القدرة على رؤية إصدار التطبيق المناسب في helm ls
• اسمح لأي واجهة برمجة تطبيقات (مثل عامل Helm) بتحديد / ترقية إصدار التطبيق بدون الحالة الوسطى

لدينا طريقتان مقدمتان:

1. helm install لتثبيت حزمة. وهو يدعم تثبيت المخطط أيضًا ، ولكنه محدود. دعونا نبسط helm install ونتركه يخدم الغرض منه - تثبيت الحزم. ثانيًا ، دعنا نضيف helm run ، والقصد من ذلك هو توفير تدفق مبسط: اجمع بين helm package و helm run ، وقم بتوفير وسيطات الأمرين ، لكن قم بتصفية تلك التي ليس لها معنى في مثل هذه الحالة .
2. أضف app-version إلى helm install cmd. سيؤدي ذلك إلى تضخيم واجهة برمجة التطبيقات هذه وإخفاء فكرة استخدام الحزم ، وسوف يخفي (كما هو الحال الآن) أيديولوجية استخدام الحزم كمثبِّتات ، وهو أمر منطقي تمامًا على الأقل بالنسبة لبعض المشاريع ، إن لم يكن معظمها.

هل يمكننا أن نتفق على أن هذين النهجين سيحلان جميع الصعوبات التي نواجهها الآن؟

يعد المكون الإضافي حلاً بديلاً لميزة مفقودة لا يرغب المطورون الأساسيون في دعمها أو ليس لديهم وقت لذلك ، لذلك لا يهمني ما إذا كان مكونًا إضافيًا.

تم تصميم Helm وفقًا لهذه الأيديولوجية ، للتعامل مع K8s على أنها نظام تشغيل وحزمة كمثبت / محدث لتطبيقك.

ووه. فهمت. من المفترض أن يكون مخطط الدفة [الحزمة] بمثابة "دورة في الدقيقة" [لكل كلمة] لـ Kubernetes. ليس الانطباع الذي حصلت عليه تمامًا: يستخدم helm الرسوم البيانية لنشر التطبيق. المخطط / الحزمة هو التطبيق "مهيأ لـ k8s."

أنا سعيد بهذا. إنه أمر منطقي - نحتاج الآن فقط إلى تحديث خادم الإنشاء الخاص بنا لزيادة إصدار التطبيق أثناء قيامنا ببناء حاويات جديدة:

• حاوية الإنشاء - العلامة "v1.2"
• تحديث Chart.yaml - appVersion: "v1.2" --- أرى أنه يوجد أمر helm package --app-version بالفعل.
• مخطط الحزمة: helm package --app-version v1.2 => حزمة [مخطط] -v1.2.tgz (على سبيل المثال "حزمة [مخطط] -v1.2.rpm")
• نشر الحزمة باستخدام خوادم النشر ، حزمة تثبيت helm [مخطط] -v1.2 (على سبيل المثال ، apt install [email protected])

الآن ، هل أنا مخطئ في فهم أي من هذا؟ إذا كانت package-v1.2 ليست v1.2 appVersion ، فلماذا لا؟ ألن يكون هذا هو القصد؟ على سبيل المثال ، rpm هو إصدار من التطبيق ، وليس حزمة (مخطط).

تعديل:

إذا كانت package-v1.2 ليست v1.2 appVersion ، فلماذا لا؟ ألن يكون هذا هو القصد؟

الآن أرى سبب تعليق الناس على Chart.version و Chart.appVersion في انسجام تام. يمكن أن تسير الوسيطات في كلا الاتجاهين هنا ... تطبيق به بنية "مخطط" مستقرة ، تتوقع أن تقوم package-v1.2 بتغيير أرقام إصداراتها. ولكن يمكنك أيضًا أن تجادل بأن package-v1.2 سيكون رقم إصدار المخطط - عندما تتغير ملفات yaml.

كيف تدير إصدار الرسم البياني الثابت (1.2) ، والذي يميز عن إصدار التطبيق المتزايد (1.6)؟ هل سيكون package-[version] 1.2؟ أو 1.6؟ لنفترض أنك قمت بنشر إصدار 1.2 من المخطط ولكن تم تغيير appVersion على العبوة: helm package --app-version 1.6 ؟

➜  chart git:(master) ✗ helm package --app-version 1.5 nginx
Successfully packaged chart and saved it to: /Users/Documents/source/docker/nginx/chart/nginx-0.1.0.tgz

:(

.... محيرة جدا.

من المفترض أن يكون مخطط الدفة [الحزمة] بمثابة "دورة في الدقيقة" [لكل كلمة] لـ Kubernetes

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

الآن ، هل أنا مخطئ في فهم أي من هذا؟ إذا كانت package-v1.2 ليست v1.2 appVersion ، فلماذا لا؟ ألن يكون هذا هو القصد؟ على سبيل المثال ، rpm هو إصدار من التطبيق ، وليس حزمة (مخطط).

هذه مشكلة تتعلق بمناقشة أخرى ، ولكن سيتم تسمية الحزمة حاليًا باسم إصدار المخطط ، وليس إصدار التطبيق. لا أعرف سبب ذلك ، أشعر أنه يجب أن يكون بطريقة أخرى. أعتقد أنها قضية تاريخية ، لكن في رأيي ، كما في مشكلتك ، يجب أن تكون package-{app-version}.tgz .

حسب رسائلي السابقة ، هناك 4 مكونات للإصدار:

• جدول
• تطبيق
• طرد
• يطلق

يعد إصدار كل هذه الأشياء بشكل مستقل أمرًا مزعجًا ، ولكن هذه هي الطريقة التي تعمل بها الآن. باستثناء واحد: تم إصدار الحزمة بعد إصدار المخطط.

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

تضمين التغريدة

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

لقد استغرقت أسبوعين للتفكير في هذا البيان وأنا أتفق معك بنسبة 100٪. بالإضافة إلى ذلك ، فهمت الآن من أين ينشأ اختلافنا في الآراء من ...

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

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

على الرغم من أننا يجب أن نستخدم في كثير من الأحيان helm template لمعرفة كيفية نشر الرسم البياني المحتمل ، إلا أن هناك فائدة كبيرة في مشاهدته يحدث vi-ca-vi run الذي يحتوي على هدف مزدوج لكوننا نجمًا في خطوط أنابيب التطوير (حيث لا نريد بالضرورة الاحتفاظ بحزمة لأنه ليس لها قيمة إذا كانت السرعة عالية جدًا).

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

كما قلت ، في عالم مثالي ، سيتم استبطان نسخة الكائن المثبت. هذا مع ذلك يعطيني فكرة.

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

قرأت جميع التعليقات وليس لدي رأي مؤهل بالكامل في هذا الشأن.

لقد وصلت إلى هنا لأن شركتي تحتفظ بمستودع Helm خاص و 90٪ من مخططاتنا هي في الأساس عملية نشر واحدة لها مواصفات حاوية واحدة. في هذه الحالات ، إذا تمكنا من استخدام appVersion لسرد علامة الصورة ، فإننا نتجنب تكرار متغير وسنكون قادرين على رؤية هذا الإصدار يعمل helm version .

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

بناءً على الطلب ، سأقوم بتضمين ردي الأخير من سلسلة الرسائل السابقة ليتمكن الآخرون من عرضها

همم. هذا هو المكان الذي تبدأ فيه الأشياء في التعارض مع بعضها البعض عندما تبدأ في ربط appVersion بعلامة Docker (ارتباط منطقي). هذا هو المكان الذي نواجه فيه مشكلة ، أي سيناريو التطوير الذي ذكرته أعلاه. نظرًا لأن version يجب أن يكون SemVer ، فلا يمكننا ببساطة استخدام علامات Docker كمخطط version .

كيف يمكننا إنشاء اختلاف في الإصدار المرئي للمطورين عندما لا يظهر appVersion في المخططات؟

نظرًا لكيفية عمل k8s مع تطبيقاته: في عالم التطوير ، توجد طريقة ما للسماح بإصدارات العلامات عبر اللوحة.

لم يكن بإمكانه فعل أشياء مثل SemVer من حيث عوامل التشغيل ~ أو ^ ، لأن الإصدار كان مرتبًا تمامًا ، بدون دلالات.

ولم لا؟ نفعل هذا طوال الوقت مع php composer . يمكننا استخدام SemVer أو يمكننا استخدام إصدارات السلاسل التي يتم تحليلها ببساطة أو تجاهلها في مخطط الإصدار ، على سبيل المثال إذا لم يكن version رقم SemVer ، فلا تقم بتضمينه في ~ و ^ مطابقة النمط

نظرًا لأنك تقتبس تعليقي على # 7299 ،

بالنسبة لحزمتي .deb و .rpm ، يتم تقسيم سلسلة الإصدار بطرق معينة (بواسطة واصلات) ، ولكن ليس لها معنى دلالي مثل "هذا متوافق مع واجهة برمجة التطبيقات (API) مع ذلك" وبالتالي لا يمكنك إنشاء تعبير مثل "Give لي أحدث إصدار متوافق مع API "أو" أعطني أحدث إصدار مع واجهة برمجة تطبيقات غير متغيرة "، كما يمكنك مع SemVer.

أتذكر أن كلاً من Debian و RedHat استخدما الأسماء المستعارة للحزم لتحقيق حالات الاستخدام هذه (وتوافق ABI) بشكل عام على أساس أرقام التحويل. سمح هذا بسلوك متسق بشكل معقول باستخدام أسماء الحزم ومقارنات الطلب فقط.

فيما يتعلق بالموضوع العام ، فإن الطريقة التي نستخدم بها مخططات Helm لمنتجنا هي تعبئة خدماتنا المتنوعة. ومع ذلك ، فإن صور Docker هي مجرد قطعة أثرية ، ويتم تسميتها من خلال إصدار الخدمة ، التي اعتمدنا لها SemVer لأنها توفر واجهات برمجة التطبيقات.

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

لذلك أنا سعيد جدًا بالطريقة التي يعمل بها Helm معنا ، لأن version يحتوي على الإصدار الدقيق لبرنامجنا ، و appVersion يحتوي على نفس الشيء ولكن كسلسلة ، ولا أحد ينظر أبدًا في Docker repo.

أنا أقل سعادة قليلاً بالطريقة التي يتم بها إصدار المخططات في https://github.com/helm/charts/ ، حيث أن المخطط له إصدار وليس البرنامج ، مما يؤدي إلى رسم بياني ثانوي (مستقر) من حين لآخر version للرسم البياني عن نسخة الأشياء التي يحتوي عليها.

لدينا مشكلة مماثلة مع مخطط عامل التشغيل الثابت / بروميثيوس ، في صفحة "المكتبات والتحف المستهلكة خارجيًا". يحتوي على مجموعة من البرامج المختلفة ، لذا فإن السؤال "ما هو الإصدار الذي نستخدمه؟" وخاصة "هل الترقية آمنة؟" من الصعب الإجابة عليها عن Agones ، وهي الإصدارات بنفس الطريقة التي نقوم بها.

تضمين التغريدة

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

أنا بالتأكيد أحب أن أرى ذلك. هناك طلب خاص بميزة ذات صلة على # 6932 على سبيل المثال.

بعد أن قمت للتو بالرجوع إلى المناقشة احتياطيًا ، فإن فكرة أن appVersion مرتبطة ببيانات وصفية لصورة Docker لا تتناسب بالتأكيد مع حالة الاستخدام الخاصة بنا ، كما تفعل بعض مخططاتنا على الأقل (تلك التي يتعامل معها المستخدمون بشكل أساسي) لا تحتوي على صور Docker ، كونها في الغالب مضيفين للموارد المشتركة (على سبيل المثال ، مفاتيح JWT العامة ، values.yaml ) بالإضافة إلى requirements.yaml لسحب الرسوم البيانية الأخرى.

فكرة أن appVersion مرتبطة بالبيانات الوصفية لصورة Docker لا تتناسب بالتأكيد مع حالة الاستخدام لدينا ، على الأقل بعض مخططاتنا

أنا لا أقول أن هذا كان _the_ الاستخدام المقصود. لقد ذكرت فقط أنه ارتباط منطقي. أنت لا تزال تستخدم appVersion كـ "حاوية منطقية" لملفات yamls الداخلية الخاصة بك.

ما زلت لا أعرف كيف أن تأمين version في SemVer له أي فوائد. هل يمكن للقيادة تحليل اختبار version (و appVersion ) والمتابعة من هناك؟

أعتقد أن وجهة نظري كانت أننا لا نستخدم appVersion على الإطلاق ، وعادة ما لا يكون موجودًا في Chart.yaml ، وعندما يكون موجودًا ، يكون مطابقًا لـ version .

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

تمتلك أنظمة حزم RPM و DEB نفس الشيء ، باستثناء أن أنظمة إصدارها تستخدم صيغة مختلفة ، لكنها لا تزال بنية مقيدة لأسباب التحليل الدلالي. لديهم أيضًا دلالات مختلفة يهتمون بها.

بالنظر إلى كيفية تشغيل الريبو / المخططات ، أشعر وكأن حقل واحد version مع إصدار DEB أو RPM سيكون خيارًا أفضل من سلسلة SemVer بالإضافة إلى appVersion . ومع ذلك ، فهذه سفينة مختلفة تمامًا وأبحرت بالفعل. ولأنني كنت بائعًا أوليًا ورابطًا في دبيان في شبابي ، فإنني أقدر عدم الاضطرار إلى التوفيق بين "أي من أرقام الإصدارات يجب أن تصطدم هنا؟" في حزم " version هي الحقيقة الواحدة".

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

مرحبا. لا توجد أخبار عن هذه الميزة.

بعد قراءة جميع التعليقات ، أستطيع أن أرى أنها ستكون مفيدة حقًا.

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

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

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

تركت التعليق في قضية مشابهة https://github.com/helm/helm/issues/7517
هل يمكننا إضافة القدرة على تجاوز هذا في القيم.
ثم نحصل على خيار سطر الأوامر مجانًا --set

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

أنا موافق. نحن محظورون حاليًا لاستخدام Chart Museum للرسوم البيانية المستندة إلى التطبيقات غير القابلة للتغيير. إصدار المخطط! = إصدار التطبيق ، مما يجعل من المستحيل علينا إصداره من خلال متحف الرسم البياني.

قرأت مجموعة (وليس كلها) من المناقشة أعلاه ، لذلك آسف إذا كنت أكرر بعض النقاط / الآراء. أحاول تقديم إجابة مدروسة.

أحب رؤية appVersion عندما أقوم بعمل helm ls والانتقال من الناحية المفاهيمية من .Values.image.tag كان أمرًا جيدًا ولكن عدم القدرة على ضبطه في وقت النشر هو بمثابة توقف عرض حقيقي وهو شيء أملكه للعودة إليه.

أنا متأكد من أن (الرسم البياني) version هو نسخة الرسم البياني و appVersion هو علامة عامل الإرساء. في عملية CI الخاصة بنا ، تعد علامة docker أيضًا علامة git.
لدينا أيضًا العديد من الخدمات المصغرة ولدينا الرغبة في إبقاء الأشياء جافة قدر الإمكان. لدينا مخططات عامة في إعادة شراء المخططات المحلية لأن الجزء الأكبر من تطبيقات java-springboot متشابهة. معظم تطبيقات tomcat هي نفسها (لكنها تختلف عن تطبيقات Springboot). اشطفها وكررها مع التقنيات الأخرى. ثم لدينا قيم بيئية حيث يشق النشر طريقه عبر بيئات مختلفة
ثم تستفيد كل من هذه الخدمات المصغرة من المخطط العام من خلال CI / CD
على سبيل المثال ، helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install أفضل استخدام .Chart.AppVersion بدلاً من .Values.image.tag لكن يجب أن أكون قادرًا على النشر بطريقة فعالة لمؤسستنا.

إذا قمت بعمل helm ls لديّ كلاً من CHART و APP VERSION لذلك يجب أن يتطابق إصدار المخطط بالكامل مع إصدار التطبيق بشكل مسطح على وجهه هناك. سيؤدي الاستمرار في هذا الطريق إلى إبعاد الناس وفي مرحلة ما سيتم تشعب المشروع لأن هذه العقلية صارمة للغاية وليست ما يسعى إليه كثير من الناس. لقد بدأ أيضًا في السير في مسار "Lets remove image.* ، nameOverride & fullnameOverride . image. * يمكن ترميزها بشكل ثابت في النشر. yaml وما إلى ذلك." لأسباب مماثلة جدا.

النقطة الأخيرة هي أن العديد من المخططات العامة لن تتطابق تمامًا مع إصدار حاوية عامل الإرساء التي يستخدمونها. قم بإلقاء نظرة على معظم حاويات عامل التحميل المعروفة مثل alpine أو nginx حيث تكون الإصدارات الرئيسية والثانوية عبارة عن علامات متدرجة مع إصدارات التصحيح فقط التي لا يتم عرضها. إن الحصول على تعيين 1: 1 لكل إصدار تصحيح يقدم قدرًا كبيرًا من النفقات العامة مقابل فائدة قليلة أو معدومة.
ليس من غير المألوف أن تكون بيئات الإنتاج غير قادرة على الترقية إلى أحدث إصدار لعدة أسباب. لا تتحدث حتى إلى معظم الأماكن حول الإصدارات المتدحرجة في الإنتاج.

نتيجة كل ما سبق يطرح السؤال التالي "لماذا يمكن لـ helm استخدام الريبو على الإطلاق؟".
عدم القدرة على الكتابة فوق appVersion في وقت التثبيت / الترقية يعني أنك تحتاج بالفعل إلى تنزيل المخطط وفك ضغطه ، أو تحرير appVersion لكل تثبيت / ترقية ، أو يمكنك أيضًا حزم حاويات عامل الإرساء المطلوبة في الرسم البياني.
الاستثناء هو المكان الذي يحدث فيه التثبيت القياسي تمامًا ، وهناك بالفعل الكثير من الجدل حول إنشاء كلمات المرور تلقائيًا وما شابه ذلك.
أعلم أن الفقرات الأخيرة بدت وكأنني كنت أسير في حفرة أرنب وأرسم نفسي في زاوية ، ولكن هذا هو المكان الذي يأخذنا فيه "appVersion هو علامة عامل الإرساء ولا يمكنه تعيين appVersion عبر سطر الأوامر أو القيم".

timothyclarke : ما قد ترغب في القيام به ، لحالة الاستخدام helm upgrade التي وصفتها هنا ، هو helm package أولاً ، والذي يتيح لك تعيين --version و --app-version ، وبعد ذلك يمكنك helm install كرة القطران ، واحتفظ بها كقطعة أثرية لـ CI ، مما يزيد من قابليتك للتكرار للتثبيت ، حيث لن تحتاج إلى إضافة أي معلمات --set . هذا ما انتقلنا إليه ، على الرغم من عدم وجود جانب "المخطط العام" ، لأن مخططاتنا ليست عامة.

إنها أيضًا فرصة جيدة لإضافة البيانات الوصفية للبناء إلى Version ، بشيء مثل +g<shortCommitSHA> .

في # 7517 ، سمح لي ذلك بإزالة مجموعة من مكالمات sed التي كانت تعيد كتابة علامة image.tag قبل التثبيت على مجموعة اختبار CI الخاصة بنا ، ثم مرة أخرى عند التعبئة والتغليف لاحقًا.

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

بالنسبة لي ، فإن الخطر من تجاوز إصدار (أو إصدار) من التطبيق في وقت التثبيت هو أنه ليس مرئيًا بشكل واضح لشخص آخر يحاول إعادة إنشاء المخطط ، أن هذا قد تم. ما لم يتم اختراق دعم القيم بطريقة ما ، فلن يكون موجودًا عندما يستخرج المرء التكوين الحالي للمخطط باستخدام helm get values -o yaml ، لذلك يصبح _ هناك شيء آخر _ يجعل نشر المخطط المباشر الخاص بك مختلفًا عما تحصل عليه. helm install <some way to specify a particular package> --values <values from helm get values> ، على سبيل المثال ، عند محاولة إعادة إنتاج مشكلة ظهرت في الإنتاج في إعداد اختبار.

بالنسبة لي ، فإن الخطر من تجاوز إصدار (أو إصدار) من التطبيق في وقت التثبيت هو أنه ليس مرئيًا بشكل واضح لشخص آخر يحاول إعادة إنشاء المخطط ، أن هذا قد تم. ما لم يتم اختراق دعم القيم بطريقة ما ، فلن يكون موجودًا عندما يستخرج المرء التكوين الحالي للمخطط باستخدام helm get values -o yaml

كنت أصاب كبد الحقيقة على رأسه. يجب أن يكون هذا النحل في values.yml من اليوم الأول.

بينما أفهم الحجج الفلسفية ضد هذه الميزة ، تظهر الممارسة الميدانية أنها ستساعد الناس كثيرًا - بما في ذلك نحن.

هناك العديد من المخططات في البرية والتي تتيح لك تعيين إصدار التطبيق من خلال values.yml ، على وجه التحديد لأنه لا يمكن تعيينه هنا.

لست متأكدًا مما إذا كان قد تمت مناقشة ذلك (هل تم إجراء CTRL + F سريعًا ولم أتمكن من العثور على أي أثر) ، ولكن ماذا عن إزالة appVersion معًا كحل بديل؟ يبدو لي أنه سيتجنب كل اللبس.

الآن يتم التعامل مع appVersion كنوع من القيمة "الخاصة". أفترض أنه موجود لتوفير الرؤية ، على سبيل المثال ، يمكنني الحصول على إصدار مخطط 123.5.6 من بروميثيوس ، ولكن سيكون به إصدار التطبيق: 2.17.1 ، لذلك أعرف ما هو إصدار تصحيح الأمان الموجود به وما هي ميزات Prometheus التي أتوقعها وأنا يمكن البحث عنه باستخدام helm ls .

أعتقد أنه يمكن توفير ذلك بطريقة مختلفة. ربما عن طريق تسميات الإصدار؟ أو ربما استعلام jsonPath جميع الإصدارات ، على غرار ما هو ممكن مع kubectl سبيل المثال:

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

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

من ناحية أخرى ، قد يكون الأمر كذلك أن العديد من الأشخاص يعتمدون على التنفيذ الحالي لـ appVersion ، وهذا يحتاج أيضًا إلى النظر فيه.

ربما التراجع قليلاً وفهم سبب إضافة appVersion بالضبط سيساعد في حل هذه المشكلة؟

bokysan كان سابقًا في values.yaml تم نقله إلى Chart.yaml بالكامل أعتقد أن helm ls يعرض كلاً من المخطط وعلامة عامل الإرساء بدلاً من الاضطرار إلى تشغيل أمر مثل كما
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

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

تقع الفرضية الكاملة لـ appVersion بشكل مسطح على وجهها بمجرد أن تحتاج إلى البدء في استخدام initContainers والسيارات الجانبية. لإعطاء مثال حقيقي ، فإن أحد المشاريع التي أحتاجها حاليًا لإدارتها يحتوي على nginx مع php sidecar. لا تتغير علامتا nginx و php كثيرًا. تعد حاوية / إصدار php مهمًا جدًا للمطورين الذين يكتبون الكود. الحاوية التي تتغير بشكل متكرر هي initContainer التي توفر المحتوى.
هل أقوم بتعيين appVersion إلى initContainer ، إلى الحاوية php أم أنها nginx ، وباختيار واحد فقط من هذه المعلومات التي فقدت؟

إذا كان ذلك مهمًا لمستخدميك ، فيجب أن يكون إصدار PHP بالتأكيد؟ هذا ما تعلن عنه. يمكنك أيضًا لصق الثلاثة في appVersion الخاص بك ، إنه حقل نصي حر بعد كل شيء.

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

إذا كان مصدر المخطط الخاص بك هو _ جزء من_ التطبيق ، على سبيل المثال Agones ، فقط اترك appVersion فارغًا ، أو انسخه من version إذا كان لديك الأدوات التي تعتمد عليها.

لا يلزم أن تكون أي من هذه الأشياء قرارات بالوقت هي helm install . كما ذكرت سابقًا ، فات الأوان helm package بما يكفي لجميع مهام سير العمل باستثناء "تبديل إصدار مختلف في المنبع في وقت التثبيت لمخطط طرف ثالث" ويجب أن يكون ذلك في --values أو --set مثل جميع إجراءات "التغيير X عند التثبيت" الأخرى.

بصراحة ، الميزة الفعلية المفقودة هي على الأرجح "تمرير appVersion عبر tpl " ، لذا يمكنك قراءتها من .Values.image.tag أو أي شيء يناسبك.

إذا كنت تريد فرض علامة صورة الحاوية appVersion ==

إذن نحن على الأرجح في https://github.com/helm/helm/issues/7517 ربما هذا هو المكان الذي ينبع منه كل هذا.

أنا لا أفهم هذا النقاش على الإطلاق. لماذا لا يُعد منح الأشخاص خيار استخدام إصدار التطبيق بالطريقة التي يعتقدون أنها الأنسب لهم مشكلة كبيرة جدًا؟

في النموذج الحالي بالنسبة لي سيكون من الأفضل عدم امتلاك هذا APP VERSION على الإطلاق. إنه يجلب الارتباك فقط للأشخاص في مشروعنا. لدينا أكثر من 80 خدمة تستخدم نفس مخطط الدفة ولأنه لا يمكن بسهولة تغيير هذا APP VERSION في helm upgrade -i ... أرى أن جميع تطبيقاتنا ستبقى إلى الأبد مع 1.0 هنا. ولا أخطط لإعادة تجميع المخطط المعبأ بالفعل لتغيير إصدار التطبيق فقط. لماذا يجب علي تعقيد CI الخاص بي لتناسب تصميمك ؟؟؟

أرى أيضًا أنني أريد فقط أن أقول للجميع عدم استخدام helm list لأنه سيكون شيئًا غير مفيد لهم. للتحقق من إصدار تطبيقاتنا لديهم ، سيحتاجون إلى استخدام شيء آخر.

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

وجود ناتجين مختلفين "CHART (version)" و "APP VERSION" في helm list ، helm history وعلى حد سواء مفيد جدًا ويتجنب الحاجة إلى التعمق أكثر في خيارات سطر الأوامر وتحليل الإخراج للحصول على أهم الحقائق.

إذا تم ربط "CHART (version)" و "APP VERSION" في وقت الإنشاء ("حزمة helm") ، فستفقد إلى حد ما الفائدة الكاملة من وجود قيمتين مختلفتين. سيؤدي إنشاء مخطط وتحديث إصدار التطبيق دون زيادة / تحديث إصدار المخطط إلى مشكلة كبيرة لأن إصدار المخطط نفسه سيعطيك نتائج مختلفة تمامًا. : - <

حتى الآن نحن مضطرون لبناء الحزمة مع كل إصدار وزيادة "CHART (الإصدار)" و "APP VERSION" متزامنة حتى لا تتعرض لموقف مجنون / غير واضح.

كما علمت للتو ، يمكننا إسقاط "APP VERSION" ، لأنه اختياري واستخدام بعض القيمة المخصصة واستخدامه بدلاً من {{Chart.appVersion}} لصورتنا .... ولكن بعد ذلك helm list تكون طريقة أقل إفادة. : - <

من منظور المستخدمين (المطورين):

• القدرة على تعيين بعض خصائص الإصدار / العلم / القيمة في وقت التثبيت
• القدرة على رؤية خصائص / إشارة / قيمة هذا الإصدار في قائمة الدفة / إخراج السجل بالتسمية "XX version"

هل هناك فرصة لانجاز ذلك؟

إذا تم ربط "CHART (version)" و "APP VERSION" في وقت الإنشاء ("حزمة helm") ، فستفقد إلى حد ما الفائدة الكاملة من وجود قيمتين مختلفتين.

أعتقد أن هذا هو جوهر عدم التوازن. فائدة إصدار التطبيق كما أستخدمه ، وكما يبدو أن المقصود من الإعداد الحالي ، هو أنك تعرف إصدار التطبيق المغلف لإصدار المخطط هذا ، لأن إصدار المخطط هو إصدار المخطط بأكمله ، وليس إصدار المخطط نسخة من القوالب في الرسم البياني. أكره أن تتم إضافة كل عبارة مثل "نحن نطلب الإصدار ~ XY من مخطط Helm" لطلب "أوه ، ولا تعبث مع AppVersion" في النهاية.

يتم فقدان هذه الميزة من إصدار التطبيق (والإصدار الفعلي من التطبيق) في وقت التثبيت ، لأن إصدار المخطط الآن لا يخبرك بالتطبيق الذي تستخدمه ، وتفقد القدرة على استخدام SemVer للتأكد ، على سبيل المثال ، لديك أحدث إصدار متوافق مع API.

بالنسبة لحالة الاستخدام التي يصفهاpniederlag ، فإن القدرة على الحصول على قالب يشير إلى إدخال قيم appVersion سيجعل helm list يفعل ما هو مطلوب ، طالما أن المخطط يدعم وجوده تم تغيير إصدار التطبيق (ربما علامة الحاوية) في وقت التثبيت ، عبر خيار التكوين --set أو --values مثل أي خيار آخر "تم تغييره في وقت التثبيت".

هنا حيث حصلت على مشكلة مع AppVersion .

نحن نستخدم كلاً من نسخة الإصدار و AppVersions.

لتعيينهم الآن - يجب أن أتصل بـ helm package صراحة مسبقًا بـ helm upgrade --install لإنشاء أرشيف tar محلي مع تعيين كلا الإصدارين.

أقوم الآن بإضافة دعم helm-secrets ، و ...
ولا يمكن أن يعمل برنامج التضمين مع helm package !

إذن - ماذا الآن؟
هل تريد إسقاط دعم جميع إصداراتنا وتدفقها؟
إسقاط باستخدام الأسرار؟
أيه أفكار؟

في الواقع ، إنها مشكلة تتعلق بـ helm-secrets ، لكنها مرتبطة بقدرة --set app-version تمت مناقشتها هنا أيضًا ، لأنه إذا كان بإمكاني استخدامها بهذه الطريقة - لست بحاجة إلى الاتصال بـ helm package على الإطلاق.

UPD أوه ، انتظر ... ما زلت قادرًا على استخدام helm secrets upgrade chart.tgz -f secrets.yaml ...
تمام.
ولكن لا يزال ، +1 لإضافة --set app-version .

إذن - ماذا الآن؟
هل تريد إسقاط دعم جميع إصداراتنا وتدفقها؟
إسقاط باستخدام الأسرار؟
أيه أفكار؟

نقوم ببناء حزمتين: حزمة خوذة بها المخططات فقط ، بلا قيم env وملف الأسرار. أعدنا تسمية هذه الحزمة إلى chart-{app-version}.tgz نظرًا لأن إصدار المخطط لا يعني شيئًا بالنسبة لنا ، ولا يدعم إصدار المخطط بنية إصدار التطبيق لدينا. تتضمن تحديثات التطبيق لدينا أي تحديثات محتملة للرسم البياني (نفس الريبو ، باستخدام علامات git).

ثم لدينا tgz ثاني خاص بالبيئة ، chart-{app-version}-{env}.tgz يتضمن الرسم البياني tgz ، قيم yaml ، وملف الأسرار المشفر. يتضمن هذا الملف أيضًا "package.yaml" يحتوي على قيم مثل العلامة والتطبيق واسم البيئة للنصوص الآلية لنشرها باستخدام helm-secrets .

نحن معتادون على تحديد إصدارات تطبيقاتنا ، أو معظمها ، برقم إصدار دلالي. ثم استخدم هذا الرقم في APP VERSION لتحديده بسهولة في قائمة helm history لعمليات التراجع أو العمليات الأخرى.
نظرًا لأن النظام لا يسمح بحقنه تلقائيًا في وقت النشر ، فإننا ننفذ هذا الأمر البسيط تلقائيًا على خط أنابيب CI / CD قبل أمر النشر:

sed -i -E "s/^appVersion: (.*)/appVersion: ${deploy.project.version}/" ${chartPath}/Chart.yaml

إنه أمر صعب ، لكنه يعمل كما هو متوقع.

bvis
تكمن المشكلة في الحل البديل في أنه يجب عليك تحرير المخطط في خط أنابيب CI / CD الخاص بك.
إذا كنت تستخدم ريبو مخطط مركزيًا ، فأنت مجبر على الدخول إلى helm pull repo/chart --untar

أي مزيد من التقدم مع حقن Chart.yaml / appVersion برمجيًا؟ هل هناك حلول؟ سيعطي دفعة هائلة في CI / CD Helm.

jakovistuk بقدر ما أستطيع أن أقول ، الرسوم البيانية التي تستخدم appVersion لإظهار إصدار الحاوية تفعل ذلك مباشرة عبر Chart.yaml ، كما هو موضح في nginx-ingress / Chart.yaml على سبيل المثال ...

لم أفكر كثيرًا في هذه المشكلة لبعض الوقت ، لذلك قد يكون هذا سؤالًا غبيًا حقًا ، ولكن هل هناك طريقة لاستخدام Helm CLI لتجاوز appVersion؟

يبدو أن الكثير من الأشخاص هنا يسألون عن طريقة لتجاوز حقل "appVersion". الهدف / الطلب الأصلي في هذه المشكلة هو السماح بـ "إصدار التطبيق كبديل" للإصدار ، بحيث يمكن للمستخدم تشغيل "helm fetch—app-version = v0.15.0" وسيحدد Helm آخر إصدار من المخطط حدد v0.15.0 باعتباره appVersion وجلب ذلك.

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

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

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

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

حتى يتم حل هذا (أو لا) إليك كيفية حل هذا في CI / CD (GitLab):

حزم المخطط بإصدار التطبيق ، ثم انشره.
أعلم أن إصدار المخطط لا يُقصد به أن يكون هو نفسه إصدار appVersion ، ولكن في حالتنا ، لا بأس به كحل بديل.

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" \
       --set-string ingress.enabled="${INGRESS}" \
       --set service.port="${CONTAINER_PORT}" \
       --set service.targetPort="${CONTAINER_PORT}" \
       --set dc="${CI_ENVIRONMENT_NAME}" \
       --set project="${CI_PROJECT_NAME}" \
       --namespace ${NAMESPACE}
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

إذا عيّنت image.tag إلى {{ .Chart.AppVersion }} فلن تحتاج إلى --set أثناء التثبيت ، فسيكون صحيحًا بالفعل. يعمل هذا بشكل جيد مع الإنشاءات التلقائية أيضًا ، عندما يتم تمييز صور Docker بعلامة SHA1 بحيث يتطابق AppVersion مع علامة صورة Docker ، ويكون الإصدار عبارة عن SemVer يتم إنشاؤه تلقائيًا.

لا توجد مشكلة في أن يكون الإصدار هو نفسه AppVersion إذا كان AppVersion الخاص بك هو SemVer.

بالنسبة للحزم التي ينتجها فريقي ، نتجه نحو الأشياء التي تبحث عن AppVersion ، مثل image.tag ، والتعيين الافتراضي إلى الإصدار إذا لم يتم تعيين AppVersion. إنه ليس فرقًا كبيرًا ، مجرد حجة واحدة أقل من helm package للإصدارات ذات العلامات ، ولكن يكون منطقيًا فقط إذا تم إنشاء مخططك من نفس SCM مثل الشيء الذي تقوم بتعبئته.

TBBle التي لن تعمل إذا كنت تستخدم مخططًا فرعيًا لتعيين علامة صورتك

هل تقصد أن image.tag موجود في مخطط فرعي ، لكنك تحاول استخدام إصدار الرسم البياني الأصل؟ إذا كان الأمر كذلك ، فهذا أمر محرج للغاية ولن يكون من السهل إدارته. لقد ارتدت للتو هذا التخطيط بالضبط في https://github.com/googleforgames/open-match/ مخططات Helm. أقترح إعادة المخططات الفرعية المعنية إلى الرسم البياني الرئيسي في هذه الحالة.

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

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

أو ربما أكون قد أسأت فهم الملاحظة التي تقوم بها.

haimari لسوء الحظ ، لا يعمل (يتعلق بـ https://github.com/helm/helm/issues/6921؟):

> helm package $DIR/deployment/chart --app-version="1111e8" --version="3454e5" --namespace stage
Error: Invalid Semantic Version

لكن هذا يعمل:

> helm package $DIR/deployment/chart --app-version="0.0.0-1111e8" --version="0.0.0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0.0.0-3454e5.tgz

وحتى هذا (لكن يبدو متسخًا):

> helm package $DIR/deployment/chart --app-version="0-1111e8" --version="0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0-3454e5.tgz

إصدار إصدار helm.BuildInfo {الإصدار: "v3.4.0" ، GitCommit: "7090a89efc8a18f3d8178bf47d2462450349a004" ، GitTreeState: "dirty" ، GoVersion: "go1.15.3"}

أعتقد أن حل haimari كما هو يعمل فقط لأنهم يستخدمون علامات متوافقة مع semver في خط أنابيب CI الخاص بهم (على سبيل المثال ، سيكون هذا مثالاً لتشغيل وظيفة للإصدارات ذات العلامات ، ولن يتم تشغيله في كل التزام)

@ a0s : أقترح بشكل عام:

helm package $DIR/deployment/chart --app-version="<container image tag>" --version="<semver version>"

ثم اجعل قيمة علامة صورة الحاوية الخاصة بك شيئًا مثل {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version ، بحيث لا تحتاج إلى تغييرها أثناء التنقل ، كما يفعل

في الأمثلة الخاصة بك ما يبدو أنه نسختان مختلفتان من git ، فهل هذا صحيح؟ هل واحد لصورة الحاوية والآخر للرسم البياني؟

مع SemVer ، لا يمكنك حقًا وضع git الالتزام SHA في الجزء ذي المعنى من semver ، لأن semver يعني الطلب ، ولا يمكن فرز git الالتزام SHA.

لذلك سترغب في استخدام إصدار مثل 0.0.1-alpha.<build-id>+g<gitcommitsha> حيث يكون <build-id> يشبه إلى حد ما خط الأنابيب أو معرّف الوظيفة من نظام CI الخاص بك ، لذلك دائمًا ما تلتزم بمشروعك. بهذه الطريقة ستحصل دائمًا على أحدث تصميم عندما تطلبه.

في SemVer ، استخدام - يعني أنه إصدار مسبق لهذا الإصدار ، لذلك يقع 0.0.1-<anything> بين الإصدارين 0.0.0 و 0.0.1. الجزء الذي يلي + هو معلومات البناء ، ويتم تجاهله من أجل الفرز ، وبالتالي فهو مكان جيد لوضع git SHAs أو أسماء الفروع أو معلومات التتبع الأخرى غير القابلة للفرز.

لذا مع ما استخدمته هنا ، سيظهر 0-3454e5 على أنه أحدث من الالتزام التالي ، إذا كان SHA يبدأ بـ 2 ، على سبيل المثال ، 0-2764e1 .

في الأمثلة الخاصة بك ما يبدو أنه نسختان مختلفتان من git ، فهل هذا صحيح؟ هل واحد لصورة الحاوية والآخر للرسم البياني؟

نعم ، التطبيق والرسم البياني - هناك نوعان من البرامج المستقلة.

بهذه الطريقة ستحصل دائمًا على أحدث تصميم عندما تطلبه.

ماذا لو كنت لا أريد (وحتى لا أتخيل) أطلب الأحدث.

0.0.1-alpha.<build-id>+g<gitcommitsha>

هذه السلسلة (بعد الاستيفاء) تبدو طويلة جدًا بحيث لا يمكن وضعها في عمود واحد من الناتج القياسي helm list :)

أعرف دائمًا إصدار (sha hash) من التطبيق الذي أريد تثبيته (مرره بـ --set args). وأعرف دائمًا إصدار المخطط الذي أستخدمه (كما وصف سأستخدم دائمًا git checkout chart && helm pack && helm upgrade .tar.gz محليًا في ci / cd)

ما الخطأ الذي يمكن أن يحدث؟
1) حدث خطأ أثناء helm upgrade العادي. حسنًا ، سأصلح الخطأ وأعد المحاولة (مع التزام sha آخر للتطبيق - 99٪) (أو باستخدام --atomic بدلاً من ذلك)
2) التراجع اليدوي: helm rollback <RELEASE_NAME> أو التزام النشر السابق من خلال CI / CD.

ما فاتني؟

ملاحظة: لأكون صادقًا ، أريد استخدام جزء sha قصير في الإصدار وإصدار التطبيق لغرض المعلومات فقط (خلال helm list )

إذا كانت لأغراض المعلومات فقط ، فإنها تأتي بعد + في SemVer ، وليس - . إذا لم تكن مهتمًا أبدًا بطلب الإصدارات ، أو توزيع مخططات Helm على أي شخص ، ولم يكن المخطط أو التطبيق الخاص بك بالفعل SemVer'd ، إذن 0+g<commitsha> هو SemVer صالح (ما يعادل 0.0.0).

هذا ما تفعله مخططات Helm المبنية تلقائيًا في Open Match ، على سبيل المثال ؛ إنهم جميعًا حاليًا 0.0.0-dev ، وقد بدأنا في جعل هذا 0.0.0-dev+g<commitsha> لذلك إذا كنت تبحث عن ما قمت بتثبيته ، يمكنك على الأقل معرفة ما هو التصميم الرئيسي لديك.