werf - ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI / CD ਲਈ ਸਾਡਾ ਟੂਲ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)

ਤਿਉਹਾਰ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਆਯੋਜਿਤ DevOpsConf 27 ਕਾਨਫਰੰਸ ਦੇ ਮੁੱਖ ਹਾਲ ਵਿੱਚ 2019 ਮਈ RIT++ 2019, "ਨਿਰੰਤਰ ਸਪੁਰਦਗੀ" ਭਾਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਇੱਕ ਰਿਪੋਰਟ ਦਿੱਤੀ ਗਈ ਸੀ "werf - Kubernetes ਵਿੱਚ CI/CD ਲਈ ਸਾਡਾ ਟੂਲ"। ਇਹ ਉਹਨਾਂ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਚੁਣੌਤੀਆਂ ਜਿਨ੍ਹਾਂ ਦਾ ਹਰ ਕੋਈ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੁਬਰਨੇਟਸ ਨੂੰ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਸੂਖਮਤਾਵਾਂ ਬਾਰੇ ਜੋ ਸ਼ਾਇਦ ਤੁਰੰਤ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਾ ਹੋਣ। ਸੰਭਾਵਿਤ ਹੱਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਦਿਖਾਉਂਦੇ ਹਾਂ ਕਿ ਇਹ ਇੱਕ ਓਪਨ ਸੋਰਸ ਟੂਲ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ werf.

ਪੇਸ਼ਕਾਰੀ ਤੋਂ ਲੈ ਕੇ, ਸਾਡੀ ਉਪਯੋਗਤਾ (ਪਹਿਲਾਂ ਡੈਪ ਵਜੋਂ ਜਾਣੀ ਜਾਂਦੀ ਸੀ) ਦੇ ਇਤਿਹਾਸਕ ਮੀਲਪੱਥਰ 'ਤੇ ਪਹੁੰਚ ਗਈ ਹੈ GitHub 'ਤੇ 1000 ਤਾਰੇ — ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਇਸਦਾ ਉਪਭੋਗਤਾਵਾਂ ਦਾ ਵਧ ਰਿਹਾ ਭਾਈਚਾਰਾ ਬਹੁਤ ਸਾਰੇ DevOps ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਜੀਵਨ ਨੂੰ ਆਸਾਨ ਬਣਾ ਦੇਵੇਗਾ।

ਇਸ ਲਈ, ਆਓ ਪੇਸ਼ ਕਰੀਏ ਰਿਪੋਰਟ ਦੀ ਵੀਡੀਓ (~ 47 ਮਿੰਟ, ਲੇਖ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਾਣਕਾਰੀ ਭਰਪੂਰ) ਅਤੇ ਟੈਕਸਟ ਦੇ ਰੂਪ ਵਿੱਚ ਇਸਦਾ ਮੁੱਖ ਐਬਸਟਰੈਕਟ। ਜਾਣਾ!

ਕੁਬਰਨੇਟਸ ਨੂੰ ਕੋਡ ਡਿਲੀਵਰ ਕਰਨਾ

ਗੱਲ ਹੁਣ werf ਬਾਰੇ ਨਹੀਂ ਹੋਵੇਗੀ, ਪਰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI/CD ਬਾਰੇ ਹੋਵੇਗੀ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਕਿ ਸਾਡਾ ਸੌਫਟਵੇਅਰ ਡੌਕਰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਪੈਕ ਕੀਤਾ ਗਿਆ ਹੈ। (ਮੈਂ ਇਸ ਬਾਰੇ ਵਿੱਚ ਗੱਲ ਕੀਤੀ ਸੀ 2016 ਦੀ ਰਿਪੋਰਟ), ਅਤੇ K8s ਦੀ ਵਰਤੋਂ ਇਸਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਚਲਾਉਣ ਲਈ ਕੀਤੀ ਜਾਵੇਗੀ (ਇਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਵਿੱਚ 2017 ਸਾਲ).

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਡਿਲੀਵਰੀ ਕਿਹੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ?

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

ਇੱਥੇ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਨੋਟਸ ਹਨ:

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

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

ਸਟੇਜ ਬਣਾਓ

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ 2019 ਵਿੱਚ ਡੌਕਰ ਚਿੱਤਰ ਬਣਾਉਣ ਬਾਰੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਡੌਕਰਫਾਈਲਾਂ ਨੂੰ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ ਅਤੇ ਚਲਾਉਣਾ ਹੈ docker build?.. ਇੱਥੇ ਉਹ ਬਾਰੀਕੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵੱਲ ਮੈਂ ਧਿਆਨ ਦੇਣਾ ਚਾਹਾਂਗਾ:

1. ਚਿੱਤਰ ਦਾ ਭਾਰ ਮਾਮਲੇ, ਇਸ ਲਈ ਵਰਤੋ ਬਹੁ-ਪੜਾਅਚਿੱਤਰ ਵਿੱਚ ਸਿਰਫ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਛੱਡਣ ਲਈ ਜੋ ਓਪਰੇਸ਼ਨ ਲਈ ਅਸਲ ਵਿੱਚ ਜ਼ਰੂਰੀ ਹੈ.
2. ਲੇਅਰਾਂ ਦੀ ਸੰਖਿਆ ਦੀਆਂ ਚੇਨਾਂ ਨੂੰ ਜੋੜ ਕੇ ਘੱਟ ਤੋਂ ਘੱਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ RUN- ਅਰਥ ਦੇ ਅਨੁਸਾਰ ਹੁਕਮ.
3. ਹਾਲਾਂਕਿ, ਇਹ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ ਡੀਬੱਗਿੰਗ, ਕਿਉਂਕਿ ਜਦੋਂ ਅਸੈਂਬਲੀ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸ ਚੇਨ ਤੋਂ ਸਹੀ ਕਮਾਂਡ ਲੱਭਣੀ ਪਵੇਗੀ ਜਿਸ ਨਾਲ ਸਮੱਸਿਆ ਪੈਦਾ ਹੋਈ।
4. ਅਸੈਂਬਲੀ ਦੀ ਗਤੀ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂਕਿ ਅਸੀਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲ ਆਊਟ ਕਰਨਾ ਅਤੇ ਨਤੀਜੇ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਭਾਸ਼ਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਨਿਰਭਰਤਾ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ।
5. ਅਕਸਰ ਇੱਕ Git ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ ਬਹੁਤ ਸਾਰੇ ਚਿੱਤਰ, ਜਿਸ ਨੂੰ ਡੌਕਰਫਾਈਲਾਂ ਦੇ ਇੱਕ ਸਮੂਹ (ਜਾਂ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਨਾਮ ਦਿੱਤੇ ਪੜਾਅ) ਅਤੇ ਉਹਨਾਂ ਦੇ ਕ੍ਰਮਵਾਰ ਅਸੈਂਬਲੀ ਨਾਲ ਇੱਕ Bash ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਹ ਆਈਸਬਰਗ ਦਾ ਸਿਰਫ ਸਿਰਾ ਸੀ ਜਿਸਦਾ ਹਰ ਕੋਈ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ. ਪਰ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ:

1. ਅਕਸਰ ਅਸੈਂਬਲੀ ਦੇ ਪੜਾਅ 'ਤੇ ਸਾਨੂੰ ਕੁਝ ਚਾਹੀਦਾ ਹੈ ਮਾਊਂਟ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਤੀਜੀ-ਧਿਰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ apt ਵਰਗੇ ਕਮਾਂਡ ਦੇ ਨਤੀਜੇ ਨੂੰ ਕੈਸ਼ ਕਰੋ)।
2. ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ Ansimate ਸ਼ੈੱਲ ਵਿੱਚ ਲਿਖਣ ਦੀ ਬਜਾਏ.
3. ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਡੌਕਰ ਤੋਂ ਬਿਨਾਂ ਬਣਾਓ (ਸਾਨੂੰ ਇੱਕ ਵਾਧੂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਕਿਉਂ ਲੋੜ ਹੈ ਜਿਸ ਵਿੱਚ ਸਾਨੂੰ ਇਸ ਲਈ ਸਭ ਕੁਝ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਕੰਟੇਨਰ ਚਲਾ ਸਕਦੇ ਹਾਂ?)
4. ਸਮਾਨਾਂਤਰ ਅਸੈਂਬਲੀ, ਜਿਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ: ਡੌਕਰਫਾਈਲ ਤੋਂ ਵੱਖ-ਵੱਖ ਕਮਾਂਡਾਂ (ਜੇ ਮਲਟੀ-ਸਟੇਜ ਵਰਤੀ ਜਾਂਦੀ ਹੈ), ਇੱਕੋ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਕਈ ਕਮਿਟ, ਕਈ ਡੌਕਰਫਾਈਲਾਂ।
5. ਵੰਡੀ ਵਿਧਾਨ ਸਭਾ: ਅਸੀਂ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਪੌਡਾਂ ਵਿੱਚ ਇਕੱਠਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ "ਅਕਾਲਿਕ" ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦਾ ਕੈਸ਼ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
6. ਅੰਤ ਵਿੱਚ, ਮੈਂ ਇੱਛਾਵਾਂ ਦੇ ਸਿਖਰ ਦਾ ਨਾਮ ਦਿੱਤਾ ਆਟੋਮੈਜਿਕ: ਰਿਪੋਜ਼ਟਰੀ 'ਤੇ ਜਾਣਾ, ਕੁਝ ਕਮਾਂਡ ਟਾਈਪ ਕਰਨਾ ਅਤੇ ਇੱਕ ਤਿਆਰ ਚਿੱਤਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਆਦਰਸ਼ ਹੋਵੇਗਾ, ਇਸ ਗੱਲ ਦੀ ਸਮਝ ਨਾਲ ਕਿ ਕਿਵੇਂ ਅਤੇ ਕੀ ਸਹੀ ਢੰਗ ਨਾਲ ਕਰਨਾ ਹੈ। ਹਾਲਾਂਕਿ, ਮੈਨੂੰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਸਾਰੀਆਂ ਸੂਖਮਤਾਵਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ.

ਅਤੇ ਇੱਥੇ ਪ੍ਰੋਜੈਕਟ ਹਨ:

• ਮੋਬੀ/ਬਿਲਡਕਿੱਟ - ਡੌਕਰ ਇੰਕ ਦਾ ਇੱਕ ਬਿਲਡਰ (ਪਹਿਲਾਂ ਹੀ ਡੌਕਰ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ), ਜੋ ਇਹਨਾਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ;
• ਕਨੀਕੋ - ਗੂਗਲ ਤੋਂ ਇੱਕ ਬਿਲਡਰ ਜੋ ਤੁਹਾਨੂੰ ਡੌਕਰ ਤੋਂ ਬਿਨਾਂ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ;
• Buildpacks.io - CNCF ਦੀ ਆਟੋਮੈਟਿਕ ਜਾਦੂ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਅਤੇ, ਖਾਸ ਤੌਰ 'ਤੇ, ਲੇਅਰਾਂ ਲਈ ਰੀਬੇਸ ਦੇ ਨਾਲ ਇੱਕ ਦਿਲਚਸਪ ਹੱਲ;
• ਅਤੇ ਹੋਰ ਉਪਯੋਗਤਾਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ, ਜਿਵੇਂ ਕਿ ਬਿਲਡਾਹ, genuinetools/img...

...ਅਤੇ ਦੇਖੋ GitHub 'ਤੇ ਉਨ੍ਹਾਂ ਦੇ ਕਿੰਨੇ ਤਾਰੇ ਹਨ। ਯਾਨੀ ਇੱਕ ਪਾਸੇ, docker build ਮੌਜੂਦ ਹੈ ਅਤੇ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਮੁੱਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਨਹੀਂ ਹੋਇਆ ਹੈ - ਇਸਦਾ ਸਬੂਤ ਵਿਕਲਪਕ ਕੁਲੈਕਟਰਾਂ ਦਾ ਸਮਾਨਾਂਤਰ ਵਿਕਾਸ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕੁਝ ਹਿੱਸੇ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।

werf ਵਿੱਚ ਅਸੈਂਬਲੀ

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

ਨੀਲੇ ਵਿੱਚ ਰੰਗਤ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਸਮਾਨਾਂਤਰ ਬਿਲਡ ਉਸੇ ਮੇਜ਼ਬਾਨ ਦੇ ਅੰਦਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਪੀਲੇ ਵਿੱਚ ਉਜਾਗਰ ਕੀਤੇ ਗਏ ਮੁੱਦਿਆਂ ਨੂੰ ਗਰਮੀਆਂ ਦੇ ਅੰਤ ਤੱਕ ਪੂਰਾ ਕਰਨ ਦੀ ਯੋਜਨਾ ਹੈ.

ਰਜਿਸਟਰੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਨ ਦਾ ਪੜਾਅ (ਪ੍ਰਕਾਸ਼ਿਤ)

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

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

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

ਟੈਗਿੰਗ ਰਣਨੀਤੀਆਂ

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

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

ਦੂਜਾ ਵਿਕਲਪ ਹੈ git ਕਮਿਟ + ਟੈਗ. ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਦਾ ਇੱਕ ਟੈਗ ਹੈ 1.0; ਰਜਿਸਟਰੀ ਵਿੱਚ ਇਸਦੇ ਲਈ - ਉਤਪਾਦਨ ਵਿੱਚ ਤੈਨਾਤ ਇੱਕ ਚਿੱਤਰ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਪ੍ਰੀਵਿਊ ਅਤੇ ਸਟੇਜਿੰਗ ਰੂਪ ਹਨ। ਅੱਗੇ ਅਸੀਂ ਗਿੱਟਫਲੋ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਾਂ: ਵਿਕਾਸ ਲਈ ਮੁੱਖ ਸ਼ਾਖਾ ਵਿੱਚ (develop) ਅਸੀਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਣਾਉਂਦੇ ਹਾਂ, ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਪਛਾਣਕਰਤਾ ਨਾਲ ਇੱਕ ਵਚਨਬੱਧਤਾ ਹੁੰਦੀ ਹੈ #c1. ਅਸੀਂ ਇਸਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸ ਪਛਾਣਕਰਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਨੂੰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ (#c1). ਉਸੇ ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਲ ਅਸੀਂ ਪ੍ਰੀਵਿਊ ਲਈ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਕਮਿਟਾਂ ਨਾਲ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰਦੇ ਹਾਂ #c2 и #c3.

ਜਦੋਂ ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਇੱਥੇ ਕਾਫ਼ੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਅਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਥਿਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ. Git ਵਿੱਚ ਇੱਕ ਸ਼ਾਖਾ ਬਣਾਓ release_1.1 (ਬੇਸ 'ਤੇ #c3 ਤੱਕ develop). ਇਸ ਰੀਲੀਜ਼ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ... ਇਹ ਪਿਛਲੇ ਪੜਾਅ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ. ਇਸ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਸਟੇਜਿੰਗ ਲਈ ਰੋਲ ਆਊਟ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਵਿੱਚ ਬੱਗ ਠੀਕ ਕਰਦੇ ਹਾਂ #c4 ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਸਟੇਜਿੰਗ ਲਈ ਰੋਲ ਆਊਟ ਕਰੋ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਵਿੱਚ ਵਿਕਾਸ ਚੱਲ ਰਿਹਾ ਹੈ develop, ਜਿੱਥੋਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ release_1.1. ਕਿਸੇ ਸਮੇਂ, ਸਾਨੂੰ ਇੱਕ ਕਮਿਟ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਟੇਜਿੰਗ ਲਈ ਅਪਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਖੁਸ਼ ਹਾਂ (#c25).

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

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

ਅਸਲ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਮਰਜ ਕਮਿਟ ਲਈ ਕੋਈ ਸਮਰਥਨ ਨਹੀਂ ਹੈ, ਤੁਹਾਨੂੰ ਫਾਸਟ-ਫਾਰਵਰਡ ਕਰਨਾ ਪਵੇਗਾ।

ਅਸੀਂ ਹੋਰ ਅੱਗੇ ਜਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇੱਕ ਚਾਲ ਕਰ ਸਕਦੇ ਹਾਂ... ਆਓ ਇੱਕ ਸਧਾਰਨ ਡੌਕਰਫਾਈਲ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵੇਖੀਏ:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ਆਓ ਹੇਠਾਂ ਦਿੱਤੇ ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ ਇਸ ਤੋਂ ਇੱਕ ਫਾਈਲ ਬਣਾਈਏ:

• ਵਰਤੇ ਗਏ ਚਿੱਤਰਾਂ ਦੇ ਪਛਾਣਕਰਤਾਵਾਂ ਤੋਂ SHA256 (ruby:2.3 и nginx:alpine), ਜੋ ਕਿ ਉਹਨਾਂ ਦੀ ਸਮੱਗਰੀ ਦੇ ਚੈੱਕਸਮ ਹਨ;
• ਸਾਰੀਆਂ ਟੀਮਾਂ (RUN, CMD ਇਤਆਦਿ.);
• SHA256 ਫਾਈਲਾਂ ਤੋਂ ਜੋ ਜੋੜੀਆਂ ਗਈਆਂ ਸਨ।

... ਅਤੇ ਅਜਿਹੀ ਫਾਈਲ ਤੋਂ ਚੈੱਕਸਮ (ਦੁਬਾਰਾ SHA256) ਲਓ। ਇਹ ਦਸਤਖਤ ਹਰ ਚੀਜ਼ ਜੋ ਡੌਕਰ ਚਿੱਤਰ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਪਰਿਭਾਸ਼ਤ ਕਰਦੀ ਹੈ.

ਆਉ ਡਾਇਗ੍ਰਾਮ ਤੇ ਵਾਪਸ ਚਲੀਏ ਅਤੇ ਕਮਿਟਸ ਦੀ ਬਜਾਏ ਅਸੀਂ ਅਜਿਹੇ ਦਸਤਖਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ, i.e. ਦਸਤਖਤਾਂ ਨਾਲ ਚਿੱਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰੋ।

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

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

werf ਵਿੱਚ ਟੈਗਿੰਗ

werf ਵਿੱਚ ਅਸੀਂ ਹੋਰ ਵੀ ਅੱਗੇ ਚਲੇ ਗਏ ਅਤੇ ਇੱਕ ਕੈਸ਼ ਦੇ ਨਾਲ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਬਿਲਡ ਕਰਨ ਦੀ ਤਿਆਰੀ ਕਰ ਰਹੇ ਹਾਂ ਜੋ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ... ਇਸ ਲਈ, ਅਸੀਂ ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਡੌਕਰ ਚਿੱਤਰ ਬਣਾ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਹਿੰਦੇ ਹਾਂ ਪੜਾਅ и ਚਿੱਤਰ ਨੂੰ.

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

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

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

ਰਜਿਸਟਰੀ ਦੀ ਸਫਾਈ

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

ਸਫਾਈ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਕੀ ਹਨ?

1. ਤੁਸੀਂ ਬਸ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸਾਫ਼ ਨਾ ਕਰੋ. ਕਈ ਵਾਰ ਟੈਗਸ ਦੀ ਇੱਕ ਵੱਡੀ ਉਲਝਣ ਨੂੰ ਖੋਲ੍ਹਣ ਨਾਲੋਂ ਵਾਧੂ ਥਾਂ ਲਈ ਥੋੜ੍ਹਾ ਜਿਹਾ ਭੁਗਤਾਨ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਪਰ ਇਹ ਸਿਰਫ ਇੱਕ ਖਾਸ ਬਿੰਦੂ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ.
2. ਪੂਰਾ ਰੀਸੈਟ. ਜੇਕਰ ਤੁਸੀਂ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹੋ ਅਤੇ CI ਸਿਸਟਮ ਵਿੱਚ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਚਿੱਤਰਾਂ ਨੂੰ ਹੀ ਮੁੜ-ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਮੱਸਿਆ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਕੰਟੇਨਰ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੇ ਲਈ ਇੱਕ ਨਵਾਂ ਚਿੱਤਰ ਲੋਡ ਕੀਤਾ ਜਾਵੇਗਾ - ਇੱਕ ਜਿਸਦੀ ਅਜੇ ਤੱਕ ਕਿਸੇ ਦੁਆਰਾ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ। ਇਹ ਅਟੱਲ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਵਿਚਾਰ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ।
3. ਨੀਲਾ-ਹਰਾ. ਇੱਕ ਰਜਿਸਟਰੀ ਓਵਰਫਲੋ ਹੋਣ ਲੱਗੀ - ਅਸੀਂ ਚਿੱਤਰਾਂ ਨੂੰ ਦੂਜੀ 'ਤੇ ਅੱਪਲੋਡ ਕਰਦੇ ਹਾਂ। ਪਿਛਲੀ ਵਿਧੀ ਵਾਂਗ ਉਹੀ ਸਮੱਸਿਆ: ਤੁਸੀਂ ਕਿਸ ਬਿੰਦੂ 'ਤੇ ਰਜਿਸਟਰੀ ਨੂੰ ਸਾਫ਼ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਓਵਰਫਲੋ ਸ਼ੁਰੂ ਹੋ ਗਈ ਹੈ?
4. ਸਮੇਂ ਦੇ ਨਾਲ. ਕੀ 1 ਮਹੀਨੇ ਤੋਂ ਪੁਰਾਣੀਆਂ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਮਿਟਾਉਣਾ ਹੈ? ਪਰ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਅਜਿਹੀ ਸੇਵਾ ਹੋਵੇਗੀ ਜੋ ਇਕ ਮਹੀਨੇ ਤੋਂ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ ...
5. ਹੱਥ ਨਾਲ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਪਹਿਲਾਂ ਹੀ ਮਿਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

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

ਅਸੀਂ ਕੀ ਕਰਨ ਆਏ ਹਾਂ werf? ਅਸੀਂ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ:

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

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

ਸਟੇਜ ਤੈਨਾਤ ਕਰੋ

ਭਰੋਸੇਯੋਗ ਘੋਸ਼ਣਾਯੋਗਤਾ

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

1. ਪਛਾਣਕਰਤਾ;
2. ਸੇਵਾ ਜਾਣਕਾਰੀ;
3. ਬਹੁਤ ਸਾਰੇ ਮੂਲ ਮੁੱਲ;
4. ਮੌਜੂਦਾ ਸਥਿਤੀ ਵਾਲਾ ਭਾਗ;
5. ਦਾਖਲਾ ਵੈਬਹੁੱਕ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ;
6. ਵੱਖ-ਵੱਖ ਕੰਟਰੋਲਰਾਂ (ਅਤੇ ਸ਼ਡਿਊਲਰ) ਦੇ ਕੰਮ ਦਾ ਨਤੀਜਾ।

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

ਇਸ ਪਹੁੰਚ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ 2-ਤਰੀਕੇ ਨਾਲ ਮਿਲਾਉਣਾ. ਇਹ ਹੈਲਮ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ.

ਵੀ ਹੈ 3-ਤਰੀਕੇ ਨਾਲ ਮਿਲਾਉਣਾ, ਜੋ ਕਿ ਇਸ ਵਿੱਚ ਵੱਖਰਾ ਹੈ:

• ਤੁਲਨਾ ਆਖਰੀ-ਲਾਗੂ ਕੀਤਾ и ਨ੍ਯੂ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕੀ ਮਿਟਾਇਆ ਗਿਆ ਸੀ;
• ਤੁਲਨਾ ਨ੍ਯੂ и ਸਿੱਧਾ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕੀ ਜੋੜਿਆ ਜਾਂ ਬਦਲਿਆ ਗਿਆ ਹੈ;
• ਸੰਖੇਪ ਪੈਚ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਸਿੱਧਾ.

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

ਅਸਲ ਰੋਲਆਉਟ ਸਥਿਤੀ

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

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

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

werf ਪੱਧਰ 'ਤੇ ਇਸ ਟਰੈਕਰ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਐਨੋਟੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਡਿਪਲਾਇਮੈਂਟਸ ਜਾਂ ਸਟੇਟਫੁਲਸੈਟਸ 'ਤੇ ਰੱਖੇ ਗਏ ਹਨ। ਮੁੱਖ ਵਿਆਖਿਆ - fail-mode - ਹੇਠ ਲਿਖੇ ਅਰਥਾਂ ਨੂੰ ਸਮਝਦਾ ਹੈ:

• IgnoreAndContinueDeployProcess - ਅਸੀਂ ਇਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਾਂ ਅਤੇ ਤੈਨਾਤੀ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ;
• FailWholeDeployProcessImmediately — ਇਸ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਡਿਪਲਾਇਮੈਂਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕਦੀ ਹੈ;
• HopeUntilEndOfDeployProcess — ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਕੰਪੋਨੈਂਟ ਤੈਨਾਤੀ ਦੇ ਅੰਤ ਤੱਕ ਕੰਮ ਕਰੇਗਾ।

ਉਦਾਹਰਨ ਲਈ, ਸਰੋਤਾਂ ਅਤੇ ਐਨੋਟੇਸ਼ਨ ਮੁੱਲਾਂ ਦਾ ਇਹ ਸੁਮੇਲ fail-mode:

ਜਦੋਂ ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ (MongoDB) ਅਜੇ ਤਿਆਰ ਨਾ ਹੋਵੇ - ਤੈਨਾਤੀਆਂ ਅਸਫਲ ਹੋ ਜਾਣਗੀਆਂ। ਪਰ ਤੁਸੀਂ ਇਸਦੇ ਸ਼ੁਰੂ ਹੋਣ ਲਈ ਪਲ ਦੀ ਉਡੀਕ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੈਨਾਤੀ ਅਜੇ ਵੀ ਹੋਵੇਗੀ।

ਵਰਫ ਵਿੱਚ ਕੁਬੇਡੋਗ ਲਈ ਦੋ ਹੋਰ ਐਨੋਟੇਸ਼ਨ ਹਨ:

• failures-allowed-per-replica - ਹਰੇਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਮਨਜ਼ੂਰ ਫਾਲਸ ਦੀ ਗਿਣਤੀ;
• show-logs-until — ਉਸ ਪਲ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕਿ ਸਾਰੇ ਰੋਲ ਆਊਟ ਪੌਡਾਂ ਤੋਂ werf (stdout ਵਿੱਚ) ਲੌਗ ਨਹੀਂ ਦਿਖਾਉਂਦਾ। ਡਿਫਾਲਟ ਹੈ PodIsReady (ਸੁਨੇਹਿਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਜੋ ਅਸੀਂ ਸ਼ਾਇਦ ਨਹੀਂ ਚਾਹੁੰਦੇ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਪੌਡ 'ਤੇ ਆਉਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇ), ਪਰ ਮੁੱਲ ਵੀ ਵੈਧ ਹਨ: ControllerIsReady и EndOfDeploy.

ਅਸੀਂ ਤਾਇਨਾਤੀ ਤੋਂ ਹੋਰ ਕੀ ਚਾਹੁੰਦੇ ਹਾਂ?

ਪਹਿਲਾਂ ਹੀ ਵਰਣਿਤ ਦੋ ਬਿੰਦੂਆਂ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ:

• ਦੇਖਣ ਲਈ ਲੌਗ - ਅਤੇ ਸਿਰਫ ਲੋੜੀਂਦੇ, ਅਤੇ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਸਭ ਕੁਝ ਨਹੀਂ;
• ਟਰੈਕ ਪ੍ਰਗਤੀ, ਕਿਉਂਕਿ ਜੇ ਕੰਮ "ਚੁੱਪ" ਕਈ ਮਿੰਟਾਂ ਲਈ ਲਟਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ;
• иметь ਆਟੋਮੈਟਿਕ ਰੋਲਬੈਕ ਜੇਕਰ ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ ਹੈ (ਅਤੇ ਇਸ ਲਈ ਤੈਨਾਤੀ ਦੀ ਅਸਲ ਸਥਿਤੀ ਨੂੰ ਜਾਣਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ)। ਰੋਲਆਉਟ ਪਰਮਾਣੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਜਾਂ ਤਾਂ ਇਹ ਅੰਤ ਤੱਕ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਹਰ ਚੀਜ਼ ਆਪਣੀ ਪਿਛਲੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਆਉਂਦੀ ਹੈ।

ਨਤੀਜੇ

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

ਕਿਸੇ ਸਿੱਟੇ ਦੀ ਬਜਾਏ:

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

ਵੀਡੀਓਜ਼ ਅਤੇ ਸਲਾਈਡਾਂ

ਪ੍ਰਦਰਸ਼ਨ ਤੋਂ ਵੀਡੀਓ (~47 ਮਿੰਟ):

ਰਿਪੋਰਟ ਦੀ ਪੇਸ਼ਕਾਰੀ:

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਕੁਬਰਨੇਟਸ ਬਾਰੇ ਹੋਰ ਰਿਪੋਰਟਾਂ:

• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; 27 ਅਪ੍ਰੈਲ, 2019 “ਸਟਰਾਈਕ” ਉੱਤੇ);
• «ਕੁਬਰਨੇਟਸ ਨੂੰ ਵਧਾਉਣਾ ਅਤੇ ਪੂਰਕ ਕਰਨਾ» (ਐਂਡਰੀ ਪੋਲੋਵੋਵ; ਸੇਂਟ ਹਾਈਲੋਡ++ 'ਤੇ 8 ਅਪ੍ਰੈਲ, 2019);
• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਹਾਈਲੋਡ++ 'ਤੇ 8 ਨਵੰਬਰ, 2018);
• «ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 28 ਮਈ, 2018);
• «ਕੁਬਰਨੇਟਸ ਅਤੇ ਗਿਟਲੈਬ ਦੇ ਨਾਲ CI/CD ਵਧੀਆ ਅਭਿਆਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਹਾਈਲੋਡ++ 'ਤੇ 7 ਨਵੰਬਰ, 2017);
• «ਛੋਟੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਨਾਲ ਸਾਡਾ ਅਨੁਭਵ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 6 ਜੂਨ, 2017).

ਸਰੋਤ: www.habr.com