خدمات Microservices. الإصدارات في التكامل المستمر وأنظمة النشر دراسة حالة CI / CD باستخدام TFS

العدد

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

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

كان علينا أن نتأكد من هذا الأمر شخصياً ونواجه الكثير من الصعوبات في مشروع كبير ، حيث تم إصدار 6-8 إصدارات جديدة من البرنامج على الواجهة الخلفية وإصدار 2-3 إصدارات من البرنامج على الواجهة الأمامية في نظام CI ، حيث لم يتمكن مهندسو الاختبار من التعامل بشكل موضوعي مع الحمل و كان هناك نقص مستمر في فهم أي إصدار من البرنامج على الواجهة الأمامية / الخلفية يعتبر ثابتًا في الوقت الحالي.

تجربتنا

تستخدم شركتنا العديد من أنظمة CI / CD في عملها ، وغالبًا ما يتم تحديد اختيارها حسب متطلبات العميل. على سبيل المثال ، غالبًا ما يصادف المختصون لدينا أنظمة CI / CD مثل Jenkins و TeamCity و Travis CI و Circle CI و Gitlab CI و Atlassian Bamboo ، حيث نعمل في بعض الأحيان بشكل كامل على البنية التحتية للعملاء. وفقًا لذلك ، مع هذا النهج ، تكمن المشكلة في حل الإصدار بالكامل في يد العميل.

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

• بيان المهام (المشكلات ، الأخطاء ، المهام) استنادًا إلى النهج المتبع في تطوير البرمجيات المستخدمة في المشروع الحالي ؛
• تخزين رمز مصدر المشروع ؛
• نشر البنية التحتية لوكلاء البناء للتجميعات لأنظمة تشغيل مختلفة (Windows ، Linux ، MacOS) ؛
• تجميع المشروعات في الوضع "اليدوي" و CI ؛
• نشر المشاريع في الوضع "اليدوي" والقرص المضغوط ؛
• مشاريع الاختبار
• تشكيل البيانات المتعلقة بالوقت الذي يقضيه الموظفون في المشروع وعدد من الوظائف الإضافية التي قمنا بتنفيذها باستخدام ملحقات TFS لتصميمنا الخاص وإضافة إضافة إحصائيات إلى WIT (في هذا النموذج ، استبدلت TFS شركتنا Redmine وبسّطت جمع الإحصاءات والتقارير وغيرها ، في سياق المشاريع )

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

الحل: استخدام TFS وأدوات الجهة الخارجية

لذلك ، نحن بحاجة إلى نظام إصدار لمشاريع هندسة الخدمات المصغرة لتنظيم بيئات الاختبار والإصدارات.

كبيانات أولية لدينا:

• Orchestration - نستخدم سرب docker أساسًا لتقليل استخدام أدوات الطرف الثالث الأخرى. في الوقت نفسه ، هناك محولات لتحويل التكوينات - على سبيل المثال ، الأداة المساعدة Kompose ، والتي سوف تسمح لك باستخدام Kubernetes إذا لزم الأمر.
• بناء وكلاء - VM على أساس خوادم لينكس.
• مستودع المصدر - بوابة المستندة إلى TFS.
• تخزين الصور - سجل عامل ميناء على VM.

إلى مسألة اسم البنيات

• سيكون من المنطقي استخدام معايير التسمية الحالية ، على سبيل المثال ، مثل مواصفة الإصدار الدلالي .
• نتبع هذا الاسم عند بدء عملية إنشاء إصدار الإصدار يدويًا ، وإلا فلن تكون قادرًا على الحصول على الاسم الصحيح تلقائيًا (إلا إذا قمت بوضعه في الكود يدويًا ، والذي يرتبط مرةً أخرى بإيديولوجية CI).
• في وضع CI لإصدارات برامج "تصحيح الأخطاء" ، نستخدم الأسماء التالية في مشاريع مختلفة:
  
  
  1. المدمج في ملحقات TFS
  2. الترقيم على أساس التاريخ الحالي ورقم البناء في ذلك اليوم ؛
  3. عدد الالتزام الذي بدأ الإنشاء.

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

خوارزمية القرار

1. في TFS2018 ، قم بإنشاء مشروع يسمى SibEDGE Semver واستيراد المستودع إلى المستودع المحلي


الشكل 1 - مشروع SibEDGE Semver في المستودع في TFS 2018

2. إنشاء ملف Dockerfile مع وصف التجميع node.js لاحتياجاتنا ( الرابط ).

FROM node:7 WORKDIR /usr/src/app COPY package.json app.js LICENSE /usr/src/app/ COPY lib /usr/src/app/lib/ LABEL license MIT COPY tests tests ENV NODE_ENV dev RUN npm config set strict-ssl false RUN npm update && \ npm install -g mocha CMD ["mocha", "tests/test.js", "--reporter", "spec"] 

البرنامج النصي 1 - Dockerfile لبناء بناء

3. على منصة الاختبار (مع تثبيت عامل الميناء) ، حيث نخطط لنشر بيئتنا ، قم بإنشاء مجموعة سرب. في حالتنا ، سيتكون من خادم واحد.

 $ docker swarm init 

4. قم بإنشاء ملف yml مع وصف للخدمات الميكروية لتلبية احتياجاتنا ( رابط ).
لاحظ أن vm-docker-registry.development.com:5000 هو المستودع الداخلي لهذا المشروع ، الذي vm-docker-registry.development.com:5000 مقدمًا. حتى يتمكن حامل الاختبار من استخدام هذا المستودع ، من الضروري تسجيل شهادة ssl على الحامل في /etc/docker/certs.d/ <اسم المستودع> /ca.crt folder

 version: '3.6' services: #--- # Portainer for manage Docker #--- portainer: image: portainer/portainer:1.15.3 command: --templates http://templates/templates.json -d /data -H unix:///var/run/docker.sock networks: - semver-network ports: - 9000:9000 volumes: - /var/run/docker.sock:/var/run/docker.sock #--- #----Service Calculator Test# #--- semver-calc: image: vm-docker-registry.development.com:5000/calculator:latest networks: - semver-network #--- #----Pminder - Nginx# #--- nginx: image: nginx:1.9.6 depends_on: - mysql ports: - "8888:80" - "6443:443" networks: - semver-network # #----------------------------- # START NoSQL - Redis. #--- redis: image: redis:4.0 networks: - semver-network ports: - "8379:6379" # # END NoSQL - Redis. #--- #----Pminder - DB# #--- mysql: image: mysql:5.7 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: 'ODdsX0xcN5A9a6q' MYSQL_DATABASE: 'semver' MYSQL_USER: 'user' MYSQL_PASSWORD: 'uXcgTQS8XUm1RzR' networks: - semver-network #--- #----PhpMyAdmin # #--- phpmyadmin: image: phpmyadmin/phpmyadmin depends_on: - mysql environment: PMA_HOST: 'mysql' PMA_USER: 'user' PMA_PASSWORD: 'uXcgTQS8XUm1RzR' ports: - "8500:80" - "8600:9000" networks: - semver-network #--- networks: semver-network: 

البرنامج النصي 2 هو محتويات ملف semver.yml ، وهو ملف مشروع إنشاء عامل ميناء.

5. قم بإنشاء وصف بناء في TFS2018 (تعريف البنية).

6. الإجراء الأول من السيناريو لدينا هو بناء صورة حاوية عامل ميناء:


الشكل 2 - بناء صورة لبناء لدينا في TFS 2018

7. أرسل صورة حاوية الإرساء التي تم إنشاؤها على آلة الإنشاء إلى مستودع التخزين الداخلي لهذا المشروع:


الشكل 3 - حفظ صورة عامل ميناء لتجميع لدينا في مستودع TFS 2018

8. للحصول على البيئة بأكملها على طاولة الاختبار في ملف وصف microservices ، قم بتغيير اسم الصورة إلى اسم جديد:


الشكل 4 - استبدال اسم الصورة في البرنامج النصي للبناء الخاص بنا في TFS 2018

9. على منصة الاختبار ، انسخ صورة حاوية عامل النقل التي تم إنشاؤها من المستودع الداخلي وتحديث الخدمة في سرب عامل الميناء:


الشكل 5 - نشر حاوية عامل الإرساء باستخدام البرنامج النصي للبناء الخاص بنا من الصورة في TFS 2018

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

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

 $ docker service ls 

الشكل 6 - تحديث خدمة الحاسبة والتحقق من نسختها الحالية على منصة الاختبار الخاصة بنا

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

ملخص - ما حصلت عليه عند الخروج

بفضل تنفيذ الإصدارات في المشاريع ذات بنية microservice ، تم تحقيق النتيجة التالية:

• انخفض حجم الفوضى في الإصدارات ؛
• زيادة سرعة نشر بيئة جديدة في المشاريع ؛
• تحسنت جودة التجميعات وانخفض مستوى الأخطاء فيها ؛
• زيادة شفافية التطوير لمديري المشاريع والعملاء ؛
• تحسن التفاعل بين الإدارات ؛
• هناك اتجاهات جديدة في عمل DevOps.

ملحوظة: شكرًا لزميلي كيريل ب. لمساعدتي في كتابة هذا المقال.