Get best of the week

بوابة بيئات الاختبار ، أو حفظ Devops لدينا



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

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

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

يتم أيضًا تصحيح الاختبارات وضمان الجودة بشكل جيد في أغلب الأحيان.

وبينهم هاوية. ويحاول DevOps ملئه. يجب أن يأخذ هذا السوبرمان الإصدار (ويجمعه بشكل مثالي في Jenkins أو شيء مشابه) ، ويصنع سيارة ، وينشر كل شيء هناك ، ويفحص العمل ، وربما يقضي بعض الاختبارات المسبقة ويعطيها إلى QA.

ما المشكلة؟


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

ولكن عندما ينمو المنتج قليلاً ، ينهار انهيار الإنتاج.

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

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

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

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

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

بشكل غير متوقع ، ولكن لا يوجد منتج نهائي


يبدو أنه يجب تغطية هذا الناقل بأكمله بنوع من المنتجات. هناك العديد من الحلول الجيدة. يتم نشر Ansible نفسه بشكل مثالي ، لكنه لا يعرف كيفية توجيه الأجهزة الافتراضية. ويمكن ل hypervisors. هناك جميع أدوات البرمجة النصية ، يمكنك توصيل الوحدات ... ما عليك سوى أخذ وتجميع من سلسلة البرامج هذه ، أليس كذلك؟

ليس من هذه الطريق. جاءت البنوك والشركات المملوكة للدولة برغبة في الاختبار في السحابة. كل حارس أمن جيد عرضة للبارانويا ، غالبًا لسبب وجيه. بالنسبة إلى IB Bank ، يعد كل تثبيت جديد عاملاً مزعجًا للغاية. أعرف حالة واحدة عندما سحبت العمليات Jenkins و Terraform في البنية التحتية ، ونشرت bash خلفها ، ثم DBMS الذي يحمل كل هذا. اتضح أنه ناقل جيد شبه أوتوماتيكي ، والذي يمكن أن ينتهي حتى نشر مستقل بالكامل. فقط لأمن المعلومات كانت كارثة.

أرادوا الكل في واحد. وإدارة الجهاز الظاهري (والعديد من البائعين ، بما في ذلك Openstack). يمكن للعميل على تطبيق واحد أن يكون لديه Vmvar و Hyper-in وشيء آخر قديم ورائع لدعم FreeBSD أو OS / 2.

نحن بحاجة إلى دراجتنا


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



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

هكذا تبدو. إنشاء بيئة باستخدام قالب:



إضافة جهاز افتراضي:



برمجة:



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

بشكل عام ، إذا كان شيئًا مشابهًا يؤلمك فجأة ، فقم فقط بمشاهدته. يتوفر الوصول التجريبي في Technoserv Cloud .

More articles:


All Articles