من الخطأ أن نقول إن أفضل ما في الناس
كسب الفرح من خلال المعاناة.
لودفيج فان بيتهوفن
أنا سيرجي ، أعمل في Yandex.Money في فريق أبحاث الأداء. أريد أن أخبركم ببداية قصة عن طريقنا إلى استخدام الأوركسترا - كيف اخترنا الأدوات وما أخذناه في الاعتبار. جميع الأحداث من هذه المادة تحدث في الوقت الحقيقي ، لذلك أنت ، أيها القراء الأعزاء ، تتبع تطور الوضع بشكل شبه مباشر.
لماذا نحتاج إلى موصل في الفريق؟
من هو موصل؟ من الاب. diriger - إدارة ، توجيه ، الرصاص - في عالم الموسيقى - هذا هو الشخص ، زعيم التعلم والأداء للموسيقى الفرقة. في حالتنا ، يشغل هذا المكان أنظمة الأوركسترا والأتمتة.
لا يختلف دورهم عن دور الموصل في الموسيقى - فهناك حاجة لمساعدة الفريق وتوجيه وتنظيم لعبه.
كقاعدة عامة ، يتمتع الفريق بمجموعة معينة من القدرات - دعنا نسميهم خوادم يقومون بتنفيذ مشاريعهم عليها.
نهج الحصول على هذه الخوادم وتشغيلها متنوع. بعض الأمثلة:
- يقدم الفريق طلبًا ، على سبيل المثال ، إلى مجموعة العمليات ، لتزويدهم بالموارد مع معلمات معينة.
- توفر لهم مجموعة التشغيل الكمية المطلوبة - السحابة أو المعدن العاري ("المعدن العاري") - وتتعهد بالحفاظ عليها في حالة جيدة وفقًا لاتفاقية مستوى الخدمة. يتم إجراء التعديل أيضًا بواسطة فريق العمليات.
- يتلقى الفريق الموارد السحابية أو المعدنية فقط من مجموعة العمليات ؛ إنه يقوم بإعداداته الخاصة.
- الفريق نفسه "يشتري" الموارد ويدعمها / يهيئها بشكل مستقل تمامًا.
يستخدم فريقنا الخوادم التي تحتاج إلى الدعم - تحديث نظام التشغيل ، تثبيت حزم جديدة ، إلخ.
بالنسبة لأنفسنا ، قمنا بتمييزها في نوعين رئيسيين:
- مجموعة دبابات
- مجموعة الخدمات.
تتكون مجموعة الخزان من مضيفين مع Yandex.Tank.
تتضمن مجموعة الخدمات كل ما يتعلق بالصيانة - هذه هي خدمات متنوعة لتوفير الدعم لدورة الإصدار ، وإنشاء تقارير تلقائية ، إلخ.
في مرحلة ما ، أصبح من غير المريح إدارة كل هذا يدويًا ، وفكرنا في أتمتة العملية برمتها ، بدءًا من "تحميل" الخوادم وانتهاءً بتطوير وتخطيط وإطلاق خدماتنا الداخلية.
لماذا هناك حاجة إلى موصل ، حتى لو كانت الأوركسترا نفسها تستطيع اللعب؟
بادئ ذي بدء ، لقد أتقنا Ansible وبدأنا في "سكب" خوادمنا المعدنية العارية لتكون أقل اعتمادًا على مسؤولي النظام - فالجميع يفوز هنا ، ونكتسب مهارات جديدة ونريح المسؤولين عن جزء العمل الذي لديهم دائمًا بدوننا. نحن نسعى جاهدين لتطوير فريقنا خارج تخصصنا واستقلالنا قدر الإمكان.
تعمل الشركة مع Ansible منذ فترة طويلة على الإعداد والتنظيم بالفعل ، لذلك قمنا بدمج حلنا بسهولة في هذه العملية.
استضافة الآن يتكون من ثلاثة أدوار Ansible:
- الدور الأول بتثبيت نظام التشغيل ،
- لفات الثانية الإعدادات الأساسية للمضيف ، إذن LDAP ، على سبيل المثال ،
- والثالث بتثبيت Yandex.Tank والتبعيات ذات الصلة في حاوية عامل ميناء.
دعنا ننتقل إلى الخدمات التي نستخدمها داخل الفريق.
لمهامنا ، نحن نستخدم Kotlin و Python بالتساوي ، وأكثر من ذلك بقليل Golang. لتوحيد تطوير ونشر خدماتنا ، قررنا تعبئتها في حاويات السفن. وهذا يمنح حرية اختيار لغة البرمجة وينظم في نفس الوقت نسق التسليم الموحد لتطبيقه.
تتوفر بعض الخدمات التي نتفاعل معها فقط عبر ipv6 ، لذلك اضطررت إلى معرفة كيفية صنع ipv6 للحاويات.
وفقًا لوثائق ipv6 على موقع Docker الرسمي ، يتم تمكين ipv6 عن طريق إضافة معلمات إلى daemon.json:
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
في هذه الحالة ، يجب على الموفر إصدار الشبكة الفرعية ipv6 ، والتي ستقوم fixed-cidr-v6. في 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'
بالمناسبة ، هناك مقال جيد حول Haber ، والذي يصف باختصار وبشكل واضح مزايا وعيوب طريقة معينة للعمل مع ipv6 في عامل ميناء.
ولكن العودة إلى سؤالنا طرح في البداية:
لماذا هناك حاجة إلى موصل ، حتى لو كانت الأوركسترا نفسها تستطيع اللعب؟
الآن يعرف الجميع كيفية اللعب في فريقنا:
- عملية "ملء" الخوادم التي تم إنشاؤها ،
- تطوير ونشر الخدمات موحدة.
يطرح سؤال معقول - كيفية نشر خدماتنا وتحديثها والتحكم فيها في حاويات الرصيف بكفاءة وأتمتة قدر الإمكان؟
على الرغم من حقيقة أن كل عضو في الأوركسترا يعرف دوره ، إلا أنه يمكن أن يضل وينتقل عن الفكرة الأصلية. لقد توصلنا إلى حقيقة أنه بدون موصل لن تقوم أوركسترانا بالتمرين بشكل فعال واللعب بشكل متناغم. موصل هو المسؤول عن جميع معايير الأداء ، لضمان أن يتم توحيد كل شيء من قبل وتيرة واحدة والمزاج.
كيفية الحصول على موصل جيد مع الحد الأدنى من الاستثمار؟
تم تطوير موضوع الأوركسترا بشكل جيد في السوق. لكن أولاً ، دعنا نتحدث عن الأدوات الداعمة التي يمكن أن تساعد الموصل.
القنصل هو نظام يوفر وظيفتين رئيسيتين:
- اكتشاف الخدمة
- تخزين القيمة الرئيسية الموزعة.
في الأوركسترا لدينا ، سيكون القنصل مسؤولاً عن تسجيل الخدمات وتخزين التكوينات الخاصة بها. هناك خياران للتسجيل:
- نشط - هذا عندما تسجل الخدمة نفسها باستخدام HTTP API ؛
- السلبي - يجب تسجيل الخدمة يدويا.
Vault هو مستودع يعمل على توحيد وتوحيد التخزين الآمن والعمل مع الأسرار - كلمات المرور والشهادات.
فيما يلي الفوائد التي سنحصل عليها باستخدام هذه الأداة:
- مركز واحد لإنشاء الأسرار وحفظها ، وإدارة دورة حياتها من خلال واجهة برمجة تطبيقات HTTP.
- Transit Secrets Engine - تشفير وفك تشفير البيانات دون حفظها. القدرة على نقل البيانات في شكل مشفر من خلال قنوات الاتصال غير المضمونة.
- سياسات الوصول المناسبة للتكوين.
- مراجعة الوصول إلى الأسرار.
- القدرة على إنشاء المرجع المصدق الخاص بك (شهادة المرجع) لإدارة الشهادات الموقعة ذاتيا داخل البنية التحتية الخاصة بك.
النظر في جميع متطلباتنا ، خيارين يناسب دور موصل - Kubernetes و Nomad.
Kubernetes
كم عدد المقالات والكتب التي كُتبت عنه بالفعل (هذا المقال ، على سبيل المثال) ، قيل لنا إنني سأكتب لفترة وجيزة - هذا معالج عالمي يمكنه فعل أي شيء تقريبًا. ليس من السهل دائمًا إعداد ودعم مجموعة على Kubernetes.
البدوي
الأداة هي من HashiCorp ، وهي شركة معروفة للقنصل والقبو المذكورة أعلاه.
بدا البدوي لنا بسيطًا في التركيب والتكوين من Kubernetes. يعمل ملف ثنائي واحد في وضع الخادم والعميل. في الوقت نفسه ، يغطي Nomad القائمة الكاملة للمهام التي نريد حلها: إدارة نظام المجموعة ، وجدولة سريعة ، دعم مراكز متعددة. بالإضافة إلى ذلك ، عند استخدام القنصل والقبو ، نحصل على تكامل أكبر لتنظيم خدماتنا.
ما هو الآن في العمل:
- أعدت الخوادم لنشر القنصل ،
- سيتم إدخال تكوين مجموعة البدو في القنصل ، والذي ينبغي نشر البدو فيه تلقائيًا ،
- في موازاة ذلك ، سنقوم بتثبيت قبو لحفظ الأسرار.
والسؤال المطروح في القاعة هو ما إذا كان من المفيد وجود موصل لمثل هذه المهام ، أم أن أوركسترا جيدة بدونها؟ أخبرنا في التعليقات عن رأيك في هذا.
اشترك في مدونتنا والبقاء على اتصال - سنخبرك قريبًا بما حدث في النهاية وما إذا كنا قد قمنا بتكوين مجموعة البدو ، كما أردنا ذلك.
تفضل بزيارة غرفة محادثة Telegram المريحة الخاصة بنا حيث يمكنك دائمًا طلب المشورة ومساعدة الزملاء ومجرد التحدث حول أبحاث الأداء والمزيد.