مساء الخير
بعد تثبيت وتكوين CI / CD مباشرةً تقريبًا ، وفقًا للتعليمات الواردة في المنشور السابق ، كان لدى الفريق سؤال حول كيفية إجراء اختبار التكامل بشكل صحيح. لدينا بالفعل تجربة في تشغيل تبعيات الاختبار في حاويات الإرساء ، ولكن هذا أصبح يمثل مشكلة منذ أن بدأ التجميع نفسه الآن في الحاوية. في هذه المقالة ، أود أن أصف طريقتين ممكنتين لاختبار التكامل داخل الحاوية التي تناسب فريقي.
متطلبات اختبار التكامل
بحكم التعريف ، فإن اختبار التكامل يختبر اختبار تشغيل التطبيق بمكوناته التابعة. تتضمن الأمثلة قواعد البيانات وقوائم الانتظار والخدمات الأخرى.
كجزء من الاختبار ، أردنا:
- تشغيل الاختبارات على قدم المساواة محليا وعلى جنكينز
- تجنب التثبيت المسبق وتكوين التطبيقات التابعة
- إعلان وتشغيل التبعيات باستخدام ملفات في مستودع المشروع
- تكون قادرة على تشغيل التجميعات متعددة في نفس الوقت
- من المستحسن أن تكون قادرة على إضافة تبعيات جديدة في المستقبل
- من المستحسن أن تكون قادرة على اختبار مع إصدارات مختلفة من نفس التبعية
استنادًا إلى هذه المتطلبات ، تخلصنا فورًا من فكرة وجود منشآت مشتركة دائمة لقواعد بيانات الاختبار وقوائم الانتظار بسبب مشاكل في مشاركة الموارد بين التجميعات وصعوبة الحفاظ على هذه البنية الأساسية وتغييرها.
الخيار 1: الحلول المدمجة
هناك عدد لا بأس به من المكتبات في نظام java البيئي التي تقوم بتشغيل تبعية للاختبار:
هذا النهج بسيط بقدر الإمكان ويلبي معظم المتطلبات الموضحة سابقًا ، ولكنه ليس عالميًا من حيث إضافة تبعيات اختبار جديدة (mysql؟) أو استخدام إصدارات معينة أو العديد من التبعيات.
مناسبة تماما للخدمات البسيطة مع 1-2 التبعيات.
الخيار 2: حاويات الاختبار
Docker هي طريقة منطقية لحل أوجه القصور في النهج السابق: يمكنك العثور على (أو إنشاء صورة Docker) لأي تبعية مع أي إصدار. ربما يتم تشغيل بعض التبعيات في الإنتاج باستخدام نفس الصور.
إذا لم يكن إطلاق الصورة محليًا (أو استخدام العديد منها باستخدام عامل الإرساء) مشكلة ، فستكون هناك صعوبات في CI لأن التجميع نفسه يحدث في الحاوية. على الرغم من أنه من الممكن تشغيل عامل ميناء في عامل ميناء ، إلا أنه لا ينصح به مُنشئ dind . تتمثل الطريقة المفضلة للتغلب على هذه المشكلة في إعادة استخدام عملية عامل التشغيل قيد التشغيل بالفعل ، والتي تُسمى غالبًا عامل الميناء. للقيام بذلك ، فأنت بحاجة إلى عملية /var/run/docker.sock الطفل لاستخدام /var/run/docker.sock من الوالد. في منشور سابق ، تم استخدام هذا بالفعل لنشر صور عامل ميناء مع تطبيق مترجم.
تقرر استخدام مكتبة حاويات الاختبار لأنها:
مناسب تمامًا للخدمات الأكثر تعقيدًا أو للخدمات ذات متطلبات التبعية الخاصة.
إدارة الموارد
بعد ذلك ، يجب الانتباه إلى استهلاك الموارد من خلال تجميع المشروع (والتي يمكن أن تزيد بشكل ملحوظ بعد إضافة اختبارات التكامل).
في الوقت الحالي ، لا يشير التجميع إلى مقدار الذاكرة ومشاركة cpu المطلوبة ، والتي قد تكون مشكلتين محتملتين:
- الأول هو وجود عدد كبير جدًا من التجميعات المتوازية على نفس الجهاز ، مما ينتج عنه عامل تحميل عالي. من المحتمل أن تمر الجمعيات ، لكنها ستقضي وقتًا أطول في هذا الأمر.
- والثاني هو قتل OOM. قد يقرر Kubernetis أنك تستهلك الكثير من الذاكرة وسوف تقتل المجموعات ببساطة قبل أن تكتمل.
يمكنك الحد من موارد الحاوية في الموقد باستخدام البناء:
resources: requests: cpu: 1 memory: 512Mi limits: cpu: 1 memory: 512Mi
Jdk9 والإصدارات الأحدث لديك بالفعل دعم للعمل في حاوية (- XXX: + UseContainerSupport (ممكّن بشكل افتراضي) ، يعمل مع -XX: InitialRAMPercentage / -XX: MaxRAMPercentage)
مثال كامل يمكن العثور عليه هنا .
لكي يعمل Jdk8 بشكل صحيح ، إما أن يكون التحديث 131 أو أعلى مطلوبًا مع -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap لقراءة الذاكرة المتوفرة من cgroup وليس من الجهاز المضيف ، أو في كل مرة حدد حجم الكومة المتاح يدويًا باستخدام Xmx .
مثال متاح هنا .
تجدر الإشارة إلى أن kubernetes لا يعرف شيئًا عن الموارد التي تنفق على الحاويات التي تعمل باستخدام حاويات الاختبار أو عامل الأخوة. للعمل بشكل صحيح في هذا الموقف ، يمكنك حجز الموارد في حاوية maven ، مع مراعاة جميع تبعيات الاختبار.
استنتاج
اختبار التكامل عند بدء بناء في حاوية أمر ممكن وليس مهمة صعبة.
تطبيق مثال مع اختبارات التكامل باستخدام حاويات الاختبار يمكنك أن تجد هنا والتكوين لتشغيل Jenkins على kubernetes هنا .