Dockerfile سریع‌تر و image کوچک‌تر؛ آموزش multi-stage و Build Cache

Dockerfile نقطهٔ شروع تعریف build است و Docker ابزار بسته‌بندی و اجرای برنامه‌ها در کانتینر است؛ این آموزش کمک می‌کند فرایند build سریع‌تر و image نهایی کوچک‌تر و امن‌تر شود. Docker یک پلتفرم برای بسته‌بندی برنامه و وابستگی‌های آن در image و اجرای ایزولهٔ آن‌ها در کانتینر است. این مدل مشکل «روی سیستم من کار می‌کند» را کم می‌کند، اما اگر Dockerfile درست طراحی نشود، buildهای کند و imageهای حجیم می‌سازد. هدف این آموزش، سریع‌تر کردن فرایند ساخت و کوچک‌تر و قابل‌اعتمادتر کردن image نهایی است. برای آشنایی با خدمات توسعه و اتوماسیون می‌توانید وب‌سایت تکتاز را نیز ببینید.

وقتی ساخت image در CI طول می‌کشد یا image نهایی چند برابر چیزی است که برنامه واقعاً نیاز دارد، مشکل همیشه از Docker نیست؛ اغلب Dockerfile و context ساخت، داده‌های اضافی و لایه‌های ناپایدار تولید می‌کنند. نتیجه هم زمان انتظار بیشتر، مصرف registry بالاتر و سطح حملهٔ بزرگ‌تر در محیط production است. در این راهنما با تکیه بر مستندات رسمی Docker، یک مسیر عملی برای کوچک‌تر و سریع‌تر کردن build را مرور می‌کنیم.

اول اندازه بگیرید، بعد تغییر دهید

پیش از اصلاح Dockerfile، زمان build سرد و گرم، حجم image، حجم build context و اندازهٔ هر لایه را ثبت کنید. اجرای docker build با خروجی پیشرفت مناسب، و بررسی docker history IMAGE کمک می‌کند بفهمید کدام دستور بیشترین داده را وارد image کرده است. یک build سرد معمولاً cache محلی ندارد؛ build گرم نشان می‌دهد پس از تغییر یک فایل، چه مقدار از لایه‌ها قابل استفادهٔ مجدد هستند. این دو عدد را جداگانه در CI ثبت کنید تا بهینه‌سازی با حدس جایگزین نشود.

build context را کوچک کنید

Docker هنگام build، context را به builder می‌فرستد. اگر پوشهٔ پروژه شامل .git، لاگ‌ها، فایل‌های تست، پوشهٔ cache یا خروجی‌های قبلی باشد، حتی اگر در image نهایی استفاده نشوند، زمان ارسال و پردازش را افزایش می‌دهند. یک .dockerignore دقیق بسازید و فقط فایل‌هایی را حذف کنید که واقعاً برای build لازم نیستند. کوچک‌شدن context هم سرعت شروع build را بهتر می‌کند و هم احتمال نشت فایل‌های ناخواسته به مراحل build را پایین می‌آورد.

لایه‌های پایدار را جلوتر بیاورید

ترتیب دستورها در Dockerfile روی cache اثر مستقیم دارد. فایل‌های dependency مانند package-lock.json، requirements.txt یا go.sum را پیش از کپی‌کردن کل source وارد کنید، dependencyها را نصب کنید و بعد کد برنامه را کپی کنید. در این حالت تغییر یک فایل source، لایهٔ نصب dependency را بی‌اعتبار نمی‌کند. دستورهای مرتبط را تا جای ممکن ترکیب کنید تا لایه‌های موقت و فایل‌های package manager در image باقی نمانند.

multi-stage؛ build جدا از runtime

در Dockerfile چندمرحله‌ای، stage اول ابزارهای compiler و dependencyهای توسعه را دارد و stage نهایی فقط artifact لازم برای اجرا را از آن با COPY --from=build می‌گیرد. برای Node.js می‌توان dependencyهای production و خروجی build را منتقل کرد؛ در پروژهٔ Go معمولاً یک binary استاتیک کافی است؛ در Python نیز باید وابستگی‌ها و فایل‌های runtime به‌صورت آگاهانه جدا شوند. image نهایی را با docker history و یک smoke test بررسی کنید تا compiler، shell اضافی یا secretهای مرحلهٔ build به runtime نرسند.

cache mount برای dependencyها

حتی اگر لایهٔ Dockerfile به‌دلیل تغییر source دوباره اجرا شود، cache mount می‌تواند دانلودهای قبلی package manager را نگه دارد. با BuildKit و syntax مناسب، برای npm، pip، Composer یا Go یک cache متناسب تعریف کنید. این cache بخشی از image نهایی نیست؛ فقط در زمان build کمک می‌کند. نوع و مسیر cache باید با package manager هماهنگ باشد و نباید برای نگهداری secret استفاده شود.

cache خارجی در CI

روی runnerهای ephemeral، cache محلی پس از پایان job از بین می‌رود. در این شرایط، cache را در registry یا backend مورد اعتماد ذخیره کنید و برای buildهای بعدی بخوانید. cold build و warm build را جدا گزارش کنید و مطمئن شوید cache با branch و معماری‌های مختلف قاطی نمی‌شود. cache سرعت می‌دهد، اما جایگزین lockfile، بررسی digest پایه و اسکن image نیست.

چک‌لیست انتشار

پس از تغییر Dockerfile، image را برای معماری هدف بسازید، حجم آن را با نسخهٔ قبل مقایسه کنید، docker history را بخوانید و smoke test سرویس را اجرا کنید. خروجی image را با اسکنر امنیتی بررسی کنید و secret را از build argument یا layer خارج نگه دارید. اگر نتیجهٔ build غیرمنتظره بود، ابتدا cache را invalidate کنید تا بدانید بهینه‌سازی واقعاً کار می‌کند. راهنمای رسمی Docker دربارهٔ بهینه‌سازی cache و multi-stage نقطهٔ شروع مناسبی برای جزئیات backendها و syntaxهای جدید است.

جمع‌بندی

ترکیب .dockerignore، ترتیب درست COPY، multi-stage، cache mount و cache خارجی معمولاً هم زمان CI و هم حجم image را کاهش می‌دهد. اما معیار موفقیت فقط عدد کوچک‌تر نیست: image باید قابل تکرار، قابل اسکن و برای runtime حداقلی باشد. تغییرها را مرحله‌ای اعمال کنید، قبل و بعد را اندازه بگیرید و در نهایت همان image‌ای را deploy کنید که تست و بررسی امنیتی شده است.

منبع: Docker Docs – Optimize cache usage in builds