أوركسترا الأداء

ولن يكون من الخطأ القول بأن أفضل الرجال
العثور على الفرح من خلال المعاناة.
لودفيج فان بيتهوفن

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

لماذا نحتاج إلى قائد في فريقنا؟

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

لا يختلف دورهم عن دور القائد في الموسيقى - فهم ضروريون لمساعدة الفريق وتوجيه وتنظيم اللعب.

كقاعدة عامة، يمتلك الفريق مجموعة معينة من القدرات - دعنا نسميها الخوادم - التي ينفذون مشاريعهم عليها.

يتنوع أسلوب الحصول على هذه الخوادم وتشغيلها. بعض الأمثلة:

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

يستخدم فريقنا الخوادم التي تحتاج إلى الدعم - تحديث نظام التشغيل، تثبيت حزم جديدة، وما إلى ذلك.

بالنسبة لأنفسنا، قسمناهم إلى نوعين رئيسيين:

• مجموعة الدبابات,
• مجموعة الخدمة.

تتكون مجموعة الدبابات من مضيفين مع Yandex.Tank.

تتضمن مجموعة الخدمات كل ما يتعلق بالصيانة - وهي خدمات متنوعة لتوفير الدعم لدورة الإصدار وإنشاء التقارير التلقائية وما إلى ذلك.

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

لماذا نحتاج إلى قائد فرقة موسيقية، حتى لو كانت الأوركسترا نفسها قادرة على العزف؟

في البداية، أتقننا Ansible وبدأنا في "صب" خوادمنا المعدنية لكي نكون أقل اعتمادًا على مسؤولي النظام - الجميع يفوز هنا، ونكتسب مهارات جديدة ونريح المسؤولين من بعض الأعمال التي لديهم دائمًا ما يكفي بدوننا . نحن نسعى جاهدين للتطوير بما يتجاوز تخصصنا واستقلالية الفريق قدر الإمكان.

في الشركة، تم تهيئة وتنظيم العمل مع Ansible لفترة طويلة، لذلك قمنا بسهولة بدمج حلنا في هذه العملية.

حاليًا، يتكون تجمع المضيفين من ثلاثة أدوار Ansible:

• الدور الأول يقوم بتثبيت نظام التشغيل،
• أما الثاني فيقوم بتشغيل الإعدادات الأساسية للمضيف، تفويض LDAP، على سبيل المثال،
• والثالث يقوم بتثبيت Yandex.Tank والتبعيات ذات الصلة في حاوية عامل الإرساء.

دعنا ننتقل إلى الخدمات التي نستخدمها داخل الفريق.

بالنسبة لمهامنا، نستخدم Kotlin وPython بالتساوي، وأكثر قليلاً من Golang. لتوحيد تطوير ونشر خدماتنا، قررنا تجميعها في حاويات Docker. يمنحك هذا حرية اختيار لغة برمجة وفي نفس الوقت ينظم تنسيق تسليم موحد لتطبيقك.

ملاحظة صغيرة حول IPv6 في Docker

بعض الخدمات التي نتفاعل معها متاحة فقط عبر IPv6، لذلك كان علينا معرفة كيفية إنشاء IPv6 للحاويات.

وفقًا لوثائق ipv6 على موقع Docker الرسمي، يتم تمكين IPv6 عن طريق إضافة معلمات إلى daemon.json:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

في هذه الحالة، يجب على الموفر إصدار شبكة فرعية ipv6، والتي ستقوم بالتسجيل فيها fixed-cidr-v6.
ومع ذلك، اخترنا خيارًا آخر - ipv6 NAT، وإليكم السبب:

• الآن عامل ميناء لا يمكن استخدام فقط مع IPv6.
• إن وجود عنوان قابل للتوجيه عالميًا في كل حاوية يعني أن جميع المنافذ (حتى تلك غير المنشورة) مكشوفة للجميع ما لم يتم إجراء تصفية إضافية.
• وكيل Userland لمنافذ النشر، iptables فقط لـ ipv4.

IPv6 NAT هو حاوية عامل ميناء، الذي يدير بنفسه القواعد في ip6tables ويحررها عند إضافة حاوية جديدة.

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

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)

تم حل المشكلة بعد إضافة التهيئة إلى الدور Ansible باستخدام الوحدة modprobe وتحميله عند بدء تشغيل نظام التشغيل باستخدام lineinfile:

- name: Add ip6table_nat module
 modprobe:
   name: ip6table_nat
   state: present
- name: Add ip6table_nat to boot
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

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

لكن لنعد إلى سؤالنا الذي طرحناه في البداية:
لماذا نحتاج إلى قائد فرقة موسيقية، حتى لو كانت الأوركسترا نفسها قادرة على العزف؟

الآن يتخيل الجميع كيفية اللعب في فريقنا:

• تم إنشاء عملية "صب" الخوادم،
• يتم توحيد تطوير ونشر الخدمات.

يطرح سؤال معقول - كيفية نشر خدماتنا وتحديثها والتحكم فيها في حاويات Docker بكفاءة وتلقائية قدر الإمكان؟

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

كيفية الحصول على موصل جيد مع الحد الأدنى من الاستثمار؟

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

قنصل - نظام يوفر وظيفتين رئيسيتين:

• اكتشاف الخدمة,
• تخزين القيمة الرئيسية الموزعة.

في فرقتنا الموسيقية، سيكون القنصل مسؤولاً عن تسجيل الخدمات وتخزين تكويناتها. هناك خياران للتسجيل:

• يكون نشطًا عندما تسجل الخدمة نفسها باستخدام HTTP API؛
• سلبي - يجب تسجيل الخدمة يدويًا.

Vault هو مستودع يعمل على توحيد وتوحيد التخزين الآمن والتعامل مع الأسرار - كلمات المرور والشهادات.
فيما يلي الفوائد التي سنحصل عليها باستخدام هذه الأداة:

• مركز واحد لإنشاء وتخزين الأسرار وإدارة دورة حياتها باستخدام HTTP API.
• Transit Secrets Engine - تشفير وفك تشفير البيانات دون حفظها. القدرة على نقل البيانات بشكل مشفر عبر قنوات اتصال غير آمنة.
• سياسات الوصول التي يسهل تكوينها.
• تدقيق الوصول إلى الأسرار.
• القدرة على إنشاء CA (المرجع المصدق) الخاص بك لإدارة الشهادات الموقعة ذاتيًا داخل البنية الأساسية لديك.

بالنظر إلى جميع متطلباتنا، كان هناك خياران مناسبان لدور الموصل - Kubernetes و Nomad.

Kubernetes

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

بدوي

أداة من شركة HashiCorp المعروفة بالقنصل والقبو المذكورين أعلاه.

لقد وجدنا أن Nomad أسهل في التثبيت والتكوين من Kubernetes. يعمل ملف ثنائي واحد في كل من وضع الخادم والعميل. وفي الوقت نفسه، يغطي Nomad القائمة الكاملة للمهام التي نريد أن يحلها: إدارة المجموعات، والجدولة السريعة، ودعم مراكز البيانات المتعددة. بالإضافة إلى ذلك، عند استخدام consul وvault، نحصل على تكامل أكثر صرامة لتنسيق خدماتنا.

ما يجري حاليا:

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

سؤال للجمهور: هل يستحق تعيين قائد لمثل هذه المهام أم أن الأوركسترا تعمل بشكل جيد بدونه؟ أخبرنا في التعليقات عن رأيك في هذا الأمر.

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

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

المصدر: www.habr.com