چرا استقرار با داکر دردسر کمتری دارد
«روی سیستم من کار می‌کرد» یک شوخی نیست؛ نشانه این است که محیط اجرا بخشی از پروژه نیست.
نویسنده
تیم بایتیرا
تاریخ انتشار
۹ شهریور ۱۴۰۵
زمان مطالعه
1 دقیقه
خلاصه
«روی سیستم من کار می‌کرد» یک شوخی نیست؛ نشانه این است که محیط اجرا بخشی از پروژه نیست.
بیشتر مشکلات استقرار از یک چیز می‌آیند: تفاوت بین محیط توسعه و محیط اجرا. نسخه متفاوت زبان، کتابخانه‌ای که آنجا نصب است و اینجا نه، متغیری که کسی دستی تنظیم کرده و مستند نشده.
محیط به‌عنوان کد
داکر محیط اجرا را به فایلی در مخزن تبدیل می‌کند. همان تصویری که روی لپ‌تاپ ساخته می‌شود، روی سرور اجرا می‌شود. این تفاوت بین «امیدوارم کار کند» و «همان است» است.
مزیت واقعی: بازگشت‌پذیری
اگر استقرار جدید مشکل داشت، تصویر قبلی هنوز هست. بازگشت یعنی اجرای نسخه قبلی، نه بازسازی سرور.
سه اشتباه رایج
تصویر بزرگ. نصب همه ابزارهای ساخت در تصویر نهایی. راه‌حل، ساخت چندمرحله‌ای است: در یک مرحله بساز، فقط خروجی را به مرحله نهایی کپی کن.
اجرا با کاربر root. پیش‌فرض است و نباید بماند. یک کاربر بدون امتیاز بسازید و به آن سوئیچ کنید.
قرار دادن اسرار در تصویر. هر چیزی که در Dockerfile بنویسید در لایه‌های تصویر می‌ماند. اسرار باید در زمان اجرا از محیط بیایند.
نکته‌ای درباره کش
ترتیب دستورها روی سرعت ساخت اثر جدی دارد. اول فایل وابستگی‌ها را کپی و نصب کنید، بعد کد را. اگر برعکس کنید، هر تغییر کوچک در کد یعنی نصب دوباره همه وابستگی‌ها.
آنچه داکر حل نمی‌کند
داکر معماری بد را درست نمی‌کند و جای مانیتورینگ، پشتیبان‌گیری و مدیریت اسرار را نمی‌گیرد. مسئله بسته‌بندی را حل می‌کند، نه مسئله عملیات را.
مطالب مرتبط
بدهی فنی: کِی بپذیریم و کِی بپردازیم
بدهی فنی همیشه بد نیست. بد آن است که ندانیم چقدر بدهکاریم و بهره‌اش را کجا می‌پردازیم.
خواندنسرعت سایت: چه چیزی را واقعاً باید بهینه کرد
بیشتر تلاش‌های بهینه‌سازی صرف چیزهایی می‌شود که کاربر حس نمی‌کند. سه چیز است که حس می‌شود.
خواندنAPI خوب چه ویژگی‌هایی دارد
API خوب آن است که مصرف‌کننده بتواند بدون خواندن کد سرور، رفتارش را حدس بزند.
خواندن