كيف تصبح مهندس DevOps في ستة أشهر أو أقل ، الجزء 2: تكوين

الصورة من ريتو سيمونت على Unsplash

ملاحظة: هذا هو الجزء 2 من سلسلة متعددة الأجزاء. للجزء 1 ، الرجاء الضغط هنا.

خلاصة سريعة

في الجزء الأول ، قلت إن مهمة DevOps Engineering هي إنشاء خطوط أنابيب رقمية مؤتمتة بالكامل تنقل الشفرة من آلة مطور إلى إنتاج.

الآن ، للقيام بهذه المهمة بفعالية يتطلب فهمًا قويًا للأساسيات ، كما هو موضح هنا:

أساسيات DevOps

بالإضافة إلى فهم جيد للأدوات والمهارات (انظر الرسم التوضيحي التالي) الذي يعتمد على هذه الأساسيات.

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

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

التركيز على مرحلة التكوين

نظرة عامة

ماذا يحدث خلال مرحلة التكوين؟

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

في الماضي ، كانت البنية التحتية لتوفير محنة طويلة ، كثيفة العمالة ، وعرضة للخطأ.

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

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

لماذا ا؟

لأن النقر على زر هو

  1. عرضة للخطأ (البشر يخطئون) ،
  2. لم يتم إصدار نسخة منه (لا يمكن تخزين النقرات في بوابة) ،
  3. غير قابل للتكرار (المزيد من الآلات = المزيد من النقر) ،
  4. وليس قابلاً للاختبار (لا توجد فكرة عما إذا كانت نقراتي ستنجح فعليًا أو ستخبط الأمور).

على سبيل المثال ، فكر في كل العمل المطلوب لتوفير بيئة التطوير لديك ... ثم البيئة int ... ثم QA ... ثم التدريج ... ثم prod في الولايات المتحدة ... ثم prod في الاتحاد الأوروبي ... تصبح مملة للغاية ومزعجة للغاية وبسرعة كبيرة.

لذلك ، هناك حاجة إلى طريقة جديدة. هذه الطريقة الجديدة هي البنية التحتية ككود وهذا ما تدور حوله مرحلة التهيئة.

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

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

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

  1. كتابة حالة البنية التحتية المطلوبة في Terraform ،
  2. قم بتخزينه في تحكم الكود المصدر ،
  3. انتقل من خلال عملية طلب سحب رسمية لطلب التعليقات ،
  4. قم بتجريبه،
  5. تنفيذ لتوفير جميع الموارد اللازمة.

لماذا هذا وليس هذا؟

الآن ، السؤال الواضح هو ، "لماذا Terraform؟ لماذا لا الشيف أو العرائس أو Ansible أو CFEngine أو الملح أو CloudFormation أو $ {مهما كان؟ ”

سؤال جيد! براميل من الحبر الظاهري قد انسكبت مناقشة هذه المسألة بالذات.

باختصار ، أعتقد أنك يجب أن تتعلم Terraform بسبب

  1. إنه عصري للغاية ، وبالتالي فإن فرص العمل وفيرة
  2. من الأسهل إلى حد ما التعلم من الآخرين
  3. انها عبر منصة

الآن ، هل يمكنك اختيار واحد من الآخرين ولا تزال ناجحة؟ إطلاقا!

ملاحظة جانبية: هذه المساحة تتطور بسرعة وهي مربكة للغاية. أريد أن يستغرق بضع دقائق للحديث عن بعض التاريخ الحديث وأين أرى الأمور تتطور.

تقليديًا ، تم استخدام أشياء مثل Terraform و CloudFormation لتوفير البنية التحتية ، في حين يتم استخدام أشياء مثل Ansible لتكوينها.

يمكنك أن تفكر في Terraform كأداة لإنشاء أساس ، Ansible لوضع المنزل في المقدمة ثم يتم نشر التطبيق كما تشاء (يمكن أن يكون Ansible أيضًا ، على سبيل المثال.)

كيف تفكر في هذه الأدوات

بمعنى آخر ، يمكنك إنشاء VMs باستخدام Terraform ثم استخدام Ansible لتكوين الخوادم ، وكذلك نشر تطبيقاتك المحتملة.

تقليديا (!) هذه هي الطريقة التي لعبت بها هذه الأشياء معا.

ومع ذلك ، يمكن لـ Ansible أن تفعل الكثير (إن لم يكن جميعها) التي يمكن أن يقوم بها Terraform. العكس هو أيضا صحيح في الغالب.

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

في الواقع ، تعد خبرة Terraform + AWS واحدة من أكثر مجموعات المهارات اكتسابًا في الوقت الحالي!

ومع ذلك ، إذا كنت ستؤجل Ansible لصالح Terraform ، فلا تزال بحاجة إلى معرفة كيفية تكوين أعداد كبيرة من الخوادم برمجيًا ، أليس كذلك؟

ليس بالضرورة!

عمليات النشر غير القابلة للتغيير

في الواقع ، أتوقع أن تقل أهمية أدوات إدارة التكوين مثل Ansible ، بينما ستزداد أهمية أدوات توفير البنية التحتية مثل Terraform أو CloudFormation.

لماذا ا؟

بسبب شيء يسمى "عمليات النشر غير القابلة للتغيير".

ببساطة ، تشير عمليات النشر غير القابلة للتغيير إلى ممارسة عدم تغيير البنية الأساسية المنشورة. بمعنى آخر ، وحدة النشر الخاصة بك عبارة عن حاوية VM أو Docker ، وليست جزءًا من التعليمات البرمجية.

لذلك ، لا تنشر الكود على مجموعة من الأجهزة الظاهرية الثابتة ، بل تنشر أجهزة VM كاملة ، مع وجود الكود بالفعل.

لا يمكنك تغيير كيفية تكوين أجهزة VM ، بل تقوم بنشر VMs جديدة مع التكوين المطلوب في المكان.

أنت لا تصحح آلات الإنتاج ، أنت تنشر آلات جديدة ، مصححة بالفعل.

لا تقوم بتشغيل مجموعة واحدة من VMs في dev ومجموعة مختلفة من VMs في prod ، فهي جميعها متماثلة.

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

تحصل على وجهة نظري.

عندما تستخدم بشكل صحيح ، وهذا هو نمط قوي جدا وأوصي بشدة!

ملاحظة: تنص عمليات النشر غير القابلة للتغيير على أن يكون التكوين منفصلًا عن الكود. يرجى قراءة البيان 12 عامل التطبيق الذي تفاصيل هذا (وغيرها من الأفكار رهيبة!) بتفصيل كبير. هذا أمر لا بد منه للقراءة لممارسي DevOps.

يعد فصل الشفرة من config أمرًا بالغ الأهمية - لا ترغب في إعادة نشر مكدس التطبيق بالكامل في كل مرة تقوم فيها بتدوير كلمات مرور قاعدة البيانات الخاصة بك. بدلاً من ذلك ، تأكد من أن التطبيقات تسحبه من متجر تهيئة خارجي (SSM / Consul / إلخ.)

علاوة على ذلك ، يمكنك بسهولة رؤية كيف أن ظهور عمليات النشر غير الثابتة ، فإن أدوات مثل Ansible تبدأ في لعب دور بارز أقل.

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

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

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

حاويات جانبا ، لأولئك الناس الذين بدأوا للتو ، وتوفير البنية التحتية AWS باستخدام Terraform هو نمط الكتب المدرسية DevOps وشيء تحتاج حقا لإتقان.

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

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

مرة أخرى ، يمكنك تعطيل الوصول عن بُعد تمامًا وتشعر بالرضا حيال كونك أكثر أمانًا من معظم الأشخاص الموجودين هناك!

كيف يضمن لك الشعور مع عمليات النشر الثابتة

لتلخيص ، تبدأ رحلة "DevOps" المؤتمتة بالكامل مع توفير موارد الحوسبة اللازمة لتشغيل الكود - مرحلة التهيئة. وأفضل طريقة لتحقيق ذلك هي من خلال عمليات النشر غير القابلة للتغيير.

أخيرًا ، إذا كنت مهتمًا بمكان البدء بالضبط ، فإن Terraform + AWS combo هو مكان قوي لبدء رحلتك!

هذا كل شيء بالنسبة إلى مرحلة "التهيئة".

الجزء 3 ، "الإصدار" هنا!