Get best of the week

Kubernetes و Microservices و CI / CD و Dockers for Retrogrades: نصائح تعليمية

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

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

لماذا أجد أنه من المهم أن أتمكن من تغيير نموذج التفكير التكنولوجي؟

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

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

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

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

اتجاهات الغوص


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

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

, .لذا ، فقد وافقنا على أننا نطلق الآن التطبيقات في عامل الميناء وأننا نشارك التطبيق في الخدمات المصغرة. الآن نحن بحاجة إلى إدارة عمال الأرصفة بطريقة أو بأخرى. يمكنك القيام بذلك بنفسك على خوادم مخصصة (والتوجيه ، على سبيل المثال ، Docker Swarm ، أو بناء Kubernetes) ، أو يمكنك استخدام الخدمات التي توفرها السحب - خدمات الحاويات من AWS أو Kubernetes. هناك ميزة واحدة كبيرة للغاية لاستخدام الغيوم. أنت ، في الواقع ، توقف عن التفكير في الطبقة التي تعمل تحت مدير الحاوية (ستضحك SRE الآن ، لكن دعنا نعترف - عندما يكون كل شيء مستقرًا ، لا نتسلق على عقد GKE في معظم الحالات). وبالتالي ، في الواقع ، فإن مدير الحاوية ، الذي أصبح Kubernetes القياسي الخاص به ، يتحول إلى نظام تشغيل. لديها مدراء حزم ، يمكنك "تثبيت البرنامج" فيه ، يمكنك تشغيل "exe-shniki" فيه - عمال الموانئ ،لديها kronjoby. Kubernetes هو نظام تشغيل جديد.

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

نفهم أن الاستضافة المحلية لمعظم التطبيقات ستكون شيئًا من الماضي (في الغرب - ذهب بالفعل).ذات مرة ، كان من المعتاد شراء الخوادم ، وتجميعها ، وإحضارها إلى العاصمة ، ووضع التجميع والتبديل. حتى بالنسبة لمشروع صغير. ثم جاءت الخوادم المخصصة. كم من الناس يفكرون الآن في تعذيب وشراء وجمع الحديد في المشاريع الصغيرة والمتوسطة؟ مخصص - في الغرب الآن ، وفي الاتحاد الروسي قريبًا - سيتم استبداله بالغيوم. لقد تم الحديث عن هذا منذ مائة عام ، وأنا أستخدم AWS منذ عام 2008 ، ولديها مشاكل ، ولكن عندما نتحدث عن الخدمة التي تتولى إدارة Kubernetes (EKS أو GKE أو Kubernetes من Yandex أو Selectel) ، لا أفهم سبب الإدارة Kubernetes و Dediks أنفسهم ، إذا فعلها أشخاص آخرون؟ لم أعد أغير المبردات في Dediks بعد الآن ... مسألة انتشار توزيعات Kubernetes المحلية في الاتحاد الروسي هي مسألة سعر صرف الدولار ،قانون بيرسدان و "شباب" استضافة السحابة الروسية. عاجلاً أم آجلاً ، سيتم تحديد هذا الأمر وسيصبح على مستوى المنشأة الوحشية التي تريدها الشركات والمشاريع الكبيرة المحملة. مع نفس القواعد. إذا كنا نتحدث عن معظم التطبيقات التي لا تتطلب تحميلًا فائقًا أو ضبطًا قويًا للغاية ، فإن PostreSQL / MongoDB / MySQL القائم على السحابة يوفر عددًا كبيرًا من المزايا. لا حاجة للتفكير في الضبط ، لا حاجة للتفكير في النسخ الاحتياطية. أنشئ خادم ديف من خادم إنتاج - أمرين في وحدة التحكم السحابية. أتفهم أن هذه الفكرة بأكملها يمكن أن تسبب الغضب في المشرف: يا رفاق ، أنا المشرف بنفسي ، ولكن بالنسبة إلى معظم المهام غير السيئة ، لا داعي لإدارة قاعدة البيانات. ربما تكون AWS و GKE باهظة الثمن ولا يمكن الوصول إلينا بسبب القانون الفارسي ، ولكن هذا هو وقت إضافي للتأخر: عاجلاً أم آجلاً ، سيكون لـ Yandex أو Selectel نفس الميزات ،وسوف يتغير النموذج.

فهم ما هي البنية التحتية المكتوبة الآن. لم يعجبني IaaC عندما كان شيفًا وعرائسًا ، ولكن الحمد لله تم استبدالهم بـ Terraform و Pulumi الأكثر ملاءمة لوصف ما تريد رفعه في المجموعة ، و Ansible للعمل في الداخل. ادخل وضع شيء في الصدفة - الآن وحشية مطلقة. نعم ، إنه أسرع وأكثر ملاءمة ، ولكن في النموذج الجديد ، البراري: تذكر exe.

دورة الغوص العميق


كيف أرى طريقة فنية محددة لفهم كيفية العمل مع مكدس حديث؟

1) قم بإنشاء حساب تجريبي على الاستضافة السحابية. يقدمها جميع مقدمي الاستضافة. لقد بدأت مع GKE ، ولكن يمكنك ، على سبيل المثال ، أخذ حساب على خدمات الاستضافة الروسية ، إذا كنت تتوقع أنك ستعمل ، على الأرجح ، في هذه المنطقة.
إذا كان Terraform / Pulumi يدعم السحابة الخاصة بك ، فصف البنية التحتية التي تريد إنشائها فيها. إذا كان لديك مهارات برمجة ، أوصي بـ Pulumi: بدلاً من Terraform SDL الخاصة بك ، يمكنك الكتابة بلغات مألوفة وتركيبات.

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

3) تعامل مع التركيبات الأساسية (لـ ، النشر ، الخدمة) لـ K8S ونشر التطبيق بيديك في مجموعة K8S.

4) التعامل مع هيلم ، كتابة مخطط هيلم ، نشر تطبيق هيلم.
خذ خطة مجانية على CircleCI كـ CI-ke ، والتي لا تحتاج إلى ضبطها ، وقم بتكوينها: ستكون التكوينات مشابهة للأنظمة الأخرى.

5) إصلاح التطبيق من خلال CI-ku.
منفصلة CI (ما يبنيه التطبيق) وقرص مضغوط. قم بإنشاء قرص مضغوط بواسطة GitOps (انظر ، على سبيل المثال ، ArgoCD).

ماذا بعد


في مكان ما من الآن فصاعدًا ، ستدرك ، من حيث المبدأ ، الأسس الرئيسية للمكدس الحديث.
أين يمكنني مواصلة البحث؟

  • إذا كنت تبحث عن وظيفة / ترغب في العمل في الغرب ، فيمكنك الانتقال إلى معرفة أعمق بالحوسبة السحابية: أرسل شهادة Google أو ما يعادلها من AWS إلى Cloud Architect (تلقينا مؤخرًا 3 مثل هذه الشهادات في ITSumma ). سيعطي هذا فكرة عن الميزات التي تعطي السحابة ، ويساعدهم على التنقل. دورة جيدة في لينكس أكاديمي .
  • سلم إلى CKA: هذا موضوع صعب ولكنه يستحق ذلك. سيوفر التحضير للامتحان حزمة ضخمة من المعرفة.
  • تعلم البرمجة إذا كنت لا تعرف كيف. الآن ذهبت لدراسة الجبهة وأنا مندهش من كيفية تغير كل شيء. علمي انتهى في مكان ما في عام 2012 أو حتى في وقت سابق ، في jQuery ، يضحك الناس. أصبحت الواجهة الآن أكثر تعقيدًا من الواجهة الخلفية ، وهناك قدر كبير من منطق التطبيق وفي نفس الوقت نماذج غير عادية تمامًا بالنسبة لي. مثير جدا!

وأنا أكثر انتظامًا من المدونة هنا ، أحتفظ بقناتي برقية ، اشترك :-)

More articles:


All Articles