ਵਰਫ ਕੁਲੈਕਟਰ ਵਿੱਚ ਸਮਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ: ਇਹ ਕਿਉਂ ਅਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

werf ਕੁਬਰਨੇਟਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਅਤੇ ਡਿਲੀਵਰ ਕਰਨ ਲਈ ਸਾਡੀ ਓਪਨ ਸੋਰਸ GitOps CLI ਉਪਯੋਗਤਾ ਹੈ। IN ਰਿਲੀਜ਼ v1.1 ਚਿੱਤਰ ਕੁਲੈਕਟਰ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਸੀ: ਸਮੱਗਰੀ ਦੁਆਰਾ ਚਿੱਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰਨਾ ਜਾਂ ਸਮੱਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ. ਹੁਣ ਤੱਕ, ਵਰਫ ਵਿੱਚ ਆਮ ਟੈਗਿੰਗ ਸਕੀਮ ਵਿੱਚ ਗਿੱਟ ਟੈਗ, ਗਿੱਟ ਬ੍ਰਾਂਚ ਜਾਂ ਗਿੱਟ ਕਮਿਟ ਦੁਆਰਾ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰਨਾ ਸ਼ਾਮਲ ਸੀ। ਪਰ ਇਹਨਾਂ ਸਾਰੀਆਂ ਸਕੀਮਾਂ ਦੇ ਨੁਕਸਾਨ ਹਨ ਜੋ ਨਵੀਂ ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਦੁਆਰਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕੀਤੇ ਗਏ ਹਨ. ਇਸ ਬਾਰੇ ਵੇਰਵੇ ਅਤੇ ਇਹ ਇੰਨਾ ਵਧੀਆ ਕਿਉਂ ਹੈ ਕੱਟ ਦੇ ਅਧੀਨ ਹਨ।

ਇੱਕ Git ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਜ਼ ਦੇ ਇੱਕ ਸੈੱਟ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨਾ

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

ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਸੇਵਾਵਾਂ ਅਸਲ ਵਿੱਚ ਸੁਤੰਤਰ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਜੁੜੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਉਹ ਵੱਖਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਸਥਿਤ ਹੋਣਗੇ ਅਤੇ ਉਹਨਾਂ ਦੀ ਰਿਲੀਜ਼ ਹਰੇਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵੱਖਰੀਆਂ CI/CD ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੁਆਰਾ ਕੀਤੀ ਜਾਵੇਗੀ।

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

Git ਬ੍ਰਾਂਚ ਅਤੇ Git ਟੈਗ ਦੁਆਰਾ ਟੈਗਿੰਗ

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

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

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

ਇਹ ਨਵੇਂ ਚਿੱਤਰ ਨਾਮ ਹੈਲਮ ਟੈਂਪਲੇਟਸ ਦੁਆਰਾ ਕੁਬਰਨੇਟਸ ਸੰਰਚਨਾ ਵਿੱਚ ਪਾਸ ਕੀਤੇ ਗਏ ਹਨ। ਜਦੋਂ ਕਮਾਂਡ ਨਾਲ ਤੈਨਾਤੀ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ werf deploy ਖੇਤਰ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ image ਕੁਬਰਨੇਟਸ ਰਿਸੋਰਸ ਵਿੱਚ ਬਦਲੇ ਹੋਏ ਚਿੱਤਰ ਨਾਮ ਦੇ ਕਾਰਨ ਸੰਬੰਧਿਤ ਸਰੋਤਾਂ ਨੂੰ ਪ੍ਰਗਟ ਅਤੇ ਮੁੜ ਚਾਲੂ ਕਰਨਾ।

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

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

ਗਿੱਟ ਕਮਿਟ ਦੁਆਰਾ ਟੈਗਿੰਗ

werf ਦੀ ਇੱਕ ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਵੀ Git ਕਮਿਟ ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ।

Git-commit ਇੱਕ Git ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਸਮੱਗਰੀ ਲਈ ਇੱਕ ਪਛਾਣਕਰਤਾ ਹੈ ਅਤੇ Git ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਫਾਈਲਾਂ ਦੇ ਸੰਪਾਦਨ ਇਤਿਹਾਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਡੌਕਰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਚਿੱਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰਨ ਲਈ ਇਸਨੂੰ ਵਰਤਣਾ ਤਰਕਪੂਰਨ ਜਾਪਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਗਿੱਟ ਕਮਿਟ ਦੁਆਰਾ ਟੈਗਿੰਗ ਦੇ ਉਹੀ ਨੁਕਸਾਨ ਹਨ ਜਿੰਨੇ ਗਿੱਟ ਸ਼ਾਖਾਵਾਂ ਜਾਂ ਗਿੱਟ ਟੈਗਸ ਦੁਆਰਾ ਟੈਗਿੰਗ:

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

ਗਿੱਟ ਸ਼ਾਖਾ ਦਾ ਨਾਮ ਟੈਗ ਕਰਨਾ ਚਿੱਤਰ ਸੰਸਕਰਣ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦਾ ਹੈ

ਗਿੱਟ ਸ਼ਾਖਾਵਾਂ ਲਈ ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਨਾਲ ਜੁੜੀ ਇਕ ਹੋਰ ਸਮੱਸਿਆ ਹੈ.

ਬ੍ਰਾਂਚ ਦੇ ਨਾਮ ਦੁਆਰਾ ਟੈਗਿੰਗ ਉਦੋਂ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਉਸ ਸ਼ਾਖਾ 'ਤੇ ਕਮਿਟਾਂ ਨੂੰ ਕਾਲਕ੍ਰਮਿਕ ਕ੍ਰਮ ਵਿੱਚ ਕ੍ਰਮਵਾਰ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਉਹਨਾਂ ਦੇ ਵਿਚਕਾਰ ਥੋੜੇ ਸਮੇਂ ਦੇ ਨਾਲ ਇੱਕ ਸ਼ਾਖਾ ਵਿੱਚ ਲਗਾਤਾਰ ਧੱਕਣ ਦੇ ਨਾਲ, ਪੁਰਾਣੀ ਪ੍ਰਤੀਬੱਧਤਾ ਨੂੰ ਨਵੇਂ ਨਾਲੋਂ ਬਾਅਦ ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਚਿੱਤਰ ਦਾ ਪੁਰਾਣਾ ਸੰਸਕਰਣ Git ਬ੍ਰਾਂਚ ਟੈਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਵੇਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰੇਗਾ। ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇੱਕ CI/CD ਸਿਸਟਮ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, GitLab CI ਵਿੱਚ ਬਾਅਦ ਦੀ ਪਾਈਪਲਾਈਨ ਕਮਿਟਾਂ ਦੀ ਇੱਕ ਲੜੀ ਲਈ ਲਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ)। ਹਾਲਾਂਕਿ, ਸਾਰੇ ਸਿਸਟਮ ਇਸਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ ਅਤੇ ਅਜਿਹੀ ਬੁਨਿਆਦੀ ਸਮੱਸਿਆ ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਹੋਰ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਮੱਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ ਕੀ ਹੈ?

ਇਸ ਲਈ, ਸਮੱਗਰੀ-ਅਧਾਰਿਤ ਟੈਗਿੰਗ ਕੀ ਹੈ - ਸਮੱਗਰੀ ਦੁਆਰਾ ਚਿੱਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰਨਾ.

ਡੌਕਰ ਟੈਗਸ ਬਣਾਉਣ ਲਈ, ਇਹ ਗਿੱਟ ਪ੍ਰਾਈਮਿਟਿਵ (ਗਿੱਟ ਬ੍ਰਾਂਚ, ਗਿੱਟ ਟੈਗ...) ਨਹੀਂ ਹੈ ਜੋ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਇਸ ਨਾਲ ਜੁੜਿਆ ਇੱਕ ਚੈੱਕਸਮ ਹੈ:

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

ਅਜਿਹਾ ਪਛਾਣਕਰਤਾ ਟੈਗ ਅਖੌਤੀ ਹੈ ਚਿੱਤਰ ਪੜਾਅ ਦਸਤਖਤ.

ਹਰੇਕ ਚਿੱਤਰ ਵਿੱਚ ਪੜਾਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੁੰਦਾ ਹੈ: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ਆਦਿ ਹਰੇਕ ਪੜਾਅ ਦਾ ਇੱਕ ਪਛਾਣਕਰਤਾ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸਦੀ ਸਮੱਗਰੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ - ਪੜਾਅ ਦੇ ਦਸਤਖਤ (ਸਟੇਜ ਹਸਤਾਖਰ).

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

ਸੰਰਚਨਾ ਤੋਂ ਹਰੇਕ ਚਿੱਤਰ ਲਈ werf.yaml ਆਮ ਸਥਿਤੀ ਵਿੱਚ, ਇਸਦੇ ਆਪਣੇ ਦਸਤਖਤ ਹੋਣਗੇ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਡੌਕਰ ਟੈਗ ਹੋਵੇਗਾ।

ਸਟੇਜ ਹਸਤਾਖਰ ਇਹਨਾਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ:

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

ਇਹ ਹੁਣ ਸਿਫਾਰਸ਼ੀ ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਹੈ ਅਤੇ ਸਾਰੇ CI ਸਿਸਟਮਾਂ ਲਈ werf ਵਿੱਚ ਡਿਫਾਲਟ ਹੈ।

ਵਰਫ ਵਿੱਚ ਕਿਵੇਂ ਸਮਰੱਥ ਅਤੇ ਵਰਤਣਾ ਹੈ

ਕਮਾਂਡ ਕੋਲ ਹੁਣ ਇੱਕ ਅਨੁਸਾਰੀ ਵਿਕਲਪ ਹੈ werf publish: --tag-by-stages-signature=true|false

ਇੱਕ CI ਸਿਸਟਮ ਵਿੱਚ, ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਕਮਾਂਡ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ werf ci-env. ਪਹਿਲਾਂ, ਇਸਦੇ ਲਈ ਪੈਰਾਮੀਟਰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ werf ci-env --tagging-strategy=tag-or-branch. ਹੁਣ, ਜੇ ਤੁਸੀਂ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹੋ werf ci-env --tagging-strategy=stages-signature ਜਾਂ ਇਸ ਵਿਕਲਪ ਨੂੰ ਨਿਰਧਾਰਤ ਨਾ ਕਰੋ, werf ਮੂਲ ਰੂਪ ਵਿੱਚ ਟੈਗਿੰਗ ਰਣਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ stages-signature. ਟੀਮ werf ci-env ਕਮਾਂਡ ਲਈ ਆਪਣੇ ਆਪ ਹੀ ਲੋੜੀਂਦੇ ਫਲੈਗ ਸੈੱਟ ਕਰ ਦੇਵੇਗਾ werf build-and-publish (ਜ werf publish), ਇਸਲਈ ਇਹਨਾਂ ਕਮਾਂਡਾਂ ਲਈ ਕੋਈ ਵਾਧੂ ਵਿਕਲਪ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਕਮਾਂਡ:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... ਹੇਠ ਲਿਖੀਆਂ ਤਸਵੀਰਾਂ ਬਣਾ ਸਕਦਾ ਹੈ:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

ਇਹ ਇਸ ਲਈ ਹੈ 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ਚਿੱਤਰ ਦੇ ਪੜਾਵਾਂ ਦਾ ਇੱਕ ਦਸਤਖਤ ਹੈ backendਅਤੇ f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - ਚਿੱਤਰ ਪੜਾਵਾਂ ਦੇ ਦਸਤਖਤ frontend.

ਵਿਸ਼ੇਸ਼ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ werf_container_image и werf_container_env ਹੈਲਮ ਟੈਂਪਲੇਟਸ ਵਿੱਚ ਕੁਝ ਵੀ ਬਦਲਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ: ਇਹ ਫੰਕਸ਼ਨ ਆਪਣੇ ਆਪ ਸਹੀ ਚਿੱਤਰ ਨਾਮ ਤਿਆਰ ਕਰਨਗੇ।

ਇੱਕ CI ਸਿਸਟਮ ਵਿੱਚ ਉਦਾਹਰਨ ਸੰਰਚਨਾ:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

ਸੰਰਚਨਾ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਉਪਲਬਧ ਹੈ:

• ਡਾਇਰੈਕਟਰੀ → ਪ੍ਰਕਾਸ਼ਨ (ਪ੍ਰਕਾਸ਼ਿਤ);
• CI/CD ਨਾਲ ਕੰਮ ਕਰਨਾ → ਆਮ ਜਾਣਕਾਰੀ → ਪੜਾਅ-ਦਸਤਖਤ;
• GitLab CI/CD → .gitlab-ci.yml ਨਾਲ ਏਕੀਕਰਣ.

ਕੁੱਲ

• ਨਵਾਂ ਵਿਕਲਪ werf publish --tag-by-stages-signature=true|false.
• ਨਵਾਂ ਵਿਕਲਪ ਮੁੱਲ werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ਜੇ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਡਿਫਾਲਟ ਹੋਵੇਗਾ stages-signature).
• ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਗਿੱਟ ਕਮਿਟ ਲਈ ਟੈਗਿੰਗ ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ (WERF_TAG_GIT_COMMIT ਜਾਂ ਵਿਕਲਪ werf publish --tag-git-commit COMMIT), ਫਿਰ ਟੈਗਿੰਗ ਰਣਨੀਤੀ 'ਤੇ ਸਵਿਚ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਓ ਪੜਾਅ - ਦਸਤਖਤ.
• ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਤੁਰੰਤ ਨਵੀਂ ਟੈਗਿੰਗ ਸਕੀਮ ਵਿੱਚ ਬਦਲਣਾ ਬਿਹਤਰ ਹੈ।
• werf 1.1 ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਸਮੇਂ, ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਨਵੀਂ ਟੈਗਿੰਗ ਸਕੀਮ ਵਿੱਚ ਬਦਲਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਪੁਰਾਣੇ ਟੈਗ-ਜਾਂ-ਸ਼ਾਖਾ ਅਜੇ ਵੀ ਸਮਰਥਿਤ ਹੈ।

ਸਮੱਗਰੀ-ਆਧਾਰਿਤ ਟੈਗਿੰਗ ਲੇਖ ਵਿੱਚ ਸ਼ਾਮਲ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ:

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

ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ! ਅਤੇ 'ਤੇ ਸਾਨੂੰ ਮਿਲਣ ਲਈ ਨਾ ਭੁੱਲੋ GitHubਕੋਈ ਮੁੱਦਾ ਬਣਾਉਣ ਜਾਂ ਮੌਜੂਦਾ ਨੂੰ ਲੱਭਣ ਲਈ, ਇੱਕ ਪਲੱਸ ਜੋੜੋ, ਇੱਕ PR ਬਣਾਓ ਜਾਂ ਸਿਰਫ਼ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਨੂੰ ਦੇਖੋ।

PS

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

• «werf 1.1 ਰੀਲੀਜ਼: ਅੱਜ ਬਿਲਡਰ ਲਈ ਸੁਧਾਰ ਅਤੇ ਭਵਿੱਖ ਲਈ ਯੋਜਨਾਵਾਂ»
• «ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ werf 1.0 ਸਥਿਰ: GitOps ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ, ਸਥਿਤੀ ਅਤੇ ਯੋਜਨਾਵਾਂ»
• «werf - ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI / CD ਲਈ ਸਾਡਾ ਟੂਲ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• werf ਵਿੱਚ ਨਵੀਨਤਾਵਾਂ ਬਾਰੇ ਨੋਟਸ ਦੀ ਇੱਕ ਲੜੀ:
  • «3-ਵੇਅ ਮਰਜ ਟੂ ਵਰਫ: ਹੈਲਮ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਦੀ ਤੈਨਾਤੀ “ਸਟੀਰੌਇਡਜ਼ ਉੱਤੇ”";
  • «ਗੁੰਝਲਦਾਰ ਹੈਲਮ ਚਾਰਟ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਲਈ werf ਦੀ ਵਰਤੋਂ ਕਰਨਾ";
  • «ਵਰਫ ਵਿੱਚ ਮੋਨੋਰੇਪੋ ਅਤੇ ਮਲਟੀਰੇਪੋ ਲਈ ਸਮਰਥਨ ਅਤੇ ਡੌਕਰ ਰਜਿਸਟਰੀ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ";
  • «ਤੁਸੀਂ ਹੁਣ ਇੱਕ ਨਿਯਮਤ ਡੌਕਰਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਵਰਫ ਵਿੱਚ ਬਣਾ ਸਕਦੇ ਹੋ".

ਸਰੋਤ: www.habr.com