ما هو الشائع بين تقشير البيض و DevOps؟

إليك ترجمة لمقال باتريك لي سكوت المنشور على موقع hackernoon.com. يقدم المؤلف التعرف على العديد من المبادئ الهامة التي ستساعدك على ضخ في DevOps.

صورة

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

أخذت بيضة مسلوقة أخرى وضربتها على لوح تقطيع ، ثم ضغطتها ولفتها على الطاولة. استغرق الأمر 3 ثوان فقط لتنظيف. وقفت وأقلعت قطعة قذيفة قطعة.

ما أريد قوله بهذا: نحن نبالغ في أهمية الجهود.

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

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

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

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

إذا نظرت إلى التطور ككل ، فسوف نرى أن هناك مبادئ عالمية أكثر ، على سبيل المثال ، "حافظ على الأمر بسيطًا ، غبي" (KISS) و "لا تكرر نفسك" (DRY). أود أن أتحدث عن أنماط ومبادئ مماثلة فيما يتعلق بـ DevOps.

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

إنشاء أنظمة DevOps ، وجدت العديد من الحلول لنفسي بالإضافة إلى مبادئ عالمية مثل KISS و DRY. على الرغم من أنه لا يمكن أن يطلق عليهم قوالب ، إلا أنهم سيساعدونك في تنظيف البيضة بسرعة. هذه الحلول (بترتيب عشوائي):

  • لا تفعل ما فعله الآخرون أمامك.
  • السماح للمطورين أن يكونوا منتجين قدر الإمكان.
  • الإنتاج هو أسطورة.
  • نقل كل شيء إلى الكتلة والنسخ الاحتياطي بأكمله.
  • VPN معقدة للغاية ؛ الحلول أسهل.
  • تنظيم وأتمتة وقهر!

الدرس 1. لا تفعل ما فعله الآخرون أمامك


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

لا تقم بإعادة اختراع العجلة - قم بشرائها.

هل تعلم أنه يمكنك استخدام نفس خادم البريد الذي يستخدمه كريغزلست؟ وما هو مجانا؟ تحتاج إلى خادم بريد - لا تنشئ خادمًا جديدًا ، وتعاون مع خادم موجود.

أحب البحث عن أدوات في قوائم مضيفة ذاتيا أو استخدام Helm Hub لهذا الغرض.

على الرغم من أن Helm أداة جديدة إلى حد ما للعثور على البرامج ، فقد تم إنشاء هذا الموقع بالفعل: https://v3.helm.sh/

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

دعنا نعود في الوقت المناسب عندما كنت بدأت للتو في البرنامج. في الصف التاسع ، تعلمت أول لغة "حقيقية" - QBasic. قبل ذلك ، كنت أقوم بإنشاء مواقع HTML و CSS لبضع سنوات. ثم كانت شبكة الإنترنت جديدة ، وعلى الرغم من أن الناس كانوا يعرفون كيفية إنشاء حزم ، إلا أنهم لم يشاركوها ، كما نحن الآن. عادةً ما تستخدم الأقراص المرنة للتخزين - سيكون من الرائع العثور عليها مع لعبة مثل arkanoid ، والتي كتبت في Java Swing في الصف 11 ...

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

الآن كل شيء خاطئ. اليوم يمكنك أن تجد مكتبات UI كاملة. يمكنك العثور على مكتبة للتعامل مع التواريخ بأناقة وسهولة باستخدام أمر واحد.

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

خبر جيد: هذه الأداة موجودة! مع Helm ، يمكنك أيضًا تثبيت أنظمة فرعية تعمل بشكل كامل ومعبأة وجاهزة للاستخدام.

المبدأ هو نفسه بالنسبة لـ NPM و Gradle ، لكن الحزم التي نديرها في Helm تسمى المخططات. تميز المخططات الحاويات حتى يتم تشغيلها على Kubernetes بعدة طرق.

اتضح حل تسليم المفتاح ، وشراء الدراجة. الرسوم البيانية هي العجلة ، والحاويات مع الأوصاف التي تعمل داخل Kubernetes هي العجلات.

ما يلفت النظر في الرسوم البيانية هو القدرة على حزم الخدمات وتشغيلها في أي مجموعة Kubernetes وحتى مشاركتها مع أشخاص آخرين إذا كنت تريد.

هذا يعني أنه يمكنك وصف البيئة بأكملها باستخدام الكود:

- name: backup repository: http://jenkins-x-chartmuseum:8080 version: 0.0.2 - name: monitor repository: http://jenkins-x-chartmuseum:8080 version: 0.0.3 - name: marketing-site repository: http://jenkins-x-chartmuseum:8080 version: 1.1.10 - name: denormalizer-service repository: http://jenkins-x-chartmuseum:8080 version: 1.0.0 - name: mongo repository: https://kubernetes-charts.storage.googleapis.com/ version: 1.0.0 

تحتاج إلى ترقية موقع التسويق الخاص بك إلى 1.2.0؟ فقط قم بإجراء التغييرات والالتزام.

الدرس 2. اجعل المطورين منتجين قدر الإمكان.


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

تادا وآم! وجدت ذلك! ثابت!

جلست خلف قسم في مكان عملي في غرفة مضاءة بنصف الشمس وصرخت للآخرين: "لقد قمت بإصلاح الخلل"

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

حسنًا ، حسنًا ، إذا كان الإصدار لا يزال يأتي يوم الثلاثاء القادم ، فسوف يقدر المستخدمون ذلك بالتأكيد!

هذه هي الطريقة التي كنت أعمل بها في عملي الأول في الكلية ، كمبرمج مبتدئ.

منذ ذلك الحين ، لقد تغير الكثير.

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

اليوم ليس عليك الصراخ من خلال القسم في المكتب.

كلما زادت الحرية التي تمنحها للمبرمجين - حرية التحكم في أجزاء البنية الأساسية التي يحتاجون إليها - كلما كان من الأسهل لك العمل كمهندس DevOps.

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

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

يمكنني سماعك بالفعل تقول: "يبدو الأمر معقدًا جدًا!" لا. فقط قم بتعيين المخطط.

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

الدرس 3. الإنتاج خرافة


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

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

تابعت هذا النمط عاماً بعد عام ولم أشك في ذلك أبداً. لقد كان دائما كذلك.

وهذا المخطط هو وسيلة أخرى غير منتجة للتخلص من الصدفة.

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

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

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

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

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

الدرس 4. نقل كل شيء إلى الكتلة والنسخ الاحتياطي بأكمله


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

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

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

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

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

بدلاً من التفكير في الخوادم ، يمكنك العمل على مجموعات كاملة.

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

الدرس 5. VPN معقدة للغاية ، وهناك حلول أسهل


هل سبق لك استخدام VPN مع السرور؟

لا حقا. هل هو ممكن حتى؟

قامت Google بمحاولة كهذه. لكن قبل عامين ، أعلنت الشركة أنها لن تستخدم VPN. أعتقد أنهم أيضًا لم يستمتعوا بها.

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

لا يلزم سوى نقلة صغيرة: بدلاً من استخدام VPN للترخيص ، استخدم وكيلًا.

تستضيف VPN أيضًا رابط إدارة Kubernetes على الشبكة الخاصة ، بينما لا يستضيف SSO. لكن لديهم آلية الترخيص الخاصة بهم. في حالة Google Cloud و AWS ، هذه هي إدارة الهوية والوصول (IAM) والقدرة على إدراج عناوين IP في القائمة البيضاء.

إذا كان من الممكن العمل مع بنية أقل ضخمة دون خسارة كبيرة ، فلماذا لا؟ كن مثل Google: انتقل من VPN إلى أنظمة "عدم الثقة".

الدرس 6. تنظيم ، أتمتة ، وقهر


آه ، يبدو لك أن التنظيم هو وقت طويل؟ هراء! في المستقبل ، سيوفر لك هذا ساعات وأيامًا وحتى أسابيع. للعمل!

التنظيم المنهجي هو الطريقة الواقعية الوحيدة لإعادة إنشاء البنية التحتية أكثر من مرة.

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

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

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

استنتاج


لا تقم باختيار القشرة من قطعة البيضة قطعة. فوز ولفة.

Source: https://habr.com/ru/post/ar457120/


All Articles