ਹੈਲਮ ਦੇ ਨਾਲ ਮਲਟੀਪਲ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ

ਡੇਲੀਮੋਸ਼ਨ ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਦਾ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਡਿਪਲਾਇਮੈਂਟ

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

ਇਹ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਹੋਇਆ

ਇੱਥੇ ਅਸੀਂ ਕਵਰ ਕਰਾਂਗੇ ਕਿ ਅਸੀਂ ਦੁਨੀਆ ਭਰ ਦੇ ਕਈ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੇ ਹਾਂ।

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

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

ਆਓ ਗੱਲ 'ਤੇ ਆਈਏ।

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

ਚਾਰਟ ਵਿਕਾਸ ਕਾਰਜ ਪ੍ਰਵਾਹ

ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਬ੍ਰਾਂਚਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਚਾਰਟਾਂ 'ਤੇ ਵੀ ਇਹੀ ਪਹੁੰਚ ਲਾਗੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

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

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

ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚਾਰਟ ਰਿਪੋਜ਼ਟਰੀਆਂ

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੀ ਛੋਟੀ ਪਾਈਥਨ ਸਕ੍ਰਿਪਟ ਕੁਬਰਨੇਟਸ ਓਪਨਏਪੀਆਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੁਬਰਨੇਟਸ ਆਬਜੈਕਟ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ ਕੁਬੇਵਾਲ, ਉਹਨਾਂ ਨੂੰ Chartmusem 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।

ਚਾਰਟ ਵਿਕਾਸ ਕਾਰਜ ਪ੍ਰਵਾਹ ਦਾ ਆਮ ਵਰਣਨ

1. ਨਿਰਧਾਰਨ ਦੇ ਅਨੁਸਾਰ ਪਾਈਪਲਾਈਨ ਕਾਰਜਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨਾ gazr.io ਗੁਣਵੱਤਾ ਨਿਯੰਤਰਣ ਲਈ (ਲਿੰਟ, ਯੂਨਿਟ-ਟੈਸਟ)।
2. ਪਾਈਥਨ ਟੂਲਸ ਨਾਲ ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਨੂੰ ਧੱਕਣਾ ਜੋ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਦੇ ਹਨ।
3. ਸ਼ਾਖਾ ਦੇ ਨਾਮ ਦੁਆਰਾ ਵਾਤਾਵਰਣ ਨੂੰ ਸਥਾਪਤ ਕਰਨਾ.
4. Kubeval ਦੀ ਵਰਤੋਂ ਕਰਕੇ Kubernetes yaml ਫਾਈਲਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ।
5. ਇੱਕ ਚਾਰਟ ਅਤੇ ਇਸਦੇ ਮੂਲ ਚਾਰਟ (ਚਾਰਟ ਜੋ ਬਦਲੇ ਜਾ ਰਹੇ ਚਾਰਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ) ਦੇ ਸੰਸਕਰਣ ਨੂੰ ਆਪਣੇ ਆਪ ਵਧਾਓ।
6. ਇੱਕ ਚਾਰਟਮਿਊਜ਼ੀਅਮ ਨੂੰ ਇੱਕ ਚਾਰਟ ਜਮ੍ਹਾਂ ਕਰਨਾ ਜੋ ਇਸਦੇ ਵਾਤਾਵਰਣ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ

ਸਮੂਹਾਂ ਵਿੱਚ ਅੰਤਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ

ਫੈਡਰੇਸ਼ਨ ਆਫ ਕਲੱਸਟਰ

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

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

ਜੀਓ-ਵਿਤਰਿਤ ਪਲੇਟਫਾਰਮ

ਸਾਡਾ ਪਲੇਟਫਾਰਮ ਵਰਤਮਾਨ ਵਿੱਚ 6 ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ - 3 ਸਥਾਨਕ ਅਤੇ 3 ਕਲਾਉਡ ਵਿੱਚ।

ਵੰਡੀ ਤੈਨਾਤੀ

ਗਲੋਬਲ ਹੈਲਮ ਮੁੱਲ

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

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

ਗਲੋਬਲ ਮੁੱਲ

ਇਹ ਮੁੱਲ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸੰਦਰਭ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਉਦੇਸ਼ਾਂ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ: ਨਿਗਰਾਨੀ, ਟਰੇਸਿੰਗ, ਲੌਗਿੰਗ, ਬਾਹਰੀ ਕਾਲਾਂ ਕਰਨਾ, ਸਕੇਲਿੰਗ, ਆਦਿ।

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

ਇੱਥੇ ਇੱਕ ਖਾਸ ਉਦਾਹਰਨ ਹੈ:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

ਹੈਲਮ ਟੈਂਪਲੇਟ ਦੀ ਉਦਾਹਰਨ

ਇਸ ਤਰਕ ਨੂੰ ਕੁਬਰਨੇਟਸ YAML ਵਿੱਚ ਗੜਬੜੀ ਤੋਂ ਬਚਣ ਲਈ ਇੱਕ ਸਹਾਇਕ ਟੈਮਪਲੇਟ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਰਜ਼ੀ ਦਾ ਐਲਾਨ

ਸਾਡੇ ਤੈਨਾਤੀ ਸਾਧਨ ਕਈ YAML ਫਾਈਲਾਂ 'ਤੇ ਅਧਾਰਤ ਹਨ। ਹੇਠਾਂ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਸੇਵਾ ਅਤੇ ਇਸਦੀ ਸਕੇਲਿੰਗ ਟੋਪੋਲੋਜੀ (ਰਿਪਲੀਕਾ ਦੀ ਸੰਖਿਆ) ਦਾ ਐਲਾਨ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ।

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

ਸੇਵਾ ਪਰਿਭਾਸ਼ਾ

ਇਹ ਉਹਨਾਂ ਸਾਰੇ ਕਦਮਾਂ ਦੀ ਰੂਪਰੇਖਾ ਹੈ ਜੋ ਸਾਡੇ ਤੈਨਾਤੀ ਵਰਕਫਲੋ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਆਖਰੀ ਪੜਾਅ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਕਈ ਵਰਕਰ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਤੈਨਾਤ ਕਰਦਾ ਹੈ।

ਜੇਨਕਿੰਸ ਤੈਨਾਤੀ ਦੇ ਪੜਾਅ

ਭੇਦ ਬਾਰੇ ਕੀ?

ਸੁਰੱਖਿਆ ਦੇ ਸੰਬੰਧ ਵਿੱਚ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੋਂ ਸਾਰੇ ਰਾਜ਼ਾਂ ਨੂੰ ਟਰੈਕ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵਿਲੱਖਣ ਵਾਲਟ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਾਂ ਵਾਲਟ ਪੈਰਿਸ ਵਿੱਚ.

ਸਾਡੇ ਤੈਨਾਤੀ ਸਾਧਨ Vault ਤੋਂ ਗੁਪਤ ਮੁੱਲਾਂ ਨੂੰ ਕੱਢਦੇ ਹਨ ਅਤੇ, ਜਦੋਂ ਤੈਨਾਤੀ ਦਾ ਸਮਾਂ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਹੈਲਮ ਵਿੱਚ ਪਾਓ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ Vault ਵਿੱਚ ਭੇਦ ਅਤੇ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਰਾਜ਼ਾਂ ਵਿਚਕਾਰ ਇੱਕ ਮੈਪਿੰਗ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਹੈ:

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

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

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਸੀਮਾਵਾਂ

ਮਲਟੀਪਲ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨਾਲ ਕੰਮ ਕਰਨਾ

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

ਆਮ ਚਾਰਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਇੱਕ ਮੁਸ਼ਕਲ ਹੈ

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

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

ਕਈ ਸੰਰਚਨਾ ਫਾਇਲਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

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

ਵਾਲਟ ਵਿੱਚ ਜੇਨਕਿਨਸ ਅਨੁਮਤੀਆਂ ਬਹੁਤ ਵਧੀਆਂ ਹਨ

ਹੁਣ ਸਾਡੇ ਕੋਲ ਇੱਕ ਹੈ ਐਪਰੋਲ, ਜੋ ਵਾਲਟ ਤੋਂ ਸਾਰੇ ਰਾਜ਼ ਪੜ੍ਹਦਾ ਹੈ।

ਰੋਲਬੈਕ ਪ੍ਰਕਿਰਿਆ ਸਵੈਚਲਿਤ ਨਹੀਂ ਹੈ

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

ਅਸੀਂ GitOps ਵੱਲ ਵਧ ਰਹੇ ਹਾਂ

ਸਾਡਾ ਟੀਚਾ

ਅਸੀਂ ਚਾਰਟ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਵਾਪਸ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ ਇਹ ਤੈਨਾਤ ਕਰਦੀ ਹੈ।

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

ਕਈ ਫਾਇਦੇ ਹਨ:

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

ਦੋ-ਪੜਾਅ ਮਾਈਗਰੇਸ਼ਨ

ਸਾਡੇ ਡਿਵੈਲਪਰ ਹੁਣ 2 ਸਾਲਾਂ ਤੋਂ ਇਸ ਵਰਕਫਲੋ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਦਰਦ ਰਹਿਤ ਹੋਵੇ। ਇਸ ਲਈ, ਅਸੀਂ ਟੀਚੇ ਦੇ ਰਸਤੇ 'ਤੇ ਇੱਕ ਵਿਚਕਾਰਲਾ ਕਦਮ ਜੋੜਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।
ਪਹਿਲਾ ਪੜਾਅ ਸਧਾਰਨ ਹੈ:

• ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਡਿਪਲਾਇਮੈਂਟ ਸੈਟ ਅਪ ਕਰਨ ਲਈ ਇੱਕ ਸਮਾਨ ਢਾਂਚਾ ਰੱਖਦੇ ਹਾਂ, ਪਰ ਡੇਲੀਮੋਸ਼ਨ ਰੀਲੀਜ਼ ਨਾਮਕ ਇੱਕ ਵਸਤੂ ਵਿੱਚ।

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

• ਪ੍ਰਤੀ ਐਪਲੀਕੇਸ਼ਨ 1 ਰੀਲੀਜ਼ (ਸਧਾਰਨ ਚਾਰਟ ਤੋਂ ਬਿਨਾਂ)।
• ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਚਾਰਟ।

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

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

ਸਰੋਤ: www.habr.com