عندما تستهدف نفس المكون من قبل نشرين لمجموعتين مختلفتين، يتم تطبيق التعديلات على الجهاز حسب ترتيب إنشاء كل نشر. فالجهاز الذي ينتقل من المجموعة A إلى المجموعة B يحتفظ بالإعدادات الخاصة بالمجموعة التي جاءت من أحدث نشر. لإيجاد سلوك ثابت، من الأفضل عدم إعداد إعدادات لنفس المكون في مجموعتين في نفس الوقت.
لحل هذه المشكلة، هناك طريقة بسيطة وهي أن يكون لكل مجموعة مكون إعدادات خاص بها. أي أن تترك إعدادات المكون في نشرات com.example.app غير موجودة، وتقوم بإرسال مكون إعدادات مستقل لكل مجموعة على حدة، مثل:
- مكون
com.example.app.config.groupAفقط لمجموعة A. - مكون
com.example.app.config.groupBفقط لمجموعة B. - المكون الرئيسي
com.example.appالذي يُنشر بدون إعدادات محددة للمجموعات، ويُرسل إلى كلا المجموعتين.
عندما ينتقل جهاز من مجموعة A إلى مجموعة B، يقوم نظام Greengrass بحذف مكون إعدادات مجموعة A لأنه لم يعد مستهدفًا لهذا الجهاز، ويضيف مكون إعدادات مجموعة B بدلاً منه. كل مكون إعدادات ينتمي إلى نشر واحد فقط، لذلك لا حاجة لدمج الإعدادات أو النظر إلى أوقات النشر.
لضمان أن التطبيق يمكنه دائماً العثور على إعداداته بشكل ثابت، يمكنك اتباع طريقتين:
- جعل مكون الإعدادات يكتب إعداداته في ملف معين عند التثبيت أو التشغيل، ويوضح التطبيق قراءة هذا الملف.
- جعل التطبيق يقرأ إعداداته من خلال واجهة تواصل بين المكونات (IPC)، باستخدام أمر
GetConfiguration، والذي يقبل اسم مكون آخر ويُتابع التحديثات. يمكنك إعطاء مكونات الإعدادات اسمًا مشتركًا لسهولة العثور عليها.
بهذه الطريقة، لا حاجة لتحديث النشرات أو إصدار نسخ جديدة عند انتقال الجهاز بين المجموعات، مما يُسهل إدارة الإعدادات بشكل مستمر وسلس.
وإذا كانت إعدادات المجموعة تتغير بشكل متكرر أو تفضل أن تُركز عمليات النشر على الشيفرة فقط، يمكنك استخدام طرق أخرى:
- تخزين إعدادات كل جهاز بشكل مباشر في “ظل الجهاز” (Device Shadow) باسم محدد، ويقوم المكون بقراءة تلك الإعدادات ومتابعة تحديثها عبر إدارة الظل.
- تفعيل أحداث السجل (Registry) التي تتعلق بانضمام الأجهزة إلى المجموعات، وعند إضافة جهاز لمجموعة B، يُشغل قاعدة عبارات (Rule) التي تكتب إعدادات المجموعة في ظل الجهاز الخاص به.
- أو يمكن للمكون أن يتحقق من إعدادات المجموعة مباشرة من أدوات مثل AppConfig أو Parameter Store عند بداية التشغيل.
وأخيرًا، يمكنك برمجيًا أن تكرر إصدار نشر جديد لمجموعة معينة عند تغيير أعضاءها، لكن هذه الطريقة أضعف من حيث الأداء لأنها تُرسل تحديثات لجميع الأجهزة في المجموعة، وتبقى تعتمد على أوقات الإنشاء.
الأفضل هو الاعتماد على الطريقة الأولى لأنها أبسط، وتستخدم ميزات النشر التقليدية في نظام Greengrass، مما يسمح بتنقل الأجهزة بين المجموعات دون الحاجة لإصدار تحديثات جديدة باستمرار.