CICD: نشر سلس لأنظمة العنقود الموزعة دون توقف

أنشر التقرير الثاني من تقريرنا الأول الذي عقد في سبتمبر. في المرة الأخيرة التي كنت تقرأ فيها (وترى) حول استخدام القنصل لتوسيع نطاق الخدمات الحكومية من إيفان بوبنوف من BIT.GAMES ، سنتحدث اليوم عن CICD. بتعبير أدق ، سيخبر مسؤول النظام لدينا Egor Panov عن ذلك ، من المسؤول عن توفر البنية التحتية والخدمات في Pixonic. تحت قطع - فك الأداء.



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

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

  1. خبرة ممتازة للمختبرين ؛
  2. التفاعل الوثيق معهم ؛
  3. الوقت الذي نعطيه للاختبار.

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

لكن بناء عملية CICD ليس بهذه البساطة. سيقول البعض ، حسنًا ، نعم ، سأضع جينكينز ، وسأتصل بسرعة بشيء ، والآن لدي جاهز CICD. لا ، هذه ليست أداة فحسب ، بل هي ممارسة أيضًا. لنبدأ بالترتيب.


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

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

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

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

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

القاعدة التالية: كلما ارتكبت أكثر ، كان ذلك أفضل. لماذا؟ لأن هناك رابع: يتم جمع كل ارتكاب. وفي الواقع ، أكثر من كل التزام. سبق أن قلت أن لدينا TeamCity ، ويسمح لك بتشغيل التزام من IDE المفضل لديك (تخمين ما أعنيه). في الواقع ، ردود فعل سريعة ، كل شيء رائع.

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

نحن اختبار على تكرار همز البيئة. الأمر بسيط ، اخترنا Ansible و AWX. قد يسأل شخص ما ، ولكن ماذا عن Docker ، Kubernetes ، OpenShift ، حيث تم حل جميع المشاكل خارج الصندوق لفترة طويلة؟ نسيت أن أقول أن لدينا مكونات لكل من Linux و Windows. وعلى سبيل المثال ، خادم الفوتون ، الموجود على نظام التشغيل Windows ، تمكنا مؤخرًا فقط من حزم أكثر أو أقل بشكل طبيعي في حاوية عامل إرساء 10 غيغابايت. وفقًا لذلك ، لدينا تطبيق Windows لا يحزم بشكل جيد في حاوية ؛ هناك تطبيق على Linux (وهو في Java) ، والذي يتم تعبئته بشكل مثالي ، ولكن لا يوجد سبب لذلك ، يعمل بشكل جيد أينما قمت بتشغيله. هذا هو جافا.

بعد ذلك ، اخترنا بين Ansible و Chef. كلاهما يعمل بشكل جيد مع Windows ، ولكن تبين أن Ansible أسهل بكثير بالنسبة لنا. عندما قمنا بالفعل بتثبيت AWX - بشكل عام أصبحت كل النار. لدى AWX أسرار ورسومات وتاريخ. يمكنك أن تظهر لشخص بعيد عن كل هذا ، سيرى كل شيء على الفور وسيصبح كل شيء واضحًا.

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


7 نقاط - وقد قمنا بالفعل ببناء نوع من عملية CI. عظيم الرسم البياني التالي غير مرئي ، ولكن لا يزال هناك Graylog على الجانب. من يقرأ مقالاتنا عن حبري ، التي شاهدت بالفعل كيف اخترنا Graylog وكيفية التثبيت . على أي حال ، يساعد على تجنب حدوث أي مشكلة.


الآن على هذه القاعدة من الممكن بالفعل الشروع في النشر.


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

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


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

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


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

النقطة الثانية - تحتاج إلى توفير بنية نشر بسيطة مقرونة بشكل فضفاض. لقد نجحنا.


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

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

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


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

بعد إكمال هذه الخطوات الـ 12 ، قمنا بزيادة عدد البيئات ، وبدأنا في اختبار المزيد ، وتم تسريع النشر ، وبدأ الناس في تلقي تعليقات سريعة.


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

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

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


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

أسئلة من الجمهور


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

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

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

أسرع.

على سبيل المثال ، إذا كنت بحاجة إلى تحديث إصدار Java ، فقم بتغيير حالة المثيل على Amazon ، أو تحديث إصدار Java أو أي شيء آخر ، ثم كيف يمكنك التراجع في هذه الحالة؟ هل تجري تغييرات على خادم الإنتاج؟

نعم ، يعمل كل مكون بشكل جيد مع الإصدار الجديد والإصدار القديم. نعم ، قد تضطر إلى إعادة تحميل الخادم.

هناك تغييرات في الحالة عندما تكون المشاكل الكبيرة ممكنة ...

ثم تنفجر.

يبدو لي فقط أن أضيف خادمًا جديدًا وأضعه على المجموعة المستهدفة في المجموعة المستهدفة - وهي مهمة صغيرة في التعقيد وممارسة جيدة جدًا.

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

أنت تقول إذا تم جمع كل التزام وإذا كان كل شيء سيئًا - فإن المطور يحكم كل شيء على الفور. هل تفهم أن كل شيء سيء؟ ما ارتكبت ارتكبت؟

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

على سبيل المثال أولاً ، يتم تنفيذ كل التزام وهل المختبرون يشاهدونه؟

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

والسؤال أصغر: هناك خادم تطبيقات في الصورة وما إلى ذلك ، هل هذا ما يهمني هناك؟ قلت أنه لا يبدو أن لديك Docker ، ما هو الخادم؟ جافا عارية أم ماذا؟

في مكان ما هذا هو الفوتون على Windows (خادم ألعاب) ، خادم التطبيق هو تطبيق Java على Tomcat.

على سبيل المثال لا افتراضية ، لا حاويات ، لا شيء؟

حسنا ، جافا ، يمكنك القول ، حاوية.

وهل كل ذلك يبدأ مع Ansible؟

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

وكيف يتم نشر قاعدة البيانات؟ الاعتماد على المكون أو الخدمة؟

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

هل قاعدتك أيضًا من الحديد أو القاعدة في مكان ما في السحابة في الأمازون؟

أكبر قاعدة هي الحديد ، ولكن هناك أخرى. هناك صغار ، لم تعد RDS حديدية ، افتراضية. تلك الخدمات الصغيرة التي عرضتها: الدردشات ، الدوريات ، الدردشة مع Facebook ، العشائر ، واحدة من هذه هي RDS.

الخادم الرئيسي - كيف يبدو؟

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

أفهم بشكل صحيح أنه لكل عملية نشر تكتبها (إذا ظهرت أي ميزات) ترحيل لتحديث البيانات؟ قلت أنك تأخذ القطع الأثرية القديمة وتملأها - ماذا يحدث للبيانات؟ هل تكتب الترحيل للتراجع عن القاعدة؟

هذه عملية استرجاع نادرة جدًا. نعم ، تكتب هجرة الأقلام ، وماذا تفعل.

كيف يتزامن تحديث الخادم مع تحديثات العميل؟ على سبيل المثال أنت بحاجة إلى إصدار نسخة جديدة من اللعبة - هل ستقوم أولاً بتحديث جميع الخوادم ، ثم سيتم تحديث العملاء؟ هل يدعم الخادم كلاً من الإصدارين القديم والجديد؟

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

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

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

على سبيل المثال هل يدعم المختبرون مستودع الاختبار في فريقك؟ وتكمن الاختبارات الذاتية بشكل منفصل؟

نعم لقد قمت ببعض الميزات ويمكنك جمع تلك الاختبارات التلقائية التي تحتاجها من مستودع المختبرين ، ولا تتحقق من كل شيء آخر.

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

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

لقد تحدثت عن طرح الأتمتة على خوادم المنتجات ، و (كما أفهمها) ، هناك أيضًا طرح الأتمتة لاختبار - ماذا عن بيئات التطوير؟ هل هناك أي نوع من الأتمتة التي تم نشرها من قبل المطورين؟

تقريبا نفس الشيء. الشيء الوحيد ليس خوادم الحديد ، ولكن في الجهاز الافتراضي ، ولكن الجوهر هو نفسه. في نفس الوقت ، على نفس Ansible ، كتبنا (لدينا Ovirt) إنشاء هذا الجهاز الافتراضي والتدليل عليه.

هل لديك القصة كاملة مخزنة في مشروع واحد مع همزات Ansible وتكوينات الاختبار ، أم أنها تعيش وتتطور بشكل منفصل؟

يمكننا القول أن هذه مشاريع منفصلة. ديف (نسميها devbox) هي قصة عندما يكون كل شيء في حزمة واحدة ، وعلى همز هي قصة موزعة.

المزيد من المحادثات مع محادثات Pixonic DevGAMM


Source: https://habr.com/ru/post/ar425813/


All Articles