د Docker بنسټیز انځورونو راښکته کول: د جوړونکي پراکسي او د جوړولو دلیلونه
هغه پراکسي دلیلونه چې د جوړولو مرحلو ته ورکول کېږي، د جوړونکي هره راجستر غوښتنه نه تنظیموي. هغه جوړونکی ومومئ چې بنسټیز انځور حل کوي.
جوړول کېدای شي د FROM د حل پر مهال ناکام شي، مخکې لدې چې د Dockerfile د کڅوړې د ډاونلوډ کومه مرحله پیل شي. د جوړونکي راجستر کلاینټ ته اړتیا ده چې خپله لار ولري ترڅو هغه بنسټیز انځور ترلاسه کړي.
| عملیه | هغه برخه چې لار ته اړتیا لري |
|---|---|
| بنسټیز انځور حل او راوړل | د جوړونکي راجستر کلاینټ |
| د RUN پر مهال ډاونلوډ | هغه بهیر چې د جوړولو مرحله ترسره کوي |
| د چلېدو پر مهال API غوښتل | هغه اپلیکیشن چې چلیږي |
جوړونکی ومومئ
د Docker اصلي ډرایور پر ډیمون متمرکز دی. نور Buildx ډرایورونه کولای شي ځانګړی BuildKit کانټینر، Kubernetes یا لرې خدمت وکاروي. د ټاکل شوي ډرایور ملاتړ شوی پراکسي میکانیزم هغه ځای کې تنظیم کړئ چې هغه worker چلیږي.
د لیپ ټاپ لوپ بیک پراکسي له لرې worker څخه په اتوماتيک ډول د لاسرسي وړ نه وي، او د سیمه ییز ډیمون سمول هغه لرې جوړونکی بیا تنظیم نه کوي.
له FROM مخکې ARG کولای شي د انځور حوالې په ټاکلو کې مرسته وکړي. خو په دې سره د راجستر کلاینټ شبکه ییزه لار نه تنظیمیږي. وروسته RUN حکمونه چې د کڅوړې تنظیمات لیکي یا سندونه نصبوي، نشي کولای دا پخوانې غوښتنه جوړه کړي.
باور، حسابونه او زیرمه شوې معلومات
منل شوی CA توکی باید د هغې برخې لپاره شته وي چې لومړنۍ راجستر اړیکه تصدیقوي. د راجستر او پراکسي اعتبار پاڼې بېلابېلو خواوو ته اجازه ورکوي؛ راجستر ته ننوتل نشي کولای د پراکسي 407 ځواب ووایي.
هغه worker چې زیرمه شوې انځور معلومات بیا کاروي کېدای شي هغه ورته شبکه ییزه غوښتنه تکرار نه کړي چې نوی worker یې کوي. په رښتیا ثبت شوې عملیه پرتله کړئ. کله چې بنسټیز انځور ته لاسرسی د پام وړ لارې له مخې کار وکړ، نو هره وروسته د جوړولو مرحلې ډاونلوډ په هماغه بله پوله کې تشخیص کړئ.