واکشی تصاویر ECR: دور زدن پروکسی برای دانلود لایه‌های S3
وقتی مسیر خصوصی ECR هنوز دانلود لایه‌ها را به پروکسی شرکتی می‌فرستد، واکشی تصاویر را فراتر از میزبان رجیستری دنبال کنید.
ورود به ECR و دریافت مانیفست می‌تواند کار کند در حالی که یک لایه تصویر متوقف می‌شود. Amazon ECR لایه‌ها را در S3 ذخیره می‌کند و راهنمای نقطه پایانی VPC آن، API ECR، رجیستری و مسیر دریافت S3 را جداگانه بررسی می‌کند.
- نام میزبان لایه ناموفق را پیدا کنید.نام میزبان را از درخواست واقعی نگه دارید، به‌جای اینکه فرض کنید دور زدن رجیستری کل واکشی را پوشش می‌دهد.
- فرستنده را پیدا کنید.برای واکشی Docker، پیکربندی پروکسی دیمن را بررسی کنید. یک نمونه بومی daemon.json در Docker Engine مسیرهای لایه خصوصی ECR و S3 را کنار هم نگه می‌دارد. متغیرهای محیطی که برای یک کانتینر برنامه جدید در نظر گرفته شده‌اند نمی‌توانند دانلود تصویری را پیکربندی کنند که پیش از وجود آن کانتینر رخ می‌دهد.
- مسیر موردنظر S3 را بررسی کنید.ورودی‌های دور زدن را با نام‌های منطقه‌ای نقطه پایانی و دستور زبانی که کلاینت پشتیبانی می‌کند تطبیق دهید. DNS خصوصی، جدول‌های مسیریابی، سیاست نقطه پایانی و مجوزها نیز باید از آن مسیر پشتیبانی کنند.
| خطای مشاهده‌شده | این چه می‌گوید |
|---|---|
| رد شدن توسط پروکسی | درخواست لایه به یک واسطه رسید. |
| اتمام زمان اتصال مستقیم | ممکن است دور زدن مسیریابی مستقیم را انتخاب کرده باشد، اما آن مسیر همچنان می‌تواند غیرقابل استفاده باشد. |
از جایگزینی یک میزبان لایه گمشده با یک استثنای بازبینی‌نشده برای هر سرویس در دامنه ارائه‌دهنده بپرهیزید. یک استثنای مستقیم نمی‌تواند مسیر گیت‌وی گمشده را بسازد.
از درخواست‌های تصویر واقعی و دستورالعمل‌های فعلی ارائه‌دهنده استفاده کنید. محتوای ویژه، از جمله لایه‌های ویندوز خارجی، می‌تواند منابع دیگری وارد کند؛ یک فهرست مجاز تاریخی دو میزبانی لازم نیست آن‌ها را پوشش دهد.