Image بزرگ فقط pull را کند نمی‌کند؛ فضای registry و host، زمان rollout و تعداد بسته‌های قابل‌نگهداری را افزایش می‌دهد. بااین‌حال کوچک‌ترین image لزوماً بهترین image نیست. حذف CA certificate، timezone یا کتابخانه native می‌تواند runtime را خراب کند و image خیلی مینیمال عیب‌یابی حادثه را دشوار سازد. هدف، حذف اجزای غیرضروری با حفظ قابلیت patch و اجراست.
پاسخ سریع: ابتدا layerهای بزرگ و build context را اندازه بگیرید. ابزار build و dependency توسعه را با Multi-stage از runtime جدا کنید، فایل‌های محلی را با .dockerignore خارج کنید، فقط dependency تولیدی را نصب و cache package manager را در همان layer پاک کنید. base image را بر اساس سازگاری انتخاب و image نهایی را با همان user و config production تست کنید.
قبل و بعد را اندازه بگیرید
اندازه فشرده registry، اندازه unpackشده روی host و مجموع layerهای مشترک یکسان نیستند. برای هدف پروژه مشخص کنید می‌خواهید زمان pull، فضای node یا سطح package را کاهش دهید. ابزار history و تحلیل layer می‌تواند دستور پرحجم را پیدا کند؛ اطلاعات build ممکن است مسیر داخلی داشته باشد، پس خروجی را بی‌فکر عمومی نکنید.
Build Context را کوچک کنید
Context شامل فایل‌هایی است که builder می‌تواند ببیند. .git، backup، log، output محلی، test fixture بزرگ و node_modules معمولاً نباید فرستاده شوند. .dockerignore هم سرعت و cache را بهتر می‌کند و هم احتمال ورود secret را کم می‌کند. اما اگر بعداً COPY به فایل ignoreشده نیاز دارد، build شکست می‌خورد؛ الگوها را در CI از context تمیز آزمون کنید.
از COPY . . زودهنگام پرهیز کنید
ابتدا manifest و lockfile وابستگی را کپی و dependency را نصب کنید؛ سپس source را اضافه کنید. این کار بیشتر سرعت cache را بهتر می‌کند تا اندازه نهایی، ولی از buildهای پرهزینه و layerهای متغیر جلوگیری می‌کند. فایل‌هایی را که runtime لازم ندارد صریحاً کپی نکنید. whitelist مسیرهای artifact اغلب قابل‌بررسی‌تر از انتقال کل repository است.
Multi-stage مؤثرترین جداسازی است
compiler، header، package manager و test runner در builder بمانند و فقط artifact لازم به runtime برود. حذف فایل در layer بعدی فضای layer قبلی را پس نمی‌دهد؛ stage تازه مرز واقعی‌تری ایجاد می‌کند. راهنمای Multi-stage Build درباره COPY --from، ABI و target تست توضیح می‌دهد.
Base Image را فقط با معیار مگابایت انتخاب نکنید
نسخه runtime، libc، معماری، CA، timezone و کتابخانه native باید سازگار باشد. Alpine برای همه workloadها بهترین نیست و تفاوت musl/glibc ممکن است dependency یا performance را تغییر دهد. image رسمی slim یا runtime-specific می‌تواند تعادل بهتری بدهد. منبع، cadence patch و SBOM/scan مهم‌تر از یک عدد کوچک‌اند.
Dependency تولیدی را جدا کنید
dependencyهای test، lint و compiler را به runtime نبرید. برای هر ecosystem از lockfile و حالت production معتبر همان package manager استفاده کنید. حذف اختیاری packageها بدون test می‌تواند feature کم‌استفاده را در production بشکند. dependencyهای transitively لازم و native libraryها را با smoke test و جریان‌های واقعی تأیید کنید.
Cache package manager و فایل موقت
اگر package نصب و cache در دستورهای جدا باشند، حذف cache در layer بعدی ممکن است اندازه قبلی را کم نکند. عملیات نصب و cleanup مرتبط را در همان RUN انجام دهید یا cache mount BuildKit را طوری استفاده کنید که وارد image نشود. فرمان دقیق برای apt، apk، npm یا pip متفاوت است؛ مثال یک ecosystem را کورکورانه به دیگری تعمیم ندهید.
فشرده‌سازی artifact و source map
برای frontend، فقط bundle production و asset لازم را انتقال دهید. source mapها برای عیب‌یابی ارزش دارند اما ممکن است source یا حجم زیادی افشا کنند؛ تصمیم بگیرید در registry خصوصی/سامانه error tracking نگهداری شوند یا در image. فشرده‌سازی static در build می‌تواند CPU runtime را کم کند، ولی Nginx/CDN و cache header باید همان format را درست ارائه دهند.
یک process یا چند process؟
تقسیم سرویس‌ها فقط برای کم‌کردن image انجام نمی‌شود. lifecycle، scale و سطح دسترسی معیارند. قراردادن app، database و proxy در یک image هم حجم و هم patch را پیچیده می‌کند. در مقابل، شکستن بی‌دلیل helperهای وابسته به lifecycle واحد نیز عملیات را سخت می‌کند. اصل یک concern را با معماری واقعی تفسیر کنید.
Debug Toolها را کجا نگه داریم؟
نصب editor و ابزار شبکه در هر runtime سطح package را بالا می‌برد. یک image debug جدا با همان پایه یا ephemeral toolbox کنترل‌شده می‌تواند برای incident استفاده شود. اما پیش از حذف ابزار، روش مشاهده log، metric، process و DNS را آماده کنید. امنیت عملی یعنی هم سطح حمله کم باشد و هم تیم بتواند حادثه را تشخیص دهد.
Squash راه‌حل اصلی نیست
ترکیب layerها ممکن است در بعضی workflowها اندازه را تغییر دهد، اما cache و reuse مشترک را کم می‌کند و علت Dockerfile بد را پنهان می‌سازد. ابتدا context، stage و dependency را اصلاح کنید. layerها برای اشتراک و cache مفیدند؛ تعداد کمتر همیشه به معنی فضای کل کمتر نیست.
امنیت و حجم رابطه یک‌به‌یک ندارند
package کمتر معمولاً سطح نگهداری را کاهش می‌دهد، اما یک dependency آسیب‌پذیر در image کوچک همچنان مهم است. scan، امضای artifact، base معتبر، user غیرroot و rebuild منظم لازم‌اند. image pinشده اگر ماه‌ها rebuild نشود، patch تازه را دریافت نمی‌کند. Dockerfile استاندارد production این چرخه را پوشش می‌دهد.
آزمون بعد از کوچک‌سازی
- image را از context تمیز و lockfile مشخص بسازید.
- با user غیرroot start و shutdown را تست کنید.
- DNS، TLS خروجی و CA certificate را بررسی کنید.
- مسیرهای کمتر استفاده‌شده، migration و worker را اجرا کنید.
- health و readiness و timeout startup را بسنجید.
- حجم pull/unpacked و زمان rollout را مقایسه کنید.
- scan و SBOM را دوباره تولید کنید.
اثر Image روی Disk سرور
Image کوچک‌تر کمک می‌کند اما log، volume و build cache ممکن است عامل اصلی باشند. layer مشترک میان چند image نیز مصرف واقعی را متفاوت می‌کند. اگر هدف آزادسازی اضطراری Disk است، قبل از بازنویسی Dockerfile دسته مصرف را با docker system df -v مشخص کنید؛ راهنمای تشخیص Disk Docker روند امن را ارائه می‌دهد.
Image چندمعماری را درست اندازه بگیرید
یک tag می‌تواند manifest چند معماری داشته باشد، ولی host معمولاً variant معماری خودش را pull می‌کند. اندازه نمایش‌داده‌شده در registry و اندازه local ممکن است به همین دلیل فرق کند. در CI برای amd64 و arm64 artifact جدا تست کنید؛ library native یا binary اشتباه می‌تواند فقط روی یکی شکست بخورد. کاهش حجم را برای هر platform بسنجید و manifest را به digestهای قابل‌ردیابی وصل کنید.
Reproducibility را قربانی چند مگابایت نکنید
دانلود binary ناشناس و حذف package manager شاید image را کوچک کند، اما verification و patch را دشوار می‌سازد. checksum یا signature artifact، نسخه dependency و منبع build باید ثبت شود. اگر مرحله بهینه‌سازی خروجی nondeterministic می‌سازد، مقایسه و rollback سخت می‌شود. یک build سرد دوره‌ای انجام دهید تا cache محلی dependency گمشده یا فایل تولیدنشده را پنهان نکرده باشد.
همچنین زمان build، زمان pull و مدت startup را جدا ثبت کنید؛ کوچک‌شدن artifact اگر build را بسیار کند یا startup را ناپایدار کند، الزاماً بهبود عملیاتی محسوب نمی‌شود.
اشتباه‌های رایج
- انتخاب base ناسازگار فقط به‌خاطر حجم
- حذف CA و timezone بدون تست
- پاک‌کردن cache در layer جدا
- کپی کل repository و history Git
- نگه‌داشتن compiler و dependency توسعه در runtime
- اندازه‌گیری فقط tag و نادیده‌گرفتن layer مشترک
- کوچک‌سازی بدون smoke test image نهایی
چه زمانی بازطراحی ارزش دارد؟
اگر pull و rollout طولانی است، nodeها دائماً image قدیمی جمع می‌کنند یا patch runtime دشوار شده، بهینه‌سازی ساخت ارزش دارد. سرویس داکرایز اپلیکیشن می‌تواند Dockerfile چندمرحله‌ای، dependency، cache CI و image runtime را بدون قربانی‌کردن قابلیت بازیابی طراحی کند.
پرسش‌های متداول
آیا Alpine همیشه کوچک‌ترین و بهترین انتخاب است؟
نه؛ سازگاری library، ابزار و رفتار workload مهم است. image slim سازگار ممکن است انتخاب عملی‌تری باشد.
آیا تعداد layer کمتر یعنی image کوچک‌تر؟
نه همیشه؛ محتوای layer و اشتراک آن‌ها مهم است. history را اندازه بگیرید.
آیا --no-cache حجم image را کم می‌کند؟
هدف اصلی آن بازسازی بدون cache است؛ اندازه به Dockerfile و artifact بستگی دارد.
آیا می‌توان source را از image حذف کرد؟
برای artifact کامپایل‌شده معمولاً بله؛ برنامه تفسیری ممکن است source runtime بخواهد. نیاز واقعی را تعیین کنید.