شب اول دو سوءبرداشت رایج را کنار می‌زند: DevOps نام یک ابزار یا تیم تحویل‌گیرندهٔ کار نیست و کانتینر نیز ماشین مجازی کوچک‌شده نیست. در پایان باید بتوانید رابطهٔ فرهنگ، فرایند و خودکارسازی را توضیح دهید و مسیر یک دستور Docker را از کلاینت تا image، container و registry دنبال کنید.

پرسش‌های ۱ تا ۵: مفاهیم اصلی DevOps#

۱. DevOps چیست؟#

پاسخ کوتاه: DevOps یک شیوهٔ کار فنی و سازمانی است که توسعه، عملیات و سایر نقش‌های درگیر در تحویل نرم‌افزار را حول مسئولیت مشترک، بازخورد سریع و خودکارسازی قابل اعتماد هماهنگ می‌کند. هدف، رساندن تغییر ارزشمند به کاربر با سرعت پایدار و ریسک کنترل‌شده است.

DevOps را نباید صرفاً «ترکیب دو تیم» یا عنوان شغلی دانست. تغییر ساختار بدون تغییر جریان کار، سنجه و مالکیت نتیجه کافی نیست. نسخهٔ خوب پاسخ به حلقهٔ کامل اشاره می‌کند: برنامه‌ریزی، ساخت، آزمون، انتشار، بهره‌برداری، مشاهدهٔ رفتار و بازگرداندن آموخته‌ها به توسعه. ابزارهایی مانند Git، CI و Kubernetes می‌توانند این حلقه را پشتیبانی کنند، اما نصب آن‌ها به‌تنهایی فرهنگ اعتماد و مسئولیت مشترک نمی‌سازد.

۲. مزایای DevOps چیست؟#

پاسخ کوتاه: تحویل کوچک‌تر و پرتکرارتر، بازخورد زودتر، کاهش کار دستی، قابلیت تکرار، مشاهده‌پذیری بهتر و بازیابی سریع‌تر از خطا مزایای محتمل‌اند. همکاری روشن‌تر نیز صف تحویل میان تیم‌ها را کوتاه می‌کند.

این مزایا تضمینی نیستند. اگر تیم فقط تعداد استقرار را زیاد کند ولی آزمون، rollback و پایش نداشته باشد، نرخ شکست بالا می‌رود. در مصاحبه مزیت را به سازوکار وصل کنید: تغییر کوچک‌تر بازبینی و بازگشت را آسان‌تر می‌کند؛ pipeline یکسان تفاوت اجرای افراد را کم می‌کند؛ و مالکیت مشترک، زمان پاس‌دادن رخداد میان تیم‌ها را کاهش می‌دهد. سنجهٔ خوب باید هم سرعت و هم پایداری را بسنجد، نه اینکه یکی را قربانی دیگری کند.

۳. یکپارچه‌سازی پیوسته یا CI چیست؟#

پاسخ کوتاه: Continuous Integration یعنی اعضای تیم تغییرهای کوچک را مرتب با شاخهٔ مشترک یکپارچه کنند و هر تغییر با ساخت و آزمون خودکار، بازخورد سریع بگیرد. CI هم عادت ادغام زودهنگام است و هم سامانه‌ای که نتیجهٔ ادغام را بررسی می‌کند.

اجرای شبانهٔ آزمون روی شاخه‌هایی که هفته‌ها جدا مانده‌اند، CI کامل نیست. فاصلهٔ زیاد میان ادغام‌ها اندازهٔ تعارض و دامنهٔ عیب را افزایش می‌دهد. pipeline باید سریع و قابل اعتماد باشد؛ آزمون ناپایدار یا نتیجه‌ای که کسی نمی‌بیند بازخورد مؤثر نمی‌سازد. خروجی CI معمولاً یک artifact نسخه‌دار و شواهد آزمون است. خود CI الزاماً چیزی را در production مستقر نمی‌کند؛ این مرز را برای دو پرسش بعدی نگه دارید.

۴. تحویل پیوسته یا Continuous Delivery چیست؟#

پاسخ کوتاه: در Continuous Delivery، هر تغییر موفق از pipeline در وضعیتی قرار می‌گیرد که بتوان آن را با فرایندی تکرارپذیر به production برد. تصمیم یا تأیید نهایی انتشار می‌تواند انسانی باشد، اما ساخت، آزمون و آماده‌سازی artifact خودکار است.

کلمهٔ «قابل انتشار» مهم‌تر از «منتشرشده» است. تیم نباید پیش از هر انتشار یک دورهٔ ادغام، اصلاح دستی و بازسازی جدا انجام دهد. یک artifact یکسان باید میان محیط‌ها ارتقا یابد و تنظیم و رازها بیرون آن مدیریت شوند. کنترل‌های امنیتی، آزمون پذیرش و مهاجرت پایگاه نیز بخشی از مسیرند. اگر آخرین گام دستی است ولی همهٔ پیش‌شرط‌ها قابل تکرار و قابل مشاهده‌اند، هنوز می‌توان از Continuous Delivery سخن گفت.

۵. استقرار پیوسته یا Continuous Deployment چیست؟#

پاسخ کوتاه: Continuous Deployment یک گام جلوتر است: هر تغییر که همهٔ کنترل‌های pipeline را با موفقیت بگذراند، بدون تأیید دستی به production می‌رود. توقف باید بر پایهٔ سیاست یا شکست کنترل باشد، نه صف امضاهای روزمره.

خودکار بودن به معنی بی‌احتیاطی نیست. آزمون چندلایه، rollout تدریجی، feature flag، پایش پس از انتشار و rollback یا roll-forward لازم‌اند. سازمانی با الزام قانونی ممکن است تأیید مستقل را برای تفکیک وظایف نگه دارد و همچنان Continuous Delivery قوی داشته باشد. تفاوت اصلی دو اصطلاح، وجود یا نبود تصمیم دستی برای رفتن هر تغییر به production است؛ نه اینکه یکی pipeline دارد و دیگری ندارد.

پرسش‌های ۶ تا ۱۰: Docker#

۶. Docker چیست؟#

پاسخ کوتاه: Docker مجموعه‌ای از ابزار و API برای ساخت، توزیع و اجرای برنامه در container است. image برنامه و وابستگی‌های فضای کاربر را بسته‌بندی می‌کند و container فرایندهای آن image را با جداسازی و محدودیت‌های سیستم‌عامل اجرا می‌کند.

کانتینر کرنل جداگانهٔ یک ماشین مجازی را با خود حمل نمی‌کند؛ معمولاً کرنل میزبان را به اشتراک می‌گذارد. جداسازی با قابلیت‌هایی مانند namespace و cgroup ایجاد می‌شود و مطلق نیست. مزیت اصلی، قرارداد اجرای تکرارپذیر و جابه‌جایی آسان artifact است. دادهٔ ماندگار باید در volume یا سامانهٔ بیرونی قرار گیرد، زیرا لایهٔ نوشتنی container برای نگه‌داری بلندمدت طراحی نشده است.

۷. Docker image و container چه تفاوتی دارند؟#

پاسخ کوتاه: image الگویی تغییرناپذیر و لایه‌لایه برای ساخت محیط اجراست؛ container نمونه‌ای ساخته‌شده از image به‌همراه تنظیم زمان اجرا و یک لایهٔ نوشتنی است. از یک image می‌توان چند container مستقل ساخت.

image معمولاً با digest محتوا قابل شناسایی و در registry ذخیره می‌شود. tag یک اشارهٔ قابل تغییر است و به‌تنهایی تضمین نمی‌کند همیشه همان بایت‌ها را گرفته‌اید. container هویت، شبکه، mount و چرخهٔ عمر دارد. حذف container دادهٔ داخل لایهٔ نوشتنی آن را از بین می‌برد، مگر داده روی volume یا bind mount باشد. عبارت «image خاموش و container روشن است» برای شروع مفید است، اما container متوقف‌شده نیز همچنان container باقی می‌ماند.

۸. Dockerfile چیست؟#

پاسخ کوتاه: Dockerfile یک فایل متنی و نسخه‌پذیر از دستورهای ساخت image است. دستورهایی مانند FROM، COPY، RUN، USER و CMD پایه، فایل‌ها، عملیات زمان ساخت، کاربر و فرمان پیش‌فرض را تعریف می‌کنند.

هر دستور می‌تواند روی cache و لایه‌های خروجی اثر بگذارد. برای image قابل اعتماد، base image را آگاهانه انتخاب و ترجیحاً با digest یا سیاست به‌روزرسانی کنترل کنید، وابستگی‌ها را قفل کنید، راز را داخل image کپی نکنید و برنامه را با کاربر غیرریشه اجرا کنید. EXPOSE فقط قصد استفاده از یک درگاه را مستند می‌کند و آن را روی میزبان منتشر نمی‌کند. Dockerfile دستور اجرای دستی سرور نیست؛ دستور ساخت artifact است.

۹. Docker Compose چیست؟#

پاسخ کوتاه: Compose مدل اعلانی اجرای یک برنامهٔ چندکانتینری است. فایل compose.yaml سرویس‌ها، image یا build، شبکه، volume، متغیر و وابستگی‌های زمان اجرا را توصیف می‌کند و فرمان docker compose آن‌ها را با هم مدیریت می‌کند.

Compose برای محیط توسعه، آزمون یکپارچه و استقرارهای کوچک مفید است، اما به‌خودی‌خود ارکستراتور کلاستر چندگرهی با زمان‌بندی و self-healing کامل نیست. depends_on ترتیب ساخت وابستگی را بیان می‌کند و بدون healthcheck لزوماً آماده‌شدن برنامه را ثابت نمی‌کند. فایل Compose نباید راز واقعی را در Git نگه دارد. مزیت مصاحبه‌ای آن این است که قرارداد اجرای چند جزء را به‌جای فهرستی از فرمان‌های متفاوت، قابل بازبینی می‌کند.

۱۰. معماری Docker را توضیح دهید.#

پاسخ کوتاه: Docker معماری client-server دارد. CLI درخواست را از طریق API به daemon یا dockerd می‌فرستد؛ daemon image، container، network و volume را مدیریت می‌کند و برای دریافت یا ارسال image با registry ارتباط دارد.

در میزبان لینوکسی، daemon برای اجرای container از اجزای پایین‌تری مانند containerd و runtime سازگار با OCI استفاده می‌کند. کلاینت و daemon ممکن است روی یک میزبان یا جدا باشند، پس دسترسی به socket یا API daemon عملاً اختیار بالایی روی میزبان می‌دهد و باید محافظت شود. مسیر پاسخ خوب چنین است: فرمان docker run image را در صورت نیاز از registry می‌گیرد، container را با تنظیم شبکه و ذخیره‌سازی می‌سازد و فرایند تعریف‌شده را آغاز می‌کند.

جمع‌بندی مصاحبه‌ای#

بین هدف و ابزار رابطه بسازید: DevOps جریان تحویل و یادگیری را تغییر می‌دهد؛ CI تغییر را زود بررسی می‌کند؛ Delivery همیشه یک نسخهٔ قابل انتشار نگه می‌دارد؛ Deployment انتشار موفق را خودکار می‌کند؛ و Docker artifact اجرایی را بسته‌بندی می‌کند. اگر پاسخ شما فقط نام ابزار باشد، مصاحبه‌کننده هنوز نمی‌داند چرا یا کجا از آن استفاده می‌کنید.

منابع#