مرحبا يا هبر! اسمي ديمتري ، أنا مطور في ISPsystem. لقد أصدرنا مؤخرًا اختبارًا تجريبيًا لإصدار جديد من لوحة التحكم في الجهاز الظاهري. اليوم سوف أخبرك كيف قررنا ما نأخذه من منتج قديم ، وما الأفضل رفضه. سأواجه أهم القضايا التي تواجهنا: مكتبة للعمل مع libvirt ، ودعم أنظمة التشغيل المختلفة أثناء تثبيت المنتج ، والانتقال من متراصة إلى الخدمات المصغرة ، ونشر الأجهزة الافتراضية.
المقالة حول برنامج
VMmanager . هذا هو نظام لإدارة ونشر ومراقبة الأجهزة الافتراضية على أساس KVM و OVZ الافتراضية. الجيل الخامس خرج في عام 2012. منذ ذلك الحين ، أصبحت الواجهة قديمة جدًا ، وحالت البنية المركزية دون تطوير المنتج. حان الوقت لعمل نسخة جديدة.
القصة الأولى. نحن نستخدم أعمال منزل الجان
العمل باستخدام libvirt: ضع في اعتبارك الخيارات ، وحدد المكتبات
كأداة لإدارة الظاهرية KVM ، يستخدم منتجاتنا libvirt. في عام 2012 ، تم اختيار مكتبة مكتوبة بلغة C لتعمل معها ، لذلك كانت أكثر ملائمة لفريق التطوير. نتيجة لذلك - هناك قدر كبير من الشفرة المكتوبة بلغة C ++ ، والتي تدعو إلى مكتبة C ، والتي تنفذ العمل المباشر مع libvirt.
والآن ، على عتبة مشروع جديد ، ننظر إلى الوراء ونفحص منتجنا ، وننظر فيما إذا كان الأمر يستحق اتخاذ حل / تكنولوجيا معينة ؛ ما أثبت نفسه وما يحتاج إلى أن نتذكره ولا يتكرر أبدًا.
نجلس ونقوم بأثر رجعي لسنوات عديدة من العمل على الإصدار السابق من المنتج. نتحلى بالصبر ونأخذ الملصقات ونكتب ثلاثة أنواع من الورق:
- ما الذي نجح في المنتج؟ ماذا المستخدمين الثناء؟ ما لم يسمع الشكاوى؟ ماذا اعجبك بنفسك
- ما فشل؟ ما هي المشاكل باستمرار؟ ما الذي أعاق العمل ، ولماذا بدأوا فرعا جديدا؟
- ما يمكن تغييره؟ ماذا يطلب المستخدمون؟ ماذا يريد أعضاء الفريق التغيير؟
يجب أن تشمل مجموعة الأشخاص الذين يفسدون الورقة بحماس كل من كان على اتصال وثيق بالمنتج لعدة قرون ، وأولئك الذين يمكنهم إلقاء نظرة جديدة على المنتج. لا تنسى طلب ميزة ومدير المنتج. يتم لصق الملصقات الجاهزة على اللوحة ، وسوف تساعدنا بالتأكيد.
العودة إلى القصة. نحن نفحص جزءًا من التعليمات البرمجية حيث يتعايش C ++ 98 القياسي بسلام مع مكالمات مكتبة C. نتذكر أن 2018 هو العام ونقرر تركه وحده. ولكن كيف نكرر وظيفة العمل مع الأجهزة الافتراضية (VMs) ، مما يجعل الكود أكثر إحكاما وسهولة في العمل؟
ندرس المشكلة ، ونفهم أنه بغض النظر عن الحل وبأي لغة نختارها ، سيكون ملفوفًا على مكتبة C. كخيار مثير للاهتمام ، تجدر الإشارة إلى
المكتبة الموجودة على Go من DigitalOcean ، فهي تستخدم بروتوكول RPC للتواصل مع libvirt مباشرة ، لكن به عيوبه. استقرنا على
مكتبة بايثون .
نتيجة لذلك ، حصلنا على سرعة كتابة التعليمات البرمجية وسهولة الاستخدام والقراءة. يجدر شرح هذه الكلمات الجميلة.
- السرعة . الآن يمكننا أن نضع نموذجًا سريعًا لجزء معين من العمل مع المجال مباشرةً من وحدة التحكم على خادم تصحيح الأخطاء ، دون إعادة إنشاء التطبيق الرئيسي.
- البساطة . بدلاً من استدعاء العديد من أساليب C ++ في معالج معين ، لدينا استدعاء البرنامج النصي Python مع تمرير المعلمة.
- التصحيح هو أيضا سريعة وغير مؤلمة قدر الإمكان. في رأيي ، يمكن أن يحمل هذا على المدى الطويل تجربة مستخدم مثيرة للاهتمام. تخيل ، مسؤول النظام ، غير سعيد لأن أجهزته الافتراضية تنتظر إيقاف التشغيل قبل إتلافها ، وتعيد تعريف البرنامج النصي لأسلوب host_stop.
هل يمكنني أيضًا كتابة لوحة لك؟
نتيجة لذلك ، حصلنا على أداة بسيطة ومريحة للعمل مع الأجهزة الافتراضية على مستوى الخادم.
القصة الثانية. المنتج المعبأ جيدًا لا يحتاج إلى عناق إضافي
توزيع المنتج: نحن نرفض من العديد من الحزم ونمر إلى Docker
يتم توزيع VMmanager 5 كمجموعة من حزم linux. يتم دعم CentOS 6/7 ، وحتى وقت قريب ، Debian 7. ماذا يعني هذا؟ هذا يعني المزيد من خوادم التصميم لـ CI / CD ، والمزيد من الاختبارات ، والمزيد من الاهتمام للرمز. يجب أن نتذكر أنه في المستودع الرسمي لإصدار CentOS 7 qemu 1.5.3 ، في CentOS 6 يكون 0.12.1. في الوقت نفسه ، يمكن للمستخدم استخدام المستودعات التي يكون إصدار هذه الحزمة فيها أعلى من ذلك بكثير. هذا يعني أنك تحتاج إلى دعم إصدارات مختلفة من api عند العمل مع VMs ، على وجه الخصوص ، أثناء الترحيل. يجب أن نتذكر الفرق بين المُهيئات (init ، systemd) ، مع مراعاة الفرق في أسماء الحزم والأدوات المساعدة. لن تعمل تلك الأدوات المساعدة التي تعمل على CentOS على دبيان ، أو تختلف إصداراتها في المستودعات الرسمية على نطاق واسع. لكل دفعة ، تحتاج إلى جمع الحزم لجميع الإصدارات ، وينصح بعدم نسيان اختبارها أيضًا.
كل هذا في المنتج الجديد لا يناسبنا. لكي لا ندعم منطقًا مختلفًا ، نتخلى عن عدة أنظمة ونترك CentOS 7. هل تم حل المشكلة؟ ليس حقا
لا نريد أيضًا التحقق من إصدار نظام التشغيل قبل التثبيت ، ما إذا كانت الأدوات المساعدة الضرورية متوفرة ، وما هي القواعد المثبتة في SELinux ، ولا نريد إعادة تكوين جدار الحماية وقوائم المستودعات. أود مرة واحدة - وهذا كل شيء ، من خلال النقر
لتدمير كل ثانية لنشر البيئة بأكملها والمنتج نفسه. يقال - فعلت ، يتم التفاف المشروع في حاوية عامل ميناء.
الآن يكفي القيام بما يلي:
الفريق يعمل.
بالطبع ، أنا أبالغ ، يجب على المستخدم تثبيت Docker لنفسه ، ولدينا أكثر من حاوية واحدة ، ويعمل VMmanager حاليًا في وضع سرب كخدمة SaaS. حول ما واجهناه عند اختيار Docker ، وكيفية حلها ، يمكنك كتابة مقالة منفصلة.
الحقيقة نفسها هي مدى أهمية تبسيط عملية التطوير ، والأهم من ذلك ، نشر منتجك ، install.sh الذي كان يشغل ذات مرة
2097 سطرًا .
نتيجة لذلك:
- تعمل بيئة تثبيت المنتج المتجانسة على تبسيط رمز البرنامج وتقليل تكاليف التجميع والاختبار.
- توزيع التطبيق كحاوية لرسو السفن يجعل عملية النشر بسيطة ويمكن التنبؤ بها.
القصة الثالثة. العلاقة الأولى مع microservices
العمارة: نتخلى عن المتراصة لصالح الخدمات الصغيرة ، أم لا
الإصدار الخامس من المنتج هو نظام متراصة كبير مع معيار C ++ عفا عليه الزمن. ونتيجة لذلك ، فإن إشكالية التنفيذ للتقنيات الجديدة وصعوبة إعادة صياغة الكود القديم ، والقياس الأفقي الضعيف. في الفرع الجديد ، قرروا استخدام نهج الخدمة المجهرية كواحدة من الطرق لتجنب مثل هذه المشاكل.
Microservices هي الاتجاه الحديث الذي يحتوي على كل من الإيجابيات والسلبيات. سأحاول تقديم رؤيتي لنقاط القوة في هذا الهيكل والتحدث عن حل المشاكل التي يجلبها المشروع. تجدر الإشارة إلى أن هذه ستكون أول نظرة على بنية الخدمات المصغرة من الناحية العملية من جانب مطور عادي. يتم تغطية الجوانب التي ربما لن أذكرها في
مقال مراجعة جيد .
الجانب الإيجابي
خدمة صغيرة يعطي العديد من الفرص.بالإضافة إلى راحة الكتابة والاختبار والتصحيح ، أدخلت خدمات microservices لغة برمجة جديدة للمشروع. عندما يكون مشروعك مترابطًا ، من الصعب أن تتخيل أنك ستحاول يومًا ما إعادة كتابة جزء منه بلغة أخرى تهمك. في الهندسة المعمارية microservice - من فضلك. بالإضافة إلى لغة البرمجة ، يمكنك أيضًا تجربة التقنيات الجديدة ، مع التحذير الوحيد الذي يبرر كل هذا للعمل. على سبيل المثال ، كتبنا بعض الخدمات المصغرة في Golang ، مع توفير قدر لا بأس به من الوقت.
تحجيم الفريقيمكننا تقسيم العديد من الأشخاص الذين اعتادوا الالتزام بمستودع واحد وحاولوا الحفاظ على هيكل المتراصة في رؤوسهم في عدة فرق. سيشارك كل فريق في خدمته. بالإضافة إلى ذلك ، يكون دخول شخص جديد إلى العمل أكثر بساطة وأسرع ، بسبب السياق المحدود الذي سيعمل فيه. من ناحية أخرى ، هناك عدد أقل من مجمعي المعرفة العالمية ، والذين يمكن التعرف عليهم دائمًا حول أي جانب من جوانب نظام ضخم. ربما في الوقت المناسب سوف أعيد النظر في موقفي لهذه النقطة.
تدهور مستقلأود أن أرجع التدهور المستقل إلى كلا الجانبين الإيجابي والسلبي لخدمات micros ، لأن من يحتاج إلى التطبيق الخاص بك إذا كان ، على سبيل المثال ، يكمن في خدمة ترخيص؟ ومع ذلك ، لا يزال هذا الجانب الإيجابي. في السابق ، جمع الإحصائيات من عدة مئات من الأجهزة الافتراضية جعل عملنا مترابطًا بجد ، في وقت ذروة التحميل ، زاد انتظار طلب المستخدم زيادة كبيرة. يمكن لخدمة تجميع الإحصائيات المنفصلة جمعها دون التأثير على الخدمات الأخرى ، بينما لا يزال من الممكن زيادتها عن طريق إضافة أجهزة جديدة أو عن طريق زيادة عدد جامعي الإحصاءات نفسها. ويمكننا حتى تحديد خادم منفصل لجرافيت ، حيث تسجل هذه الخدمة الإحصاءات. مع متراصة ، حيث توجد قاعدة واحدة ، هذا مستحيل.
الجانب السلبي
طلب السياقجاءت كل ما عندي من تصحيح الأخطاء في متراصة إلى اثنين من الاستعلامات في وحدة التحكم:
انتهى يمكنني تتبع الطلب بأكمله ، من استلامه إلى النظام حتى يحدث خطأ.
ولكن ماذا عن الآن ، عندما ينتقل الطلب من الخدمة الصغيرة إلى الخدمة الصغيرة ، مصحوبة بمكالمات إضافية للخدمات والسجلات المجاورة في قواعد بيانات مختلفة؟ للقيام بذلك ، قمنا بتطبيق معلومات الطلب ، والتي تحتوي على معرف الطلب ومعلومات حول المستخدم أو الخدمة التي أنتجت ذلك. لذلك يصبح من الأسهل تتبع سلسلة الأحداث بأكملها ، لكن الرغبة تأتي لكتابة خدمة تجميع السجلات ، لأننا ، بعد كل شيء ، لدينا بنية خدمات ميكروية. يمكنك أيضًا البحث عن Elasticsearch ، هذه المشكلة مفتوحة وسيتم حلها قريبًا.
عدم تناسق البياناتالبيانات في microservices غير مركزية ، لا توجد قاعدة بيانات واحدة يتم فيها تخزين جميع المعلومات. عند التفكير في هذا المقال ، تخطّيت التفاعلات الرئيسية بين خدمات microservices في ذهني - حيث يمكننا الحصول على التكرارات ، حيث نستخدم المعاملات عبر الإنترنت - وأدركت أننا حلنا مشكلة عدم الاتساق مع متراصة.
لقد بنينا حقًا متراصة مع قاعدة رئيسية واحدة ، حيث قمنا بتغطية معظم إجراءات المعاملات فيه. وحول المتراصة تم جمع جميع الخدمات المصغرة التي لا تؤثر على تناسق البيانات الرئيسية. الاستثناء هو مجموعة من ترخيص الخدمة + متراصة. المشكلة في هذه الحالة هي أن قاعدة بيانات التطبيق الأساسي لا تحتوي على مستخدمين على هذا النحو ، وأدوارهم ومعلمات إضافية ، كل هذا في خدمة التخويل.
يمكن لمستخدم النظام العمل مع الأجهزة الافتراضية في كتلة واحدة ، بينما في خدمة التفويض قد تتغير حقوقه ، أو سيتم حظره تمامًا. يجب أن يستجيب النظام لهذا في الوقت المناسب. في هذه الحالة ، يتم تحقيق تناسق البيانات عن طريق التحقق من معلمات المستخدم قبل تنفيذ أي طلب.
بالنسبة إلى الخدمات المصغرة المتبقية ، فإن عدم القدرة على التسجيل في خدمة الإحصائيات لا يؤثر على تشغيل الجهاز الظاهري ، ويمكن تكرار هذا الإجراء دائمًا. حسنًا ، نحن نقوم بعمل خدمة لجمع الإحصائيات. لكن خدمة تعريف المجال (إنشاء جهاز افتراضي باستخدام libvirt) لن ترى النور أبدًا ، نظرًا لأن من يحتاج إلى فراغ من الجهاز دون وجوده الفعلي.
القصة الرابعة. الطازج هو عدو الخير
نشر VM: التثبيت من الصور بدلاً من التثبيت عبر شبكة
في الإصدار الخامس من المنتج ، يستغرق نشر جهاز افتراضي وقتًا طويلاً بمعايير حقيقية. السبب في ذلك هو تثبيت نظام التشغيل عبر الشبكة.
بالنسبة إلى Centos و Fedora ، RedHat هي
طريقة البداية :
1. إنشاء ملف بدء التشغيل.
2. حدد الرابط إلى ملف الاستجابة في معلمات kernel linux inst.ks = <link to the kickstart file>.
3. قم بتشغيل التثبيت kickstart.
Kickstart-file مرن للغاية ، حيث يمكنك وصف جميع خطوات التثبيت ، بدءًا من طريقته وتحديد المنطقة الزمنية ، وتنتهي بتقسيم القرص وإعداد الشبكة. تشير معلمة url في قوالبنا إلى أن التثبيت من خادم بعيد.
بالنسبة إلى دبيان وأوبونتو ، طريقة ما قبل التشغيل:
إنه مشابه للطريقة السابقة ، وهذه الطريقة مبنية أيضًا على ملف التكوين ومحتوياته. في ذلك ، نحن أيضا تكوين التثبيت عبر الشبكة.
يشبه التثبيت لـ FreeBSD ، ولكن بدلاً من ملف بدء التشغيل ، يوجد نص برمجي من إنتاجنا.
الجوانب الإيجابية للنهج
يتيح لك خيار التثبيت هذا استخدام قالب واحد في منتجينا: VMmanager و
DCImanager (إدارة الخوادم المخصصة).
يتميز نشر الأجهزة الافتراضية بمرونة كبيرة ، حيث يمكن لمسؤول اللوحة ببساطة نسخ قالب نظام التشغيل وتغيير ملف التكوين كما يراه مناسبًا.
لدى جميع المستخدمين دائمًا إصدارات محدثة من أنظمة التشغيل إذا تم تحديثها في الوقت المناسب على خادم بعيد.
الجانب السلبي
كما أوضحت الممارسة ، لم يكن مستخدمو VMmanager بحاجة إلى مرونة في التثبيت: بالمقارنة مع الخوادم المخصصة ، قلقة من الناس بشأن إعدادات ملفات بدء التشغيل المحددة للأجهزة الافتراضية. ولكن في انتظار تثبيت نظام التشغيل كان حقا ترفا غير مقبول. الجانب الآخر من أهمية أنظمة التشغيل هو أن جزءًا من المثبت موجود على الشبكة ، والجزء محلي
للبدء . ويجب أن تتطابق إصداراتها.
هذه مشاكل قابلة للحل. يمكنك إنشاء مجموعة من الأجهزة المثبتة وإنشاء مستودع خاص بك لأنظمة التشغيل ، ولكن هذا يتطلب تكاليف إضافية.
كيفية حل هذه المشكلات دون إنشاء مستودعات وتجمعات؟ اخترنا ملفات صور نظام التشغيل. الآن تبدو عملية التثبيت كما يلي:
1. نسخ صورة نظام التشغيل إلى قرص الجهاز الظاهري.
2. قم بزيادة القسم الرئيسي من الصورة بحجم المساحة الحرة بعد النسخ.
3. الإعداد الأساسي (إعداد كلمة مرور ، والمنطقة الزمنية ، وما إلى ذلك).
كل ما هو جديد قديم طي النسيان. استخدمنا صور نظام التشغيل في VDSmanager-Linux ، سلف برنامج VMmanager.
ولكن ماذا عن مرونة التثبيت؟ أظهرت الممارسة أن معظم المستخدمين لا يهتمون بإعدادات محددة للشبكة وتعيين القرص على الأجهزة الافتراضية.
وأهمية البيانات؟ يمكن تحقيق ذلك من خلال وجود صور مع أحدث إصدارات نظام التشغيل في المستودع ، ويمكن تثبيت تحديثات بسيطة في البرنامج النصي للتكوين الأولي. وبالتالي ، سيتم إنشاء الجهاز الظاهري وتشغيله بالفعل ، والوصول إليه ، ستجد تحديث yum المشروط قيد التشغيل.
في المقابل ، نحصل على آلة افتراضية جاهزة ، يعتمد نشرها فقط على نسخ القرص ، وزيادة قسم القرص وبدء نظام التشغيل. يتيح لنا تنفيذ هذا النهج للعمل مع الآلات الفرصة لإنشاء صورنا الخاصة ومشاركتها. يمكن للمستخدم تثبيت حزمة
LAMP أو بعض البيئة المعقدة على الجهاز الظاهري ، ثم إنشاء صورة لهذا الجهاز. الآن ، لن يضطر الأشخاص الآخرون إلى إضاعة الوقت في تثبيت الأدوات الضرورية.
طبقنا تكوين وتعديل الأقسام باستخدام الأدوات المساعدة من
مجموعة libguestfs . على سبيل المثال ، تحول تغيير كلمة المرور على جهاز linux من 40 سطرًا من التعليمات البرمجية ، تتكون من mount و chroot و usermod ، إلى سطر واحد:
command = "/usr/bin/virt-customize --root-password password:{password} --domain '{domain_name}'".format(password=args.password, domain_name=args.domain_name)
نتيجة لذلك ، جعلنا الحصول على الجهاز الظاهري الانتهاء بأسرع وقت ممكن. تجدر الإشارة إلى أنه مع إعداد الشبكة وتثبيت البرامج النصية الداخلية ، زاد وقت النشر قليلاً. لقد حللنا هذه المشكلة من خلال عرض خطوات التثبيت على الواجهة الأمامية ، وبالتالي ملء الإيقاف المؤقت الذي تم إنشاؤه بين الإنشاء والاستعداد الكامل للجهاز.
لقد حصلنا أيضًا على نهج أكثر مرونة في نشر الأجهزة الافتراضية ، استنادًا إلى أنه من المناسب إنشاء صورك الخاصة مع البيئة اللازمة.
ماذا تمكنت من القيام به
في الإصدار السادس من المنتج ، حاولنا أن نأخذ في الاعتبار العيب الرئيسي للمنتج الخامس: مدى تعقيد تفاعل المستخدم مع المنتج. لقد قللنا من مهلة الإجراءات الرئيسية. إلى جانب واجهة خالية من الحظر ، يتيح ذلك العمل مع اللوحة دون انتظار قسري. جعلت Containerization عملية تثبيت المنتج أسهل وأكثر راحة. لقد أدى استخدام التقنيات الحديثة ولغات البرمجة المختلفة إلى تبسيط الدعم والصيانة لكل من المبرمجين ومتخصصي الدعم الفني. أتاح التحول إلى الخدمات الصغيرة إضافة ميزات جديدة بسرعة وبدون قيود طفيفة.
في الختام ، أود أن أقول إن المنتج الجديد يمثل فرصة جيدة لتجربة أساليب تطوير أخرى ، وتقنيات جديدة. تجدر الإشارة إلى سبب قيامك بذلك ، ما الأشياء الجديدة التي ستجلبها لك وللمستخدمين. الذهاب لذلك!
ندعو مجتمع Habr لرؤية النسخة التجريبية من VMmanager 6 وترك ملاحظاتك. للقيام بذلك ، انتقل إلى my.saasvm.com ، وقم بتسجيل الدخول وتوصيل خادم مخصص (CentOS 7 x64 ، والوصول إلى الإنترنت ، وعنوان IP العام).
إذا لم يكن لديك خادم ، أو مراسلتنا على help@ispsystem.com أو الدردشة على الموقع ، فسوف نقدم معدات الاختبار من شريكنا ، Selectel.
اقرأ المزيد في الأخبار على موقع ISPsystem .