أفضل الممارسات لعمليات نشر Rails الجديدة على Linux؟
https://stackoverflow.com/questions/280155
-
07-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد استخدمت Mongrel مباشرة، واستخدمت مجموعات Mongrel خلف Apache، ونظرت إلى Thin، وأصبحت مفتونًا جدًا بالركاب.لقد ألقيت نظرة على Nginx أيضًا.لقد ألقيت نظرة على MRI وRuby Enterprise Edition وRubinius وJRuby.هناك الكثير من الخيارات، كل منها يدعي أنه الكأس المقدسة الجديدة.
ما هو الخيار الأفضل المتاح للنشر الجديد والمحدث بالكامل؟الافتراضات الوحيدة هي:
- التطبيق يعتمد على Rails 2.2.(أعلم أن الإصدار 2.2 لم يتم إصداره بالكامل بعد، ولكن لم يتم نشره أيضًا.)
- الخادم يعتمد على Linux.ربما Ubuntu Hardy، ولكن في الواقع، كل ما يعمل بشكل أفضل في هذه الحالة.
- ستحتاج ريلز إلى أن تعمل بكامل طاقتها وربما تتصل بقاعدة بيانات MySQL.
- كل شيء آخر قابل للتفاوض.
وبالنظر إلى هذه القيود الواسعة بشكل خاص، ما هي مجموعة البرامج التي ستحقق أفضل نتيجة، من حيث التزامن والنفقات العامة المنخفضة؟
أنا أميل نحو Apache مع mpm "العامل" وPassenger + Ruby Enterprise Edition، وذلك ببساطة لأنه يوفر استقرارًا فوريًا وبساطة في الإعداد والصيانة.
هل من المحتمل أن أكون أفضل حالًا بشكل خاص مع خيار آخر؟
المحلول
لقد قمت بالتبديل من Mongrel Cluster إلى Passenger منذ أسبوعين (Debian Linux Server).لم أنظر إلى الوراء لثانية واحدة.ربما يكون Passenger هو أسهل طريقة لإعداد خادمك الجديد وتشغيله.الأداء والموثوقية معقولة أيضًا.
شخصيًا، أحب قضاء وقتي في العمل على مشاريع Rails الجديدة والمثيرة بدلاً من التعامل مع مشكلات النشر - يتيح لي برنامج Passenger القيام بذلك بالضبط.ومع ذلك، قد يظل Mongrel أو أي شيء آخر هو المفضل إذا كان لديك بعض المتطلبات الخاصة (لا ينطبق ذلك على معظم المنتجات).
نصائح أخرى
هذا الصباح، يتحدث DHH عن هذا الموضوع بالذات على مدونته الخاصة:
ولكن بطريقة ما كانت رسالة الراكب بطيئة بعض الشيء في استيعابها.هناك بالفعل عدد كبير من المواقع الكبيرة التي تعمل عليه.بما في ذلك Shopify، وMTV، وGeni، وYammer، وسننتقل إلى قائمة Ta-da الأولى قريبًا، ثم نأمل أن بقية مجموعة 37signals سريعًا بعد ذلك.
لذلك، بينما لا تزال هناك أسباب لتشغيل الإعداد المخصص متعدد المستويات الخاص بك للأجزاء التي تم تكوينها يدويًا، تمامًا كما هو الحال مع الأشخاص الذين يتجنبون mod_php للحصول على تفاصيلهم، أعتقد أننا استقرنا أخيرًا على إجابة افتراضية.شيء لا يتطلب منك التفكير حقًا في النشر الأول لتطبيق Rails الخاص بك.شيء يعمل فقط خارج الصندوق.حتى لو كان هذا الصندوق مضيفًا مشتركًا!
http://www.loudthinking.com/posts/30-myth-1-rails-is-hard-to-deploy
توبياس لوتكي حول موضوع التبديل Shopify (مليون طلب / يوم) إلى الركاب:
كل هذا يعني أن إجمالي حجم الذاكرة التي يستخدمها Shopify أثناء العمليات العادية ارتفع من متوسط 9 جيجابايت إلى متوسط 5 جيجابايت.لقد قمنا بتوزيع المدخرات بالتساوي بين المزيد من عمليات Shopify والمزيد من المساحة المخزنة على الذاكرة مما أدى إلى نقل متوسط وقت الاستجابة لدينا من 210 مللي ثانية إلى 130 مللي ثانية بينما زادت حركة المرور بنسبة 30% في الأشهر القليلة الماضية.
ختاماً:لا أستطيع أن أرى أي سبب لاختيار استراتيجية نشر مختلفة في هذه المرحلة.إنها بسيطة وكاملة وسريعة وموثقة جيدًا.
لقد كنا نستخدم المعيار القديم nginx -> mongrel stack منذ 18 شهرًا، وعلى الرغم من أنه لم يكن من السهل إعداده في المرة الأولى، إلا أنه أثبت مرونته، وتعامل مع بعض المواقع ذات الزيارات العالية جدًا بالنسبة لنا.لقد كان Nginx على وجه الخصوص قويًا وسريعًا للغاية، وإذا تمكنت من الحصول على ذاكرة تخزين مؤقت لصفحة التطبيق، فيمكنك التعامل مع الكثير من الطلبات.
لقد كانت النغول العالقة مشكلة، لذلك نستخدم monit لقتلهم عندما يسيئون التصرف.مرة أخرى، لم يكن الإعداد تافهًا تمامًا، ولكننا استخدمنا نفس العملية في العديد من المواقع في هذه المرحلة.
لم نلعب مع الركاب بعد، لذلك ربما يكون الأمر أسهل وأكثر استقرارًا، سأرجع إلى المستجيبين الآخرين بشأن هذا الأمر، كل ما يمكنني قوله هو أنه لا يوجد سبب على الإطلاق يمنعك من بناء مكدس قوي باستخدام nginx والهجين.
لقد قمنا بتحويل fron NginX+Mongrel إلى Passenger.
أعتقد تمامًا أن Passenger سيكون المعيار الجديد للقضبان، على الرغم من اعتماد مجموعة NginX وMongrel من قبل بعض الأشخاص الأذكياء جدًا.لقد دفعت التطورات الأخيرة في مجال الركاب بالفعل إلى الأمام.
التكوين الحالي لدينا هو شيء من هذا القبيل:
خوادم الويب
- أوبونتو 8.04 إل تي إس
- Phusion الركاب على Apache2
- التصوير بالرنين المغناطيسي روبي 1.8.6 والأصدقاء (نموذج مناسب)
- Ruby Gems 1.3.0 (مثبت من المصدر)
خوادم قواعد البيانات
- سنتوس 5
- MySQL Cluster (لقد تحولنا للتو إلى هذا، ولكنه واعد)
بعد توحيد توزيعة Linux الدقيقة، تمكنا من كتابة وصفات Capitrano للمساعدة في النشر (كانت الاختلافات الطفيفة في التكوين مصدرًا للعديد من حالات انقطاع الخدمة) وتبسيط حياتنا.
القي نظرة على لايت سبيد.يمكنك الحصول على نسخة مجانية تعمل على وحدة معالجة مركزية واحدة أو الدفع للحصول على وحدة معالجة مركزية متعددة.إنها باهظة الثمن بعض الشيء ولكنها صلبة وتتعامل مع القضبان ببراعة (على سبيل المثال.يستخدم ذاكرة أقل ويمثل عبئًا أقل للمراقبة والإعداد).أقوم بتشغيل عدد هائل من التطبيقات عليه ولا يفوتني أي شيء.
لقد قمنا أيضًا بالتبديل من Mongrel إلى mod_passenger ووجدنا أن الاستقرار قد تحسن بشكل كبير مع هذا الجهد المطلوب للإعداد والصيانة.اختيار جيد.
قطعة أخرى من الذهب:
جوش بيك جوهرة شريحة المضيف مليء بوصفات Capistrano التي هي أبسط بكثير وأكثر تنظيمًا من Deprec.لا يوجد شيء خاص بـ Slicehost أيضًا.
أنا أستضيف تطبيقاتي الجديدة مع Apache2 وPassenger على Ubuntu Hardy.يبدو أنه الخيار الأسهل والأفضل لمعظم السيناريوهات.لقد انضممت للتو إلى Slicehost.com لهذا الغرض.يبدو أنهم يحصلون على تقييمات جيدة ولديهم أسعار أكثر تنافسية لمضيفي الدرجة الأولى.
لا يمكنني حقًا أن أؤيدهم بعد لأنني عميل جديد ولكن مجموعة الأدلة ومجموعة خيارات الدعم مثيرة للإعجاب.
ما لم تذكره هو مدى ضخامة وشعبية تطبيقك.هذه المعايير يمكن أن تؤثر على عملية اتخاذ القرار.
Capistrano + Deprec لإعداد مجموعتي فعليًا على Ubuntu وإدارة النشر فعليًا.
وكيل Nginx لمجموعات Mongrel لبنية الخادم.إنها ليست أحدث التقنيات المتطورة ولكنها تعمل بشكل جيد، وقد تم توثيقها جيدًا، وهي ذات أداء عالٍ للغاية حتى عند العمل على خوادم VPS صغيرة.بافتراض أنك لم تقم بإزعاج التطبيق، يمكنك Slashdot على Slicehost VPS بسعة 128 ميجابايت وسيستمر في العودة للحصول على المزيد.
وقد قلت ذلك:كان هناك كثير من مسكتك في المرة الأولى، حتى اكتشفت كيف يعمل Nginx فعليًا.بعد ذلك، يصبح الأمر مذهلًا - مثل أباتشيليت صغير بلكنة روسية بسيطة.
