ਡੌਕਰ ਸੁਝਾਅ: ਕਬਾੜ ਦੀ ਆਪਣੀ ਮਸ਼ੀਨ ਨੂੰ ਸਾਫ਼ ਕਰੋ

ਹੇ ਹਬਰ! ਮੈਂ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਤੁਹਾਡੇ ਧਿਆਨ ਵਿੱਚ ਪੇਸ਼ ਕਰਦਾ ਹਾਂ "ਡੌਕਰ ਸੁਝਾਅ: ਆਪਣੀ ਸਥਾਨਕ ਮਸ਼ੀਨ ਨੂੰ ਸਾਫ਼ ਕਰੋ" ਲੇਖਕ Luc Juggery.

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

ਕੁੱਲ ਖਪਤ

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

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

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

$ docker system df

ਇਹ ਵੱਖ-ਵੱਖ ਸੰਦਰਭਾਂ ਵਿੱਚ ਡੌਕਰ ਦੀ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ:

• ਚਿੱਤਰ - ਚਿੱਤਰਾਂ ਦਾ ਕੁੱਲ ਆਕਾਰ ਜੋ ਚਿੱਤਰ ਭੰਡਾਰਾਂ ਤੋਂ ਡਾਊਨਲੋਡ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਤੁਹਾਡੇ ਸਿਸਟਮ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ;
• ਕੰਟੇਨਰ - ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਦੁਆਰਾ ਵਰਤੀ ਗਈ ਡਿਸਕ ਸਪੇਸ ਦੀ ਕੁੱਲ ਮਾਤਰਾ (ਮਤਲਬ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਦੀਆਂ ਰੀਡ-ਰਾਈਟ ਲੇਅਰਾਂ ਦੀ ਕੁੱਲ ਮਾਤਰਾ);
• ਸਥਾਨਕ ਵਾਲੀਅਮ - ਕੰਟੇਨਰਾਂ 'ਤੇ ਮਾਊਂਟ ਕੀਤੇ ਸਥਾਨਕ ਸਟੋਰੇਜ ਦੀ ਮਾਤਰਾ;
• ਬਿਲਡ ਕੈਸ਼ - ਚਿੱਤਰ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀਆਂ ਅਸਥਾਈ ਫਾਈਲਾਂ (ਬਿਲਡਕਿੱਟ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਡੌਕਰ ਸੰਸਕਰਣ 18.09 ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਉਪਲਬਧ ਹੈ)।

ਮੈਂ ਸੱਟਾ ਲਗਾਉਂਦਾ ਹਾਂ ਕਿ ਇਸ ਸਧਾਰਨ ਤਬਾਦਲੇ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਕੂੜੇ ਦੀ ਆਪਣੀ ਡਿਸਕ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਅਤੇ ਕੀਮਤੀ ਗੀਗਾਬਾਈਟ ਨੂੰ ਦੁਬਾਰਾ ਜੀਵਨ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਉਤਸੁਕ ਹੋ (ਨੋਟ: ਖਾਸ ਕਰਕੇ ਜੇ ਤੁਸੀਂ ਹਰ ਮਹੀਨੇ ਇਹਨਾਂ ਗੀਗਾਬਾਈਟਾਂ ਲਈ ਕਿਰਾਇਆ ਦਿੰਦੇ ਹੋ)।

ਕੰਟੇਨਰਾਂ ਦੁਆਰਾ ਡਿਸਕ ਦੀ ਵਰਤੋਂ

ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਹੋਸਟ ਮਸ਼ੀਨ ਉੱਤੇ ਇੱਕ ਕੰਟੇਨਰ ਬਣਾਉਂਦੇ ਹੋ, /var/lib/docker ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕਈ ਫਾਈਲਾਂ ਅਤੇ ਡਾਇਰੈਕਟਰੀਆਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਹਨਾਂ ਵਿੱਚੋਂ ਹੇਠ ਲਿਖੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹਨ:

• ਡਾਇਰੈਕਟਰੀ /var/lib/docker/containers/container_ID - ਸਟੈਂਡਰਡ ਲੌਗਿੰਗ ਡਰਾਈਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਵੈਂਟ ਲੌਗ JSON ਫਾਰਮੈਟ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਸਤ੍ਰਿਤ ਲੌਗ, ਅਤੇ ਨਾਲ ਹੀ ਉਹ ਲੌਗ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਨਹੀਂ ਪੜ੍ਹਦਾ ਜਾਂ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕਰਦਾ, ਅਕਸਰ ਡਿਸਕਾਂ ਨੂੰ ਭਰਨ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ।
• /var/lib/docker/overlay2 ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੰਟੇਨਰ ਰੀਡ-ਰਾਈਟ ਲੇਅਰ ਹਨ (ਓਵਰਲੇ2 ਜ਼ਿਆਦਾਤਰ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਤਰਜੀਹੀ ਡਰਾਈਵਰ ਹੈ)। ਜੇਕਰ ਕੰਟੇਨਰ ਆਪਣੇ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹੈ ਜੋ ਇਸਨੂੰ ਰੱਖਿਆ ਜਾਵੇਗਾ।

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

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         0          0          0B         0B
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

ਚਲੋ ਕੁਝ ਕੰਟੇਨਰ ਲਾਂਚ ਕਰੀਏ, ਉਦਾਹਰਨ ਲਈ, NGINX:

$ docker container run --name www -d -p 8000:80 nginx:1.16

ਡਿਸਕ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ:

• ਚਿੱਤਰ 126 MB ਰੱਖਦੇ ਹਨ, ਇਹ ਉਹੀ NGINX ਹੈ ਜੋ ਅਸੀਂ ਕੰਟੇਨਰ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਹੈ;
• ਕੰਟੇਨਰ ਇੱਕ ਹਾਸੋਹੀਣੀ 2 ਬਾਈਟ ਲੈਂਦੇ ਹਨ।

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          2B         0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

ਸਿੱਟੇ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਸਾਡੇ ਕੋਲ ਅਜੇ ਕੋਈ ਜਗ੍ਹਾ ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਅਸੀਂ ਖਾਲੀ ਕਰ ਸਕੀਏ. ਕਿਉਂਕਿ 2 ਬਾਈਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਕਾਰ ਹਨ, ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਡੇ NGINX ਨੇ ਅਚਾਨਕ ਕਿਤੇ 100 ਮੈਗਾਬਾਈਟ ਡੇਟਾ ਲਿਖਿਆ ਹੈ ਅਤੇ ਆਪਣੇ ਅੰਦਰ ਬਿਲਕੁਲ ਇਸ ਆਕਾਰ ਦੀ ਇੱਕ ਫਾਈਲ test.img ਬਣਾਈ ਹੈ।

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

ਆਉ ਦੁਬਾਰਾ ਹੋਸਟ ਉੱਤੇ ਡਿਸਕ ਸਪੇਸ ਦੀ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰੀਏ। ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਕੰਟੇਨਰ (ਕੰਟੇਨਰ) ਉੱਥੇ 100 ਮੈਗਾਬਾਈਟ ਉੱਤੇ ਕਬਜ਼ਾ ਕਰ ਲੈਂਦਾ ਹੈ।

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          104.9MB    0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਖੋਜੀ ਦਿਮਾਗ ਪਹਿਲਾਂ ਹੀ ਹੈਰਾਨ ਹੈ ਕਿ ਸਾਡੀ test.img ਫਾਈਲ ਕਿੱਥੇ ਸਥਿਤ ਹੈ। ਆਓ ਇਸ ਦੀ ਖੋਜ ਕਰੀਏ:

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img

ਵੇਰਵਿਆਂ ਵਿੱਚ ਜਾਣ ਤੋਂ ਬਿਨਾਂ, ਅਸੀਂ ਨੋਟ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ test.img ਫਾਈਲ ਆਸਾਨੀ ਨਾਲ ਰੀਡ-ਰਾਈਟ ਪੱਧਰ 'ਤੇ ਸਥਿਤ ਹੈ, ਓਵਰਲੇ2 ਡਰਾਈਵਰ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਆਪਣੇ ਕੰਟੇਨਰ ਨੂੰ ਰੋਕਦੇ ਹਾਂ, ਤਾਂ ਹੋਸਟ ਸਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਇਹ ਸਪੇਸ, ਸਿਧਾਂਤ ਵਿੱਚ, ਖਾਲੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ:

# Stopping the www container
$ docker stop www

# Visualizing the impact on the disk usage
$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          0          104.9MB    104.9MB (100%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹਾਂ? ਕੰਟੇਨਰ ਨੂੰ ਮਿਟਾਉਣ ਦੁਆਰਾ, ਜਿਸ ਨਾਲ ਪੜ੍ਹਨ-ਲਿਖਣ ਦੇ ਪੱਧਰ 'ਤੇ ਸੰਬੰਧਿਤ ਸਪੇਸ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ ਸ਼ਾਮਲ ਹੋਵੇਗਾ।

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

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Total reclaimed space: 104.9MB

ਇਸ ਲਈ, ਅਸੀਂ ਕੰਟੇਨਰ ਨੂੰ ਮਿਟਾ ਕੇ 104,9 ਮੈਗਾਬਾਈਟ ਖਾਲੀ ਕਰ ਦਿੱਤਾ ਹੈ। ਪਰ ਕਿਉਂਕਿ ਅਸੀਂ ਹੁਣ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਕੀਤੇ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਇਹ ਸਾਡੇ ਸਰੋਤਾਂ ਨੂੰ ਮਿਟਾਉਣ ਅਤੇ ਖਾਲੀ ਕਰਨ ਲਈ ਵੀ ਇੱਕ ਉਮੀਦਵਾਰ ਬਣ ਜਾਂਦਾ ਹੈ:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          0          126M       126M (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

ਨੋਟ: ਜਿੰਨਾ ਚਿਰ ਚਿੱਤਰ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕੰਟੇਨਰ ਦੁਆਰਾ ਵਰਤੋਂ ਵਿੱਚ ਹੈ, ਤੁਸੀਂ ਇਸ ਚਾਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ।

ਪ੍ਰੂਨ ਸਬਕਮਾਂਡ ਜੋ ਅਸੀਂ ਉੱਪਰ ਵਰਤੀ ਹੈ, ਸਿਰਫ ਰੁਕੇ ਹੋਏ ਕੰਟੇਨਰਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਨਾ ਸਿਰਫ਼ ਰੁਕੇ ਹੋਏ, ਸਗੋਂ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਵੀ ਮਿਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

# Historical command
$ docker rm -f $(docker ps –aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

ਸਾਈਡ ਨੋਟਸ: ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਕੰਟੇਨਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ -rm ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਜਦੋਂ ਇਹ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਰੀ ਡਿਸਕ ਸਪੇਸ ਖਾਲੀ ਹੋ ਜਾਵੇਗੀ ਜਿਸ 'ਤੇ ਇਸ ਨੇ ਕਬਜ਼ਾ ਕੀਤਾ ਹੈ।

ਡਿਸਕ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

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

ਇੱਥੇ ਕਈ ਕਿਸਮਾਂ ਦੀਆਂ ਤਸਵੀਰਾਂ ਹਨ ਜੋ ਸਿੱਧੇ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੀਆਂ:

• ਵਿਚਕਾਰਲੇ ਚਿੱਤਰ, ਜਿਸ ਦੇ ਆਧਾਰ 'ਤੇ ਹੋਰ ਤਸਵੀਰਾਂ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ - ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ "ਹੋਰ" ਚਿੱਤਰਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਮਿਟਾਇਆ ਜਾ ਸਕਦਾ;
• ਲਟਕਦੀਆਂ ਤਸਵੀਰਾਂ ਵਿਚਕਾਰਲੇ ਚਿੱਤਰ ਹਨ ਜੋ ਕਿਸੇ ਵੀ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਦੁਆਰਾ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤੇ ਗਏ ਹਨ - ਉਹਨਾਂ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਨਾਲ ਤੁਸੀਂ ਆਪਣੇ ਸਿਸਟਮ 'ਤੇ ਲਟਕਦੀਆਂ ਤਸਵੀਰਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ:

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਤਰੀਕੇ ਨਾਲ ਹਟਾ ਸਕਦੇ ਹੋ:

$ docker image rm $(docker image ls -f dangling=true -q)

ਅਸੀਂ prune ਸਬਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰ ਸਕਦੇ ਹਾਂ:

$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Total reclaimed space: 12.9kB

ਜੇਕਰ ਅਸੀਂ ਅਚਾਨਕ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਿਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ (ਅਤੇ ਨਾ ਸਿਰਫ਼ ਲਟਕਦੇ ਹੋਏ) ਤਾਂ ਅਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹਾਂ:

$ docker image rm $(docker image ls -q)

ਵਾਲੀਅਮ ਦੁਆਰਾ ਡਿਸਕ ਦੀ ਵਰਤੋਂ

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

ਚਲੋ ਇੱਕ MongoDB ਕੰਟੇਨਰ ਲਾਂਚ ਕਰੀਏ, ਕੰਟੇਨਰ ਦੇ ਬਾਹਰ ਇੱਕ ਵਾਲੀਅਮ ਮਾਊਂਟ ਕਰੀਏ, ਅਤੇ ਇਸ ਤੋਂ ਇੱਕ ਡਾਟਾਬੇਸ ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਕਰੀਏ (ਸਾਡੇ ਕੋਲ ਇਹ bck.json ਫਾਈਲ ਵਿੱਚ ਉਪਲਬਧ ਹੈ):

# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0

# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport 
  --db 'test' 
  --collection 'demo' 
  --file /tmp/bck.json 
  --jsonArray

ਡੇਟਾ /var/lib/docker/volumes ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹੋਸਟ ਮਸ਼ੀਨ ਉੱਤੇ ਸਥਿਤ ਹੋਵੇਗਾ। ਪਰ ਡੱਬੇ ਦੇ ਪੜ੍ਹਨ-ਲਿਖਣ ਦੇ ਪੱਧਰ 'ਤੇ ਕਿਉਂ ਨਹੀਂ? ਕਿਉਂਕਿ ਮੋਂਗੋਡੀਬੀ ਚਿੱਤਰ ਦੀ ਡੌਕਰਫਾਈਲ ਵਿੱਚ, /ਡਾਟਾ/ਡੀਬੀ ਡਾਇਰੈਕਟਰੀ (ਜਿੱਥੇ ਮੋਂਗੋਡੀਬੀ ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰਦੀ ਹੈ) ਨੂੰ ਇੱਕ ਵਾਲੀਅਮ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਸਾਈਡ ਨੋਟ: ਬਹੁਤ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਡਾਟਾ ਪੈਦਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਲਈ ਵਾਲੀਅਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

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

$ docker volume rm $(docker volume ls -q)

ਖੈਰ, ਜਾਂ ਅਸੀਂ prune ਸਬਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਡੇ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣੂ ਹੈ:

$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Total reclaimed space: 25.82GB
luc@saturn:~$

ਚਿੱਤਰ ਬਿਲਡ ਕੈਸ਼ ਲਈ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

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

ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਧਾਰਨ Node.Js ਐਪਲੀਕੇਸ਼ਨ ਹੈ:

• index.js ਫਾਈਲ ਇੱਕ ਸਧਾਰਨ HTTP ਸਰਵਰ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਜੋ ਪ੍ਰਾਪਤ ਕੀਤੀ ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਇੱਕ ਲਾਈਨ ਨਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ:
• package.json ਫਾਈਲ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ HTTP ਸਰਵਰ ਨੂੰ ਚਲਾਉਣ ਲਈ ਸਿਰਫ਼ expressjs ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ:

$ cat index.js
var express = require('express');
var util    = require('util');
var app = express();
app.get('/', function(req, res) {
  res.setHeader('Content-Type', 'text/plain');
  res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);

$ cat package.json
    {
      "name": "testnode",
      "version": "0.0.1",
      "main": "index.js",
      "scripts": {
        "start": "node index.js"
      },
      "dependencies": {
        "express": "^4.14.0"
      }
    }

ਚਿੱਤਰ ਬਣਾਉਣ ਲਈ ਡੌਕਰਫਾਈਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

ਆਓ ਬਿਲਡਕਿਟ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ, ਆਮ ਤਰੀਕੇ ਨਾਲ ਚਿੱਤਰ ਨੂੰ ਬਣਾਈਏ:

$ docker build -t app:1.0 .

ਜੇਕਰ ਅਸੀਂ ਡਿਸਕ ਸਪੇਸ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਸਿਰਫ਼ ਬੇਸ ਚਿੱਤਰ (ਨੋਡ: 13-ਐਲਪਾਈਨ) ਅਤੇ ਟਾਰਗੇਟ ਚਿੱਤਰ (ਐਪ: 1.0) ਸਪੇਸ ਲੈ ਰਹੇ ਹਨ:

TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

ਆਓ BuildKit ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਦੂਜਾ ਸੰਸਕਰਣ ਬਣਾਈਏ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸਿਰਫ਼ DOCKER_BUILDKIT ਵੇਰੀਏਬਲ ਨੂੰ 1 'ਤੇ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

ਜੇਕਰ ਅਸੀਂ ਹੁਣ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਬਿਲਡ ਕੈਸ਼ (buid-cache) ਹੁਣ ਉੱਥੇ ਸ਼ਾਮਲ ਹੈ:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    11         0          8.949kB    8.949kB

ਇਸਨੂੰ ਸਾਫ਼ ਕਰਨ ਲਈ, ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ:

$ docker builder prune
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Total reclaimed space: 8.949kB

ਸਾਰਾ ਸਾਫ ਕਰੋ!

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

$ docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N]

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

ਸਰੋਤ: www.habr.com