Docker چیست؟ بسته‌بندی و اجرای یکنواخت نرم‌افزار

Docker (داکر) یک پلتفرم باز برای توسعه، ارسال و اجرای نرم‌افزار است. طبق مستندات رسمی، ایدهٔ محوری این است که اپلیکیشن را از زیرساخت جدا کنید تا فاصلهٔ بین «نوشتن کد» و «اجرا در Production» کوتاه‌تر و قابل‌پیش‌بینی‌تر شود. واحد این جداسازی Container است: محیطی نسبتاً ایزوله که همهٔ آنچه برای اجرای اپ لازم است را با خود می‌آورد.

مشکل رایجی که تیم‌ها می‌شناسند این است: روی ماشین توسعه‌دهنده کار می‌کند، روی Staging نسخهٔ Python یا Node فرق دارد، و روی سرور Production کتابخانهٔ سیستم قدیمی است. Container این وابستگی‌ها را داخل بسته می‌گذارد تا همان Image در لپ‌تاپ، pipelineی CI و محیط نهایی اجرا شود — نه اینکه هر محیط «تقریباً شبیه» باشد.

این مقاله Docker را در سطح تصمیم معرفی می‌کند: معماری کلاینت/daemon، Image و Container، Registry، و اینکه Docker جایگزین Kubernetes یا CI نیست. جزئیات Image در برابر Container در ۱۰۷، Compose در ۱۰۸، و مقایسه با ماشین مجازی در ۱۰۶ می‌آید.

پاسخ کوتاه

Docker ابزاری است برای ساخت Image (قالب فقط‌خواندنی)، اجرای Container از روی آن Image، و مدیریت چرخهٔ عمر — از توسعه تا تست و استقرار. Containerها سبک‌اند چون هستهٔ سیستم‌عامل میزبان را به‌اشتراک می‌گذارند، برخلاف ماشین مجازی کامل. نتیجهٔ عملی برای تیم: محیط توسعه یکدست‌تر، تست نزدیک‌تر به Production، و امکان اجرای چند سرویس روی یک میزبان با ایزولاسیون نسبی.

Docker «جادوی مقیاس‌پذیری خودکار» نیست. یک Container روی یک ماشین راه‌اندازی می‌کند؛ اگر چند ماشین، خودترمیم، و کشف سرویس در مقیاس بزرگ می‌خواهید، وارد قلمرؤ Orchestration (مثل Kubernetes) می‌شوید. برای خیلی از محصولات کوچک تا متوسط، Docker به‌همراه Compose یا یک مسیر Deploy ساده کافی است.

اگر هنوز نمی‌توانید بگویید «همین Image با همین digest روی Staging تأیید شد و به Production رفت»، کانتینر را فقط به‌عنوان روش نصب پیچیده کرده‌اید — نه به‌عنوان واحد تحویل.

چه مشکلی را حل می‌کند؟

مستندات Docker سه کاربرد اصلی را برجسته می‌کند:

• تحویل سریع و یکنواخت: توسعه‌دهنده روی Container محلی کار می‌کند؛ همان بسته به تست و سپس Production می‌رود — پایهٔ خوبی برای CI/CD.
• استقرار و مقیاس‌پذیری واکنش‌پذیر: Container قابل حمل است؛ روی لپ‌تاپ، VM دیتاسنتر یا ابر عمومی قابل اجراست و بالا/پایین کردن نمونه‌ها سریع‌تر از ساخت VM کامل است.
• تراکم بیشتر روی سخت‌افزار: چون سبک‌تر از hypervisor-based VM است، روی همان منابع می‌توانید workload بیشتری اجرا کنید — به‌ویژه در محیط‌های پرتراکم یا استقرارهای کوچک و متوسط.

برای مالک محصول، ترجمهٔ کسب‌وکاری این است: کمتر «روی سیستم من کار می‌کرد»، زمان کوتاه‌تر از ادغام تا انتشار، و هزینهٔ کمتر اتلاف منابع. برای توسعه‌دهنده: وابستگی‌های پروژه داخل Image قفل می‌شوند و تداخل نسخه‌ها روی یک ماشین کم می‌شود.

معماری: Client، Daemon و Registry

Docker معماری کلاینت–سرور دارد. کلاینت (`docker`) فرمان‌هایی مثل `docker run` را به Docker daemon (`dockerd`) می‌فرستد. Daemon کار سنگین را انجام می‌دهد: ساخت، اجرا و توزیع Containerها، و مدیریت اشیایی مثل Image، Network و Volume. کلاینت و Daemon می‌توانند روی یک سیستم باشند یا کلاینت به Daemon راه دور وصل شود؛ ارتباط معمولاً از طریق REST API روی UNIX socket یا شبکه است.

Docker Desktop

Docker Desktop برنامهٔ نصب‌ساده‌ای برای macOS، Windows و Linux است که Daemon، کلاینت، Compose و ابزارهای کمکی را یکجا می‌آورد. برای شروع محلی اغلب کافی است؛ روی سرور Linux معمولاً Docker Engine نصب می‌شود.

Registry و Docker Hub

Registry محل ذخیره و توزیع Image است. Docker Hub رجیستری عمومی پیش‌فرض است؛ می‌توانید Registry خصوصی هم داشته باشید. `docker pull` / `docker run` Image را از Registry پیکربندی‌شده می‌گیرد و `docker push` آن را ارسال می‌کند. در تیم حرفه‌ای، Imageهای Production را در Registry کنترل‌شده نگه دارید — نه فقط از روی لپ‌تاپ کپی کنید.

Image و Container — دو مفهوم جدا

Image قالب فقط‌خواندنی با دستورالعمل ساخت Container است. اغلب روی Image پایه (مثلاً Ubuntu یا Python رسمی) لایه‌های سفارشی اضافه می‌کنید: وابستگی‌ها، کد اپ، تنظیمات اجرا. Dockerfile مراحل ساخت را تعریف می‌کند؛ هر دستور یک لایه می‌سازد و در rebuild فقط لایه‌های تغییرکرده دوباره ساخته می‌شوند — بخشی از سبکی Imageها.

Container نمونهٔ اجرایی یک Image است. می‌توانید آن را بسازید، شروع/توقف کنید، به شبکه وصل کنید، Volume بچسبانید، یا از وضعیت فعلی Image جدید بسازید. به‌صورت پیش‌فرض از میزبان و Containerهای دیگر نسبتاً ایزوله است؛ وقتی Container را بدون ذخیره‌سازی پایدار حذف کنید، تغییرات فایل‌سیستم داخل آن از بین می‌رود.

تفصیل این دو مفهوم — و اشتباه رایج یکی‌گرفتن‌شان — در مقالهٔ ۱۰۷ است. اینجا کافی است بدانید: Image را می‌سازید و نسخه‌گذاری می‌کنید؛ Container را اجرا و مدیریت می‌کنید.

زیر پوست: Namespace و هستهٔ مشترک

Docker به زبان Go نوشته شده و از قابلیت‌های هستهٔ Linux مثل namespace برای فضای کاری ایزوله استفاده می‌کند. هر Container مجموعه‌ای از namespace می‌گیرد تا دسترسی‌اش محدود بماند. چند Container روی یک میزبان هسته را شریک‌اند؛ به همین دلیل از VM کامل سبک‌ترند. مقایسهٔ دقیق با ماشین مجازی در مقالهٔ ۱۰۶ آمده است.

جریان کاری روزمرهٔ تیم

1. Dockerfile را برای اپ (و در صورت نیاز سرویس‌های جانبی) می‌نویسید.
2. Image را build می‌کنید و با تگ/digest مشخص به Registry می‌فرستید.
3. در توسعه محلی با `docker run` یا Compose چند سرویس را بالا می‌آورید.
4. در CI همان build را اجرا و تست می‌کنید.
5. در Staging/Production همان digest تأییدشده را deploy می‌کنید.

قدرت واقعی وقتی ظاهر می‌شود که artifact یکسان بین محیط‌ها جابه‌جا شود — همان اصل مقالهٔ استقرار (۰۵۰). Docker بسته‌بندی را استاندارد می‌کند؛ بدون شناسهٔ نسخه و مسیر Rollback، فقط نصب را عوض کرده‌اید.

چه چیزهایی Docker نیست؟

• جایگزین نوشتن تست و طراحی معماری نیست.
• به‌تنهایی Orchestrator خوشه‌ای نیست (هرچند Desktop می‌تواند Kubernetes آزمایشی داشته باشد).
• جایگزین مدیریت Secret نیست؛ رمزها را داخل Image نگذارید.
• ضمانت امنیت مطلق نیست؛ ایزولاسیون نسبی است و سخت‌سازی Image و میزبان لازم است.

Kubernetes صریحاً می‌گوید CI/CD و نوع اپ را دیکته نمی‌کند؛ Docker هم فقط واحد اجرا را استاندارد می‌کند. انتخاب ابزار استقرار و مشاهده‌پذیری جداست.

جدول تصمیم سریع

اشتباه‌های رایج شروع با Docker

• کپی کردن Secret و `.env` داخل Image و push به Hub عمومی.
• استفاده از تگ `latest` برای Production بدون digest قفل‌شده.
• اجرای همه چیز به‌عنوان root داخل Container بدون ضرورت.
• حجم عظیم Image به‌خاطر لایهٔ build و cache اضافی در Image نهایی.
• فرض اینکه «Container یعنی دیگر نیازی به Staging نیست».

برای Secret و متغیر محیطی، همان اصول مقالهٔ ۰۴۷ برقرار است: از Image جدا، مخصوص هر محیط، و قابل چرخش.

مسیر یادگیری عملی بدون گم شدن

اگر تازه‌کارید، ترتیب پیشنهادی این است: یک Container آماده از Hub اجرا کنید؛ یک Dockerfile برای اپ ساده بنویسید؛ تفاوت stop و remove را ببینید؛ سپس Volume برای دادهٔ پایدار و Network برای ارتباط سرویس‌ها را لمس کنید. بعد Compose را برای چند سرویس بیاموزید. Kubernetes را وقتی درد مقیاس و چندنودی واقعی شد سراغش بروید — نه چون «همه می‌گویند K8s».

برای مدیر غیرتکنیکال: سوال درست این نیست «آیا Docker داریم؟» بلکه «آیا همان بستهٔ تست‌شده به Production می‌رود و می‌توانیم برگردیم؟» است.

جمع‌بندی برای تصمیم

Docker پلتفرم بسته‌بندی و اجرای اپ در Container است: Client به Daemon فرمان می‌دهد، Image قالب است، Container اجراست، Registry توزیع می‌کند. فایده‌اش یکنواختی محیط، تراکم بهتر منابع، و پایهٔ محکم برای مسیر CI تا Deploy است — به‌شرط نسخه، Secret جدا و مشاهدهٔ حداقلی.

اگر این هفته یک قدم برمی‌دارید: یک سرویس را Image کنید، با تگ مشخص به Registry خصوصی یا حداقل با digest ثبت‌شده بفرستید، و همان را روی Staging اجرا کنید. از آنجا مسیر Compose یا CI را انتخاب کنید.

منابع و مراجع

• Docker Docs — What is Docker? (overview) — https://docs.docker.com/get-started/docker-overview/
• Docker Docs — What is a container? — https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/
• Docker Docs — What is an image? — https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/

برای مقایسه با VM مقالهٔ ۱۰۶، برای Image در برابر Container مقالهٔ ۱۰۷، و برای چندسرویسی محلی مقالهٔ ۱۰۸ را ببینید.