بندر یک HTTP Proxy است که برای container runtime کلاسترهای Kubernetes ستون از جمله docker یا containerd تنظیم می‌شود تا بتوانید بدون دغدغه‌ی تحریم imageهای خورد را از رجیستری‌های معروف (مثل docker hub، gcr و quay) دریافت کنید.

وقتی یک درخواست image pull به container runtime شما مثل docker یا containerd می‌رسد، از بندر به عنوان یک پروکسی رد شده و سپس به مقصد می‌رسد. درخواست‌های http که از سمت container runtime فرستاده می‌شوند اعم از درخواست‌های manifest و درخواست‌های blob مربوط به image ها از داخل پروکسی بندر عبور می‌کنند و به مقصد می‌رسند. بندر برای یک سری از container registry های معروف به عنوان یک mirror نیز عمل کرده و imageهای پر استفاده را cache می‌کند. ولی برای بقیه‌ی آنها کاملا مانند یک پروکسی عادی عمل می‌کند. بندر تنها به ریکوئست‌هایی که از سمت کلاسترهای کوبرنیتیز ستون ارسال شوند پاسخ می‌دهد. بندر درخواست‌های push به این رجیستری‌ها را پشتیبانی نمی‌کند و هم‌چنین imageهای private در این رجیستری‌ها در بندر پشتیبانی نمی‌شوند.

بندر از طریق environment variableهای docker یا containerd بر روی ورکرهای کلاستر تنظیم می‌شود.

در کلاستر هایی که از containerd استفاده می‌کنند در مسیر زیر می‌توانید فایل مربوط به کانفیگ کردن systemd service آن را مشاهده کنید.

و در کلاسترهایی که از docker استفاده می‌کنند به شکل زیر کانفیگ می‌شود:

متغیر NO_PROXY با آدرس‌ رجیستری‌هایی جایگزین می‌شود که از بندر رد نمی‌شوند و BANDAR_TOKEN یک توکن است که به طور اتوماتیک جایگزین می‌شود و یک مکانیزم کنترل دسترسی به بندر است.

شما می‌توانید با تغییر تنظیمات بالا بر روی workerهای خود بندر را غیر فعال کرده یا رجیستری‌هایی که درخواست‌ به آن‌ها از بندر عبور می‌کند را تغییر دهید.

دقت کنید پس از آپدیت کردن متغیرهای مربوط به proxy برای container runtime که در بالا توضیح داده شده است. لازم است تا مراحل زیر اجرا شود تا این تغییرات اعمال شوند.

که CONTAINER_RUNTIME_NAME می‌تواند docker یا containerd باشد. دقت کنید اگر از docker به عنوان container runtime استفاده می‌کنید restart کردن docker باعث restart شدن container های شما خواهد شد.

• برای استفاده از پروکسی خودتان برای اتصال به registery های خارجی می‌توانید به شکل زیر فایل کانفیگی که در قسمت بالا وارد شده است را تغییر دهید.

• برای اینکه container registry شما از بندر عبور نکند می‌توانید به شکل زیر فایل را تغییر دهید.

• می‌توانید هم به صورت کلی از بندر استفاده نکنید و به شکل دیگری مشکل pull کردن image از registry های معروف را حل کنید. برای این کار فایل کانفیگ container runtime را پاک کنید یا به شکل دلخواه خود تغییر دهید.

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

در حال حاضر imageهای داخل registryهای زیر در بندر cache می‌شوند و تحریم ایران در آن‌ها دور زده می‌شود:

• docker.io
• gcr.io
• mcr.microsoft.com
• quay.io

برای رجیستری‌های زیر تنها تحریم دور زده می‌شود و شامل cache نمی‌شوند:

• amazonaws.com
• registry.opensource.zalan.do
• gitlab.com
• gitlab-static.net
• k8s.io
• docker.elastic.co
• oracle.com

ریکوئست‌های به هر registry که در کانفیگ container runtime در دسته‌ی NO_PROXY قرار نگیرد از بندر عبور کرده و لذا اگر container registry شما (مثلا artifact registry مربوط به gitlab شما) در این دسته قرار ندارد، باید container registry شما به صورت public در اینترنت قابل دسترسی باشد تا بندر بتواند به آن ریکوئست ارسال کند و باید درخواست‌ها از سمت بندر را نیز پاسخ دهد. مثلا اگر در container registry خود از مکانیزم ip whitelist استفاده می‌کنید باید آدرس gateway.bandar.sotoon.ir را نیز داخل whitelist قرار دهید. لازم به ذکر است بندر به محتوی ریکوئست‌های شما به container registry خود دسترسی ندارد و فقط مانند یک پروکسی آنها را از خود رد می‌کند. و طبیعتا به همین خاطر image‌های داخل container registry شما در بندر cache نمی‌شوند.

• ریکوئست‌ها از سمت بندر به container registry شما لزوما با آیپی ثابتی ارسال نمی‌شوند و به جای وایت لیست کردن یک آیپی ثابت باید آیپی‌ای که gateway.bandar.sotoon.ir به آن resolve می‌شود را همواره وایت لیست کنید.