سؤال

هل هناك أي إرشادات للكتابة محرك تطبيقات جوجل بيثون رمز من شأنه أن يعمل بدون البنية التحتية ل Google على منصات أخرى؟

هل هناك أي محاولة معروفة لإنشاء إطار مفتوح المصدر يمكنه تشغيل التطبيقات المصممة لمحرك Google App على منصات أخرى؟

يحرر:

للتوضيح، والسؤال حقا هو:

إذا قمت بتطوير تطبيق على Google App Engine الآن، فهل سأتمكن من الترحيل إلى منصة أخرى لاحقا، أم أنه قفل في؟

هل كانت مفيدة؟

المحلول

هناك عدد من المكونات اللازمة لإجراء تطبيق محمول بالكامل:

  • بيئة وقت التشغيل نفسها. يمكن استئناف ذلك ببساطة نسبيا، من خلال إعداد خادم CGI أو FastCGI الذي يحوش بيئة محرك التطبيق (والذي يتم تحسينه بشكل أساسي بشكل أساسي CGI). معظم الكود للقيام بذلك موجود بالفعل في SDK. لسوء الحظ، لا توجد مجموعة أدوات سهلة المعبأة مسبقا لهذا بعد.
  • Datastore. إلى حد بعيد API الأكثر تعقيدا للميناء. هناك عدد من الجهود الجارية: appscale. يعمل على EC2 / Eucalyptus / Xen ويستخدم خلفية فرط الفعل أو HBase؛ لا تزال جودة بيتا كبيرة للغاية ولا يقومون بتوزيع موصل البيانات بشكل منفصل (إنها بدايات حل كامل تشغيل التطبيق الخاص بك). جينز هو / كان يكتب sqlite backend., ، وهناك مشروعي الخاص، bdbdatastore., ، والتي تستخدم BDB-JE كخلفية، وهي تعمل بشكل كامل (على الرغم من جودة بيتا). appdrop., ، والتي ذكرها الآخرون، ما عليك سوى استخدام خادم التطوير كخلفية، وبالتالي ليست مناسبة لاستخدام الإنتاج.
  • يحتاج المستخدمون API إلى استبدال شيء آخر، مثل API المستند إلى OpenID. مرة أخرى، بسيطة إلى حد ما، ولكن لا توجد حلول كريمة بعد.
  • يحتاج API MEMCACHTE إلى الواجهة الخلفية التي تستخدم Candion C Memcache Backends.
  • يعاني واجهة برمجة التطبيقات الأخرى وظيفية بشكل مثالي كجزء من SDK، لذلك لا تحتاج حقا إلى التنقل.
  • سيحتاج دعم Cron أيضا إلى تطبيق، وكذلك معالجة الخلفية، XMPP، إلخ، عندما تصبح متوفرة.

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

نصائح أخرى

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

تم تصحيح Django واستقلت للعمل في appengine التصحيح المشروع وهو الأكثر استخدام FW على Appengine.

قد ترغب في إحالة هذه الخطوة بخطوة مقدمة إلى تشغيل تطبيق Django على محرك التطبيق

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

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

يمكنك إنشاء تطبيقات APPENGINE باستخدام Framework Django Python (على الرغم من أن الإصدار المدعوم قليلا وراء أحدث إصدار Django الأخير). حيث تفقد قابلية قابلية (على الأقل الآن) هو عند استخدام GQL / Bigtable للمثابرة. هذه هي منصة قاعدة بيانات Google الخاصة ب Google. كما ذكر هانك هذا هو أحد أكبر الأسباب اللازمة لاستخدام Appengine فعليا، لكنها أيضا أكبر نقطة قفل واحدة.

فيما يلي بعض روابط لدعم Django في Appengine و GQL / BigTable:

حتى الآن، وجدت مضيفا تجريبيا يسمى app-drop. والتي هي قادرة على استضافة مشاريع Google App-Engine. هذا يجب أن يعني أنه على الأقل المستطاع لتشغيل مشاريع المحرك في التطبيق خارج البنية التحتية من Google.

ومع ذلك، من الواضح أن هذا غير مناسب بعد للإنتاج.

يجب أن يكون الرمز المحمولة في الغالب (يقومون بعمل جيد للغاية للإشارة إلى الوحدات النمطية التي لا يمكنك استخدامها في APPEngine والتي تتوافق التعليمات البرمجية المحظورة بها الوحدات المحرمة)، ولكن النقطة كاملة من Appengine هي الوصول إلى البنية التحتية لجوجل وبعد لا يوجد الكثير لكتابة الكود الخاص بك إلى قيود APPEngine إذا كنت لن تستخدم البنية التحتية الخاصة بهم.

AppDrop هو دليل على ميناء مفهوم APPEngine إلى خدمات Amazon Web / الحوسبة المرنة التي تم الانتهاء منها في أبريل من عام 2008. ويستخدم ملف مسطح بدلا من Bigtable ويعمل في مثيل واحد، لذلك هناك مشاكل تحجيم؛ لكن المطور يقول إنه استغرق الأمر أربعة أيام فقط، وربما يمكن معالجة هذه القيود من قبل الآخرين.

فعلت الترحيل العكسي من Vanilla Unix إلى محرك التطبيق مؤخرا بسهولة شديدة باستخدام موارد النفقات. في الأساس تكوين أي شيء منصة تعتمد كموارد ثم مبادلة / استبدال الموارد في تكوينات مختلفة.

http://piopio.appspot.com/w1000_1000.Resources.

انظر أيضا

http://aaron.oirt.rutgers.edu/myapp/docs/w1100_1200.wwiki.

للحصول على مثال مفصل من تبديل الموارد / التكوين. (ملاحظة: قد تذهب الروابط في النهاية، التطبيق هو تجريبي.)

الدفع typhoonae.. وبعد إنه في بيتا، ولكن قابلة للاستخدام تماما - انتقلنا واحدة من تطبيقاتنا إلى خادم inhouse هذا المكدس.

APPSCALE هو التنفيذ الأكثر تنضج للمصادر مفتوحة لمحرك تطبيقات Google. لقد كان في التنمية منذ عام 2008 ويدعم حاليا جميع اللغات الأربعة: بيثون وجافا و GO و PHP. لديها مستخدمين يقومون بتشغيل تطبيقهم في الإنتاج اليوم.

وتوضح الأسئلة الشائعة ما هو دعم واجهات برمجة التطبيقات وما تفتقر إليه:https://github.com/appscale/appcale/wiki/faqs.

(إخلاء المسؤولية: أعمل في المشروع)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top