كان لدينا خدمة على golang ، و kafka ذو موضوع منفصل ، و clickhouse ، و gitlab-ci ، و payline ، و ssh-key الفاسد وهذا كل شيء ، إلى جانب موسم العطلات ، والأمطار الرهيبة في المدينة ، وجهاز كمبيوتر محمول مكسور ، والتنبيهات في الليل ، وبيع الساخنة . ليس أن كل هذا كان ضروريًا لهذا المقال ، ولكن بمجرد إظهار الحياة اليومية المعتادة للاختبار ، ثم انتقل في نيتك إلى النهاية. الشيء الوحيد الذي أزعجني هو p0. في العالم لا يوجد شيء أكثر يأسًا ، أو كآبة ، أو كآبة ، أكثر من الفاحص الذي فاته على المنتج. لكنني علمت أنه قريباً جداً سأغوص فيه.
لماذا كل هذا؟
هناك حزمة مشتركة من الخدمات - الخدمة نفسها التي تقوم بشيء ما - وقاعدة بيانات مكتوبة فيها هذه النتائج. يحدث هذا في بعض الأحيان بشكل مباشر ، أي "قاعدة الخدمة". في حالتي ، يحدث التسجيل من خلال وسيط ، أي "قائمة انتظار الخدمة - القاعدة".
في المجموع ، هناك العديد من العناصر ، وحدود هذه العناصر - إخراج أحدها ومدخلات الآخر - هو المكان الذي تظهر فيه المشاكل. انهم ببساطة لا يمكن أن تظهر هناك.
مثال حي: في الخدمة ، تتم معالجة حقل السعر كـ float32 ، في قاعدة البيانات تم تكوينه على أنه رقم عشري (18 ، 5) ، نحن نطعم القيمة القصوى لـ float32 كحالة اختبار من إخراج الخدمة إلى قاعدة البيانات - أوه ، لا تستجيب قاعدة البيانات. أو مثال أكثر حزينًا - قاعدة البيانات لا تتعطل ، ولكن لا يوجد خطأ في سجلات البيانات في قاعدة البيانات. انها مجرد أن قاعدة البيانات لم تعد تصب. أو يمر التسجيل ، ولكن مع فقد البيانات أو تشويه: يخرج الحقل من الخدمة كـ float64 ، ويتم تسجيله كـ float32.
أو أثناء عملية دورة حياة الخدمة ، قرروا أنه من الضروري تغيير نوع هذا الحقل أو هذا الحقل. تم تنفيذ الحقل منذ فترة طويلة على المنتج ، لكن من الضروري تعديله هنا. وبالطبع قمنا بتغييره في مكان واحد فقط. هوبا ، حدث خطأ ما مرة أخرى.
مهمة
لا أريد تتبع كل هذه التغييرات. أريد أن لا تسقط. أريد أن يذهب التسجيل إلى اليمين.
خروج: اختبارات التكامل!
التنفيذ والصعوبات
أين تنكسر؟
هناك بيئة مطورة: غير مستقرة بشكل كبير وعادة ما تستخدم من قبل المطورين كصندوق رمل. هناك فوضى وخاصية الفوضى من الصعب الخلفية.
هناك بيئة اختبار أو موقف qa: يتم ضبطها بشكل أفضل ، حتى أن المطورين يراقبونها ، ولكن إلى أن تركلهم ، لن يحدث شيء. وغالبا ما يتم تحديث هذه البيئة. وحتى في كثير من الأحيان ، يتم كسر شيء هناك.
وهناك همز - قدس الأقداس: من الأفضل عدم دفع أي شيء كهذا عليه. اختبارات التكامل تشير إلى احتمال وجود خطأ يجب أن يعثروا عليه قبل وصوله إلى المنتج.
فما الذي يجب فعله بالبيئة عندما تكون غير مستقرة أو قتالية؟ هذا صحيح ، اصنع بنفسك!
ماذا تفعل مع القاعدة؟
يمكن إطلاق قاعدة البيانات بعدة طرق.
كما ناقشنا أعلاه ، لن نقوم بالاتصال بالقاعدة الحقيقية لهذه البيئة أو تلك.
أولاً ، يمكنك رفع خادم
crolick clickhouse-server بالإعدادات اللازمة ، وطرح sql اللازمة عليه والتواصل معه عبر clickhouse-client. في أول محاولة ناجحة لوضع قاعدة مماثلة ، كان سي حزينًا. تومض الاختبارات ، لم يخرج الخادم واستمر في العمل. دعنا نقول فقط ، لا يزال لغزا بالنسبة لي لماذا بدأت حتى. (هو نفسه ، ليس لدي أي شيء لتفعله حيال ذلك). أنا لا أوصي بهذا الخيار.
خيار مناسب خارج المربع هو استخدام
صورة عامل ميناء .
قم بتنزيل النسخة المطلوبة لسيارتك. يحتاج Clickhouse إلى config.xml مع بدء الإعدادات. مزيد من التفاصيل
هنابالنسبة إلى صورة النقر التي تمت إعادة استخدامها ، يلزمك إنشاء dockerfile الصحيح. نشير فيه إلى أننا نريد نسخ config.xl إلى المجلد ، ونحن نرتب التكوينات الأخرى المطلوبة. تأكد من نسخ البرامج النصية لنشر قاعدتك.
نظرًا لأننا سنصل إلى الصورة من الخارج ، نحتاج إلى فتح المنافذ التي سنتواصل من خلالها مع clicklick. انقر فوق العمل على 8123 على http و 9000 على tcp.
نحصل على dockerfile التالية:
From yandex/clickhouse-server Expose 8123 Expose 9000 Add config.xml /etc/clickhouse-server/config.xml Add my_init_script.sql /docker-entrypoint-initdb.d/
كيفية رمي صورة في ci؟
للعمل بطريقة أو بأخرى مع صورة عامل النقل في ci ، تحتاج إلى تسميتها بطريقة ما هناك.
يمكنك الالتزام وتشغيل الصورة في المستودع الخاص بك وتشغيل عامل التشغيل باستخدام المعلمات الضرورية كجزء من إجراء الاختبارات. هنا فقط تزن صورة عامل ميناء النقرة تحت 350 ميجابايت. من غير المناسب الاحتفاظ بهذه الملفات في مكانها الصحيح.
بالإضافة إلى ذلك ، إذا كانت هناك حاجة إلى نفس صورة عامل الإرساء في مشاريع مختلفة (على سبيل المثال ، تتم كتابة خدمات مختلفة إلى نفس قاعدة البيانات) ، ثم لا يجب عليك القيام بذلك. يمكنك استخدام التخزين صورة
التسجيل عامل ميناءنحن نعتقد أنه في مشروعنا موجود بالفعل ويستخدم. لذلك ، تسجيل الدخول ، وجمع صورة عامل ميناء ودفعها هناك.
docker build -t my_clickhouse_image . docker login my_registry_path.domain.com docker push my_clickhouse_image
طار وصورتنا في التسجيل. تأكد من تحديد العلامة أثناء التجميع!
القاعدة جاهزة.
قراءة المزيد عن التسجيل
هناماذا تفعل مع CI؟
كيف تطلق خدمتك وقاعدة بياناتك في خطوة واحدة؟
كل هذا يتوقف على كيفية بدء الخدمة واستخدامها. إذا كنت تعمل مع الخدمة كما هو الحال مع صورة عامل ميناء ، وبالفعل .gitlab-ci.yml يعمل فقط معهم ، فكل شيء بسيط.
هناك ضالة طائشة -
عامل ميناء في الميناء . يشار إلى أنه يعمل مع خدمة ci الرئيسية ، ويسمح لك باستخدام عامل النقل بالكامل وعدم الضغط على الإطلاق.
نقوم بضخ أحدث صورة ، ونضيف خطوة الاختبار المطلوبة إلى المراحل ، ونصف تسلسل الإجراءات لدينا.
image: docker:stable services: - docker:dind stages: - build … - test-click ... - test - release … test-click: variables: VERY_IMPORTANT_VARIABLE: “its value” before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - docker pull My_Service_Image - docker pull My_ClickHouse_Image - docker run -FLAGS My_ClickHouse_Image - docker run My_Service_Image /path/to/tests
يوضح عامل الميناء الرسمي أنه لا ينصح باستخدام
dind ، ولكن إذا كنت بحاجة حقًا إلى ...
في مشروعي ، يجب اختبار الخدمة من خلال إطلاق الثنائي. هذا هو المكان الذي يبدأ السحر.
للقيام بذلك ، استخدم قاعدة البيانات كخدمة. تشير وثائق gitlab-ci الرسمية إلى استخدام الحاوية ذات القاعدة
كمثال لحالة الاستخدام الأكثر شيوعًا لحاوية الإرساء في ci. يتم توفير
أمثلة على إعدادات mysql و postress و redis. لكننا لا نبحث عن طرق سهلة ، نحن بحاجة إلى النقر.
ربط القاعدة! تأكد من تحديد الاسم المستعار. إذا لم يتم تحديد ذلك ، فسيتم تخصيص اسم عشوائي وعنوان IP عشوائي للقاعدة. وهذا يعني أنه لن يكون من الواضح بالضبط كيفية الوصول إليه. لن تكون هناك مشكلة من هذا القبيل مع الاسم المستعار - في رمز الاختبار ، ستبدو المكالمة ، على سبيل المثال ، بواسطة
http://my_alias_name:8123 .
للاختبارات ، لا تزال هناك حاجة إلى صورة من قاعدة البيانات ، والتي وضعناها بعناية في السجل. لتنزيل الصورة ، تحتاج إلى القيام بتسجيل الدخول إلى عامل ميناء وسحب عامل ميناء ، فقط ci لا يعرف ما هو عامل ميناء - تحتاج إلى تثبيته.
الكود الناتج للخطوة في gitlab-ci.yml:
Integration tests: Services: - name: my_clickhouse:latest alias: clicktest Stage: tests Variables: Variables_for_my_service: “value” Before_script: - curl -ssl https://get.docker.com/ | sh - docker login -u gitlab-ci-token -p $ci_build_token my_registry_path.domain.com Script: - ./bin/my_service & - go test -v ./tests -tags=integration Dependencies: - build
ربح
- لدي مجموعة من قاعدة العمل.
- كجزء من الاختبار التلقائي ، من السهل الوصول إلى قاعدة البيانات - ببساطة عن طريق الاسم المستعار.
- أقوم بإعادة تعيين سجلات وإعدادات قاعدة البيانات كجزء من اختبار الإعداد ، وأتصل بالخدمة ، وكتب إلى قاعدة البيانات ، وأتجه إلى قاعدة البيانات ، وأرى أن قاعدة البيانات لم تسقط ، وأرى ما وصل ، وأنا أتحقق. رمي المزيد من الاختبارات.
- لا يمكنك اختبار مع الأقلام!
النتائج
يبدو أن بضعة أسطر من الإعداد في gitlab-ci. بناء صورة عامل ميناء أمر سهل. تشغيل محليا بسيط. حصلت على التكامل مع الاختبارات الأولى التي وجدت مشاكل في يوم واحد. لكن محاولات إطلاقها على ci تحولت إلى أسبوع من الألم واليأس. والآن ، في أسابيع الألم واليأس للمطورين الذين يضطرون لإصلاح كل شيء قاموا ببرمجته هناك.
ماذا نجحنا في فعله؟
- أنشأنا حاوية مع clickhouse.
- بدأنا الحاوية في التخزين المحلي.
- لقد تعلمنا سحب هذه الصورة إلى الخطوة ci.
- بدأت في عداء.
إرسال البيانات بسهولة إلى قاعدة البيانات والوصول إليها من الاختبار.
الأتمتة هي طريقة بسيطة للتخلص من روتين التكامل الثاقب يدويًا.
من المهم الانتباه إلى: تأكد من أن أنواع الإدخال للقاعدة تتوافق مع أنواع مخرجات الرابط السابق. (والوثائق
، إن وجدت ).