اليوم سنتحدث عن DevOps ، أو بالأحرى عن Ops. يقولون أن هناك عدد قليل جدًا من الأشخاص الراضين عن مستوى أتمتة عملياتهم. لكن يبدو أن الموقف قابل للإصلاح. في هذه المقالة ، سيتحدث نيكولاي ريجيكوف عن تجربته في توسيع Kubernetes.
تم إعداد المادة على أساس خطاب نيكولاي في مؤتمر الخريف DevOops 2017. تحت المقطع - فيديو ونص نص التقرير.
يعمل نيكولاي ريجيكوف حاليًا في قطاع تكنولوجيا المعلومات الصحية لإنشاء أنظمة معلومات طبية. عضو في مجتمع سانت بطرسبرغ للمبرمجين الوظيفيين FPROG. عضو نشط في مجتمع Clojure عبر الإنترنت ، وهو عضو في معيار HL7 FHIR لتبادل المعلومات الطبية. تم البرمجة منذ 15 عامًا.
ما هو الجانب الذي لدينا لـ DevOps؟ لمدة 10 سنوات ، كانت صيغة DevOps الخاصة بنا بسيطة للغاية: المطورون مسؤولون عن العمليات ، ويتم نشر المطورين ، ويتم الحفاظ على المطورين. مع هذا الترتيب ، الذي يبدو قاسيًا بعض الشيء ، ستصبح على أي حال DevOps. إذا كنت ترغب في تنفيذ DevOps بسرعة وبألم - اجعل المطورين مسؤولين عن إنتاجك. إذا كان الرجال أذكياء ، فسيبدأون في الخروج وفهم كل شيء.
قصتنا: منذ فترة طويلة ، عندما لم يكن هناك شيف وأتمتة ، قمنا بالفعل بنشر كابيسترانو التلقائي. ثم بدأوا في حمله ، حتى يصنع الأزياء. ولكن بعد ذلك ظهر الشيف. تحولنا إليها وتوجهنا إلى السحابة: لقد تعبنا من مراكز البيانات الخاصة بنا. ثم ظهر Ansible ، قام Docker. بعد ذلك ، انتقلنا إلى Terraform مع مشرف رصيف Condo المكتوب بخط اليد على Camel. والآن ننتقل إلى Kubernetes.
ما هو أسوأ شيء في العمليات؟ قلة قليلة من الناس راضون عن مستوى أتمتة عملياتهم. هذا أمر مخيف ، أؤكد: لقد أنفقنا الكثير من الموارد والجهود لجمع كل هذه الأكوام لأنفسنا ، والنتيجة غير مرضية.
هناك شعور بأنه مع ظهور Kubernetes ، يمكن أن يتغير شيء ما. أنا ملتزم بالتصنيع الخفيف ، ومن وجهة نظره ، فإن العمليات ليست مفيدة بشكل عام. العمليات المثالية هي غياب أو الحد الأدنى من العمليات في المشروع. يتم إنشاء القيمة عندما يقوم المطور بإنشاء منتج. عندما يكون جاهزًا ، لا يضيف التسليم قيمة. ولكن عليك تقليل التكاليف.
بالنسبة لي ، كان المثل الأعلى دائمًا heroku. استخدمناها للتطبيقات البسيطة ، حيث كان المطور ينشر خدمته ، كان يكفي أن نقول git push وتكوين heroku. يستغرق دقيقة.
كيف تكون يمكنك شراء NoOps - أيضًا heroku. وأنصحك بالشراء ، وإلا ستكون هناك فرصة لإنفاق المزيد من الأموال على تطوير العمليات العادية.
هناك رجال Deis ، يحاولون القيام بشيء مثل heroku على Kubernetes. هناك مسبك سحابي ، والذي يوفر أيضًا منصة للعمل عليها.
ولكن إذا كنت تهتم بشيء أكثر تعقيدًا أو كبيرًا ، فيمكنك القيام بذلك بنفسك. الآن ، مع Docker و Kubernetes ، تصبح هذه مهمة يمكن إكمالها في فترة زمنية معقولة وبتكلفة معقولة. كانت قاسية جدا.
قليلا عن Docker و Kubernetes
واحدة من مشاكل العمليات هي التكرار. الشيء العظيم الذي جلبه عامل الميناء هو مرحلتين. لدينا مرحلة بناء.
النقطة الثانية التي ترضي في عامل الميناء هي واجهة عالمية لإطلاق الخدمات التعسفية. قام شخص بتجميع Docker ، ووضع شيء في الداخل ، والعمليات يكفي أن يقول Docker يجري ويبدأ.
ما هو Kubernetes؟ لذا صنعنا Docker ونحتاج إلى إطلاقه ودمجه وتكوينه وربطه بالآخرين في مكان ما. يتيح لك Kubernetes القيام بذلك. يقدم سلسلة من التجريدات ، والتي تسمى "الموارد". سنتناولها بسرعة ونحاول إنشاءها.
التجريد
التجريد الأول هو POD أو مجموعة من الحاويات. بشكل صحيح ، ما هي بالضبط
مجموعة من الحاويات ، وليس واحدة. يمكن أن تفتش المجموعات فيما بينها الأحجام التي ترى بعضها البعض من خلال المضيف المحلي. يسمح لك هذا باستخدام نمط مثل السيارة الجانبية (هذا عندما نطلق الحاوية الرئيسية ، وهناك حاويات مساعدة قريبة تساعدها).
على سبيل المثال ، نهج السفير. هذا عندما لا تريد الحاوية أن تفكر في مكان وجود بعض الخدمات. يمكنك وضع حاوية بجانبها تعرف أين توجد هذه الخدمات. وتصبح متاحة للحاوية الرئيسية على مضيف محلي. وهكذا ، تبدأ البيئة في الظهور وكأنك تعمل محليًا.
دعنا نرفع POD ونرى كيف يتم وصفه. محليا يمكنك تطوير minikube. إنه يأكل مجموعة من وحدات المعالجة المركزية ، ولكنه يسمح لك برفع مجموعة Kubernetes صغيرة على صندوق ظاهري والعمل معها.
دعونا نشر POD. قلت Kubernetes تطبيق وإغراق POD. أستطيع أن أرى ما PODs لدي: أرى أن POD واحد تم نشره. هذا يعني أن Kubernetes أطلقت هذه الحاويات.
يمكنني حتى الذهاب إلى هذه الحاوية.
من هذا المنظور ، تم تصميم Kubernetes للناس. في الواقع ، ما نقوم به باستمرار في العمليات ، في ربط Kubernetes ، على سبيل المثال ، باستخدام أداة kubectl ، يمكن القيام به بسهولة.
لكن POD قاتلة. يبدأ كركض Docker: إذا أوقفه أحد ، فلن يرفعه أحد. علاوة على هذا التجريد ، يبدأ Kubernetes في بناء ما يلي - على سبيل المثال ، مجموعة نسخ طبق الأصل. هذا هو المشرف الذي يراقب PODs ، ويراقب عددهم ، وإذا سقطت PODs ، فإنه يرفعها. هذا مفهوم مهم للشفاء الذاتي في Kubernetes يسمح لك بالنوم بهدوء في الليل.
فوق مجموعة النسخ المتماثلة ، يوجد تجريد للنشر - وهو أيضًا مورد يتيح لك القيام بوقت نشر صفر. على سبيل المثال ، تعمل نسخة متماثلة واحدة. عندما نقوم بنشر وتغيير إصدار الحاوية ، على سبيل المثال نسختنا ، داخل النشر ، ترتفع مجموعة نسخ متماثلة أخرى. ننتظر حتى تبدأ هذه الحاويات ، ونخضع لفحوصاتها الصحية ، ثم ننتقل بسرعة إلى مجموعة النسخ المتماثلة الجديدة. أيضا ممارسة كلاسيكية وجيدة.
دعنا نتلقى خدمة بسيطة. على سبيل المثال ، لدينا نشر. في الداخل ، يصف نمط PODs الذي سيلتقطه. يمكننا تطبيق هذا النشر ، ونرى ما لدينا. ميزة Kubernetes الرائعة - كل شيء يكمن في قاعدة البيانات ، ويمكننا مشاهدة ما يحدث في النظام.
هنا نرى انتشارًا واحدًا. إذا حاولنا إلقاء نظرة على PODs ، نرى أن بعض POD قد ارتفع. يمكننا أخذ وإزالة هذا POD. ماذا يحدث لل PODs؟ تم تدمير واحد ، والثاني يرتفع على الفور. لم يجد جهاز تحكم مجموعة النسخ المتماثل POD المطلوب وأطلق آخر.
علاوة على ذلك ، إذا كان هذا نوعًا من خدمة الويب ، أو يجب أن تتواصل داخل خدماتنا ، فنحن بحاجة إلى اكتشاف الخدمة. يجب أن تعطي الخدمة اسم ونقطة دخول. تقدم Kubernetes موردًا يسمى خدمة لهذا الغرض. يمكنه التعامل مع موازنة التحميل ويكون مسؤولًا عن اكتشاف الخدمة.
دعونا نرى خدمة بسيطة. نحن نربطها بالنشر و PODs عبر العلامات: مثل هذا الارتباط الديناميكي. مفهوم مهم للغاية في Kubernetes: النظام ديناميكي. لا يهم بأي ترتيب سيتم إنشاء كل هذا. ستحاول الخدمة العثور على PODs مع هذه التسميات وبدء توازن الحمل.
تطبيق الخدمة ، انظر الخدمات التي لدينا. نذهب إلى اختبار POD الخاص بنا ، والذي تم رفعه ، ونقوم nslookup. تعطينا Kubernetes نظام DNS-ku الذي يمكن للخدمات من خلاله رؤية واكتشاف بعضها البعض.
الخدمة هي واجهة. هناك العديد من التطبيقات المختلفة ، لأن مهام موازنة التحميل والخدمة معقدة للغاية: بطريقة ما نعمل مع قواعد البيانات العادية ، وفي الأخرى مع قواعد البيانات المحملة ، وبعضها البسيط يجعلها بسيطة للغاية. هذا أيضًا مفهوم مهم في Kubernetes: يمكن تسمية بعض الأشياء واجهات بدلاً من التطبيقات. لم يتم إصلاحها بشكل صارم ، ومختلف ، على سبيل المثال ، يقدم مزودو الخدمات السحابية تطبيقات مختلفة. هذا ، على سبيل المثال ، هناك حجم مستمر من الموارد ، والذي يتم تنفيذه بالفعل في كل سحابة معينة بوسائلها العادية.
بعد ذلك ، نرغب عادةً في إخراج خدمة الويب. Kubernetes لديه تجريد دخول. عادة يتم إضافة SSL هناك.
يبدو أبسط دخول شيء من هذا القبيل. هناك نكتب القواعد: أي عناوين URL ، والتي يستضيف لها ، أي خدمة داخلية لإعادة توجيه الطلب إليها. بنفس الطريقة ، يمكننا رفع دخولنا.
بعد ذلك ، بعد التسجيل محليًا في المضيفين ، يمكنك رؤية هذه الخدمة من هنا.
هذه مهمة عادية: نشرنا خدمة ويب معينة ، التقينا قليلاً مع Kubernetes.
سنقوم بتنظيف كل شيء ، وإزالة الدخول ونلقي نظرة على جميع الموارد.
هناك عدد من الموارد ، مثل configmap و secret. هذه موارد معلومات بحتة يمكنك تركيبها في حاوية ونقلها ، على سبيل المثال ، كلمة المرور من postgres. يمكنك ربط هذا بمتغيرات البيئة التي سيتم حقنها في الحاوية عند بدء التشغيل. يمكنك تحميل نظام الملفات. كل شيء مريح للغاية: المهام القياسية والحلول الرائعة.
هناك حجم ثابت - واجهة يتم تنفيذها بشكل مختلف من قبل موفري الخدمات السحابية المختلفين. وهي مقسمة إلى جزأين: هناك مطالبة مستمرة بالحجم (طلب) ، ثم يتم إنشاء بعض EBS تسحب إلى الحاوية. يمكنك العمل مع خدمة الدولة.
ولكن كيف يعمل في الداخل؟ المفهوم نفسه بسيط وشفاف للغاية. تتكون Kubernetes من جزأين. واحد هو مجرد قاعدة بيانات لدينا كل هذه الموارد. يمكن اعتبار الموارد كأقراص: على وجه التحديد ، هذه الحالات هي ببساطة سجلات في الأجهزة اللوحية. في أعلى Kubernetes ، تم تكوين خادم API. أي أنه عندما يكون لديك مجموعة Kubernetes ، فأنت تتصل عادةً بخادم واجهة برمجة التطبيقات (وبشكل أدق ، يتواصل العميل معها).
وفقًا لذلك ، ما قمنا بإنشائه (PODs ، الخدمات ، إلخ) مكتوب ببساطة في قاعدة البيانات. يتم تنفيذ قاعدة البيانات هذه من قبل ETCD ، أي بحيث تكون مستقرة عند مستوى عالٍ من التوفر.
ماذا يأتي بعد ذلك؟ علاوة على ذلك ، يوجد تحت كل نوع من الموارد وحدة تحكم معينة. هذه مجرد خدمة تراقب نوع مواردها وتقوم بعمل ما في العالم الخارجي. على سبيل المثال ، هل يعمل Docker. إذا كان لدينا PODs ، لكل عقدة هناك خدمة kubelet تراقب PODs المتصلة بهذه العقدة. وكل ما يفعله هو تشغيل Docker بعد الفحص الدوري التالي إذا لم يكن POD موجودًا.
علاوة على ذلك ، وهو أمر مهم للغاية - يحدث كل شيء في الوقت الفعلي ، لذا فإن قوة وحدة التحكم هذه أعلى من الحد الأدنى. في كثير من الأحيان ، لا تزال وحدة التحكم تأخذ المقاييس وتنظر في ما بدأت. على سبيل المثال إزالة التعليقات من العالم الواقعي وكتابتها إلى قاعدة البيانات ، حتى تتمكن أنت أو غيرها من وحدات التحكم من رؤيتها. على سبيل المثال ، سيتم إعادة كتابة حالة POD نفسها إلى ETCD.
وهكذا ، يتم تنفيذ كل شيء في Kubernetes. من الرائع جدًا فصل نموذج المعلومات عن غرفة العمليات. في قاعدة البيانات من خلال واجهة CRUD المعتادة نعلن ما يجب أن يكون. ثم تحاول مجموعة وحدات التحكم تصحيح كل شيء. صحيح أن هذا لا يحدث دائمًا.
هذا نموذج سيبرنيت. لدينا إعداد مسبق معين ، هناك نوع من الآلة التي تحاول توجيه العالم الحقيقي أو الآلة إلى المكان المطلوب. لا تسير الأمور دائمًا على هذا النحو: يجب أن يكون لدينا حلقة ملاحظات. في بعض الأحيان لا تستطيع الآلة القيام بذلك ويجب أن تتحول إلى شخص.
في الأنظمة الحقيقية ، نفكر في تجريدات المستوى التالي: لدينا بعض الخدمات وقواعد البيانات وكلنا نربطها. نحن لا نفكر في PODs و Ingresss ، ونريد بناء بعض المستوى التالي من التجريد.
بحيث كان المطور سهلاً قدر الإمكان: حتى قال ببساطة ، "أريد أن أبدأ مثل هذه الخدمة" ، وكل شيء آخر حدث في الداخل.
هناك شيء مثل هيلم. هذه هي الطريقة الخاطئة - نمذجة نمط غير مرئي ، حيث نحاول فقط إنتاج مجموعة من الموارد المكونة وإسقاطها في مجموعة Kubernetes.
المشكلة ، أولاً ، هي أن هذا يتم فقط في وقت الدحرجة. أي أنه لا يستطيع تنفيذ الكثير من المنطق. ثانياً ، يختفي هذا التجريد في وقت التشغيل. عندما أذهب لإلقاء نظرة على مجموعتي ، أرى فقط PODs والخدمات. أنا لا أرى أنه تم نشر مثل هذه الخدمة ، وأن مثل هذه والقاعدة مع النسخ المتماثل قد أثيرت هناك. أرى عشرات المداخن هناك. يختفي التجريد كما هو الحال في المصفوفة.
نموذج الحل الداخلي
من ناحية أخرى ، توفر Kubernetes نفسها نموذج امتداد مثير للاهتمام وبسيط للغاية في الداخل. يمكننا أن نعلن عن أنواع جديدة من الموارد ، على سبيل المثال النشر. هذا مورد مبني على PODs أو مجموعة النسخ المتماثلة. يمكننا كتابة وحدة تحكم في هذا المورد ، ووضع هذا المورد في قاعدة البيانات وتشغيل الحلقة الإلكترونية الخاصة بنا حتى يعمل كل شيء. يبدو هذا مثيرًا للاهتمام ، ويبدو لي أن هذه هي الطريقة الصحيحة لتمديد Kubernetes.
أود أن أكون قادرًا على كتابة بعض البيانات الظاهرة فقط لخدمتي على غرار البطل. مثال بسيط للغاية: أريد نشر نوع من التطبيق في بيئتي الحقيقية. بالفعل اتفاقات ، SSL ، المجالات التي تم شراؤها. أود فقط أن أعطي المطورين أبسط واجهة ممكنة. يخبرني Manifest أي حاوية يجب رفعها ، وما هي الموارد التي لا تزال بحاجة إليها. يرمي هذا الإعلان إلى الكتلة ، ويبدأ كل شيء في العمل.
كيف سيبدو هذا من حيث الموارد المخصصة وأجهزة التحكم؟ هنا سيكون لدينا تطبيق موارد في قاعدة البيانات. وسوف تولد وحدة تحكم التطبيق ثلاثة موارد. أي أنه سوف يكتب القواعد في الدخول حول كيفية التوجيه إلى هذه الخدمة ، وبدء الخدمة لموازنة الحمل ونشر النشر مع نوع من التكوين.
قبل أن ننشئ موردًا مخصصًا في Kubernetes ، نحتاج إلى الإعلان عنه. لهذا ، يوجد مورد تعريف يسمى CustomResourceDefinition.
من أجل إعلان مورد جديد في Kubernetes ، يكفي أن ننشر مثل هذا الإعلان. ضع في اعتبارك إنشاء هذا الجدول.
إنشاء جدول. بعد ذلك ، يمكننا إلقاء نظرة على kubectl للحصول على موارد الطرف الثالث التي لدينا. بمجرد الإعلان عن ذلك ، حصلنا أيضًا على لافتة. يمكننا القيام ، على سبيل المثال ، kubeclt بالحصول على التطبيقات. ولكن حتى الآن لا يوجد تطبيق.
لنكتب بعض التطبيقات. بعد ذلك ، يمكننا إنشاء مثيل مورد مخصص. لنلق نظرة عليه في YAML وننشئه عن طريق النشر على عنوان URL محدد.
إذا ركضنا ونظرنا في kubectl ، فسيظهر تطبيق واحد. ولكن على الرغم من عدم حدوث أي شيء ، فإنه يكمن فقط في قاعدة البيانات. يمكنك ، على سبيل المثال ، أخذ جميع موارد التطبيق وطلبها.
يمكننا إنشاء مورد ثان من نفس القالب ببساطة عن طريق تغيير الاسم. هنا هو المورد الثاني.
علاوة على ذلك ، يجب أن يقوم المتحكم لدينا بالتخطيط ، على غرار ما تقوم به HELM. بمعنى ، بعد أن تلقيت وصفًا لتطبيقنا ، يجب أن أقوم بإنشاء خدمة نشر الموارد والموارد ، وكذلك إدخال إدخال في الدخول. هذا هو الجزء الأسهل: هنا في clojure هو erlmacro. أمرر بنية البيانات ، فهي تسحب وظيفة النشر ، وتمرر إلى التصحيح ، وهو خط الأنابيب. وهذه وظيفة نقية: قوالب بسيطة. وفقًا لذلك ، في أكثر الأشكال سذاجة ، يمكنني إنشاءها على الفور ، وتحويلها إلى أداة مساعدة لوحدة التحكم والبدء في توزيعها.
نفعل نفس الشيء بالنسبة للخدمة: تقبل وظيفة الخدمة الإعلان وتولد لنا مورد Kubernetes.
نفعل نفس الشيء بالنسبة للخط في الدخول.
كيف سيعمل كل هذا؟ سيكون هناك شيء في العالم الحقيقي وسيكون هناك ما نريده. ما نريده - نحن نأخذ مورد التطبيق وننشئ عليه ما يجب أن يكون. والآن نحتاج أن نرى ما هو. ما نطلبه من خلال REST API. يمكننا الحصول على جميع الخدمات وجميع عمليات النشر.
كيف ستعمل وحدة التحكم المخصصة لدينا؟ سيحصل على ما نريد وما هو ، خذ من هذا التقسيم وقدم طلبًا إلى Kubernetes. هذا مشابه لرد فعل. توصلت إلى DOM افتراضي عندما تقوم بعض الوظائف ببساطة بإنشاء شجرة من كائنات JS. ثم تقوم خوارزمية معينة بحساب التصحيح وتطبيقه على DOM الحقيقي.
سنفعل نفس الشيء هنا. يتم ذلك في 50 سطرًا من التعليمات البرمجية. هل تريد - كل شيء موجود على جيثب. في النهاية ، يجب أن نحصل على وظيفة إجراءات التوفيق.
لدينا وظيفة إجراءات التوفيق التي لا تفعل شيئًا وتحسب فقط هذا div. تأخذ ما هو ، بالإضافة إلى ما هو مطلوب. ثم يوضح ما يجب القيام به لإحضار الأول إلى الثاني.
فلنجرها. لا حرج فيها ، يمكن أن تنحل. تقول أنك بحاجة إلى إنشاء خدمة دخول ، وإجراء إدخالين فيها ، وإنشاء عملية نشر 1 و 2 ، وإنشاء خدمة 1 و 2.
في هذه الحالة ، يجب أن يكون هناك بالفعل خدمة واحدة فقط. نرى من الدخول أنه لا يزال هناك إدخال واحد.
ثم كل ما تبقى هو كتابة دالة تطبق هذا التصحيح على مجموعة Kubernetes. للقيام بذلك ، نقوم ببساطة بتمرير إجراءات التوفيق إلى وظيفة التوفيق ، وسيتم تطبيق كل شيء. والآن نرى أن POD قد ارتفع ، وأصبح النشر قد بدأ وبدأت الخدمة.
دعنا نضيف خدمة أخرى: تنفيذ وظيفة إجراءات التوفيق مرة أخرى. دعنا نرى ما حدث. بدأ كل شيء ، كل شيء على ما يرام.
كيف تتعامل مع هذا؟ نحن نحزم كل هذا في حاوية دوكر. بعد ذلك ، نكتب دالة تستيقظ بشكل دوري ، وتتصالح ، وتنام. السرعة ليست مهمة جدًا ، يمكنها أن تنام لمدة خمس ثوانٍ وتقوم بأعمال التوفيق في كثير من الأحيان.
وحدة التحكم المخصصة لدينا هي مجرد خدمة تستيقظ وتحسب التصحيح بشكل دوري.
الآن لدينا خدمتين zaddeloino ، دعنا نحذف أحد التطبيقات. دعونا نرى كيف كان رد فعل مجموعتنا: كل شيء على ما يرام. نحذف الثاني: يتم مسح كل شيء.
دعونا نرى من خلال عيون المطور. يحتاج فقط إلى القول بأن Kubernetes تقدم طلبًا وتسمية الخدمة الجديدة. نفعل ذلك ، التقطت وحدة التحكم لدينا كل شيء وأنشأته.
ثم نجمع كل هذا في خدمة نشر ، ونقوم بإلقاء وحدة التحكم المخصصة هذه في المجموعة باستخدام أدوات Kubernetes القياسية. قمنا بإنشاء تجريد لـ 200 سطر من التعليمات البرمجية.
يبدو كل شيء مثل هيلم ، ولكن في الواقع أكثر قوة. تعمل أداة التحكم في مجموعة: فهي ترى القاعدة ، وترى العالم الخارجي ويمكن أن تكون ذكية بما يكفي.
CI الخاصة
النظر في أمثلة ملحق Kubernetes. قررنا أن CI يجب أن تكون جزءًا من البنية التحتية. هذا أمر جيد ، وهو ملائم من الناحية الأمنية - مستودع خاص. حاولنا استخدام جنكينز ، لكنها أداة قديمة. أردت القراصنة CI.
لا نحتاج إلى واجهات ، نحن نحب ChatOps: دعها تقول فقط في الدردشة ما إذا كان البناء قد سقط أم لا. بالإضافة إلى ذلك ، أردت تصحيح كل شيء محليًا.
جلسنا وكتبنا CI في غضون أسبوع. مجرد امتداد ل Kubernetes. إذا كنت تفكر في CI ، فهذه مجرد أداة تدير نوعًا من الوظائف. كجزء من هذه المهمة ، نبني شيئًا ونجري الاختبارات وننشر غالبًا.كيف يعمل كل ذلك؟ وهي مبنية على نفس مفهوم وحدات التحكم المخصصة. أولاً ، نسقط في Kubernetes وصفًا للمستودعات التي نتابعها. وحدة التحكم تذهب فقط إلى github وتضيف ربط الويب. لا يزال لدينا استبطان.يأتي بعد ذلك ربط الويب ، الذي تتمثل مهمته الوحيدة في معالجة JSON الوارد وإفلاته في مورد بناء مخصص ، والذي يضيف أيضًا إلى قاعدة بيانات Kubernetes. تتم مراقبة مورد البناء بواسطة وحدة تحكم البناء ، والتي تقرأ البيان داخل المشروع وتطلق POD. في هذا الدليل ، يتم إطلاق جميع الخدمات الضرورية.في POD ، وكيل بسيط جدًا يقرأ إعلانًا في نمط ترافيس أو سيركليسي ، وفي YAML ، مجموعة من الخطوات. يبدأ في تحقيقها. ثم في نهاية البناء يرمي بنتيجته في Telegram.ميزة أخرى حصلنا عليها مع Kubernetes هي أن أحد الأوامر في تنفيذ CI الخاص بك أو التسليم المستمر يمكن تعيينه ببساطة أثناء النوم الحقيقي 10 ، وسوف يتجمد POD الخاص بك في هذه الخطوة. يمكنك تنفيذ kubectl exec ، وتجد نفسك داخل المبنى الخاص بك ويمكنك الظهور لأول مرة.ميزة أخرى - كل شيء مبني على عمال الأرصفة ويمكنك تصحيح البرنامج النصي محليًا عن طريق تشغيل عامل الإرساء. استغرق الأمر كله أسبوعين و 300 سطر من التعليمات البرمجية.
العمل مع postgres
تم بناء منتجاتنا على postgres ، ونحن نستخدم جميع أنواع الميزات المثيرة للاهتمام. لقد كتبنا حتى عددًا من الامتدادات. ولكن لا يمكننا استخدام RDS أو أي شيء آخر.نحن الآن بصدد تطوير عامل تشغيل لـ postgres غير قابل للتدمير. سأبدو الهندسة المعمارية. أريد أن أقول "الكتلة ، أعطني بطاقات بريدية لا يمكن قتلها". أضف إلى ذلك أنني بحاجة إلى نسختين متماثلتين غير متزامنتين ، نسخة متزامنة ، نسخ احتياطي يوميًا وما يصل إلى تيرابايت. أرمي كل شيء ، ثم تبدأ وحدة تحكم الكتلة الخاصة بي في القيام بالتنسيق وتوسيع حاويتي. يخلق pginstance الموارد المسؤولة عن كل postgres istance. سيكون هذا postgres العنقودية.مزيد من وحدة تحكم pginstance ، بسيطة للغاية ، فقط تحاول تشغيل POD أو النشر هناك مع postgres. القلب هو حجم مستمر. هذا الجهاز كله يسيطر بشكل كامل على postgres. أنت تعطيها حاوية Docker ، والتي تحتوي فقط على postgres ثنائية فيها. كل شيء آخر: تقوم وحدة التحكم نفسها بتكوين وإنشاء مجموعة postgres لبدء التشغيل. يفعل ذلك حتى نتمكن من إعادة التكوين لاحقًا ، وحتى يتمكن من تكوين النسخ المتماثل ، ومستويات السجل ، وما إلى ذلك. في البداية ، يعمل POD المؤقت على وحدة التخزين الثابتة ويقوم بإنشاء مجموعة postgres للصفحة الرئيسية هناك.بعد ذلك ، علاوة على ذلك ، يبدأ النشر بالسيد. ثم يتم إنشاء وحدة تخزين ثابتة بنفس الطريقة. يقوم POD آخر بالمرور ، وإنشاء نسخة احتياطية أساسية ، وسحبه ، وفوق ذلك ، يبدأ النشر برقيق.بعد ذلك ، تقوم وحدة تحكم نظام المجموعة بإنشاء مورد نسخ احتياطي (بعد أن تم وصفه بالنسخ الاحتياطية). ووحدة التحكم الاحتياطية تأخذها بالفعل وترميها في بعض S3.
ما هي الخطوة التالية؟
دعنا نقدم لكم المستقبل القريب. قد يحدث أن عاجلاً أو آجلاً سيكون لدينا مثل هذه الموارد المخصصة المثيرة للاهتمام ، وحدات التحكم المخصصة التي سأقولها "أعطني postgres ، أعطني كافكا ، اترك لي CI وابدأ كل شيء." كل شيء سيكون بسيطا.إذا لم نتحدث عن المستقبل القريب ، فعندئذ كمبرمج إعلاني ، أعتقد أن البرمجة المنطقية أو العلائقية فقط هي الأعلى من البرمجة الوظيفية. هناك ، دلالات عملياتنا منفصلة تمامًا عن دلالات المعلومات. إذا نظرنا عن كثب إلى وحدات التحكم المخصصة التي قمنا بها ، فلدينا ، على سبيل المثال ، تطبيق موارد في قاعدة بياناتنا. ونستمد منها ثلاثة موارد إضافية. هذا يشبه إلى حد كبير طريقة عرض قاعدة البيانات. هذه حقيقة واقعة. هذه وجهة نظر منطقية أو علاقة.الخطوة التالية لـ Kubernetes هي إعطاء وهم معين لقاعدة علائقية أو منطقية بدلاً من REST API المفروم ، حيث يمكنك ببساطة كتابة قاعدة. نظرًا لأن كل شيء يتدفق عاجلاً أو آجلاً إلى قاعدة البيانات ، بما في ذلك الملاحظات ، فقد تبدو القواعد على النحو التالي: "إذا زاد الحمل بهذه الطريقة ، فقم بزيادة النسخ المتماثل على هذا النحو". سيكون لدينا قاعدة صغيرة أو قاعدة منطقية. كل ما تحتاجه هو محرك عام سيتبع ذلك. لكن هذا مستقبل مشرق.
— DevOops 2018 ! — .
«The DevOps Handbook» , «Learning Chef: A Guide to Configuration Management and Automation» , «How to containerize your Go code» «Liquid Software: How to Achieve Trusted Continuous Updates in the DevOps World» — . - .
: !
: 1 يمكنك حجز تذكرة لـ DevOops 2018 بخصم.