ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਬਾਰੇ ਕੁਝ ਸੁਝਾਅ। ਉਦਾਹਰਨ ਲਈ, 30 ਸਕਿੰਟਾਂ ਤੱਕ

ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਉਤਪਾਦਨ ਵਿੱਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਗੁੰਝਲਦਾਰ ਆਰਕੈਸਟਰੇਟਰਾਂ ਅਤੇ CI/CD ਦੇ ਇਹਨਾਂ ਦਿਨਾਂ ਵਿੱਚ, ਟੈਸਟਾਂ ਅਤੇ ਡਿਲੀਵਰੀ ਤੱਕ ਵਚਨਬੱਧਤਾ ਤੋਂ ਲੈ ਕੇ ਇੱਕ ਲੰਮਾ ਸਫ਼ਰ ਤੈਅ ਕਰਨਾ ਹੈ। ਪਹਿਲਾਂ, ਤੁਸੀਂ FTP ਰਾਹੀਂ ਨਵੀਆਂ ਫਾਈਲਾਂ ਅੱਪਲੋਡ ਕਰ ਸਕਦੇ ਹੋ (ਹੁਣ ਅਜਿਹਾ ਕੋਈ ਨਹੀਂ ਕਰਦਾ, ਠੀਕ ਹੈ?), ਅਤੇ "ਡਿਪਲਾਇਮੈਂਟ" ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਕਿੰਟਾਂ ਲੱਗੀਆਂ। ਹੁਣ ਤੁਹਾਨੂੰ ਇੱਕ ਵਿਲੀਨਤਾ ਬੇਨਤੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਲੰਮਾ ਸਮਾਂ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ।

ਇਸ ਮਾਰਗ ਦਾ ਹਿੱਸਾ ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਬਣਾ ਰਿਹਾ ਹੈ। ਕਈ ਵਾਰ ਅਸੈਂਬਲੀ ਮਿੰਟਾਂ ਤੱਕ ਚੱਲਦੀ ਹੈ, ਕਈ ਵਾਰ ਕਈ ਮਿੰਟਾਂ ਦੀ, ਜਿਸ ਨੂੰ ਸ਼ਾਇਦ ਹੀ ਆਮ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਐਪਲੀਕੇਸ਼ਨ ਲਵਾਂਗੇ ਜੋ ਅਸੀਂ ਇੱਕ ਚਿੱਤਰ ਵਿੱਚ ਪੈਕ ਕਰਾਂਗੇ, ਬਿਲਡ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਕਈ ਤਰੀਕਿਆਂ ਨੂੰ ਲਾਗੂ ਕਰਾਂਗੇ, ਅਤੇ ਇਹਨਾਂ ਵਿਧੀਆਂ ਦੇ ਕੰਮ ਕਰਨ ਦੀਆਂ ਬਾਰੀਕੀਆਂ ਨੂੰ ਦੇਖਾਂਗੇ।

ਸਾਡੇ ਕੋਲ ਮੀਡੀਆ ਵੈੱਬਸਾਈਟਾਂ ਬਣਾਉਣ ਅਤੇ ਸਮਰਥਨ ਕਰਨ ਦਾ ਚੰਗਾ ਅਨੁਭਵ ਹੈ: ਟਾਸ, ਬੈੱਲ, "ਨਵਾਂ ਅਖਬਾਰ", ਗਣਤੰਤਰ… ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ ਅਸੀਂ ਉਤਪਾਦ ਦੀ ਵੈੱਬਸਾਈਟ ਜਾਰੀ ਕਰਕੇ ਆਪਣੇ ਪੋਰਟਫੋਲੀਓ ਦਾ ਵਿਸਤਾਰ ਕੀਤਾ ਸੀ ਰੀਮਾਈਂਡਰ. ਅਤੇ ਜਦੋਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੇਜ਼ੀ ਨਾਲ ਜੋੜੀਆਂ ਗਈਆਂ ਸਨ ਅਤੇ ਪੁਰਾਣੇ ਬੱਗ ਫਿਕਸ ਕੀਤੇ ਗਏ ਸਨ, ਹੌਲੀ ਤੈਨਾਤੀ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਬਣ ਗਈ।

ਅਸੀਂ GitLab ਵਿੱਚ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਚਿੱਤਰ ਇਕੱਠੇ ਕਰਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ GitLab ਰਜਿਸਟਰੀ ਵਿੱਚ ਧੱਕਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹਾਂ। ਇਸ ਸੂਚੀ ਵਿੱਚ ਸਭ ਤੋਂ ਲੰਬੀ ਚੀਜ਼ ਚਿੱਤਰਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ: ਬਿਨਾਂ ਅਨੁਕੂਲਤਾ ਦੇ, ਹਰੇਕ ਬੈਕਐਂਡ ਬਿਲਡ ਵਿੱਚ 14 ਮਿੰਟ ਲੱਗੇ।

ਅੰਤ ਵਿੱਚ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਅਸੀਂ ਹੁਣ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦੇ, ਅਤੇ ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਬੈਠ ਗਏ ਕਿ ਚਿੱਤਰਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਵਿੱਚ ਇੰਨਾ ਸਮਾਂ ਕਿਉਂ ਲੱਗ ਰਿਹਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਅਸੈਂਬਲੀ ਦੇ ਸਮੇਂ ਨੂੰ 30 ਸਕਿੰਟਾਂ ਤੱਕ ਘਟਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ!

ਇਸ ਲੇਖ ਲਈ, ਰੀਮਾਈਂਡਰ ਦੇ ਵਾਤਾਵਰਣ ਨਾਲ ਨਾ ਬੰਨ੍ਹੇ ਜਾਣ ਲਈ, ਆਉ ਇੱਕ ਖਾਲੀ ਐਂਗੁਲਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵੇਖੀਏ। ਇਸ ਲਈ, ਆਓ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਈਏ:

ng n app

ਇਸ ਵਿੱਚ PWA ਸ਼ਾਮਲ ਕਰੋ (ਅਸੀਂ ਪ੍ਰਗਤੀਸ਼ੀਲ ਹਾਂ):

ng add @angular/pwa --project app

ਜਦੋਂ ਕਿ ਇੱਕ ਮਿਲੀਅਨ npm ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਡੌਕਰ ਚਿੱਤਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਡੌਕਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਪੈਕੇਜ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਕੰਟੇਨਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਆਈਸੋਲੇਸ਼ਨ ਲਈ ਧੰਨਵਾਦ, ਤੁਸੀਂ ਇੱਕ ਸਰਵਰ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਕਈ ਕੰਟੇਨਰ ਚਲਾ ਸਕਦੇ ਹੋ। ਕੰਟੇਨਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨਾਲੋਂ ਬਹੁਤ ਹਲਕੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਿਸਟਮ ਕਰਨਲ 'ਤੇ ਸਿੱਧੇ ਚੱਲਦੇ ਹਨ। ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਇੱਕ ਕੰਟੇਨਰ ਨੂੰ ਚਲਾਉਣ ਲਈ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਚਿੱਤਰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਹਰ ਉਹ ਚੀਜ਼ ਪੈਕੇਜ ਕਰਾਂਗੇ ਜੋ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਚਲਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇੱਕ ਚਿੱਤਰ ਫਾਇਲ ਸਿਸਟਮ ਦੀ ਇੱਕ ਕਾਪੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਡੌਕਰਫਾਈਲ ਲਓ:

FROM node:12.16.2
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

ਇੱਕ ਡੌਕਰਫਾਈਲ ਹਦਾਇਤਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ; ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੂੰ ਕਰਨ ਨਾਲ, ਡੌਕਰ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੇਗਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪਿਛਲੀਆਂ ਉੱਤੇ ਓਵਰਲੇ ਕਰੇਗਾ। ਹਰ ਟੀਮ ਆਪਣੀ ਪਰਤ ਬਣਾਉਂਦੀ ਹੈ। ਅਤੇ ਮੁਕੰਮਲ ਚਿੱਤਰ ਲੇਅਰਾਂ ਨੂੰ ਜੋੜਿਆ ਗਿਆ ਹੈ।

ਕੀ ਜਾਣਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਹਰੇਕ ਡੌਕਰ ਲੇਅਰ ਕੈਸ਼ ਕਰ ਸਕਦੀ ਹੈ. ਜੇਕਰ ਆਖਰੀ ਬਿਲਡ ਤੋਂ ਬਾਅਦ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ ਹੈ, ਤਾਂ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਣ ਦੀ ਬਜਾਏ, ਡੌਕਰ ਇੱਕ ਤਿਆਰ-ਬਣਾਈ ਪਰਤ ਲਵੇਗਾ। ਕਿਉਂਕਿ ਬਿਲਡ ਸਪੀਡ ਵਿੱਚ ਮੁੱਖ ਵਾਧਾ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਦੇ ਕਾਰਨ ਹੋਵੇਗਾ, ਜਦੋਂ ਬਿਲਡ ਸਪੀਡ ਨੂੰ ਮਾਪਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ ਰੈਡੀਮੇਡ ਕੈਚ ਨਾਲ ਇੱਕ ਚਿੱਤਰ ਬਣਾਉਣ ਵੱਲ ਧਿਆਨ ਦੇਵਾਂਗੇ। ਇਸ ਲਈ, ਕਦਮ ਦਰ ਕਦਮ:

1. ਅਸੀਂ ਚਿੱਤਰਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਮਿਟਾ ਦਿੰਦੇ ਹਾਂ ਤਾਂ ਕਿ ਪਿਛਲੀਆਂ ਦੌੜਾਂ ਟੈਸਟ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰਨ।
   docker rmi $(docker images -q)
2. ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ ਬਿਲਡ ਲਾਂਚ ਕਰਦੇ ਹਾਂ।
   time docker build -t app .
3. ਅਸੀਂ src/index.html ਫਾਈਲ ਨੂੰ ਬਦਲਦੇ ਹਾਂ - ਅਸੀਂ ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਦੇ ਕੰਮ ਦੀ ਨਕਲ ਕਰਦੇ ਹਾਂ.
4. ਅਸੀਂ ਬਿਲਡ ਨੂੰ ਦੂਜੀ ਵਾਰ ਚਲਾਉਂਦੇ ਹਾਂ।
   time docker build -t app .

ਜੇ ਚਿੱਤਰ ਬਣਾਉਣ ਲਈ ਵਾਤਾਵਰਣ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ (ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ), ਤਾਂ ਜਦੋਂ ਬਿਲਡ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਡੌਕਰ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਬੋਰਡ 'ਤੇ ਕੈਚਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੋਵੇਗਾ। ਸਾਡਾ ਕੰਮ ਇਹ ਸਿੱਖਣਾ ਹੈ ਕਿ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਤਾਂ ਜੋ ਬਿਲਡ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ. ਕਿਉਂਕਿ ਅਸੀਂ ਇਹ ਮੰਨ ਰਹੇ ਹਾਂ ਕਿ ਇੱਕ ਕੈਸ਼ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਬਿਲਡ ਚਲਾਉਣਾ ਸਿਰਫ ਇੱਕ ਵਾਰ ਹੁੰਦਾ ਹੈ - ਪਹਿਲੀ ਵਾਰ - ਅਸੀਂ ਇਸ ਲਈ ਅਣਡਿੱਠ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਪਹਿਲੀ ਵਾਰ ਕਿੰਨੀ ਹੌਲੀ ਸੀ। ਟੈਸਟਾਂ ਵਿੱਚ, ਬਿਲਡ ਦਾ ਦੂਜਾ ਰਨ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕੈਚ ਪਹਿਲਾਂ ਹੀ ਗਰਮ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅਸੀਂ ਆਪਣੇ ਕੇਕ ਨੂੰ ਸੇਕਣ ਲਈ ਤਿਆਰ ਹੁੰਦੇ ਹਾਂ। ਹਾਲਾਂਕਿ, ਕੁਝ ਸੁਝਾਅ ਪਹਿਲੇ ਬਿਲਡ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਨਗੇ।

ਆਉ ਉੱਪਰ ਦੱਸੇ ਗਏ ਡੌਕਰਫਾਈਲ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਫੋਲਡਰ ਵਿੱਚ ਪਾਓ ਅਤੇ ਬਿਲਡ ਸ਼ੁਰੂ ਕਰੀਏ। ਸਾਰੀਆਂ ਸੂਚੀਆਂ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਸੌਖ ਲਈ ਸੰਘਣਾ ਕੀਤਾ ਗਿਆ ਹੈ।

$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Status: Downloaded newer image for node:12.16.2
Step 2/5 : WORKDIR /app
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Time: 37581ms
Successfully built c8c279335f46
Successfully tagged app:latest

real 5m4.541s
user 0m0.000s
sys 0m0.000s

ਅਸੀਂ src/index.html ਦੀ ਸਮੱਗਰੀ ਬਦਲਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਦੂਜੀ ਵਾਰ ਚਲਾਉਂਦੇ ਹਾਂ।

$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
 ---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Time: 37902ms
Successfully built 79f335df92d3
Successfully tagged app:latest

real 3m33.262s
user 0m0.000s
sys 0m0.000s

ਇਹ ਵੇਖਣ ਲਈ ਕਿ ਕੀ ਸਾਡੇ ਕੋਲ ਚਿੱਤਰ ਹੈ, ਕਮਾਂਡ ਚਲਾਓ docker images:

REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
app          latest   79f335df92d3   About a minute ago   1.74GB

ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਡੌਕਰ ਮੌਜੂਦਾ ਸੰਦਰਭ ਵਿੱਚ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਡੈਮਨ ਨੂੰ ਭੇਜਦਾ ਹੈ Sending build context to Docker daemon 409MB. ਬਿਲਡ ਸੰਦਰਭ ਨੂੰ ਬਿਲਡ ਕਮਾਂਡ ਲਈ ਆਖਰੀ ਆਰਗੂਮੈਂਟ ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ ਮੌਜੂਦਾ ਡਾਇਰੈਕਟਰੀ ਹੈ - ".", - ਅਤੇ ਡੌਕਰ ਹਰ ਚੀਜ਼ ਨੂੰ ਖਿੱਚਦਾ ਹੈ ਜੋ ਸਾਡੇ ਕੋਲ ਇਸ ਫੋਲਡਰ ਵਿੱਚ ਹੈ. 409 MB ਬਹੁਤ ਹੈ: ਆਓ ਇਸ ਬਾਰੇ ਸੋਚੀਏ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ.

ਸੰਦਰਭ ਨੂੰ ਘਟਾਉਣਾ

ਸੰਦਰਭ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਦੋ ਵਿਕਲਪ ਹਨ. ਜਾਂ ਅਸੈਂਬਲੀ ਲਈ ਲੋੜੀਂਦੀਆਂ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਫੋਲਡਰ ਵਿੱਚ ਪਾਓ ਅਤੇ ਡੌਕਰ ਸੰਦਰਭ ਨੂੰ ਇਸ ਫੋਲਡਰ ਵੱਲ ਪੁਆਇੰਟ ਕਰੋ। ਇਹ ਹਮੇਸ਼ਾ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਅਪਵਾਦਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸੰਭਵ ਹੈ: ਸੰਦਰਭ ਵਿੱਚ ਕੀ ਨਹੀਂ ਖਿੱਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ .dockerignore ਫਾਈਲ ਪਾਓ ਅਤੇ ਦੱਸੋ ਕਿ ਬਿਲਡ ਲਈ ਕੀ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ:

.git
/node_modules

ਅਤੇ ਬਿਲਡ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ:

$ time docker build -t app .
Sending build context to Docker daemon 607.2kB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
 ---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Time: 37313ms
Successfully built 4942f010792a
Successfully tagged app:latest

real 1m47.763s
user 0m0.000s
sys 0m0.000s

607.2 KB 409 MB ਨਾਲੋਂ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਅਸੀਂ ਚਿੱਤਰ ਦਾ ਆਕਾਰ ਵੀ 1.74 ਤੋਂ 1.38 GB ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਹੈ:

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
app          latest   4942f010792a   3 minutes ago   1.38GB

ਆਓ ਚਿੱਤਰ ਦੇ ਆਕਾਰ ਨੂੰ ਹੋਰ ਘਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ.

ਅਸੀਂ ਅਲਪਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

ਚਿੱਤਰ ਦੇ ਆਕਾਰ ਨੂੰ ਬਚਾਉਣ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ ਇੱਕ ਛੋਟੇ ਪੇਰੈਂਟ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਮਾਤਾ-ਪਿਤਾ ਦਾ ਚਿੱਤਰ ਉਹ ਚਿੱਤਰ ਹੁੰਦਾ ਹੈ ਜਿਸ ਦੇ ਆਧਾਰ 'ਤੇ ਸਾਡਾ ਚਿੱਤਰ ਤਿਆਰ ਹੁੰਦਾ ਹੈ। ਹੇਠਲੀ ਪਰਤ ਕਮਾਂਡ ਦੁਆਰਾ ਦਰਸਾਈ ਗਈ ਹੈ FROM ਡੌਕਰਫਾਈਲ ਵਿੱਚ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਉਬੰਟੂ-ਅਧਾਰਿਤ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਨੋਡਜ ਸਥਾਪਤ ਹਨ। ਅਤੇ ਇਸਦਾ ਭਾਰ ਹੈ ...

$ docker images -a | grep node
node 12.16.2 406aa3abbc6c 17 minutes ago 916MB

... ਲਗਭਗ ਇੱਕ ਗੀਗਾਬਾਈਟ। ਤੁਸੀਂ ਐਲਪਾਈਨ ਲੀਨਕਸ 'ਤੇ ਅਧਾਰਤ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਾਲੀਅਮ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾ ਸਕਦੇ ਹੋ। ਐਲਪਾਈਨ ਇੱਕ ਬਹੁਤ ਛੋਟਾ ਲੀਨਕਸ ਹੈ। ਅਲਪਾਈਨ 'ਤੇ ਅਧਾਰਤ ਨੋਡਜ ਲਈ ਡੌਕਰ ਚਿੱਤਰ ਦਾ ਭਾਰ ਸਿਰਫ 88.5 MB ਹੈ। ਤਾਂ ਆਓ ਘਰਾਂ ਵਿੱਚ ਆਪਣੇ ਜੀਵੰਤ ਚਿੱਤਰ ਨੂੰ ਬਦਲੀਏ:

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

ਸਾਨੂੰ ਕੁਝ ਚੀਜ਼ਾਂ ਸਥਾਪਤ ਕਰਨੀਆਂ ਪਈਆਂ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹਨ। ਹਾਂ, ਐਂਗੁਲਰ ਪਾਈਥਨ ¯(°_o)/¯ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਬਣਦਾ

ਪਰ ਚਿੱਤਰ ਦਾ ਆਕਾਰ ਘਟ ਕੇ 150 MB ਹੋ ਗਿਆ:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   aa031edc315a   22 minutes ago   761MB

ਚਲੋ ਹੋਰ ਵੀ ਅੱਗੇ ਚੱਲੀਏ।

ਮਲਟੀਸਟੇਜ ਅਸੈਂਬਲੀ

ਹਰ ਚੀਜ਼ ਜੋ ਚਿੱਤਰ ਵਿੱਚ ਹੈ ਉਹ ਨਹੀਂ ਹੈ ਜਿਸਦੀ ਸਾਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਲੋੜ ਹੈ।

$ docker run app ls -lah
total 576K
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 .
drwxr-xr-x 1 root root 4.0K Apr 16 20:00 ..
-rwxr-xr-x 1 root root 19 Apr 17 2020 .dockerignore
-rwxr-xr-x 1 root root 246 Apr 17 2020 .editorconfig
-rwxr-xr-x 1 root root 631 Apr 17 2020 .gitignore
-rwxr-xr-x 1 root root 181 Apr 17 2020 Dockerfile
-rwxr-xr-x 1 root root 1020 Apr 17 2020 README.md
-rwxr-xr-x 1 root root 3.6K Apr 17 2020 angular.json
-rwxr-xr-x 1 root root 429 Apr 17 2020 browserslist
drwxr-xr-x 3 root root 4.0K Apr 16 19:54 dist
drwxr-xr-x 3 root root 4.0K Apr 17 2020 e2e
-rwxr-xr-x 1 root root 1015 Apr 17 2020 karma.conf.js
-rwxr-xr-x 1 root root 620 Apr 17 2020 ngsw-config.json
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 node_modules
-rwxr-xr-x 1 root root 494.9K Apr 17 2020 package-lock.json
-rwxr-xr-x 1 root root 1.3K Apr 17 2020 package.json
drwxr-xr-x 5 root root 4.0K Apr 17 2020 src
-rwxr-xr-x 1 root root 210 Apr 17 2020 tsconfig.app.json
-rwxr-xr-x 1 root root 489 Apr 17 2020 tsconfig.json
-rwxr-xr-x 1 root root 270 Apr 17 2020 tsconfig.spec.json
-rwxr-xr-x 1 root root 1.9K Apr 17 2020 tslint.json

ਦੀ ਸਹਾਇਤਾ ਨਾਲ docker run app ls -lah ਅਸੀਂ ਆਪਣੇ ਚਿੱਤਰ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਕੰਟੇਨਰ ਲਾਂਚ ਕੀਤਾ ਹੈ app ਅਤੇ ਇਸ ਵਿੱਚ ਕਮਾਂਡ ਨੂੰ ਚਲਾਇਆ ls -lahਜਿਸ ਤੋਂ ਬਾਅਦ ਕੰਟੇਨਰ ਨੇ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਕਰ ਲਿਆ।

ਉਤਪਾਦਨ ਵਿੱਚ ਸਾਨੂੰ ਸਿਰਫ ਇੱਕ ਫੋਲਡਰ ਦੀ ਲੋੜ ਹੈ dist. ਇਸ ਕੇਸ ਵਿੱਚ, ਫਾਈਲਾਂ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਬਾਹਰ ਦੇਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਤੁਸੀਂ ਨੋਡਜ 'ਤੇ ਕੁਝ HTTP ਸਰਵਰ ਚਲਾ ਸਕਦੇ ਹੋ। ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਵਾਂਗੇ। ਇੱਕ ਰੂਸੀ ਸ਼ਬਦ ਦਾ ਅਨੁਮਾਨ ਲਗਾਓ ਜਿਸ ਵਿੱਚ ਚਾਰ ਅੱਖਰ “y” ਹਨ। ਸਹੀ! Ynzhynyksy. ਆਉ nginx ਨਾਲ ਇੱਕ ਚਿੱਤਰ ਲੈਂਦੇ ਹਾਂ, ਇਸ ਵਿੱਚ ਇੱਕ ਫੋਲਡਰ ਪਾਓ dist ਅਤੇ ਇੱਕ ਛੋਟੀ ਸੰਰਚਨਾ:

server {
    listen 80 default_server;
    server_name localhost;
    charset utf-8;
    root /app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡ ਇਹ ਸਭ ਕਰਨ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰੇਗਾ। ਆਓ ਆਪਣੀ ਡੌਕਰਫਾਈਲ ਨੂੰ ਬਦਲੀਏ:

FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .

ਹੁਣ ਸਾਡੇ ਕੋਲ ਦੋ ਹਦਾਇਤਾਂ ਹਨ FROM ਡੌਕਰਫਾਈਲ ਵਿੱਚ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰਾ ਬਿਲਡ ਸਟੈਪ ਚਲਾਉਂਦਾ ਹੈ। ਅਸੀਂ ਪਹਿਲੇ ਨੂੰ ਬੁਲਾਇਆ builder, ਪਰ ਆਖਰੀ FROM ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਸਾਡਾ ਅੰਤਿਮ ਚਿੱਤਰ ਤਿਆਰ ਕੀਤਾ ਜਾਵੇਗਾ। ਆਖਰੀ ਕਦਮ ਹੈ nginx ਦੇ ਨਾਲ ਅੰਤਿਮ ਚਿੱਤਰ ਵਿੱਚ ਪਿਛਲੇ ਪੜਾਅ ਵਿੱਚ ਸਾਡੀ ਅਸੈਂਬਲੀ ਦੇ ਆਰਟੀਫੈਕਟ ਦੀ ਨਕਲ ਕਰਨਾ। ਚਿੱਤਰ ਦਾ ਆਕਾਰ ਬਹੁਤ ਘੱਟ ਗਿਆ ਹੈ:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   2c6c5da07802   29 minutes ago   36MB

ਆਓ ਆਪਣੇ ਚਿੱਤਰ ਦੇ ਨਾਲ ਕੰਟੇਨਰ ਨੂੰ ਚਲਾਓ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ:

docker run -p8080:80 app

-p8080:80 ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਆਪਣੀ ਮੇਜ਼ਬਾਨ ਮਸ਼ੀਨ 'ਤੇ ਪੋਰਟ 8080 ਨੂੰ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਪੋਰਟ 80 'ਤੇ ਫਾਰਵਰਡ ਕੀਤਾ ਜਿੱਥੇ nginx ਚੱਲਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਖੋਲ੍ਹੋ http://localhost:8080/ ਅਤੇ ਅਸੀਂ ਆਪਣੀ ਅਰਜ਼ੀ ਦੇਖਦੇ ਹਾਂ। ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ!

ਚਿੱਤਰ ਦੇ ਆਕਾਰ ਨੂੰ 1.74 GB ਤੋਂ 36 MB ਤੱਕ ਘਟਾਉਣਾ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਪਹੁੰਚਾਉਣ ਵਿੱਚ ਲੱਗਣ ਵਾਲੇ ਸਮੇਂ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾਉਂਦਾ ਹੈ। ਪਰ ਆਓ ਅਸੈਂਬਲੀ ਦੇ ਸਮੇਂ ਤੇ ਵਾਪਸ ਚਲੀਏ.

$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/11 : FROM node:12.16.2-alpine3.11 as builder
Step 2/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Using cache
Step 3/11 : WORKDIR /app
 ---> Using cache
Step 4/11 : COPY . .
Step 5/11 : RUN npm ci
added 1357 packages in 47.338s
Step 6/11 : RUN npm run build --prod
Date: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Time: 39948ms
 ---> 27f1479221e4
Step 7/11 : FROM nginx:stable-alpine
Step 8/11 : WORKDIR /app
 ---> Using cache
Step 9/11 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Using cache
Step 10/11 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Using cache
Step 11/11 : COPY --from=builder /app/dist/app .
Successfully built d201471c91ad
Successfully tagged app:latest

real 2m17.700s
user 0m0.000s
sys 0m0.000s

ਲੇਅਰਾਂ ਦਾ ਕ੍ਰਮ ਬਦਲਣਾ

ਸਾਡੇ ਪਹਿਲੇ ਤਿੰਨ ਕਦਮ ਕੈਸ਼ ਕੀਤੇ ਗਏ ਸਨ (ਸੰਕੇਤ Using cache). ਚੌਥੇ ਪੜਾਅ 'ਤੇ, ਸਾਰੀਆਂ ਪ੍ਰੋਜੈਕਟ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਪੰਜਵੇਂ ਪੜਾਅ 'ਤੇ ਨਿਰਭਰਤਾ ਸਥਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ RUN npm ci - ਜਿੰਨਾ 47.338 ਸਕਿੰਟ। ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਹਰ ਵਾਰ ਮੁੜ-ਸਥਾਪਿਤ ਕਿਉਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੇਕਰ ਉਹ ਬਹੁਤ ਘੱਟ ਬਦਲਦੇ ਹਨ? ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕੈਸ਼ ਕਿਉਂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਡੌਕਰ ਇਹ ਵੇਖਣ ਲਈ ਲੇਅਰ ਦਰ ਪਰਤ ਦੀ ਜਾਂਚ ਕਰੇਗਾ ਕਿ ਕੀ ਕਮਾਂਡ ਅਤੇ ਇਸ ਨਾਲ ਜੁੜੀਆਂ ਫਾਈਲਾਂ ਬਦਲ ਗਈਆਂ ਹਨ. ਚੌਥੇ ਪੜਾਅ 'ਤੇ, ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ, ਬੇਸ਼ੱਕ, ਤਬਦੀਲੀਆਂ ਹਨ, ਇਸਲਈ ਡੌਕਰ ਨਾ ਸਿਰਫ ਇਸ ਪਰਤ ਨੂੰ ਕੈਸ਼ ਤੋਂ ਲੈਂਦਾ ਹੈ, ਬਲਕਿ ਸਾਰੀਆਂ ਅਗਲੀਆਂ ਵੀ! ਆਓ ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਕੁਝ ਛੋਟੇ ਬਦਲਾਅ ਕਰੀਏ।

FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build --prod

FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .

ਪਹਿਲਾਂ, package.json ਅਤੇ package-lock.json ਦੀ ਨਕਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਨਿਰਭਰਤਾ ਸਥਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਨਕਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਫਲਸਰੂਪ:

$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/12 : FROM node:12.16.2-alpine3.11 as builder
Step 2/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Using cache
Step 3/12 : WORKDIR /app
 ---> Using cache
Step 4/12 : COPY package*.json ./
 ---> Using cache
Step 5/12 : RUN npm ci
 ---> Using cache
Step 6/12 : COPY . .
Step 7/12 : RUN npm run build --prod
Date: 2020-04-16T21:29:44.770Z - Hash: fffa0fddaa3425c55dd3 - Time: 38287ms
 ---> 1b9448c73558
Step 8/12 : FROM nginx:stable-alpine
Step 9/12 : WORKDIR /app
 ---> Using cache
Step 10/12 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Using cache
Step 11/12 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Using cache
Step 12/12 : COPY --from=builder /app/dist/app .
Successfully built a44dd7c217c3
Successfully tagged app:latest

real 0m46.497s
user 0m0.000s
sys 0m0.000s

46 ਮਿੰਟ ਦੀ ਬਜਾਏ 3 ਸਕਿੰਟ - ਬਹੁਤ ਵਧੀਆ! ਲੇਅਰਾਂ ਦਾ ਸਹੀ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਪਹਿਲਾਂ ਅਸੀਂ ਨਕਲ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਨਹੀਂ ਬਦਲਦਾ, ਫਿਰ ਕੀ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਅਕਸਰ ਕੀ ਬਦਲਦਾ ਹੈ।

ਅੱਗੇ, CI/CD ਸਿਸਟਮਾਂ ਵਿੱਚ ਚਿੱਤਰਾਂ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ।

ਕੈਸ਼ ਲਈ ਪਿਛਲੀਆਂ ਤਸਵੀਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਜੇ ਅਸੀਂ ਬਿਲਡ ਲਈ ਕਿਸੇ ਕਿਸਮ ਦੇ SaaS ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਥਾਨਕ ਡੌਕਰ ਕੈਸ਼ ਸਾਫ਼ ਅਤੇ ਤਾਜ਼ਾ ਹੋ ਸਕਦਾ ਹੈ. ਡੌਕਰ ਨੂੰ ਬੇਕਡ ਲੇਅਰਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਜਗ੍ਹਾ ਦੇਣ ਲਈ, ਉਸਨੂੰ ਪਿਛਲੀ ਬਣਾਈ ਗਈ ਚਿੱਤਰ ਦਿਓ।

ਆਉ GitHub ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਲਈਏ। ਅਸੀਂ ਇਸ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

on:
  push:
    branches:
      - master

name: Test docker build

jobs:
  deploy:
    name: Build
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
      IMAGE_TAG: ${{ github.sha }}

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Login to GitHub Packages
      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN

    - name: Build
      run: |
        docker build 
          -t $IMAGE_NAME:$IMAGE_TAG 
          -t $IMAGE_NAME:latest 
          .

    - name: Push image to GitHub Packages
      run: |
        docker push $IMAGE_NAME:latest
        docker push $IMAGE_NAME:$IMAGE_TAG

    - name: Logout
      run: |
        docker logout docker.pkg.github.com

ਚਿੱਤਰ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੋ ਮਿੰਟ ਅਤੇ 20 ਸਕਿੰਟਾਂ ਵਿੱਚ GitHub ਪੈਕੇਜਾਂ ਵਿੱਚ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ:

ਆਓ ਹੁਣ ਬਿਲਡ ਨੂੰ ਬਦਲੀਏ ਤਾਂ ਕਿ ਪਿਛਲੀਆਂ ਬਣਾਈਆਂ ਗਈਆਂ ਤਸਵੀਰਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕੇ:

on:
  push:
    branches:
      - master

name: Test docker build

jobs:
  deploy:
    name: Build
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
      IMAGE_TAG: ${{ github.sha }}

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Login to GitHub Packages
      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN

    - name: Pull latest images
      run: |
        docker pull $IMAGE_NAME:latest || true
        docker pull $IMAGE_NAME-builder-stage:latest || true

    - name: Images list
      run: |
        docker images

    - name: Build
      run: |
        docker build 
          --target builder 
          --cache-from $IMAGE_NAME-builder-stage:latest 
          -t $IMAGE_NAME-builder-stage 
          .
        docker build 
          --cache-from $IMAGE_NAME-builder-stage:latest 
          --cache-from $IMAGE_NAME:latest 
          -t $IMAGE_NAME:$IMAGE_TAG 
          -t $IMAGE_NAME:latest 
          .

    - name: Push image to GitHub Packages
      run: |
        docker push $IMAGE_NAME-builder-stage:latest
        docker push $IMAGE_NAME:latest
        docker push $IMAGE_NAME:$IMAGE_TAG

    - name: Logout
      run: |
        docker logout docker.pkg.github.com

ਪਹਿਲਾਂ ਸਾਨੂੰ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਦੋ ਕਮਾਂਡਾਂ ਕਿਉਂ ਲਾਂਚ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ build. ਤੱਥ ਇਹ ਹੈ ਕਿ ਇੱਕ ਮਲਟੀਸਟੇਜ ਅਸੈਂਬਲੀ ਵਿੱਚ ਨਤੀਜਾ ਚਿੱਤਰ ਆਖਰੀ ਪੜਾਅ ਤੋਂ ਲੇਅਰਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੋਵੇਗਾ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪਿਛਲੀਆਂ ਲੇਅਰਾਂ ਤੋਂ ਪਰਤਾਂ ਚਿੱਤਰ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ। ਇਸ ਲਈ, ਪਿਛਲੇ ਬਿਲਡ ਤੋਂ ਅੰਤਿਮ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਡੌਕਰ ਨੋਡਜ (ਬਿਲਡਰ ਪੜਾਅ) ਨਾਲ ਚਿੱਤਰ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਲੇਅਰਾਂ ਨੂੰ ਲੱਭਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ। ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਇੱਕ ਵਿਚਕਾਰਲਾ ਚਿੱਤਰ ਬਣਾਇਆ ਗਿਆ ਹੈ $IMAGE_NAME-builder-stage ਅਤੇ GitHub ਪੈਕੇਜਾਂ 'ਤੇ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸ ਨੂੰ ਕੈਸ਼ ਸਰੋਤ ਵਜੋਂ ਬਾਅਦ ਦੇ ਬਿਲਡ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕੇ।

ਕੁੱਲ ਅਸੈਂਬਲੀ ਦਾ ਸਮਾਂ ਘਟਾ ਕੇ ਡੇਢ ਮਿੰਟ ਕਰ ਦਿੱਤਾ ਗਿਆ। ਪਿਛਲੀਆਂ ਤਸਵੀਰਾਂ ਖਿੱਚਣ ਵਿੱਚ ਅੱਧਾ ਮਿੰਟ ਬਿਤਾਇਆ ਜਾਂਦਾ ਹੈ।

ਪ੍ਰੀਇਮੇਜਿੰਗ

ਇੱਕ ਸਾਫ਼ ਡੌਕਰ ਕੈਸ਼ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ ਕੁਝ ਲੇਅਰਾਂ ਨੂੰ ਕਿਸੇ ਹੋਰ ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਲਿਜਾਣਾ, ਇਸਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਬਣਾਉਣਾ, ਇਸਨੂੰ ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਧੱਕਣਾ ਅਤੇ ਇਸਨੂੰ ਮਾਤਾ-ਪਿਤਾ ਵਜੋਂ ਵਰਤਣਾ ਹੈ।

ਅਸੀਂ ਇੱਕ ਐਂਗੁਲਰ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਆਪਣਾ ਨੋਡਜ ਚਿੱਤਰ ਬਣਾਉਂਦੇ ਹਾਂ। ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ Dockerfile.node ਬਣਾਓ

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++

ਅਸੀਂ ਡੌਕਰ ਹੱਬ ਵਿੱਚ ਇੱਕ ਜਨਤਕ ਚਿੱਤਰ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਧੱਕਦੇ ਹਾਂ:

docker build -t exsmund/node-for-angular -f Dockerfile.node .
docker push exsmund/node-for-angular:latest

ਹੁਣ ਸਾਡੀ ਮੁੱਖ ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਅਸੀਂ ਮੁਕੰਮਲ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ:

FROM exsmund/node-for-angular:latest as builder
...

ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਬਿਲਡ ਟਾਈਮ ਘੱਟ ਨਹੀਂ ਹੋਇਆ ਹੈ, ਪਰ ਪਹਿਲਾਂ ਤੋਂ ਬਣਾਈਆਂ ਗਈਆਂ ਤਸਵੀਰਾਂ ਉਪਯੋਗੀ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਇੱਕੋ ਨਿਰਭਰਤਾ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਹੈ।

ਅਸੀਂ ਡੌਕਰ ਚਿੱਤਰਾਂ ਦੇ ਨਿਰਮਾਣ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਕਈ ਤਰੀਕਿਆਂ ਵੱਲ ਦੇਖਿਆ. ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੈਨਾਤੀ ਜਲਦੀ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ:

• ਸੰਦਰਭ ਨੂੰ ਘਟਾਉਣਾ;
• ਛੋਟੇ ਮਾਤਾ-ਪਿਤਾ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ;
• ਮਲਟੀਸਟੇਜ ਅਸੈਂਬਲੀ;
• ਕੈਸ਼ ਦੀ ਕੁਸ਼ਲ ਵਰਤੋਂ ਕਰਨ ਲਈ ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਕ੍ਰਮ ਨੂੰ ਬਦਲਣਾ;
• CI/CD ਸਿਸਟਮਾਂ ਵਿੱਚ ਕੈਸ਼ ਸਥਾਪਤ ਕਰਨਾ;
• ਚਿੱਤਰਾਂ ਦੀ ਸ਼ੁਰੂਆਤੀ ਰਚਨਾ।

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਉਦਾਹਰਨ ਇਹ ਸਪੱਸ਼ਟ ਕਰ ਦੇਵੇਗੀ ਕਿ ਡੌਕਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਆਪਣੀ ਤੈਨਾਤੀ ਨੂੰ ਵਧੀਆ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੋਗੇ. ਲੇਖ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਨਾਲ ਖੇਡਣ ਲਈ, ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਈ ਗਈ ਹੈ https://github.com/devopsprodigy/test-docker-build.

ਸਰੋਤ: www.habr.com