3-ਵੇਅ ਮਰਜ ਟੂ ਵਰਫ: ਹੈਲਮ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਦੀ ਤੈਨਾਤੀ “ਸਟੀਰੌਇਡਜ਼ ਉੱਤੇ”

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

ਜੇ ਇਹ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਪਾਉਂਦੇ ਹਾਂ WERF_THREE_WAY_MERGE=enabled - ਸਾਨੂੰ ਤੈਨਾਤੀ ਮਿਲਦੀ ਹੈ "ਜਿਵੇਂ ਕਿ ਵਿੱਚ kubectl apply", ਮੌਜੂਦਾ ਹੈਲਮ 2 ਸਥਾਪਨਾਵਾਂ ਦੇ ਅਨੁਕੂਲ ਅਤੇ ਥੋੜਾ ਹੋਰ ਵੀ।

ਪਰ ਆਓ ਸਿਧਾਂਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ: 3-ਵੇ-ਅਭੇਦ ਪੈਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹਨ, ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਪਹੁੰਚ ਕਿਵੇਂ ਲੈ ਕੇ ਆਏ, ਅਤੇ ਉਹ ਕੁਬਰਨੇਟਸ-ਅਧਾਰਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਾਲ CI/CD ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹਨ? ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ, ਆਓ ਦੇਖੀਏ ਕਿ 3-ਵੇਅ-ਮਰਜ ਕੀ ਹੈ werf ਵਿੱਚ, ਕਿਹੜੇ ਮੋਡ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਹੈ।

ਇੱਕ 3-ਵੇ-ਅਭੇਦ ਪੈਚ ਕੀ ਹੈ?

ਇਸ ਲਈ, ਆਓ YAML ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਵਰਣਿਤ ਸਰੋਤਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਨ ਦੇ ਕੰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ।

ਸਰੋਤਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, Kubernetes API ਹੇਠਾਂ ਦਿੱਤੇ ਬੁਨਿਆਦੀ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ: ਬਣਾਓ, ਪੈਚ ਕਰੋ, ਬਦਲੋ ਅਤੇ ਮਿਟਾਓ। ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀ ਮਦਦ ਨਾਲ ਕਲੱਸਟਰ ਲਈ ਸਰੋਤਾਂ ਦਾ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਨਿਰੰਤਰ ਰੋਲਆਉਟ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਕਿਵੇਂ?

kubectl ਜ਼ਰੂਰੀ ਹੁਕਮ

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

• ਟੀਮ ਦੁਆਰਾ kubectl run ਤੁਸੀਂ ਤੈਨਾਤੀ ਜਾਂ ਨੌਕਰੀ ਚਲਾ ਸਕਦੇ ਹੋ:

  kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

• ਟੀਮ ਦੁਆਰਾ kubectl scale - ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਗਿਣਤੀ ਬਦਲੋ:

  kubectl scale --replicas=3 deployment/mysql

• ਅਤੇ ਇਸ ਤਰਾਂ ਹੀ.

ਇਹ ਪਹੁੰਚ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਸੁਵਿਧਾਜਨਕ ਲੱਗ ਸਕਦਾ ਹੈ. ਹਾਲਾਂਕਿ ਸਮੱਸਿਆਵਾਂ ਹਨ:

1. ਇਹ ਔਖਾ ਹੈ ਸਵੈਚਾਲਤ.
2. ਕਰਨਾ ਸੰਰਚਨਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ Git ਵਿੱਚ? ਕਲੱਸਟਰ ਵਿੱਚ ਹੋ ਰਹੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਿਵੇਂ ਕਰੀਏ?
3. ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ ਪ੍ਰਜਨਨਯੋਗਤਾ ਰੀਸਟਾਰਟ 'ਤੇ ਸੰਰਚਨਾਵਾਂ?
4. ...

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਪਹੁੰਚ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕੋਡ (IaC; ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ) ਸਟੋਰ ਕਰਨ ਦੇ ਨਾਲ ਠੀਕ ਨਹੀਂ ਬੈਠਦੀ ਹੈ GitOps ਇੱਕ ਵਧੇਰੇ ਆਧੁਨਿਕ ਵਿਕਲਪ ਵਜੋਂ, ਕੁਬਰਨੇਟਸ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕਰਨਾ)। ਇਸਲਈ, ਇਹਨਾਂ ਕਮਾਂਡਾਂ ਨੂੰ kubectl ਵਿੱਚ ਹੋਰ ਵਿਕਾਸ ਨਹੀਂ ਮਿਲਿਆ।

ਓਪਰੇਸ਼ਨ ਬਣਾਓ, ਪ੍ਰਾਪਤ ਕਰੋ, ਬਦਲੋ ਅਤੇ ਮਿਟਾਓ

ਪ੍ਰਾਇਮਰੀ ਦੇ ਨਾਲ ਰਚਨਾ ਇਹ ਸਧਾਰਨ ਹੈ: ਆਪਰੇਸ਼ਨ ਲਈ ਮੈਨੀਫੈਸਟ ਭੇਜੋ create kube api ਅਤੇ ਸਰੋਤ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਮੈਨੀਫੈਸਟ ਦੀ YAML ਨੁਮਾਇੰਦਗੀ Git ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ kubectl create -f manifest.yaml.

С ਹਟਾ ਰਿਹਾ ਹੈ ਇਹ ਵੀ ਸਧਾਰਨ: ਉਹੀ ਬਦਲੋ manifest.yaml Git ਤੋਂ ਟੀਮ ਤੱਕ kubectl delete -f manifest.yaml.

ਓਪਰੇਸ਼ਨ replace ਤੁਹਾਨੂੰ ਸਰੋਤ ਸੰਰਚਨਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਇੱਕ ਨਵੇਂ ਨਾਲ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਸਰੋਤ ਨੂੰ ਮੁੜ ਬਣਾਏ ਬਿਨਾਂ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਸਰੋਤ ਵਿੱਚ ਤਬਦੀਲੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਓਪਰੇਸ਼ਨ ਦੇ ਨਾਲ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਨਾ ਤਰਕਪੂਰਨ ਹੈ get, ਇਸਨੂੰ ਬਦਲੋ ਅਤੇ ਇਸਨੂੰ ਅਪਰੇਸ਼ਨ ਨਾਲ ਅਪਡੇਟ ਕਰੋ replace. kube apiserver ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ ਆਸ਼ਾਵਾਦੀ ਤਾਲਾਬੰਦੀ ਅਤੇ, ਜੇ ਸਰਜਰੀ ਤੋਂ ਬਾਅਦ get ਵਸਤੂ ਬਦਲ ਗਈ ਹੈ, ਫਿਰ ਓਪਰੇਸ਼ਨ replace ਇਹ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ।

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

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

ਕੁੱਲ: ਕੀ ਅਸੀਂ ਲਗਾਤਾਰ ਰੋਲਆਊਟ ਬਣਾ ਸਕਦੇ ਹਾਂ ਸਿਰਫ਼ ਬਣਾਓ, ਬਦਲੋ ਅਤੇ ਮਿਟਾਓ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸੰਰਚਨਾ ਕੋਡ ਅਤੇ ਸੁਵਿਧਾਜਨਕ CI/CD ਦੇ ਨਾਲ Git ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਗਈ ਹੈ?

ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਇਸ ਲਈ... ਤੁਹਾਨੂੰ ਅਭੇਦ ਕਾਰਵਾਈ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਮੈਨੀਫੈਸਟੋ ਅਤੇ ਕਿਸੇ ਕਿਸਮ ਦੀ ਬਾਈਡਿੰਗ ਜੋ ਕਿ:

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

ਅੱਪਡੇਟ ਕਰਦੇ ਸਮੇਂ, ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਸਰੋਤ ਬਦਲਿਆ ਹੋ ਸਕਦਾ ਹੈ ਪਿਛਲੇ ਤੋਂ get ਅਤੇ ਆਸ਼ਾਵਾਦੀ ਲਾਕਿੰਗ ਦੇ ਮਾਮਲੇ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਹੈਂਡਲ ਕਰੋ - ਵਾਰ-ਵਾਰ ਅਪਡੇਟ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰੋ।

ਹਾਲਾਂਕਿ, ਜਦੋਂ ਕਿਊਬ-ਐਪੀਸਰਵਰ ਸਰੋਤਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਪਹੀਏ ਨੂੰ ਦੁਬਾਰਾ ਕਿਉਂ ਬਣਾਇਆ ਜਾਵੇ: ਓਪਰੇਸ਼ਨ patch, ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਵਰਣਿਤ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਕੁਝ ਤੋਂ ਰਾਹਤ ਦਿੰਦਾ ਹੈ?

ਪੈਚ

ਹੁਣ ਅਸੀਂ ਪੈਚਾਂ 'ਤੇ ਆਉਂਦੇ ਹਾਂ।

ਪੈਚ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮੌਜੂਦਾ ਵਸਤੂਆਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਪ੍ਰਾਇਮਰੀ ਤਰੀਕਾ ਹੈ। ਓਪਰੇਸ਼ਨ patch ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:

• kube-apiserver ਉਪਭੋਗਤਾ ਨੂੰ JSON ਫਾਰਮ ਵਿੱਚ ਇੱਕ ਪੈਚ ਭੇਜਣ ਅਤੇ ਆਬਜੈਕਟ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ,
• ਅਤੇ apiserver ਖੁਦ ਆਬਜੈਕਟ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਨਾਲ ਨਜਿੱਠੇਗਾ ਅਤੇ ਇਸਨੂੰ ਲੋੜੀਂਦੇ ਰੂਪ ਵਿੱਚ ਲਿਆਏਗਾ।

ਇਸ ਕੇਸ ਵਿੱਚ ਆਸ਼ਾਵਾਦੀ ਲਾਕਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਓਪਰੇਸ਼ਨ ਬਦਲਣ ਨਾਲੋਂ ਵਧੇਰੇ ਘੋਸ਼ਣਾਤਮਕ ਹੈ, ਹਾਲਾਂਕਿ ਪਹਿਲਾਂ ਇਹ ਇਸਦੇ ਉਲਟ ਲੱਗ ਸਕਦਾ ਹੈ।

ਇਸ ਪ੍ਰਕਾਰ:

• ਇੱਕ ਓਪਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ create ਅਸੀਂ ਗਿੱਟ ਤੋਂ ਮੈਨੀਫੈਸਟ ਦੇ ਅਨੁਸਾਰ ਇੱਕ ਵਸਤੂ ਬਣਾਉਂਦੇ ਹਾਂ,
• ਦੀ ਸਹਾਇਤਾ ਨਾਲ delete - ਮਿਟਾਓ ਜੇ ਵਸਤੂ ਦੀ ਹੁਣ ਲੋੜ ਨਹੀਂ ਹੈ,
• ਦੀ ਸਹਾਇਤਾ ਨਾਲ patch - ਅਸੀਂ ਆਬਜੈਕਟ ਨੂੰ ਬਦਲਦੇ ਹਾਂ, ਇਸਨੂੰ ਗਿੱਟ ਵਿੱਚ ਵਰਣਿਤ ਰੂਪ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹਾਂ।

ਹਾਲਾਂਕਿ, ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਸਹੀ ਪੈਚ!

ਹੈਲਮ 2 ਵਿੱਚ ਪੈਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ: 2-ਵੇ-ਅਭੇਦ

ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲੀ ਵਾਰ ਰੀਲੀਜ਼ ਸਥਾਪਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਹੈਲਮ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ create ਚਾਰਟ ਸਰੋਤਾਂ ਲਈ.

ਹਰੇਕ ਸਰੋਤ ਲਈ ਹੈਲਮ ਰੀਲੀਜ਼ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਸਮੇਂ:

• ਪਿਛਲੇ ਚਾਰਟ ਅਤੇ ਮੌਜੂਦਾ ਚਾਰਟ ਸੰਸਕਰਣ ਤੋਂ ਸਰੋਤ ਸੰਸਕਰਣ ਦੇ ਵਿਚਕਾਰ ਪੈਚ ਨੂੰ ਸਮਝਦਾ ਹੈ,
• ਇਸ ਪੈਚ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ.

ਅਸੀਂ ਇਸ ਪੈਚ ਨੂੰ ਕਾਲ ਕਰਾਂਗੇ 2-ਤਰੀਕੇ ਨਾਲ ਮਿਲਾਨ ਪੈਚ, ਕਿਉਂਕਿ 2 ਮੈਨੀਫੈਸਟੋ ਇਸਦੀ ਰਚਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਪਿਛਲੀ ਰੀਲੀਜ਼ ਤੋਂ ਸਰੋਤ ਪ੍ਰਗਟ,
• ਸਰੋਤ ਮੌਜੂਦਾ ਸਰੋਤ ਤੋਂ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ।

ਓਪਰੇਸ਼ਨ ਨੂੰ ਹਟਾਉਣ ਵੇਲੇ delete kube apiserver ਵਿੱਚ ਉਹਨਾਂ ਸਰੋਤਾਂ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਜੋ ਪਿਛਲੀ ਰੀਲੀਜ਼ ਵਿੱਚ ਘੋਸ਼ਿਤ ਕੀਤੇ ਗਏ ਸਨ, ਪਰ ਮੌਜੂਦਾ ਵਿੱਚ ਘੋਸ਼ਿਤ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ।

2 ਵੇਅ ਮਰਜ ਪੈਚ ਪਹੁੰਚ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਇਹ ਇਸ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ ਕਲੱਸਟਰ ਵਿੱਚ ਸਰੋਤ ਦੀ ਅਸਲ ਸਥਿਤੀ ਅਤੇ Git ਵਿੱਚ ਮੈਨੀਫੈਸਟ ਨਾਲ ਸਮਕਾਲੀਕਰਨ ਤੋਂ ਬਾਹਰ.

ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਨਾਲ ਸਮੱਸਿਆ ਦਾ ਵਰਣਨ

• ਗਿੱਟ ਵਿੱਚ, ਇੱਕ ਚਾਰਟ ਇੱਕ ਮੈਨੀਫੈਸਟ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਖੇਤਰ image ਤੈਨਾਤੀ ਦੇ ਮਾਮਲੇ ubuntu:18.04.
• ਦੁਆਰਾ ਉਪਭੋਗਤਾ kubectl edit ਇਸ ਖੇਤਰ ਦੇ ਮੁੱਲ ਨੂੰ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ubuntu:19.04.
• ਹੈਲਮ ਚਾਰਟ ਨੂੰ ਮੁੜ-ਤੈਨਾਤ ਕਰਦੇ ਸਮੇਂ ਇੱਕ ਪੈਚ ਤਿਆਰ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਖੇਤਰ image ਰੀਲੀਜ਼ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ ਵਿੱਚ ਅਤੇ ਮੌਜੂਦਾ ਚਾਰਟ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਹਨ।
• ਮੁੜ ਤਾਇਨਾਤੀ ਦੇ ਬਾਅਦ image ਬਚਿਆ ubuntu:19.04, ਹਾਲਾਂਕਿ ਚਾਰਟ ਕਹਿੰਦਾ ਹੈ ubuntu:18.04.

ਸਾਨੂੰ ਡੀਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਮਿਲੀ ਅਤੇ ਘੋਸ਼ਣਾਤਮਕਤਾ ਖਤਮ ਹੋ ਗਈ।

ਇੱਕ ਸਮਕਾਲੀ ਸਰੋਤ ਕੀ ਹੈ?

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

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

3-ਤਰੀਕੇ ਨਾਲ ਮਿਲਾਨ ਪੈਚ

ਮੁੱਖ ਵਿਚਾਰ 3-ਤਰੀਕੇ ਨਾਲ ਮਿਲਾਨ ਪੈਚ: ਅਸੀਂ ਚੱਲ ਰਹੇ ਕਲੱਸਟਰ ਤੋਂ ਮੈਨੀਫੈਸਟ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, Git ਤੋਂ ਮੈਨੀਫੈਸਟ ਦੇ ਆਖਰੀ ਲਾਗੂ ਕੀਤੇ ਸੰਸਕਰਣ ਅਤੇ Git ਤੋਂ ਮੈਨੀਫੈਸਟ ਦੇ ਟਾਰਗੇਟ ਸੰਸਕਰਣ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਪੈਚ ਤਿਆਰ ਕਰਦੇ ਹਾਂ। ਨਤੀਜੇ ਵਾਲੇ ਪੈਚ ਨੂੰ ਸਮਕਾਲੀ ਸਰੋਤ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

• ਟੀਚੇ ਦੇ ਸੰਸਕਰਣ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਨਵੇਂ ਖੇਤਰਾਂ ਨੂੰ ਇੱਕ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ;
• ਪਿਛਲੇ ਲਾਗੂ ਕੀਤੇ ਸੰਸਕਰਣ ਵਿੱਚ ਪਹਿਲਾਂ ਮੌਜੂਦ ਖੇਤਰ ਅਤੇ ਟੀਚੇ ਦੇ ਸੰਸਕਰਣ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਇੱਕ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੀਸੈਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ;
• ਆਬਜੈਕਟ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਵਿੱਚ ਖੇਤਰ ਜੋ ਮੈਨੀਫੈਸਟ ਦੇ ਟਾਰਗੇਟ ਸੰਸਕਰਣ ਤੋਂ ਵੱਖਰੇ ਹਨ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਪਡੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਇਹ ਇਸ ਸਿਧਾਂਤ 'ਤੇ ਹੈ ਕਿ ਇਹ ਪੈਚ ਤਿਆਰ ਕਰਦਾ ਹੈ kubectl apply:

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

ਹੁਣ ਜਦੋਂ ਅਸੀਂ ਥਿਊਰੀ ਨੂੰ ਸੁਲਝਾ ਲਿਆ ਹੈ, ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣ ਦਾ ਸਮਾਂ ਹੈ ਕਿ ਅਸੀਂ ਵਰਫ ਵਿੱਚ ਕੀ ਕੀਤਾ ਹੈ।

werf ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ

ਪਹਿਲਾਂ, werf, ਹੈਲਮ 2 ਵਾਂਗ, 2-ਤਰੀਕੇ-ਅਭੇਦ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਸੀ।

ਮੁਰੰਮਤ ਪੈਚ

ਇੱਕ ਨਵੀਂ ਕਿਸਮ ਦੇ ਪੈਚਾਂ ਵਿੱਚ ਬਦਲਣ ਲਈ - 3-ਤਰੀਕੇ ਨਾਲ ਮਿਲਾਓ - ਪਹਿਲਾ ਕਦਮ ਅਸੀਂ ਅਖੌਤੀ ਪੇਸ਼ ਕੀਤਾ ਮੁਰੰਮਤ ਪੈਚ.

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

ਜੇਕਰ ਇੱਕ ਡੀਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਵਾਪਰਦਾ ਹੈ, ਤੈਨਾਤੀ ਦੇ ਅੰਤ ਵਿੱਚ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਅਨੁਸਾਰੀ ਸੰਦੇਸ਼ ਅਤੇ ਇੱਕ ਪੈਚ ਦੇ ਨਾਲ ਇੱਕ ਚੇਤਾਵਨੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ ਜੋ ਸਰੋਤ ਨੂੰ ਇੱਕ ਸਮਕਾਲੀ ਰੂਪ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਪੈਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਿਆਖਿਆ ਵਿੱਚ ਵੀ ਦਰਜ ਹੈ werf.io/repair-patch. ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਦੇ ਹੱਥ сам ਇਸ ਪੈਚ ਨੂੰ ਲਾਗੂ ਕਰੇਗਾ: werf ਇਸ ਨੂੰ ਬਿਲਕੁਲ ਲਾਗੂ ਨਹੀਂ ਕਰੇਗਾ।

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

ਸਿਰਫ਼ ਨਵੀਆਂ ਰੀਲੀਜ਼ਾਂ ਲਈ 3-ਤਰੀਕੇ ਨਾਲ ਮਰਜ ਪੈਚ

1 ਦਸੰਬਰ, 2019 ਤੋਂ, werf ਦੇ ਬੀਟਾ ਅਤੇ ਅਲਫ਼ਾ ਵਰਜਨ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਿਰਫ werf ਦੁਆਰਾ ਰੋਲ ਆਊਟ ਕੀਤੇ ਗਏ ਨਵੇਂ ਹੈਲਮ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਾਗੂ ਕਰਨ ਲਈ ਪੂਰੇ 3-ਵੇਅ-ਮਰਜ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਮੌਜੂਦਾ ਰੀਲੀਜ਼ 2-ਵੇਅ-ਅਭੇਦ + ਮੁਰੰਮਤ ਪੈਚ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣਗੀਆਂ।

ਇਹ ਓਪਰੇਟਿੰਗ ਮੋਡ ਸੈਟਿੰਗ ਦੁਆਰਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਰੱਥ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ WERF_THREE_WAY_MERGE_MODE=onlyNewReleases ਹੁਣ

ਟਿੱਪਣੀ: ਵਿਸ਼ੇਸ਼ਤਾ ਕਈ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ werf ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਈ: ਅਲਫ਼ਾ ਚੈਨਲ ਵਿੱਚ ਇਹ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਤਿਆਰ ਹੋ ਗਈ v1.0.5-ਅਲਫ਼ਾ.19, ਅਤੇ ਬੀਟਾ ਚੈਨਲ ਵਿੱਚ - ਨਾਲ v1.0.4-ਬੀਟਾ.20.

ਸਾਰੀਆਂ ਰੀਲੀਜ਼ਾਂ ਲਈ 3-ਤਰੀਕੇ ਨਾਲ ਮਰਜ ਪੈਚ

15 ਦਸੰਬਰ, 2019 ਤੋਂ, werf ਦੇ ਬੀਟਾ ਅਤੇ ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਸਾਰੀਆਂ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਪੂਰੇ 3-ਵੇਅ-ਅਭੇਦ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ।

ਇਹ ਓਪਰੇਟਿੰਗ ਮੋਡ ਸੈਟਿੰਗ ਦੁਆਰਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਰੱਥ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ WERF_THREE_WAY_MERGE_MODE=enabled ਹੁਣ

ਸਰੋਤ ਆਟੋਸਕੇਲਿੰਗ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ?

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਟੋਸਕੇਲਿੰਗ ਦੀਆਂ 2 ਕਿਸਮਾਂ ਹਨ: ਐਚਪੀਏ (ਹਰੀਜ਼ਟਲ) ਅਤੇ ਵੀਪੀਏ (ਵਰਟੀਕਲ)।

ਹਰੀਜ਼ਟਲ ਆਟੋਮੈਟਿਕ ਹੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਸੰਖਿਆ ਚੁਣਦਾ ਹੈ, ਲੰਬਕਾਰੀ - ਸਰੋਤਾਂ ਦੀ ਸੰਖਿਆ। ਰਿਸੋਰਸ ਮੈਨੀਫੈਸਟ (ਸਰੋਤ ਮੈਨੀਫੈਸਟ ਦੇਖੋ) ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਸਰੋਤ ਲੋੜਾਂ ਦੋਵੇਂ ਦਰਸਾਏ ਗਏ ਹਨ। spec.replicas ਜ spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

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

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

• werf.io/set-replicas-only-on-creation=true
• werf.io/set-resources-only-on-creation=true

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

ਹੋਰ ਵੇਰਵਿਆਂ ਲਈ, ਲਈ ਪ੍ਰੋਜੈਕਟ ਦਸਤਾਵੇਜ਼ ਵੇਖੋ HPA и VPA.

3-ਤਰੀਕੇ ਨਾਲ ਮਰਜ ਪੈਚ ਦੀ ਵਰਤੋਂ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾਓ

ਉਪਭੋਗਤਾ ਵਰਤਮਾਨ ਵਿੱਚ ਇੱਕ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ werf ਵਿੱਚ ਨਵੇਂ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾ ਸਕਦਾ ਹੈ WERF_THREE_WAY_MERGE_MODE=disabled. ਹਾਲਾਂਕਿ, ਸ਼ੁਰੂ 1 ਮਾਰਚ 2020 ਤੋਂ ਇਹ ਪਾਬੰਦੀ ਲਾਗੂ ਨਹੀਂ ਹੋਵੇਗੀ। ਅਤੇ ਇਹ ਸਿਰਫ 3-ਤਰੀਕੇ-ਅਭੇਦ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੋਵੇਗਾ।

ਵਰਫ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਅਪਣਾਉਣਾ

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

ਹੈਲਮ 2 ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਤੁਸੀਂ ਚਾਰਟ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਇੱਕ ਸਰੋਤ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇਸ ਸਰੋਤ ਨੂੰ ਸਕ੍ਰੈਚ ਤੋਂ ਮੁੜ ਬਣਾਏ ਬਿਨਾਂ ਕਲੱਸਟਰ ਵਿੱਚ ਮੌਜੂਦ ਹੈ (ਵੇਖੋ। #6031, #3275). ਅਸੀਂ ਰੀਲੀਜ਼ ਲਈ ਮੌਜੂਦਾ ਸਰੋਤਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਵਰਫ ਨੂੰ ਸਿਖਾਇਆ. ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਚੱਲ ਰਹੇ ਕਲੱਸਟਰ ਤੋਂ ਸਰੋਤ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ 'ਤੇ ਇੱਕ ਐਨੋਟੇਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ (ਉਦਾਹਰਨ ਲਈ, kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

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

ਟਿੱਪਣੀ: ਸੈਟਿੰਗ WERF_THREE_WAY_MERGE_MODE ਸਰੋਤਾਂ ਨੂੰ ਅਪਣਾਉਣ 'ਤੇ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਉਂਦਾ - ਗੋਦ ਲੈਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇੱਕ 3-ਤਰੀਕੇ ਨਾਲ ਮਰਜ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਵੇਰਵੇ - ਵਿੱਚ ਦਸਤਾਵੇਜ਼.

ਸਿੱਟੇ ਅਤੇ ਭਵਿੱਖ ਦੀਆਂ ਯੋਜਨਾਵਾਂ

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

ਹਾਲੇ ਵੀ ਹੈਲਮ ਵਰਗੀਆਂ ਤੈਨਾਤੀਆਂ ਦੇ ਨਾਲ ਕੁਝ ਮੁੱਦੇ ਅਤੇ ਚੁਣੌਤੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਗੋ ਟੈਂਪਲੇਟਸ ਦੀ ਵਰਤੋਂ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਹੱਲ ਕਰਨਾ ਜਾਰੀ ਰੱਖਾਂਗੇ।

ਸਰੋਤ ਅੱਪਡੇਟ ਕਰਨ ਦੇ ਢੰਗ ਅਤੇ ਅਪਣਾਉਣ ਬਾਰੇ ਜਾਣਕਾਰੀ ਵੀ 'ਤੇ ਮਿਲ ਸਕਦੀ ਹੈ ਇਹ ਦਸਤਾਵੇਜ਼ ਸਫ਼ਾ.

ਹੈਲਮ 3

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

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

ਹਾਲਾਂਕਿ, ਹੈਲਮ 3 ਕੋਡਬੇਸ ਵਿੱਚ ਵਰਫ ਦਾ ਸਵਿਚ ਕਰਨਾ ਅਟੱਲ ਹੈ ਅਤੇ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਹੋਵੇਗਾ। ਸੰਭਵ ਤੌਰ 'ਤੇ ਇਹ werf 1.1 ਜਾਂ werf 1.2 ਹੋਵੇਗਾ (ਇਸ ਸਮੇਂ, werf ਦਾ ਮੁੱਖ ਸੰਸਕਰਣ 1.0 ਹੈ; werf ਸੰਸਕਰਣ ਡਿਵਾਈਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਵੇਖੋ ਇੱਥੇ). ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਹੈਲਮ 3 ਕੋਲ ਸਥਿਰ ਹੋਣ ਦਾ ਸਮਾਂ ਹੋਵੇਗਾ।

PS

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

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

ਸਰੋਤ: www.habr.com