آموزش ۵۰۰+ سوال و جواب مصاحبه داکر (Docker) سال ۲۰۲۶ - آخرین آپدیت

پوشش جامع حوزه‌های آزمون

این محیط تست جامع مستقیماً با انتظارات ساختاری پیشرفته در مصاحبه‌های واقعی DevOps، مهندسی ابری و معماری سیستم‌های Backend مطابقت دارد.

• مبانی داکر (۱۵٪): نوشتن Dockerfileهای بسیار ساختاریافته، مدیریت تنظیمات پیچیده چند-کانتینری از طریق Docker Compose، استراتژی‌های ابطال کش لایه (Layer Cache Invalidation)، اسمبل کردن ایمیج و تعاملات پیچیده با Docker CLI.

• ارکستراسیون کانتینر (۲۰٪): کلاسترینگ در مقیاس تولید با استفاده از Docker Swarm و معماری Kubernetes، پیاده‌سازی شبکه‌های Overlay، پیکربندی‌های Declarative، کشف سرویس (Service Discovery) و مکانیسم‌های پیشرفته لود بالانس داخلی.

• شبکه‌بندی داکر (۱۰٪): بررسی عمیق درایورهای شبکه (bridge, host, overlay, macvlan, none)، پیکربندی‌های دستی نگاشت پورت، الگوهای ارتباط بین کانتینری، فضای نام‌های شبکه لینوکس و نگاشت داخلی DNS داکر.

• ذخیره‌سازی داکر (۸٪): معماری چرخه حیات داده‌های مجزا با استفاده از Named Volumes، Bind Mountهای ساختاری، مانت‌های حافظه tmpfs با کارایی بالا، نوشتن درایورهای Volume شخص ثالث و استراتژی‌های پایداری داده در چندین هاست.

• امنیت داکر (۱۲٪): پیاده‌سازی منشاء دقیق ایمیج با Docker Content Trust (DCT)، مدیریت امضای رمزنگاری‌شده ایمیج، اعمال ایزولاسیون کانتینر در سطح کرنل، نوشتن سیاست‌های امنیتی شبکه و مدیریت Secretهای محیط تولید با استفاده از محیط‌های ایزوله و سیستم‌های Vault.

• پایپ‌لاین‌های CI/CD (۱۵٪): پایپ‌لاین‌های بیلد چندمرحله‌ای بومی در Jenkins، استقرار‌های خودکار مبتنی بر Git از طریق GitLab CI و GitHub Actions، ساخت تگ‌های انتشار بهینه در Docker Hub و تزریق مجموعه‌های تست خودکار کانتینری‌شده.

• عیب‌یابی داکر (۱۰٪): تحلیل‌های پیشرفته استریم لاگ، بازرسی برنامه‌ریزی‌شده کانتینر، عیب‌یابی ریشه-علت شبکه در فضای نام‌های لینوکس، نظارت بر عملکرد منابع و مدیریت وضعیت‌های خطای پیچیده Daemon.

• بهینه‌سازی داکر (۱۰٪): طراحی بیلد‌های چندمرحله‌ای سبک، به حداقل رساندن اندازه ایمیج پایه با استفاده از پیکربندی‌های Alpine یا Distroless، مدیریت بهینه کش و کنترل معیارهای مصرف منابع CPU و حافظه در زمان اجرا.

درباره دوره

به دست آوردن یک موقعیت شغلی با رشد بالا در DevOps یا مهندسی Backend نیازمند تسلط فنی عمیق بر مکانیسم‌های کانتینری‌سازی است. شرکت‌هایی که زیرساخت‌های ابری مدرن و مبتنی بر میکروسرویس را اجرا می‌کنند، دیگر متقاضیان را با دستورات ساده مانند شروع یا توقف یک کانتینر آزمایش نمی‌کنند. آن‌ها به دنبال شایستگی عملیاتی عمیق هستند؛ اینکه چگونه بیلد‌های چندمرحله‌ای را برای کاهش برد حملات طراحی می‌کنید، فضای نام‌های شبکه کانتینر را پیکربندی می‌کنید، محدودیت‌های حافظه را در ترافیک بالای تولید عیب‌یابی می‌کنید و استقرارها را مستقیماً به پلتفرم‌های پیچیده CI/CD متصل می‌نمایید. من این بانک سوالات گسترده را ایجاد کردم تا آمادگی فنی دقیقی را که برای ورود به این مراحل سخت مصاحبه با اعتماد به نفس کامل نیاز دارید، در اختیار شما قرار دهم.

با ۵۵۰ سوال اصیل و مهندسی‌شده، این منبع از مطالب سطحی عبور کرده و بر چالش‌های عیب‌یابی و معماری با دقت بالا تمرکز می‌کند. من ناهنجاری‌های واقعی سیستم، خطاهای بیلد، کرش‌های ذخیره‌سازی در محیط Production و الگوهای طراحی ارکستراسیون را تحلیل کرده‌ام. هر سوال شامل یک بررسی ساختاری جامع است که دقیقاً توضیح می‌دهد چرا رویکرد درست به درستی عمل می‌کند و چرا گزینه‌های دیگر در سناریوهای واقعی سازمانی شکست می‌خورند. اگر برای مصاحبه DevOps آماده می‌شوید، در حال تقویت مهارت‌های مهندسی معماری خود هستید یا به دنبال عبور از پانل‌های ارزیابی کانتینری‌سازی هستید، این مطالب آموزشی تمرین جامع لازم برای موفقیت شما را فراهم می‌کند.

نمونه‌ای از سوالات تمرینی

سوال ۱: دینامیک‌های ابطال کش در اسمبل Dockerfile چندمرحله‌ای

یک توسعه‌دهنده یک سرویس API تولیدی را با استفاده از یک Dockerfile چندمرحله‌ای می‌سازد. پایپ‌لاین یک اپلیکیشن Node.js را بیلد می‌کند، اما تغییرات در کد منبع در دایرکتوری اپلیکیشن باعث می‌شود داکر در هر تکرار، تمام وابستگی‌های سنگین npm را دوباره دانلود کند. قطعه کد مربوطه به این شکل است:

Dockerfile

FROM node:18-alpine

WORKDIR /app

COPY . .

RUN npm ci

CMD ["node", "server.js"]

کدام تنظیم بهینه‌سازی، لایه کشینگ پکیج‌ها را ایزوله می‌کند تا از دانلودهای دورادور غیرضروری جلوگیری شود؟

• الف) انتقال اعلان WORKDIR /app به پایین، درست قبل از بلوک اجرای نهایی CMD.

• ب) استفاده از یک مانت ذخیره‌سازی tmpfs در طول مرحله اجرای RUN npm ci برای نگه داشتن فایل‌های موقت وابستگی.

• ج) تغییر تخصیص ایمیج پایه به یک نسخه distroless که وابستگی‌های پکیج را به طور بومی در ذخیره‌سازی هاست مدیریت می‌کند.

• د) کپی کردن صریح package.json و package-lock.json به ./، سپس اجرای RUN npm ci، و سپس اجرای یک بلوک COPY . . جداگانه برای بقیه کد.

• ه) قرار دادن حلقه نصب وابستگی‌ها در یک بلوک بیلد چندمرحله‌ای صریح با برچسب FROM scratch.

• و) تزریق یک دستور متغیر محیطی (ENV CACHE_INVALIDATE=true) درست بالای دستور اصلی نصب پکیج.

پاسخ صحیح و توضیح:

• پاسخ صحیح: د

• چرا درست است: داکر بر یک مکانیسم کشینگ لایه‌ای متوالی تکیه دارد. هر دستور در Dockerfile یک لایه ایمیج متمایز ایجاد می‌کند. وقتی یک بلوک COPY اجرا می‌شود، داکر چک‌سام‌های رمزنگاری‌شده فایل‌های هدف را تحلیل می‌کند تا determine کند آیا می‌تواند از لایه کش‌شده استفاده کند یا خیر. در تنظیمات اولیه، COPY . . همه چیز را وارد می‌کند، به این معنی که هر تغییر کوچک در یک فایل کد منبع، کش آن لایه را ابطال می‌کند. در نتیجه، تمام لایه‌های بعدی - از جمله مرحله سنگین RUN npm ci - باید از ابتدا اجرا شوند. با کپی کردن تنها فایل‌های مانیفست پکیج در ابتدا، لایه RUN npm ci کاملاً کش شده و دست‌نخورده باقی می‌ماند مگر اینکه یک وابستگی در package.json واقعاً تغییر کند.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: تغییر ترتیب WORKDIR این حقیقت را تغییر نمی‌دهد که فایل‌ها همچنان پیش از نصب وابستگی‌ها کپی می‌شوند.

  • گزینه ب نادرست است: استفاده از مانت tmpfs محل نگه داشتن فایل‌ها در حافظه را تغییر می‌دهد اما مانع از ابطال بخش‌های کش توسط موتور اجرای لایه نمی‌شود.

  • گزینه ج نادرست است: ایمیج‌های Distroless برای به حداقل رساندن حجم، مدیریت پکیج‌ها و شل‌ها را کاملاً حذف می‌کنند، اما پکیج‌های سفارشی سطح اپلیکیشن را به طور خودکار مدیریت نمی‌کنند.

  • گزینه ه نادرست است: ایمیج پایه scratch کاملاً خالی است؛ این ایمیج فاقد ران‌تایم‌های باینری node و npm لازم برای اجرای بلوک نصب وابستگی است.

  • گزینه و نادرست است: تزریق یک متغیر محیطی که تغییر می‌کند، صراحتاً باعث ابطال کش می‌شود که دقیقاً عکس چیزی است که توسعه‌دهنده می‌خواهد.

سوال ۲: رفع موانع ایزولاسیون شبکه در تنظیمات چند-کانتینری Docker Compose

یک سیستم Backend از Docker Compose برای مدیریت یک کانتینر API پایتون Flask و یک کانتینر دیتابیس PostgreSQL جداگانه استفاده می‌کند. کانتینر API مدام خطای اتصال زیر را می‌دهد: dial tcp: lookup db on 127.0.0.1:53: no such host. سرویس دیتابیس صراحتاً تحت نام سرویس db در پیکربندی compose تعریف شده است و اپلیکیشن API از رشته اتصال postgresql://user:pass@db:5432/main استفاده می‌کند. علت این اختلال در ارتباط چیست؟

• الف) Docker Compose برای انجام نگاشت DNS خودکار بین کانتینری، نیاز دارد که کانتینرها در حالت شبکه بومی هاست (native host network mode) اجرا شوند.

• ب) کانتینر اپلیکیشن API سعی می‌کند دامنه دیتابیس را از طریق رابط loopback داخلی خود Resolve کند به جای اینکه به موتور DNS داخلی داکر تکیه کند.

• ج) پیکربندی سرویس دیتابیس فاقد توصیف ویژگی صریح container_name: db برای ثبت هویت هاست خود به صورت جهانی است.

• د) کانتینرها روی شبکه‌های bridge پیش‌فرض متفاوتی اجرا می‌شوند زیرا با قوانین انتشار پورت صریح پیکربندی نشده‌اند.

• ه) سیستم هاست زیربنایی فاقد نقشه IP سرور DNS خارجی معتبر در فایل عملیاتی /etc/resolv.conf خود است.

• و) PostgreSQL به طور خودکار اتصالات ورودی کانتینر را مسدود می‌کند مگر اینکه ایمیج دیتابیس به صورت دستی با توکن Docker Content Trust امضا شده باشد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: Docker Compose به طور خودکار یک شبکه bridge ایزوله پیش‌فرض برای تمام سرویس‌های لیست شده در یک فایل compose ایجاد می‌کند. هر سرویس به این شبکه می‌پیوندد و می‌تواند سایر کانتینرها را با استفاده از نام سرویس آن‌ها به عنوان Hostnameهای معتبر DNS شناسایی کند. با این حال، اگر فریم‌ورک اپلیکیشن یا کتابخانه کلاینت دیتابیس در کانتینر API به گونه‌ای پیکربندی شده باشد که درخواست‌های DNS را منحصراً از طریق loopback محلی (127.0.0.1) هدایت کند، یا اگر فایل resolver استاندارد کانتینر را کاملاً نادیده بگیرد، سرور DNS داخلی داکر (127.0.0.11) را دور می‌زند. این امر باعث می‌شود جستجو برای Hostname 'db' بلافاصله با شکست مواجه شود.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: استفاده از حالت شبکه host، ایزولاسیون شبکه را کاملاً از بین می‌برد و در واقع سیستم نگاشت نام شناسایی DNS داخلی داکر را غیرفعال می‌کند.

  • گزینه ج نادرست است: Compose هویت‌ها را مستقیماً بر اساس نام‌های کلید سرویس ریشه نگاشت می‌کند؛ ویژگی container_name برای ردیابی DNS کاملاً اختیاری است.

  • گزینه د نادرست است: انتشار پورت‌ها با استفاده از ports: پورت‌های کانتینر را به سیستم هاست خارجی باز می‌کند، اما هیچ تأثیری بر مسیرهای رزولوشن نام داخلی بین کانتینرها ندارد.

  • گزینه ه نادرست است: خطا مربوط به شکست رزولوشن داخلی برای یک Alias کانتینر است؛ سرورهای DNS خارجی روی هاست مسئول نگاشت نام‌های کانتینر نیستند.

  • گزینه و نادرست است: Docker Content Trust یکپارچگی ایمیج را تأیید می‌کند و از اجرای ایمیج‌های غیرقابل اعتماد جلوگیری می‌کند، اما اتصالات شبکه داخلی یا در دسترس بودن پورت‌ها در زمان اجرا را تغییر نمی‌دهد.

سوال ۳: رفتار تخلیه Volume داده‌های کانتینر در هنگام به‌روزرسانی لایه هاست

یک مهندس عملیات ابری یک کانتینر لاگینگ Stateful را با استفاده از یک Bind Mount صریح که از دایرکتوری هاست /var/log/app مستقیماً به دایرکتوری داخلی کانتینر /var/log نگاشت شده است، ایجاد می‌کند. در طول یک ارتقای زیرساختی Rolling، ایمیج کانتینر حذف شده و با یک نسخه نرم‌افزاری کاملاً به‌روز جایگزین می‌شود. چه اتفاقی برای فایل‌های لاگ زیربنایی ذخیره شده در /var/log/app روی هاست می‌افتد؟

• الف) فایل‌های هاست به طور خودکار پاک می‌شوند زیرا داکر همگام‌سازی مطلق چرخه حیات را روی تمام Bind Mountهای فعال اعمال می‌کند.

• ب) فایل‌ها به طور خودکار به یک دایرکتوری تصادفی مدیریت شده توسط سیستم در /var/lib/docker/volumes/ منتقل می‌شوند تا از خرابی جلوگیری شود.

• ج) داده‌ها در درایو ذخیره‌سازی هاست کاملاً دست‌نخورده باقی می‌مانند زیرا Bind Mountها مستقل از چرخه حیات کانتینر وجود دارند.

• د) لاگ‌ها به طور دائمی Read-only و غیرقابل خواندن می‌شوند زیرا لایه جدید کانتینر مجموعه‌ای از IDهای کاربر فضای نام تصادفی جدید را اختصاص می‌دهد.

• ه) درایور ذخیره‌سازی داکر به طور خودکار دایرکتوری را به یک ساختار فایل .tar مستقل تبدیل می‌کند تا در فضای دیسک سیستم صرفه‌جویی شود.

• و) معماری فایل هاست با یک استثنای تداخل مانت دایرکتوری کرش می‌کند تا زمانی که سرور زیربنایی ریبوت شود.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• چرا درست است: Bind Mountها یک مسیر فایل صریح تعریف شده توسط کاربر در سیستم فایل هاست را مستقیماً به فضای دایرکتوری کانتینر نگاشت می‌کنند. برخلاف لایه‌های خواندنی-نوشتنی استاندارد کانتینر که همراه با نمونه کانتینر کاملاً تخریب می‌شوند، Bind Mountها به زیرساختی اشاره می‌کنند که مستقل از داکر وجود دارد. وقتی یک کانتینر متوقف، حذف یا کاملاً به ایمیج جدید ارتقا می‌یابد، داده‌های زیربنایی ذخیره شده در آن مسیر هاست کاملاً حفظ شده و بدون تغییر باقی می‌مانند.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: داکر هرگز دایرکتوری‌های هاست را در طول حلقه‌های تخریب استاندارد کانتینر هنگام مدیریت Bind Mountها حذف نمی‌کند.

  • گزینه ب نادرست است: انتقال داده‌ها به /var/lib/docker/volumes/ تنها زمانی اتفاق می‌افتد که با Volumeهای استاندارد ناشناس یا نام‌گذاری شده که صراحتاً توسط داکر مدیریت می‌شوند سروکار داشته باشیم، نه Bind Mountها.

  • گزینه د نادرست است: اگرچه مجوزهای فایل باید با کاربر در حال اجرای کانتینر همسو باشد، اما فایل‌ها به طور دائمی برای سیستم هاست والد خراب یا غیرقابل خواندن نمی‌شوند.

  • گزینه ه نادرست است: داکر دایرکتوری‌های هاست را فشرده نمی‌کند و هنگام تخریب یا به‌روزرسانی کانتینرها، به طور خودکار بلوک‌های داده آرشیوی ایجاد نمی‌کند.

  • گزینه و نادرست است: قفل‌های فایل به محض خروج پروسه کانتینر قدیمی به طور تمیز آزاد می‌شوند و به نسخه جدید ایمیج اجازه می‌دهند بلافاصله مسیر را بدون نیاز به ریبوت سیستم مانت کند.

چه انتظاراتی داشته باشید

• به تست‌های سوالات مصاحبه خوش آمدید تا شما را برای آزمون تمرینی سوالات مصاحبه داکر آماده کنیم.

• شما می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات گسترده و اصیل است.

• اگر سوالی داشته باشید، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• با اپلیکیشن Udemy سازگار با موبایل است.

امیدواریم تا الان متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.