فراتر از داکر: سفری به دنیای امن و قدرتمند پادمن

بسیاری از ما در دنیای فناوری، طلوع عصر کانتینرسازی را به یاد داریم. ابتدا Vagrant ظهور کرد، ابزاری امیدوارکننده که هدفش استانداردسازی محیط‌های توسعه بود. سپس داکر از راه رسید و تنها یک ابزار نبود؛ یک انقلاب بود. داکر شیوه توسعه، ارسال و استقرار برنامه‌ها را از نو شکل داد. توانایی ایجاد یک محیط تکرارپذیر و ایزوله، مانند یک ابرقدرت به نظر می‌رسید. «فقط داکری‌اش کن» به راه‌حل پیش‌فرض برای مشکلات بی‌شماری تبدیل شد. اما این راحتی، هزینه‌ای پنهان داشت: دیمن (daemon) همیشه‌حاضر dockerd که با دسترسی ریشه (root) اجرا می‌شد، منابع را مصرف می‌کرد و یک خطر امنیتی قابل توجه به شمار می‌رفت.

برای کسانی از ما که مدتی در این صنعت بوده‌اند، می‌دانیم که پیشرفت از زیر سؤال بردن وضع موجود حاصل می‌شود. آن دیمن آرام داکر کم‌کم دیگر شبیه یک دستیار مفید نبود و بیشتر به یک تهدید بالقوه شباهت داشت. مجموعه‌ای از آسیب‌پذیری‌های بزرگ در طول سال‌ها این ترس‌ها را تأیید کرد؛ از اکسپلویت‌های فرار از کانتینر مانند CVE-2019-5736 گرفته تا مشکلات سطح کرنل مانند «Dirty Pipe» و سری باگ‌های «Leaky Vessels». این‌ها فقط ریسک‌های تئوری نبودند؛ تهدیدهای واقعی بودند که می‌توانستند به تسخیر کامل سیستم میزبان منجر شوند. این جستجو برای یک جایگزین امن‌تر و قوی‌تر، مرا به کشف پادمن (Podman) رساند و این انتقال چیزی فراتر از تعویض یک ابزار بود—یک تغییر پارادایم بود.

تفاوت معماری بدون دیمن

مشکل اصلی معماری داکر، اتکای آن به یک سرویس پس‌زمینه پایدار است: دیمن `dockerd`. هر دستور `docker` در واقع درخواستی به این دیمن است که با دسترسی ریشه اجرا می‌شود. اگر این دیمن دچار مشکل شود یا به خطر بیفتد، کل سیستم در معرض خطر قرار می‌گیرد. پادمن این مدل را به طور کامل کنار می‌گذارد. هیچ دیمن پس‌زمینه‌ای وجود ندارد. وقتی شما `podman run my-app` را اجرا می‌کنید، فرآیند کانتینر مستقیماً فرزند دستور شما می‌شود و با دسترسی‌های کاربر شما اجرا می‌گردد. این تغییر ساده، پیامدهای عمیقی دارد:

• امنیتی که واقعاً منطقی است: با رویکرد بدون ریشه (rootless) پادمن، حتی اگر یک مهاجم در داخل کانتینر به دسترسی ریشه برسد، در سیستم میزبان همچنان یک کاربر عادی و بدون دسترسی ویژه است. این امر سطح حمله را به شدت کاهش می‌دهد و یک دسته کامل از آسیب‌پذیری‌های فرار از کانتینر را خنثی می‌کند.
• نبود نقطه شکست واحد: همه ما این تجربه را داشته‌ایم—دیمن داکر هنگ می‌کند و ناگهان تمام کانتینرهای در حال اجرا تحت تأثیر قرار می‌گیرند. با معماری پادمن، اگر یک کانتینر از کار بیفتد، بقیه بدون هیچ مشکلی به کار خود ادامه می‌دهند. این یک مدل انعطاف‌پذیرتر و ایزوله‌تر است.
• مصرف منابع کمتر: بدون وجود یک دیمن پایدار که دائماً در پس‌زمینه در حال اجرا باشد، پادمن در حالت بیکاری حافظه و پردازنده کمتری مصرف می‌کند. منابع سیستم شما تنها زمانی استفاده می‌شوند که فعالانه در حال اجرای کانتینر هستید.

جایی که پادمن واقعاً می‌درخشد

فراتر از ماهیت بدون دیمن، پادمن ویژگی‌هایی ارائه می‌دهد که به نظر می‌رسد با دقت برای توسعه و عملیات مدرن طراحی شده‌اند:

• یکپارچگی برتر با Systemd: برای هر کسی که سرویس‌ها را روی لینوکس مدیریت می‌کند، این یک ویژگی متحول‌کننده است. پادمن می‌تواند به طور خودکار فایل‌های واحد `systemd` را برای کانتینرهای شما با یک دستور ساده تولید کند: `podman generate systemd –name my-app`. این کار فوراً کانتینر شما را به یک شهروند درجه یک در اکوسیستم سرویس لینوکس تبدیل می‌کند که شامل راه‌اندازی مجدد خودکار، مدیریت وابستگی‌ها و کنترل منابع است و نیاز به مدیران فرآیند شخص ثالث را از بین می‌برد.
• همسویی واقعی با کوبرنتیز: پادمن با در نظر گرفتن کوبرنتیز توسعه یافته است. پشتیبانی بومی آن از «پادها» (pod) —گروه‌هایی از کانتینرها که منابع را به اشتراک می‌گذارند— به شما امکان می‌دهد تا محیط تولید خود را به صورت محلی شبیه‌سازی کنید. شما می‌توانید برنامه‌های چندکانتینری را در پادهای پادمن بسازید و آزمایش کنید و سپس فایل‌های YAML کوبرنتیز مربوطه را مستقیماً با استفاده از `podman generate kube` تولید کنید. این گردش کار یکپارچه از توسعه محلی تا استقرار نهایی، فوق‌العاده قدرتمند است.
• فلسفه یونیکس در عمل: پادمن بر روی انجام یک کار به بهترین شکل تمرکز دارد: اجرای کانتینرها. برای سایر وظایف تخصصی، با مجموعه‌ای از ابزارهای متمرکز یکپارچه می‌شود. نیاز به ساخت ایمیج دارید؟ از Buildah استفاده کنید. نیاز به بازرسی یا انتقال ایمیج‌ها بین رجیستری‌ها دارید؟ از Skopeo استفاده کنید. این رویکرد ماژولار به شما امکان می‌دهد از بهترین ابزار برای هر کار استفاده کنید، به جای اینکه در یک سیستم یکپارچه و محدود گرفتار شوید.

مهاجرتی که به طرز شگفت‌آوری ساده بود

شاید جذاب‌ترین بخش داستان این باشد که این تغییر چقدر بی‌دردسر بود. تیم پادمن هوشمندانه رابط خط فرمان خود را به عنوان جایگزینی مستقیم برای داکر طراحی کرده است. تنها با ایجاد یک نام مستعار در شل (alias docker=podman)، ۹۹٪ از گردش کارها، اسکریپت‌ها و حافظه عضلانی من بدون هیچ مشکلی به کار خود ادامه دادند. داکرفایل‌های من سازگار بودند و دستوراتی مانند podman run، podman build و podman ps دقیقاً همانطور که انتظار داشتم رفتار می‌کردند.

معدود تفاوت‌هایی که با آن‌ها مواجه شدم، در واقع بهبودهایی بودند. عدم امکان اتصال به پورت‌های ممتاز در حالت بدون ریشه؟ این یک ویژگی امنیتی است که شما را به سمت معماری بهتر با یک پراکسی معکوس هدایت می‌کند. سروکار داشتن با پیچیدگی‌های مجوزهای والیوم؟ این یک تنظیم کوچک است که یک مدل دسترسی به فایل امن‌تر را تقویت می‌کند.

راهنمای عملی: مهاجرت یک برنامه FastAPI

برای نشان دادن اینکه این فرآیند چقدر آسان است، در اینجا یک راهنمای سریع برای انتقال یک برنامه استاندارد FastAPI از داکر به پادمن آورده شده است.

1. داکرفایل شما 그대로 کار می‌کند: پادمن با استاندارد OCI سازگار است، بنابراین داکرفایل موجود شما، مانند نمونه زیر، نیازی به تغییر ندارد.

   FROM python:3.10-slim-buster
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir --upgrade -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

2. ایمیج خود را بسازید: `docker build` را با `podman build` جایگزین کنید.

   podman build -t my-fastapi-app:latest .

3. کانتینر خود را اجرا کنید: دستور `run` یکسان است.

   podman run --rm -p 8000:8000 --name my-fastapi-container my-fastapi-app:latest

4. استقرار با Systemd: برای محیط تولید، یک فایل سرویس تولید کرده و آن را با `systemctl` مدیریت کنید.

   # تولید فایل سرویس
   podman generate systemd --name my-fastapi-container > ~/.config/systemd/user/my-fastapi.service
   
   # فعال‌سازی و راه‌اندازی
   systemctl --user daemon-reload
   systemctl --user enable --now my-fastapi.service

5. استفاده از پاد برای برنامه‌های چندسرویسی: سرویس‌های مرتبط مانند پایگاه داده را در یک پاد مشترک مدیریت کنید.

   # ایجاد یک پاد
   podman pod create --name my-app-pod -p 8000:8000
   
   # اجرای سرویس‌ها در پاد
   podman run -d --pod my-app-pod --name api my-fastapi-app
   podman run -d --pod my-app-pod --name db -e POSTGRES_PASSWORD=secret postgres

داکر به این زودی‌ها ناپدید نخواهد شد، اما پادمن نمایانگر تکامل منطقی فناوری کانتینر است—امن‌تر، کارآمدتر و هماهنگ‌تر با اصول مدیریت سیستم مدرن. این ابزار ما را تشویق می‌کند تا ابزارهایی را که به طور پیش‌فرض استفاده می‌کنیم زیر سؤال ببریم و مسیری را انتخاب کنیم که امنیت و طراحی قوی را در اولویت قرار می‌دهد.

منبع: https://codesmash.dev/why-i-ditched-docker-for-podman-and-you-should-too