🥇GitOps: ਪੁੱਲ ਅਤੇ ਪੁਸ਼ ਵਿਧੀਆਂ ਦੀ ਤੁਲਨਾ

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

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

ਇਸ ਪਹੁੰਚ ਦੇ ਮੁੱਖ ਫਾਇਦੇ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹਨ::

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

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

ਤੈਨਾਤੀ ਢੰਗ

ਹਾਲ ਹੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਤੈਨਾਤੀ ਲਈ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਅਤੇ ਸਾਧਨ ਸਥਾਪਿਤ ਹੋ ਗਏ ਹਨ:

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

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

ਖਿੱਚੋ ਅਤੇ ਧੱਕੋ

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

NB! GitOps ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਸਾਰੇ ਲਾਭ ਦੋਵਾਂ ਤਰੀਕਿਆਂ ਲਈ ਇੱਕੋ ਜਿਹੇ ਰਹਿੰਦੇ ਹਨ.

ਖਿੱਚ ਆਧਾਰਿਤ ਪਹੁੰਚ

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

ਪ੍ਰੋ:

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

Минусы:

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

ਪੁਸ਼ ਆਧਾਰਿਤ ਪਹੁੰਚ

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

Плюсы:

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

Минусы:

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

ਨਤੀਜੇ: ਪੁਸ਼ ਜਾਂ ਪੁੱਲ?

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

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

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

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

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਮੇਰਾ ਅਨੁਭਵ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ ਕਿ ਤੁਹਾਡੀ ਕਿਸਮ ਦੀ ਤੈਨਾਤੀ ਲਈ ਕਿਹੜਾ ਤਰੀਕਾ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ, ਅਤੇ ਮੈਨੂੰ ਤੁਹਾਡੀ ਰਾਏ ਸੁਣ ਕੇ ਖੁਸ਼ੀ ਹੋਵੇਗੀ।

ਅਨੁਵਾਦਕ ਤੋਂ PS ਨੋਟ

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

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

ਅਸੀਂ ਦੋਵੇਂ ਮਾਡਲਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਅਤੇ ਲੇਖ ਦੇ ਲੇਖਕ ਦੇ ਰੂਪ ਵਿੱਚ ਉਸੇ ਸਿੱਟੇ ਤੇ ਪਹੁੰਚੇ:

ਪੁੱਲ ਮਾਡਲ ਸਾਡੇ ਲਈ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਕਲੱਸਟਰਾਂ (ਵੇਖੋ. ਐਡਆਨ-ਓਪਰੇਟਰ ਬਾਰੇ ਲੇਖ).
GitLab CI 'ਤੇ ਆਧਾਰਿਤ ਪੁਸ਼ ਮਾਡਲ ਹੈਲਮ ਚਾਰਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਲਈ ਢੁਕਵਾਂ ਹੈ। ਉਸੇ ਸਮੇਂ, ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਾਈਪਲਾਈਨਾਂ ਦੇ ਅੰਦਰ ਤਾਇਨਾਤੀ ਦੇ ਰੋਲਆਊਟ ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ werf. ਵੈਸੇ, ਸਾਡੇ ਇਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਜਦੋਂ ਅਸੀਂ KubeCon Europe'19 ਵਿਖੇ ਆਪਣੇ ਸਟੈਂਡ 'ਤੇ DevOps ਇੰਜੀਨੀਅਰਾਂ ਦੀਆਂ ਪ੍ਰਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਤਾਂ ਅਸੀਂ ਨਿਰੰਤਰ "GitOps" ਸੁਣੇ।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਪੀ.ਐੱਸ

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

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਸੀਂ GitOps ਵਰਤ ਰਹੇ ਹੋ?

ਹਾਂ, ਖਿੱਚੋ ਪਹੁੰਚ
ਹਾਂ, ਧੱਕਾ
ਹਾਂ, ਖਿੱਚੋ + ਧੱਕੋ
ਹਾਂ, ਕੁਝ ਹੋਰ
ਕੋਈ

30 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 10 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com

GitOps: ਪੁੱਲ ਅਤੇ ਪੁਸ਼ ਵਿਧੀਆਂ ਦੀ ਤੁਲਨਾ