الخدمات اليتيمة: الجانب العكسي لهيكل الخدمة (الصغير)

قال مدير عمليات بوابة Banki.ru ، أندريه نيكولسكي ، في مؤتمر العام الماضي ، DevOpsDays Moscow حول خدمات الأيتام: كيفية التعرف على يتيم في البنية التحتية ، وما هي خدمات الأيتام السيئة ، وماذا تفعل معهم ، وكيف يكون ذلك إذا لم يكن هناك شيء مفيد.

تحت الخفض هو إصدار النص للتقرير.


مرحبا الزملاء! اسمي أندري ، أقود العملية في Banki.ru.

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

إيجابيات الخدمة

سأنظر بسرعة في مزايا الخدمات.



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



ثانياً ، التطوير المنعزل ، عندما يكون لديك العديد من فرق التطوير ، والعديد من المطورين المختلفين في كل فريق ، ويشهد كل فريق نوعًا من الخدمة.

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



انظر إلى الصورة: إنه مطور جيد ، ولديه أيادي كبيرة ، ويمكنه أن يفعل الكثير. المشكلة الرئيسية هي من أين تنمو هذه الأيدي.



تتيح الخدمات استخدام لغات البرمجة المختلفة الأكثر ملاءمة للمهام المختلفة. بعض الخدمات على الذهاب ، وبعض على Erlang ، وبعض على روبي ، وبعض على PHP ، وبعض على بيثون. بشكل عام ، يمكنك الدوران على نطاق واسع جدًا. هناك أيضا الفروق الدقيقة هنا.



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

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

إذا كان لديك خدمة بعد الاختبار (إذا كان هناك اختبار بالطبع) ، وتحتاج أيضًا إلى الانتهاء من ذلك باستخدام ملف بحيث يعمل في الإنتاج ، فإن لدي أيضًا أخبار سيئة لك.

إذا كنت تعتمد على خدمات محددة من Amazon وتعمل في روسيا ، فقبل شهرين ، كان لديك أيضًا "كل شيء على النار ، أنا بخير ، كل شيء رائع".



نحن نستخدم Ansible لأتمتة النشر ، و Puppet للتقارب ، و Bamboo لأتمتة النشر ، و Confluence لوصفها بطريقة أو بأخرى.

لن أتطرق إلى هذا بالتفصيل ، لأن التقرير يدور حول ممارسة التفاعلات ، وليس التطبيق التقني.



على سبيل المثال ، واجهنا مشاكل في أن Puppet على الخادم يعمل مع Ruby 2 ، وقد تمت كتابة بعض التطبيقات تحت Ruby 1.8 ، وهي لا تعمل معًا. هناك نوع من عضادة يحدث. وعندما تحتاج إلى الاحتفاظ بعدة إصدارات من Ruby على نفس الجهاز ، فعادة ما تواجهك مشكلات.

على سبيل المثال ، نوفر لكل مطور نظامًا قائمًا عليه فقط حول كل ما لدينا ، وجميع الخدمات التي يمكن تطويرها حتى يكون لديه بيئة معزولة ، ويمكنه كسرها وبناءها كما يريد.

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

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



لدينا مواقع وخدمات في PHP 5.6 ، نشعر بالخجل منها ، ولكن ماذا نفعل. هذا هو موقعنا واحد. هناك مواقع وخدمات في PHP 7 ، وهناك المزيد منها ، ونحن لا نخجل منها. ولكل مطور قاعدة خاصة به ، حيث يرى بسعادة.

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



لديك مواقع وخدمات على هذا ، في هذا ، ثم منصة أخرى لـ Go ، منصة واحدة لـ Ruby ، ​​و Redis أخرى على الجانب. ونتيجة لذلك ، يتحول كل هذا إلى مجال كبير للحصول على الدعم ، وقد ينكسر بعض هذا الوقت.



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

كل خدمة لها فريقها الخاص.

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

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

يتم إنشاء ميزات جديدة بسرعة ، لأنه عندما يكون لديك خدمة ذرية واحدة ، يمكنك بسرعة توصيل شيء ما بها.

وعندما توقفت عن خدمتك ، وهذا يحدث حتماً ، لم تؤذي خدمات شخص آخر ، ولا يلجأ المطورون ذوو القطع الصغيرة من الفرق الأخرى إليك ولا يقولون: "عذرًا ، لا تفعل ذلك".



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

إذا كانت الفرق تطفو (وهذا يستخدم أيضًا في بعض الأحيان معنا) ، فهناك طريقة جيدة تسمى خريطة النجوم.



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

كيف تظهر خدمات الأيتام؟

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

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



في الوقت نفسه ، المهام من الدعم ومن العمل لا تختفي ، فهي تستقر في الأعمال المتراكمة. إذا كان هناك أي أخطاء معمارية أثناء تطوير الخدمة ، فإنهم أيضًا يستقرون في الأعمال المتأخرة. الخدمة مهينة ببطء.

كيفية التعرف على اليتيم؟

هذه القائمة تصف الموقف جيدًا. من الذي تعلم أي شيء في البنية التحتية؟



حول الحلول العملية الموثقة: هناك خدمة ، وبشكل عام ، تعمل ، لديها دليل من صفحتين ، وكيفية التعامل معها ، ولكن لا أحد يعرف كيف يعمل في الداخل.

أو ، على سبيل المثال ، هناك نوع من اختصار الارتباط. على سبيل المثال ، نستخدم الآن ثلاثة مختصرات ارتباط لأغراض مختلفة في خدمات مختلفة. هذه هي العواقب.



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

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



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



على سبيل المثال ، كان لدينا خدمة كان فيها أبو الهول في أماكن مختلفة غير متوقعة. سأخبرك لاحقًا بما يجب علي فعله.

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

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



يجب التحقق من الخدمة ، ويجب مراجعة الخدمة ، ويجب تغيير كلمات المرور. كانت لدينا قضية عندما ألقت الخدمة بنا ، هناك لوحة المسؤول "if login == 'admin' && password == 'admin' ..." مكتوبة مباشرة في الكود. نجلس ونفكر ، والناس يكتبون هذا في عام 2018؟

اختبار حجم التخزين هو أيضا أمر لا بد منه. تحتاج إلى إلقاء نظرة على ما سيحدث في مائة ألف سجل ، حتى قبل أن تبدأ هذه الخدمة في مكان ما في الإنتاج.



إرسال الخدمة للمراجعة يجب أن لا تخجل. عندما تقول: "لن نقبل هذه الخدمة ، لدينا 20 مهمة ، ونقوم بها ، ثم سنقبلها" ، هذا أمر طبيعي. يجب ألا يؤذي الضمير من حقيقة أنك بديلاً للمدير أو أن الشركة تنفق الأموال. الأعمال سوف تنفق أكثر من ذلك.

كان لدينا قضية عندما قررنا أن نجعل مشروع تجريبي بشأن الاستعانة بمصادر خارجية.



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



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



وهناك طريقة أخرى للحصول على خدمة يتيمة: عندما يتم تحميل فريق ما فجأة ، تقول الإدارة: "دعنا ننقل خدمة هذا الفريق إلى فريق آخر ، يكون حمله أقل". وبعد ذلك سننتقل إلى الفريق الثالث ، وسوف نغير المدير. وفي النهاية ، لدينا يتيم مرة أخرى.

ما هي مشكلة الأيتام؟

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

قد تغرق السفينة ، بالمناسبة ، أسوأ بكثير ، على سبيل المثال ، عندما يركبها الملك في مكان ما في عاصفة. وهكذا ، غرق على الفور ، وفقًا لما قاله ajail ، من الجيد أن تفشل مبكرًا.

إذا فشلنا في وقت مبكر ، وعادة ما لا توجد مشاكل. على سبيل المثال ، أثناء القبول أرسلوا للمراجعة. وإذا فشلنا بالفعل في الإنتاج ، وعندما يتم استثمار الأموال ، فقد تكون هناك مشاكل. العواقب ، كما يطلق عليها في الأعمال التجارية.

لماذا خدمات اليتيم الخطرة:

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

ماذا تفعل مع خدمات اليتيم؟

مرة أخرى ، ما يجب القيام به. أولا ، يجب أن يكون هناك وثائق. لمدة 7 سنوات في Banki.ru لقد علمت أنه لا ينبغي للمختبرين أخذ كلمة للمطورين ، ويجب ألا تأخذ العملية كلمة للجميع. من الضروري التحقق.



ثانياً ، من الضروري كتابة مخططات التفاعل ، لأنه يحدث أن الخدمات التي لم يتم تلقيها بشكل جيد تحتوي على تبعيات لم يتحدث عنها أحد. على سبيل المثال ، وضع المطورون الخدمة على مفتاحهم في بعض Yandex.Maps أو Dadata. لقد نفدت حدك المجاني ، لقد تعطل كل شيء ، ولا تعرف ما حدث على الإطلاق. يجب وصف كل هذه المكابس: تستخدم الخدمة Dadata ، Sms ، شيء آخر.



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

مع المهام المعمارية ، كان لدينا قصة عن أبو الهول. في إحدى الخدمات ، تم استخدام Sphinx لإدخال القوائم. مجرد قائمة ترقيم الصفحات ، لكن تم إعادة توصيفها كل ليلة. تم تجميعها من مؤشريين: تم فهرسة واحدة كل ليلة كبيرة ، وكان لا يزال هناك مؤشر صغير مثبت عليه. كل يوم ، مع احتمال بنسبة 50 ٪ ، فإنه إما أن يقصف أو لا ، أثناء الحساب ، كان المؤشر ينبض ، والأخبار توقفت عن التحديث على الصفحة الرئيسية. في البداية كانت 5 دقائق ، بينما تمت إعادة فهرسة المؤشر ، ثم نما المؤشر ، وفي مرحلة ما بدأ إعادة الفهرسة 40 دقيقة. عندما أوقفناه ، تنفسنا الصعداء ، لأنه كان من الواضح أن مزيدًا من الوقت سيمر ، وسيعاد فهرسة فهرسنا بدوام كامل. سيكون ملفًا لبوابتنا ، ولن يكون هناك ثماني ساعات من الأخبار - لقد انتهى الأمر.

خطة العمل مع خدمة اليتيم

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

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



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

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



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

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

هذا هو كل ما أردت الحديث عنه ، وأنا على استعداد للمناقشة ، والموضوع كلي ، وطرح فيه الكثيرون.

على الشرائح ، كان الأمر يتعلق بحقيقة توحيدك للغات. مثال على ذلك كان تغيير حجم الصور. ولكن هل من الضروري حقًا أن تتحول إلى لغة واحدة؟ لأن تغيير حجم الصور في PHP ، حسنًا ، يمكنك فعل ذلك في Golang.

في الواقع ، هذا ليس ضروريا ، مثل كل الممارسات. ربما ، في بعض الحالات ، حتى غير مرغوب فيه. لكن عليك أن تفهم أنه إذا كان لديك 50 شخصًا في القسم الفني ، 45 منهم من مطوري PHP ، و 3 آخرون هم من المصلين الذين يمكنهم القيام بيثون ، وأنسبل ، ودمى ، وشيء من هذا القبيل ، ويكتب واحد منهم فقط على بعض انتقل إلى خدمة تغيير حجم الصور ، ثم عندما يغادر ، يترك الفحص معه. وفي الوقت نفسه ، ستحتاج إلى البحث عن مطور خاص بالسوق يعرف هذه اللغة ، خاصة إذا كانت نادرة. وهذا هو ، من وجهة نظر تنظيمية ، وهذا هو مشكلة. من وجهة نظر المطورين ، لن تحتاج فقط إلى استنساخ مجموعة من كتب اللعب الجاهزة التي تستخدمها لنشر الخدمات ، ولكن سيتعين عليك كتابتها مرة أخرى.

نشاهد الآن الخدمة على Node.js ، وستكون مجرد منصة قريبة لكل مطور بلغة منفصلة. ولكن جلسنا التفكير في أن اللعبة كانت تستحق كل هذا العناء. هذا هو ، والسؤال هنا هو الجلوس والتفكير.

كيف تراقب خدماتك؟ كيف تجمع وتتبع السجلات؟

نقوم بجمع السجلات في Elasticsearch ووضعنا في Kibana ، واعتمادًا على بيئات الإنتاج أو الاختبار ، يتم استخدام أدوات تجميع مختلفة هناك. في مكان ما الحطاب ، في مكان آخر شيء ، لم أعد أتذكر. وما زالت هناك بعض الأماكن في خدمات معينة حيث وضعنا Telegraf و bullet في مكان آخر بشكل منفصل.

كيف تعيش مع الدمى و Ansible في بيئة واحدة؟

في الواقع ، لدينا الآن بيئتان ، واحدة هي دمية ، والآخر هو Ansible. نحن نعمل على تهجينهم. Ansible هي بيئة جيدة للإعداد الأولي ، Puppet شيء سيء للإعداد الأولي لأنه يتطلب أيدي للعمل مباشرة مع الموقع ، ويوفر Puppet تقارب التكوين. هذا يعني أن الموقع نفسه مُحدَّث ، ولكي يتم تحديث الجهاز الذي تم إزالته ، يجب عليك مطاردة كتب اللعب به بأي تردد. هنا هو هذا الاختلاف.

كيف يمكنك الحفاظ على التوافق؟ هل لديك التكوينات في كل من Ansible و Puppet؟

هذا هو ألمنا الكبير ، ونحن نحافظ على التوافق مع أيدينا ونفكر ، كما لو الآن ، في الانتقال من كل هذا إلى مكان ما. اتضح أن Puppet تدحرج الحزم وتدعم بعض الوصلات هناك ، بينما Ansible ، على سبيل المثال ، تدحرج الكود ويدفع التكوينات الجديدة للتطبيق هناك.

كان العرض التقديمي حول إصدارات مختلفة من روبي. ما هو الحل؟

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

هذا العام ، سيعقد مؤتمر DevOpsDays موسكو في 7 ديسمبر في تكنوبوليس. حتى 11 نوفمبر ، نحن نقبل طلبات التقارير. مراسلتنا عبر البريد الإلكتروني إذا كنت تريد التحدث.

التسجيل للمشاركين مفتوح ، انضم!