Podman چیست؟ پادمن (Podman) یک ابزار متن‌باز برای ساخت، اجرا و مدیریت کانتینرها، ایمیج‌ها و گروه‌هایی از کانتینرها به نام Pod است. این ابزار که با مشارکت مهندسان Red Hat و جامعه متن‌باز توسعه یافته، یکی از مهم‌ترین جایگزین‌های Docker محسوب می‌شود و به‌خصوص به دلیل معماری Daemonless، پشتیبانی از Rootless Containers و یکپارچگی با Linux و systemd مورد توجه توسعه‌دهندگان، مدیران سرور و متخصصان DevOps قرار گرفته است.

اگر قبلاً با Docker کار کرده باشید، بسیاری از دستورات Podman برایتان آشنا خواهند بود. برای مثال، می‌توانید با دستور podman run یک کانتینر اجرا کنید، با podman ps وضعیت آن را ببینید و با podman build یک Container Image بسازید.

اما شباهت دستورات به این معنی نیست که Podman و Docker کاملاً یکسان هستند. مهم‌ترین تفاوت آن‌ها در معماری مدیریت کانتینر، مدل دسترسی، نحوه اجرای سرویس‌های دائمی و ابزارهای مدیریت برنامه‌های چندکانتینری است.

Podman همچنین یک قابلیت مهم دارد که نام آن از همین ویژگی گرفته شده است: مدیریت Pod. در این مدل، چند کانتینر مرتبط می‌توانند در یک گروه قرار بگیرند و از Namespaceهای مشترک، به‌ویژه فضای شبکه، استفاده کنند. این مفهوم شباهت زیادی به Pod در Kubernetes دارد.

در این راهنمای جامع بررسی می‌کنیم Podman چیست، چگونه کار می‌کند، چه تفاوتی با Docker دارد، معماری Daemonless و Rootless به چه معناست و چگونه می‌توان Podman را روی Ubuntu، Fedora و RHEL نصب کرد. سپس ساخت Container، مدیریت Image، ایجاد Pod، کار با Network و Volume، اجرای Podman Compose و راه‌اندازی سرویس دائمی با Quadlet و systemd را به‌صورت عملی آموزش می‌دهیم.

اگر هنوز با مفاهیم Container، Image و Containerization آشنا نیستید، پیشنهاد می‌کنیم ابتدا مقاله Docker چیست؟ آموزش داکر، کانتینر و Docker Compose را مطالعه کنید. این مقاله مفاهیم پایه را توضیح می‌دهد و راهنمای فعلی بر ویژگی‌های اختصاصی Podman تمرکز دارد.

سطح مقاله: مقدماتی تا پیشرفته | مناسب برای: توسعه‌دهندگان، مدیران لینوکس، متخصصان DevOps، مدیران VPS و سرور اختصاصی، مهندسان زیرساخت و تیم‌های Cloud Native.

فهرست مطالب

Podman چیست؟

Podman مخفف Pod Manager است و به فارسی می‌توان آن را «مدیر پادها» نامید.

این ابزار یک Container Engine متن‌باز است که امکان مدیریت چرخه عمر کانتینرها را فراهم می‌کند.

به کمک Podman می‌توان:

  • Container Image دریافت کرد.
  • از Image یک یا چند Container ساخت.
  • کانتینرها را اجرا، متوقف و حذف کرد.
  • Container Image اختصاصی ساخت.
  • چند کانتینر را داخل یک Pod گروه‌بندی کرد.
  • Network و Volume مدیریت کرد.
  • کانتینرها را بدون دسترسی root اجرا کرد.
  • سرویس‌ها را با systemd مدیریت کرد.
  • Imageها را در Registryهای عمومی یا خصوصی منتشر کرد.

Podman از استانداردهای Open Container Initiative یا OCI پشتیبانی می‌کند. به همین دلیل می‌تواند با بسیاری از Container Imageهایی که برای Docker ساخته شده‌اند کار کند.

برای مثال Image رسمی Nginx را می‌توان بدون Docker Engine اجرا کرد:

podman run -d \
  --name web \
  -p 127.0.0.1:8080:80 \
  docker.io/library/nginx:stable-alpine

این دستور یک کانتینر Nginx ایجاد می‌کند و پورت ۸۰۸۰ میزبان را به پورت ۸۰ کانتینر متصل می‌کند.

بنابراین برای اجرای کانتینر با Podman نیازی به نصب Docker Engine نیست.

چرا Podman ساخته شد؟

Docker نقش بسیار مهمی در فراگیر شدن Containerization داشت؛ اما معماری سنتی Docker بر وجود یک سرویس مرکزی به نام dockerd استوار است.

در این معماری، Docker Client درخواست‌ها را به Docker Daemon ارسال می‌کند و Daemon عملیات مربوط به کانتینرها را مدیریت می‌کند.

این مدل بسیار قدرتمند است، اما در بعضی محیط‌ها چالش‌هایی ایجاد می‌کند؛ مخصوصاً زمانی که هدف، کاهش دسترسی‌های سطح بالا، اجرای کانتینر توسط کاربران عادی یا یکپارچگی مستقیم با ابزارهای مدیریت سرویس لینوکس باشد.

Podman با رویکرد متفاوتی توسعه پیدا کرد:

  • عدم نیاز به یک Daemon مرکزی دائمی برای اجرای محلی کانتینرها
  • پشتیبانی از اجرای Rootless
  • امکان مدیریت مستقیم Podها
  • سازگاری با OCI
  • استفاده از ابزارهای استاندارد اکوسیستم لینوکس
  • یکپارچگی با systemd

هدف Podman صرفاً جایگزین کردن نام دستور docker با podman نیست؛ بلکه ارائه معماری متفاوتی برای مدیریت Containerهاست.

مهم‌ترین ویژگی‌های Podman

۱. معماری Daemonless

برای اجرای کانتینرهای محلی به یک سرویس مرکزی دائماً فعال مانند Docker Daemon نیاز ندارد.

۲. پشتیبانی از Rootless Container

کاربران عادی می‌توانند با استفاده از User Namespace و تنظیمات مناسب سیستم، کانتینر ایجاد و اجرا کنند.

۳. مدیریت Pod

چند کانتینر مرتبط می‌توانند یک Pod تشکیل دهند و فضای شبکه مشترک داشته باشند.

۴. سازگاری با OCI

امکان استفاده از Container Imageهای استاندارد و Runtimeهای سازگار وجود دارد.

۵. شباهت دستورات با Docker

بسیاری از دستورهای روزمره Podman و Docker مشابه هستند.

۶. یکپارچگی با systemd

با استفاده از Quadlet می‌توان کانتینرها و Podها را به‌صورت سرویس‌های مدیریت‌شده در Linux اجرا کرد.

۷. پشتیبانی از Registryهای مختلف

Podman می‌تواند با Registryهایی مانند Docker Hub، Quay.io و Registryهای خصوصی کار کند.

۸. قابلیت استفاده در محیط‌های توسعه و Production

این ابزار هم برای محیط توسعه شخصی و هم برای اجرای سرویس‌های عملیاتی قابل استفاده است.

معماری Podman چگونه کار می‌کند؟

برای درک معماری Podman باید چند جزء مهم را بشناسیم.

User / Developer
       |
       v
   Podman CLI
       |
       v
     libpod
       |
       +----------------+
       |                |
       v                v
 Container Image     OCI Runtime
                        |
                        v
                    Container
                        |
                        v
                   Linux Kernel

این نمودار ساده‌شده است و تمام اجزای داخلی را نمایش نمی‌دهد.

Podman برای مدیریت کانتینرها از کتابخانه libpod و برای اجرای آن‌ها از Container Runtimeهای سازگار با OCI استفاده می‌کند.

اجزایی مانند conmon نیز در نظارت بر فرآیندها و مدیریت وضعیت کانتینر نقش دارند.

بنابراین Daemonless بودن به معنی نبود هیچ فرآیند پس‌زمینه‌ای نیست؛ بلکه یعنی اجرای کانتینر به یک Docker-style Central Daemon دائمی وابسته نیست.

Daemonless چیست و چرا مهم است؟

Daemon فرآیندی است که در پس‌زمینه سیستم‌عامل اجرا می‌شود و معمولاً خدمات مشخصی ارائه می‌دهد.

Docker در معماری متداول خود از یک Daemon مرکزی استفاده می‌کند:

Docker CLI
    |
    v
Docker Daemon
    |
    v
Containers

Podman برای عملیات محلی از مدل متفاوتی استفاده می‌کند:

Podman CLI
    |
    v
OCI Runtime
    |
    v
Container Process

در عمل، فرآیندهای کمکی مانند conmon می‌توانند پس از پایان فرمان Podman به نظارت بر کانتینر ادامه دهند.

مزایای معماری Daemonless

  • عدم وابستگی به Daemon مرکزی دائمی
  • امکان مدیریت کانتینرها در سطح کاربر
  • کاهش برخی ریسک‌های مرتبط با API مدیریتی دارای دسترسی بالا
  • یکپارچگی مناسب با systemd
  • استقلال بیشتر محیط کاربران مختلف

بااین‌حال Daemonless بودن به‌تنهایی تضمین نمی‌کند که Podman در تمام سناریوها سریع‌تر یا امن‌تر از Docker باشد.

امنیت و عملکرد واقعی به تنظیمات، Runtime، Kernel، نوع Workload و نحوه Deployment بستگی دارند.

Rootless Container چیست و چگونه کار می‌کند؟

یکی از مهم‌ترین ویژگی‌های Podman، پشتیبانی گسترده از Rootless Containers است.

Rootless یعنی کاربر عادی Linux بتواند کانتینر را بدون اجرای Podman با دسترسی root مدیریت کند.

برای مثال:

podman run --rm \
  docker.io/library/alpine:3.22 \
  id

این دستور را می‌توان با یک کاربر عادی اجرا کرد؛ البته باید قابلیت‌های Rootless روی میزبان پشتیبانی و پیکربندی شده باشند.

Rootless چگونه امکان‌پذیر می‌شود؟

Podman از قابلیت User Namespace در Linux استفاده می‌کند.

User Namespace امکان نگاشت شناسه‌های کاربری داخل کانتینر به شناسه‌های متفاوت در میزبان را فراهم می‌کند.

در نتیجه ممکن است فرآیندی داخل کانتینر UID صفر داشته باشد، اما در میزبان اختیار واقعی کاربر root را نداشته باشد.

Inside Container:
UID 0 (root in namespace)
          |
          v
User Namespace Mapping
          |
          v
Host:
Unprivileged User / Subordinate UID

این ویژگی سطح دسترسی کانتینر به منابع میزبان را محدودتر می‌کند.

آیا Rootless همان اجرای برنامه با USER غیر root است؟

خیر.

این دو مفهوم با یکدیگر تفاوت دارند:

  • Rootless Container: کانتینر توسط کاربر غیر root در میزبان مدیریت و اجرا می‌شود.
  • Non-root Container Process: برنامه داخل کانتینر با کاربری غیر از UID صفر اجرا می‌شود.

می‌توان هر دو روش را هم‌زمان استفاده کرد.

آیا Docker هم Rootless دارد؟

بله. Docker نیز از Rootless Mode پشتیبانی می‌کند.

بنابراین ادعای اینکه «فقط Podman می‌تواند بدون root کانتینر اجرا کند» درست نیست.

تفاوت مهم این است که Rootless بودن از ابتدا یکی از ویژگی‌های اصلی و محوری طراحی Podman بوده است.

محدودیت‌های Rootless

اجرای Rootless مزایای امنیتی مهمی دارد، اما ممکن است با محدودیت‌هایی همراه باشد:

  • محدودیت انتشار پورت‌های Privileged مانند ۸۰ و ۴۴۳ در بعضی تنظیمات
  • نیاز به User Namespace
  • نیاز به تنظیمات UID/GID Mapping برای برخی Workloadها
  • پیچیدگی Permission در Bind Mountها
  • محدودیت دسترسی مستقیم به بعضی Deviceها
  • وابستگی بعضی Resource Limitها به cgroups و تنظیمات میزبان

به همین دلیل Rootless معمولاً انتخاب مناسبی برای بسیاری از سرویس‌هاست، اما قبل از استفاده Production باید با نیازهای همان برنامه آزمایش شود.

Pod در Podman چیست؟

مفهوم Pod یکی از ویژگی‌های مهم Podman است.

Pod گروهی از یک یا چند کانتینر مرتبط است که می‌توانند برخی Namespaceها، به‌خصوص Network Namespace، را با یکدیگر به اشتراک بگذارند.

این مفهوم از نظر طراحی شباهت زیادی به Pod در Kubernetes دارد.

یک مثال ساده

فرض کنید یک برنامه شامل دو کانتینر باشد:

  • Web Server
  • Monitoring Sidecar

می‌توان این دو را در یک Pod اجرا کرد:

Pod: web-pod
   |
   +-- Nginx Container
   |
   +-- Monitoring Container
   |
   +-- Shared Network Namespace

کانتینرهای داخل این Pod می‌توانند از طریق localhost با یکدیگر ارتباط برقرار کنند.

تفاوت Pod با Network معمولی چیست؟

در یک Network معمولی، هر کانتینر اغلب Network Namespace خودش را دارد و از طریق آدرس شبکه یا نام سرویس با دیگر کانتینرها ارتباط برقرار می‌کند.

اما کانتینرهای عضو یک Pod می‌توانند Network Namespace مشترک داشته باشند.

در این حالت:

  • IP و فضای پورت مشترک دارند.
  • می‌توانند از طریق localhost ارتباط برقرار کنند.
  • دو سرویس نمی‌توانند هم‌زمان یک پورت و آدرس یکسان را در همان Namespace اشغال کنند.
  • انتشار پورت‌ها معمولاً هنگام ساخت Pod تعریف می‌شود.

Infra Container چیست؟

Podman به‌صورت پیش‌فرض معمولاً یک Infra Container برای Pod ایجاد می‌کند.

این کانتینر به حفظ Namespaceهای مشترک و چرخه عمر Pod کمک می‌کند.

Infra Container همان Application اصلی نیست و معمولاً کار پردازشی سنگینی انجام نمی‌دهد.

Podman، Buildah و Skopeo چه ارتباطی دارند؟

اکوسیستم Podman فقط به یک دستور CLI محدود نمی‌شود.

Podman

برای مدیریت کانتینرها، Podها، Imageها، Networkها و Volumeها استفاده می‌شود.

Buildah

ابزاری تخصصی برای ساخت Container Image است.

Buildah می‌تواند با Containerfile یا Dockerfile کار کند و برای ساخت Image بدون نیاز به Docker Daemon مناسب است.

Skopeo

ابزاری برای Inspect، Copy و مدیریت Imageها میان Registryها و Storageهای مختلف است.

برای مثال می‌توان از Skopeo برای بررسی اطلاعات یک Image بدون اجرای آن استفاده کرد.

OCI Runtime

Runtimeهایی مانند crun و runc مسئول راه‌اندازی فرآیندهای کانتینری مطابق استانداردهای OCI هستند.

conmon

ابزار نظارت بر فرآیند کانتینر است و به مدیریت وضعیت، خروجی و چرخه عمر آن کمک می‌کند.

Netavark و aardvark-dns

در نسخه‌های جدید Podman، Netavark از اجزای مهم مدیریت شبکه است و aardvark-dns می‌تواند برای DNS و Name Resolution کانتینرها استفاده شود.

البته جزئیات دقیق این اجزا به نسخه و تنظیمات Podman بستگی دارد.

تفاوت Podman و Docker چیست؟

Podman و Docker هر دو امکان ساخت و اجرای Container Imageهای استاندارد را فراهم می‌کنند، اما معماری و تجربه مدیریت آن‌ها کاملاً یکسان نیست.

ویژگیPodmanDocker
معماری متداولDaemonless برای اجرای محلیClient-Server با Docker Daemon
Rootlessپشتیبانی محوریپشتیبانی با Rootless Mode
دستورات CLIمشابه Dockerاستاندارد رایج Docker CLI
پشتیبانی OCIبلهبله
مدیریت Podبومیدر Docker Engine به همان شکل وجود ندارد
برنامه‌های چندکانتینریPod، Compose Provider، QuadletDocker Compose
systemdیکپارچگی قوی از طریق Quadletامکان مدیریت سرویس Docker با systemd
ابزار DesktopPodman DesktopDocker Desktop
اجرای Linux Container در macOSبا Linux VMبا Linux VM
ابزارهای CI/CDقابل استفاده؛ نیازمند بررسی سازگاریاکوسیستم گسترده و شناخته‌شده

آیا Podman از Docker امن‌تر است؟

Podman به‌دلیل مدل Daemonless و پشتیبانی گسترده از Rootless، مزایای امنیتی مشخصی در برخی سناریوها دارد.

اما نمی‌توان گفت هر نصب Podman الزاماً از هر نصب Docker امن‌تر است.

برای مثال یک کانتینر Podman که به‌صورت Privileged و با دسترسی گسترده به فایل‌های میزبان اجرا می‌شود، همچنان می‌تواند ریسک بالایی داشته باشد.

در مقابل، Docker با Rootless Mode، محدودسازی Capabilityها، Seccomp و سایر تنظیمات امنیتی می‌تواند در محیط‌های حساس استفاده شود.

آیا Podman سریع‌تر از Docker است؟

پاسخ قطعی وجود ندارد.

عملکرد نهایی به OCI Runtime، Network Backend، Storage Driver، تنظیمات Kernel و نوع Workload بستگی دارد.

برای انتخاب حرفه‌ای بهتر است روی پروژه واقعی Benchmark انجام دهید.

Podman بهتر است یا Docker؟

اگر تیم شما از Docker Compose، ابزارهای Docker API و Pipelineهای مبتنی بر Docker استفاده گسترده‌ای دارد، مهاجرت الزاماً مزیت اقتصادی یا عملیاتی ایجاد نمی‌کند.

اما اگر اجرای Rootless، یکپارچگی systemd و معماری بدون Daemon مرکزی برایتان اهمیت زیادی دارد، Podman گزینه بسیار جذابی است.

آموزش نصب Podman روی Ubuntu، Fedora و RHEL

Podman در مخازن رسمی بسیاری از توزیع‌های Linux موجود است.

توجه: نسخه‌ای که از مخزن سیستم‌عامل نصب می‌شود ممکن است از آخرین نسخه منتشرشده Podman قدیمی‌تر باشد. قبل از استفاده از ویژگی‌های جدید، نسخه نصب‌شده و مستندات همان نسخه را بررسی کنید.

نصب Podman روی Ubuntu ۲۴.۰۴

ابتدا Package Index را به‌روزرسانی کنید:

sudo apt update

سپس Podman را نصب کنید:

sudo apt install -y podman

برای مشاهده نسخه:

podman --version

برای بررسی اطلاعات محیط:

podman info

نصب Podman روی Fedora

sudo dnf install -y podman

نصب Podman روی RHEL

روی نسخه‌های پشتیبانی‌شده RHEL می‌توانید Podman را از مخازن رسمی نصب کنید:

sudo dnf install -y podman

در محیط‌های سازمانی RHEL ممکن است بسته‌های Container Tools و سیاست‌های پشتیبانی توزیع نیز اهمیت داشته باشند.

نصب Podman روی Debian

sudo apt update

sudo apt install -y podman

آیا پس از نصب باید سرویس Podman را Start کنیم؟

برخلاف Docker Engine، برای اجرای معمول کانتینرهای محلی با Podman نیازی به راه‌اندازی یک Daemon مرکزی دائمی نیست.

بنابراین پس از نصب، می‌توانید مستقیماً دستورات Podman را اجرا کنید.

البته برای ارائه Podman API به ابزارهای خارجی، امکان راه‌اندازی Socket-activated Service وجود دارد که موضوعی جداگانه است.

تنظیم اولیه Rootless Podman

برای اجرای Rootless، بهتر است از یک کاربر عادی Linux استفاده کنید.

ابتدا هویت کاربر را بررسی کنید:

id

اگر کاربر root نیستید، می‌توانید Podman را بدون sudo اجرا کنید.

بررسی Subordinate UID و GID

روی سیستم‌های Linux معمولاً نگاشت‌های UID و GID در فایل‌های زیر مدیریت می‌شوند:

/etc/subuid
/etc/subgid

برای مشاهده تنظیمات کاربر جاری:

grep "^$(id -un):" /etc/subuid /etc/subgid

نمونه خروجی:

/etc/subuid:deploy:100000:65536
/etc/subgid:deploy:100000:65536

این خروجی فقط مثال است.

اگر نگاشت‌ها وجود ندارند یا Rootless با خطای UID/GID مواجه می‌شود، باید تنظیمات User Namespace و بسته‌های موردنیاز توزیع را بررسی کنید. تغییر دستی محدوده‌ها باید با اطمینان از تداخل نداشتن شناسه‌ها انجام شود.

تست Rootless

podman run --rm \
  docker.io/library/alpine:3.22 \
  echo "Podman Rootless OK"

اگر خروجی زیر نمایش داده شد، اولین کانتینر آزمایشی اجرا شده است:

Podman Rootless OK

آموزش اجرای اولین کانتینر واقعی با Podman

در این مثال یک وب‌سرور Nginx راه‌اندازی می‌کنیم.

مرحله اول: دریافت Image

podman pull docker.io/library/nginx:stable-alpine

برای مشاهده Imageها:

podman images

مرحله دوم: اجرای Nginx

podman run -d \
  --name demo-nginx \
  -p 127.0.0.1:8080:80 \
  docker.io/library/nginx:stable-alpine

توضیح گزینه‌ها:

  • -d: اجرای کانتینر در پس‌زمینه
  • --name: تعیین نام کانتینر
  • -p: انتشار پورت کانتینر روی میزبان

در این مثال پورت فقط روی Loopback میزبان منتشر شده و به‌صورت مستقیم روی IP عمومی در دسترس نیست.

مرحله سوم: تست وب‌سرور

curl -I http://127.0.0.1:8080

اگر سرویس درست اجرا شده باشد، پاسخ HTTP دریافت می‌کنید.

مرحله چهارم: مشاهده کانتینر

podman ps

مرحله پنجم: مشاهده لاگ

podman logs demo-nginx

مرحله ششم: ورود به کانتینر

podman exec -it demo-nginx sh

در Imageهای کوچک ممکن است Bash نصب نباشد؛ بنابراین sh انتخاب سازگارتری است.

مرحله هفتم: توقف و حذف

podman stop demo-nginx

podman rm demo-nginx

به این ترتیب چرخه اولیه ایجاد، اجرا، بررسی و حذف کانتینر را انجام داده‌اید.

دستورات کاربردی Podman

یکی از مزیت‌های Podman برای کاربران Docker، آشنا بودن بسیاری از دستورات است.

کاربرددستور Podman
نمایش کانتینرهای فعالpodman ps
نمایش همه کانتینرهاpodman ps -a
دریافت Imagepodman pull IMAGE
اجرای کانتینرpodman run IMAGE
توقف کانتینرpodman stop NAME
شروع مجددpodman start NAME
ری‌استارتpodman restart NAME
مشاهده لاگpodman logs NAME
اجرای دستور در کانتینرpodman exec NAME COMMAND
نمایش Imageهاpodman images
حذف کانتینرpodman rm NAME
حذف Imagepodman rmi IMAGE
نمایش Podهاpodman pod ps
نمایش Volumeهاpodman volume ls
نمایش Networkهاpodman network ls
مصرف منابعpodman stats
اطلاعات محیطpodman info

بررسی مصرف CPU و RAM

podman stats

این دستور اطلاعات مصرف منابع کانتینرهای فعال را نمایش می‌دهد.

بررسی فضای مصرفی

podman system df

برای بررسی Imageها و داده‌های بلااستفاده مفید است.

ساخت Image اختصاصی با Podman و Containerfile

Podman فقط برای اجرای Imageهای آماده نیست.

می‌توان با استفاده از Containerfile یا Dockerfile، Image اختصاصی ساخت.

ساختار دستورها مشابه است.

مثال: ساخت یک وب‌سایت استاتیک

ابتدا پوشه پروژه را ایجاد کنید:

mkdir podman-site

cd podman-site

فایل index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Podman Demo</title>
</head>
<body>
    <h1>Hello from Podman</h1>
</body>
</html>

فایل Containerfile:

FROM docker.io/library/nginx:stable-alpine

COPY index.html /usr/share/nginx/html/index.html

EXPOSE 80

حالا Image را بسازید:

podman build -t localhost/podman-site:1.0 .

سپس آن را اجرا کنید:

podman run -d \
  --name podman-site \
  -p 127.0.0.1:8080:80 \
  localhost/podman-site:1.0

برای تست:

curl http://127.0.0.1:8080

اکنون یک Image اختصاصی ساخته‌اید که می‌توان آن را در Registry ذخیره یا روی سرور دیگری اجرا کرد.

آموزش عملی ساخت Pod در Podman

حالا به یکی از قابلیت‌های اصلی Podman می‌رسیم: ایجاد یک Pod واقعی.

در این مثال دو کانتینر ایجاد می‌کنیم:

  • Nginx
  • یک کانتینر Alpine برای تست ارتباط داخلی

هر دو عضو یک Pod خواهند بود.

مرحله اول: ساخت Pod

podman pod create \
  --name web-pod \
  -p 127.0.0.1:8081:80

در این مرحله پورت Pod را منتشر می‌کنیم.

مرحله دوم: اجرای Nginx داخل Pod

podman run -d \
  --name pod-nginx \
  --pod web-pod \
  docker.io/library/nginx:stable-alpine

توجه کنید که در این دستور پورت جدیدی Publish نکردیم؛ انتشار پورت هنگام ساخت Pod انجام شده است.

مرحله سوم: اجرای کانتینر دوم

podman run -d \
  --name pod-helper \
  --pod web-pod \
  docker.io/library/alpine:3.22 \
  sleep 3600

مرحله چهارم: تست ارتباط localhost

podman exec pod-helper \
  wget -qO- http://127.0.0.1:80

اگر صفحه Nginx نمایش داده شد، مشخص می‌شود کانتینر دوم توانسته از طریق localhost به سرویس داخل همان Pod متصل شود.

مرحله پنجم: مشاهده Pod

podman pod ps

برای مشاهده جزئیات:

podman pod inspect web-pod

مرحله ششم: توقف Pod

podman pod stop web-pod

مرحله هفتم: حذف Pod آزمایشی

podman pod rm -f web-pod

هشدار: گزینه -f می‌تواند کانتینرهای عضو Pod را نیز متوقف و حذف کند. روی سرویس عملیاتی بدون بررسی استفاده نشود.

مدیریت شبکه در Podman

Podman امکانات مختلفی برای مدیریت شبکه کانتینرها ارائه می‌کند.

در محیط‌های جدید Linux، Netavark یکی از اجزای مهم Networking است و برای Name Resolution کانتینرها نیز می‌توان از aardvark-dns استفاده کرد.

مشاهده شبکه‌ها

podman network ls

ساخت Network اختصاصی

podman network create app-network

اتصال کانتینر به Network

podman run -d \
  --name nginx-app \
  --network app-network \
  docker.io/library/nginx:stable-alpine

در شبکه‌های دارای DNS فعال، کانتینرها می‌توانند معمولاً از نام‌های ثبت‌شده برای پیدا کردن یکدیگر استفاده کنند.

Rootless Networking

در Rootless Mode، مدیریت شبکه به‌دلیل محدودیت دسترسی کاربران عادی تفاوت‌هایی با Rootful دارد.

Podman می‌تواند از ابزارهایی مانند pasta برای ایجاد ارتباط شبکه Rootless استفاده کند.

جزئیات رفتار شبکه به نسخه Podman و تنظیمات میزبان بستگی دارد.

چرا پورت ۸۰ در Rootless گاهی خطا می‌دهد؟

در بسیاری از سیستم‌های Linux، کاربران عادی اجازه Bind مستقیم روی پورت‌های کمتر از ۱۰۲۴ را ندارند.

بنابراین دستور زیر ممکن است با خطا مواجه شود:

podman run -p 80:80 IMAGE

راهکار ساده‌تر این است که سرویس را روی پورتی مانند ۸۰۸۰ منتشر کنید و برای ارائه HTTPS عمومی از Reverse Proxy با تنظیمات مناسب استفاده کنید.

برای سرویس‌های وب، انتخاب و تنظیم درست Nginx نیز اهمیت دارد. راهنمای پیکربندی Nginx و PHP-FPM روی Ubuntu می‌تواند برای آشنایی بیشتر با این بخش مفید باشد.

مدیریت Volume و ذخیره‌سازی داده در Podman

مانند Docker، داده‌هایی که فقط در لایه قابل نوشتن Container ذخیره شوند، به چرخه عمر همان کانتینر وابسته‌اند.

برای ذخیره‌سازی پایدار باید از Volume یا Bind Mount استفاده کنید.

ساخت Volume

podman volume create app-data

مشاهده Volumeها

podman volume ls

ذخیره داده در Volume

podman run --rm \
  -v app-data:/data \
  docker.io/library/alpine:3.22 \
  sh -c 'echo "Persistent Data" > /data/example.txt'

حالا اطلاعات را با کانتینر جدید بخوانید:

podman run --rm \
  -v app-data:/data \
  docker.io/library/alpine:3.22 \
  cat /data/example.txt

خروجی:

Persistent Data

این مثال نشان می‌دهد داده داخل Volume باقی می‌ماند، حتی اگر کانتینر اولیه حذف شده باشد.

Bind Mount در Podman

می‌توانید مسیر مشخصی از Host را داخل کانتینر Mount کنید:

podman run --rm \
  -v "$PWD/data:/data" \
  docker.io/library/alpine:3.22 \
  ls /data

در سیستم‌های دارای SELinux Enforcing ممکن است لازم باشد Context امنیتی مسیر Mountشده نیز تنظیم شود.

Podman برای بعضی سناریوها گزینه‌هایی مانند :Z و :z ارائه می‌کند؛ اما استفاده از آن‌ها باید با شناخت اثر تغییر SELinux Label روی مسیر میزبان انجام شود.

آیا Volume جای Backup را می‌گیرد؟

خیر.

Volume فقط داده را از چرخه عمر کانتینر جدا می‌کند.

برای دیتابیس و سرویس‌های مهم همچنان باید Backup مستقل و قابل Restore داشته باشید.

Podman Compose چیست؟

در Docker، ابزار Docker Compose برای اجرای برنامه‌های چندکانتینری کاربرد زیادی دارد.

در Podman نیز امکان کار با Compose وجود دارد، اما یک تفاوت فنی مهم وجود دارد.

podman compose در مستندات رسمی یک Wrapper برای اجرای Compose Provider خارجی است.

این Provider می‌تواند ابزاری مانند:

  • docker-compose
  • podman-compose

باشد.

بنابراین وجود خود Podman الزاماً به معنی نصب بودن یک Compose Provider نیست.

بررسی پشتیبانی Compose

podman compose version

اگر Provider مناسب نصب و پیکربندی شده باشد، اطلاعات آن نمایش داده می‌شود.

نمونه فایل Compose

services:
  web:
    image: docker.io/library/nginx:stable-alpine
    ports:
      - "127.0.0.1:8082:80"
    restart: unless-stopped

پس از نصب و پیکربندی Compose Provider سازگار، می‌توان فایل را با دستور زیر اجرا کرد:

podman compose up -d

بااین‌حال همه رفتارهای Docker Compose الزاماً بدون تغییر در Podman بازتولید نمی‌شوند.

برای پروژه‌های Production باید Network، Volume، Health Check، Permissionها و سایر ویژگی‌های فایل Compose را روی نسخه واقعی Podman و Provider مورد استفاده تست کنید.

اجرای Podman به‌عنوان سرویس دائمی با systemd و Quadlet

یکی از جذاب‌ترین کاربردهای Podman روی سرورهای Linux، یکپارچگی آن با systemd است.

برای مثال ممکن است بخواهید یک کانتینر:

  • بعد از Boot سرور اجرا شود.
  • در صورت خطای برنامه دوباره راه‌اندازی شود.
  • با systemctl مدیریت شود.
  • لاگ‌های آن از طریق journalctl قابل بررسی باشند.

برای این کار، مستندات فعلی Podman استفاده از Quadlet را توصیه می‌کنند.

Quadlet چیست؟

Quadlet روشی Declarative برای تعریف کانتینرها و سایر منابع Podman به‌صورت فایل‌هایی با ساختار مشابه systemd Unit است.

فایل‌های Quadlet می‌توانند پسوندهایی مانند موارد زیر داشته باشند:

.container
.pod
.volume
.network
.kube
.image
.build

وجود بعضی از این انواع به نسخه Podman وابسته است.

نمونه عملی: اجرای Nginx با Quadlet

این مثال برای کاربر غیر root و روی سیستمی با Podman، systemd و Quadlet سازگار نوشته شده است.

ابتدا مسیر مربوط را ایجاد کنید:

mkdir -p ~/.config/containers/systemd

سپس فایل زیر را بسازید:

nano ~/.config/containers/systemd/demo-web.container

محتوای فایل:

[Unit]
Description=Podman Nginx Demo

[Container]
Image=docker.io/library/nginx:stable-alpine
ContainerName=demo-web
PublishPort=127.0.0.1:8080:80

[Service]
Restart=on-failure
TimeoutStartSec=300

[Install]
WantedBy=default.target

بارگذاری تنظیمات systemd

systemctl --user daemon-reload

شروع سرویس

systemctl --user start demo-web.service

مشاهده وضعیت

systemctl --user status demo-web.service

مشاهده لاگ

journalctl --user -u demo-web.service -f

اجرای سرویس بعد از Reboot

برای اجرای سرویس‌های User بعد از Boot، حتی زمانی که کاربر Login نکرده است، ممکن است لازم باشد Linger برای آن کاربر فعال شود:

sudo loginctl enable-linger "$(id -un)"

در Quadlet، برخلاف Unitهای معمولی، فایل‌های Service تولیدشده توسط Generator از قواعد خاصی پیروی می‌کنند.

به همین دلیل برای فعال شدن خودکار، بخش [Install] در خود Quadlet اهمیت دارد و نباید فرض کنیم دستور systemctl enable برای Unit تولیدشده همان رفتار Unit معمولی را دارد.

آیا podman generate systemd هنوز مناسب است؟

دستور قدیمی:

podman generate systemd

در مستندات جدید Podman با وضعیت Deprecated مشخص شده است.

این دستور هنوز برای سازگاری وجود دارد، اما برای پیاده‌سازی‌های جدید بهتر است Quadlet را در اولویت قرار دهید.

امنیت Podman؛ بهترین روش‌های امن‌سازی

یکی از مهم‌ترین دلایل انتخاب Podman، توجه به امنیت کانتینرهاست.

اما Rootless و Daemonless بودن به‌تنهایی کافی نیست.

۱. از Rootless استفاده کنید

تا جایی که نیاز برنامه اجازه می‌دهد، کانتینرها را با کاربر غیر root اجرا کنید.

۲. Imageهای معتبر انتخاب کنید

استفاده از Imageهای ناشناس می‌تواند باعث ورود کتابخانه‌های آسیب‌پذیر یا نرم‌افزارهای مخرب به زیرساخت شود.

۳. Imageها را به‌روزرسانی کنید

نسخه‌های قدیمی ممکن است شامل آسیب‌پذیری‌های شناخته‌شده باشند.

۴. کانتینر Privileged اجرا نکنید

از گزینه‌هایی مانند:

--privileged

بدون ضرورت فنی استفاده نکنید.

۵. دسترسی به Volumeها را محدود کنید

فقط مسیرهایی را Mount کنید که برنامه واقعاً به آن‌ها نیاز دارد.

برای اطلاعات فقط‌خواندنی از Read-only Mount استفاده کنید.

۶. از SELinux و سایر سیاست‌های امنیتی بهره ببرید

روی توزیع‌های دارای SELinux، Labeling می‌تواند به محدودسازی دسترسی کانتینر کمک کند.

همچنین Linux Capabilities، Seccomp و User Namespace در کاهش سطح دسترسی نقش دارند.

۷. Podman API Socket را محافظت کنید

اگر Podman API را فعال می‌کنید، باید دسترسی به Socket را محدود نگه دارید.

API مدیریتی می‌تواند امکان اجرای عملیات حساس با سطح دسترسی کاربر اجراکننده سرویس را فراهم کند.

بنابراین قرار دادن Socket مدیریتی روی اینترنت عمومی بدون طراحی امنیتی مناسب بسیار خطرناک است.

۸. Kernel میزبان را به‌روزرسانی کنید

کانتینرهای لینوکسی از Kernel میزبان استفاده می‌کنند.

در نتیجه آسیب‌پذیری‌های Kernel می‌توانند روی امنیت محیط Containerized تأثیر داشته باشند.

برای مطالعه یک نمونه فنی می‌توانید مقاله بررسی آسیب‌پذیری Copy Fail در Linux Kernel را مطالعه کنید.

۹. محدودیت منابع اعمال کنید

برای مثال:

podman run -d \
  --name limited-web \
  --memory=512m \
  --cpus=1 \
  docker.io/library/nginx:stable-alpine

در Rootless Mode، اعمال بعضی محدودیت‌ها به پشتیبانی cgroups و تنظیمات سیستم وابسته است.

۱۰. Backup مستقل داشته باشید

Volume و Container Storage جایگزین Backup نیستند.

Podman Desktop چیست؟

Podman Desktop یک ابزار گرافیکی برای مدیریت کانتینرها و محیط‌های مرتبط با Podman است.

با استفاده از آن می‌توان بسیاری از عملیات روزمره را بدون وارد کردن مستقیم دستورات ترمینال انجام داد.

امکانات آن شامل موارد زیر است:

  • مشاهده و مدیریت Containerها
  • مدیریت Imageها
  • ساخت و مدیریت Podها
  • بررسی Log و وضعیت سرویس‌ها
  • مدیریت محیط توسعه محلی
  • استفاده از قابلیت‌های توسعه‌پذیر از طریق Extensionها

Podman روی macOS و Windows چگونه کار می‌کند؟

Podman در Linux می‌تواند مستقیماً از امکانات Kernel لینوکس استفاده کند.

اما روی macOS و Windows برای اجرای کانتینرهای لینوکسی به یک Linux VM یا محیط سازگار نیاز دارد.

Podman ابزار podman machine را برای مدیریت این محیط ارائه می‌کند.

برای مثال:

podman machine init

podman machine start

سپس می‌توان دستورات معمول Podman را اجرا کرد.

Podman Desktop مدیریت این محیط را از طریق رابط گرافیکی ساده‌تر می‌کند.

چگونه از Docker به Podman مهاجرت کنیم؟

یکی از دلایل جذابیت Podman، شباهت دستورهای آن با Docker است.

برای مثال:

DockerPodman
docker pspodman ps
docker runpodman run
docker pullpodman pull
docker buildpodman build
docker logspodman logs
docker execpodman exec

اما مهاجرت واقعی به تغییر نام دستورات محدود نمی‌شود.

مرحله اول: بررسی وابستگی‌ها

مشخص کنید کدام ابزارها و سرویس‌ها به Docker وابسته‌اند:

  • Docker Compose
  • CI/CD Pipeline
  • Docker Socket
  • Volumeها
  • Networkها
  • Restart Policy
  • Monitoring
  • Registry Authentication

مرحله دوم: بررسی Imageها

بسیاری از Imageهای استاندارد Docker با Podman سازگارند.

بااین‌حال باید Imageها و معماری موردنیاز برنامه را آزمایش کنید.

مرحله سوم: بررسی داده‌های پایدار

نباید تصور کنید Podman به‌صورت خودکار تمام Containerها، Volumeها و Metadata مربوط به Docker را می‌بیند.

Docker و Podman Storage و Metadata مدیریتی متفاوتی دارند.

برای دیتابیس‌ها و سرویس‌های Stateful، بهتر است مهاجرت با Backup، انتقال کنترل‌شده داده و تست Restore انجام شود.

مرحله چهارم: بررسی Compose

اگر پروژه از Docker Compose استفاده می‌کند، باید سازگاری فایل Compose با Provider انتخابی Podman بررسی شود.

مرحله پنجم: طراحی Startup و Restart

در محیط‌های Linux، استفاده از Quadlet و systemd می‌تواند راهکار مناسبی برای سرویس‌های دائمی باشد.

مرحله ششم: تست در Staging

قبل از جایگزینی Docker در Production، سرویس‌ها را در محیط جداگانه اجرا و بررسی کنید.

نکته: نصب بسته‌هایی مانند podman-docker یا ساخت Alias برای دستور Docker، ممکن است اجرای دستورهای آشنا را ساده کند، اما سازگاری کامل همه قابلیت‌ها را تضمین نمی‌کند. روی سرور Production نباید بدون بررسی Package Conflict و وابستگی سرویس‌ها، Docker را جایگزین کرد.

ارتباط Podman با Kubernetes چیست؟

Podman از مفهوم Pod پشتیبانی می‌کند، اما این به معنی یکسان بودن Podman با Kubernetes نیست.

Kubernetes یک پلتفرم Container Orchestration برای مدیریت Workloadها در مقیاس گسترده‌تر است.

اما Podman بیشتر روی مدیریت کانتینرها و Podها در سطح Host تمرکز دارد.

آیا Podman می‌تواند فایل Kubernetes YAML اجرا کند؟

Podman از قابلیت‌هایی مانند:

podman kube play

برای اجرای برخی Workloadهای تعریف‌شده با Kubernetes YAML پشتیبانی می‌کند.

بااین‌حال این قابلیت معادل اجرای یک Kubernetes Cluster کامل نیست و همه APIها و ویژگی‌های Kubernetes را پیاده‌سازی نمی‌کند.

Podman یا Kubernetes؟

اگر چند کانتینر روی یک سرور دارید و می‌خواهید آن‌ها را با systemd مدیریت کنید، Podman و Quadlet می‌توانند کافی باشند.

اما اگر به Scheduling میان چند Node، Auto-scaling پیشرفته، مدیریت Cluster و Orchestration گسترده نیاز دارید، Kubernetes انتخاب مناسب‌تری است.

آیا Podman روی VPS اجرا می‌شود؟

بله؛ Podman را می‌توان روی سرور مجازی Linux اجرا کرد، مشروط بر اینکه سیستم‌عامل و محیط مجازی‌سازی از قابلیت‌های موردنیاز پشتیبانی کنند.

برای مثال، یک VPS مبتنی بر KVM با Ubuntu یا RHEL می‌تواند میزبان Podman باشد.

برای آشنایی با ساختار این سرویس، مقاله سرور مجازی چیست؟ را مطالعه کنید.

Podman به چه منابعی نیاز دارد؟

میزان منابع بیشتر به Containerهایی بستگی دارد که اجرا می‌کنید.

برای شروع، جدول زیر می‌تواند یک برآورد اولیه باشد:

سناریوCPU اولیهRAM اولیه
محیط آزمایش و چند کانتینر سبک۲ vCPU۴ GB
API کوچک با Redis۴ vCPU۸ GB
چند سرویس با دیتابیس۸ vCPU۱۶ GB
زیرساخت پرترافیکبر اساس Benchmarkبر اساس مصرف واقعی

این اعداد حداقل رسمی Podman نیستند؛ صرفاً نقطه شروع برای انتخاب زیرساخت هستند.

Podman روی VPS ایران یا آلمان؟

انتخاب موقعیت سرور به نوع پروژه بستگی دارد.

برای سرویس‌هایی با کاربران ایرانی، سرور مجازی ایران می‌تواند قابل بررسی باشد.

برای سرویس‌های بین‌المللی، برنامه‌های وابسته به Registryهای خارجی و زیرساخت‌های توسعه، سرور مجازی آلمان نیز گزینه مناسبی برای ارزیابی است.

برای شناخت کاربردها و ویژگی‌های این موقعیت می‌توانید مقاله سرور مجازی آلمان چیست؟ را بخوانید.

آیا Podman روی هاست اشتراکی نصب می‌شود؟

در سرویس‌های هاست اشتراکی معمولاً کاربر دسترسی لازم برای نصب و مدیریت Container Engine را ندارد.

برای اجرای سرویس‌های اختصاصی Podman معمولاً VPS یا سرور اختصاصی انتخاب مناسب‌تری است.

بهترین روش‌های اجرای Podman در Production

برای استفاده عملیاتی از Podman بهتر است چند اصل را رعایت کنید.

۱. نسخه Image را کنترل کنید

برای سرویس‌های مهم از نسخه‌های مشخص و در صورت نیاز Image Digest استفاده کنید.

۲. از Quadlet استفاده کنید

برای سرویس‌های دائمی Linux، Quadlet روشی مناسب برای تعریف و مدیریت چرخه عمر کانتینرهاست.

۳. Health Check داشته باشید

فعال بودن فرآیند کانتینر الزاماً به معنی سالم بودن Application نیست.

۴. Resource Limit تعیین کنید

مصرف CPU، RAM و سایر منابع را بر اساس نیاز Workload کنترل کنید.

۵. از Volumeها Backup بگیرید

به‌خصوص اگر PostgreSQL، MySQL، Redis یا سایر سرویس‌های Stateful اجرا می‌کنید.

۶. Log و Monitoring را جدی بگیرید

از ابزارهایی مانند podman logs، journalctl و سیستم‌های مانیتورینگ استفاده کنید.

۷. Network Exposure را محدود کنید

فقط پورت‌هایی را روی Host منتشر کنید که واقعاً باید قابل دسترس باشند.

۸. Auto-update را کنترل‌شده اجرا کنید

Podman قابلیت Auto-update برای بعضی سرویس‌های مدیریت‌شده با systemd دارد.

اما به‌روزرسانی خودکار بدون تست Compatibility ممکن است باعث اختلال سرویس شود.

برای Production بهتر است فرآیند Update با Staging، Health Check و Rollback Plan همراه باشد.

۹. زیرساخت را قابل بازتولید نگه دارید

فایل‌های Containerfile، Quadlet و سایر Configurationها بهتر است در Version Control ذخیره شوند.

۱۰. قبل از تغییرات بزرگ Backup بگیرید

به‌خصوص هنگام جابه‌جایی Runtime، مهاجرت از Docker یا تغییر Storage و Network.

خطاهای رایج Podman و روش عیب‌یابی

۱. خطای Permission denied در Rootless

ممکن است User Namespace، دسترسی فایل‌ها یا UID/GID Mapping درست تنظیم نشده باشد.

ابتدا موارد زیر را بررسی کنید:

id

podman info

grep "^$(id -un):" /etc/subuid /etc/subgid

۲. کانتینر به پورت ۸۰ متصل نمی‌شود

در Rootless ممکن است کاربر اجازه Bind پورت‌های کمتر از ۱۰۲۴ را نداشته باشد.

پورت بالاتر مانند ۸۰۸۰ را تست کنید.

۳. کانتینر پس از Logout متوقف می‌شود

اگر سرویس به User Session وابسته باشد، تنظیمات systemd و Linger را بررسی کنید.

loginctl show-user "$(id -un)" -p Linger

۴. Podman Compose اجرا نمی‌شود

ممکن است Compose Provider نصب نشده یا درست پیکربندی نشده باشد.

بررسی کنید:

podman compose version

۵. خطای Mount در سیستم‌های SELinux

Permission فایل‌ها و SELinux Context را بررسی کنید.

در بعضی سناریوها باید از روش‌های مناسب Labeling استفاده شود.

۶. کانتینر بعد از Reboot اجرا نمی‌شود

وضعیت Quadlet، systemd و Linger را بررسی کنید.

systemctl --user list-unit-files

systemctl --user --failed

۷. فضای دیسک پر شده است

ابتدا مصرف Container Storage را بررسی کنید:

podman system df

سپس Imageها، Containerها و Volumeهای بلااستفاده را شناسایی کنید.

قبل از پاک‌سازی حتماً مشخص کنید داده مهمی در Storage وجود ندارد.

۸. Image پیدا نمی‌شود یا Registry اشتباه انتخاب شده است

برای جلوگیری از ابهام بهتر است نام کامل Registry را وارد کنید.

به‌جای:

podman pull nginx

می‌توانید از:

podman pull docker.io/library/nginx:stable-alpine

استفاده کنید.

سوالات متداول درباره Podman

Podman چیست؟

Podman یک Container Engine متن‌باز برای ساخت، اجرا و مدیریت کانتینرها و Podهاست که معماری Daemonless و پشتیبانی گسترده از Rootless Containers دارد.

Podman مخفف چیست؟

Podman مخفف Pod Manager است.

تفاوت اصلی Podman و Docker چیست؟

یکی از مهم‌ترین تفاوت‌ها معماری است. Podman برای اجرای محلی کانتینرها به Daemon مرکزی دائمی نیاز ندارد، در حالی که Docker Engine معمولاً از Docker Daemon استفاده می‌کند.

آیا Podman رایگان است؟

Podman یک پروژه متن‌باز است و استفاده از آن به‌عنوان ابزار اصلی Container Management رایگان است. خدمات پشتیبانی سازمانی یا محصولات تجاری مرتبط می‌توانند شرایط جداگانه داشته باشند.

آیا Podman به Docker نیاز دارد؟

خیر. برای اجرای کانتینرهای استاندارد با Podman نیازی به نصب Docker Engine نیست.

آیا Podman می‌تواند Docker Image اجرا کند؟

بله. بسیاری از Imageهای استاندارد موجود در Docker Registryها با Podman قابل استفاده‌اند.

آیا Podman از Dockerfile پشتیبانی می‌کند؟

بله. Podman می‌تواند از Dockerfile یا Containerfile برای ساخت Image استفاده کند.

آیا Podman از Docker Compose پشتیبانی می‌کند؟

Podman می‌تواند از Compose Providerهای خارجی برای اجرای فایل‌های Compose استفاده کند. سازگاری دقیق به Provider و ویژگی‌های فایل Compose بستگی دارد.

آیا Podman امن‌تر از Docker است؟

مدل Daemonless و Rootless می‌تواند در بعضی سناریوها مزیت امنیتی ایجاد کند؛ اما امنیت نهایی به تنظیمات، Kernel، سطح دسترسی و نوع اجرای کانتینر وابسته است.

Rootless در Podman یعنی چه؟

یعنی امکان مدیریت و اجرای کانتینر توسط کاربر غیر root میزبان با استفاده از قابلیت‌هایی مانند User Namespace وجود دارد.

Pod در Podman چیست؟

Pod گروهی از کانتینرهاست که می‌توانند فضای شبکه و برخی منابع مشترک داشته باشند.

آیا Podman جایگزین Kubernetes می‌شود؟

برای بعضی Deploymentهای کوچک و تک‌سروری می‌تواند کافی باشد، اما جایگزین مستقیم قابلیت‌های Orchestration یک Kubernetes Cluster نیست.

Quadlet چیست؟

Quadlet روشی برای تعریف و مدیریت کانتینرها، Podها و منابع مرتبط Podman با استفاده از فایل‌های Declarative و systemd است.

آیا Podman روی Ubuntu اجرا می‌شود؟

بله. Podman در مخازن رسمی نسخه‌های پشتیبانی‌شده Ubuntu موجود است.

آیا Podman روی macOS نصب می‌شود؟

بله. اجرای Linux Containerها روی macOS با استفاده از Linux VM انجام می‌شود.

آیا Podman روی سرور مجازی مناسب است؟

بله. برای بسیاری از سرویس‌های Containerized، یک VPS لینوکسی با Kernel سازگار و منابع کافی می‌تواند میزبان مناسبی برای Podman باشد.

آیا برای استفاده از Podman باید Docker بلد باشیم؟

خیر. اما آشنایی با مفاهیم Docker، Image و Container یادگیری Podman را ساده‌تر می‌کند.

Podman بهتر است یا Docker؟

اگر اولویت شما یکپارچگی با اکوسیستم Docker و Compose است، Docker می‌تواند انتخاب مناسب‌تری باشد. اگر معماری Daemonless، Rootless و مدیریت سرویس‌ها با systemd برایتان مهم است، Podman ارزش بررسی بیشتری دارد.

جمع‌بندی؛ آیا Podman جایگزین مناسبی برای Docker است؟

Podman یکی از مهم‌ترین ابزارهای متن‌باز برای مدیریت کانتینرها در Linux است و بسیاری از قابلیت‌های موردنیاز توسعه‌دهندگان و مدیران زیرساخت را فراهم می‌کند.

مهم‌ترین ویژگی این ابزار معماری Daemonless، امکان اجرای Rootless و مدیریت گروهی کانتینرها در قالب Pod است.

در کنار این ویژگی‌ها، یکپارچگی Podman با systemd و Quadlet امکان تعریف و مدیریت سرویس‌های دائمی را به‌شکل مناسبی فراهم می‌کند.

Podman همچنین با استانداردهای OCI سازگار است و می‌تواند بسیاری از Imageهایی را اجرا کند که قبلاً برای Docker ساخته شده‌اند.

بااین‌حال Podman و Docker کاملاً قابل جایگزینی بدون بررسی نیستند. هنگام مهاجرت باید Compose، Network، Volume، Docker API، Permissionها، Monitoring و Startup سرویس‌ها را بررسی کنید.

اگر در حال یادگیری Containerization هستید، ابتدا مقاله Docker چیست؟ را مطالعه کنید و سپس مفاهیم اختصاصی Podman مانند Rootless، Pod و Quadlet را یاد بگیرید.

برای اجرای Podman در محیط واقعی نیز به یک Linux Host مناسب نیاز دارید. می‌توانید متناسب با منابع پروژه، موقعیت کاربران و نوع سرویس، گزینه‌های سرور مجازی و اختصاصی پویاسازان را بررسی کنید.

در نهایت، بهترین ابزار لزوماً جدیدترین یا محبوب‌ترین ابزار نیست؛ بلکه ابزاری است که با معماری نرم‌افزار، نیازهای امنیتی، تجربه تیم فنی و زیرساخت شما سازگاری بیشتری داشته باشد.

منابع و مستندات

آخرین به روز رسانی: ۲۵ مهر ۱۴۰۵