كيفية بناء حزمة تطبيقات سهلة للمبتدئين دون تحويل كل خدمة إلى تبعية

تظل حزمة التطبيقات المناسبة للمبتدئين مفهومة عندما تكون لكل خدمة غاية واحدة، وتملك بياناتها، ويمكن أن تتعطل دون تعطيل وظائف منزلية أخرى غير مرتبطة بها.

لا يكمن الخطر في عدد الحاويات وحده. يظهر التعقيد عندما يعتمد كل تطبيق على قاعدة البيانات نفسها، وطبقة المصادقة نفسها، والوكيل العكسي نفسه، وخدمة DNS نفسها، ومسار التخزين نفسه، ونافذة التحديث نفسها، وحساب المسؤول نفسه. لذلك ينبغي أن تستخدم البنية الأولية أساسًا مشتركًا صغيرًا، وأن تبقي وسائل الراحة الاختيارية خارج مسارات الخدمات الأساسية، وأن توثّق بدقة المكونات التي يجب أن تعود قبل أن يصبح كل تطبيق قابلًا للاستخدام.

ابدأ بالنتائج المنزلية بدلًا من فهرس التطبيقات

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

تعرّف TechTarget بنية التطبيقات بأنها خريطة هيكلية توضّح كيفية تفاعل التطبيقات مع البرمجيات الوسيطة وقواعد البيانات والتطبيقات الأخرى لتلبية متطلبات المستخدمين. وتعد خريطة متطلبات المستخدم إلى المكونات هذه أكثر فائدة من التعامل مع كل تطبيق متاح على أنه ميزة مستقلة.

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

اجعل الأساس المشترك أصغر من طبقة التطبيقات

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

يوضح تحليل TechTarget للاعتماديات الدائرية أن المكونات شديدة الترابط تصبح صعبة التحديث والاختبار والنشر بشكل مستقل. وينطبق تحذير دورة الاعتماديات على الخادم المنزلي حتى عندما تكون البنية أصغر بكثير.

استخدم الحد الأدنى من الأساس المشترك المطلوب اليوم. ينبغي إضافة وكيل عكسي، أو طبقة هوية مركزية، أو خدمة DNS داخلية لأن عدة تطبيقات مستقرة تستفيد منها، لا لأن مخططًا يبدو أكثر اكتمالًا بإضافة مربع آخر.

امنح كل خدمة مالكًا واضحًا للبيانات ومسارًا مستمرًا

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

يوضح Better Stack أن بيانات الحاويات المستمرة تحتاج إلى دورة حياة مستقلة عن الحاوية التي تستخدمها. ويُعد نموذج دورة حياة البيانات المستقلة أساس استبدال تطبيق واحد دون جعل بياناته غامضة.

استخدم مسارات مضيف واضحة مثل /srv/appdata/service, /srv/data/service، و /srv/cache/service. سجّل المسؤول، وأذونات الكتابة، وقاعدة النسخ الاحتياطي، وطريقة الاستعادة لكل منها. ينبغي أن تكون لبيانات المنزل المشتركة جهة واحدة موثوقة، حتى عندما تقوم عدة تطبيقات بفهرستها أو عرضها.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

أنشئ مسارات وصول تتدهور بسلاسة

غالبًا ما يبدأ المبتدئ بعناوين IP ومنافذ محلية مباشرة، ثم يضيف نظام أسماء نطاقات محليًا، وHTTPS، ووكيلًا عكسيًا، ووصولًا عن بُعد. تحسّن كل طبقة سهولة الاستخدام، لكنها تضيف أيضًا موضعًا آخر قد يظهر فيه التطبيق غير متاح رغم أن التطبيق نفسه يعمل بشكل سليم.

يرسم دليل إعداد المختبر المنزلي مسار الطلب عبر نظام أسماء النطاقات (DNS)، والتوجيه، والوكيل العكسي، والتطبيق، واعتماده على قاعدة البيانات أو التخزين. ويساعد نموذج مسار الطلبات متعدد الطبقات المبتدئَ على فصل مشكلات الوصول عن مشكلات التطبيق.

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

أبقِ خدمات الراحة الاختيارية خارج المسارات الأساسية

يمكن للوحات المعلومات وفهارس البحث ووحدات ترحيل الإشعارات وبيانات الأعمال الفنية للوسائط والمصادقة المركزية تحسين التجربة، من دون أن تكون مطلوبة لبقاء البيانات الأساسية متاحة. صنّف هذه العناصر على أنها تبعيات اختيارية، بحيث يؤدي تعطل طبقة الراحة إلى انخفاض الوظائف بدلًا من انقطاع كامل.

يصف دليل TechTarget للمرونة نمط الحواجز بأنه عزل أجزاء النظام بحيث لا يتسبب عطل واحد في سلسلة أعطال تؤدي إلى فشل شامل. ويترجم مبدأ عزل الأعطال إلى قاعدة منزلية بسيطة: يجب أن تظل مسارات التخزين الأساسية والنسخ الاحتياطي والإدارة قابلة للاستخدام عند توقف الطبقات الاختيارية.

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

حدّث الخدمات وانسخها احتياطيًا كوحدات تعافٍ مستقلة

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

ترى Backblaze أن خطة التعافي لا تكون بقوة أحدث اختبار لها إلا، وتوصي بتمارين تعافٍ متكررة ومحدودة النطاق. ويُعد تمرين التعافي خدمةً بخدمة مناسبًا لحزمة صغيرة مستضافة ذاتيًا.

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

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

استخدم حزمة بداية يمكنها النمو من دون أن تتحول إلى سلسلة مترابطة

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

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

يساعد دليل ZimaSpace حول بناء أول خادم حول ثلاث خدمات مترابطة على إبقاء النطاق الأولي محدودًا. يناسب خادم ZimaBoard 2 المنزلي المصغر حزمة مدمجة تركز على التطبيقات، مع تخزين مدروس وعدد محدود من الخدمات. أما وحدة ZimaCube 2 للتخزين الشبكي السحابي الشخصي بالذكاء الاصطناعي فتصبح قاعدة أوضح عندما يكون التخزين عبر عدة أقراص، وتعدد المستخدمين في المنزل، والاحتفاظ بالبيانات لفترات أطول، والاسترداد الذي يضع التخزين أولًا، متطلبات أساسية بالفعل.

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