🤹🏻 🧕🏼 👲🏽 "Docker ميت بالفعل" أو أي شيء تريد أن تعرفه عن Devops لكنك كنت تخشى السؤال 🐐 👩🏽‍🤝‍👨🏼 ↕️

في الآونة الأخيرة ، تحدث ألكسندر تشيستياكوف ، DevOps الذي يتمتع بخبرة 7 سنوات والمؤسس المشارك لمجتمع المهندسين DevOps في سانت بطرسبرغ ، على شبكاتنا الاجتماعية.

Sasha هو أحد أفضل المتحدثين في هذا المجال ، وقد قام بأداء المسرحيات الرئيسية في Highload ++ و RIT ++ و PiterPy و Strike ، حيث قدم ما لا يقل عن 100 تقرير في المجموع. يوم الاثنين الماضي أجاب على أسئلة المشاهدين وتحدث عن تجربته.

نحن نشارك تسجيل البث والنسخ.

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

لقد استشرت في الأساس شركات أجنبية.

سنتحدث عن كيفية استخدام الناس لـ Kubernetes في الممارسة اليومية ، ولماذا هناك حاجة إليها ، ولماذا لا يجب أن تخافوا منها ، وما يجب الانتباه إليه وما سيحدث بعد ذلك.

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

كيف تطور هذا المشهد؟ أتذكر أجهزة الكمبيوتر المثبت عليها ROM Basic وكان من الممكن كتابة برامج بدون تثبيت نظام تشغيل. ومنذ ذلك الحين تدفقت مياه كثيرة تحت الجسر. في البداية ، لم يكن هناك نظام تشغيل على هذا النحو (بتعبير أدق ، تم كتابتها بلغة التجميع). ثم ظهرت لغة C وتحسن الوضع بشكل كبير. بالطبع ، نحن الآن على دراية بمفهوم نظام التشغيل: إنه نظام أساسي يسمح لنا بتشغيل تطبيقات مخصصة وإدارة الموارد التي لدينا على هذا الكمبيوتر. أو غيرها ، إذا تم توزيعها. حتى ذلك الحين ، كان من الممكن تجميع مجموعة حوسبة عالية الأداء من الكمبيوتر المحمول وسطح المكتب - وهذا ما فعله الطلاب في عنبر سانت بطرسبرغ للفنون التطبيقية في 97.

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

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

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

كان من المعتاد سؤال المطور عما يكتب عليه. كان هناك متخصصون في C ++ (على الأرجح ، والآن يوجد في مكان ما) ، يوجد الآن العديد من المتخصصين في PHP (يضحكون على أنفسهم أحيانًا) والعديد من مطوري JavaScript. تكتسب الأنواع ، لغة GoLang التي تحول إليها الأشخاص الذين لديهم معرفة بلغة PHP ، شعبية الآن. كانت هناك لغة بيرل (ربما لا تزال موجودة ، لكنها فقدت الكثير من شعبيتها) ، لغة روبي. بشكل عام ، يمكن كتابة طلب في أي شيء. إذا كنت تعيش في العالم الحقيقي ، فمن المحتمل أن تكون قد صادفت حقيقة أنها مكتوبة بأي شيء: Javascript، Rust، C؛ ابتكر اسمًا - تم كتابة شيء عليه.

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

على الرغم من حقيقة أن البشرية تتحرك على طول عملية تطورية معينة ، فإن هذه العملية متقاربة. في صناعتنا ، اتضح أن شخصًا ما لا يزال يكتب التعليمات البرمجية بلغة Perl (تحت mod_perl Apache) ، وأن هناك شخصًا ما يكتب بالفعل بنية خدمات مصغرة في GoLang. اتضح أن العقد مع المنصة مهم جدًا ، ومحتوى المنصة مهم جدًا ، ومن المهم جدًا أن تساعد المنصة الشخص. يصبح إجراء العمليات اليدوية مكلفًا للغاية من أجل إنهاء الخدمة وبدء تشغيلها. اضطررت للتعامل مع مشاريع بها 20 خدمة - ولم يكن مشروعًا كبيرًا جدًا ؛ لقد سمعت عن الرجال الذين لديهم ألف خدمة مختلفة. 20 مبلغ عادي ؛ ويتم تطوير كل مجموعة من الخدمات من قبل فريقه الخاص بلغته الخاصة ، ولا يتم توصيلها إلا من خلال بروتوكول التبادل.

فيما يتعلق بكيفية عمل عقد التطبيق. يوجد "بيان تطبيق مكون من 12 عاملاً" - 12 قاعدة لكيفية ترتيب التطبيق بحيث يكون مناسبًا للاستخدام. انا لا احبه. على وجه الخصوص ، تقول أنك بحاجة إلى تقديم تكوينات عبر متغيرات البيئة ؛ ولقد صادفت مرارًا وتكرارًا حقيقة أنه في Amazon ، على سبيل المثال ، عدد متغيرات البيئة التي يمكن تمريرها إلى Elastic Beanstalk هو صفحة واحدة من Linux kernel - 4 كيلوبايت. وتفيض بسرعة كبيرة. عندما يكون لديك 80 متغيرًا مختلفًا ، يصعب الالتزام بـ 81 متغيرًا. علاوة على ذلك ، إنها مساحة تكوين مسطحة - عندما تكون هناك متغيرات ، يجب تسميتها بأحرف كبيرة مع شرطة سفلية ، ولا يوجد تسلسل هرمي بينها ؛ من الصعب فهم ما يحدث. لم أفهم بعد كيفية التعامل مع هذا ، وليس لدي من أناقش الأمر معه - لا توجد مجموعة من المتحمسين ،من سيكون ضد مثل هذا النهج. إذا كان هذا فجأة لا يناسب شخصًا ما - اكتب لي (المزيل في Telegram) ، فسأعرف أنني لست وحدي. أنا لا أحب ذلك على الإطلاق. من الصعب إدارتها ، ومن الصعب نقل البيانات الهرمية ؛ اتضح أن مهمة المهندس الحديث هي معرفة مكان المتغيرات ، وماذا تعني ، وما إذا كانت قد تم ضبطها بشكل صحيح ، ومدى سهولة تغييرها. أعتقد أن قواعد التكوين القديمة الجيدة كانت أفضل.ما إذا تم إعدادها بشكل صحيح ، ما مدى سهولة تغييرها. أعتقد أن قواعد التكوين القديمة الجيدة كانت أفضل.ما إذا تم إعدادها بشكل صحيح ، ما مدى سهولة تغييرها. يبدو لي أن قواعد التكوين القديمة الجيدة كانت أفضل.

العودة إلى العقد. اتضح أنك بحاجة إلى صورة Docker: ستحتاج إلى Docker نفسه (على الرغم من حقيقة أنها فقيرة - آمل أن تشتريها بعض Microsoft وتقوم إما بدفنها أو تطويرها بشكل طبيعي). إذا لم تكن راضيًا عن Docker ، يمكنك تجربة Red Hat's Stack ؛ لا يمكنني قول أي شيء عنها ، على الرغم من أنه يبدو لي أنه يجب أن يكون أفضل من مجرد Vanilla Kubernetes. يولي الرجال من Red Hat مزيدًا من الاهتمام لقضايا الأمان ، بل إنهم يعرفون كيفية إجراء عمليات تثبيت متعددة الاستخدامات ، ومتعددة المستخدمين ، ومتعددة العملاء ، مع فصل طبيعي للحقوق - بشكل عام ، يتأكدون من أن إدارة الحقوق في مكانها الصحيح.

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

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

مع Kubernetes ، لدينا نفس الموقف بالنسبة لشركات الطيران مع Boeing 737 MAX - فهي لا تطير بسبب وجود خطأ فيها ، ولكن لا يوجد شيء آخر ، لأن التصميم معقد للغاية. لا أستطيع أن أقول إنني أحبها - مثل لغة GoLang ، والتحكم من خلال تنسيق YAML ، عندما يكون لديك بعض بناء الجملة ، ولا يوجد شيء فوقها - لا تحقق مما تكتبه ، ولا أنواع البيانات. جميع عمليات التحقق التي تجريها قبل تطبيق التكوينات في Kubernetes هي بدائل. يمكنك محاولة تطبيق التكوين الخاطئ وسيتم تطبيقه دون سؤال ولا تعرف ماذا. من السهل جدًا كتابة ملف التكوين الخاطئ. هذه مشكلة كبيرة ، وقد بدأ الناس بالفعل في حلها ببطء باستخدام DSL و Kubernetes بلغات Kotlin ، حتى Typescript. يوجد مشروع بولومي ،هناك مشروع أمازون EKS - على الرغم من أنه يركز بشكل أكبر على أمازون ؛ Pulumi هو Terraform ، فقط في الكتابة المطبوعة. أتمنى لو أنني جربت Pulumi حتى الآن لأنني أعتقد أنه المستقبل. يجب وصف التكوين بلغة برمجة ذات كتابة ثابتة قوية ، بحيث يتم إخبارك على الأقل في وقت التجميع أن هذا غير ممكن قبل تطبيقه ، والذي قد يؤدي إلى تدمير الكتلة.

وبالتالي ، في الوقت الحالي لا يوجد سوى منسق واحد. أعلم أن هناك بعض مستخدمي MATA غادروا ، أصافحهم ؛ آمل ألا يستخدم أي شخص آخر Docker Swarm - كانت تجربتي معها سلبية للغاية. أعتقد أنه يمكن أن يكون الأمر خلاف ذلك ، لكني لا أعرف لماذا. لا أتوقع أي تطوير إضافي لـ Docker Swarm ، ولا أعتقد أن الأشخاص الذين يطلقونه سيفعلون أي شيء به الآن. الرأسمالية إذا لم تكسب المال ، فلن يكون هناك ما تنفقه على التطوير - وكانت شركتهم في "وادي الموت" للشركات الناشئة خلال العامين الماضيين: لا أحد يريد منحهم المال. يمكنك وضع مزايدات على من سيشتريها. لم تكن مايكروسوفت مهتمة. ربما سيفعل ذلك بعض Microfocus إذا نجا Docker.

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

ماذا يمكن أن يفعل؟ فقط تخيل أنك بحاجة إلى أن تشرح لطفل يبلغ من العمر خمس سنوات ما فعلته في العمل. وهكذا أبي ، الذي حاول كتابة كتيبات اللعب والأدوار على Ansible والتي من شأنها أن تسمح له بالقيام بالنشر باللونين الأزرق والأخضر استنادًا إلى Nginx على مضيف ومجموعة من الحاويات غير المسجلة بأي شيء آخر غير التلفزيون ، يقول: حان الوقت لإنشاء Kubernetes الخاصة بك. إنه لا يعمل بشكل جيد ، لقد تم اختباره بشكل سيئ ، ولا أفهمه جيدًا ، ولا أعرف جميع الشروط الحدودية ، إنه يعمل داخل نفس الجهاز ، لكنه ملكي! " لقد رأيت هذا مرات عديدة بشكل غير مبرر - لقد شاهدته للتو مرتين أو ثلاث مرات ، وشاركت مرتين في كتابة شيء كهذا. عاجلاً أم آجلاً ، يدرك الشخص الذي يشارك في هذا أنه لا ينبغي أن يكون هناك مرة رابعة. إنه مثل أصدقائي في السيارةالذي قام بترميم VAZ-2101 ذات مرة - نوافذ كهربائية مثبتة ، قام بإصلاح الجزء الداخلي بقطيع ، ورسمه بالمعدن. إنشاء المنسق الخاص بك هو شيء من هذا القبيل. يمكنك تجربته مرة واحدة للتأكد من أنه يمكنك ذلك ، لكنني لست مستعدًا للتوصية به للجميع - وليس فقط المتحمسين. لذلك ، فإن إدارة دورة الحياة وإدارة حالة الحاوية هي مهمة Kubernetes.

يمكنه التأكد من أن الحاوية تعمل على العقدة التي توجد بها موارد ، ويمكنه إعادة تشغيل حاوية ميتة ، ويمكنه التأكد من أنه إذا لم تبدأ الحاوية ، فلن تذهب حركة المرور إليها إذا كان هناك نشر جديد. بدأنا أيضًا بالقول إن Kubernetes هو نظام التشغيل ؛ حيث يوجد نظام التشغيل ، يجب أن يكون هناك مدير حزم. عندما بدأ برنامج Kubernetes ، كان وصف الكائن أمرًا ضروريًا ؛ المجموعة ذات الحالة ووصف الكود هي أوصاف تعمل بشكل مباشر ، وتحتاج إلى إضافة شيء في الأعلى لجعل حالة [؟؟؟ 18:52 - تسجيل خلل]. في الواقع ، الاختلاف الجذري عن Ansible وأنظمة إدارة التكوين المماثلة الأخرى هو أنك في Kubernetes تصف ما يجب أن يتحول ، وليس كيف يجب أن يكون. أنت تصف بشكل طبيعيما هي الأشياء التي لديك وما هي خصائصها. الكائنات هي service ، والتوزيع ، و daemonset ، و statefulset. ومن المثير للاهتمام أنه بالإضافة إلى تلك الكائنات التي يمكن إنشاؤها بشكل قياسي ، هناك أيضًا كائنات مخصصة يمكن وصفها وإنشاؤها في Kubernetes. مفيد جدا؛ كما أنه سيضعف بشكل كبير صفوف مسؤولي النظام ومهندسي devops.

متى يموت Kubernetes؟

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

Docker ميت بالفعل. عندما تموت Kubernetes - فلننتظر 5 سنوات. لن تموت ، سيحصل عليها الجميع - ستكون داخل Tesla ، داخل هاتفك ، في كل مكان ، ولن يهتم أحد بالحديث عنها. أعتقد أن هذا هو الموت. ربما ليس في غضون 5 سنوات ، ولكن في 3. سؤال آخر هو ما الذي سيحل محله: بعض التقنيات الجديدة بصوت عالٍ التي سيتحدث عنها الجميع ، وربما ليس من عالم DevOps على الإطلاق. يتحدثون الآن عن Kubernetes حتى لمجرد إبقاء المحادثة مستمرة ، ولا بأس بذلك - إنها عصرية.

ما هو الخطأ في Docker؟

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

كيف تخزن الدول؟ هل يمكنني استضافة قاعدة البيانات على Kubernetes؟

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

أعتقد أنه يمكن تمثيل قواعد البيانات في Kubernetes. ما مدى موثوقيتها؟ حسنًا ، انظر: نحن نتعامل مع نظام موزع. عندما تضع قاعدة بيانات في نظام مجموعة ، يجب أن تفهم أن لديك متطلبًا للتسامح مع الخطأ. إذا كان لديك مثل هذا المطلب ، فمن المرجح أن ما تضعه داخل Kubernetes هو مجموعة قواعد بيانات. كم عدد الأشخاص في العالم الحديث الذين يعرفون كيفية عمل مجموعة قواعد بيانات عادية؟ هل توفر العديد من قواعد البيانات إمكانيات التجميع؟ هنا يبدأ تقسيم قواعد البيانات إلى تقليدية - علائقية ، وغير علائقية. لا يتمثل الاختلاف بينهما في أن الأخير لا يدعم SQL بشكل أو بآخر. الفرق هو أن قواعد البيانات غير العلائقية مناسبة بشكل أفضل للعمل في مجموعات ، لأنها كتبت في الأصل بحيث تم توزيع قاعدة البيانات. وبالتالي،إذا كنت ترغب في استضافة بعض MongoDB أو Cassandra في Kubernetes ، فلا يمكنني ثنيك عن ذلك ، ولكن يجب أن تكون لديك فكرة جيدة جدًا عما سيحدث بعد ذلك. يجب أن تفهم جيدًا مكان وجود بياناتك ، وما الذي سيحدث في حالة الفشل والاسترداد ، وكيف يتم إجراء النسخ الاحتياطية ، وأين توجد نقطة الاسترداد ، والوقت الذي سيستغرقه التعافي. هذه الأسئلة ليست ذات صلة بـ Kubernetes ؛ يتعلق الأمر بكيفية تشغيل حل الكتلة استنادًا إلى قواعد البيانات التقليدية. إنه أسهل مع حلول NoSQL ، فهي جاهزة على الفور للشبكة السحابية.أين هي نقطة الاستعادة وكم من الوقت سيستغرق التعافي. هذه الأسئلة ليست ذات صلة بـ Kubernetes ؛ يتعلق الأمر بكيفية تشغيل حل الكتلة استنادًا إلى قواعد البيانات التقليدية. إنه أسهل مع حلول NoSQL ، فهي جاهزة على الفور للشبكة السحابية.أين هي نقطة الاستعادة وكم من الوقت سيستغرق التعافي. هذه الأسئلة ليست ذات صلة بـ Kubernetes ؛ يتعلق الأمر بكيفية تشغيل حل الكتلة استنادًا إلى قواعد البيانات التقليدية. إنه أسهل مع حلول NoSQL ، فهي جاهزة على الفور للشبكة السحابية.

ولكن لا يزال السؤال الذي يطرح نفسه - لماذا وضع قاعدة البيانات في Kubernetes؟ يمكنك الحصول على خدمة مقدمة من مزودك ، حل مُدار ؛ يمكنك أخذ RDS من Amazon ، وكذلك قاعدة بيانات مُدارة من Google. وحتى المجموعة الموزعة جغرافيًا لقاعدة البيانات هذه ، في حالة Amazon ، هذه هي Aurora ، يمكنك تثبيتها واستخدامها. ولكن ، إذا كنت تنوي تثبيت مجموعة قاعدة موزعة جغرافيًا ، فاقرأ التوثيق بعناية ؛ لقد صادفت مجموعات Aurora مع عقدة واحدة - لم يتم تقسيمها حتى إلى منطقتين. علاوة على ذلك ، فإن المنطقة الثانية ليست ضرورية على الإطلاق. بشكل عام ، لدى الناس أشياء غريبة جدًا في رؤوسهم: فهم يعتقدون أن الشيء الرئيسي هو اختيار منتج ، وبعد ذلك سيوفر نفسه ويعمل كما ينبغي. لا. لم تكن قواعد البيانات العلائقية جاهزة على الإطلاق للعمل حتى في مجموعة منتظمة ،ناهيك عن التوزيع الجغرافي. لذلك ، إذا كنت تفعل شيئًا معقدًا بناءً عليها ، فراجع الوثائق.

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

إذا كان لديك حل متوسط أو صغير - حل متوسط لروسيا يتوافق تقريبًا مع وكالة أنباء كبيرة مثل Lenta - فلا ينبغي أن يكون هناك عدد كبير من الاستفسارات المعقدة لقاعدة البيانات. إذا كانت القاعدة لا تتأقلم ، فمن المحتمل أنك تفعل شيئًا خاطئًا وتحتاج إلى التفكير فيه. لا تتوسع بلا تفكير. إن نقل حل غير مجمع إلى مجموعة له مزايا ، ولكن أيضًا عددًا كبيرًا من العيوب - خاصة إذا كنت تأخذ مجموعة postgres استنادًا إلى Patroni أو Stallone. هناك العديد من الشروط الحدودية. لم أصادفهم ، لكن الزملاء من Data Egret سيسعدون أن يخبروك عن كيفية حدوث ذلك. هناك تقرير رائع من قبل Alexei Lesovsky حول ما سيحدث إذا حاولت نقل قاعدتك إلى كتلة دون تفكير.

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

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

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

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

لقد قمت بتنزيل كتاب Red Hat - الذي يقدمونه مجانًا - حول كيفية عمل مشغلي Kubernetes وكيفية كتابة كتابك الخاص ، أوصي بالذهاب إلى موقع الويب الخاص بهم وتنزيله أيضًا ، الكتاب ممتع للغاية. عندما أقرأها بالكامل ، ربما يمكننا تحليل بعض العوامل معًا.

من يدعم السرب؟ إلى جانب Docker Inc؟

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

السيد / العبد

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

ما اسم كتاب ريد هات؟

يطلق على مشغلي Kubernetes ذلك. البطة مرسومة هناك. كتاب O'Reilly ، أعاد تصميم الأغلفة الآن ؛ تم نشر عدد غير قليل من الكتب بالتعاون مع Red Hat. لدى Red Hat ثلاثة أو أربعة كتب أخرى من Kubernetes يمكنك تنزيلها مجانًا: على سبيل المثال ، Kubernetes Patterns و gRPC. يستخدم العديد من بروتوكول gRPC لتبادل البيانات بين الخدمات المصغرة ، على الرغم من أنه لا يرتبط مباشرة بـ Kubernetes. بالإضافة إلى ذلك ، يتم استخدامه في الجيل التالي من موازنات الأحمال ، على سبيل المثال ، في Envoy.

ما هو SRA؟

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

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

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

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

من المهم جدًا عندما يكون لديك نظام أساسي لبنية الخدمات المصغرة أن تجعله قابلاً للتتبع والملاحظة ، حتى تتمكن من فهم مكان الطلبات وأين تضيع الوقت وما إلى ذلك. بناء مثل هذه المنصة يتطلب الكثير من العمل. سوف تحتاج إلى بروميثيوس. ستكون هناك حاجة لأنه مشروع مؤسسة Cloud Native Computing Foundation ؛ إنه مصمم خصيصًا لمراقبة Kubernetes. يحتوي على عدد كبير من المصدرين ومجمعي المقاييس ؛ تحتوي بعض التطبيقات في الأصل على جميع لوحات المعلومات الخاصة بها. إذا كان التطبيق الخاص بك لا يحتوي عليها ، فسيستغرق الأمر 20 دقيقة لإرفاقها بتطبيق لوحة معلومات Prometheus طويل العمر. على الرغم من أنه لسبب ما لا أحد يعلقه. من واقع خبرتي ، يحدث هذا لأن الناس يحتفظون بمنتجاتهم في السحاب. هناك Amazon CloudWatch و Google StackDriver وويمكنك إرسال المقاييس إلى هناك بنفس الطريقة - على الرغم من أنها ستكلف مالًا. أي ، إذا استمر الناس في الدفع مقابل البنية التحتية ، فإنهم يدفعون مقابل أدوات المراقبة المرتبطة بها. ومع ذلك ، يمكن أن يكون Prometheus مناسبًا للغاية إذا كان لديك عدة أماكن مختلفة تأخذ منها المقاييس ، إذا لم تكن السحابة في مكان واحد ، إذا كانت مختلطة ، إذا كانت لديك أجهزة محلية وتحتاج إلى بنية تحتية مركزية. ثم بروميثيوس هو خيارك.إذا كان لديك أجهزة داخل الشركة وتحتاج إلى بنية تحتية مركزية. ثم بروميثيوس هو خيارك.إذا كان لديك أجهزة داخل الشركة وتحتاج إلى بنية تحتية مركزية. ثم بروميثيوس هو خيارك.

ماذا تريد ايضا؟ من الواضح أنه حيث توجد بروميثيوس ، هناك أيضًا حاجة إلى مدير التنبيهات. وتحتاج أيضًا إلى نوع من التتبع الموزع لطلباتك. كيفية القيام بذلك في Kubernetes - حسنًا ، خذ بعض المنتجات مثل jaeger أو zipkin أو أي شيء موجود في الأعلى الآن ؛ أيضًا Cassandra لتخزين آثارك ، وكذلك Grafana لتقديمها. على حد علمي ، ظهرت هذه الميزة في Grafana مؤخرًا ، لكن هذا ليس سببًا لعدم تنفيذها. وهذا يعني أنه يمكنك تجميع بيئة يدويًا حيث ستعمل التطبيقات فيها على [مواطن الخلل 49:14] (؟) بحلول وقت التشغيل هذا ، كل من العدادات والمقاييس الأخرى المناسبة لبناء وتصور آثارك الموزعة: أين يقضي التطبيق كم من الوقت؟

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

أعتقد أنني أخبرت كل ما أريد قوله. سأكرر الأحكام الرئيسية مرة أخرى.

أولاً: يريحك برنامج Kubernetes من الحاجة إلى كتابة آلية لاستبدال حاوية بأخرى بأمان على Ansible Engine X.

ثانيًا: لن تختفي Kubernetes في أي مكان. يمكن أن "يموت" ، لكن لم يعد من الممكن التوقف عن استخدامه ، فقد استحوذ على معظم السوق. على السؤال "متى يموت Kubernetes:" أريد أن أسأل "متى يموت WordPress؟" ولا يزال يتعين عليه أن يعيش ويعيش ، فلنضبط الترتيب: أولاً WP ، ثم Kubernetes.

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

ماذا سيحدث غير ذلك؟ ستكون هناك أيضًا القدرة على إدارة كل هذا ، لغات البرمجة المكتوبة بشكل ثابت مثل GoLang و TypeScript. وأنا أؤمن حقًا بـ Kotlin - تمت كتابة الكثير من DSLs الرائعة عليها بالفعل. وسوف يكتب المزيد.

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

لكن كل هذا لا يعني أن Kubernetes جيد ، ولا شيء يمكن أن يكون أفضل. أقارنه بما كان عليه من قبل - مع حلول أمازون: ECS ، Elastic Beanstalk. أولئك الذين صادفوهم يعرفون أنه في تشبيهي القديم أن شيئًا واحدًا لن يكون مجرد 737 ماكس ، ولكن 737 ماكس ، مصنوع من الشريط الكهربائي والبلاستيك. لذلك ، فإن اللاعبين الرئيسيين - Amazon و Microsoft Azure و Google - موجودون بالفعل في Kubernetes. من المحتمل أن يكون Yandex و Mail.ru أيضًا ، لكنني لا أتابعهم. هذا مستقبل مشترك. مثل هذا المستقبل المشترك السيئ ، ولكن "الجيد بما فيه الكفاية" الذي يتفق عليه الجميع حتى الآن. ماذا سيتحول كل هذا إلى التالي ، عليك أن تسأل ريد هات - إنهم أذكى مني.

ما هو شعور Java تجاه Kubernetes؟

غرامة.

ما هو نظام التشغيل الذي تستخدمه على جهاز الكمبيوتر الخاص بك؟

كلاهما يعمل بنظام macOS.

هل يتم تعيين متخصصي DevOps بشكل نشط الآن؟

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

"Docker ميت بالفعل" أو أي شيء تريد أن تعرفه عن Devops لكنك كنت تخشى السؤال