الصورة: على قد احتياجك، مش أصغر صورة ممكنة

اتجاه شائع: «صغّر الصورة لكل سطر». لكن الهدف الصح هو حجم كافٍ وسليم — صورة مفرّغة من كل شيء (من غير أدوات compile) بيبقى صعب تركّب بيها أي امتداد وقت التشغيل. الحل المتوازن هو البناء متعدد المراحل:

مرحلة 1 (builder): uv sync — نركّب كل التبعيات
مرحلة 2 (runtime): ننسخ بس الملفات الجاهزة على صورة slim سليمة

الناتج: صورة صغيرة، لكنها تحتفظ بكل خصائص التشغيل اللي محتاجها فعلًا.

التشغيل بغير root — مش اختيار نفسي

حاوية بنظام root: لو حصل ثغرة في التطبيق، المهاجم بياخد جذر بداخلها. القاعدة:

• أنشئ USER في الـ Dockerfile بصلاحية محدودة.
• علّم مجلدات اللوجز والبيانات بحيث يكتب فيها المستخدمده بس.

كده تشغيل الحاوية بصلاحيات أقل — عزل أخير قبل أي مشكلة.

الـ healthcheck: اعتماد صحة، لا اعتماد توفر

في docker-compose، خطأي القديم كان depends_on الساذج — ده بيربط «التوفر» (الحاوية اتشغّلت) مش «الصحة» (التطبيق جاهز فعلًا). التصحيح:

services:
  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 3s
      timeout: 2s
      retries: 30
  app:
    build: .
    depends_on:
      redis:
        condition: service_healthy

نقطتا صحة للتطبيق نفسه

وأهم: التطبيق نفسه عنده نقطتا فحص — /health/live و /health/ready:

HEALTHCHECK CMD curl -f http://localhost:8000/health/ready

• live: الحاوية شغالة.
• ready: شغالة وقادرة (بتفحص ريديس فعلًا) — فالموزّع ما يبعتهوش ترافيك قبل الجهوز.

تطبيقان في ملف واحد

الكومبوز بيشغّل خدمتين (app + redis) في نفس الشبكة، فبيئة مطوّرة وكاملة جاهزة بأمر واحد:

docker compose up --build

بدل ما كل مشروع يعيد اختراع الإعداد.

الخلاصة

Docker للبايثون مش أحجية «أصغر صورة» — انضباط: بناء متعدد مراحل على قد الحاجة، صلاحيات قليلة، تبعية تنتظر صحة فعلية، ونقطة فحص واحدة يثق فيها الجميع. بالممارسة، دي بتقلب كل مشاكل «شغال عندي بس بينفجر في النشر».