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

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

VM 'ਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

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

ਇਹ ਕਿਸ ਲਈ ਸੀ?

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

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

ਇਸ ਸਭ ਵਿਚ ਸਾਨੂੰ ਕੀ ਫ਼ਾਇਦੇ ਹੋਏ?

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

ਪਰ ਅਸੀਂ ਇਸ ਸਭ ਵਿੱਚ ਕਈ ਕਮੀਆਂ ਵੀ ਵੇਖੀਆਂ:

1. ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ, ਵਿਕਾਸ ਦੇ ਵਾਤਾਵਰਣ ਤੋਂ ਇਲਾਵਾ, ਹੋਰ ਵਾਤਾਵਰਣ ਹਨ. ਉਦਾਹਰਨ ਲਈ, qa ਅਤੇ ਪੂਰਵ-ਉਤਪਾਦਨ। ਉਸ ਸਮੇਂ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਸਰਵਰ ਸਨ ਅਤੇ ਲਗਭਗ 60 ਸੇਵਾਵਾਂ ਸਨ। ਇਸ ਕਾਰਨ ਇਹ ਜ਼ਰੂਰੀ ਸੀ ਹਰੇਕ ਸੇਵਾ ਲਈ, ਇਸਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਨੂੰ ਬਣਾਈ ਰੱਖੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਤੁਸੀਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜਾਂ ਨਵੀਂ ਨਿਰਭਰਤਾ ਸਥਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਸਾਰੇ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਤੁਹਾਨੂੰ ਉਸ ਸਮੇਂ ਨੂੰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅਗਲੇ ਨਵੇਂ ਸੰਸਕਰਣ ਨੂੰ ਉਸ ਸਮੇਂ ਦੇ ਨਾਲ ਤੈਨਾਤ ਕਰਨ ਜਾ ਰਹੇ ਹੋ ਜਦੋਂ devops ਜ਼ਰੂਰੀ ਵਾਤਾਵਰਣ ਸੈਟਿੰਗਾਂ ਕਰਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਜਾਣਾ ਆਸਾਨ ਹੈ ਜਿੱਥੇ ਸਾਡਾ ਵਾਤਾਵਰਣ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਾਰੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕੁਝ ਵੱਖਰਾ ਹੋਵੇਗਾ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ QA ਵਾਤਾਵਰਣ ਵਿੱਚ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਕੁਝ ਸੰਸਕਰਣ ਹੋਣਗੇ, ਅਤੇ ਇੱਕ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਵੱਖੋ-ਵੱਖਰੇ ਹੋਣਗੇ, ਜਿਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਣਗੀਆਂ।
2. ਨਿਰਭਰਤਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਤੁਹਾਡੀ ਅਰਜ਼ੀ। ਇਹ ਤੁਹਾਡੇ 'ਤੇ ਨਹੀਂ, ਪਰ ਦੂਜੀ ਟੀਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਅਰਥਾਤ, ਸਰਵਰਾਂ ਦੀ ਸਾਂਭ-ਸੰਭਾਲ ਕਰਨ ਵਾਲੀ ਡਿਵੋਪਸ ਟੀਮ ਤੋਂ। ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਢੁਕਵਾਂ ਕੰਮ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਸ ਦਾ ਵੇਰਵਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
3. ਉਸ ਸਮੇਂ, ਅਸੀਂ ਉਹਨਾਂ ਵੱਡੀਆਂ ਵੱਡੀਆਂ ਮੋਨੋਲਿਥਾਂ ਨੂੰ ਵੀ ਵੱਖ-ਵੱਖ ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੰਡਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਕਿਉਂਕਿ ਅਸੀਂ ਸਮਝਦੇ ਸੀ ਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੋਣਗੇ। ਉਸ ਸਮੇਂ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਵਿੱਚੋਂ 100 ਤੋਂ ਵੱਧ ਸਨ। ਹਰੇਕ ਨਵੀਂ ਸੇਵਾ ਲਈ, ਇੱਕ ਵੱਖਰੀ ਨਵੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਬਣਾਉਣੀ ਜ਼ਰੂਰੀ ਸੀ, ਜਿਸਦੀ ਸਾਂਭ-ਸੰਭਾਲ ਅਤੇ ਤਾਇਨਾਤੀ ਦੀ ਵੀ ਲੋੜ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਇਕ ਕਾਰ ਦੀ ਨਹੀਂ, ਪਰ ਘੱਟੋ ਘੱਟ ਦੋ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਸ ਸਭ ਵਿੱਚ QA ਵਾਤਾਵਰਣ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਨਵੇਂ ਸਿਸਟਮ ਬਣਾਉਣਾ ਅਤੇ ਚਲਾਉਣਾ ਹੋਰ ਵੀ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਗੁੰਝਲਦਾਰ, ਮਹਿੰਗਾ ਅਤੇ ਲੰਮੀ ਪ੍ਰਕਿਰਿਆ.

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

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

Nomad 'ਤੇ ਜਾਓ

Nomad HashiCorp ਦਾ ਇੱਕ ਉਤਪਾਦ ਹੈ। ਉਹ ਆਪਣੇ ਹੋਰ ਹੱਲਾਂ ਲਈ ਵੀ ਜਾਣੇ ਜਾਂਦੇ ਹਨ:

"ਕੌਂਸਲ" ਸੇਵਾ ਖੋਜ ਲਈ ਇੱਕ ਸਾਧਨ ਹੈ।

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

"ਆਵਾਗਰ" ਤੁਹਾਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਾਂ ਕਲਾਉਡ ਵਿੱਚ ਖਾਸ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਰਾਹੀਂ ਤੈਨਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

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

ਤੁਹਾਨੂੰ ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਨੋਮੈਡ ਵਿੱਚ ਤਾਇਨਾਤ ਕਰਨ ਦੀ ਕੀ ਲੋੜ ਹੈ?

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

ਜਦੋਂ ਅਸੀਂ ਨੋਮੈਡ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ HCL ਭਾਸ਼ਾ ਨੂੰ ਇਸਦੇ ਜਾਣਕਾਰੀ ਫਾਈਲ ਫਾਰਮੈਟ ਵਜੋਂ ਵਰਤਦਾ ਹੈ, ਜਿਸਦਾ ਅਰਥ ਹੈ HashiCorp ਸੰਰਚਨਾ ਭਾਸ਼ਾ. ਇਹ Yaml ਦਾ ਇੱਕ ਸੁਪਰਸੈੱਟ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਤੁਹਾਡੀ ਸੇਵਾ ਦਾ ਵਰਣਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ Nomad ਸ਼ਬਦਾਂ ਵਿੱਚ।

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

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

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

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

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

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

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

ਜਦੋਂ ਨੋਮੈਡ ਸੇਵਾ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।

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

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

ਮਨੁੱਖੀ ਸੰਸਾਧਨਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪਰਿਵਰਤਨ ਵਿੱਚ ਸਾਨੂੰ ਕਿੰਨਾ ਖਰਚਾ ਆਇਆ?

ਸਾਰੀ ਕੰਪਨੀ ਨੂੰ ਨੋਮੈਡ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਵਿੱਚ ਲਗਭਗ 5-6 ਮਹੀਨੇ ਲੱਗ ਗਏ। ਅਸੀਂ ਸੇਵਾ-ਦਰ-ਸੇਵਾ ਦੇ ਆਧਾਰ 'ਤੇ ਚਲੇ ਗਏ, ਪਰ ਕਾਫ਼ੀ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਨਾਲ। ਹਰੇਕ ਟੀਮ ਨੂੰ ਸੇਵਾਵਾਂ ਲਈ ਆਪਣੇ-ਆਪਣੇ ਕੰਟੇਨਰ ਬਣਾਉਣੇ ਪਏ।

ਅਸੀਂ ਅਜਿਹੀ ਪਹੁੰਚ ਅਪਣਾਈ ਹੈ ਕਿ ਹਰੇਕ ਟੀਮ ਆਪਣੇ ਸਿਸਟਮਾਂ ਦੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਲਈ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। Devops ਤੈਨਾਤੀ ਲਈ ਲੋੜੀਂਦਾ ਆਮ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਰਥਾਤ, ਕਲੱਸਟਰ ਲਈ ਸਮਰਥਨ, CI ਸਿਸਟਮ ਲਈ ਸਮਰਥਨ, ਆਦਿ। ਅਤੇ ਉਸ ਸਮੇਂ, ਸਾਡੇ ਕੋਲ 60 ਤੋਂ ਵੱਧ ਸਿਸਟਮ ਨੋਮੈਡ ਵਿੱਚ ਚਲੇ ਗਏ ਸਨ, ਜੋ ਕਿ ਲਗਭਗ 2 ਹਜ਼ਾਰ ਕੰਟੇਨਰਾਂ ਦੇ ਬਰਾਬਰ ਸਨ।

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

Nomad ਨੂੰ ਛੱਡਣ ਦੇ ਕਾਰਨ

ਨੋਮੈਡ ਅਤੇ ਡੌਕਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੈਨਾਤੀ 'ਤੇ ਸਵਿਚ ਕਰਨ ਨਾਲ ਸਾਨੂੰ ਹੋਰ ਕੀ ਫਾਇਦੇ ਹੋਏ ਹਨ?

1. ਸਾਨੂੰ ਬਰਾਬਰ ਸ਼ਰਤਾਂ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਸਾਰੇ ਵਾਤਾਵਰਣ ਲਈ. ਵਿਕਾਸ ਵਿੱਚ, QA ਵਾਤਾਵਰਣ, ਪੂਰਵ-ਉਤਪਾਦਨ, ਉਤਪਾਦਨ, ਉਹੀ ਕੰਟੇਨਰ ਚਿੱਤਰ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਉਸੇ ਨਿਰਭਰਤਾ ਦੇ ਨਾਲ. ਇਸ ਅਨੁਸਾਰ, ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਕੋਈ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ ਕਿ ਉਤਪਾਦਨ ਵਿੱਚ ਕੀ ਖਤਮ ਹੋਵੇਗਾ ਉਹ ਨਹੀਂ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਾਂ ਤੁਹਾਡੇ ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ ਸੀ।
2. ਅਸੀਂ ਇਹ ਵੀ ਪਾਇਆ ਕਿ ਇਹ ਕਾਫ਼ੀ ਹੈ ਨਵੀਂ ਸੇਵਾ ਜੋੜਨਾ ਆਸਾਨ ਹੈ. ਤੈਨਾਤੀ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਕੋਈ ਵੀ ਨਵਾਂ ਸਿਸਟਮ ਬਹੁਤ ਹੀ ਅਸਾਨੀ ਨਾਲ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਸ ਉਸ ਰਿਪੋਜ਼ਟਰੀ 'ਤੇ ਜਾਓ ਜੋ ਸੰਰਚਨਾ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਉੱਥੇ ਆਪਣੇ ਸਿਸਟਮ ਲਈ ਇੱਕ ਹੋਰ ਸੰਰਚਨਾ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਹੋ। ਤੁਸੀਂ devops ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਕੋਸ਼ਿਸ਼ ਦੇ ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ।
3. ਸਾਰੇ ਸੰਰਚਨਾ ਫਾਇਲ ਇੱਕ ਆਮ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਮੀਖਿਆ ਅਧੀਨ ਨਿਕਲਿਆ. ਉਸ ਸਮੇਂ ਜਦੋਂ ਅਸੀਂ ਆਪਣੇ ਸਿਸਟਮਾਂ ਨੂੰ ਵਰਚੁਅਲ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਤੈਨਾਤ ਕੀਤਾ, ਅਸੀਂ Ansible ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜਿਸ ਵਿੱਚ ਸੰਰਚਨਾ ਉਸੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਨ। ਹਾਲਾਂਕਿ, ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਸ ਨਾਲ ਕੰਮ ਕਰਨਾ ਥੋੜ੍ਹਾ ਹੋਰ ਮੁਸ਼ਕਲ ਸੀ। ਇੱਥੇ ਸੰਰਚਨਾ ਅਤੇ ਕੋਡ ਦੀ ਮਾਤਰਾ ਜੋ ਤੁਹਾਨੂੰ ਸੇਵਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ ਬਹੁਤ ਘੱਟ ਹੋ ਗਈ ਹੈ। ਨਾਲ ਹੀ, devops ਲਈ ਇਸਨੂੰ ਠੀਕ ਕਰਨਾ ਜਾਂ ਬਦਲਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ। ਪਰਿਵਰਤਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ, Nomad ਦੇ ਇੱਕ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ, ਉਹ ਉਸੇ ਥਾਂ ਤੇ ਸਥਿਤ ਸਾਰੀਆਂ ਓਪਰੇਟਿੰਗ ਫਾਈਲਾਂ ਨੂੰ ਲੈ ਅਤੇ ਬਲਕ ਅੱਪਡੇਟ ਕਰ ਸਕਦੇ ਹਨ।

ਪਰ ਸਾਨੂੰ ਕਈ ਨੁਕਸਾਨਾਂ ਦਾ ਵੀ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ:

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

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

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

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

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਤਬਦੀਲੀ

ਮੈਂ ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀਆਂ ਬੁਨਿਆਦੀ ਧਾਰਨਾਵਾਂ ਬਾਰੇ ਅਤੇ ਨੋਮੈਡ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ ਬਾਰੇ ਥੋੜਾ ਦੱਸਾਂਗਾ।

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

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

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

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

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

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

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

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

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

ਹੈਲਮ ਵਿੱਚ ਬੁਨਿਆਦੀ ਧਾਰਨਾਵਾਂ

ਹੈਲਮ ਹੈ ਪੈਕੇਜ ਮੈਨੇਜਰ ਕੁਬਰਨੇਟਸ ਲਈ. ਇਹ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪੈਕੇਜ ਪ੍ਰਬੰਧਕਾਂ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਸਮਾਨ ਹੈ। ਉਹ ਤੁਹਾਨੂੰ ਇੱਕ ਸੇਵਾ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਤੈਨਾਤੀ nginx, ਤੈਨਾਤੀ php-fpm, Ingress ਲਈ ਸੰਰਚਨਾ, configmaps (ਇਹ ਇੱਕ ਅਜਿਹੀ ਇਕਾਈ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ ਸਿਸਟਮ ਲਈ env ਅਤੇ ਹੋਰ ਮਾਪਦੰਡ ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ) ਇਸ ਤਰ੍ਹਾਂ- ਚਾਰਟ ਕਹਿੰਦੇ ਹਨ। ਉਸੇ ਸਮੇਂ ਹੈਲਮ ਕੁਬਰਨੇਟਸ ਦੇ ਸਿਖਰ 'ਤੇ ਚੱਲਦਾ ਹੈ. ਯਾਨੀ, ਇਹ ਇੱਕ ਪਾਸੇ ਖੜ੍ਹਾ ਕੋਈ ਸਿਸਟਮ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਕਿਊਬ ਦੇ ਅੰਦਰ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਇੱਕ ਹੋਰ ਸੇਵਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਕੰਸੋਲ ਕਮਾਂਡ ਦੁਆਰਾ ਇਸਦੇ API ਦੁਆਰਾ ਇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹੋ। ਇਸਦੀ ਸਹੂਲਤ ਅਤੇ ਸੁੰਦਰਤਾ ਇਹ ਹੈ ਕਿ ਭਾਵੇਂ ਹੈਲਮ ਟੁੱਟ ਜਾਵੇ ਜਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕਲੱਸਟਰ ਤੋਂ ਹਟਾ ਦਿੰਦੇ ਹੋ, ਤੁਹਾਡੀਆਂ ਸੇਵਾਵਾਂ ਅਲੋਪ ਨਹੀਂ ਹੋਣਗੀਆਂ, ਕਿਉਂਕਿ ਹੈਲਮ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਸਿਰਫ ਸਿਸਟਮ ਨੂੰ ਚਾਲੂ ਕਰਨ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਖੁਦ ਫਿਰ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸੇਵਾਵਾਂ ਦੀ ਸਥਿਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

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

ਹੈਲਮ ਸਾਡੇ ਲਈ ਕੁਝ ਹੋਰ ਧਾਰਨਾਵਾਂ ਜੋੜਦਾ ਹੈ।

ਚਾਰਟ - ਇਹ ਤੁਹਾਡੀ ਸੇਵਾ ਦਾ ਵਰਣਨ ਹੈ। ਦੂਜੇ ਪੈਕੇਜ ਪ੍ਰਬੰਧਕਾਂ ਵਿੱਚ ਇਸਨੂੰ ਇੱਕ ਪੈਕੇਜ, ਬੰਡਲ ਜਾਂ ਕੁਝ ਸਮਾਨ ਕਿਹਾ ਜਾਵੇਗਾ। ਇੱਥੇ ਇਸਨੂੰ ਚਾਰਟ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਮੁੱਲ ਵੇਰੀਏਬਲ ਹਨ ਜੋ ਤੁਸੀਂ ਟੈਂਪਲੇਟਸ ਤੋਂ ਆਪਣੀ ਸੰਰਚਨਾ ਬਣਾਉਣ ਲਈ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ।

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

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

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

ਇਸ ਨੇ ਸਾਨੂੰ ਕੀ ਦਿੱਤਾ?

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

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

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

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

ਸਿੱਟਾ

ਕੁਬਰਨੇਟਸ ਸੇਵਾ Nomad ਨਾਲੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਜਾਪਦੀ ਹੈ।

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

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

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

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

ਸਰੋਤ: www.habr.com