Docker build ਨਿੱਜੀ ਨਿਰਭਰਤਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ: ਇਹ ਜਾਂਚੋ

ਤੁਹਾਡੀ ਮਸ਼ੀਨ ’ਤੇ ਬਿਨਾਂ ਰੁਕਾਵਟ ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਿੱਜੀ ਪੈਕੇਜ build ਦੇ ਅੰਦਰ 404 ਜਾਂ ਟਾਈਮਆਊਟ ਨਾਲ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ Dockerfile ਇਸ ਦਾ ਕਾਰਨ ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ। build ਦਾ ਕਦਮ ਦੂਜੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਵੱਖਰੇ DNS ਦ੍ਰਿਸ਼ ਅਤੇ ਵੱਖਰੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਸਟੋਰ ਨਾਲ, ਜਿਸ shell ਵਿੱਚ ਤੁਸੀਂ ਟੈਸਟ ਕੀਤਾ ਸੀ ਉਸ ਤੋਂ ਵੱਖਰਾ। ਇਹ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਫੇਲ੍ਹ ਹੋਣ ’ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਹਰ ਅਗਲੀ ਜਾਂਚ ਮੰਨਦੀ ਹੈ ਕਿ ਪਿਛਲੀ ਪਾਸ ਹੋਈ ਹੈ। ਹਰ ਕਦਮ ਉਸ ਕਮਾਂਡ ਦਾ ਨਾਂ ਦੱਸਦਾ ਹੈ ਜੋ ਮਾਮਲਾ ਤੈਅ ਕਰਦੀ ਹੈ।

Dockerfile ਨਹੀਂ, builder ਦੇ ਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

BuildKit ਸਥਾਨਕ, ਕੰਟੇਨਰ ਵਿੱਚ ਜਾਂ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ’ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਹੁੰਦਾ ਹੈ। ਚਲਾਓ docker buildx ls ਅਤੇ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤਾਰੇ ਵਾਲਾ ਨੋਡ ਪੜ੍ਹੋ। ਇੱਕ docker-container ਡਰਾਈਵਰ ਜਾਂ ਕਲਾਊਡ builder ਸਿਰਫ਼ ਇਸ ਲਈ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਦਾ ਨਿੱਜੀ ਰਸਤਾ ਸਾਂਝਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਤੁਸੀਂ ਉੱਥੇ ਕਮਾਂਡ ਟਾਈਪ ਕੀਤੀ ਸੀ। ਜੇ ਸਰਗਰਮ builder ਦੂਰ ਹੈ, ਤਾਂ ਬਾਕੀ ਹਰ ਜਾਂਚ ਤੁਹਾਡੇ ਵਰਕਸਟੇਸ਼ਨ ’ਤੇ ਨਹੀਂ, ਉਸ ਹੋਸਟ ’ਤੇ ਚੱਲਣੀ ਚਾਹੀਦੀ ਹੈ।

builder ਆਪਣਾ resolver ਸੰਰਚਨਾ ਅਤੇ proxy ਵੇਰੀਏਬਲਵੀ ਰੱਖਦਾ ਹੈ। ਦੋਵੇਂ build ਵੇਲੇ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ ਅਤੇ build ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੇ ਟਰਮੀਨਲ ਤੋਂ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੇ।

build ਕਦਮ ਦੇ ਅੰਦਰੋਂ ਨੈੱਟਵਰਕ ਰਸਤਾ ਸਾਬਤ ਕਰੋ

ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲਾ ਪੜਾਅ ਲਿਖੋ ਜੋ ਨਿਰਭਰਤਾ ਦੇ ਹੋਸਟ ਨੂੰ ਹੱਲ ਕਰੇ ਅਤੇ ਉਸ ਨਾਲ ਜੁੜਾਅ ਖੋਲ੍ਹੇ। 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 ਕੁਝ ਨਹੀਂ ਛਾਪਦਾ, ਤਾਂ ਖ਼ਰਾਬੀ ਨਾਂ-ਹੱਲ ਵਿੱਚ ਹੈ ਅਤੇ ਕੋਈ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਜੇ ਨਾਂ ਹੱਲ ਹੁੰਦਾ ਹੈ ਪਰ curl ਟਾਈਮਆਊਟ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਰੁਕਾਵਟ ਰਸਤਾ ਜਾਂ ਰਜਿਸਟਰੀ ਸਾਹਮਣੇ ਦੀ ਈਗ੍ਰੈਸ ਨੀਤੀ ਹੈ।

ਜਵਾਬ ਮਿਲਦਿਆਂ ਹੀ ਪ੍ਰੋਬ ਹਟਾ ਦਿਓ। ਇਹ ਨਿਦਾਨ ਪੜਾਅ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਕਦੇ ਟੈਗ ਜਾਂ ਪੁਸ਼ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।

ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਮਾਊਂਟ ਕਰੋ

ਰਸਤਾ ਚੱਲਣ ਤੋਂ ਬਾਅਦ, ਅਗਲੀ ਫੇਲ੍ਹ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ। 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 ਡਾਇਰੈਕਟਰੀਆਂ ਅਤੇ ਕਈ ਵਾਰ ਹੱਲ ਕੀਤਾ ਰਜਿਸਟਰੀ 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 ਸਮੇਂ ਦੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਤੋਂ ਬਿਨਾਂ ਸ਼ੁਰੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਆਪਣੀਆਂ ਰਨਟਾਈਮ ਨਿਰਭਰਤਾਵਾਂ ਹੱਲ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਸੇਵਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਇਸ ਨੂੰ ਉੱਥੇ ਪਰਖੋ ਜਿੱਥੇ ਨਿੱਜੀ ਰਜਿਸਟਰੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ, ਜਾਂ ਕੰਟੇਨਰ ਨੂੰ ਸਿਰਫ਼ --network none ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਮਾਊਂਟ ਕੀਤੇ secret ਤੋਂ ਬਿਨਾਂ ਬੂਟ ਹੁੰਦਾ ਹੈ। ਜੋ ਕੰਟੇਨਰ ਸਿਰਫ਼ build secret ਹੋਣ ’ਤੇ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਉਹ ਅਜੇ ਵੀ build ਵਾਤਾਵਰਨ ਨਾਲ ਬੱਝਿਆ ਹੈ।

ਜੇ ਕੰਟੇਨਰ ਨੂੰ ਰਨਟਾਈਮ ’ਤੇ ਰਜਿਸਟਰੀ ਸੱਚਮੁੱਚ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਹ ਵੱਖਰਾ ਪਹੁੰਚ ਫ਼ੈਸਲਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਥਾਂ ਆਰਕੈਸਟ੍ਰੇਟਰ ਦੇ secret ਸਟੋਰ ਵਿੱਚ ਹੈ, build ਵਿੱਚ ਨਹੀਂ। ਦੋਵੇਂ ਰਸਤੇ ਵੱਖਰੇ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਕੋਈ build ਫ਼ਲੈਗ ਨਾਲ ਰਨਟਾਈਮ ਪੁੱਲ ਸੁਧਾਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨ ਕਰੇ। ਜਦੋਂ ਪੰਜੇ ਜਾਂਚਾਂ ਪਾਸ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਮੂਲ ਲੱਛਣ ਦਾ ਹਰ ਪਰਤ ’ਤੇ ਨਾਂ ਦਿੱਤਾ ਕਾਰਨ ਹੁੰਦਾ ਹੈ, Docker ਨੈੱਟਵਰਕਿੰਗ ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਨਹੀਂ।