📧 🐵 👩🏿‍🍳 كيف تصبح مهندس DevOps في ستة أشهر أو حتى أسرع. الجزء 5. النشر 🐩 🙎 ❔

كيف تصبح مهندس DevOps في ستة أشهر أو حتى أسرع. الجزء 1. مقدمة
كيف تصبح مهندس DevOps في ستة أشهر أو حتى أسرع. الجزء 2. التكوين
كيف تصبح مهندس DevOps في ستة أشهر أو حتى أسرع. الجزء 3. الإصدارات
كيف تصبح مهندس DevOps في ستة أشهر أو حتى أسرع. الجزء 4. تغليف البرمجيات

قم بتحديث الذاكرة

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

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

نشر الرمز

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

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

ويعمل على سيارتي!

إذا كانت البنية الأساسية للمطور لديك تبدو كما يلي: وتبدو البنية الأساسية

للمنتج كما يلي:

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

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

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

نهج النشر الحديث

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

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

يُسمى هذا "النشر غير القابل للتغيير" وهو قالب قوي جدًا سيوفر لك العديد من ساعات الصداع بعد النشر. بالطبع ، إذا قمت بتشغيل حاويات ، تنطبق نفس الفكرة: يمكنك نشر نفس الحاوية في كل مكان. يمكنك أن تقول: "توقف! هذا المنتج مختلف عن dev! "وهذا صحيح ، لأن قاعدة بيانات أسماء المستخدمين / كلمات المرور ، وسلاسل الاتصال ، ومواقع مكبات S3 كلها أشياء مختلفة! نعم ، إنهم أشياء مختلفة للغاية.

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

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

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

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

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

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

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

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

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

لماذا أنصحك بالبدء مع Jenkins؟ لأنه على الرغم من جميع عيوبه ، فإنه لا يزال يتمتع بشعبية كبيرة ويستخدم على نطاق واسع في مجال تكنولوجيا المعلومات. إن معرفة Jenkins ، ولا سيما كيفية بناء ملف Jenkinsfile ، يعد ميزة كبيرة بالنسبة لآفاق العمل ولا يمكن تجاهلها. عند استكشاف Jenkins ، تأكد من أنك تستخدم البرنامج الإضافي Pipeline BlueOcean الجديد ، وليس على خط أنابيب Jenkins القديم. هذا أمر بالغ الأهمية إذا كنت تريد أن يعيش خط أنابيب CI / CD مباشرة داخل رمز الريبو الخاص بـ GitHub / GitLab. وبالتالي ، فإن خط الأنابيب نفسه عبارة عن قطعة من التعليمات البرمجية!

في الواقع ، من المهم جدًا أن يستحق التكرار مرة أخرى: كل شيء هو رمز! التطبيق الخاص بك ، وكيف يتم نشره ، وكيف يتم تعقبه ، وكيف يتم تكوينه ، وما إلى ذلك كلها مقتطفات التعليمات البرمجية ذات الإصدارات المناسبة المخزنة في GitHub / GitLab / Anywhere. الهدف من ذلك هو خلق بيئة خالية من التناقضات للمطورين الرئيسيين (مهندسي البرمجيات الذين يكتبون التعليمات البرمجية الوظيفية).

على سبيل المثال ، ينبغي أن أكون قادرًا على:

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

هذا هو الهدف ، الذي يمثل تحقيقه جوهر المهمة الأساسية لمهندسي DevOps.

بدائل لجينكينز

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

البديل الثاني هو وحدة التكامل المستمر GitLab CI. إذا كانت مؤسستك تقوم بتشغيل GitLab ، فمن المحتمل أن تبدأ في العمل معها ، حيث أنها متكاملة تمامًا مع بقية GitLab.

وأخيرًا ، أعلن GitHub عن أداته الخاصة لنشر تطبيقات الإجراءات ، والتي تدعمها الأتمتة الخاصة بهم.

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

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

يتبع قريبا جدا ...

القليل من الدعاية :)

أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟

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