هذه المقالة هي نسخة من تقرير الفيديو من أليكسي فاخوف من Uchi.ru "السحب في الغيوم"
Uchi.ru هي عبارة عن منصة على الإنترنت للتعليم المدرسي ، وأكثر من 2 مليون طالب ، والفصول التفاعلية تقرر بانتظام معنا. يتم استضافة جميع مشاريعنا بالكامل في السحب العامة ، وتعمل 100٪ من التطبيقات في حاويات ، بدءًا من الأصغر ، للاستخدام الداخلي ، وتنتهي بالإنتاج الكبير بمعدل 1k + طلبات في الثانية. لقد حدث أن لدينا 15 مجموعة من مجموعات عمال الرصيف المعزولة (وليس Kubernetes ، هكذا!) في خمسة مزودي خدمات سحابية. خمسة عشر مائة تطبيق مستخدم ، يتزايد عددهم باستمرار.
سأتحدث عن أشياء محددة للغاية: كيف تحولنا إلى الحاويات ، وكيف ندير البنية التحتية ، والمشاكل التي واجهناها ، وما الذي نجح وما لم يفعل.
خلال التقرير ، سنناقش:
- الدافع لاختيار التكنولوجيا وميزات العمل
- الأدوات: Ansible ، Terraform ، Docker ، Github Flow ، القنصل ، Nomad ، Prometheus ، Shaman - واجهة ويب لـ Nomad.
- استخدام اتحاد الكتلة لإدارة البنية التحتية الموزعة
- نشرات NoOps وبيئات الاختبار ودارات التطبيق (يقوم المطورون بإجراء التغييرات الخاصة بهم عملياً من تلقاء أنفسهم)
- مسلية قصص من الممارسة
من يهتم ، من فضلك ، تحت القط.
اسمي أليكسي فاخوف. أنا أعمل كمدير فني في Uchi.ru. نستضيف في الغيوم العامة. نحن نستخدم بنشاط Terraform ، Ansible. منذ ذلك الحين ، تحولنا بالكامل إلى Docker. راضي جدا كيف سعيد ، كيف نحن سعداء - سأقول.
يتمثل نشاط شركة Uchi.ru في إنتاج منتجات للتعليم المدرسي. لدينا منصة رئيسية يقوم الأطفال بحل المشكلات التفاعلية في مواضيع مختلفة في روسيا والبرازيل والولايات المتحدة الأمريكية. نجري أولمبياد الإنترنت والمسابقات والنوادي والمخيمات. كل عام هذا النشاط ينمو.
من وجهة نظر هندسية ، مكدس الويب الكلاسيكي (Ruby ، Python ، NodeJS ، Nginx ، Redis ، ELK ، PostgreSQL). الميزة الرئيسية هي أن العديد من التطبيقات. يتم استضافة التطبيقات في جميع أنحاء العالم. كل يوم هناك نشرات في الإنتاج.
الميزة الثانية هي أن مخططاتنا تتغير في كثير من الأحيان. يطلبون رفع تطبيق جديد ، إيقاف التطبيق القديم ، إضافة cron للوظائف الخلفية. كل أسبوعين هناك أولمبياد جديدة - هذا تطبيق جديد. كل ذلك ضروري لمرافقة ومراقبة والنسخ الاحتياطي. لذلك ، البيئة فائقة الديناميكية. الديناميكية هي الصعوبة الرئيسية لدينا.
وحدة العمل لدينا هي الموقع. من حيث مقدمي السحابة ، وهذا هو المشروع. موقعنا عبارة عن كيان منعزل تمامًا مع واجهة برمجة التطبيقات وشبكة فرعية خاصة. عندما ندخل البلاد ، فإننا نبحث عن موفري السحابة المحليين. ليس في كل مكان هناك جوجل والأمازون. يحدث أحيانًا عدم وجود واجهة برمجة تطبيقات لمزود الخدمة السحابية. ظاهريا ننشر VPN و HTTP و HTTPS للموازنات. جميع الخدمات الأخرى التواصل داخل السحابة.
لكل موقع أنشأنا مستودع Ansible الخاص بنا. يحتوي المستودع على hosts.yml ، و playbook ، و الأدوار ، و 3 مجلدات سرية ، والتي سأتحدث عنها لاحقًا. هذا هو terraform ، وتوفير ، التوجيه. نحن عشاق التوحيد. يجب أن يُطلق على مستودعنا دائمًا "اسم الموقع غير الصحيح". نحن توحيد كل اسم الملف ، الهيكل الداخلي. هذا مهم جدا لمزيد من الأتمتة.
لقد أنشأنا Terraform منذ عام ونصف ، لذلك نستخدمها. Terraform بدون وحدات ، بدون بنية ملف (يتم استخدام بنية مسطحة). بنية ملف Terraform: خادم واحد - ملف واحد ، إعدادات الشبكة وإعدادات أخرى. باستخدام terraform ، نقوم بوصف الخوادم ومحركات الأقراص والمجالات ودلو s3 والشبكات وما إلى ذلك. Terraform في الموقع تستعد بالكامل الحديد.
يقوم Terraform بإنشاء الخادم ، ثم تقوم المجموعة بلف هذه الخوادم. نظرًا لحقيقة أننا نستخدم نفس الإصدار من نظام التشغيل في كل مكان ، فقد كتبنا جميع الأدوار من البداية. عادة ما يتم نشر الأدوار غير المرئية على شبكة الإنترنت لجميع أنظمة التشغيل التي لا تعمل في أي مكان. أخذنا جميعًا أدوار Ansible ولم نترك سوى ما نحتاجه. أدوار غير قياسية موحدة. لدينا 6 قواعد اللعبة الأساسية. عند بدء التشغيل ، يقوم Ansible بتثبيت قائمة قياسية من البرامج: OpenVPN و PostgreSQL و Nginx و Docker. Kubernetes نحن لا نستخدمها.
نحن نستخدم القنصل + البدوي. هذه هي برامج بسيطة جدا. تشغيل 2 برامج مكتوبة في Golang على كل خادم. القنصل هو المسؤول عن اكتشاف الخدمة والفحص الصحي وقيمة المفتاح لتخزين التكوين. البدوي هو المسؤول عن الجدولة ، لبدء التشغيل. تقوم Nomad بإطلاق حاويات ، وتوفر لك النشرات ، بما في ذلك التحديث المستمر على الفحص الصحي ، إمكانية تشغيل حاويات جانبية. الكتلة سهلة التوسع أو العكس بالعكس. البدوي يدعم كرون الموزعة.
بعد دخولنا للموقع ، ينفذ Ansible كتاب اللعب الموجود في دليل التوفير. يعد playbook في هذا الدليل مسؤولاً عن تثبيت البرنامج في نظام عامل التشغيل الذي يستخدمه المسؤولون. قم بتثبيت برنامج بروميثيوس وغرافانا وبرنامج شامان السري.
شامان هي لوحة القيادة على شبكة الإنترنت لرحل. بدوي منخفض المستوى ولا أريد حقًا السماح للمطورين بالدخول إليه. في شامان نرى قائمة من التطبيقات ، ونحن نقدم للمطورين زر نشر للتطبيقات. يمكن للمطورين تغيير التكوينات: إضافة حاويات ، متغيرات البيئة ، بدء تشغيل الخدمات.
وأخيرًا ، يتم توجيه المكون النهائي للموقع. يتم تخزين التوجيه في تخزين K / V للقنصل ، أي أن هناك رابطًا بين المنبع ، والخدمة ، وعنوان url ، إلخ. على كل موازن ، هناك قالب قنصل يقوم بإنشاء تكوين nginx ويجعله إعادة التحميل. شيء موثوق للغاية ، لم يكن لدينا مشكلة في ذلك. الميزة في هذا المخطط هي أن حركة المرور تقبل nginx القياسي ويمكنك دائمًا معرفة التكوين الذي تم إنشاؤه ويعمل كما هو الحال مع nginx القياسي.
وبالتالي ، يتكون كل موقع من 5 طبقات. مع terraform ، نحن تخصيص الأجهزة. Ansible نحن ننفذ التكوين الأساسي للخوادم ، ووضع كتلة عامل الميناء. توفير القوائم برنامج النظام. التوجيه يوجه حركة المرور داخل الموقع. تحتوي التطبيقات على تطبيقات المستخدم وتطبيقات المسؤول.
قمنا بتصحيح هذه الطبقات لفترة طويلة حتى تكون متطابقة قدر الإمكان. توفير ، التوجيه مطابقة 100 ٪ بين المواقع. لذلك ، للمطورين ، كل موقع هو نفسه تماما.
إذا تحول متخصصو تكنولوجيا المعلومات من مشروع إلى آخر ، فسيقعون في بيئة نموذجية تمامًا. في إجابة ، لم نتمكن من جعل إعدادات جدار الحماية و VPN متطابقة مع مختلف مزودي خدمات السحاب. مع شبكة ، يعمل كل مزودي السحابة بشكل مختلف. Terraform في كل مكان خاص به ، لأنه يحتوي على تصميمات محددة لكل موفر سحابة.
لدينا 14 مواقع الإنتاج. السؤال الذي يطرح نفسه: كيفية إدارتها؟ لقد صنعنا الموقع الرئيسي الخامس عشر ، والذي نسمح فيه فقط للمشرفين. إنها تعمل على مخطط الاتحاد.
أخذت الفكرة من بروميثيوس. هناك وضع في بروميثيوس عندما نقوم بتثبيت بروميثيوس في كل موقع. نقوم بنشر Prometheus من خلال ترخيص HTTPS الأساسي للمصادقة. يقوم بروميثيوس ماستر بالتقاط المقاييس الضرورية فقط من بروميثيوس البعيد. هذا يجعل من الممكن مقارنة مقاييس التطبيق في السحب المختلفة ، والعثور على أكثر التطبيقات التي تم تنزيلها أو إلغاء تحميلها. ينتقل الإشعار المركزي (التنبيه) إلى سيد prometheus للمشرفين. تلقي المطورين تنبيهات من بروميثيوس المحلية.
يتم تكوين الشامان بنفس الطريقة. من خلال الموقع الرئيسي ، يمكن للمسؤولين نشر ، تكوين على أي موقع من خلال واجهة واحدة. نحن نحل فئة كبيرة بما فيه الكفاية من المشاكل دون مغادرة هذا الموقع الرئيسي.
سأخبرك كيف تحولنا إلى عامل ميناء. هذه العملية بطيئة جدا. عبرنا حوالي 10 أشهر. في صيف عام 2017 ، كان لدينا 0 حاوية إنتاج. في نيسان (أبريل) 2018 ، قمنا بإرساء وتطبيق أحدث تطبيق لدينا إلى الإنتاج.
نحن من عالم الياقوت على القضبان. كان هناك 99 ٪ من تطبيقات روبي أون ريلز. القضبان تتحرك من خلال Capistrano. من الناحية الفنية ، يعمل Capistrano على النحو التالي: يقوم المطور بإطلاق نشر cap ، ويذهب capistrano إلى جميع خوادم التطبيقات عبر ssh ، ويأخذ أحدث إصدار من الكود ، ويجمع عمليات ترحيل الأصول ، وقاعدة البيانات. يقوم Capistrano بعمل رابط للنسخة الجديدة من الكود ويرسل إشارة USR2 إلى تطبيق الويب. عند هذه الإشارة ، يلتقط خادم الويب رمزًا جديدًا.
لم يتم الخطوة الأخيرة في عامل ميناء مثل هذا. في عامل ميناء ، تحتاج إلى إيقاف الحاوية القديمة ، ورفع الحاوية الجديدة. هذا يطرح السؤال: كيفية تبديل حركة المرور؟ في عالم السحابة ، يكون اكتشاف الخدمة مسؤولاً عن هذا.
لذلك ، أضفنا القنصل إلى كل موقع. تمت إضافة القنصل لأنهم استخدموا Terraform. نحن ملفوفة جميع التكوينات nginx في قالب القنصل. من الناحية الرسمية ، نفس الشيء ، لكننا بالفعل كنا مستعدين لإدارة حركة المرور بشكل حيوي داخل المواقع.
بعد ذلك ، كتبنا نصًا روبيًا قام بجمع صورة على أحد الخوادم ، ودفعها إلى السجل ، ثم انتقل إلى كل خادم ، واكتسب خوادم جديدة وأوقف الحاويات القديمة ، وقام بتسجيلها في القنصل. استمر المطورون أيضًا في تشغيل ميزة نشر الحد الأقصى ، لكن الخدمات كانت تعمل بالفعل في عامل ميناء.
أتذكر أنه كان هناك نسختان من البرنامج النصي ، والثاني ظهر أنهما متقدمان للغاية ، كان هناك تحديث متواصل ، عندما توقف عدد صغير من الحاويات ، وارتفعت حاويات جديدة ، وانتظر القنصل هلفشيكي وانتقل.
ثم أدركوا أن هذا هو طريق مسدود. زاد البرنامج النصي إلى 600 سطر. الخطوة التالية في السقوط اليدوي حللنا محل البدوي. إخفاء تفاصيل العمل من المطور. وهذا هو ، ما زالوا يطلقون على نشر قبعة ، ولكن في الداخل كان بالفعل تكنولوجيا مختلفة تماما.
وفي النهاية ، نقلنا عملية النشر إلى واجهة المستخدم وأخذنا الوصول إلى الخادم ، تاركين زر النشر الأخضر وواجهة التحكم.
من حيث المبدأ ، تبين أن هذا الانتقال طويل بالطبع ، لكننا تجنبنا المشكلة التي التقيت بها عدة مرات.
هناك نوع من المكدس القديم أو النظام أو شيء من هذا القبيل. Khachennaya بالفعل فقط في اللوحات. يبدأ تطوير نسخة جديدة. بعد شهرين أو بضع سنوات ، اعتمادًا على حجم الشركة ، في الإصدار الجديد ، يتم تنفيذ أقل من نصف الوظائف الضرورية ، ولا يزال الإصدار القديم نجا. وهذه واحدة جديدة أصبحت أيضا إرث جدا. لقد حان الوقت لبدء إصدار جديد ثالث من البداية. بشكل عام ، هذه عملية لا نهاية لها.
لذلك ، نقوم دائمًا بتحريك المكدس بالكامل. في خطوات صغيرة ، ملتوية ، مع العكازات ، ولكن تماما. لا يمكننا الترقية على سبيل المثال ، عامل ميناء في موقع واحد. من الضروري التحديث في كل مكان ، إذا كانت هناك رغبة.
لفة عموميات. تقوم كل إرشادات عامل الإرساء بطرح 10 حاويات nginx أو 10 حاويات redis في حوض الإرساء. هذا مثال سيئ ، نظرًا لتجميع الصور بالفعل ، تكون الصور فاتحة. نحن حزم تطبيقاتنا القضبان في عامل ميناء. كان حجم الصور عامل ميناء 2-3 غيغا بايت. سوف يطفو على السطح بهذه السرعة.
المشكلة الثانية جاءت من شبكة محب. شبكة محب هي دائما جيثب فلو. في عام 2011 ، كانت هناك وظيفة صنع حقبة عهدها Github Flow ، وبالتالي فإن شبكة الويب كلها تتحرك. كيف تبدو؟ فرع ماستر هو دائما الإنتاج. عند إضافة وظائف جديدة ، نقوم بعمل فرع. عندما نقوم بعملية الدمج ، نراجع الكود ونجري الاختبارات ونرفع بيئة التدريج. الأعمال تبحث انطلاق محيط. في الوقت X ، إذا كان كل شيء ناجحًا ، فإننا ندمج الفرع بشكل رئيسي ونطرحه للإنتاج.
على capistrano ، هذا ما يرام ، لأنه تم إنشاؤه لهذا الغرض. عامل الميناء تبيع لنا دائما خط أنابيب. تجميعها الحاوية. يمكن نقل الحاوية إلى المطور ، واختبارها ، ونقلها إلى الإنتاج. ولكن في وقت الدمج في برنامج الماجستير ، كان الكود مختلفًا بالفعل. جميع صور عامل ميناء تم جمعها من فرع الميزة ، لم يتم جمعها من سيد.
كيف فعلنا ذلك؟ نقوم بجمع الصورة ووضعها في سجل عامل الميناء المحلي. وبعد ذلك نقوم ببقية العمليات: الهجرة ، نشر إلى الإنتاج.
لتجميع هذه الصورة بسرعة ، نستخدم Docker-in-Docker. على شبكة الإنترنت ، يكتب الجميع أن هذا هو نمط مضاد ، فإنه يتعطل. لم يكن لدينا شيء من هذا القبيل. كم من العمل بالفعل معه لم يكن لديه مشكلة. نعيد توجيه دليل / var / lib / docker إلى الخادم الرئيسي باستخدام وحدة التخزين الدائمة. جميع الصور الوسيطة موجودة على الخادم الأساسي. تجميع الصورة الجديدة يناسب في بضع دقائق.
بالنسبة لكل تطبيق ، نقوم بإنشاء سجل عامل إرساء داخلي وحجم الإنشاء الخاص بنا. لأن عامل الميناء يحفظ جميع الطبقات على القرص ويصعب تنظيفه. الآن نحن نعرف استخدام القرص لكل سجل عامل ميناء محلي. نحن نعرف مقدار القرص الذي يتطلبه. يمكنك تلقي تنبيهات من خلال Grafana المركزية ونظيفة. بينما نقوم بتنظيف أيديهم. لكننا سوف أتمتة ذلك.
نقطة أخرى. صورة عامل الميناء التي تم جمعها. الآن هذه الصورة تحتاج إلى أن تتحلل إلى خوادم. عند نسخ صورة كبيرة لرسو السفن ، لا تتعامل الشبكة. في السحابة لدينا 1 جيجابت / ثانية. هناك اغلاق عالمي في السحابة. الآن نحن ننشر صورة عامل ميناء إلى 4 خوادم الإنتاج الثقيلة. على الرسم البياني يمكنك رؤية القرص يعمل على حزمة واحدة من الخوادم. ثم يتم نشر الحزمة الثانية من الخوادم. أدناه يمكنك رؤية استخدام القناة. حوالي 1 جيجابت / ثانية نحن تقريبا سحب. لم يعد هناك الكثير من التسارع.
إنتاجي المفضل هو جنوب إفريقيا. هناك الحديد مكلفة للغاية وبطيئة. أربع مرات أكثر تكلفة مما كانت عليه في روسيا. هناك شبكة سيئة للغاية. الإنترنت مستوى المودم ، ولكن ليس عربات التي تجرها الدواب. هناك نطلق التطبيقات في غضون 40 دقيقة ، مع مراعاة ضبط التخزين المؤقت ومعلمات المهلة.
المشكلة الأخيرة التي كانت تقلقني قبل التواصل مع عامل الميناء كانت الحمل. في الواقع ، الحمل هو نفسه كما هو الحال دون عامل ميناء مع الحديد متطابقة. فارق بسيط فقط واجهنا نقطة واحدة فقط. إذا قمت بجمع السجلات من محرك Docker من خلال برنامج تشغيل fluentd المضمن ، عند تحميل حوالي 1000 rps ، يبدأ المخزن المؤقت fluentd الداخلي بالتناثر وتبدأ الطلبات في التباطؤ. أخرجنا قطع الأشجار في حاويات جانبية. في البدو ، وهذا ما يسمى سجل الشاحن. حاوية صغيرة معلقة بجانب حاوية تطبيق كبيرة. المهمة الوحيدة هي استلامه وإرساله إلى مستودع مركزي.
ما هي المشاكل / الحلول / التحديات. حاولت تحليل ما كانت المهمة. ميزات مشاكلنا هي:
- العديد من التطبيقات المستقلة
- تغييرات مستمرة في البنية التحتية
- تدفق جيثب وصور عامل ميناء كبير
حلولنا
- اتحاد مجموعات عمال الرصيف. من وجهة نظر التعامل مع الأمر صعب. ولكن عامل الميناء جيد في طرح وظائف العمل في الإنتاج. نحن نعمل مع البيانات الشخصية ولدينا شهادات في كل بلد. في موقع معزول ، من السهل تمرير هذه الشهادة. أثناء إصدار الشهادات ، تنشأ كل الأسئلة: من أين تستضيف ، كيف يكون لديك موفر سحابة ، وأين تقوم بتخزين البيانات الشخصية ، وأين يمكنك النسخ الاحتياطي ، ومن لديه حق الوصول إلى البيانات. عندما يتم عزل كل شيء ، يكون من الأسهل بكثير وصف دائرة المشتبه فيهم ومراقبة كل ذلك.
- الأوركسترا. من الواضح أن kubernetes. هو في كل مكان. لكنني أريد أن أقول إن Consul + Nomad هو الحل الإنتاج بالكامل.
- تجميع الصور. يمكنك إنشاء صور بسرعة في Docker-in-Docker.
- عند استخدام Docker ، فإن حمل حمولة 1000 دورة في الثانية أمر ممكن أيضًا.
متجه اتجاه التنمية
الآن إحدى المشاكل الكبيرة هي عدم تزامن إصدارات البرامج على المواقع. سابقا ، أنشأنا الخادم باليد. ثم أصبحنا المهندسين devops. الآن تكوين الخادم باستخدام ansible. الآن لدينا توحيد كامل ، توحيد. نحن نقدم التفكير العادي في الرأس. لا يمكننا إصلاح PostgreSQL بأيدينا على الخادم. إذا كنت بحاجة إلى نوع من الضبط على خادم واحد فقط ، فإننا نفكر في كيفية نشر هذا الإعداد في كل مكان. إذا لم تقم بالتوحيد القياسي ، فستكون هناك مجموعة من الإعدادات.
أنا مسرور وسعيد للغاية لأننا خرجنا من الصندوق مجانًا وبنية تحتية تعمل حقًا.
يمكنك إضافة لي في الفيسبوك. إذا فعلنا شيئًا جيدًا ، سأكتب عنه.
أسئلة:
ما فائدة قالب القنصل على قالب Ansible ، على سبيل المثال ، لتكوين قواعد جدار الحماية والمزيد؟
الجواب: الآن لدينا حركة المرور من الموازين الخارجية الذهاب مباشرة إلى الحاويات. لا يوجد أحد بينهما. يتم تكوين هناك لإعادة توجيه عناوين IP ومنافذ الكتلة. أيضا ، لدينا جميع إعدادات التوازن في K / V في القنصل. لدينا فكرة لإعطاء إعدادات التوجيه للمطورين من خلال واجهة آمنة حتى لا يكسروا أي شيء.
سؤال: فيما يتعلق بتجانس جميع المواقع. هل هناك حقا أي طلبات من رجال الأعمال أو من المطورين تحتاج إلى طرح شيء غير قياسي على هذا الموقع؟ على سبيل المثال ، تارانتول مع كاسندرا.
الجواب: هذا يحدث ، لكنه نادر جدًا. هذا نضع قطعة أثرية منفصلة الداخلية. هناك مثل هذه المشكلة ، لكنها نادرة.
السؤال: يتمثل الحل لمشكلة التسليم في استخدام سجل عامل ميناء خاص في كل موقع ، ومن هناك سريعًا بالفعل الحصول على صور عامل ميناء.
الإجابة: على أي حال ، سيتم تشغيل النشر في الشبكة ، نظرًا لأننا ننشر صورة عامل ميناء إلى 15 خادمًا هناك في وقت واحد. نحن نستريح ضد الشبكة. داخل الشبكة ، 1 جيجابت / ثانية.
السؤال: تستند العديد من حاويات الرصيف إلى نفس كومة التقنية تقريبًا؟
الجواب: روبي ، بيثون ، NodeJS.
السؤال: كم مرة تقوم باختبار أو التحقق من الصور عامل ميناء الخاص للحصول على التحديثات؟ كيف يمكنك حل مشاكل التحديث ، على سبيل المثال ، عندما تحتاج glibc ، openssl إلى إصلاح في كل عامل ميناء؟
الإجابة: إذا وجدت مثل هذا الخطأ ، والضعف ، فإننا نجلس لمدة أسبوع ونصلحه. إذا كنت بحاجة إلى البدء ، فيمكننا طرح السحابة بأكملها (جميع التطبيقات) من نقطة الصفر إلى الاتحاد. يمكننا النقر على جميع الأزرار الخضراء لنشر التطبيقات وترك لشرب الشاي.
سؤال: هل ستطلقون شامانك في مصدر مفتوح؟
الجواب: هنا أندريه (يشير إلى الشخص من الجمهور) يعدنا بوضع شامان في الخريف. ولكن هناك تحتاج إلى إضافة دعم ل kubernetes. يجب أن يكون المصدر المفتوح دائمًا أفضل.