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

كيف تبدو عمليات نشر الكود النموذجية

خلاصة سريعة

دعونا نلقي نظرة سريعة على مكاننا في رحلة DevOps لدينا.

في الجزء 1 ، تحدثنا عن ثقافة DevOps والأسس المطلوبة:

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

في الجزء 3 ، تحدثنا عن كيفية الحفاظ على تنظيم التعليمات البرمجية المنشورة:

في الجزء 4 ، تحدثنا عن كيفية حزم التعليمات البرمجية المنظمة لسهولة النشر:

كمرجع ، هذا هو المكان الذي نحن فيه على خريطتنا:

الخريطة الذهنية لرحلتنا

لذلك ، إذا كنت تقضي حوالي شهر في كل قسم ، فنحن في الشهر الرابع في هذه المرحلة.

لذلك ، نحن نعرف كيفية توفير البنية التحتية التي ستعمل على تشغيل برنامجنا ، ونعرف كيفية إصدارها بشكل مناسب ، ونعرف كيفية حزمها للنشر.

أخيرًا ، سنناقش كيفية نشر الشفرة الخاصة بك بالفعل!

نشر الرمز

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

لسوء الحظ ، لا يزال نشر الكود الصحيح من بيئة مطورة إلى حث عملية مؤلمة ، محفوفة بالأخطاء والفشل.

لماذا هذا؟

الأسباب عديدة ، بالطبع ، لكن في رأيي ، يرجع الأمر في الغالب إلى الاختلافات.

على وجه التحديد ، الاختلافات بين البيئات التي يتم فيها إنشاء الكود ومكان تشغيله بالفعل.

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

لذا ، كيف يمكننا تقليل و / أو القضاء على الاختلافات بين بيئاتنا غير الضارة وغير الضارة؟

انها عملت على الجهاز الخاص بي!

إذا كان لديك البنية التحتية ديف يشبه هذا

تجميعها باليد مع العطاء الحب والرعاية

ولكن البنية التحتية الخاصة بك همز يشبه هذا

همز

ثم لديك مشكلة.

إذا كنت تستخدم البنية التحتية كرمز بدلاً من تكوين الأشياء باليد ، فأنت بذلك تمثل 90٪ من الطريق.

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

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

لذا ، فإن أول ما عليك القيام به هو التأكد من أن كل شيء يلمس prod هو قطعة أثرية تم نشرها بواسطة خادم النشر.

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

الأساليب الحديثة لنشر الكود

هذا صحيح - إن نشر الكود على أجهزة prod هو حقبة التسعينيات.

أحدث جهاز نشر الشفرة

أكبر مشكلة في نشر الكود على مجموعة من آلات الإنتاج الثابتة هي أن خوادم prod (حيث يتم تشغيل الكود) تختلف بحكم التعريف عن خوادم dev (حيث تتم كتابة الكود).

لذلك ، فلا عجب أن تنشأ الكثير من المشكلات فور نشرها لم يسبق له مثيل من قبل - كل شيء مختلف!

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

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

يُعرف هذا باسم "النشر غير الثابت" وهو نمط قوي جدًا يوفر لك ساعات من الصداع بعد النشر.

بالطبع ، إذا قمت بتشغيل حاويات ، تنطبق نفس الفكرة: تقوم بنشر الحاوية نفسها في كل مكان.

"لكن انتظر! بلدي همز يختلف عن ديف! "يمكنك القول. أسماء المستخدمين / كلمات المرور لقاعدة البيانات ، سلاسل الاتصال ، مواقع مجموعة S3 ، إلخ. كلها مختلفة!

نعم ، هم مختلفون.

طريقة حل هذه المشكلة هي مع مبدأ تكوين التطبيق 12 عامل. يجب أن يكون كل التكوين الخاص بك خارجيًا وأن يتم تمريره كمتغيرات بيئة لجهازك.

على سبيل المثال ، إذا كنت في AWS ، فاستخدم SSM كمخزن للمعلمات الخارجية - فهو يتكامل بشكل جيد مع CloudFormation. ومن السهل أيضًا ضبط متغيرات البيئة مباشرةً من أوامر aws ssm cli. بالطبع ، لدى مقدمي السحابة الآخرين آليات مماثلة.

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

في الواقع ، يجب أن لا يكون هدفك هو الوصول إلى أجهزة prod على الإطلاق. لا ssh ، لا scp ، لا همز الوصول إلى أي شخص. ليس أنت ، وليس الطامحين المتسللين.

ولكن ماذا لو كنت بحاجة إلى سجلات لاستكشاف المشكلة؟

لقد فكرت في الأمر - يجب أن تكون سجلاتك خارجية أيضًا ، ويتم شحنها بشكل مثالي في أي مكان آخر إما باستخدام مكدس ElasticSearch / Logstash / Kibana (ELK) أو برنامج تجاري مثل SumoLogic أو Datadog.

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

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

ميكانيكا نشر الكود

حسناً ، أنت تعرف ماذا تفعل ولكن كيف تفعل ذلك؟

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

الآن ، أقول "لسوء الحظ" لأن جنكينز (وسلفها ، هدسون) موجودان منذ ما يقرب من عقد من الزمان. و تظهر.

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

في الواقع ، إن إعدادات جينكينز متعددة الصمود والمرنة حقًا نادرة ولا تتم رؤيتها عادةً إلا من قِبل أكبر المؤسسات.

فلماذا أوصي بأن تبدأ مع جينكينز؟

لأنه على الرغم من كل عيوبه ، فإنه لا يزال يتمتع بشعبية كبيرة ويستخدم بكثرة في صناعتنا.

إن معرفة جنكينز ، وتحديداً كيفية هيكلة جنكينفيل هي فائدة كبيرة لفرص العمل لديك ولا يمكن التغاضي عنها.

ومع ذلك ، عندما تتعلم Jenkins ، تأكد من اتباع مسار Pipeline BlueOcean الأحدث ، وليس مسار Jenkins Jobs الأقدم.

هذا أمر بالغ الأهمية لأنك تريد أن يعيش خط أنابيب CI / CD داخل كود GitHub / GitLab مباشرة. بهذه الطريقة ، يعد خط الأنابيب نفسه جزءًا من الكود!

في الواقع ، هذا أمر مهم لدرجة أنه يحمل التكرار مرة أخرى.

كل شيء رمز.

تطبيقك ، وكيفية نشره ، وكيفية مراقبته ، وكيفية تكوينه ، وما إلى ذلك - جميع أجزاء التعليمات البرمجية ، المخزنة في GitHub / GitLab / Whatever ، التي تم إصدارها بشكل صحيح.

الهدف هنا هو إنشاء بيئة خالية من الاحتكاك حقًا للمطورين الأساسيين (مهندسي البرمجيات الذين يكتبون رمز الميزات.)

على سبيل المثال ، يجب أن أكون قادرًا على كتابة الخدمة الصغيرة الخاصة بي ، وإضافة أي اختبارات أراها ضرورية ، وإضافة ملف Jenkinsfile ، وإضافة تكوين رمز المراقبة ، وتحديد المعلمات الخاصة بي في بعض ملفات "env.yaml" ، وتخزينها جميعًا في repo واحد ، اطلب من جينكينز اكتشاف الريبو المذكور ، وقم ببنائه واختباره ونشره (كناري أو أزرق / أخضر) وأرسل لي رسالة عبر البريد الإلكتروني عند الانتهاء من ذلك!

يا للعجب.

هذا هو الهدف! في الواقع ، هذا هو جوهر المهمة الأساسية لمهندسي DevOps.

بدائل جنكينز

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

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

آخر هو GitLab CI. إذا كانت مؤسستك تدير GitLab ، فمن المحتمل أن تبدأ من هناك لأنها مدمجة بدقة مع بقية GitLab.

وأخيرا ، أعلن جيثب الإجراءات ، التي من المفترض أن تكون الأتمتة الخاصة بهم.

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

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

في الواقع ، يمكنك أن تبدأ بسيطة ، دون أي تزامن حاوية ، وهو موضوع المنشور التالي. ترقب!