خدمات Docker و کانتینرسازی سرور

راهنمای خدمات Docker و کانتینرسازی سرور

کانتینرسازی یعنی اپلیکیشن و همه وابستگی‌هایش، از نسخه زبان برنامه‌نویسی تا کتابخانه‌ها، در یک ایمیج بسته‌بندی شوند و روی هر سروری که Docker دارد به همان شکل اجرا شوند. کانتینر از کرنل سیستم‌عامل میزبان استفاده می‌کند، پس از ماشین مجازی سبک‌تر است و در بیشتر سازمان‌ها داخل ماشین‌های مجازی اجرا می‌شود. Docker Compose چند کانتینر، مثل اپلیکیشن، دیتابیس و reverse proxy، را در یک فایل تعریف می‌کند. نکته‌های زیر به تیمی کمک می‌کند که می‌خواهد سرویس‌هایش را کانتینری کند، Compose را برای production آماده کند یا مشکل دریافت ایمیج روی سرورهای ایران را حل کند.

کدام سرویس‌ها را اول کانتینری کنیم؟

سرویس‌های بدون داده ماندگار، مثل اپلیکیشن وب، Workerها و reverse proxy، ساده‌ترین نقطه شروع هستند، چون با حذف و ساخت دوباره کانتینر چیزی از دست نمی‌رود. دیتابیس هم در کانتینر اجرا می‌شود، اما داده باید در ولوم باشد و بکاپ و تست بازیابی جداگانه داشته باشد. نرم‌افزاری که لایسنسش به سخت‌افزار گره خورده یا به رابط گرافیکی نیاز دارد، گزینه مناسبی برای کانتینر نیست و برای یک سایت ساده روی هاست اشتراکی هم Docker معمولاً لازم نیست. مهاجرت را با یک سرویس کم‌خطر شروع کنید، آن را کنار نصب قبلی آزمایش کنید و بعد ترافیک را جابه‌جا کنید.

Dockerfile و ایمیج قابل تکرار

اگر ایمیج هر بار با نسخه‌های متفاوتی ساخته شود، تفاوت بین محیط تست و production دوباره برمی‌گردد. ایمیج پایه را با تگ نسخه مشخص انتخاب کنید و از latest استفاده نکنید. با multi-stage build ابزارهای کامپایل در مرحله ساخت می‌مانند و ایمیج نهایی کوچک‌تر می‌شود. فایل .dockerignore جلوی کپی شدن پوشه‌های اضافه و فایل‌های محرمانه به ایمیج را می‌گیرد. رمزها و تنظیمات محیطی داخل ایمیج قرار نمی‌گیرند و هنگام اجرا با متغیر محیطی یا فایل به کانتینر داده می‌شوند.

سرویس را با کاربر غیر root اجرا کنید و healthcheck تعریف کنید تا سرویس ناسالم تشخیص داده شود. هر ایمیج را با شماره نسخه یا شناسه commit تگ‌گذاری کنید تا معلوم باشد روی سرور دقیقاً چه نسخه‌ای اجرا می‌شود و بازگشت به نسخه قبلی ممکن باشد. ساخت ایمیج و push آن به رجیستری را به pipeline بسپارید تا هر نسخه از یک مسیر مشخص ساخته شود؛ این بخش در پیاده‌سازی CI/CD طراحی می‌شود.

Docker Compose برای production

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

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

لاگ کانتینرها به‌صورت پیش‌فرض بدون محدودیت رشد می‌کند و روی سرورهای پرترافیک دیسک را پر می‌کند، پس حداکثر حجم و تعداد فایل لاگ را در daemon.json یا خود فایل Compose تعیین کنید. ولوم داده را از چرخه عمر کانتینر جدا نگه می‌دارد، اما جای بکاپ را نمی‌گیرد. برای دیتابیس‌ها خروجی منظم و تست بازیابی لازم است که در بکاپ و بازیابی بحران طراحی می‌شود. سیستم‌عامل میزبان هم باید جداگانه سخت‌سازی شود، چون کانتینر به‌خودی‌خود مرز امنیتی کامل نیست.

رجیستری داخلی و محدودیت‌های ایران

Docker Hub دسترسی از IPهای ایران را مسدود می‌کند، دسترسی به بعضی رجیستری‌های دیگر هم ممکن است محدود یا ناپایدار باشد و Docker Hub برای pull بدون احراز هویت محدودیت نرخ هم دارد. کانفیگ سرور مشکل دسترسی به تمام سرویس‌های تحریم‌شده را حل می‌کند. با این حال اگر استقرار به این دسترسی وابسته باشد، روزی که اینترنت بین‌الملل مختل است نسخه جدید منتشر نمی‌شود و سرور خراب هم بازسازی نمی‌شود. تنظیم registry-mirrors در daemon.json فقط برای ایمیج‌های Docker Hub اعمال می‌شود. ایمیج‌هایی که از ghcr.io یا quay.io می‌آیند، با پروژه proxy cache در Harbor یا تغییر آدرس ایمیج در فایل Compose مدیریت می‌شوند.

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

زمان و هزینه کانتینرسازی به چه بستگی دارد؟

تعداد سرویس‌ها و وابستگی‌هایشان، اینکه Dockerfile باید از صفر نوشته شود یا فقط بازبینی شود، حجم داده‌ای که به ولوم منتقل می‌شود و نیاز به Harbor و میرور پایه برآورد هستند. تعداد محیط‌ها، مثل تست و production، هم زمان کار را بیشتر می‌کند. برای برآورد، زبان و فریم‌ورک اپلیکیشن، فهرست سرویس‌ها، سیستم‌عامل سرور و محل نگهداری کد را بفرستید تا پس از مشاوره اولیه رایگان قیمت اعلام شود. اگر تعداد سرورها و سرویس‌ها رشد کند و به توزیع خودکار روی چند سرور نیاز پیدا کنید، مرحله بعد استقرار و مدیریت Kubernetes است.

Docker هنگام انتشار پورت قوانین iptables خودش را اضافه می‌کند و این پورت‌ها ممکن است با وجود فعال بودن UFW از اینترنت باز بمانند. پورت سرویس‌های داخلی مثل دیتابیس را منتشر نکنید یا آن را فقط روی 127.0.0.1 منتشر کنید.