Docker build സ്വകാര്യ ആശ്രിതത്വത്തിൽ എത്തുന്നില്ല: ഇത് പരിശോധിക്കുക

നിങ്ങളുടെ മെഷീനിൽ പ്രശ്നമില്ലാതെ resolve ചെയ്യുന്ന സ്വകാര്യ പാക്കേജ് build-നുള്ളിൽ 404 അല്ലെങ്കിൽ ടൈംഔട്ടോടെ പരാജയപ്പെടാം, Dockerfile അതിന് കാരണമാകുന്നത് അപൂർവമാണ്. build ഘട്ടം മറ്റൊരു നെറ്റ്വർക്ക് നെയിംസ്പേസിൽ പ്രവർത്തിക്കുന്നു, വ്യത്യസ്ത DNS കാഴ്ചയും വ്യത്യസ്ത ക്രെഡൻഷ്യൽ സ്റ്റോറും ഉപയോഗിച്ച്, നിങ്ങൾ പരീക്ഷിച്ച shell-ൽ നിന്ന് വ്യത്യസ്തമായി. ഈ പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക, കാരണം ഓരോ തുടർന്നുള്ള പരിശോധനയും മുൻപത്തേത് കടന്നുപോയി എന്ന് കരുതുന്നു. ഓരോ ഘട്ടവും കാര്യം തീരുമാനിക്കുന്ന കമാൻഡ് പേരിടുന്നു.

Dockerfile അല്ല, builder-ന്റെ പേരിൽ തുടങ്ങുക

BuildKit ലോക്കൽ, കണ്ടെയ്നറിൽ അല്ലെങ്കിൽ മറ്റൊരു മെഷീനിൽ പ്രവർത്തിക്കാം, ഓരോന്നിനും സ്വന്തം ഡിഫോൾട്ട് നെറ്റ്വർക്ക് ഉണ്ട്. പ്രവർത്തിപ്പിക്കുക docker buildx ls എന്നിട്ട് എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് നക്ഷത്ര ചിഹ്നമിട്ട നോഡ് വായിക്കുക. ഒരു docker-container ഡ്രൈവറോ ക്ലൗഡ് builder-ഓ നിങ്ങൾ അവിടെ കമാൻഡ് ടൈപ്പ് ചെയ്തതിനാൽ മാത്രം നിങ്ങളുടെ ലാപ്ടോപ്പിലെ സ്വകാര്യ റൂട്ട് പങ്കിടുന്നില്ല. സജീവമായ builder വിദൂരമാണെങ്കിൽ, ബാക്കിയുള്ള ഓരോ പരിശോധനയും നിങ്ങളുടെ വർക്ക്സ്റ്റേഷനിലല്ല, ആ ഹോസ്റ്റിൽ നടത്തണം.

builder-ന് സ്വന്തമായി resolver കോൺഫിഗറേഷനും proxy വേരിയബിളുകളുംഉണ്ട്. രണ്ടും build സമയത്ത് വായിക്കുന്നു, build ആരംഭിച്ച ടെർമിനലിൽ നിന്ന് പാരമ്പര്യമായി ലഭിക്കുന്നില്ല.

build ഘട്ടത്തിനുള്ളിൽ നിന്ന് നെറ്റ്വർക്ക് പാത തെളിയിക്കുക

ആശ്രിതത്വത്തിന്റെ ഹോസ്റ്റ് resolve ചെയ്ത് അതിലേക്ക് കണക്ഷൻ തുറക്കുന്ന ഒറ്റത്തവണ ഘട്ടം എഴുതുക. builder-നു വേണ്ടി ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന ഏക പരീക്ഷ ഇതാണ്, നിങ്ങളുടെ shell-നു വേണ്ടിയല്ല.

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 പ്രിന്റ് ചെയ്യുന്നില്ലെങ്കിൽ, തകരാർ പേര്-resolve ചെയ്യുന്നതിലാണ്, ഒരു ക്രെഡൻഷ്യലും അത് ശരിയാക്കില്ല. പേര് resolve ചെയ്യുന്നുവെങ്കിലും curl ടൈംഔട്ട് റിപ്പോർട്ട് ചെയ്താൽ, തടസ്സം റൂട്ടോ രജിസ്ട്രിക്ക് മുൻപിലുള്ള എഗ്രസ് നയമോ ആണ്.

പ്രോബ് ഉത്തരം നൽകിയ ഉടൻ അത് ഇല്ലാതാക്കുക. ഇത് ഡയഗ്നോസ്റ്റിക് ഘട്ടമാണ്, ഇതിന് ഒരിക്കലും ടാഗ് ചെയ്യുകയോ push ചെയ്യുകയോ അരുത്.

ക്രെഡൻഷ്യൽ പകർത്തുന്നതിന് പകരം മൗണ്ട് ചെയ്യുക

പാത പ്രവർത്തിച്ചാൽ, അടുത്ത പരാജയം പ്രാമാണീകരണമാണ്. BuildKit secret മൗണ്ട് ഒരു ഫയൽ ഒരു RUN ഘട്ടത്തിന് മാത്രം തുറക്കുന്നു, അത് ലെയറിൽ എഴുതാതെ; ആശ്രിതത്വ ഉപകരണത്തിന് വേണ്ടതും image സൂക്ഷിക്കാൻ പാടില്ലാത്തതും അതാണ്.

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 .. ഫയൽ ക്ലയന്റിൽ തന്നെ നിൽക്കുന്നു, image ചരിത്രത്തിൽ ഒരിക്കലും പ്രവേശിക്കുന്നില്ല. ഒരു ARG അല്ലെങ്കിൽ ENV അതേ ടോക്കണുമായി ഈ ജോലി ചെയ്യുന്നില്ല, കാരണം രണ്ടും image കോൺഫിഗറേഷനിൽ രേഖപ്പെടുത്തുന്നു.

root അല്ലാത്ത image-ന് സ്വന്തം ലക്ഷ്യ പാത വേണം, ഉദാഹരണത്തിന് /home/app/.npmrc അല്ലെങ്കിൽ pip, Maven, Cargo എന്നിവയ്ക്കുള്ള തുല്യമായ ഫയൽ. മൗണ്ട് ലക്ഷ്യം കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്ന ഉപയോക്താവുമായി പൊരുത്തപ്പെടണം, അല്ലെങ്കിൽ യഥാർത്ഥത്തിൽ ഉള്ള ഒരു കോൺഫിഗറേഷൻ ഫയൽ കാണുന്നില്ലെന്ന് ഉപകരണം റിപ്പോർട്ട് ചെയ്യും.

ആശ്രിതത്വ ഉപകരണം image-ൽ എന്ത് അവശേഷിപ്പിക്കുന്നു എന്ന് പരിശോധിക്കുക

താൽക്കാലിക മൗണ്ട് ക്രെഡൻഷ്യലിനെ ലെയറിന് പുറത്ത് നിർത്തുന്നു, പക്ഷേ ഉപകരണം മറ്റെന്തെങ്കിലും എഴുതുന്നത് തടയുന്നില്ല. പാക്കേജ് മാനേജർമാർ lock ഫയലുകൾ, cache ഡയറക്ടറികൾ, ചിലപ്പോൾ resolve ചെയ്ത രജിസ്ട്രി URL എന്നിവ അവശേഷിപ്പിക്കുന്നു.

Dockerfile-നെ വിശ്വസിക്കുന്നതിന് പകരം തയ്യാറായ ഫയൽസിസ്റ്റം വായിക്കുക. docker history --no-trunc image:tag ഓരോ ലെയർ കമാൻഡും പട്ടികപ്പെടുത്തുന്നു, കൂടാതെ docker run --rm image:tag sh -c "ls -a /root" പ്രവർത്തിക്കുന്ന കണ്ടെയ്നറിൽ എന്ത് അവശേഷിച്ചു എന്ന് കാണിക്കുന്നു. ഫയൽ മൗണ്ട് മാത്രം ചെയ്തതായിരുന്നാലും, ലോഗ് വരിയിൽ എഴുതിയ ടോക്കൺ npm ci സമയത്തും ചോർച്ച തന്നെയാണ്.

build ലോഗും വായിക്കുക, കാരണം --progress=plain കമാൻഡുകളുടെ ഔട്ട്പുട്ട് അക്ഷരാർത്ഥത്തിൽ പ്രിന്റ് ചെയ്യുന്നു. ടോക്കൺ അവിടെ കണ്ടാൽ, മറ്റെന്തിനും മുൻപ് അത് റൊട്ടേറ്റ് ചെയ്ത്, ഉപകരണം നിശ്ശബ്ദമായി വായിക്കുന്ന ഫയലിലൂടെ കടത്തിവിടുക.

റൺടൈം image-ന് ഇനി സ്വകാര്യ പാത ആവശ്യമില്ലെന്ന് ഉറപ്പാക്കുക

build-ഉം പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനും ഒരേ ആശ്രിതത്വത്തിന്റെ രണ്ട് വ്യത്യസ്ത ഉപഭോക്താക്കളാണ്, സ്വകാര്യ പാത ആദ്യത്തേതിന് മാത്രം വേണം. തയ്യാറായ image build സമയത്തെ ക്രെഡൻഷ്യലില്ലാതെ ആരംഭിക്കണം, അതിന്റെ റൺടൈം ആശ്രിതത്വങ്ങൾ resolve ചെയ്യണം, ട്രാഫിക് നൽകണം.

സ്വകാര്യ രജിസ്ട്രി എത്താനാകാത്ത ഇടത്ത് ഇത് പരീക്ഷിക്കുക, അല്ലെങ്കിൽ കണ്ടെയ്നർ വെറുതെ --network none ഉപയോഗിച്ച് ആരംഭിച്ച് മൗണ്ട് ചെയ്ത secret ഇല്ലാതെ അത് ബൂട്ട് ആകുന്നുവെന്ന് ഉറപ്പാക്കുക. build secret ഉള്ളപ്പോൾ മാത്രം ആരംഭിക്കുന്ന കണ്ടെയ്നർ ഇപ്പോഴും build പരിസ്ഥിതിയോട് ബന്ധിതമാണ്.

കണ്ടെയ്നറിന് റൺടൈമിൽ രജിസ്ട്രി ശരിക്കും വേണമെങ്കിൽ, അത് വേറെ ഒരു ആക്സസ് തീരുമാനമാണ്, അതിന്റെ സ്ഥാനം ഓർക്കസ്ട്രേറ്ററിന്റെ secret സ്റ്റോറിലാണ്, build-ൽ അല്ല. രണ്ട് പാതകളും വെവ്വേറെ രേഖപ്പെടുത്തുക, ആരും build ഫ്ലാഗ് ഉപയോഗിച്ച് റൺടൈം പുൾ ശരിയാക്കാൻ ശ്രമിക്കാതിരിക്കാൻ. അഞ്ച് പരിശോധനകളും കടന്നുപോയാൽ, യഥാർത്ഥ ലക്ഷണത്തിന് ഓരോ പാളിയിലും പേരിട്ട കാരണമുണ്ടാകും, Docker നെറ്റ്വർക്കിംഗിനെക്കുറിച്ചുള്ള ഊഹമല്ല.