OpenShift ਲਈ GitOps ਦੀ ਜਾਣ-ਪਛਾਣ

ਅੱਜ ਅਸੀਂ GitOps ਦੇ ਸਿਧਾਂਤਾਂ ਅਤੇ ਮਾਡਲਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਨਾਲ ਹੀ ਇਹ ਮਾਡਲਾਂ ਨੂੰ OpenShift ਪਲੇਟਫਾਰਮ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਇੰਟਰਐਕਟਿਵ ਗਾਈਡ ਉਪਲਬਧ ਹੈ ਲਿੰਕ.

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

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

GitOps ਲਈ ਕੋਈ ਅਕਾਦਮਿਕ ਪਰਿਭਾਸ਼ਾ ਜਾਂ ਨਿਯਮਾਂ ਦਾ ਪ੍ਰਵਾਨਿਤ ਸੈੱਟ ਨਹੀਂ ਹੈ, ਸਿਰਫ਼ ਸਿਧਾਂਤਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਅਭਿਆਸ ਬਣਾਇਆ ਗਿਆ ਹੈ:

• ਸਿਸਟਮ ਦਾ ਘੋਸ਼ਣਾਤਮਕ ਵੇਰਵਾ Git ਰਿਪੋਜ਼ਟਰੀ (ਸੰਰਚਨਾ, ਨਿਗਰਾਨੀ, ਆਦਿ) ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• ਰਾਜ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਪੁੱਲ ਬੇਨਤੀਆਂ ਰਾਹੀਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• ਚੱਲ ਰਹੇ ਸਿਸਟਮਾਂ ਦੀ ਸਥਿਤੀ ਨੂੰ Git ਪੁਸ਼ ਬੇਨਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਡੇਟਾ ਦੇ ਅਨੁਸਾਰ ਲਿਆਇਆ ਜਾਂਦਾ ਹੈ।

GitOps ਸਿਧਾਂਤ

• ਸਿਸਟਮ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਸਰੋਤ ਕੋਡ ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ

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

• ਸਿਸਟਮਾਂ ਦੀ ਲੋੜੀਦੀ ਸਥਿਤੀ ਅਤੇ ਸੰਰਚਨਾ Git ਵਿੱਚ ਸੈੱਟ ਅਤੇ ਸੰਸਕਰਣ ਹਨ

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

• ਕੌਂਫਿਗਰੇਸ਼ਨ ਤਬਦੀਲੀਆਂ ਪੁੱਲ ਬੇਨਤੀਆਂ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ

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

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

• ਸੰਰਚਨਾ ਦੇ ਬੇਕਾਬੂ ਵਹਾਅ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ

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

OpenShift ਲਈ GitOps ਮਾਡਲ

ਆਨ-ਕਲੱਸਟਰ ਰਿਸੋਰਸ ਰੀਕੌਂਸੀਲਰ

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

ਬਾਹਰੀ ਸੰਸਾਧਨ ਰੀਕਨਸਿਲਰ (ਪੁਸ਼)

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

OpenShift ਪਲੇਟਫਾਰਮ 'ਤੇ GitOps

ਮਲਟੀ-ਕਲੱਸਟਰ ਕੁਬਰਨੇਟਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਪ੍ਰਸ਼ਾਸਨ

ਕੁਬਰਨੇਟਸ ਦੇ ਫੈਲਣ ਅਤੇ ਬਹੁ-ਕਲਾਊਡ ਰਣਨੀਤੀਆਂ ਅਤੇ ਕਿਨਾਰੇ ਕੰਪਿਊਟਿੰਗ ਦੀ ਵਧਦੀ ਪ੍ਰਸਿੱਧੀ ਦੇ ਨਾਲ, ਪ੍ਰਤੀ ਗਾਹਕ ਓਪਨਸ਼ਿਫਟ ਕਲੱਸਟਰਾਂ ਦੀ ਔਸਤ ਗਿਣਤੀ ਵੀ ਵਧ ਰਹੀ ਹੈ।

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ:

• ਨਿਯੰਤਰਣ ਕਰੋ ਕਿ ਕਲੱਸਟਰ ਇੱਕ ਸਮਾਨ ਸਥਿਤੀ ਵਿੱਚ ਹਨ (ਸੰਰਚਨਾ, ਨਿਗਰਾਨੀ, ਸਟੋਰੇਜ, ਆਦਿ)
• ਕਿਸੇ ਜਾਣੀ-ਪਛਾਣੀ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਕਲੱਸਟਰ ਮੁੜ ਬਣਾਓ (ਜਾਂ ਰੀਸਟੋਰ)।
• ਕਿਸੇ ਜਾਣੀ-ਪਛਾਣੀ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਨਵੇਂ ਕਲੱਸਟਰ ਬਣਾਓ।
• ਕਈ OpenShift ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰੋ।
• ਇੱਕ ਤੋਂ ਵੱਧ OpenShift ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰੋ।
• ਟੈਂਪਲੇਟ ਕੀਤੀਆਂ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਨਾਲ ਲਿੰਕ ਕਰੋ।

ਐਪਲੀਕੇਸ਼ਨ ਸੰਰਚਨਾਵਾਂ

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਰਜਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਕਲੱਸਟਰਾਂ (ਦੇਵ, ਪੜਾਅ, ਆਦਿ) ਵਿਚਕਾਰ ਐਪਲੀਕੇਸ਼ਨਾਂ (ਬਾਈਨਰੀ, ਸੰਰਚਨਾ, ਆਦਿ) ਦੀ ਗਤੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਓ।
• ਕਈ OpenShift ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ (ਬਾਈਨਰੀ, ਸੰਰਚਨਾ, ਆਦਿ) ਵਿੱਚ ਬਦਲਾਅ ਰੋਲ ਆਊਟ ਕਰੋ।
• ਪਿਛਲੇ ਜਾਣੇ-ਪਛਾਣੇ ਰਾਜ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰੋ।

OpenShift GitOps ਵਰਤੋਂ ਦੇ ਕੇਸ

1. Git ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨਾ

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

2. ਸੀਕ੍ਰੇਟ ਮੈਨੇਜਰ ਨਾਲ ਸਮਕਾਲੀਕਰਨ

ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਇਸ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਬਣਾਏ ਗਏ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ Vault ਵਰਗੇ ਢੁਕਵੇਂ ਸੌਫਟਵੇਅਰ ਨਾਲ OpenShift ਗੁਪਤ ਵਸਤੂਆਂ ਨੂੰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਨ ਦੀ ਯੋਗਤਾ ਤੋਂ ਵੀ ਲਾਭ ਹੋਵੇਗਾ।

3. ਵਹਿਣ ਸੰਰਚਨਾ ਦਾ ਨਿਯੰਤਰਣ

ਐਡਮਿਨ ਕੇਵਲ ਤਾਂ ਹੀ ਪੱਖ ਵਿੱਚ ਹੋਵੇਗਾ ਜੇਕਰ ਓਪਨਸ਼ਿਫਟ ਗਿਟਓਪਸ ਖੁਦ ਅਸਲ ਸੰਰਚਨਾਵਾਂ ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਅੰਤਰਾਂ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ ਅਤੇ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਵਹਿਣ ਦਾ ਜਵਾਬ ਦੇ ਸਕਣ।

4. ਕੌਂਫਿਗਰੇਸ਼ਨ ਡਰਾਫਟ ਬਾਰੇ ਸੂਚਨਾਵਾਂ

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

5. ਵਹਿਣ ਵੇਲੇ ਸੰਰਚਨਾਵਾਂ ਦਾ ਮੈਨੁਅਲ ਸਮਕਾਲੀਕਰਨ

ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਕਲੱਸਟਰ ਨੂੰ ਪਿਛਲੀ ਜਾਣੀ-ਪਛਾਣੀ ਸਥਿਤੀ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਕਰਨ ਲਈ, ਸੰਰਚਨਾ ਡਰਾਫਟ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਓਪਨਸ਼ਿਫਟ ਕਲੱਸਟਰ ਨੂੰ Git ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਨਾਲ ਸਮਕਾਲੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

6. ਵਹਿਣ ਵੇਲੇ ਸੰਰਚਨਾ ਦਾ ਆਟੋ-ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ

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

7. ਕਈ ਕਲੱਸਟਰ - ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ

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

8. ਕਲੱਸਟਰ ਸੰਰਚਨਾਵਾਂ ਦੀ ਲੜੀ (ਵਿਰਸਾ)

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

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ Git ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦਰਜਾਬੰਦੀ “ਪ੍ਰੋਡਕਸ਼ਨ ਕਲੱਸਟਰ (ਉਤਪਾਦ) → ਸਿਸਟਮ X ਕਲੱਸਟਰ → ਸਿਸਟਮ X ਦੇ ਉਤਪਾਦਨ ਕਲੱਸਟਰ” ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦਾ ਸੁਮੇਲ ਸਿਸਟਮ X ਦੇ ਉਤਪਾਦਨ ਕਲੱਸਟਰਾਂ ਉੱਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

• ਸਾਰੇ ਉਤਪਾਦਨ ਕਲੱਸਟਰਾਂ ਲਈ ਸਾਂਝੀਆਂ ਸੰਰਚਨਾਵਾਂ।
• ਸਿਸਟਮ X ਕਲੱਸਟਰ ਲਈ ਸੰਰਚਨਾ।
• X ਸਿਸਟਮ ਉਤਪਾਦਨ ਕਲੱਸਟਰ ਲਈ ਸੰਰਚਨਾ।

9. ਟੈਂਪਲੇਟਸ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਓਵਰਰਾਈਡ

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

10. ਸੰਰਚਨਾਵਾਂ, ਐਪਲੀਕੇਸ਼ਨ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਲਈ ਚੋਣਵੇਂ ਸ਼ਾਮਲ ਅਤੇ ਬਾਹਰ ਕੱਢੋ

ਪ੍ਰਬੰਧਕ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲੇ ਕਲੱਸਟਰਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਕੁਝ ਸੰਰਚਨਾਵਾਂ ਦੇ ਗੈਰ-ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸ਼ਰਤਾਂ ਸੈਟ ਕਰ ਸਕਦਾ ਹੈ।

11. ਟੈਂਪਲੇਟ ਸਮਰਥਨ

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

OpenShift ਪਲੇਟਫਾਰਮ 'ਤੇ GitOps ਟੂਲ

ਆਰਗੋਸੀਡੀ

ਅਰਗੋਸੀਡੀ ਬਾਹਰੀ ਸਰੋਤ ਰਿਕੰਸਾਈਲ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲੱਸਟਰਾਂ ਅਤੇ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿਚਕਾਰ ਇੱਕ-ਤੋਂ-ਅਨੇਕ ਸਬੰਧਾਂ ਨੂੰ ਆਰਕੇਸਟ੍ਰੇਟ ਕਰਨ ਲਈ ਇੱਕ ਕੇਂਦਰੀਕ੍ਰਿਤ UI ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਇਸ ਪ੍ਰੋਗਰਾਮ ਦੇ ਨੁਕਸਾਨਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥਾ ਸ਼ਾਮਲ ਹੈ ਜਦੋਂ ArgoCD ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ।

ਸਰਕਾਰੀ ਵੈਬਸਾਈਟ '

ਵਹਿਣਾ

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

ਸਰਕਾਰੀ ਵੈਬਸਾਈਟ '

ਓਪਨਸ਼ਿਫਟ 'ਤੇ ਅਰਗੋਸੀਡੀ ਸਥਾਪਤ ਕਰਨਾ

ArgoCD ਇੱਕ ਸ਼ਾਨਦਾਰ ਕਮਾਂਡ ਲਾਈਨ ਇੰਟਰਫੇਸ ਅਤੇ ਵੈਬ ਕੰਸੋਲ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਇੱਥੇ ਫਲਕਸ ਅਤੇ ਹੋਰ ਵਿਕਲਪਾਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਾਂਗੇ।

ਓਪਨਸ਼ਿਫਟ 4 ਪਲੇਟਫਾਰਮ 'ਤੇ ਆਰਗੋਸੀਡੀ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ, ਕਲੱਸਟਰ ਪ੍ਰਸ਼ਾਸਕ ਵਜੋਂ ਇਹਨਾਂ ਕਦਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:

ਓਪਨਸ਼ਿਫਟ ਪਲੇਟਫਾਰਮ 'ਤੇ ਅਰਗੋਸੀਡੀ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

ਅਰਗੋਸੀਡੀ ਸਰਵਰ ਵਿੱਚ ਸੁਧਾਰ ਤਾਂ ਜੋ ਇਸਨੂੰ ਓਪਨਸ਼ਿਫਟ ਰੂਟ ਦੁਆਰਾ ਦੇਖਿਆ ਜਾ ਸਕੇ

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

ਅਰਗੋਸੀਡੀ ਕਲੀ ਟੂਲ ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

ArgoCD ਸਰਵਰ ਐਡਮਿਨ ਪਾਸਵਰਡ ਬਦਲਣਾ

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

ਇਹਨਾਂ ਪੜਾਵਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ArgoCD WebUI ਵੈੱਬ ਕੰਸੋਲ ਜਾਂ ArgoCD Cli ਕਮਾਂਡ ਲਾਈਨ ਟੂਲ ਰਾਹੀਂ ArgoCD ਸਰਵਰ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - ਇਹ ਕਦੇ ਵੀ ਬਹੁਤ ਦੇਰ ਨਹੀਂ ਹੁੰਦਾ

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

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

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

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

• ਕੋਡ ਲਈ ਇੱਕ Git ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਓ।
• ਅਸੀਂ ਆਪਣੀਆਂ ਮੌਜੂਦਾ ਵਸਤੂਆਂ ਨੂੰ ਨਿਰਯਾਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ Git ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰਦੇ ਹਾਂ।
• GitOps ਟੂਲਸ ਦੀ ਚੋਣ ਅਤੇ ਤੈਨਾਤ ਕਰਨਾ।
• ਅਸੀਂ ਇਸ ਟੂਲਕਿੱਟ ਵਿੱਚ ਆਪਣੀ ਰਿਪੋਜ਼ਟਰੀ ਜੋੜਦੇ ਹਾਂ।
• ਅਸੀਂ ਸਾਡੀ GitOps ਟੂਲਕਿੱਟ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ।
• ਅਸੀਂ GitOps ਟੂਲਕਿੱਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇੱਕ ਟੈਸਟ ਰਨ ਕਰਦੇ ਹਾਂ।
• ਅਸੀਂ GitOps ਟੂਲਕਿੱਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਸਤੂਆਂ ਨੂੰ ਸਮਕਾਲੀ ਕਰਦੇ ਹਾਂ।
• ਵਸਤੂਆਂ ਦੀ ਛਾਂਗਣ ਅਤੇ ਆਟੋ-ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ।

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

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

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

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

ਹੁਣ ਆਉ ਫੀਲਡ ਨੂੰ ਹਟਾਉਣ ਲਈ deployment.yaml ਫਾਈਲ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੀਏ ਜਿਸ ਨੂੰ ਆਰਗੋ ਸੀਡੀ ਸਿੰਕ ਨਹੀਂ ਕਰ ਸਕਦੀ ਹੈ।

sed -i '/sgeneration: .*/d' deployment.yaml

ਇਸ ਤੋਂ ਇਲਾਵਾ ਰੂਟ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਪਹਿਲਾਂ ਇੱਕ ਮਲਟੀਲਾਈਨ ਵੇਰੀਏਬਲ ਸੈਟ ਕਰਾਂਗੇ ਅਤੇ ਫਿਰ ingress: null ਨੂੰ ਉਸ ਵੇਰੀਏਬਲ ਦੀ ਸਮੱਗਰੀ ਨਾਲ ਬਦਲਾਂਗੇ।

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

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

git commit -am ‘initial commit of objects’
git push origin master

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

argocd repo add https://github.com/cooktheryan/blogpost

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

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

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

ਹੁਣ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇੱਕ ਟੈਸਟ ਰਨ ਕਰੀਏ ਕਿ ਸਾਡੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਕੋਈ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਹਨ।

argocd app sync simple-app --dry-run

ਜੇਕਰ ਕੋਈ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਸਮਕਾਲੀਕਰਨ ਲਈ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ।

argocd app sync simple-app

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

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

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

argocd app set simple-app --sync-policy automated --auto-prune

ਇਸ ਲਈ, ਅਸੀਂ ਸਫਲਤਾਪੂਰਵਕ GitOps ਨਿਯੰਤਰਣ ਅਧੀਨ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਲਿਆਏ ਹਨ ਜੋ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ GitOps ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਸੀ।

ਸਰੋਤ: www.habr.com