رجیستری خصوصی کانتینر، داخل ایران

رجیستری مدیریت‌شده هنوز عرضه نشده است: سفارش، پلن و قیمت ندارد و زمان عرضه هم اعلام نشده. چیزی که همین حالا روی سرورهای ایران‌کلاد در دسترس است، آینهٔ Docker Hub است؛ یک حافظهٔ میانی که ایمیج‌های عمومی را داخل شبکهٔ ما نگه می‌دارد تا pull آن‌ها سریع‌تر و پایدارتر باشد.

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

دسترسی مستقیم به Docker Hub از داخل ایران اغلب کند یا محدود است و همین می‌تواند استقرار را وسط کار متوقف کند. روی سرورهای ایران‌کلاد کافی است آدرس آینه را در فایل /etc/docker/daemon.json زیر کلید registry-mirrors بنویسید و سرویس Docker را دوباره راه‌اندازی کنید. آدرس دقیق و دستورها در صفحهٔ آینهٔ بسته‌ها و در پنل کاربری، بخش آینهٔ بسته‌ها آمده است.

از آن به بعد دستورهایی مثل docker pull nginx یا docker pull postgres بدون تغییر کار می‌کنند و Docker خودش ابتدا سراغ آینه می‌رود. اولین دریافت هر ایمیج از مبدأ انجام می‌شود و دفعه‌های بعد از حافظهٔ داخلی. برای نصب خود Docker، راهنمای نصب Docker را ببینید.

هر سه ابزار زیر متن‌باز و رایگان‌اند و با docker login و کوبرنتیز کار می‌کنند. انتخاب به این بستگی دارد که چه امکاناتی کنار رجیستری لازم دارید:

ساده‌ترین رجیستری خصوصی با ایمیج رسمی registry:2 ساخته می‌شود. مسیر کلی این است:

رجیستری روی سرور خودتان هزینهٔ جداگانه ندارد و فقط قیمت ساعتی سرور ابری را می‌پردازید. نرم‌افزار سبک است؛ عامل تعیین‌کننده فضای دیسک است، چون هر نسخهٔ جدید ایمیج لایه‌های تازه اضافه می‌کند. برای Gitea یا Harbor پلنی با رَم بیشتر انتخاب کنید.

قیمت‌های جدول لحظه‌ای‌اند و معادل ماهانه بر پایهٔ ۷۳۰ ساعت حساب شده است. هر سرور ۵۰ گیگابایت ترافیک ماهانه دارد؛ اگر خوشه‌ها و CI مدام ایمیج‌های حجیم pull می‌کنند، مصرف ترافیک را در پنل زیر نظر داشته باشید.

در کوبرنتیز مدیریت‌شده با دستور kubectl create secret docker-registry یک Secret شامل آدرس رجیستری، نام کاربری و توکن بسازید و در بخش imagePullSecrets هر Deployment به آن ارجاع دهید. اگر چند namespace دارید، Secret را در هر کدام بسازید یا به ServiceAccount پیش‌فرض متصل کنید.

در داکر سوارم مدیریت‌شده کافی است روی نود مدیر docker login کنید و دستور docker stack deploy را با گزینهٔ --with-registry-auth اجرا کنید تا اطلاعات ورود به نودهای کارگر هم برسد. برای خط لولهٔ CI، یک کاربر جدا با دسترسی فقط push بسازید.

رجیستری بدون احراز هویت روی اینترنت یعنی هر کسی می‌تواند ایمیج‌های شما را بخواند یا ایمیج آلوده جایگزین کند. همیشه HTTPS و رمز یا توکن را فعال کنید، برای هر سیستم کاربر جدا بسازید و دسترسی SSH سرور را با فایروال ابری محدود کنید.

برای پیدا کردن آسیب‌پذیری‌های شناخته‌شده، ابزار Trivy را در CI پیش از push اجرا کنید و اگر آسیب‌پذیری بحرانی پیدا شد، ساخت را متوقف کنید. Harbor همین کار را داخل خود رجیستری انجام می‌دهد. ایمیج پایه را کوچک نگه دارید؛ هرچه بستهٔ کمتری در ایمیج باشد، سطح حمله کمتر است.

برچسب latest را برای استقرار تولید استفاده نکنید. هر ایمیج را با شمارهٔ نسخه یا شناسهٔ کامیت برچسب بزنید تا دقیقاً بدانید چه چیزی روی سرور اجرا می‌شود و بازگشت به نسخهٔ قبلی فقط یک تغییر برچسب باشد.

اگر امروز ایمیج‌های خصوصی‌تان در Docker Hub‏، GitLab یا رجیستری یک ارائه‌دهندهٔ خارجی است، انتقال آن‌ها ساده است. برای هر ایمیج، نسخه‌های مورد نیاز را pull کنید، با نام رجیستری جدید برچسب بزنید و push کنید. ابزار skopeo همین کار را بدون نیاز به Docker و مستقیم بین دو رجیستری انجام می‌دهد و برای انتقال تعداد زیاد ایمیج مناسب‌تر است.

بعد از انتقال، آدرس ایمیج را در manifest‌های کوبرنتیز، فایل‌های compose و خط لولهٔ CI عوض کنید و Secret‌های دسترسی را به‌روز کنید. پیشنهاد ما این است که چند روز هر دو رجیستری را نگه دارید و فقط وقتی همهٔ استقرارها از رجیستری جدید انجام شد، رجیستری قبلی را خاموش کنید. همهٔ نسخه‌ها را منتقل نکنید؛ معمولاً چند نسخهٔ آخر هر ایمیج کافی است.

رجیستری‌ها با گذشت زمان بزرگ می‌شوند. سیاست ساده‌ای بگذارید، مثلاً فقط ده نسخهٔ آخر هر ایمیج بماند، و پس از حذف برچسب‌ها garbage collection را اجرا کنید؛ حذف برچسب به‌تنهایی فضای دیسک را آزاد نمی‌کند. Docker Registry می‌تواند داده‌هایش را به‌جای دیسک محلی در فضای ذخیره‌سازی ابری سازگار با S3 نگه دارد تا محدودیت دیسک سرور از بین برود.

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