Flynn: لماذا لا تسورو؟

نوقش هذا

/ cc fsouza

titanous رأيت هذا الموضوع. إذا كان أكبر اختلاف بين tsuru و flynn هو tsuru يكون محددًا للويب ، مع القليل من الجهد يمكن تعديله.

أعتقد أنه إذا اجتمع المشروعان معًا فسيكون أفضل لهذا المشروع وسيسهل بناء مجتمع أقوى لإنشاء وصيانة هذا المشروع الجديد (tsuru + flynn) مثل ما حدث مع السكك الحديدية + merb.

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

الختام ، كما أعتقد أنه من الواضح ما هي الاختلافات الآن.

ما هي الاختلافات؟ ليس من الواضح بالنسبة لي ، هل هناك مصدر ما يمكنك أن توصي به يكون منطقيًا لجميع أعمال PaaS التي يتم إجراؤها؟

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

مما رأيته حتى الآن ، يبدو فلين جميلًا جدًا - أنا متحمس لتجربته قريبًا.

ملاحظة: لقد جئت إلى هنا عن طريق Googling "tsuru flynn"

keyvanfatehi شكرا على اهتمامك.

من الصعب مواكبة جميع مشاريع PaaS الموجودة هناك ، خاصة وأن العديد منها يتبع خرائط طريق خاصة أو غير متسقة. بشكل عام ، إليك ما نعتقد أن الاختلافات بين Flynn ومعظم مشاريع PaaS الأخرى (ليست مقارنة مباشرة مع tsuru ، فقط المساحة بشكل عام):

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

معظم مشاريع PaaS الأخرى هي على الأقل واحدة مما يلي: صعب / بطيء الإعداد والنشر ، مفيد فقط لأنواع محددة من التطبيقات ، يتطلب من المطورين إعادة تصميم تطبيقاتهم ، ومتجانسة. باختصار ، نعتقد أن Flynn تحاول حل المشكلات الصعبة وأن معظم المشاريع الأخرى لا تحاول حلها ، بسبب عمرها وقواعد المستخدم الحالية ودوافع التصميم.

مع وصول Flynn إلى استقرار الإنتاج وإكمال الميزات ، سنحاول توثيق الاختلافات على أساس كل مشروع.

danielsiders شكرا لك! أتطلع إلى رؤيتكم يبدعون في هذا الفضاء يا رفاق. أعاني بالتأكيد من وجود الكثير من العمليات التي تقع على كتفي (ولهذا السبب أنظر إلى Docker والأدوات من حوله). أود أن أصدق أنه يمكن حل العمليات ، كما كان ...

حتى الآن ، كانت تجربتي تستخدم عرض flynn-demo (بنجاح) والذي بدا وكأنه يشبه deis (وهو ما لم أجربه بشكل مباشر ، لكن لديهم مقطع فيديو رائع يُظهر سلوكها الشبيه بالوكو). لذا في هذا المستوى الضحل ، يبدو أن Deis و Flynn و heroku متطابقان.

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

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

keyvanfatehi دعم معظم PaaS لنشر التطبيقات على غرار Heroku (git push). حيث تختلف الأشياء حقًا هو نوع التطبيقات التي يمكن نشرها وما يحدث بعد نشر التطبيق.

(ملحوظة: يدعم Flynn أيضًا العديد من نماذج النشر الأخرى مثل Docker pull و git pull وأي شيء آخر تريد بناءه. حتى FTP لن يكون صعبًا)

keyvanfatehi ، في
فيما يتعلق بالخدمات ، فهي محددة جدًا بحيث لا يمكن التعامل معها بشكل جيد مع تطبيق واحد (تخيل مدى صعوبة التعامل مع قواعد البيانات ، nosql ، redis ، memcached ، elasticsearch ، تخزين الكائنات ، إلخ). فضلنا تحديد API للخدمة (حيث سيتم وضع منطق الأعمال للتعامل مع الخدمة) وسوف يتعامل tsuru بنفس الطريقة مع أي خدمة ، بغض النظر عن مدى اختلافها.

نحن ودودون للغاية ومنفتحون تمامًا على المساهمات والأفكار الجديدة. ما زلنا نعتقد أنه سيكون من الرائع العمل مع flynn في حل واحد (يمكننا تمديد tsuru للقاء نموذج flynn المثالي في المستقبل) ، لكننا نحترم رأيهم ورؤيتهم تمامًا ، لأنهم طموحات مثلنا :-)

TL ؛ الدكتور
نحن نعلم مدى أهمية الخدمات ، لذلك نقوم بتطوير طريقة أنيقة للتعامل مع هذا المطلب. يمكن لـ Tsuru التعامل مع أي خدمة بواجهة برمجة تطبيقات خدمة محددة جيدًا (مع بعض نقاط الدخول البسيطة مثل الإنشاء والإزالة والربط والتخطيط). لذلك ، سيتم التعامل مع كل تعقيدات خدمة معينة من خلال خدمة API الخاصة بها. لنقدم لك مثالاً على واجهة برمجة تطبيقات Redis الخاصة بنا: عند تشغيل # tsuru service-add redis (اسم الخدمة) redis_blognews (serviceinstancename) بالإضافة إلى (الخطة) ، فإنه سيُنشئ مثيل redis بالاسم redis_blognews والخطة الإضافية (التي توفر مثيلين من redis مع توفر عالٍ). لا يعرف Tsuru كيف سيتم إنشاؤه (حتى لو كان سيوفر بدرجة عالية) ، فسيتم التعامل معه بالكامل بواسطة Service-api. كما أنه يجعل من الممكن استخدام خدمات خارجية (حتى مملوكة) فقط لإنشاء خدمة API لذلك دون الحاجة إلى اللمس في كود tsuru. لذلك ، سيكون التعامل مع الخدمات أكثر مرونة ، وتجنب زيادة هذا التعقيد في تسورو. بعد ذلك يمكنك استخدام # tsuru bind redis_blognews --app yourblognewsapp وسيقوم tsuru بحقن بيانات اعتماد الخدمة في تطبيقك

أنا جديد في PaaSes وهو أمر محير. اخترت Tsuru وكنت العبث بها قليلاً. يبدو لي أن الأمر لا يختلف كثيرًا عن أهداف فلين. يمكنك تشغيل الأشياء ذات الحالة باستخدام واجهة برمجة تطبيقات الخدمة الخاصة بهم وهي معيارية للغاية ، حيث يكون لديك tsuru-api و docker-cluster و gandalf وما إلى ذلك.

ما زلت أتساءل عما إذا كان توحيد الجهود سيحقق منتجًا أفضل.

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