🥇 اختبار تلقائي للخدمات المصغرة في Docker من أجل التكامل المستمر

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

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

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

تقدم أتمتة هذا النهج عددًا من المشكلات ، سيتم وصف حلها أدناه:

تضارب المهام المتوازية في مضيف عامل واحد ؛
تضارب المعرفات في قاعدة البيانات أثناء تكرار الاختبار ؛
في انتظار أن تكون الخدمات المصغرة جاهزة ؛
توحيد وإخراج السجلات للأنظمة الخارجية ؛
اختبار طلبات HTTP الصادرة ؛
اختبار مقبس الويب (باستخدام SignalR) ؛
اختبار مصادقة OAuth والتفويض.

هذه المقالة على أساس خطابي في SECR 2019. لذا بالنسبة لأولئك الذين يعانون من كسالى للغاية في القراءة ، هنا تسجيل الخطاب.

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

يتم تشغيل نفس البرنامج النصي من قبل المطورين أنفسهم على أجهزة كمبيوتر سطح المكتب التي تعمل بنظام Windows وخادم Gitlab CI في نظام Linux.

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

يجب تشغيل الاختبار على خادم محلي للأسباب التالية:

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

بالإضافة إلى ذلك ، من غير المرغوب فيه استخدام الحامل للأسباب التالية:

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

حول المشروع وتنظيم العملية

كانت شركتنا تطور تطبيق ويب للخدمات المصغرة يعمل على Docker في سحابة Amazon AWS. استخدم المشروع بالفعل اختبارات الوحدة ، ولكن غالبًا ما كانت هناك أخطاء لم تكتشفها اختبارات الوحدة. كان مطلوبًا اختبار الخدمة المصغرة بأكملها جنبًا إلى جنب مع قاعدة البيانات وخدمات Amazon.

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

هندسة المشروع

التطبيق يتكون من أكثر من عشر خدمات. بعضها مكتوب بلغة .NET Core والبعض الآخر بلغة NodeJs. يتم تشغيل كل خدمة في حاوية Docker في Amazon Elastic Container Service. كل شخص لديه قاعدة بيانات Postgres الخاصة به ، وبعضها لديه Redis أيضًا. لا توجد قواعد مشتركة. إذا احتاجت العديد من الخدمات إلى نفس البيانات ، فسيتم إرسال هذه البيانات إلى كل خدمة من هذه الخدمات عبر SNS (خدمة الإعلام البسيط) و SQS (خدمة Amazon Simple Queue Service) في وقت تغييرها ، وتقوم الخدمات بحفظها في قواعد بياناتها المنفصلة.

SQS و SNS

يتيح لك SQS وضع الرسائل في قائمة انتظار عبر HTTPS وقراءة الرسائل من قائمة الانتظار.

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

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

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

بوابة API

لا يمكن الوصول إلى معظم الخدمات مباشرة من الإنترنت. يتم الوصول من خلال بوابة API ، التي تتحقق من حقوق الوصول. هذه أيضًا خدمتنا ، وهناك اختبارات لها أيضًا.

إخطارات في الوقت الحقيقي

يستخدم التطبيق سيجنال آرلإظهار إشعارات الوقت الفعلي للمستخدم. يتم تنفيذ ذلك في خدمة الإعلام. يمكن الوصول إليه مباشرة من الإنترنت ويعمل مع OAuth نفسه ، لأن دمج دعم مقبس الويب في البوابة تبين أنه غير عملي مقارنة بدمج OAuth وخدمة الإعلام.

نهج معروف للاختبار

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

В مقال من Microsoft يُقترح استخدام قاعدة في الذاكرة وتنفيذ كائنات وهمية.

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

تقوم الكائنات الوهمية بنمذجة الفئة التي يتم استبدالها فقط بقدر ما يفهم مطور الاختبار كيفية عملها.

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

دعنا ننتقل إلى الحل

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

تهيئة بيئة الاختبار

المهمة الأولى هي نشر بيئة الاختبار. الخطوات المطلوبة لبدء الخدمة المصغرة:

إعداد الخدمة قيد الاختبار لبيئة محلية ، تحدد متغيرات البيئة تفاصيل الاتصال بقاعدة البيانات و AWS ؛
ابدأ Postgres وقم بالترحيل عن طريق بدء Liquibase.
في DBMS العلائقية ، قبل كتابة البيانات إلى قاعدة البيانات ، تحتاج إلى إنشاء مخطط بيانات ، بمعنى آخر ، جداول. عند تحديث أحد التطبيقات ، يجب تحويل الجداول إلى النموذج المستخدم بواسطة الإصدار الجديد ، ويفضل ، دون فقدان البيانات. وهذا ما يسمى بالهجرة. يعد إنشاء الجداول في قاعدة بيانات فارغة في البداية حالة خاصة من الترحيل. يمكن دمج الترحيل في التطبيق نفسه. يحتوي كل من .NET و NodeJS على أطر عمل ترحيل. في حالتنا ، لأسباب أمنية ، تُحرم الخدمات المصغرة من الحق في تغيير مخطط البيانات ، ويتم الترحيل باستخدام Liquibase.
قم بتشغيل Amazon LocalStack. هذا هو تنفيذ لخدمات AWS للتشغيل في المنزل. توجد صورة جاهزة لـ LocalStack في Docker Hub.
قم بتشغيل برنامج نصي لإنشاء الكيانات الضرورية في LocalStack. تستخدم برامج Shell النصية AWS CLI.

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

كيف يعمل الاختبار الآلي

أثناء الاختبار ، يعمل كل شيء في Docker: الخدمة التي يتم اختبارها ، و Postgres ، وأداة الترحيل ، و Postman ، أو بالأحرى إصدار وحدة التحكم - Newman.

يحل Docker عددًا من المشكلات:

الاستقلال عن تكوين المضيف ؛
تثبيت التبعيات: يقوم عامل التحميل بتنزيل الصور من Docker Hub ؛
إعادة النظام إلى حالته الأصلية: فقط قم بإزالة الحاويات.

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

يتم التحكم في الاختبار بواسطة برنامج نصي للقذيفة. نستخدم git-bash لإجراء الاختبار على Windows. وبالتالي ، يكفي برنامج نصي واحد لكل من Windows و Linux. تم تثبيت Git و Docker من قبل جميع المطورين في المشروع. يؤدي تثبيت Git على نظام التشغيل Windows إلى تثبيت git-bash ، لذلك يتمتع الجميع بذلك أيضًا.

يقوم البرنامج النصي بتنفيذ الخطوات التالية:

بناء صور عامل ميناء
```
docker-compose build
```

بدء DB و LocalStack

docker-compose up -d <контейнер>

ترحيل قاعدة البيانات وإعداد LocalStack
```
docker-compose run <контейнер>
```
تشغيل الخدمة قيد الاختبار
```
docker-compose up -d <сервис>
```
تشغيل الاختبار (نيومان)
أوقف كل الحاويات
```
docker-compose down
```
نشر النتائج على Slack
لدينا دردشة حيث تنتقل الرسائل التي تحمل علامة اختيار خضراء أو صليب أحمر ورابط إلى السجل.

تتضمن هذه الخطوات صور Docker التالية:

الخدمة التي يتم اختبارها هي نفس صورة الإنتاج. التكوين للاختبار من خلال متغيرات البيئة.
بالنسبة إلى Postgres و Redis و LocalStack ، يتم استخدام الصور المبنية مسبقًا من Docker Hub. هناك أيضًا صور جاهزة لـ Liquibase و Newman. نحن نبني ملفاتنا على هيكلهم العظمي ، ونضيف ملفاتنا هناك.
تُستخدم صورة AWS CLI مسبقة الإنشاء لتوفير LocalStack ويتم إنشاء صورة تحتوي على البرنامج النصي منه.

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

المشاكل التي قد تواجهك

في انتظار الاستعداد

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

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

حل: نصوص توفير LocalStack تنتظر استجابة 200 من كل من SQS و SNS.

تعارضات المهام المتوازية

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

حل: يعيّن النص البرمجي قيمة فريدة للمتغير COMPOSE_PROJECT_NAME.

خصائص الويندوز

عند استخدام Docker على Windows ، هناك عدد من الأشياء التي أود لفت انتباهك إليها ، لأن هذه التجربة مهمة في فهم أسباب الأخطاء.

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

هذه هي طريقة تكوين git:

git config core.autocrlf input

يحاكي Git-bash مجلدات Linux القياسية وعند استدعاء ملف exe (بما في ذلك docker.exe) يستبدل مسارات Linux المطلقة بمسارات Windows. ومع ذلك ، فإن هذا غير منطقي بالنسبة للمسارات غير الموجودة على الجهاز المحلي (أو المسارات الموجودة في الحاوية). لم يتم تعطيل هذا السلوك.

حل: قم بإلحاق شرطة مائلة إضافية ببداية المسار: // bin بدلاً من / bin. يفهم لينكس هذه المسارات ، فبالنسبة له ، فإن العديد من الخطوط المائلة هي نفسها. لكن git-bash لا يتعرف على مثل هذه المسارات ولا يحاول تحويلها.

إخراج السجل

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

كان الحل الأصلي هو القيام بذلك عامل ميناء يؤلف لا علم -d، ولكن باستخدام قدرات الصدفة ، أرسل هذه العملية إلى الخلفية:

docker-compose up <service> &

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

حل:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

تعارض المعرف أثناء تكرار الاختبار

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

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

حل: إنشاء GUIDs مع البرامج النصية في Postman.

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

ثم في الاستعلام استخدم الحرف {{myUUID}}، والتي سيتم استبدالها بقيمة المتغير.

التفاعل من خلال LocalStack

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

حل: الطلبات من Postman إلى LocalStack.

تم توثيق AWS Services API ، مما يسمح لك بتقديم طلبات بدون SDK.

إذا كتبت الخدمة إلى قائمة الانتظار ، فسنقرأها ونتحقق من محتويات الرسالة.

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

إذا كانت الخدمة بحاجة إلى قراءة رسالة من قائمة الانتظار ، فإننا في خطوة الاختبار السابقة نكتب هذه الرسالة إلى قائمة الانتظار.

اختبار طلبات HTTP الواردة من الخدمة المصغرة قيد الاختبار

تعمل بعض الخدمات عبر HTTP بشيء آخر غير AWS ، ولا يتم تنفيذ بعض ميزات AWS في LocalStack.

حل: في هذه الحالات يمكن أن تساعد خادم موك، الذي يحتوي على صورة جاهزة بتنسيق دوكر هاب. يتم تكوين الطلبات المتوقعة واستجاباتها بواسطة طلب HTTP. تم توثيق واجهة برمجة التطبيقات (API) ، لذا فإننا نتقدم بطلبات من Postman.

اختبار مصادقة OAuth والتفويض

نحن نستخدم OAuth و رموز ويب JSON (JWT). يتطلب الاختبار موفر OAuth يمكننا تشغيله محليًا.

ينخفض كل تفاعل الخدمة مع موفر OAuth إلى طلبين: أولاً ، يتم طلب التكوين /.well-known/openid-configuration، ثم يتم طلب المفتاح العام (JWKS) على العنوان من التكوين. كل هذا محتوى ثابت.

حل: موفر OAuth التجريبي لدينا هو خادم محتوى ثابت وملفان عليه. يتم إنشاء الرمز المميز مرة واحدة ويلتزم بـ Git.

ميزات اختبار SignalR

ساعي البريد لا يعمل مع مآخذ الويب. تم إنشاء أداة خاصة لاختبار SignalR.

يمكن أن يكون عميل SignalR أكثر من مجرد متصفح. توجد مكتبة عميل لها ضمن .NET Core. يقوم عميل مكتوب في .NET Core بتأسيس اتصال والمصادقة وانتظار تسلسل معين من الرسائل. في حالة تلقي رسالة غير متوقعة أو فقد الاتصال ، يخرج العميل بالرمز 1. إذا تم استلام آخر رسالة متوقعة ، فسيتم الخروج بالرمز 0.

نيومان يعمل مع العميل في نفس الوقت. يتم إطلاق العديد من العملاء للتحقق من تسليم الرسائل إلى كل من يحتاجها.

لتشغيل عدة عملاء ، استخدم الخيار --حجم في سطر أوامر عامل الإرساء.

قبل بدء Postman ، ينتظر البرنامج النصي أن يقوم جميع العملاء بإنشاء اتصال.
لقد واجهنا بالفعل مشكلة انتظار الاتصال. لكن كانت هناك خوادم ، وها هو العميل. نحن بحاجة إلى نهج مختلف.

حل: العميل في الحاوية يستخدم الآلية فحص طبيلإبلاغ البرنامج النصي على المضيف بوضعه. يقوم العميل بإنشاء ملف في مسار محدد ، على سبيل المثال / healthcheck ، بمجرد إنشاء الاتصال. يبدو البرنامج النصي HealthCheck في ملف عامل الشحن كما يلي:

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

فريق فحص عامل ميناء يُظهر الحالة الطبيعية للحاوية ، والحالة الصحية ، وكود الخروج.

بعد اكتمال نيومان ، يتحقق البرنامج النصي من أن جميع الحاويات مع العميل قد انتهت ، علاوة على ذلك ، برمز 0.

هابينيس موجود

بعد أن تغلبنا على الصعوبات المذكورة أعلاه ، أجرينا مجموعة من اختبارات العمل المستقرة. في الاختبارات ، تعمل كل خدمة ككيان واحد ، وتتفاعل مع قاعدة البيانات ومع Amazon LocalStack.

تحمي هذه الاختبارات فريقًا من أكثر من 30 مطورًا من الأخطاء في تطبيق ما مع تفاعلات معقدة لأكثر من 10 خدمات مصغرة مع عمليات نشر متكررة.

المصدر: www.habr.com

الاختبار الآلي للخدمات المصغرة في Docker من أجل التكامل المستمر