Docker Compose: تشغيل التطبيق وAPI وقاعدة البيانات معاً

لماذا تصف البيئة في ملف

يمكن أن يعتمد التطبيق على واجهة برمجة التطبيقات (API) وقاعدة البيانات وذاكرة التخزين المؤقت وعملية المعالجة. إن تشغيلها بشكل منفصل باستخدام أدوات التحكم اليدوية يشجع على النسيان والاختلافات بين الأشخاص. يجمع Docker Compose تعريفاتها في تكوين مُصدر: الصور والشبكات والأحجام والمعلمات. يشرح هذا التكوين بنية البيئة القابلة للتكرار. وهو لا يحل محل القرارات المعمارية أو إجراءات النسخ الاحتياطي، ولكنه يوفر أساسًا قابلاً للقراءة لبدء المكونات وإيقافها وفحصها. يجب أن يكون عضو الفريق الجديد قادرًا على فهم الخدمات دون إعادة بناء سلسلة من الأوامر المنسية.

تحديد الخدمات حسب المسؤولية

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

تنظيم الشبكات وأسماء الخدمات

يمكن للمكونات الموجودة في شبكة Compose مشتركة التواصل باستخدام أسماء الخدمات الخاصة بها. من واجهة برمجة التطبيقات (API)، لا يمكن الوصول إلى قاعدة البيانات بشكل عام ضمن المضيف المحلي، لأن هذا الاسم يشير إلى حاوية واجهة برمجة التطبيقات (API) نفسها. قم بتكوين عنوان الخدمة الأساسي ومنفذه الداخلي. المنافذ المنشورة على المضيف تخدم الوصول الخارجي؛ فهي ليست ضرورية لكل اتصال داخلي. شبكات منفصلة عندما يوفر ذلك حدودًا مفيدة. قد تحتاج الواجهة الأمامية العامة إلى إرفاق واجهة برمجة التطبيقات (API) دون إمكانية الوصول إلى القاعدة مباشرةً من المتصفح أو الإنترنت.

إدارة المتغيرات والتكوينات والأسرار

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

فهم التبعيات والتوافر

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

الحفاظ على البيانات وإعداد النسخ الاحتياطية

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

مثال على واجهة برمجة التطبيقات (API) والبيئة الأساسية

يمكن لمنصة صغيرة أن تعرض واجهة برمجة التطبيقات (API) على المضيف وتحتفظ بـ PostgreSQL على شبكة داخلية. تتلقى واجهة برمجة التطبيقات (API) سلسلة الاتصال الخاصة بها وتحتوي قاعدة البيانات على وحدة تخزين. ثم قم بإضافة عمليات التحقق من التوفر والترحيل الخاصة بالمشروع. المثال أدناه يوضح البنية فقط؛ يجب تحديد الأسرار والإصدارات والحدود وإعدادات التطبيق للبيئة الحقيقية. التكوين التجريبي المنسوخ بدون تحليل لا يعد تكوين إنتاج.

services:
  api:
    image: my-company/api:release-42
    ports:
      - '8080:8080'
    environment:
      DB_HOST: database
  database:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD is required}
volumes:
  db-data:

احتياجات التطوير والإنتاج منفصلة

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

تعرف على حدود الإنشاء

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

توفير بيئة يمكن للفريق استغلالها

يصف التسليم الكامل كيفية البدء والتحقق والتحديث والنسخ الاحتياطي والاستعادة. أضف أوامر تشخيصية مفيدة وسجل المواقع، دون الكشف عن الأسرار. اختبر التثبيت النظيف والتحديث باستخدام البيانات الموجودة. يمكن لـ Tuplify Studio إعداد بيئات Docker Compose لتطبيقاتك وتوثيق تشغيلها. لا تأتي القيمة من ملف YAML فقط: فهي تكمن في التشغيل القابل للتكرار والمسؤوليات الواضحة وإجراءات الاسترداد المفهومة من قبل الأشخاص الذين سيضمنون استمرارية الخدمة.

ورشة عمل: محاكاة التبعية غير المتاحة

ابدأ تشغيل البيئة ثم اجعل قاعدة البيانات غير متاحة في سياق الاختبار. راقب سلوك واجهة برمجة التطبيقات (API): أخطاء مفهومة، وعمليات إعادة المحاولة المحدودة، ونقص تشبع السجل. قم باستعادة قاعدة البيانات وتحقق من عودة الخدمة إلى حالة قابلة للاستخدام دون معالجة مخفية. كرر ذلك مع التهيئة البطيئة عند بدء التشغيل. ثم تحقق من المنافذ التي يمكن الوصول إليها من المضيف ومن الخدمات الأخرى. الهدف هو التحقق من التوفر والتعرض، وليس فقط أمر الإطلاق. قم بتوثيق النتائج والقيود، لأن التبعية التي تقع بعد بدء التشغيل لن يتم التعامل معها بالضرورة من خلال الشروط المستخدمة لتشغيل الحاويات وحدها.

الأسئلة المتداولة: المضيف المحلي والإنتاج

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

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

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