📥 دریافت شده از:
Amin Qurjili
-------------

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

با سلام خدمت همه دوستان عزیز و همراهان همیشگی

به صورت پیشفرض برای یه برنامه نویس، Runtime میتونه به معنی فاز زمانی اجرای یک نرم افزار Program Runtime یا Implementation ی که امکان اجرای نرم افزار رو فراهم میکنه باشه مثل JRE یا .Net Runtime
اما وظیفه Container Runtime در واقع اجرای تمام مراحل  مورد نیاز برای اجرای یک کانتینر هست و هیچ کاری با اجرای خود نرم افزار درون کانتینر نداره.

اما چی شد که Container Runtime معانی مختلفی پیدا کرد؟

داکر سال 2013 با معرفی نرم افزار و پلتفورم خودش خیلی از مشکلاتی رو که برنامه نویسی برای اجرای کانتینر ها و مدیریت چرخه عمر کانتینر ها داشتن رو حل کرد که شامل ویژگی های زیر بود:

✔️فرمت Image مناسب کارنتینر
✔️روش و ابزاری برای ساخت Image ها (Dockerfile, Docker Build)
✔️ابزار و روش مدیریت Image ها (Docker Images, Docker rm, ..)
✔️روش و ابزار مدیریت کانتینرها (Docker ps, Docker rm, …)
✔️روش و ابزار اشتراک گذاری کانتینرها (Docker push, Docker pull)
✔️روش و ابزار مناسب برای اجرای کانتینرها (Docker Run)

سال 2013 داکر یک نرم افزار مونولیث بود ولی در واقع هیچ بخشی وابسته به بخش دیگه ای نبود و محدودیت برای شکستن این نرم افزار مونولیث به تیکه های کوچیک تر وجود نداشت. به همین دلیل توی سال 2015 داکر با همراهی گوگل و Core OS سازمان OCI رو پایه گذاری کرد و یه تیکه از نرم افزارشو به نام runc به صورت یک لایبرری به عنوان مرجع پیاده سازی Container Runtime به OCI اهدا کرد.

اوایل چیزی که داکر به OCI اهدا کرد یه مقدار گیج کننده بود چرا که فقط و فقط یک لایبرری و مرجعی برای اجرای یک کانتینر بود نه چیز دیگه ای در صورتی که برای اجرای کانتینر، شما به یک فرمت استاندارد و ابزاری برای دریافت Image هم نیاز دارین و در واقع زمانی که شما با داکر یه کانتینر رو اجرا میکنید قدم هایی که برداشته میشه شامل  دانلود Image، باز کردن یا همون Unpacking Image و تبدیل اون به یک باندل و اجرای کانتینر از اون باندل رو شامل میشه.

چیزی که داکر استاندارد سازی کرده بود فقط مرحله سوم یعنی اجرای کانتینر با استفاده از باندل Unpack شده بود.

.....

برای مطالعه ادامه مطلب به خاطر طولانی شدن لطفا وارد این لینک بشید.
https://lnkd.in/evxjDzmW

امیدوارم براتون مفید واقع بشه.
#containers #containerd #docker #runc #containerruntime 

➖➖➖➖➖➖➖➖➖
🔰 @gopher_academy

🔵 عنوان مقاله
Why I Ditched Docker for Podman (And You Should Too)

🟢 خلاصه مقاله:
مهاجرت از Docker به Podman برای من بیشتر یک انتخاب عملی بود تا بحث سلیقه؛ به‌ویژه در جریان‌های کاری مرتبط با Go که در Golang Weekly هم زیاد دیده می‌شود. دلیل اصلی، معماری ساده‌تر و امن‌تر Podman است: بدون daemon و با اجرای rootless به‌صورت پیش‌فرض، پس سطح حمله و دردسرهای دسترسی کاهش می‌یابد و سرویس پرامتیازِ دائمی لازم نیست. مهاجرت هم کم‌اصطکاک است؛ چون Podman با CLI و فرمت OCI سازگار است و دستورات رایج مثل podman build/run عملاً جایگزین مستقیم می‌شوند. برای Compose، ابزار Podman Compose و برای رابط گرافیکی، Podman Desktop وجود دارد؛ روی macOS و Windows هم podman machine تجربه‌ای سبک و قابل‌اتکا می‌دهد. ادغام بومی با systemd، مدیریت لاگ‌ها و قابلیت‌هایی مثل pods و podman generate kube، راه را برای استفاده در CI/CD و حتی انتقال به Kubernetes هموار می‌کند. در پروژه‌های Go، ساخت چندمرحله‌ای، ایمیج‌های کم‌حجم، و mountهای rootless بدون مشکل دسترسی، چرخه توسعه و تست را سریع و قابل‌اعتماد می‌کند. هرچند تفاوت‌هایی مثل مسیر socket و جزئیات volumes نسبت به Docker وجود دارد، اما راهکارهای روشن و مستندی برایشان هست. نتیجه: اگر Docker جواب‌گو است، خوب؛ اما Podman در اکثر سناریوهای روزمره توسعه و CI تجربه‌ای امن‌تر، ساده‌تر و سازگار ارائه می‌دهد.

#Podman #Docker #Containers #DevOps #Go #GolangWeekly #Kubernetes #Security

🟣لینک مقاله:
https://golangweekly.com/link/174075/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy