لا يتم نشر مواد فاضحة ومهمة وبسيطة جدًا في وسائل الإعلام كل يوم ، ولن يتعهد أي محرر بالتنبؤ بنجاح مقال بدقة 100٪. الحد الأقصى الذي يتمتع به الفريق هو في المستوى الغريزي لقول مادة "قوية" أو "عادية". هذا كل شيء. ثم يبدأ سحر الوسائط الذي لا يمكن التنبؤ به ، والذي بفضله يمكن أن تصل المقالة إلى قمة نتائج البحث بعشرات الروابط من منشورات أخرى أو ستغرق المواد في غياهب النسيان. وفي حالة نشر مقالات رائعة ، تندرج مواقع الوسائط بشكل دوري تحت التدفق الوحشي للمستخدمين ، والذي نسميه بتواضع "التهيج".
في هذا الصيف ، أصبح موقع منشورات
الجمهورية ضحية لمهنيي مؤلفيها: جمعت مقالات حول موضوع إصلاح المعاشات والتعليم المدرسي والتغذية المناسبة إجمالاً جمهوراً من عدة ملايين من القراء. أدى نشر كل مادة من المواد المذكورة إلى ارتفاع الأحمال لدرجة أنه حتى سقوط موقع الجمهورية ، كان هناك "مساحة صغيرة" على الإطلاق. أدركت الإدارة أن هناك شيئًا ما يجب تغييره: كان من الضروري تغيير هيكل المشروع بحيث يمكن أن يتفاعل بقوة مع التغييرات في ظروف العمل (الحمل الخارجي بشكل أساسي) ، بينما تظل وظيفية بالكامل ومتاحة للقراء حتى في أوقات القفزات الحادة جدًا في الحضور. ومكافأة كبيرة ستكون الحد الأدنى من التدخل اليدوي للفريق الفني للجمهورية في مثل هذه الأوقات.
استنادًا إلى نتائج مناقشة مشتركة مع أخصائيي الجمهورية حول مختلف الخيارات لتنفيذ قائمة الأمنيات الصوتية ، فقد قررنا نقل موقع المنشور إلى Kubernetes *. حول ما كلفنا جميعًا ، وستكون قصتنا اليوم.
* خلال هذه الخطوة ، لم يصب أخصائي تقني جمهوري واحدكيف بدا بعبارات عامة
بدأ كل شيء ، بالطبع ، بمفاوضات حول كيفية حدوث كل شيء "الآن" و "لاحقًا". لسوء الحظ ، فإن النموذج الحديث في سوق تكنولوجيا المعلومات يعني أنه بمجرد أن تذهب أي شركة إلى جانب نوع من حلول البنية التحتية ، فإنها تقوم بتشغيله على قائمة أسعار خدمة تسليم المفتاح. يبدو أن العمل "جاهز" - ما الذي يمكن أن يكون أجمل وأكثر جمالًا من المدير الشرطي أو صاحب العمل؟ لقد دفعت ، ولم يؤلم رأسي: التخطيط ، التطوير ، الدعم - كل شيء موجود ، إلى جانب المقاول ، لا يمكن لرجال الأعمال جني الأموال إلا مقابل هذه الخدمة الممتعة.
ومع ذلك ، فإن النقل الكامل للبنية التحتية لتكنولوجيا المعلومات غير مناسب دائمًا للعميل على المدى الطويل. من الأصح من جميع وجهات النظر أن تعمل كفريق واحد كبير ، بحيث بعد الانتهاء من المشروع ، يفهم العميل كيفية التعايش مع البنية التحتية الجديدة بشكل أكبر ، وليس لدى الزملاء في طابق المتجر سؤال "أوه ، ولكن ماذا فعلت هنا؟ بعد توقيع شهادة الإنجاز وعرض النتائج. كان رجال الجمهورية من نفس الرأي. ونتيجة لذلك ، قمنا منذ شهرين بتهريب أربعة أشخاص للعميل ، الذي لم يدرك فكرتنا فحسب ، ولكن أيضًا المتخصصين المدربين تقنيًا على الجانب الجمهوري لمواصلة العمل والوجود في حقائق Kubernetes.
وقد استفادت جميع الأطراف من هذا: لقد أكملنا العمل بسرعة ، وأبقينا المتخصصين على استعداد لإنجازات جديدة وحصلنا على Republic كعميل في دعم استشاري مع مهندسينا. من ناحية أخرى ، تلقى المنشور بنية تحتية جديدة تتلاءم مع "التحرّكات" وموظفيها المحتجزين من المتخصصين التقنيين والقدرة على طلب المساعدة إذا لزم الأمر.
نحن نستعد جسر
"تدمير - وليس بناء". ينطبق هذا القول على أي شيء على الإطلاق. بطبيعة الحال ، يبدو أن الحل الأبسط هو أخذ الرهائن المذكور سابقًا للبنية التحتية للعميل وتقييده ، العميل بنفسه ، أو رفع تردد الموظفين الحاليين وشرط توظيف معلم في التقنيات الجديدة. ذهبنا الطريق الثالث ، وليس الطريقة الأكثر شعبية اليوم ، وبدأنا بتدريب مهندسي الجمهورية.
في البداية ، رأينا مثل هذا الحل لضمان تشغيل الموقع:
وهذا هو ، كان جمهورية فقط اثنين من خوادم الحديد - الرئيسية والنسخ الاحتياطي ، والنسخ الاحتياطي. كان أهم شيء بالنسبة لنا هو تحقيق نقلة نوعية في تفكير المتخصصين التقنيين للعميل ، لأنهم تعاملوا في وقت سابق مع مجموعة بسيطة جدًا من NGINX و PHP-fpm و PostgreSQL. الآن واجهوا مع هيكل حاوية قابلة للتطوير من Kubernetes. لذلك أولاً ، حولنا تطور الجمهورية المحلية إلى بيئة إنشاء عامل الميناء. وكانت هذه هي الخطوة الأولى فقط.
قبل الهبوط لدينا ، حافظ مطورو Republic على بيئة العمل المحلية الخاصة بهم في الأجهزة الافتراضية التي تم تكوينها من خلال Vagrant ، أو عملوا مباشرة مع خادم dev عبر sftp. استنادًا إلى الصورة الأساسية العامة لجهاز افتراضي ، قام كل مطور "بتكوين" آليته "لنفسه" ، مما أدى إلى ظهور مجموعة كاملة من التكوينات المختلفة. نتيجة لهذا النهج ، زاد إدراج أشخاص جدد في الفريق بشكل كبير من الوقت الذي دخلوا فيه المشروع.
في الواقع الجديد ، قدمنا للفريق بنية أكثر شفافية لبيئة العمل. ووصف تعريف البرنامج والإصدارات التي يحتاجها المشروع وترتيب الاتصالات والتفاعلات بين الخدمات (التطبيقات). تم تحميل هذا الوصف إلى مستودع بوابة منفصل بحيث يمكن إدارته بشكل مركزي مركزيًا.
بدأ تشغيل جميع التطبيقات الضرورية في حاويات منفصلة لرسو السفن - وهذا هو موقع php منتظم مع nginx ، والكثير من الاستاتيكا ، والخدمات للعمل مع الصور (تغيير الحجم ، والتحسين ، وما إلى ذلك) ، و ... خدمة منفصلة لمقابس الويب المكتوبة في D أصبحت جميع ملفات التكوين (nginx-conf ، php-conf ...) جزءًا من قاعدة كود المشروع.
وفقًا لذلك ، تم "إعادة إنشاء" البيئة المحلية تمامًا ، وهي مطابقة تمامًا للبنية الأساسية للخادم الحالي. وبالتالي ، تم تقليل الوقت اللازم للحفاظ على نفس البيئة على الأجهزة المحلية للمطورين وعلى المنتج. والتي بدورها ساعدت بشكل كبير في تجنب المشكلات غير الضرورية تمامًا التي تسببها التكوينات المحلية المكتوبة ذاتيا لكل مطور.
نتيجة لذلك ، تم رفع الخدمات التالية في بيئة عامل التأسيس:
- الويب لتطبيق php-fpm ؛
- إنجن إكس
- impproxy و cairosvg (خدمات للعمل مع الصور) ؛
- بوستجرس
- redis
- البحث المرن
- البوق (نفس الخدمة لمآخذ الويب على D).
من وجهة نظر المطورين ، ظل العمل مع قاعدة الكود بدون تغيير - تم تثبيته في الخدمات الضرورية من دليل منفصل (المستودع الأساسي بكود الموقع) إلى الخدمات الضرورية: الدليل العام في خدمة nginx ، وكل كود تطبيق php في خدمة php-fpm. من الدليل المنفصل (الذي يحتوي على جميع تكوينات بيئة الإنشاء) ، يتم تثبيت ملفات التكوين المقابلة في خدمات nginx و php-fpm. يتم أيضًا تثبيت الدلائل التي تحتوي على postgres للبيانات و elasticsearch و redis على الجهاز المحلي للمطور ، بحيث إذا كان لابد من إعادة بناء / حذف جميع الحاويات ، فلن يتم فقد البيانات الموجودة في هذه الخدمات.
للعمل مع سجلات التطبيق - أيضًا في بيئة إنشاء عامل النقل - تم رفع خدمات مكدس ELK. في السابق ، تمت كتابة جزء من سجلات التطبيق في المعيار / var / log / ... ، وتم كتابة سجلات تطبيق php وعمليات الإعدام في Sentry ، وكان هذا الخيار لتخزين السجل "اللامركزي" غير مريح للغاية للعمل معه. الآن ، تم تكوين التطبيقات والخدمات وصقلها للتفاعل مع مكدس ELK. أصبح استخدام السجلات أسهل ؛ حيث أصبح لدى المطورين الآن واجهة ملائمة للبحث عن السجلات وتصفيتها. في المستقبل (بالفعل في المكعب) - يمكنك مشاهدة سجلات إصدار محدد من التطبيق (على سبيل المثال ، أطلقت kronzhoba في اليوم السابق أمس).
علاوة على ذلك ، بدأ فريق الجمهورية فترة قصيرة من التكيف. احتاج الفريق إلى فهم وتعلم كيفية العمل في نموذج التطوير الجديد ، والذي يجب مراعاة ما يلي:
- تصبح التطبيقات عديمة الجنسية ، وقد تفقد البيانات في أي وقت ، لذلك يجب أن يكون العمل باستخدام قواعد البيانات والجلسات والملفات الثابتة مختلفًا. يجب تخزين جلسات PHP مركزيًا ومشاركتها بين جميع مثيلات التطبيق. قد تستمر في كونها ملفات ، ولكن في كثير من الأحيان يتم أخذ redis لهذه الأغراض بسبب سهولة إدارتها. يجب أن تقوم حاويات قواعد البيانات إما "بتركيب" قاعدة بيانات ، أو يجب تشغيل قاعدة البيانات خارج البنية التحتية للحاوية.
- يجب ألا يكون تخزين الملفات الذي يتراوح حجمه بين 50 و 60 غيغابايت من الصور "داخل تطبيق الويب". لهذه الأغراض ، من الضروري استخدام بعض وحدات التخزين الخارجية وأنظمة الأقراص المضغوطة وغيرها.
- جميع التطبيقات (قواعد البيانات ، خوادم التطبيقات ...) أصبحت الآن "خدمات" منفصلة ، وينبغي تكوين التفاعل بينها بالنسبة لمساحة الاسم الجديدة.
بعد أن اعتاد فريق تطوير Republic على الابتكارات ، بدأنا نقل البنية التحتية لمبيعات المنشور إلى Kubernetes.
وهنا Kubernetes
استنادًا إلى بيئة إنشاء عامل الإرساء للتنمية المحلية ، بدأنا في ترجمة المشروع إلى "مكعب". جميع الخدمات التي تم بناء المشروع عليها محليًا ، "نحن معبأ في حاويات": قمنا بتنظيم إجراء خطي ومفهوم لبناء التطبيقات ، وتخزين التكوينات ، وجمع الإحصائيات. من وجهة نظر التطوير ، قاموا بإزالة معلمات التكوين التي احتجناها إلى متغيرات البيئة ، وبدأنا في تخزين الجلسات ليس في الملفات ، ولكن في الفجل. لقد رفعنا بيئة الاختبار ، حيث نشرنا نسخة قابلة للتطبيق من الموقع.
نظرًا لأن هذا مشروع متراصة سابقًا ، فمن الواضح أن هناك علاقة قوية بين إصدارات الواجهة الأمامية والإصدارات الخلفية ، على التوالي ، وقد تم نشر هذين المكونين في نفس الوقت. لذلك ، قررنا إنشاء قرون تطبيق الويب بطريقة تدور حاويتان في جراب واحد: php-fpm و nginx.
لقد صممنا أيضًا تحجيمًا تلقائيًا بحيث يتم توسيع نطاق تطبيقات الويب إلى 12 كحد أقصى في ذروة حركة المرور ، وتعيين بعض اختبارات الاستعداد / الاستعداد ، لأن التطبيق يتطلب تشغيل دقيقتين على الأقل (نظرًا لأنك تحتاج إلى تسخين ذاكرة التخزين المؤقت ، وإنشاء تكوينات ...)
على الفور ، بالطبع ، كانت هناك جميع أنواع المياه الضحلة والفروق الدقيقة. على سبيل المثال: كانت الإحصائيات المترجمة ضرورية لكل من خادم الويب الذي قام بتوزيعها وخادم التطبيقات على fpm ، والتي ولدت في مكان ما نوعًا ما من الصور ، أعطى svg في مكان ما الرمز مباشرةً. لقد أدركنا أنه حتى لا ننهض مرتين ، نحتاج إلى إنشاء حاوية بناء وسيطة وتجميع الحاويات النهائية عبر عدة مراحل. للقيام بذلك ، أنشأنا العديد من الحاويات الوسيطة ، حيث يتم سحب التبعيات بشكل منفصل ، ثم يتم جمع الإحصائيات (css و js) بشكل منفصل ، ثم في حاويتين - في nginx وفي fpm - يتم نسخهما من حاوية الإنشاء الوسيطة.
نبدأ
للعمل مع الملفات في التكرار الأول ، قدمنا دليلًا مشتركًا متزامنًا مع جميع الأجهزة العاملة. بكلمة "متزامنة" أعني هنا بالضبط ما يمكنك التفكير به من الرعب في المقام الأول - rsync في دائرة. من الواضح أن القرار سيء. نتيجةً لذلك ، حصلنا على كل مساحة القرص على GlusterFS ، وقمنا بإعداد العمل مع الصور بحيث يمكن الوصول إليها دائمًا من أي جهاز ولا يتباطأ أي شيء. لتفاعل تطبيقاتنا مع أنظمة التخزين (postgres ، elasticsearch ، redis) ، تم إنشاء خدمات externalName في k8s ، بحيث ، على سبيل المثال ، في حالة التحول العاجل إلى قاعدة بيانات النسخ الاحتياطي ، قم بتحديث معلمات الاتصال في مكان واحد.
تم نقل كل العمل مع crones إلى كيانات k8s الجديدة - cronjob ، والتي يمكن تشغيلها وفقًا لجدول زمني محدد.
نتيجة لذلك ، حصلنا على هذه البنية:
قابل للنقريا صعب
كان هذا هو إطلاق الإصدار الأول ، لأنه بالتوازي مع إعادة الهيكلة الكاملة للبنية التحتية ، كان الموقع لا يزال يخضع لإعادة التصميم. تم بناء جزء من الموقع مع بعض المعلمات - للإحصائيات وكل شيء آخر ، وجزء - مع الآخرين. هناك كان من الضروري ... بعبارة ملطفة ... أن تنحرف مع كل هذه الحاويات متعددة المراحل ، ونسخ البيانات منها بترتيب مختلف ، إلخ.
كان علينا أيضًا أن نرقص مع الدف في جميع أنحاء نظام CI \ CD من أجل تعليم كل هذا للنشر والتحكم من مستودعات مختلفة ومن بيئات مختلفة. بعد كل شيء ، هناك حاجة إلى التحكم المستمر في إصدارات التطبيق حتى تتمكن من فهم متى تم نشر خدمة أو خدمة أخرى وبأي إصدار من التطبيق بدأ خطأ واحد أو آخر. للقيام بذلك ، قمنا بإعداد نظام التسجيل الصحيح (وكذلك ثقافة التسجيل نفسها) وتطبيق ELK. لقد تعلم الزملاء تعيين محددات معينة ، ومعرفة أي cron يولد الأخطاء ، وكيف يتم تنفيذها بشكل عام ، لأنه في "cube" بعد تنفيذ cron-container ، لن تتمكن من الدخول فيه بعد الآن.
ولكن أصعب شيء بالنسبة لنا هو إعادة صياغة ومراجعة قاعدة الشفرة بأكملها.
واسمحوا لي أن أذكركم ، أن Republic هو مشروع عمره الآن 10 سنوات. بدأ الأمر بفريق واحد ، والآخر يتطور الآن ، ومن الصعب حقًا تجفيف جميع الأكواد المصدرية للأخطاء والأخطاء المحتملة. بالطبع ، في هذه اللحظة ، ربط فريقنا المكون من أربعة أفراد موارد بقية الفريق: لقد نقرنا واختبرنا الموقع بالكامل من خلال الاختبارات ، حتى في الأقسام التي لم يزرها الأشخاص المباشرون منذ عام 2016.
لا يفشل في أي مكان
في يوم الإثنين ، في الصباح الباكر ، عندما ذهب الناس إلى البريد عبر الخلاصة ، حصلنا جميعًا على حصة. تم العثور على الجاني بسرعة كبيرة: بدأت cronjob وبدأت بشكل محموم بإرسال رسائل إلى كل من أراد الحصول على مجموعة مختارة من الأخبار على مدار الأسبوع الماضي ، والتهام موارد المجموعة بأكملها على طول الطريق. لم نتمكن من تحمل مثل هذا السلوك ، لذلك وضعنا قيودًا سريعة على جميع الموارد: مقدار المعالج والذاكرة التي يمكن أن تستهلكها الحاوية وما إلى ذلك.
كيف تعامل فريق مطوري الجمهورية
جلبت أنشطتنا الكثير من التغييرات ، وفهمنا ذلك. في الواقع ، لم نقم فقط بإعادة تصميم البنية التحتية للمنشور ، بدلاً من حزمة "خادم النسخ الاحتياطي الرئيسي" المعتادة ، قمنا بتطبيق حل حاوية ، حيث كان ذلك ضروريًا ، قام بتوصيل موارد إضافية ، ولكننا قمنا أيضًا بتغيير النهج الخاص بالمزيد من التطوير.
بعد مرور بعض الوقت ، بدأ الرجال يدركون أن هذا لا يعمل بشكل مباشر مع الكود ، ولكنه يعمل مع تطبيق تجريدي. نظرًا لعمليات CI \ CD (المبنية على Jenkins) ، فقد بدأوا في كتابة الاختبارات ، وحصلوا على بيئات تطوير مطورة كاملة حيث يمكنهم اختبار إصدارات جديدة من تطبيقاتهم في الوقت الحقيقي ، ومعرفة أين يقع كل شيء ، وتعلم كيفية العيش في عالم مثالي جديد.
ماذا حصل العميل
بادئ ذي بدء ، حصلت الجمهورية أخيرًا على عملية نشر مسيطر عليها! اعتاد أن يكون: في الجمهورية كان هناك شخص مسؤول ذهب إلى الخادم ، وبدأ كل شيء يدويًا ، ثم جمع احصائيات ، وتحقق بأيديهم من أنه لم يحدث أي شيء ... الآن تم بناء عملية النشر بحيث يشترك المطورون في التطوير ولا يضيعون الوقت في أي شيء آخر . والشخص المسؤول لديه الآن مهمة واحدة - لمراقبة كيف ذهب الإصدار بشكل عام.
بعد حدوث دفعة للفرع الرئيسي ، إما تلقائيًا أو عن طريق نشر "الضغط على الزر" (بشكل دوري ، بسبب بعض متطلبات العمل ، يتم تعطيل النشر التلقائي) ، يدخل Jenkins المعركة: يبدأ تجميع المشروع. أولاً ، يتم تجميع جميع حاويات الرصيف: يتم تثبيت التبعيات (الملحن والغزل و npm) في الحاويات التحضيرية ، مما يسمح لك بتسريع عملية الإنشاء إذا لم تتغير قائمة المكتبات المطلوبة أثناء النشر ؛ ثم يتم جمع حاويات php-fpm ، nginx ، وغيرها من الخدمات ، والتي ، من خلال القياس مع بيئة عامل الميناء ، يتم نسخ الأجزاء الضرورية فقط من قاعدة الشفرة. بعد ذلك ، يتم إطلاق الاختبارات ، وفي حالة النجاح في اجتياز الاختبارات ، هناك دفعة من الصور إلى المتجر الخاص ، وفي الواقع ، يتم نشرها في cuber.
بفضل نقل جمهورية إلى k8s ، حصلنا على بنية باستخدام مجموعة من ثلاث آلات حقيقية يمكن أن "تدور" ما يصل إلى اثني عشر نسخة من تطبيق الويب في نفس الوقت. في الوقت نفسه ، يقرر النظام نفسه ، استنادًا إلى الأحمال الحالية ، عدد النسخ التي يحتاجها في الوقت الحالي. لقد أخذنا Republic من يانصيب "works - لا يعمل" مع خوادم ثابتة ونسخ احتياطي ثابتة وقمنا ببناء نظام مرن لهم ، جاهزين لزيادة الحمل على الموقع بشكل يشبه الانهيار.
في هذه اللحظة ، قد يطرح السؤال "يا شباب ، لقد قمت بتغيير قطعتين من الحديد إلى نفس قطعة الحديد ، ولكن مع المحاكاة الافتراضية ، ما هي المكسب ، هل أنت بخير هناك؟" وبطبيعة الحال ، سيكون من المنطقي. ولكن فقط جزئيا. نتيجة لذلك ، لم نحصل على قطع الأجهزة الافتراضية فقط. لدينا بيئة عمل مستقرة ، نفس الشيء في كل من الغذاء والعذراء. بيئة تدار مركزيا لجميع المشاركين في المشروع. لدينا آلية لتجميع المشروع بأكمله ونشر الإصدارات ، مرة أخرى ، هي نفسها للجميع. لقد حصلنا على نظام مناسب لتنسيق المشروع. بمجرد أن يلاحظ فريق Republic أنهم يتوقفون عمومًا عن امتلاك ما يكفي من الموارد الحالية ومخاطر الأحمال العالية جدًا (أو عندما يكون قد حدث بالفعل واستقر كل شيء) ، فإنهم يأخذون خادمًا آخر ، في غضون 10 دقائق ، يقومون بدور عقدة نظام المجموعة عليه ، و op-op كل شيء جميل وجيد مرة أخرى. لم يشر هيكل المشروع السابق إلى مثل هذا النهج على الإطلاق ؛ لم تكن هناك حلول بطيئة أو سريعة لهذه المشاكل.
ثانياً ، ظهر نشر سلس: سيحصل الزائر على الإصدار القديم من التطبيق ، أو إلى إصدار جديد. وليس كما كان من قبل ، عندما يكون المحتوى جديدًا ، ولكن الأنماط قديمة.
نتيجة لذلك ، فإن العمل راضٍ: يمكن الآن إجراء جميع أنواع الأشياء الجديدة بشكل أسرع وأكثر.
في المجموع ، من "ولكن دعونا نحاول" إلى "القيام به" ، استغرق العمل في المشروع شهرين. الفريق من جانبنا هو الهبوط البطولي لأربعة أشخاص + دعم لـ "القاعدة" أثناء التحقق من الشفرة والاختبارات.
ما حصل المستخدمين
والزائرين ، من حيث المبدأ ، لم يروا التغييرات. بنيت عملية النشر على استراتيجية RollingUpdate "بسلاسة". لن يؤدي إصدار نسخة جديدة من الموقع إلى إيذاء المستخدمين بأي حال من الأحوال ، ولن يكون الإصدار الجديد من الموقع متاحًا ، حتى يتم اجتياز الاختبارات واختبارات الصلاحية / الاستعداد. إنهم فقط يرون أن الموقع يعمل وأنه لن يسقط بعد نشر مقالات رائعة. وهو ، بشكل عام ، ما يحتاج إليه أي مشروع.