فهم صور دوكر (Docker Images) وكيفية سحبها وإدارتها

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

في سياق الأعمال السحابية وفرق CI/CD، فهم كيفية بناء وسحب وإدارة الصور يختصر وقت النشر، يقلل أخطاء التوافق، ويرفع مستوى الأمان التشغيلي. وإذا كنت قد قرأت مقال مشكلة “الكود يعمل على جهازي فقط” وكيف يحلها Docker نهائياً؟ فستعرف أن الصور هي العنصر الذي يجعل هذا الوعد قابلاً للتنفيذ عملياً.

ما هي صورة دوكر ولماذا تختلف عن الحاوية؟

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

تعتمد الصور على بنية الطبقات Layered Filesystem. كل تعليمة داخل Dockerfile مثل RUN أو COPY تُنشئ طبقة جديدة. هذه البنية تسمح بإعادة استخدام الطبقات المشتركة بين الصور، ما يوفر المساحة ويُسرّع عمليات السحب والبناء في البيئات الكبيرة.

مكونات صورة دوكر داخلياً

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

أهم العناصر التي تتكون منها الصورة

• صورة أساسية Base Image مثل alpine أو ubuntu.
• طبقات أوامر البناء الناتجة من Dockerfile.
• بيانات وصفية Metadata مثل المتغيرات والمنافذ وأمر التشغيل.
• وسوم تعريفية Tags لتحديد الإصدارات مثل 1.0.4 أو latest.

من أين يتم سحب الصور؟

غالباً ما يتم سحب الصور من سجل مركزي Container Registry مثل Docker Hub أو GitHub Container Registry أو سجلات سحابية مثل ECR وGCR. السجل هو المستودع الذي يحفظ الإصدارات ويجعلها قابلة للتوزيع بين بيئات التطوير والاختبار والإنتاج.

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

كيفية سحب صورة دوكر عملياً

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

docker pull nginx
docker pull nginx:1.25
docker pull redis:7-alpine
docker pull python:3.12-slim

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

docker images

ولتشغيل حاوية مباشرة من الصورة، يمكنك استخدام الأمر التالي، وهو امتداد عملي لما تم شرحه في مقال أول حاوية (Container) لك: تشغيل سيرفر ويب Nginx بكلمة واحدة:

docker run -d --name web01 -p 8080:80 nginx:1.25

فهم الوسوم والإصدارات في الصور

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

استخدم دائماً وسوماً ثابتة مثل app:2.3.1 أو حتى image@sha256:... لضمان قابلية التتبع ومنع التغيير الصامت الذي قد يسبب Downtime أو فشل النشر.

إدارة الصور محلياً بكفاءة

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

أوامر مهمة لإدارة الصور

docker image ls
docker image inspect nginx:1.25
docker image rm nginx:1.25
docker image prune
docker system prune -a

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

قبل تنفيذ docker system prune -a على خادم مشترك أو عقدة بناء مركزية، راجع الحاويات النشطة والمخططات الزمنية لوظائف CI/CD حتى لا تحذف طبقات يعتمد عليها بناء لاحق وتسبب بطئاً أو فشلاً غير متوقع.

العلاقة بين صور دوكر وملف Dockerfile

الصورة الجيدة تبدأ من Dockerfile مصمم بعناية. كل قرار داخل الملف يؤثر على حجم الصورة، سطح الهجوم الأمني، وزمن البناء. في المشاريع الاحترافية، يتم اعتماد صور صغيرة الحجم وتقنيات Multi-stage Build لعزل أدوات البناء عن بيئة التشغيل النهائية.

docker build -t myapp:1.0.0 .
docker tag myapp:1.0.0 myrepo/myapp:1.0.0
docker push myrepo/myapp:1.0.0

هذا التسلسل هو العمود الفقري لأي دورة DevOps حديثة، وهو مرتبط مباشرة بمفهوم الأتمتة الذي تم توضيحه في مقال ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟.

أفضل الممارسات الأمنية عند التعامل مع الصور

إدارة الصور ليست مسألة تشغيل فقط، بل أيضاً مسألة ثقة وسلسلة توريد برمجية Software Supply Chain. سحب أي صورة مجهولة من الإنترنت إلى بيئة حساسة قد يفتح الباب لبرمجيات خبيثة أو إعدادات ضعيفة.

• اعتمد صوراً موثقة ورسمية من ناشرين معروفين.
• ثبّت الإصدارات ولا تعتمد على وسوم متغيرة.
• افحص الصور باستخدام أدوات مثل Trivy أو Docker Scout.
• قلل عدد الحزم داخل الصورة لتصغير سطح الهجوم.
• شغّل العمليات باستخدام مستخدم غير جذري non-root user.

لا تستخدم صوراً قديمة غير محدثة في بيئات الإنتاج، خصوصاً للخدمات المعرضة للإنترنت مثل Nginx وRedis وPostgreSQL. التحديثات الأمنية للصورة قد تكون الفاصل بين خدمة مستقرة واختراق مكلف.

دور الصور في Kubernetes وبيئات النشر المستمر

عند الانتقال إلى Kubernetes، تصبح الصورة المرجع الأساسي الذي تعتمد عليه كل Pod. لذلك فإن أي خلل في الوسم أو السجل أو صلاحيات الوصول قد يمنع الجدولة أو يؤدي إلى فشل التحديث المرحلي Rolling Update.

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

خاتمة

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

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