تحدث أندريه نيكولسكي، مدير عمليات بوابة Banki.ru، في مؤتمر العام الماضي حول خدمات الأيتام: كيفية التعرف على اليتيم في البنية التحتية، ولماذا خدمات الأيتام سيئة، وماذا تفعل بها، وماذا تفعل إذا لم يساعد أي شيء.
يوجد أسفل المقطع نسخة نصية من التقرير.
مرحبا زملائي! اسمي أندريه، وأرأس العمليات في Banki.ru.
لدينا خدمات كبيرة، وهذه خدمات متجانسة، وهناك خدمات بالمعنى الكلاسيكي، وهناك خدمات صغيرة جدًا. في مصطلحاتي العمالية الفلاحية، أقول إنه إذا كانت الخدمة بسيطة وصغيرة، فهي صغيرة، وإذا لم تكن بسيطة وصغيرة جدًا، فهي مجرد خدمة.
إيجابيات الخدمات
سأتحدث بسرعة عن مزايا الخدمات.
الأول هو التحجيم. يمكنك القيام بشيء ما بسرعة في الخدمة وبدء الإنتاج. لقد تلقيت حركة مرور، وقمت باستنساخ الخدمة. لديك المزيد من حركة المرور، لقد قمت باستنساخها والتعايش معها. هذه مكافأة جيدة، ومن حيث المبدأ، عندما بدأنا، كان الأمر الأكثر أهمية بالنسبة لنا هو سبب قيامنا بكل هذا.
ثانيًا، التطوير المعزول، عندما يكون لديك عدة فرق تطوير، وعدة مطورين مختلفين في كل فريق، ويقوم كل فريق بتطوير خدمته الخاصة.
مع الفرق هناك فارق بسيط. المطورين مختلفون. وهناك على سبيل المثال . رأيت هذا لأول مرة مع مكسيم دوروفييف. في بعض الأحيان يكون الأشخاص الذين يشبهون ندفة الثلج في بعض الفرق وليس في فرق أخرى. وهذا يجعل الخدمات المختلفة المستخدمة عبر الشركة غير متساوية بعض الشيء.
انظر إلى الصورة: هذا مطور جيد، لديه أيدٍ كبيرة، يمكنه فعل الكثير. المشكلة الرئيسية هي من أين تأتي هذه الأيدي.
تتيح الخدمات استخدام لغات برمجة مختلفة أكثر ملاءمة للمهام المختلفة. بعض الخدمات موجودة في Go، وبعضها في Erlang، وبعضها في Ruby، وبعضها في PHP، وبعضها في Python. بشكل عام، يمكنك التوسع على نطاق واسع جدا. هناك فروق دقيقة هنا أيضًا.
الهندسة الموجهة نحو الخدمة تدور في المقام الأول حول المطورين. أي أنه إذا لم يكن لديك أتمتة، فلا توجد عملية نشر، وإذا قمت بتكوينها يدويًا، فيمكن أن تتغير تكويناتك من مثيل خدمة إلى مثيل، وعليك الذهاب إلى هناك للقيام بشيء ما، فأنت في الجحيم.
على سبيل المثال، لديك 20 خدمة وتحتاج إلى النشر يدويًا، ولديك 20 وحدة تحكم، وتضغط في نفس الوقت على "إدخال" مثل النينجا. انها ليست جيدة جدا.
إذا كانت لديك خدمة بعد الاختبار (إذا كان هناك اختبار بالطبع)، وما زلت بحاجة إلى إنهائها بملف حتى تعمل في الإنتاج، فلدي أيضًا أخبار سيئة لك.
إذا كنت تعتمد على خدمات معينة من أمازون وتعمل في روسيا، فقبل شهرين كان لديك أيضًا "كل شيء يحترق، أنا بخير، كل شيء رائع".
نحن نستخدم Ansible لأتمتة النشر، وPuppet للتقارب، وBamboo لأتمتة النشر، وConfluence لوصف كل شيء بطريقة ما.
لن أتطرق إلى هذا بالتفصيل، لأن التقرير يتعلق بممارسات التفاعل، وليس بالتنفيذ الفني.
على سبيل المثال، واجهنا مشكلات حيث تعمل Puppet على الخادم مع Ruby 2، ولكن تمت كتابة بعض التطبيقات لـ Ruby 1.8، ولا تعمل معًا. هناك خطأ ما يحدث هناك. وعندما تحتاج إلى تشغيل إصدارات متعددة من Ruby على جهاز واحد، فعادةً ما تبدأ في مواجهة المشكلات.
على سبيل المثال، نمنح كل مطور منصة يوجد عليها كل ما لدينا تقريبًا، وجميع الخدمات التي يمكن تطويرها، بحيث يكون لديه بيئة معزولة، يمكنه كسرها وبنائها كما يريد.
يحدث أنك تحتاج إلى حزمة مجمعة خصيصًا مع دعم لشيء ما هناك. انها صعبة للغاية. لقد استمعت إلى تقرير حيث يبلغ حجم صورة Docker 45 جيجابايت. في Linux، بالطبع، الأمر أسهل، كل شيء أصغر هناك، ولكن لا يزال هناك مساحة كافية.
حسنًا، هناك تبعيات متضاربة، عندما يعتمد جزء من المشروع على مكتبة من إصدار واحد، ويعتمد جزء آخر من المشروع على إصدار آخر، ولا يتم تثبيت المكتبات معًا على الإطلاق.
لدينا مواقع وخدمات PHP 5.6، ونخجل منها، ولكن ماذا يمكننا أن نفعل؟ هذا هو موقعنا الوحيد. هناك مواقع وخدمات على PHP 7، وهناك المزيد منها، ونحن لا نخجل منها. ولكل مطور قاعدته الخاصة حيث ينشر بسعادة.
إذا كنت تكتب في شركة بلغة واحدة، فإن ثلاثة أجهزة افتراضية لكل مطور تبدو طبيعية. إذا كان لديك لغات برمجة مختلفة، فإن الوضع يصبح أسوأ.
لديك مواقع وخدمات في هذا، ثم موقع آخر لـ Go، وموقع واحد لـ Ruby، وبعض مواقع Redis الأخرى على الجانب. ونتيجة لذلك، يتحول كل هذا إلى مجال كبير للدعم، وفي كل وقت يمكن أن ينكسر جزء منه.
لذلك، استبدلنا فوائد لغة البرمجة باستخدام أطر عمل مختلفة، نظرًا لأن أطر عمل PHP مختلفة تمامًا، ولديها قدرات مختلفة ومجتمعات مختلفة ودعم مختلف. ويمكنك كتابة خدمة بحيث يكون لديك بالفعل شيء جاهز لها.
كل خدمة لها فريقها الخاص
ميزتنا الرئيسية، والتي تبلورت على مدى عدة سنوات، هي أن كل خدمة لها فريقها الخاص. يعد هذا مناسبًا لمشروع كبير، ويمكنك توفير الوقت في التوثيق، والمديرون يعرفون مشروعهم جيدًا.
يمكنك بسهولة إرسال المهام من الدعم. على سبيل المثال، انهارت خدمة التأمين. وعلى الفور يذهب الفريق الذي يتعامل مع التأمين لإصلاحه.
يتم إنشاء ميزات جديدة بسرعة، لأنه عندما يكون لديك خدمة ذرية واحدة، يمكنك دمج شيء ما فيها بسرعة.
وعندما تتعطل خدمتك، وهذا ما يحدث حتماً، فإنك لا تؤثر على خدمات الآخرين، ولا يأتي إليك المطورون من الفرق الأخرى ويقولون لك: "لا تفعل ذلك".
كما هو الحال دائما، هناك فروق دقيقة. لدينا فرق مستقرة، والمديرون ملتزمون بالفريق. هناك وثائق واضحة، والمديرون يراقبون كل شيء عن كثب. كل فريق لديه مدير لديه عدة خدمات، وهناك نقطة اختصاص محددة.
إذا كانت الفرق عائمة (نستخدم هذا أحيانًا أيضًا)، فهناك طريقة جيدة تسمى "خريطة النجوم".
لديك قائمة من الخدمات والأشخاص. النجمة تعني أن الشخص خبير في هذه الخدمة، والكتاب يعني أن الشخص يدرس هذه الخدمة. مهمة الشخص هي تغيير الكتيب لعلامة النجمة. وإذا لم يتم كتابة أي شيء أمام الخدمة، فستبدأ المشاكل، والتي سأتحدث عنها أكثر.
كيف تظهر خدمات الأيتام؟
المشكلة الأولى، الطريقة الأولى للحصول على خدمة يتيمة في بنيتك التحتية هي طرد الأشخاص. هل سبق لأي شخص أن التزم بالمواعيد النهائية قبل تقييم المهام؟ في بعض الأحيان يحدث أن تكون المواعيد النهائية ضيقة ولا يوجد ببساطة وقت كافٍ للتوثيق. "نحن بحاجة إلى تسليم الخدمة إلى الإنتاج، ثم سنضيفها."
إذا كان الفريق صغيرا، يحدث أن هناك مطور واحد يكتب كل شيء، والباقي في الأجنحة. "لقد كتبت البنية الأساسية، فلنضف الواجهات." ثم في مرحلة ما، يغادر المدير، على سبيل المثال. وخلال هذه الفترة، عندما غادر المدير ولم يتم تعيين مدير جديد بعد، يقرر المطورون أنفسهم أين تذهب الخدمة وما يحدث هناك. وكما نعلم (دعونا نعود ببعض الشرائح)، يوجد في بعض الفرق أشخاص يشبهون ندفة الثلج، وفي بعض الأحيان يكون هناك قائد فريق ندفة الثلج. ثم يستقيل ونحصل على خدمة الأيتام.
في الوقت نفسه، لا تختفي المهام من الدعم ومن الأعمال، فهي في نهاية المطاف في تراكم. إذا كانت هناك أية أخطاء معمارية أثناء تطوير الخدمة، فإنها تنتهي أيضًا بالتراكم. الخدمة تتدهور ببطء.
كيفية التعرف على اليتيم؟
تصف هذه القائمة الوضع جيدًا. من تعلم أي شيء عن البنية التحتية الخاصة بهم؟
حول الحلول الموثقة: هناك خدمة، وهي تعمل بشكل عام، ولها دليل من صفحتين حول كيفية العمل معها، ولكن لا أحد يعرف كيف تعمل في الداخل.
أو، على سبيل المثال، هناك نوع من اختصار الروابط. على سبيل المثال، لدينا حاليًا ثلاثة أدوات لتقصير الروابط قيد الاستخدام لأغراض مختلفة في خدمات مختلفة. هذه مجرد العواقب.
الآن سأكون قائد الواضح. ما الذي يجب إتمامه؟ أولا، نحتاج إلى نقل الخدمة إلى مدير آخر، فريق آخر. إذا لم يستقيل قائد فريقك بعد، ففي هذا الفريق الآخر، عندما تفهم أن الخدمة مثل اليتيم، تحتاج إلى تضمين شخص يفهم شيئًا عنها على الأقل.
الشيء الرئيسي: يجب أن تكون إجراءات النقل مكتوبة بالدم. في حالتنا، عادةً ما أراقب هذا الأمر، لأنني أحتاج إلى أن يعمل كل شيء. يحتاج المديرون إلى تسليمها بسرعة، وما يحدث لها لاحقًا لم يعد مهمًا جدًا بالنسبة لهم.
الطريقة التالية لجعل اليتيم هي "سنقوم بذلك بالاستعانة بمصادر خارجية، وسيكون أسرع، وبعد ذلك سنسلمه إلى الفريق". من الواضح أن كل شخص لديه بعض الخطط في الفريق، وهو دور. غالبًا ما يعتقد عميل الأعمال أن المتعاقد الخارجي سيفعل نفس الشيء الذي يفعله القسم الفني الموجود في الشركة. على الرغم من أن دوافعهم مختلفة. هناك حلول تكنولوجية غريبة وحلول خوارزمية غريبة في الاستعانة بمصادر خارجية.
على سبيل المثال، كانت لدينا خدمة قامت بوضع أبو الهول في أماكن مختلفة غير متوقعة. سأخبرك لاحقًا بما كان علي فعله.
لدى المتعاقدين الخارجيين أطر مكتوبة ذاتيًا. هذا مجرد PHP مع نسخ ولصق من مشروع سابق، حيث يمكنك العثور على كل أنواع الأشياء. تعد البرامج النصية للنشر عيبًا كبيرًا عندما تحتاج إلى استخدام بعض البرامج النصية المعقدة لـ Bash لتغيير عدة أسطر في بعض الملفات، ويتم استدعاء البرامج النصية للنشر هذه بواسطة برنامج نصي ثالث. ونتيجة لذلك، يمكنك تغيير نظام النشر، واختيار شيء آخر، والقفز، ولكن خدمتك لا تعمل. لأنه كان من الضروري وضع 8 روابط أخرى بين مجلدات مختلفة. أو يحدث أن ألف سجل يعمل، ولكن مائة ألف لم تعد تعمل.
سأستمر كقائد. قبول خدمة الاستعانة بمصادر خارجية هو إجراء إلزامي. هل وصل أي شخص من قبل إلى خدمة الاستعانة بمصادر خارجية ولم يتم قبولها في أي مكان؟ هذه ليست شعبية، بالطبع، مثل خدمة الأيتام، ولكن لا تزال.
يجب فحص الخدمة، ويجب مراجعة الخدمة، ويجب تغيير كلمات المرور. كانت لدينا حالة عندما قدموا لنا خدمة، وكانت هناك لوحة إدارة "إذا كان تسجيل الدخول == 'admin' && كلمة المرور == 'admin'..."، فهي مكتوبة مباشرة في الكود. نقعد نفكر والناس تكتب هذا في 2018؟
يعد اختبار سعة التخزين أمرًا ضروريًا أيضًا. أنت بحاجة إلى إلقاء نظرة على ما سيحدث لمائة ألف سجل، حتى قبل وضع هذه الخدمة في مرحلة الإنتاج في مكان ما.
لا ينبغي أن يكون هناك خجل في إرسال خدمة للتحسين. وعندما تقول: “لن نقبل هذه الخدمة، لدينا 20 مهمة، قم بها، ثم سنقبل”، فهذا طبيعي. لا ينبغي أن يتأذى ضميرك من حقيقة أنك تقوم بتعيين مدير أو أن الشركة تهدر المال. سوف تنفق الشركة بعد ذلك المزيد.
كانت لدينا حالة عندما قررنا الاستعانة بمصادر خارجية لمشروع تجريبي.
تم تسليمه في الوقت المحدد، وكان هذا هو معيار الجودة الوحيد. ولهذا السبب قمنا بإنشاء مشروع تجريبي آخر، والذي لم يعد تجريبيًا بعد الآن. تم قبول هذه الخدمات، ومن خلال الوسائل الإدارية قالوا، هذا هو الكود الخاص بك، هنا الفريق، هنا مديرك. لقد بدأت الخدمات بالفعل في تحقيق الربح. وفي الوقت نفسه، ما زالوا في الواقع أيتامًا، ولا أحد يفهم كيف يعملون، ويبذل المديرون قصارى جهدهم للتبرأ من مهامهم.
هناك مفهوم عظيم آخر - تطوير حرب العصابات. عندما يرغب قسم ما، عادةً قسم التسويق، في اختبار فرضية ويطلب الاستعانة بمصادر خارجية للخدمة بأكملها. تبدأ حركة المرور في التدفق، ويغلقون المستندات، ويوقعون المستندات مع المقاول، ويبدأون العمل ويقولون: "يا شباب، لدينا خدمة هنا، لديها حركة مرور بالفعل، وهي تجلب لنا المال، فلنقبلها". لقد كنا مثل، "أوبا، كيف يمكن أن يكون ذلك."
وطريقة أخرى للحصول على خدمة يتيمة: عندما يجد فريق ما نفسه محملاً فجأة، تقول الإدارة: “دعونا ننقل خدمة هذا الفريق إلى فريق آخر، فهو يحمل حملاً أقل”. وبعد ذلك سننقله إلى فريق ثالث ونغير المدير الفني. وفي النهاية لدينا يتيم مرة أخرى.
ما مشكلة الأيتام؟
ومن لا يعلم، هذه هي السفينة الحربية واسا التي نشأت في السويد، المشهورة بغرقها بعد 5 دقائق من إطلاقها. وبالمناسبة، لم يعدم ملك السويد أحداً بسبب ذلك. تم بناؤه من قبل جيلين من المهندسين الذين لم يعرفوا كيفية بناء مثل هذه السفن. تأثير طبيعي.
بالمناسبة، كان من الممكن أن تغرق السفينة بطريقة أسوأ بكثير، على سبيل المثال، عندما كان الملك يركبها بالفعل في مكان ما وسط عاصفة. وهكذا، غرق على الفور، وفقًا لـ Agile، من الجيد أن تفشل مبكرًا.
إذا فشلنا مبكرًا، فلن تكون هناك مشكلات عادةً. على سبيل المثال، أثناء القبول تم إرساله للمراجعة. ولكن إذا فشلنا بالفعل في الإنتاج، عندما يتم استثمار الأموال، فقد تكون هناك مشاكل. العواقب، كما يطلق عليها في عالم الأعمال.
لماذا تعتبر خدمات الأيتام خطيرة:
- قد تنقطع الخدمة فجأة.
- تستغرق الخدمة وقتًا طويلاً لإصلاحها أو لا يتم إصلاحها على الإطلاق.
- مشاكل السلامة.
- مشاكل مع التحسينات والتحديثات.
- إذا تعطلت خدمة مهمة، فإن سمعة الشركة تتأثر.
ما العمل مع خدمات الأيتام؟
سأكرر ما يجب فعله مرة أخرى. أولا، يجب أن يكون هناك وثائق. علمتني 7 سنوات في Banki.ru أن المختبرين لا ينبغي أن يأخذوا كلام المطورين، ولا ينبغي للعمليات أن تأخذ كلام الجميع. نحن بحاجة للتحقق.
ثانيا، من الضروري كتابة مخططات التفاعل، لأنه يحدث أن الخدمات التي لم يتم تلقيها بشكل جيد تحتوي على تبعيات لم يتحدث عنها أحد. على سبيل المثال، قام المطورون بتثبيت الخدمة على مفتاحهم لبعض Yandex.Maps أو Dadata. لقد استنفدت الحد الحر، وكل شيء مكسور، ولا تعرف ما حدث على الإطلاق. يجب وصف كل هذه المكابس: تستخدم الخدمة بيانات البيانات والرسائل النصية القصيرة وشيء آخر.
ثالثا، العمل مع الديون الفنية. عندما تقوم بنوع ما من العكازات أو تقبل خدمة وتقول إن شيئًا ما يحتاج إلى القيام به، فأنت بحاجة إلى التأكد من إنجازه. لأنه بعد ذلك قد يتبين أن الثقب الصغير ليس صغيرًا جدًا، وسوف تسقط من خلاله.
مع المهام المعمارية، كان لدينا قصة عن أبو الهول. استخدمت إحدى الخدمات أبو الهول لإدخال القوائم. مجرد قائمة مرقّمة، ولكن تمت إعادة فهرستها كل ليلة. وقد تم تجميعه من فهرسين: واحد كبير كان يفهرس كل ليلة، وكان هناك أيضًا فهرس صغير يُثبت عليه. كل يوم، مع احتمال 50% لقصف أم لا، يتعطل المؤشر أثناء الحساب، وتتوقف أخبارنا عن التحديث على الصفحة الرئيسية. في البداية، استغرق الأمر 5 دقائق لإعادة فهرسة المؤشر، ثم نما المؤشر، وفي مرحلة ما بدأت تستغرق إعادة الفهرسة 40 دقيقة. عندما قمنا بحذف ذلك، تنفسنا الصعداء، لأنه كان من الواضح أن المزيد من الوقت سوف يمر وسيتم إعادة فهرسة مؤشرنا بدوام كامل. سيكون هذا بمثابة فشل لبوابتنا، فلا توجد أخبار لمدة ثماني ساعات - كل شيء، لقد توقف العمل.
خطة للعمل مع خدمة الأيتام
في الواقع، من الصعب جدًا القيام بذلك، لأن المطورين يتعلقون بالتواصل. تريد أن تكون على علاقة جيدة مع زملائك، وعندما تضرب زملائك ومديريك باللوائح، فقد تكون لديهم مشاعر متضاربة تجاه الأشخاص الذين يفعلون ذلك.
بالإضافة إلى كل هذه النقاط، هناك شيء مهم آخر: يجب أن يكون هناك أشخاص محددون مسؤولون عن كل خدمة محددة، وعن كل قسم محدد من إجراءات النشر. عندما لا يكون هناك أشخاص وتضطر إلى جذب بعض الأشخاص الآخرين لدراسة هذا الأمر برمته، يصبح الأمر صعبًا.
إذا لم يساعد كل هذا، ولا تزال خدمة الأيتام الخاصة بك يتيمة، فلا أحد يريد أن يأخذها، ولم يتم كتابة الوثائق، والفريق الذي تم استدعاؤه لهذه الخدمة يرفض القيام بأي شيء، هناك طريقة بسيطة - لإعادة كل شيء.
أي أنك تأخذ متطلبات الخدمة من جديد وتكتب خدمة جديدة أفضل على منصة أفضل دون حلول تكنولوجية غريبة. وهاجروا إليها قتالا .
لقد واجهنا موقفًا عندما حصلنا على خدمة على Yii 1 وأدركنا أننا لا نستطيع تطويرها بشكل أكبر، لأنه لم يعد لدينا مطورين يمكنهم الكتابة بشكل جيد على Yii 1. جميع المطورين يكتبون بشكل جيد على Symfony XNUMX. ما يجب القيام به؟ لقد خصصنا الوقت، وخصصنا فريقًا، وخصصنا مديرًا، وأعدنا كتابة المشروع وقمنا بتحويل حركة المرور إليه بسلاسة.
وبعد ذلك، يمكن حذف الخدمة القديمة. هذا هو الإجراء المفضل لدي، عندما تحتاج إلى أخذ بعض الخدمات وتنظيفها من نظام إدارة التكوين ثم المتابعة والتأكد من تعطيل جميع السيارات في الإنتاج، بحيث لا يتبقى للمطورين أي آثار. يبقى المستودع في Git.
هذا كل ما أردت التحدث عنه، أنا مستعد للمناقشة، الموضوع هو هوليفار، وقد سبح فيه الكثيرون.
قالت الشرائح أنك وحدت اللغات. ومن الأمثلة على ذلك تغيير حجم الصور. هل من الضروري حقًا قصرها على لغة واحدة؟ لأن تغيير حجم الصورة في PHP، حسنًا، يمكن إجراؤه بالفعل في Golang.
في الواقع، إنه اختياري، مثل كل الممارسات. وربما يكون الأمر غير مرغوب فيه في بعض الحالات. لكن عليك أن تفهم أنه إذا كان لديك قسم فني في شركة مكونة من 50 شخصًا، 45 منهم متخصصون في PHP، و3 آخرون من المطورين الذين يعرفون Python وAnsible وPuppet وشيء من هذا القبيل، وواحد منهم فقط يكتب في بعض اللغات. نوع من اللغة. بعض خدمات تغيير حجم الصور تذهب، وعندما تغادر، تذهب معها الخبرة. وفي نفس الوقت، ستحتاج إلى البحث عن مطور خاص بالسوق يعرف هذه اللغة، خاصة إذا كانت نادرة. وهذا يعني أن هذا يمثل مشكلة من الناحية التنظيمية. من وجهة نظر المطورين، لن تحتاج فقط إلى استنساخ مجموعة جاهزة من أدلة التشغيل التي تستخدمها لنشر الخدمات، ولكن سيتعين عليك كتابتها مرة أخرى.
نقوم حاليًا ببناء خدمة على Node.js، وستكون هذه مجرد منصة قريبة لكل مطور بلغة منفصلة. لكننا جلسنا واعتقدنا أن اللعبة كانت تستحق كل هذا العناء. أي أن هذا سؤال عليك أن تجلس وتفكر فيه.
كيف تراقب خدماتك؟ كيف يمكنك جمع ومراقبة السجلات؟
نقوم بجمع السجلات في Elasticsearch ووضعها في Kibana، واعتمادًا على ما إذا كانت بيئة إنتاج أو اختبار، يتم استخدام أدوات تجميع مختلفة هناك. في مكان ما حطاب، في مكان آخر، شيء آخر، لا أتذكر. ولا تزال هناك بعض الأماكن في بعض الخدمات حيث نقوم بتثبيت Telegraf والتصوير في مكان آخر بشكل منفصل.
كيف تعيش مع Puppet وAnsible في نفس البيئة؟
في الواقع، لدينا الآن بيئتان، إحداهما Puppet والأخرى Ansible. نحن نعمل على تهجينهم. يعد Ansible إطارًا جيدًا للإعداد الأولي، ويعتبر Puppet إطار عمل سيئًا للإعداد الأولي لأنه يتطلب عملاً عمليًا مباشرة على النظام الأساسي، ويضمن Puppet تقارب التكوين. هذا يعني أن النظام الأساسي يحافظ على نفسه في حالة محدثة، ومن أجل الحفاظ على تحديث الجهاز غير المحدود، تحتاج إلى تشغيل أدلة التشغيل عليه طوال الوقت مع بعض التردد. هذا هو الفرق.
كيف تحافظ على التوافق؟ هل لديك تكوينات في كل من Ansible وPuppet؟
هذا هو ألمنا الكبير، فنحن نحافظ على التوافق بين أيدينا ونفكر في كيفية المضي قدمًا من كل هذا إلى مكان ما الآن. اتضح أن Puppet تطرح الحزم وتحتفظ ببعض الروابط هناك، بينما يقوم Ansible، على سبيل المثال، بنشر التعليمات البرمجية وضبط أحدث تكوينات التطبيق هناك.
كان العرض التقديمي يدور حول إصدارات مختلفة من روبي. ما الحل؟
لقد واجهنا هذا في مكان واحد، وعلينا أن نبقيه في أذهاننا طوال الوقت. لقد قمنا ببساطة بإيقاف تشغيل الجزء الذي يعمل على روبي والذي كان غير متوافق مع التطبيقات وأبقيناه منفصلاً.
مؤتمر هذا العام سيقام يوم 7 ديسمبر في تكنوبوليس. نحن نقبل طلبات التقارير حتى 11 نوفمبر. لنا إذا كنت ترغب في التحدث.
التسجيل للمشاركين مفتوح، انضم إلينا!
المصدر: www.habr.com