Discourse Automation رائع ومفيد حقًا، لكن الأتمتات المتاحة محدودة للغاية. يبدو الكثير منها وكأنه حلول مؤقتة[1] لمعالجة حالة استخدام خاصة لعميل CDCK معين، بدلاً من أدوات للأغراض العامة.
من الممكن إنشاء أتمتات مخصصة، ولكن لا توجد طريقة للعملاء المستضافين لإدخالها كما أرى. بالإضافة إلى ذلك، يبدو أنها يمكن أن تكون خطيرة جدًا. أنا متأكد من أنني أستطيع العمل مع موظفي Discourse الودودين لنشر أتمتة كتبتها، ولكن هذا يبدو الكثير من العمل من كلا الجانبين.
لذلك، إليك فكرتي:
- واجهة مسؤول[2] حيث يمكن للمرء توفير روابط لصور OCI[3] (باستخدام
registry.example.org/imagename:tag). - طريقة لربط مفتاح API بهذه الصورة (مرتبط بصفحة إدارة مفاتيح API الحالية)
- طريقة لربط خطاف ويب بهذه الصورة (مرتبط بصفحة إدارة خطافات الويب الحالية)
- إما إضافة خيار جدول زمني متكرر لهذا، أو (أفضل، في رأيي!) إضافة ذلك إلى خطافات الويب بشكل عام.
سيستمع وسيط/مرسل لخطافات الويب ويوجهها إلى الحاوية المطابقة، ويوفر مفتاح API كسر وعبء البيانات عبر stdin أو إلى منفذ HTTP. (أتخيل أن الكثير من هذه ستكون “مرة واحدة” - ستبدأ الحاوية، وتعالج حدثًا واحدًا، وتخرج - ولكن يمكن أن يكون هناك خيار للحاويات الدائمة (أو، ربما، للاستماع لمدة N ثوانٍ قبل الخروج).
سيتم تشغيل الحاويات بحدود موارد معقولة، إما بدون تخزين دائم أو الوصول إلى نفس مرفقات مجموعة التخزين والأشياء التي تدخل فيها. بالنسبة للمواقع المستضافة، يمكنني تخيل وقت وحدة المعالجة المركزية للأتمتة كحد آخر لكل خطة بجانب عدد مرات مشاهدة الصفحة ورسائل البريد الإلكتروني والتخزين.
يمكن توفير موقع API للموقع إما كمتغير بيئة أو سر آخر. سيتم حظر الوصول الشبكي الآخر افتراضيًا، على الرغم من أنه يجب أن يكون من الممكن السماح باتصالات صادرة محددة.
يمكن بالطبع إعداد مثل هذا الشيء الآن “على الجانب”، ولكن وجوده مدمجًا مع واجهات إدارة API و Webhooks سيكون رائعًا (ويتعامل بشكل أساسي مع مشكلة إدارة الأسرار بشكل كامل). بالإضافة إلى ذلك، فإن إعداد المرسل/الوسيط معقد بعض الشيء.