ਵਰਫ ਵਿੱਚ ਮੋਨੋਰੇਪੋ ਅਤੇ ਮਲਟੀਰੇਪੋ ਲਈ ਸਮਰਥਨ ਅਤੇ ਡੌਕਰ ਰਜਿਸਟਰੀ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ

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

werf ਦਾ ਹਾਲੀਆ ਮੋਨੋ-ਰੇਪੋ ਸਪੋਰਟ ਇਸਦੀ ਵਧੀਆ ਉਦਾਹਰਣ ਹੈ। ਪਰ ਪਹਿਲਾਂ, ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਇਹ ਸਮਰਥਨ ਆਮ ਤੌਰ 'ਤੇ werf ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਿਵੇਂ ਸਬੰਧਤ ਹੈ ਅਤੇ ਡੌਕਰ ਰਜਿਸਟਰੀ ਦਾ ਇਸ ਨਾਲ ਕੀ ਸੰਬੰਧ ਹੈ ...

ਮੁੱਦੇ

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

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

ਹੱਲ

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

ਜਦੋਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਈ ਹਿੱਸਿਆਂ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼, ਫਿਰ ਇੱਕ ਖਾਸ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ. ਦੋ ਚਿੱਤਰਾਂ ਵਾਲੀ ਇੱਕ ਆਮ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਉਦਾਹਰਣ 'ਤੇ: frontend и backend - ਸੰਭਵ ਵਿਕਲਪ ਹਨ:

1. ਚਿੱਤਰਾਂ ਨੂੰ ਵੱਖਰੇ ਨੇਸਟਡ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਸਟੋਰ ਕਰੋ:

   

2. ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਟੈਗ ਵਿੱਚ ਚਿੱਤਰ ਦੇ ਨਾਮ 'ਤੇ ਵਿਚਾਰ ਕਰੋ, ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਅਨੁਸਾਰ:

   

NB: ਅਸਲ ਵਿੱਚ, ਵੱਖ-ਵੱਖ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਬੱਚਤ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਹੈ, PROJECT-frontend и PROJECT-backend, ਪਰ ਅਸੀਂ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਸਮਰਥਨ, ਸੰਗਠਨ ਅਤੇ ਅਧਿਕਾਰਾਂ ਦੀ ਵੰਡ ਦੀ ਗੁੰਝਲਤਾ ਦੇ ਕਾਰਨ ਇਸ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਾਂਗੇ।

werf ਸਹਿਯੋਗ

ਸ਼ੁਰੂ ਵਿੱਚ, werf ਆਪਣੇ ਆਪ ਨੂੰ ਨੇਸਟਡ ਰਿਪੋਜ਼ਟਰੀਆਂ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ - ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਜ਼ਿਆਦਾਤਰ ਰਜਿਸਟਰੀਆਂ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ। ਸੰਸਕਰਣ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ v1.0.4-ਅਲਫ਼ਾ.3, ਜਿਸ ਵਿੱਚ ਰਜਿਸਟਰੀਆਂ ਨਾਲ ਕੰਮ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ ਆਲ੍ਹਣਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਡੌਕਰ ਹੱਬ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਉਸ ਬਿੰਦੂ ਤੋਂ, ਉਪਭੋਗਤਾ ਕੋਲ ਐਪਲੀਕੇਸ਼ਨ ਚਿੱਤਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦਾ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ।

ਵਿਕਲਪ ਦੇ ਅਧੀਨ ਲਾਗੂ ਕਰਨਾ ਉਪਲਬਧ ਹੈ --images-repo-mode=multirepo|monorepo (ਮੂਲ multirepo, i.e. ਨੇਸਟਡ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਸਟੋਰੇਜ)। ਇਹ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸ ਦੁਆਰਾ ਚਿੱਤਰਾਂ ਨੂੰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬੁਨਿਆਦੀ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਲੋੜੀਂਦਾ ਮੋਡ ਚੁਣਨ ਲਈ ਇਹ ਕਾਫ਼ੀ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਬਦਲਿਆ ਨਹੀਂ ਰਹੇਗਾ.

ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ werf ਵਿਕਲਪ ਸੈੱਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ, CI / CD ਸਿਸਟਮਾਂ ਵਿੱਚ, ਸਟੋਰੇਜ ਮੋਡ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਣ ਲਈ, GitLab ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਿਰਫ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਇੱਕ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਸ਼ਾਮਲ ਕਰੋ: ਸੈਟਿੰਗਾਂ -> CI / CD -> ਵੇਰੀਏਬਲ: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

ਸ਼ੈਤਾਨ ਵੇਰਵੇ ਵਿੱਚ ਹੈ

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

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

1. 3 ਰਣਨੀਤੀਆਂ ਜੋ ਕਿ ਗਿਟ ਪ੍ਰਾਈਮਿਟਿਵਜ਼ ਦੁਆਰਾ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ ਜਿਵੇਂ ਕਿ ਟੈਗ, ਸ਼ਾਖਾ ਅਤੇ ਪ੍ਰਤੀਬੱਧ;
2. ਮਨਮਾਨੇ ਕਸਟਮ ਟੈਗਾਂ ਲਈ 1 ਰਣਨੀਤੀ।

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

ਜਦੋਂ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (monorepo), ਚਿੱਤਰ ਟੈਗ ਵਿੱਚ, ਮੈਟਾ ਟੈਗ ਤੋਂ ਇਲਾਵਾ, ਚਿੱਤਰ ਦਾ ਨਾਮ ਵੀ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: PROJECT:frontend-META-TAG. ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਲਈ, ਅਸੀਂ ਕੋਈ ਖਾਸ ਵਿਭਾਜਕ ਪੇਸ਼ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵੇਲੇ ਅੰਤਿਮ ਚਿੱਤਰ ਦੇ ਲੇਬਲ ਵਿੱਚ ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਮੁੱਲ ਜੋੜਿਆ ਹੈ।

NB: ਜੇਕਰ ਤੁਸੀਂ werf ਸੋਰਸ ਕੋਡ ਵਿੱਚ ਵਰਣਿਤ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੇਖਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੋ ਸਕਦਾ ਹੈ PR 1684.

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

ਸੰਖੇਪ ਕਰਨ ਲਈ

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

ਸਾਡੇ ਨਾਲ ਰਹੋ ਅਤੇ ਬਹੁਤ ਜਲਦੀ ਅਸੀਂ ਤੁਹਾਨੂੰ ਹੋਰ ਕਾਢਾਂ ਬਾਰੇ ਦੱਸਾਂਗੇ werf!

PS

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

• «ਤੁਸੀਂ ਹੁਣ ਇੱਕ ਨਿਯਮਤ ਡੌਕਰਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਵਰਫ ਵਿੱਚ ਬਣਾ ਸਕਦੇ ਹੋ";
• «werf - ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI / CD ਲਈ ਸਾਡਾ ਟੂਲ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)".

ਸਰੋਤ: www.habr.com