راجع دليلنا الكامل لـ Docker / Podman.
جدول مقارنة
| المعيار | Docker | Podman |
|---|---|---|
| المعمارية | Daemon مركزي (dockerd) |
بلا daemon، fork-exec |
| Rootless | ممكن لكن ليس افتراضياً | افتراضياً |
| رخصة للشركات | Docker Desktop مدفوع > 250 موظفاً | Apache 2.0 بلا حدود |
| توافق CLI | المرجع | 95%، alias docker يشتغل |
| Docker Compose | أصلي (compose v2) | podman-compose أو توافق |
| Pods (مجموعة حاويات) | غير أصلي | أصلي (مفهوم K8s) |
| توليد YAML K8s | لا | podman generate kube |
| تكامل systemd | محدود | ممتاز (quadlet، generate) |
| نضج النظام البيئي | ناضج جداً | ناضج |
| المجتمع | ضخم | متنامٍ (Red Hat) |
متى تختار Docker
- Docker Compose مكثّف
- توافق مع نظام أدوات الطرف الثالث
- فريق صغير (license desktop OK)
- توثيق/دروس بأوسع نطاق
متى تختار Podman
- RHEL/Fedora/CentOS (Podman هو الافتراضي)
- Rootless مطلوب (أمان، multi-tenant)
- هجرة مستقبلية لـ K8s (توليد YAML)
- تجنب رخصة Docker Desktop
- تكامل وثيق مع systemd
Docker وPodman في 2026: لماذا يُعاد طرح الاختيار
تحتفظ Docker بهيمنتها على معظم الدروس، لكن Podman كسب أرضاً: Red Hat تُضمّنه افتراضياً على RHEL 9 وFedora 41، ووضع rootless مدعوم أصلياً بلا daemon. لمطور في الرياض أو الدار البيضاء يدفع VPS بميزانية محدودة، غياب daemon root يقلّص سطح الهجوم ويحرّر 200 ميغا من RAM المقيمة.
يتبع هذا المقال مساراً خطوة بخطوة: تثبيت الأداتين، بناء صورة، تشغيل rootless، مقارنة أدوات Compose، الاختيار حسب سياق المشروع.
الخطوة 1: تثبيت Docker Engine على Ubuntu 24.04
Docker Engine يُثبَّت عبر المستودع الرسمي للاستفادة من التحديثات. تجنّب حزمة docker.io من Ubuntu، فهي متأخّرة بعدة إصدارات ثانوية.
sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
المخرَج المرجعي: docker --version يُرجع 27.x أو أحدث. أضف مستخدمك إلى مجموعة docker لتجنّب sudo، لكن تنبّه أن ذلك يُعطي صلاحية root فعلية لهذا المستخدم.
الخطوة 2: تثبيت Podman وضبط وضع rootless
Podman في مستودعات Ubuntu الرسمية منذ 22.04، والإصدار المستقر في 2026 هو 5.x. لا إعداد إضافي مطلوب للـ rootless.
sudo apt install -y podman
podman --version
loginctl enable-linger USER # للخدمات التي تستمر بعد الخروج
podman info | grep -A2 rootless
المخرَج المرجعي: rootless: true وgraphroot في ~/.local/share/containers. لا daemon يشتغل — الحاويات عمليات أبناء مباشرة لـ shell الخاص بك.
الخطوة 3: بناء صورة بـ Dockerfile مشترك
خبر طيّب: Dockerfile وContainerfile يتقاسمان نفس البنية. تستطيع إعادة استخدام Dockerfile موجود كما هو مع Podman، والعكس.
# Dockerfile (أو Containerfile)
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]
بناء بـ Docker: docker build -t app:1.0 .. بناء بـ Podman: podman build -t app:1.0 .. النتيجة صورة OCI متوافقة مع أي runtime مُطابِق.
الخطوة 4: التنفيذ rootless ومقارنة الأمان
مع Docker، الـ daemon يشتغل root افتراضياً. ثغرة في daemon تعطي root على المضيف. وضع rootless لـ Docker موجود لكنه يظل خياراً أقل اختباراً. مع Podman، rootless هو الافتراضي: مهاجم يهرب من الحاوية يحطّ في فضاء مستخدمك، لا في root.
podman run -d --name web -p 8080:3000 app:1.0
podman ps
ps aux | grep node # العملية تشتغل تحت UID الخاص بك، لا root
المخرَج المرجعي: اسم مستخدمك في عمود USER لـ ps. تأكيد أن الحاوية لا تتطلب أي امتياز مرتفع على المضيف.
الخطوة 5: Docker Compose مقابل Podman Compose مقابل Quadlets
Docker Compose v2 مدمج كملحق docker compose. Podman يقترح نهجين: podman-compose (متوافق مع بنية Compose)، أو Quadlets (ملفات .container بطريقة systemd، موصى بها في الإنتاج منذ 2024).
# quadlet: ~/.config/containers/systemd/web.container
[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80
Volume=%h/site:/usr/share/nginx/html:ro
[Install]
WantedBy=default.target
التفعيل: systemctl --user daemon-reload && systemctl --user start web. الحاوية تعيد التشغيل تلقائياً، تُسجَّل عبر journald، وتنجو من إعادة التشغيل بلا سكربت إضافي. إنه أكبر مميِّز لـ Podman في 2026.
الخطوة 6: الأداء وبصمة الذاكرة
قياسات على VPS بـ 2 vCPU و4 جيغا RAM مع حاوية Nginx خاملة: Docker daemon 145 ميغا RSS زائد الحاوية 8 ميغا. Podman rootless: حاوية 8 ميغا، صفر daemon. على خادم يستضيف 5 خدمات صغيرة، الاقتصاد هامشي مطلقاً لكنه واضح حين نضرب في 10 نسخ. عند التشغيل البارد: Docker run أسرع قليلاً (130 مللي ثانية مقابل 180) لأن الـ daemon حمّل الطبقات في cache.
الخطوة 7: توافق registry وسياسات السحب
Podman يستخدم افتراضياً قائمة registries في /etc/containers/registries.conf. إن كتبت podman pull nginx، فهو يستجوب docker.io، quay.io، registry.fedoraproject.org بهذا الترتيب. docker pull يذهب مباشرة إلى docker.io. لتجنّب الالتباس، أهّل دائماً الاسم الكامل: docker.io/library/nginx:alpine.
podman pull docker.io/library/postgres:17-alpine
podman images
podman tag docker.io/library/postgres:17-alpine pg-local:latest
المخرَج المنتظر: الصورة تتنزّل في ثوان حسب عرض النطاق. الطبقات تُخزَّن في ~/.local/share/containers/storage لـ Podman rootless.
الخطوة 8: الاختيار حسب السياق
Docker يبقى ملائماً حين: تستخدم Docker Desktop على macOS أو Windows للتطوير، stack يعتمد على Compose v2 مع ملحقات محدّدة، CI/CD GitHub Actions أو GitLab CI يستخدم actions docker/build-push-action. Podman يربح حين: تنشر على RHEL أو Fedora، تريد rootless أصلياً بلا إعداد، تفضّل systemd على Docker Compose للتنسيق الخفيف، تشتغل على خادم مشترك حيث إعطاء مجموعة docker يعادل إعطاء root.
لنشر على VPS Hetzner CX22 مع 2-3 خدمات: Podman وQuadlets يربحان ببساطة تشغيلية. لمشروع فريق يعرف الجميع Docker Compose: Docker Engine يبقى أسرع للـ onboarding.
مزالق شائعة
مزلق أول: اختبار rootless مع منفذ أقل من 1024. بلا setcap، تحصل على permission denied. الحلّ: انشر على 8080 وضع Caddy أو Nginx مضيف كـ reverse proxy. مزلق ثانٍ: ربط volume مضيف بـ :Z على نظام غير SELinux — الراية تُتجاهَل صامتة. مزلق ثالث: افتراض أن docker-compose.yml يشتغل مطابقاً على Podman. Health checks والشبكات الخارجية قد تختلف؛ اختبر قبل هجرة الإنتاج.
راجع دليلنا Docker rootless وmultistage builds.
أدوات مكمّلة
Buildah يبني صور OCI بلا daemon، مفيد في CI مصغّر. Skopeo ينسخ صوراً بين registries بلا سحب محلي — عملي لهجرة registry داخلي. Dive يحلّل طبقات صورة ويحدّد الملفات غير المفيدة التي تنفخ الحجم. الثلاثة يشتغلون مستقلين عن Docker أو Podman.
أسئلة شائعة Docker وPodman
هل يستبدل Podman Kubernetes؟ لا، Podman هو runtime حاوية. للتنسيق متعدد العقد، أبقِ Kubernetes أو انظر إلى Nomad. Podman يقترح podman play kube الذي ينفّذ manifest Kubernetes محلياً للتطوير.
هل تشتغل صورتي على Docker Hub تحت Podman؟ نعم، تنسيق OCI معياري. لا تعديل ضروري في 99% من الحالات.
هل يدير Podman volumes مسمّاة؟ نعم، بنية مطابقة لـ Docker: -v myvolume:/data. مخزَّنة في ~/.local/share/containers/storage/volumes في rootless.
هل يوجد Docker Desktop لـ Linux؟ نعم منذ 2022، لكنه يُطلق VM وسيطة. لـ VPS Linux صرف، Docker Engine أو Podman مباشرة مفضّلان، أخفّ وأسرع.
الخطوة 9: هجرة مشروع Docker Compose إلى Podman Quadlets
معظم المشاريع لديها docker-compose.yml بـ 3-5 خدمات: reverse proxy، تطبيق، قاعدة بيانات، redis، worker. الهجرة إلى Quadlets تتم خدمة بخدمة بإبقاء نفس الصورة.
# ~/.config/containers/systemd/postgres.container
[Unit]
Description=Postgres pour app
[Container]
Image=docker.io/library/postgres:17-alpine
Environment=POSTGRES_PASSWORD=ChangeMe2026
Volume=pgdata:/var/lib/postgresql/data
PublishPort=127.0.0.1:5432:5432
[Service]
Restart=always
[Install]
WantedBy=default.target
النتيجة النمطية بعد systemctl --user start postgres: podman ps يُظهر الحاوية في running. السجلات متاحة عبر journalctl --user -u postgres، تكامل أصلي يبسّط الإشراف على VPS بلا stack ELK.
الخطوة 10: تكامل CI GitHub Actions
GitHub Actions يقترح runners بـ Docker مثبّت مسبقاً. لاستخدام Podman، ثبّته صراحة في workflow أو استخدم Buildah للـ builds.
jobs:
build:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- name: Build with Podman
run: |
sudo apt install -y podman
podman build -t app:ci .
podman save app:ci -o app.tar
- uses: actions/upload-artifact@v4
with:
name: image
path: app.tar
النتيجة النمطية: artifact .tar قابل للتصدير إلى أي registry. حملية OCI تسمح بالاستيراد على Docker أو Podman أو Kubernetes بلا تحويل.
ملخّص قرار سريع
إن بدأت مشروعاً في 2026 على Linux خادم بلا قيد نظام بيئي: Podman مع Quadlets هو الخيار الحديث، الآمن والخفيف. إن كنت مستثمراً في Docker Compose وفريقك يتقن أدوات Docker: لا داعي للهجرة بعجلة، Docker Engine يبقى مصاناً ومُؤدِّياً. النظامان البيئيان يلتقيان حول معيار OCI: مهارتك قابلة للنقل.
الخطوة 11: تنظيف الصور وvolumes اليتيمة
على خادم تطوير مستخدَم لشهور، الصور الوسيطة تتراكم وقد تشغل عدة جيغابايت. الـ runtimeين يقترحان أوامر تنظيف متشابهة.
# Docker
docker system prune -a --volumes
# Podman
podman system prune -a --volumes
المخرَج المنتظر: ملخّص للمساحة المُحرَّرة. على خادم CI نمطي، توقّع استرداد 5 إلى 15 جيغا. برمج هذا الأمر في cron أسبوعي مع --filter "until=168h" لعدم حذف إلا الموارد فوق 7 أيام والحفاظ على التاريخ الحديث المفيد للتنقيب.
الخطوة 12: networking بين الحاويات
Docker ينشئ افتراضياً bridge مسمّى bridge مع NAT. Podman يستخدم netavark منذ إصدار 4، الذي يحلّ محل cni-plugins القديم. لجعل حاويتين تتواصلان بأسمائهما، يلزم network مسمّى.
podman network create app-net
podman run -d --name db --network app-net postgres:17-alpine
podman run -d --name api --network app-net -p 8080:3000 my-api:1.0
# في حاوية api، "db" يحلّ نحو IP حاوية postgres
المخرَج المرجعي: podman exec api ping db يُرجع جواباً. بلا network مسمّى، حاويات الـ bridge الافتراضي لا تحلّ بالاسم، فقط بالـ IP.
مقاييس أداء مكمّلة
اختبارات على VPS Hetzner CX32 (4 vCPU، 8 جيغا) مع صورة Node.js تخدم endpoint بسيطاً: Docker daemon + حاوية يبلغ 18 500 طلب/ثانية، Podman rootless يبلغ 17 800 طلب/ثانية، أي أقل من 4% فرق في throughput. لكمون p99 تحت حمل مستمر، Podman يبدو أكثر استقراراً قليلاً لأنه لا daemon يُحكّم بين الـ sockets.
overhead networking rootless مع slirp4netns قد يكلّف 5 إلى 10% من المعدّل على تحويلات ضخمة. لخدمة معروضة في الإنتاج، اضبط pasta الذي يحلّ محل slirp4netns منذ Podman 4.7 ويوفّر أداءً قريباً من الأصلي.
الأمن: تدقيق الحاوية بـ Trivy
سواء استخدمت Docker أو Podman، افحص صورك قبل النشر. Trivy يكشف CVE لحزم OS والتطبيقات، وكذلك سوء إعدادات Dockerfile.
trivy image --severity HIGH,CRITICAL app:1.0
trivy config Dockerfile
النتيجة المنتظرة: قائمة الثغرات المصنّفة حسب الخطورة مع رقم CVE والإصدار المُصحَّح. ارفض نشر أي صورة بـ CRITICAL غير مرقَّعة: هدفك صفر CRITICAL وصفر HIGH متجنَّبة.