ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਦੀ "ਸਮਾਰਟ" ਸਫਾਈ ਦੀ ਸਮੱਸਿਆ ਅਤੇ ਵਰਫ ਵਿੱਚ ਇਸਦਾ ਹੱਲ

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

ਜਾਣ ਪਛਾਣ

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

1. ਚਿੱਤਰਾਂ ਲਈ ਇੱਕ ਨਿਸ਼ਚਿਤ ਗਿਣਤੀ ਦੇ ਟੈਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ;
2. ਚਿੱਤਰਾਂ ਨੂੰ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਸਾਫ਼ ਕਰੋ।

ਪਹਿਲੀ ਸੀਮਾ ਕਈ ਵਾਰ ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਡਿਵੈਲਪਰ ਕੋਲ ਕਾਫ਼ੀ ਸਥਾਈ ਟੈਗ ਹਨ (latest, main, test, boris ਆਦਿ), ਰਜਿਸਟਰੀ ਆਕਾਰ ਵਿਚ ਨਹੀਂ ਸੁੱਜੇਗੀ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਬਾਰੇ ਬਿਲਕੁਲ ਨਹੀਂ ਸੋਚਣਾ ਪਏਗਾ। ਆਖ਼ਰਕਾਰ, ਸਾਰੀਆਂ ਅਪ੍ਰਸੰਗਿਕ ਤਸਵੀਰਾਂ ਮਿਟਾ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਸਫਾਈ ਲਈ ਕੋਈ ਕੰਮ ਨਹੀਂ ਬਚਦਾ ਹੈ (ਸਭ ਕੁਝ ਇੱਕ ਨਿਯਮਤ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ).

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

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

ਪਰ ਤੁਸੀਂ ਇਹ ਵੀ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ ਕਿ ਕੋਈ ਚਿੱਤਰ ਢੁਕਵਾਂ ਹੈ ਜਾਂ ਨਹੀਂ?

ਚਿੱਤਰ ਦੀ ਸਾਰਥਕਤਾ ਲਈ ਮਾਪਦੰਡ

ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮੁੱਖ ਮਾਪਦੰਡ ਇਹ ਹੋਣਗੇ:

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

2. ਦੂਜਾ (ਘੱਟ ਸਪੱਸ਼ਟ, ਪਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਵੀ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੋਸ਼ਣ ਨਾਲ ਸਬੰਧਤ ਹੈ) - ਚਿੱਤਰ ਜੋ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਰੋਲਬੈਕ ਲਈ ਲੋੜੀਂਦਾ ਹੈ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਵਿੱਚ. ਉਦਾਹਰਨ ਲਈ, ਹੈਲਮ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਉਹ ਚਿੱਤਰ ਹਨ ਜੋ ਰੀਲੀਜ਼ ਦੇ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। (ਵੈਸੇ, ਹੇਲਮ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸੀਮਾ 256 ਸੰਸ਼ੋਧਨ ਹੈ, ਪਰ ਇਹ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ ਕਿ ਕਿਸੇ ਨੂੰ ਅਸਲ ਵਿੱਚ ਬਚਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਜਿਹੇ ਇੱਕ ਸੰਸਕਰਣਾਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ?..) ਆਖਰਕਾਰ, ਅਸੀਂ, ਖਾਸ ਤੌਰ 'ਤੇ, ਸੰਸਕਰਣਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵਰਤ ਸਕੀਏ, ਜਿਵੇਂ ਕਿ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਉਹਨਾਂ ਨੂੰ "ਰੋਲ ਬੈਕ" ਕਰੋ।

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

4. ਚੌਥਾ - ਚਿੱਤਰ ਜੋ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੰਸਕਰਣਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, i.e. ਅੰਤਿਮ ਉਤਪਾਦ ਹਨ: v1.0.0, 20.04.01/XNUMX/XNUMX, ਸਿਏਰਾ, ਆਦਿ।

ਨੋਟ: ਇੱਥੇ ਪਰਿਭਾਸ਼ਿਤ ਮਾਪਦੰਡ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਦੀਆਂ ਦਰਜਨਾਂ ਵਿਕਾਸ ਟੀਮਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਅਨੁਭਵ ਦੇ ਆਧਾਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ। ਹਾਲਾਂਕਿ, ਬੇਸ਼ੱਕ, ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਵਰਤੇ ਗਏ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (ਉਦਾਹਰਨ ਲਈ, ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ) 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਇਹ ਮਾਪਦੰਡ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ।

ਯੋਗਤਾ ਅਤੇ ਮੌਜੂਦਾ ਹੱਲ

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

* ਖਾਸ ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ ਲਾਗੂਕਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਹੱਲਾਂ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ: Azure CR, Docker Hub, ECR, GCR, GitHub ਪੈਕੇਜ, GitLab ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ, ਹਾਰਬਰ ਰਜਿਸਟਰੀ, JFrog Artifactory, Quay.io - ਸਤੰਬਰ'2020 ਤੱਕ।

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

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

ਪਹਿਲੇ ਦੋ ਮਾਪਦੰਡਾਂ ਦੇ ਨਾਲ ਸਥਿਤੀ ਸਮਾਨ ਹੈ: ਉਹ ਇੱਕ ਬਾਹਰੀ ਸਿਸਟਮ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਹੋ ਸਕਦੇ - ਇੱਕ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ)।

Git ਵਿੱਚ ਵਰਕਫਲੋ ਦਾ ਉਦਾਹਰਨ

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ Git ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਹੇ ਹੋ:

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

ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਸਫ਼ਾਈ ਨੀਤੀਆਂ ਸਿਰਫ਼ ਚਿੱਤਰਾਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ (ਮਿਟਾਏ ਨਹੀਂ ਜਾਂਦੇ) ਦਿੱਤੇ ਟੈਗ ਨਾਮਾਂ ਦੁਆਰਾ?

ਜ਼ਾਹਿਰ ਹੈ, ਅਜਿਹਾ ਦ੍ਰਿਸ਼ ਕਿਸੇ ਨੂੰ ਖ਼ੁਸ਼ ਨਹੀਂ ਕਰੇਗਾ।

ਜੇਕਰ ਨੀਤੀਆਂ ਚਿੱਤਰਾਂ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀਆਂ ਤਾਂ ਕੀ ਬਦਲੇਗਾ? ਇੱਕ ਦਿੱਤੇ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ / ਆਖਰੀ ਕਮਿਟਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਅਨੁਸਾਰ?

ਨਤੀਜਾ ਬਹੁਤ ਵਧੀਆ ਹੋ ਗਿਆ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਆਦਰਸ਼ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ. ਆਖਰਕਾਰ, ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਡਿਵੈਲਪਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬੱਗ ਡੀਬੱਗ ਕਰਨ ਲਈ ਰਜਿਸਟਰੀ (ਜਾਂ K8s ਵਿੱਚ ਤੈਨਾਤ) ਵਿੱਚ ਚਿੱਤਰਾਂ ਦੀ ਲੋੜ ਹੈ...

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

ਹਾਲਾਂਕਿ, ਅਸੀਂ ਇੱਕ ਯੂਨੀਵਰਸਲ ਹੱਲ ਲੱਭ ਰਹੇ ਸੀ ਜੋ ਵੱਖ-ਵੱਖ ਰਜਿਸਟਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਲਈ ਚਿੱਤਰ ਕਲੀਨਅੱਪ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰੇਗਾ...

ਯੂਨੀਵਰਸਲ ਚਿੱਤਰ ਸਫਾਈ ਲਈ ਸਾਡਾ ਮਾਰਗ

ਇਹ ਲੋੜ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ? ਤੱਥ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਡਿਵੈਲਪਰਾਂ ਦਾ ਇੱਕ ਵੱਖਰਾ ਸਮੂਹ ਨਹੀਂ ਹਾਂ, ਪਰ ਇੱਕ ਟੀਮ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤਿਆਂ ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ, CI/CD ਮੁੱਦਿਆਂ ਨੂੰ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਅਤੇ ਇਸਦੇ ਲਈ ਮੁੱਖ ਤਕਨੀਕੀ ਸਾਧਨ ਓਪਨ ਸੋਰਸ ਉਪਯੋਗਤਾ ਹੈ werf. ਇਸਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਇਹ ਇੱਕ ਵੀ ਫੰਕਸ਼ਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਸਾਰੇ ਪੜਾਵਾਂ 'ਤੇ ਨਿਰੰਤਰ ਡਿਲੀਵਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਨਾਲ ਹੈ: ਅਸੈਂਬਲੀ ਤੋਂ ਤੈਨਾਤੀ ਤੱਕ।

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

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

ਹਾਲਾਂਕਿ ਅਸੀਂ werf ਨੂੰ ਇੱਕ ਉਦਾਹਰਨ ਲਾਗੂ ਕਰਨ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਵਰਤੀਆਂ ਗਈਆਂ ਪਹੁੰਚ ਸਮਾਨ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੀਆਂ ਹੋਰ ਟੀਮਾਂ ਲਈ ਉਪਯੋਗੀ ਹੋਣਗੀਆਂ।

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

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

ਟੈਗਿੰਗ ਸਕੀਮਾਂ

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਪਹੁੰਚ ਚੁਣੀ ਹੈ ਜਿਸ ਵਿੱਚ ਅੰਤਮ ਚਿੱਤਰ ਨੂੰ ਸਫਾਈ ਲਈ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਟੈਗਿੰਗ ਸਕੀਮਾਂ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਬਣਾਈ ਹੈ। ਇੱਕ ਚਿੱਤਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਸਮੇਂ, ਉਪਭੋਗਤਾ ਨੇ ਇੱਕ ਖਾਸ ਟੈਗਿੰਗ ਵਿਕਲਪ ਚੁਣਿਆ (git-branch, git-commit ਜ git-tag) ਅਤੇ ਸੰਬੰਧਿਤ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। CI ਸਿਸਟਮਾਂ ਵਿੱਚ, ਇਹ ਮੁੱਲ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੇ ਅਧਾਰ ਤੇ ਆਪਣੇ ਆਪ ਸੈੱਟ ਕੀਤੇ ਗਏ ਸਨ। ਵਾਸਤਵ ਵਿੱਚ ਅੰਤਮ ਚਿੱਤਰ ਨੂੰ ਇੱਕ ਖਾਸ ਗਿੱਟ ਪ੍ਰਾਈਮਿਟਿਵ ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਲੇਬਲਾਂ ਵਿੱਚ ਸਫਾਈ ਲਈ ਲੋੜੀਂਦੇ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨਾ।

ਇਸ ਪਹੁੰਚ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਨੀਤੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੋਇਆ ਜਿਸ ਨੇ ਗਿੱਟ ਨੂੰ ਸੱਚ ਦੇ ਇੱਕਲੇ ਸਰੋਤ ਵਜੋਂ ਵਰਤਣ ਦੀ ਆਗਿਆ ਦਿੱਤੀ:

• Git ਵਿੱਚ ਇੱਕ ਸ਼ਾਖਾ/ਟੈਗ ਨੂੰ ਮਿਟਾਉਣ ਵੇਲੇ, ਰਜਿਸਟਰੀ ਵਿੱਚ ਸਬੰਧਿਤ ਚਿੱਤਰ ਆਪਣੇ ਆਪ ਮਿਟਾ ਦਿੱਤੇ ਗਏ ਸਨ।
• ਗਿੱਟ ਟੈਗਸ ਅਤੇ ਕਮਿਟਸ ਨਾਲ ਸਬੰਧਿਤ ਚਿੱਤਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਚੁਣੀ ਗਈ ਸਕੀਮਾ ਵਿੱਚ ਵਰਤੇ ਗਏ ਟੈਗਾਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਉਸ ਸਮੇਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸ ਸਮੇਂ ਸਬੰਧਿਤ ਕਮਿਟ ਬਣਾਇਆ ਗਿਆ ਸੀ।

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

ਨਵਾਂ ਐਲਗੋਰਿਦਮ

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

ਨਵੇਂ ਸਫਾਈ ਐਲਗੋਰਿਦਮ ਲਈ, ਟੈਗਿੰਗ ਸਕੀਮਾਂ ਅਤੇ ਬਿਲਡ ਤੋਂ ਦੂਰ ਜਾਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ ਮੈਟਾ-ਚਿੱਤਰ ਪ੍ਰਕਿਰਿਆ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦਾ ਇੱਕ ਸਮੂਹ ਸਟੋਰ ਕਰਦਾ ਹੈ:

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

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

ਅੰਤਮ ਸੰਰਚਨਾ ਅਤੇ ਆਮ ਐਲਗੋਰਿਦਮ

ਸਫਾਈ ਦੀ ਸੰਰਚਨਾ ਕਰਦੇ ਸਮੇਂ, ਉਪਭੋਗਤਾਵਾਂ ਕੋਲ ਹੁਣ ਉਹਨਾਂ ਨੀਤੀਆਂ ਤੱਕ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ ਜੋ ਮੌਜੂਦਾ ਚਿੱਤਰਾਂ ਨੂੰ ਚੁਣਦੀਆਂ ਹਨ। ਅਜਿਹੀ ਹਰੇਕ ਨੀਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ:

• ਬਹੁਤ ਸਾਰੇ ਹਵਾਲੇ, i.e. Git ਟੈਗਸ ਜਾਂ Git ਸ਼ਾਖਾਵਾਂ ਜੋ ਸਕੈਨਿੰਗ ਦੌਰਾਨ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ;
• ਅਤੇ ਸੈੱਟ ਤੋਂ ਹਰੇਕ ਸੰਦਰਭ ਲਈ ਖੋਜੇ ਗਏ ਚਿੱਤਰਾਂ ਦੀ ਸੀਮਾ।

ਦਰਸਾਉਣ ਲਈ, ਡਿਫੌਲਟ ਨੀਤੀ ਸੰਰਚਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਣ ਲੱਗੀ:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ਇਸ ਸੰਰਚਨਾ ਵਿੱਚ ਤਿੰਨ ਨੀਤੀਆਂ ਹਨ ਜੋ ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ:

1. ਚਿੱਤਰ ਨੂੰ ਆਖਰੀ 10 ਗਿੱਟ ਟੈਗਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਕਰੋ (ਟੈਗ ਬਣਾਉਣ ਦੀ ਮਿਤੀ ਦੁਆਰਾ)।
2. ਪਿਛਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ 2 ਤੋਂ ਵੱਧ ਚਿੱਤਰਾਂ ਨੂੰ ਪਿਛਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਸਰਗਰਮੀ ਵਾਲੇ 10 ਥਰਿੱਡਾਂ ਤੋਂ ਵੱਧ ਨਾ ਸੰਭਾਲੋ।
3. ਸ਼ਾਖਾਵਾਂ ਲਈ 10 ਚਿੱਤਰ ਸੁਰੱਖਿਅਤ ਕਰੋ main, staging и production.

ਅੰਤਮ ਐਲਗੋਰਿਦਮ ਹੇਠਾਂ ਦਿੱਤੇ ਪੜਾਵਾਂ 'ਤੇ ਉਬਲਦਾ ਹੈ:

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

ਸਾਡੇ ਦ੍ਰਿਸ਼ਟਾਂਤ 'ਤੇ ਵਾਪਸ ਆਉਣਾ, werf ਨਾਲ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ:

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

ਸਿੱਟਾ

• ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਰਜਿਸਟਰੀ ਓਵਰਫਲੋ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ।
• ਹੱਲਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਸਮੇਂ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਚਿੱਤਰ ਦੀ ਸਾਰਥਕਤਾ ਲਈ ਮਾਪਦੰਡ ਨਿਰਧਾਰਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ.
• ਪ੍ਰਸਿੱਧ ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਟੂਲ ਤੁਹਾਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਸਫਾਈ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਜੋ "ਬਾਹਰਲੀ ਦੁਨੀਆਂ" ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ: ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਵਰਤੀਆਂ ਗਈਆਂ ਤਸਵੀਰਾਂ ਅਤੇ ਟੀਮ ਦੇ ਵਰਕਫਲੋ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ।
• ਇੱਕ ਲਚਕਦਾਰ ਅਤੇ ਕੁਸ਼ਲ ਐਲਗੋਰਿਦਮ ਵਿੱਚ CI/CD ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸਮਝ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਨਾ ਸਿਰਫ਼ ਡੌਕਰ ਚਿੱਤਰ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਵਰਫ ਕੁਲੈਕਟਰ ਵਿੱਚ ਸਮਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ: ਇਹ ਕਿਉਂ ਅਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?";
• «3-ਵੇਅ ਮਰਜ ਟੂ ਵਰਫ: ਹੈਲਮ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਦੀ ਤੈਨਾਤੀ “ਸਟੀਰੌਇਡਜ਼ ਉੱਤੇ”";
• «ਵਰਫ ਵਿੱਚ ਮੋਨੋਰੇਪੋ ਅਤੇ ਮਲਟੀਰੇਪੋ ਲਈ ਸਮਰਥਨ ਅਤੇ ਡੌਕਰ ਰਜਿਸਟਰੀ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ";
• «werf 1.1 ਰੀਲੀਜ਼: ਅੱਜ ਬਿਲਡਰ ਲਈ ਸੁਧਾਰ ਅਤੇ ਭਵਿੱਖ ਲਈ ਯੋਜਨਾਵਾਂ".

ਸਰੋਤ: www.habr.com