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 ಮುದ್ರಿಸದಿದ್ದರೆ, ದೋಷ ಹೆಸರು-resolution‌ನಲ್ಲಿದೆ ಮತ್ತು ಯಾವುದೇ ರುಜುವಾತು ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಹೆಸರು 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 ನೆಟ್‌ವರ್ಕಿಂಗ್ ಬಗ್ಗೆ ಊಹೆಯಲ್ಲ.