Docker build ખાનગી ડિપેન્ડન્સી સુધી પહોંચતું નથી: આ તપાસો

તમારી મશીન પર સરળતાથી રિઝોલ્વ થતું ખાનગી પેકેજ build વચ્ચે 404 અથવા ટાઇમઆઉટ સાથે નિષ્ફળ જઈ શકે છે, અને Dockerfile ભાગ્યે જ તેનું કારણ હોય છે. build પગલું બીજા નેટવર્ક નેમસ્પેસમાં ચાલે છે, અલગ DNS દૃશ્ય અને અલગ ક્રેડેન્શિયલ સ્ટોર સાથે, જે તમે જે શેલમાં પરીક્ષણ કર્યું તેનાથી અલગ છે. આ તપાસો ક્રમમાં કરો અને પહેલી જે નિષ્ફળ જાય ત્યાં થોભો, કારણ કે દરેક પછીની તપાસ ધારે છે કે અગાઉની પસાર થઈ છે. દરેક પગલું એ આદેશનું નામ આપે છે જે બાબત નક્કી કરે છે.

Dockerfile થી નહીં, builder ના નામથી શરૂ કરો

BuildKit સ્થાનિક, કન્ટેનરમાં અથવા બીજી મશીન પર ચાલી શકે છે, અને દરેકનું પોતાનું ડિફોલ્ટ નેટવર્ક હોય છે. ચલાવો docker buildx ls અને કંઈપણ બદલતા પહેલાં તારાથી ચિહ્નિત નોડ વાંચો. એક docker-container ડ્રાઇવર અથવા ક્લાઉડ builder તમે ત્યાં આદેશ લખ્યો છે એટલા માટે જ તમારા લેપટોપનો ખાનગી રૂટ શેર કરતું નથી. જો સક્રિય builder દૂરનું હોય, તો બાકીની દરેક તપાસ તમારા વર્કસ્ટેશન પર નહીં, તે હોસ્ટ સામે ચલાવવી પડશે.

builder પોતાનું રિઝોલ્વર કન્ફિગરેશન અને proxy ચલોપણ સાથે રાખે છે. બંને build સમયે વાંચવામાં આવે છે અને build શરૂ કરનાર ટર્મિનલથી વારસામાં મળતા નથી.

build પગલાની અંદરથી નેટવર્ક માર્ગ સાબિત કરો

એક કામચલાઉ સ્ટેજ લખો જે ડિપેન્ડન્સી હોસ્ટ રિઝોલ્વ કરે અને તેની સાથે જોડાણ ખોલે. આ એકમાત્ર પરીક્ષણ છે જે પ્રશ્નનો જવાબ builder માટે આપે છે, તમારા શેલ માટે નહીં.

FROM alpine:3.20
RUN apk add --no-cache curl bind-tools  && getent hosts registry.example.internal  && curl -sS -o /dev/null -w "%{http_code}
" https://registry.example.internal/simple/

તમારું અસલી build જે builder, નેટવર્ક મોડ અને secret માઉન્ટ વાપરે છે તેની સાથે જ એ ફાઇલ build કરો: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. જો getent કંઈ છાપે નહીં, તો ખામી નામ-રિઝોલ્યુશનમાં છે અને કોઈ ક્રેડેન્શિયલ તેને સુધારશે નહીં. જો નામ રિઝોલ્વ થાય પણ curl ટાઇમઆઉટ જણાવે, તો અવરોધ રૂટ અથવા રજિસ્ટ્રી સામેની ઇગ્રેસ નીતિ છે.

પ્રોબ જવાબ આપે કે તરત તેને કાઢી નાખો. તે નિદાનનું સ્ટેજ છે અને તેને ક્યારેય ટેગ કે પુશ કરવું ન જોઈએ.

ક્રેડેન્શિયલ કોપી કરવાને બદલે માઉન્ટ કરો

માર્ગ કામ કરે પછી, પ્રમાણીકરણ એ લાઇનમાં આગળની નિષ્ફળતા છે. BuildKit secret માઉન્ટ એક ફાઇલને એક RUN પગલા સામે ખુલ્લી કરે છે, તેને લેયરમાં લખ્યા વિના; ડિપેન્ડન્સી સાધનને એ જ જોઈએ છે અને ઇમેજે એ રાખવું ન જોઈએ.

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc     npm ci --omit=dev

secret Dockerfile ની બહારથી પૂરું પાડવું પડશે: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. ફાઇલ ક્લાયન્ટ પાસે જ રહે છે અને ક્યારેય ઇમેજ ઇતિહાસમાં જતી નથી. એક ARG કે ENV સમાન ટોકન સાથે આ કામ કરતું નથી, કારણ કે બંને ઇમેજ કન્ફિગરેશનમાં નોંધાય છે.

રૂટ વગરની ઇમેજને પોતાનો લક્ષ્ય માર્ગ જોઈએ, જેમ કે /home/app/.npmrc અથવા pip, Maven કે Cargo માટે સમકક્ષ ફાઇલ. માઉન્ટ લક્ષ્ય આદેશ ચલાવતા વપરાશકર્તા સાથે મેળ ખાવો જોઈએ, નહીં તો સાધન ખૂટતી કન્ફિગરેશન ફાઇલ જણાવશે જે વાસ્તવમાં હાજર છે.

ડિપેન્ડન્સી સાધન ઇમેજમાં શું છોડે છે તે તપાસો

કામચલાઉ માઉન્ટ ક્રેડેન્શિયલને લેયરની બહાર રાખે છે, પણ સાધનને બીજું કંઈ લખતું અટકાવતું નથી. પેકેજ મેનેજરો lock ફાઇલો, કેશ ડિરેક્ટરીઓ અને ક્યારેક રિઝોલ્વ થયેલી રજિસ્ટ્રી URL મૂકી જાય છે.

Dockerfile પર ભરોસો કરવાને બદલે તૈયાર ફાઇલસિસ્ટમ વાંચો. docker history --no-trunc image:tag દરેક લેયર આદેશની યાદી આપે છે, અને docker run --rm image:tag sh -c "ls -a /root" ચાલતા કન્ટેનરમાં શું બચ્યું તે બતાવે છે. જ્યારે ફાઇલ ફક્ત માઉન્ટ કરેલી હોય ત્યારે પણ, લોગ લીટીમાં લખાયેલ ટોકન npm ci દરમિયાન પણ લીક જ રહે છે.

build લોગ પણ વાંચો, કારણ કે --progress=plain આદેશોનું આઉટપુટ શબ્દશઃ છાપે છે. જો ટોકન ત્યાં દેખાય, તો બીજું કંઈ કરતાં પહેલાં તેને ફેરવો અને એવી ફાઇલ દ્વારા મોકલો જે સાધન શાંતિથી વાંચે છે.

ખાતરી કરો કે રનટાઇમ ઇમેજને હવે ખાનગી માર્ગની જરૂર નથી

build અને ચાલતી એપ્લિકેશન એક જ ડિપેન્ડન્સીના બે અલગ વપરાશકર્તા છે, અને ફક્ત પહેલાને ખાનગી માર્ગની જરૂર છે. પૂર્ણ ઇમેજે build સમયની ક્રેડેન્શિયલ વગર શરૂ થવું જોઈએ, તેની રનટાઇમ ડિપેન્ડન્સીઓ રિઝોલ્વ કરવી જોઈએ અને ટ્રાફિક પરોસવો જોઈએ.

જ્યાં ખાનગી રજિસ્ટ્રી પહોંચમાં નથી ત્યાં તેને ચકાસો, અથવા ફક્ત કન્ટેનરને --network none સાથે શરૂ કરો અને ખાતરી કરો કે તે માઉન્ટ કરેલ secret વગર બૂટ થાય છે. જે કન્ટેનર ફક્ત build secret હાજર હોય ત્યારે જ શરૂ થાય છે તે હજી પણ build પર્યાવરણ સાથે જોડાયેલું છે.

જો કન્ટેનરને ખરેખર રનટાઇમમાં રજિસ્ટ્રીની જરૂર હોય, તો તે અલગ ઍક્સેસ નિર્ણય છે, અને તેનું સ્થાન ઓર્કેસ્ટ્રેટરના secret સ્ટોરમાં છે, build માં નહીં. બંને માર્ગો અલગ દસ્તાવેજ કરો જેથી કોઈ build ફ્લેગ વડે રનટાઇમ પુલ સુધારવાનો પ્રયત્ન ન કરે. જ્યારે પાંચેય તપાસ પસાર થાય, ત્યારે મૂળ લક્ષણને દરેક સ્તરે નામ આપેલું કારણ હોય છે, Docker નેટવર્કિંગ વિશેની ધારણા નહીં.