تم تخصيص المقالة لتطوير مخططات Helm لـ Kubernetes باستخدام حلول جاهزة من مستودعات التخطيط. مع هذا النهج ، يطبق المستخدم وصفات المجتمع أو صفاته الخاصة ، مما يضمن التحديث في الوقت المناسب للمكونات القياسية لجميع مشاريعه وراحة الحفاظ على الحلول بشكل عام.
تم تصميم هذه الميزة المريحة الآن في الأداة المساعدة GitOps الخاصة بنا ، والتي يجب أن تبسط العملية الكاملة لتشغيل البنية التحتية للتطبيقات التي تم تجميعها ونشرها على Kubernetes.
المدمج في هيلم
ربما لا يرتبط النجاح الرئيسي لشركة Helm - "مدير الحزم في Kubernetes" - بوظائفها بقدر ارتباطها
بمستودع التخطيط الرسمي
ودعم المستودعات بشكل عام. ويرافق وصفات وإعدادات الرسم البياني من قبل مجتمع ضخم. يدعم المتخصصون الحلول الحديثة التي يطلبها المستخدمون النهائيون. كل مخطط للمستودع الرسمي موحد وموثق جيدًا.
في الحالات البسيطة ، لا يحتاج المستخدم حتى إلى إنشاء مخطط لطرح التطبيق: إنه فقط يجد حلاً جاهزًا ، ويقرأ الوثائق ، ويعد الإعدادات ويستخدم المخطط الرسمي.
لفترة طويلة ، كنا نستخدم بنشاط Helm داخل werf لنشر البنية التحتية للتطبيق والآن نذهب أبعد من ذلك. بدءًا من الإصدار
v1.0.4-alpha.10 ، تمت إضافة
أوامر للعمل مع التبعيات ومستودعات التخطيط إلى werf للتخلي عن عميل Helm تمامًا.
الأوامر الرئيسية لهذا:
werf helm repo
add Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in local directory init Init default chart repositories configuration list List chart repositories remove Remove a chart repository search Search for a keyword in charts update Update information of available charts locally from chart repositories
werf helm dependency
build Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
بالإضافة إلى ذلك ،
تمت إضافة دعم
werf helm deploy-chart الأمر
werf helm deploy-chart .
وإليك كيف يبدو كل هذا السحر في الواقع - وبشكل أكثر دقة ، نعرض هنا مقارنة لتدرج المخطط نفسه في werf (يسار) وفي Helm (يمين):
المزيد من الممارسة
العودة إلى الراحة في استخدام حلول جاهزة لنشر التطبيقات بالكامل -
مثال شائع مع WordPress . طرح مخطط Helm الخاص به إلى مجموعة Kubernetes باستخدام werf قد يبدو كما يلي:
$ cat << EOF > values.yaml wordpressBlogName: flant wordpressUsername: admin wordpressPassword: password mariadb: mariadbRootPassword: password EOF $ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
→
مظاهرة في أسينيسينيما .
نظرًا لأن المستودعات تحتوي على
العديد من الحلول ، يمكنك
إنشاء تطبيقاتك الخاصة منها كمكعبات ، حيث ستكون المكعبات هي مخططات Helm المتعددة التي يعتمد عليها النظام بالكامل. على الأرجح ، تحتاج فقط إلى تكوين المكونات بشكل صحيح لاحتياجاتك.
على سبيل المثال ، يتطلب تطبيق الويب قائمة انتظار وذاكرة تخزين مؤقت وتخزين البيانات. كيف ننشر هذه المكونات من خلال werf؟
للبدء - دعنا نسرع البحث عن كل ما تحتاجه باستخدام CLI:
$ werf helm repo search queue NAME CHART VERSION APP VERSION DESCRIPTION stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A... stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
وقياسًا على ذلك ، سنجد المكونات المتبقية لجميع مستودعات التخطيط المسجلة (يمكن رؤية قائمة المستودعات المستخدمة من خلال تشغيل أمر
werf helm repo list ).
بعد العثور على كل شيء ، يبقى فقط لإضافتها إلى المخطط. هناك عدة طرق للقيام بذلك: إضافة مخططات مكونة إلى دليل المخططات أو إنشاء ملف
requirements.yaml ووصف التبعيات ، ثم التفاعل معهم باستخدام
werf helm dependency build|list|updateرسم توضيحي للمسار الثاني:
$ cat << EOF > .helm/requirements.yaml dependencies: - name: mysql version: 0.3.4 repository: "@stable" - name: redis version: 1.1.11 repository: "@stable" - name: rabbitmq version: 0.6.16 repository: "@stable" EOF $ werf helm dependency build $ werf deploy --env test
→
مظاهرة في أسينيسينيما .
أثناء عملية بدء التشغيل ،
ستقوم werf
بإنشاء جميع التبعيات وتتبعها مع بقية الموارد - لا يلزم اتخاذ إجراءات إضافية.
نتيجةً لذلك ، مع مراعاة خبرة المجتمع ذي الخبرة ، فإنك توفر كثيرًا من الوقت في تطوير وصيانة المخططات. ومع ذلك ، لا يحدك أي شخص من استخدام المخططات العامة: يمكنك طرح المخططات الخاصة بك بنجاح متساوٍ ، حيث يتم إعداد التهيئة مع مراعاة التفاصيل المطلوبة.
يتم تقديم الوثائق الخاصة بأمر المستودع وأوامر التبعية في werf
هنا . قد تكون مهتمًا أيضًا بقراءة الوثائق للحصول على مزيد من التفاصيل حول
النشر إلى werf والاختلافات الرئيسية من Helm .
استنتاج
إن عدم وجود ميزات مهمة بالنسبة لنا في الحلول مفتوحة المصدر الحالية يجبرنا على إنشاء القدرات والروابط والتكامل المطابقين. تم إنشاء ودعم مشروع werf ، أولاً وقبل كل شيء ، لحل المهام اليومية لمهندسي DevOps.
على سبيل المثال ، نحن نعمل منذ فترة طويلة (السنة الثانية!) بحيث
يتم قبول
اقتراحنا لتتبع الموارد في Helm كطريقة بديلة في قاعدة الكود الرئيسية للمشروع (المنبع). وافق المجتمع على الفكرة ودعمها كثيرون بحاجة إلى هذه الفرصة. ومع ذلك ، بدأ التقدم في هذا الاتجاه في
هيلم 3 والآن فقط ...
حتى الآن ، تم حظر تنفيذ هذه الفكرة في هيلم من قبل المطورين. ومع ذلك ، قمنا خلال هذا الوقت بتطوير الوظائف المقابلة لتتبع الموارد في مكتبة منفصلة مفتوحة المصدر -
kubedog - ونحن نستخدمها بالفعل في werf. واستنادا إلى النشاط على GitHub ، وجدت المكتبة اهتمامًا بين مستخدمي Kubernetes / Helm الآخرين ، وهو أمر مبهج للغاية.
يمكنك دعم فكرتنا (وتنفيذها) من خلال وضع نجمة على مشروع kubedog على GitHub و / أو التجربة في
الإصدار الأصلي في Helm. شكرا لك
PS
اقرأ أيضًا في مدونتنا: