منطق ایجنت‌ها › M7 — زیرساخت، پلن و هزینه
۷.۳ پایدار مرجع ~۲۰ دقیقه

Docker و container

قبل از این فصل: فصل ۷.۱

در یک نگاه

۷.۳.۱

مشکل «روی سیستم من کار می‌کرد»

این جمله قدیمی‌ترین شکایتِ دنیای نرم‌افزار است، و برای فهمیدن container باید اول خودِ مشکل را ببینی.

یک برنامه هیچ‌وقت تنها نیست. برای کار کردن به چیزهای دیگری تکیه دارد:

روی لپ‌تاپ تو، همه‌ی این‌ها یک شکل‌اند. روی سرور، شکل دیگری. و نتیجه‌اش این است که برنامه‌ی سالم، آن‌جا خطا می‌دهد — بدون اینکه خودِ برنامه عوض شده باشد. این ناامیدکننده‌ترین نوع خطاست، چون هیچ‌چیز اشتباهی نکرده‌ای.

و توجه کن این همان مشکلی است که در مقیاس کوچک‌تر ممکن است سرِ نصب هم دیده باشی (فصل ۰.۸): «همان دستور، روی دستگاه من جواب نداد.» علتش یکی است.

۷.۳.۲

container چیست

راه‌حل ساده است: به‌جای فرستادنِ برنامه‌ی تنها، برنامه را با همه‌ی چیزهایی که لازم دارد در یک بسته می‌گذاری و آن بسته را می‌فرستی. آن بسته container است — که کانتینر خوانده می‌شود.

container به زبان ساده یک بسته که برنامه و کتابخانه‌ها و تنظیمات و نسخه‌های دقیق را با هم دارد، و همان بسته روی لپ‌تاپ و سرور شرکت و سرور اجاره‌ای یک‌طور کار می‌کند. یک بسته‌ی مهروموم برنامه کتابخانه‌ها، با نسخه‌ی دقیق تنظیمات همه‌چیز، با هم بدون تغییر لپ‌تاپ تو همان‌طور کار می‌کند سرور اجاره‌ای همان‌طور کار می‌کند کامپیوتر همکارت همان‌طور کار می‌کند قولِ container همین است: یک بسته، همه‌جا یک رفتار
بسته مهروموم است: نسخه‌ها داخلش قفل شده‌اند، پس محیطِ بیرون نمی‌تواند رفتارش را عوض کند.

دو کلمه‌ای که با هم می‌آیند و قاطی می‌شوند:

و Docker — «داکر» — نامِ رایج‌ترین ابزاری است که این کار را می‌کند. آن‌قدر رایج که اسمش تقریباً مساویِ خودِ مفهوم شده، مثل «تاید» برای پودر لباسشویی.

یک تفکیک که ارزش دانستن دارد: container با ماشین مجازی فرق دارد. ماشین مجازی یک سیستم‌عاملِ کاملِ دیگر را بالا می‌آورد (سنگین، کند در شروع)؛ container سیستم‌عاملِ میزبان را قرض می‌گیرد و فقط چیزهای خودِ برنامه را جدا نگه می‌دارد (سبک، سریع). به همین دلیل است که container این‌قدر همه‌گیر شد.

۷.۳.۳

چه وقت اسمش را می‌شنوی

حالا بخش عملی: تو کِی با این کلمه روبه‌رو می‌شوی؟

به‌خاطر بسپار لازم نیست بلد باشی container بسازی؛ لازم است بدانی وقتی جایی گفت «داکر لازم داری»، دارد چه چیزی را حل می‌کند. و آن چیز یکی است: تفاوت محیطِ تو با محیطی که برنامه در آن نوشته شده.

نکته‌ی طلایی اگر مستندی دو راه نصب داد — یکی معمولی و یکی با Docker — و تو مطمئن نیستی، راهِ Docker معمولاً کم‌دردسرتر است، چون همه‌ی نسخه‌ها از قبل جور شده‌اند. تنها هزینه‌اش نصبِ یک‌بارِ خودِ Docker است.
ضدالگو یاد گرفتنِ Docker چون «مهم است». برای کارِ این دوره تو مصرف‌کننده‌ی container هستی، نه سازنده‌اش — و فاصله‌ی این دو زیاد است. یاد گرفتنش قبل از اینکه واقعاً لازمت شود، همان ضدالگوی فصل ۷.۱ است: حفظ‌کردن بی‌بستر.

تمرین (فکری)

با یک تشبیه خودت container را توضیح بده — تشبیهی از کارِ خودت، نه از این متن. بعد آزمونش کن:

  1. تشبیهت را به ایجنت بده و بگو «این تشبیه کجا می‌لنگد؟»
  2. و خودت جواب بده: در تشبیه تو، تفاوت image و container چه می‌شود؟
پاسخنامه — یک تشبیه، و آن جایی که هر تشبیهی می‌لنگد

تشبیه: غذای آماده‌ی سفری. اگر بخواهی غذایی را جای دیگری درست کنی، به آشپزخانه‌ی آن‌جا وابسته‌ای — شاید اجاقش فرق کند، شاید ادویه نداشته باشد. ولی اگر غذا را پخته و بسته‌بندی‌شده ببری، هر جا بازش کنی همان مزه را دارد.

image = بسته‌ی دربسته در کیف. container = همان غذا وقتی گرم شده و روی میز است.

و اینجا هر تشبیهی می‌لنگد — از جمله همین: غذای بسته‌بندی هنوز به یک اجاق برای گرم‌شدن نیاز دارد، و container هم به یک سیستم‌عاملِ میزبان. یعنی container کاملاً مستقل نیست؛ فقط وابستگی‌هایش را از محیط جدا کرده، نه اینکه حذفشان کرده باشد. کسی که این را نداند، انتظار دارد یک container لینوکسی همه‌جا کار کند و بعد گیج می‌شود.

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

ذخیره شد