فئة رئيسية موجزة حول تطوير رمز البنية التحتية
في شهر أكتوبر من هذا العام ، قدمت عرضًا تقديميًا في مؤتمر HashiConf 2018 ، حيث تحدثت عن 5 دروس رئيسية تعلمها زملائي من Gruntwork وتعلمت في عملية إنشاء وصيانة مكتبة تضم أكثر من 300000 سطر من رمز البنية التحتية التي تستخدمها مئات الشركات في أنظمة الإنتاج. في هذا المنشور ، سأشارك مقاطع فيديو وشرائح من العرض التقديمي ، بالإضافة إلى نسخة نصية مختصرة من وصف الدروس الخمسة الرئيسية.
أشرطة الفيديو والشرائح
مقدمة: DevOps الآن في العصر الحجري
على الرغم من أن الصناعة مليئة بالكلمات التقدمية العصرية: Kubernetes ، والخدمات المصغرة ، وشبكات الخدمة ، والبنية التحتية غير المستقرة ، والبيانات الضخمة ، وبحيرات البيانات ، وما إلى ذلك ، فإن الحقيقة هي أنه عندما تكون منغمسًا في إنشاء البنية التحتية ، فلا تشعر بذلك من المألوف جدا والتقدمية.
شخصيا ، يذكرني DevOps أكثر بهذا:
إنشاء بنية تحتية على مستوى الإنتاج أمر صعب. هذا هو الضغط الحقيقي. ويأكل الكثير من الوقت. الكثير من الوقت.
يوضح مقدار الوقت المستغرق لتنفيذ مشروع البنية التحتية التالي. لقد اعتمدنا على البيانات التجريبية التي جمعناها أثناء العمل مع مئات الشركات المختلفة:
الدرس 1. قائمة مراجعة للبنية التحتية للتصنيع
تستغرق مشاريع DevOps دائمًا وقتًا أطول مما تتوقع. دائما لماذا هذا
السبب الأول هو قصة شعر الياك . فيما يلي توضيح واضح لهذه الظاهرة ، (هذا مقتطف من سلسلة "مالكولم في دائرة الضوء")
السبب الثاني هو أن عملية إنشاء بنية تحتية على مستوى الإنتاج (على سبيل المثال ، البنية التحتية التي ستضعها شركتك) تتكون من آلاف الأجزاء الصغيرة. الغالبية العظمى من المطورين ليسوا على دراية بهذه التفاصيل ، لذلك ، عند تقييم مشروع ما ، عادة ما تنسى العديد من المهام الحرجة (والمستهلكة للوقت).
لتجنب ذلك ، في كل مرة تبدأ العمل في قسم جديد من البنية التحتية ، استخدم قائمة الاختيار التالية:
لن تكون جميع عناصر القائمة ضرورية لكل قطعة من البنية الأساسية ، ولكن يجب أن توثق بوعي وصراحة العناصر التي طبقتها ، والتي قررت تخطيها ولماذا.
الدرس 2. مربع الأدوات
ندرج الأدوات الرئيسية التي نستخدمها في Gruntwork لإنشاء وإدارة البنية التحتية (اعتبارًا من 2018):
- terraform . نستخدم Terraform لنشر البنية التحتية الأساسية بأكملها ، بما في ذلك الشبكة وأنظمة موازنة التحميل وقواعد البيانات وأدوات إدارة المستخدم والتصريح وجميع خوادمنا.
- باكر . نحن نستخدم Packer لتكوين وإنشاء صور للأجهزة الافتراضية التي نعمل على خوادمنا.
- عامل الميناء . بعض خوادمنا تشكل مجموعات حيث نقوم بتشغيل التطبيقات كحاويات Docker. بالنسبة إلى مجموعات Docker ، نستخدم الأدوات التالية بشكل رئيسي: Kubernetes و ECS و Fargate .
كل هذه الأدوات مفيدة ، لكن هذا ليس هو الهدف. عليك أن تفهم أن بعض الأدوات ليست كافية. من الضروري أيضًا تغيير سلوك الفريق.
على وجه الخصوص ، حتى أفضل الأدوات في العالم لن تساعد فريقك إذا كانوا لا يرغبون في استخدامها أو ليس لديهم الوقت الكافي لمعرفة كيفية استخدامها. وبالتالي ، فإن الاستنتاج الرئيسي هو أن استخدام "البنية التحتية كرمز" هو استثمار ، وهذا يعني أن بعض التكاليف الأولية ستكون مطلوبة منك. إذا استثمرت بحكمة ، فستحصل على أرباح كبيرة على المدى الطويل.
الدرس 3. الوحدات الكبيرة شريرة
غالبًا ما يحدد الوافدون الجدد إلى تطبيق "البنية التحتية كرمز" بنيتهم الأساسية بالكامل لجميع بيئاتهم (بيئة التطوير ، البيئة الوسيطة ، بيئة الإنتاج ، إلخ) في ملف واحد أو مجموعة من الملفات التي يتم نشرها ككل. عبثا.
فيما يلي بعض عيوب هذا النهج:
- سرعة منخفضة إذا تم تعريف البنية التحتية بأكملها في مكان واحد ، فإن تنفيذ أي أمر سيستغرق الكثير من الوقت. واجهنا مواقف في الشركات عندما استغرق فريق
terraform plan 5-6 دقائق لإكماله! - انخفاض الأمن . إذا كنت تدير البنية الأساسية بأكملها معًا ، فعندئذٍ لتغيير شيء ما تحتاج إلى أذونات للوصول إلى كل شيء. أي ، يجب أن يكون كل مستخدم مسؤولًا ، وهذا غير مريح أيضًا.
- مخاطر عالية . إذا وضعت كل بيضك في سلة واحدة ، فقم بإنشاء موقف يمكن أن يؤدي فيه خطأ محلي واحد إلى تعطيل تشغيل البنية الأساسية بأكملها. على سبيل المثال ، عند إجراء تغييرات بسيطة على تطبيق خارجي في بيئة التطوير ، يمكن أن يؤدي خطأ مطبعي واحد أو أمر غير صحيح إلى حذف قاعدة بيانات الإنتاج.
- من الصعب أن نفهم . كلما تم وضع الكود في مكان واحد ، زاد صعوبة فهم شخص واحد لكل هذا. وعندما يتم توصيل كل هذا ، ستلعب الأجزاء غير المفهومة مزحة قاسية معك.
- من الصعب اختبار . اختبار رمز البنية التحتية صعب ؛ اختبار كميات كبيرة من رمز البنية التحتية يكاد يكون من المستحيل. سوف نعود إلى هذا لاحقًا.
- من الصعب التحليل . يصبح إخراج الأوامر مثل خطة terraform عديم الفائدة ، حيث لا أحد يكترث لعرض آلاف الخطوط. علاوة على ذلك ، يصبح تحليل الشفرة عديم الفائدة.
باختصار ، يجب عليك إنشاء التعليمات البرمجية الخاصة بك من وحدات مركبة صغيرة قائمة بذاتها وقابلة لإعادة الاستخدام. هذا ليس خبر ولا اكتشاف. لقد سمعت هذا الف مرة ، على الرغم من أنه في مواقف مختلفة قليلاً:
"افعل شيئًا واحدًا وافعله جيدًا" - فلسفة يونكس.
القاعدة الأولى للوظائف هي أنها يجب أن تكون صغيرة. تنص القاعدة الثانية على أن الوظائف يجب أن تكون أصغر. " - "كود نظيف"
الدرس 4. رمز البنية التحتية بدون اختبارات تلقائية خاطئ
إذا لم يكن رمز البنية الأساسية لديك اختبارات تلقائية ، فلن يعمل بشكل صحيح. أنت فقط لا تعرف ذلك بعد. لكن اختبار رمز البنية التحتية أمر صعب. ليس لديك "مضيف محلي" (على سبيل المثال ، لا يمكنك نشر سحابة خاصة افتراضية AWS VPC على الكمبيوتر المحمول الخاص بك) ، ولا "اختبارات وحدة" حقيقية (على سبيل المثال ، لا يمكنك عزل رمز Terraform عن العالم "الخارجي" ، لأنه يشبه مرات ومصممة للتواصل مع العالم الخارجي).
لذلك ، من أجل اختبار رمز البنية التحتية بشكل صحيح ، يتعين عليك عادةً نشره في بيئة حقيقية ، وإدارة بنية أساسية حقيقية ، والتحقق من أن الشفرة تعمل ، ثم كسرها (للحصول على وصف لنمط الاختبار: انظر Terratest ، هذه مكتبة مفتوحة المصدر تتضمن أدوات لاختبار Terraform code ، Packer and Docker ، العمل مع واجهات برمجة التطبيقات AWS ، GCP و Kubernetes ، تنفيذ أوامر shell محليًا وخوادم بعيدة عن طريق SSH ، بالإضافة إلى العديد من الميزات الأخرى). وبالتالي ، عند اختبار البنية التحتية ، تحتاج إلى إعادة تعريف الشروط قليلاً:
تقوم اختبارات الوحدة بنشر واختبار واحد أو أكثر من وحدات البنية التحتية ذات الصلة من نفس النوع (على سبيل المثال ، الوحدات النمطية لقاعدة بيانات واحدة).
تقوم اختبارات التكامل بنشر واختبار العديد من وحدات البنية التحتية بأنواعها المختلفة للتحقق من أنها تعمل معًا (على سبيل المثال ، وحدات قاعدة البيانات ووحدات خدمة الويب).
تقوم الاختبارات الشاملة (e2e) بنشر واختبار البنية بأكملها.
يرجى ملاحظة أن الرسم البياني هو هرم: لدينا العديد من اختبارات الوحدة ، واختبارات التكامل أقل وعدد قليل جدا من اختبارات e2e. لماذا؟ يعتمد على مدة كل نوع من الاختبارات:
تستغرق اختبارات البنية التحتية الكثير من الوقت ، خاصةً في المستويات العليا من الهرم ، وبالطبع ، سوف ترغب في العثور على أكبر عدد ممكن من الأخطاء وإصلاحها قدر الإمكان. للقيام بذلك ، تحتاج إلى:
- قم بإنشاء وحدات مستقلة صغيرة وبسيطة (انظر الدرس 3) واكتب الكثير من اختبارات الوحدة لهم - تأكد من أنها تعمل بشكل صحيح.
- اجمع بين هذه الكتل الصغيرة والبسيطة والمثبتة لإنشاء بنية أساسية أكثر تطوراً تختبرها بتكامل أقل واختبارات E2E.
الدرس 5. عملية الإصدار
لتلخيص كل ما سبق. إليك كيفية إنشاء وإدارة البنية الأساسية الخاصة بك الآن:
- تحقق من قائمة التحقق الخاصة بالبنية التحتية الخاصة بمستوى الإنتاج وتأكد من أنك تعمل في الاتجاه الصحيح.
- حدد "البنية التحتية الخاصة بك كرمز" باستخدام أدوات مثل Terraform و Packer و Docker. تأكد من أن فريقك لديه ما يكفي من الوقت لتعلم هذه الأدوات (انظر موارد DevOps ).
- قم بإنشاء رمز من الوحدات المركبة الصغيرة المستقلة (أو استخدم الوحدات النمطية القياسية من البنية التحتية كمكتبة رمز ).
- إعداد الاختبارات الآلية للوحدات النمطية الخاصة بك مع Terratest .
- أكمل طلب تضمين التغييرات لمراجعة الكود.
- حرر الإصدار الجديد من الكود.
- نسخ الإصدار الجديد من التعليمات البرمجية من بيئة إلى أخرى.
