Зацягванне базавых вобразаў Docker: проксі будаўніка і аргументы зборкі
Аргументы проксі, перададзеныя крокам зборкі, не наладжваюць кожны запыт да рэестра, які робіць будаўнік. Знайдзіце будаўніка, які развязае базавы вобраз.
Зборка можа не ўдацца пры развязанні FROM яшчэ да запуску любога кроку загрузкі пакетаў Dockerfile. Кліенту рэестра будаўніка патрэбны ўласны шлях, каб атрымаць гэты базавы вобраз.
| Аперацыя | Кампанент, якому патрэбны шлях |
|---|---|
| Развязаць і атрымаць базавы вобраз | Кліент рэестра будаўніка |
| Загрузка падчас RUN | Працэс, які выконвае крок зборкі |
| Выклік API у час выканання | Працаздольная праграма |
Знайдзіце будаўніка
Стандартны драйвер Docker будуецца вакол дэмана. Іншыя драйверы Buildx могуць выкарыстоўваць асобны кантэйнер BuildKit, Kubernetes або выдалены сэрвіс. Наладзьце падтрыманы механізм проксі абранага драйвера там, дзе працуе гэты працоўны.
Loopback-проксі на ноўтбуку не дасягальны аўтаматычна з выдаленага працоўнага, а змяненне лакальнага дэмана не пераналаджвае гэты выдалены будаўнік.
ARG перад FROM можа дапамагчы выбраць спасылку на вобраз. Але гэтым ён не наладжвае сеткавы шлях кліента рэестра. Наступныя каманды RUN, якія запісваюць налады пакетаў або ўсталёўваюць сертыфікаты, не могуць выправіць гэты ранейшы запыт.
Давер, уліковыя запісы і кэшаваныя даныя
Ухвалены матэрыял CA павінен быць даступны кампаненту, які правярае першапачатковае злучэнне з рэестрам. Уліковыя даныя рэестра і проксі дазваляюць розныя бакі; уваход у рэестр не можа адказаць на 407 проксі.
Працоўны, які паўторна выкарыстоўвае кэшаваныя даныя вобраза, можа не паўтараць той жа сеткавы запыт, што і новы працоўны. Параўнайце фактычна зарэгістраваную аперацыю. Калі доступ да базавага вобраза працуе праз намечаны шлях, дыягнастуйце любую наступную загрузку кроку зборкі на гэтай наступнай мяжы.