بیشتر توسعهدهندگان داکر را فقط با کپیپیست کردن یک داکرفایل Dockerfile از Stack Overflow یاد میگیرند و همانجا کار را تمامشده میدانند. اما اگر میخواهید واقعاً مفهوم کانتینرها، محدودیتها، ویژگیهای عجیبشان و راههای شخصیسازی کردنشان را بفهمید، باید دست به کار شوید و بازی کنید!
در ادامه، ۵ پروژه عملی آوردهام که کمک میکنند مهارتهای داکر Docker خودتان را سریع ارتقا بدهید.
آیا اینها چیزهایی هستند که هر روز استفاده خواهید کرد؟ احتمالاً نه.
اما شاید روزی در یک موقعیت عجیب، این مهارتها حسابی نجاتتان بدهند!
احتمالاً الان یک پروژه دارید — مثلاً یک فرانتاند Next.js یا یک API با Flask. چالش اینجاست:
ایمیج خودتان را تا جایی که میتوانید کوچک کنید. فقط Base Image را عوض نکنید؛ بروید و فایلها، لایهها و حتی ابزارهایی که لازم ندارید را حذف کنید.
وقتی ایمیج شکست خورد و کار نکرد، بررسی کنید چرا شکست خورد. راهحل پیدا کنید. باز امتحان کنید. باز هم کوچکترش کنید.
پیشنهاد ابزار: از دستورات docker history و ابزارهایی مثل dive استفاده کنید تا ببینید دقیقاً چه چیزی داخل ایمیجتان هست.
چیزی انتخاب کنید که غیرعادی و حتی خندهدار به نظر برسد: مثلاً Spotify، یک IDE گرافیکی یا حتی کل محیط دسکتاپ لینوکس یا ویندوز!
سعی کنید آن را داخل کانتینر اجرا کنید.
بیشتر موارد شکست میخورند — و دقیقاً همین هدف ماست.
درک عمیق از محدودیتهای Docker و اینکه چرا برای همه چیز مناسب نیست.
معمولاً Dockerfileها این شکلی نوشته میشوند:
FROM node
FROM ubuntu
حالا متفاوت عمل کنید:
FROM scratch
و خودتان از صفر، Base Image بسازید که اپلیکیشن شما روی آن اجرا شود.
نکته مهم: این کار برای تولید (production) پیشنهاد نمیشود، فقط برای یادگیری عالی است.
بسیاری از پروژههای متنباز چند نوع ایمیج منتشر میکنند:
ساخت ایمیجهای منعطف و قابل نگهداری
درباره مورد چهارم (پارامتریک کردن Docker builds) الان برات دقیق توضیح میدم که چه کاری باید انجام بدی، چه چیزهایی یاد میگیری، و حتی برات یک نمونه Dockerfile هم مینویسم.
در پروژههای واقعی، معمولاً فقط یک Docker image وجود ندارد.
مثلاً:
برای اینکه هر بار همه چیز را از صفر ننویسی، میتوانی:
مثلاً:
ARG BASE_IMAGE=node:alpine FROM ${BASE_IMAGE}
# انتخاب base image با ARG ARG BASE_IMAGE=node:alpine FROM ${BASE_IMAGE} as build WORKDIR /app COPY . . RUN npm install && npm run build # مرحله production فقط فایلهای نهایی را نگه میدارد FROM nginx:alpine COPY --from=build /app/build /usr/share/nginx/html
موقع build اینطور صداش میزنی:
docker build --build-arg BASE_IMAGE=node:18-alpine -t myapp:alpine . docker build --build-arg BASE_IMAGE=node:18-bullseye -t myapp:debian .
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:multiarch .
نکته مهم
سعی کن داکر فایل Dockerfile را DRY بنویسی (Don’t Repeat Yourself)
یعنی:
- از متغیرها استفاده کن
- کدهای تکراری را با if و ARG کنترل کن
- به جای چند Dockerfile جدا، یکی بنویس که انعطافپذیر باشد
فرض کنید میخواهید در بکاند خودتان، اسکریپتهایی که کاربران ارسال میکنند اجرا کنید. چطور آن را ایمن میکنید؟
واقعاً امتحانش کنید:
اینکه داکر چه زمانی کافی نیست و چه زمانی نیاز به sandboxing واقعی دارید.
هر کدام از این پنج مورد توضیحات بیشتری دارند که اگر میخواهید برای دریافت توضیحات بیشتر در ارتباط باشید.
داکر Docker فقط یک فرانت اند (برنامه سمت جلویی) است. پشت پردهاش ابزارهایی مثل BuildKit کانتینر شده و شخصی سازی ایمیج وجود دارند.
تمرین:
مدل ذهنی دقیقتری از کانتینرها و عملکرد پشتصحنه Docker
آیا این لیست کامل است؟ قطعاً نه. همیشه چیزهای بیشتری برای یادگیری وجود دارد.
اما امیدوارم همینها انگیزهای برایتان باشد که عمیقتر به داکر Docker نگاه کنید و فقط به کپیپیست کردن قناعت نکنید.
