ਡੀਵੋਕਸ ਯੂਕੇ. ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ: ਬਲੂ/ਗਰੀਨ ਡਿਪਲਾਇਮੈਂਟ, ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਆਟੋਮੇਸ਼ਨ। ਭਾਗ 2

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

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

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

ਡੀਵੋਕਸ ਯੂਕੇ. ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ: ਬਲੂ/ਗਰੀਨ ਡਿਪਲਾਇਮੈਂਟ, ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਆਟੋਮੇਸ਼ਨ। ਭਾਗ 1

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

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

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

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

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

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

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

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

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

ਸਿਸਟਮ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਕਿ ਸਾਰੀਆਂ ਅੱਪਡੇਟ ਕੀਤੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ, ਡਿਪਲੋਇਰ ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰੇਗਾ ਅਤੇ ਸਹੀ confd ਪਾਸ ਕਰੇਗਾ, ਜੋ ha-proxy ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰੇਗਾ।

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

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

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

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

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

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

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

ਇਹ ਕੁਬਰਨੇਟਸ ਤੈਨਾਤੀਆਂ ਨੂੰ ਆਰਕੇਸਟ੍ਰੇਟ ਕਰਨ ਲਈ ਇੱਕ ਸਾਧਨ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ:

• ਨੀਲਾ/ਹਰਾ ਤੈਨਾਤੀ;
• ਇੱਕ ਬਾਹਰੀ ਲੋਡ ਬੈਲੈਂਸਰ ਸਥਾਪਤ ਕਰਨਾ;
• ਤੈਨਾਤੀ ਵਰਣਨ ਪ੍ਰਬੰਧਨ;
• ਅਸਲ ਤੈਨਾਤੀ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ;
• ਤੈਨਾਤੀ ਦੌਰਾਨ ਸਿਹਤ ਜਾਂਚਾਂ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ;
• ਪੌਡ ਵਿੱਚ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਨੂੰ ਲਾਗੂ ਕਰਨਾ।

ਇਹ ਡਿਪਲਾਇਰ ਕੁਬਰਨੇਟਸ API ਦੇ ਸਿਖਰ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਹੈਂਡਲ ਅਤੇ ਤੈਨਾਤੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ REST API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਸਟ੍ਰੀਮਿੰਗ ਲੌਗਸ ਲਈ ਇੱਕ Websocket API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇਹ ਲੋਡ ਬੈਲੈਂਸਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਡੇਟਾ ਨੂੰ etcd ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਇਸਲਈ ਤੁਹਾਨੂੰ ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ ਸਹਾਇਤਾ ਦੇ ਨਾਲ ha-proxy ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਆਸਾਨੀ ਨਾਲ ਆਪਣੀ ਖੁਦ ਦੀ ਲੋਡ ਬੈਲੈਂਸਰ ਸੰਰਚਨਾ ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰੋ। Amdatu Deployer ਗੋ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਕੁਬਰਨੇਟਸ ਖੁਦ, ਅਤੇ ਅਪਾਚੇ ਦੁਆਰਾ ਲਾਇਸੰਸਸ਼ੁਦਾ ਹੈ।

ਡਿਪਲਾਇਰ ਦੇ ਇਸ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਹੇਠਾਂ ਦਿੱਤੇ ਡਿਪਲਾਇਮੈਂਟ ਡਿਸਕ੍ਰਿਪਟਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜੋ ਮੈਨੂੰ ਲੋੜੀਂਦੇ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

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

ਇੱਕ ਹੋਰ ਟੂਲ ਜੋ ਓਪਨ-ਸੋਰਸ ਅਮਡਾਟੂ ਪ੍ਰੋਜੈਕਟ ਦਾ ਹਿੱਸਾ ਹੈ ਉਹ ਹੈ Deploymentctl. ਇਸ ਵਿੱਚ ਤੈਨਾਤੀਆਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ, ਤੈਨਾਤੀ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ UI ਹੈ, ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਕਾਲਬੈਕ ਲਈ ਵੈਬਹੁੱਕ ਸ਼ਾਮਲ ਹਨ। ਤੁਸੀਂ UI ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ ਕਿਉਂਕਿ Amdatu ਡਿਪਲੋਅਰ ਖੁਦ ਇੱਕ REST API ਹੈ, ਪਰ ਇਹ ਇੰਟਰਫੇਸ ਬਿਨਾਂ ਕਿਸੇ API ਨੂੰ ਸ਼ਾਮਲ ਕੀਤੇ ਤੁਹਾਡੇ ਲਈ ਤੈਨਾਤੀ ਨੂੰ ਬਹੁਤ ਸੌਖਾ ਬਣਾ ਸਕਦਾ ਹੈ। Angular 2 ਦੀ ਵਰਤੋਂ ਕਰਕੇ Deploymentctl OSGi/Vertx ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ।

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

ਇੱਥੇ ਅਸੀਂ ਇੱਕ HTTP ਸਰਵਰ ਬਣਾ ਰਹੇ ਹਾਂ ਜੋ ਸਿਰਫ /health ਲਈ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਇਸਲਈ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਸਿਰਫ ਸਿਹਤ ਜਾਂਚ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਜੇਕਰ ਚੈੱਕ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹੇਠਾਂ ਦਿਖਾਇਆ ਗਿਆ JSON ਢਾਂਚਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਡਿਪਲੋਇਰ ਦੁਆਰਾ ਤੈਨਾਤ ਕੀਤਾ ਜਾਵੇਗਾ, ਸੁਨੇਹਾ ਜੋ ਤੁਸੀਂ ਫਾਈਲ ਦੇ ਸਿਖਰ 'ਤੇ ਦੇਖਦੇ ਹੋ, ਅਤੇ ਬੂਲੀਅਨ ਡੇਟਾ ਕਿਸਮ - ਭਾਵੇਂ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਜਾਂ ਨਹੀਂ।

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

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

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

ਜੇਕਰ ਤੁਸੀਂ ਹੁਣ ਕਮਾਂਡ ~ kubectl get pods ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਿਸਟਮ 20 ਸਕਿੰਟਾਂ ਲਈ "ਫ੍ਰੀਜ਼" ਹੋ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਦੌਰਾਨ ha-proxy ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, ਪੌਡ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਡੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਤੈਨਾਤੀ ਲੌਗ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ.

ਮੈਂ ਵੀਡੀਓ ਤੋਂ 20 ਸਕਿੰਟ ਦੀ ਉਡੀਕ ਨੂੰ ਕੱਟ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਹੁਣ ਤੁਸੀਂ ਸਕ੍ਰੀਨ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਪਹਿਲਾ ਸੰਸਕਰਣ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਸਭ ਸਿਰਫ UI ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਗਿਆ ਸੀ।

ਹੁਣ ਦੂਜੇ ਸੰਸਕਰਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਮੈਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੰਦੇਸ਼ ਨੂੰ "ਹੈਲੋ, ਕੁਬਰਨੇਟਸ!" ਤੋਂ ਬਦਲਦਾ ਹਾਂ. “Hello, Deployer!” ਉੱਤੇ, ਸਿਸਟਮ ਇਸ ਚਿੱਤਰ ਨੂੰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਡੌਕਰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਸਿਰਫ਼ Deploymentctl ਵਿੰਡੋ ਵਿੱਚ “Deploy” ਬਟਨ ਉੱਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਾਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਡਿਪਲਾਇਮੈਂਟ ਲੌਗ ਆਪਣੇ ਆਪ ਉਸੇ ਤਰ੍ਹਾਂ ਲਾਂਚ ਹੋ ਜਾਂਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪਹਿਲੇ ਸੰਸਕਰਣ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਵੇਲੇ ਹੋਇਆ ਸੀ।

ਕਮਾਂਡ ~ kubectl get pods ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵਰਤਮਾਨ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੇ 2 ਸੰਸਕਰਣ ਚੱਲ ਰਹੇ ਹਨ, ਪਰ ਫਰੰਟਐਂਡ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਸੀਂ ਅਜੇ ਵੀ ਸੰਸਕਰਣ 1 ਚਲਾ ਰਹੇ ਹਾਂ।

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

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

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

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

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

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

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

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

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

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

ਨਵੀਂ ਮਸ਼ੀਨ ਸਕੇਲਿੰਗ ਸਮੂਹ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਨੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਮਾਸਟਰ ਦੀ ਰਜਿਸਟਰੀ ਵਿੱਚ ਰਜਿਸਟਰ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਨਤੀਜੇ ਵਾਲੇ ਨੋਡਾਂ 'ਤੇ ਵਰਤੋਂ ਲਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਸਕਦੇ ਹੋ। ਸਕੇਲ ਡਾਊਨ ਕਰਨ ਲਈ ਵਧੇਰੇ ਮਿਹਨਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਅਜਿਹਾ ਕਦਮ "ਬੇਲੋੜੀਆਂ" ਮਸ਼ੀਨਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਵਿਨਾਸ਼ ਵੱਲ ਅਗਵਾਈ ਨਹੀਂ ਕਰਦਾ। ਅਜਿਹੀ ਸਥਿਤੀ ਨੂੰ ਰੋਕਣ ਲਈ, ਤੁਹਾਨੂੰ ਨੋਡਾਂ ਨੂੰ "ਅਨਿਸ਼ਚਿਤ" ਸਥਿਤੀ 'ਤੇ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡਿਫਾਲਟ ਸ਼ਡਿਊਲਰ ਡੈਮਨਸੈਟ ਪੌਡਸ ਨੂੰ ਤਹਿ ਕਰਨ ਵੇਲੇ ਇਹਨਾਂ ਨੋਡਾਂ ਨੂੰ ਅਣਡਿੱਠ ਕਰੇਗਾ। ਸ਼ਡਿਊਲਰ ਇਹਨਾਂ ਸਰਵਰਾਂ ਤੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਮਿਟਾਏਗਾ, ਪਰ ਉੱਥੇ ਕੋਈ ਨਵਾਂ ਕੰਟੇਨਰ ਵੀ ਲਾਂਚ ਨਹੀਂ ਕਰੇਗਾ। ਅਗਲਾ ਕਦਮ ਡਰੇਨ ਨੋਡ ਨੂੰ ਬਾਹਰ ਕੱਢਣਾ ਹੈ, ਯਾਨੀ ਇਸ ਤੋਂ ਚੱਲ ਰਹੇ ਪੌਡਾਂ ਨੂੰ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ, ਜਾਂ ਹੋਰ ਨੋਡਾਂ ਵਿੱਚ ਇਸ ਲਈ ਲੋੜੀਂਦੀ ਸਮਰੱਥਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾ ਲੈਂਦੇ ਹੋ ਕਿ ਇਹਨਾਂ ਨੋਡਾਂ 'ਤੇ ਹੁਣ ਕੋਈ ਕੰਟੇਨਰ ਨਹੀਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਤੋਂ ਹਟਾ ਸਕਦੇ ਹੋ। ਇਸ ਤੋਂ ਬਾਅਦ, ਉਹ ਬਸ ਕੁਬਰਨੇਟਸ ਲਈ ਮੌਜੂਦ ਰਹਿਣਗੇ. ਅੱਗੇ, ਤੁਹਾਨੂੰ ਬੇਲੋੜੇ ਨੋਡਾਂ ਜਾਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਅਯੋਗ ਕਰਨ ਲਈ AWS API ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਤੁਸੀਂ Amdatu Scalerd, AWS API ਦੇ ਸਮਾਨ ਇੱਕ ਹੋਰ ਓਪਨ-ਸੋਰਸ ਸਕੇਲਿੰਗ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਨੋਡਾਂ ਨੂੰ ਜੋੜਨ ਜਾਂ ਹਟਾਉਣ ਲਈ ਇੱਕ CLI ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾ ਹੇਠ ਦਿੱਤੀ json ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸ਼ਡਿਊਲਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ.

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

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

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

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

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

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

ਕੁਝ ਵਿਗਿਆਪਨ 🙂

ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $4.99 ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਲਾਉਡ VPS, ਪ੍ਰਵੇਸ਼-ਪੱਧਰ ਦੇ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਐਨਾਲਾਗ, ਜਿਸਦੀ ਖੋਜ ਸਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਲਈ ਕੀਤੀ ਗਈ ਸੀ: VPS (KVM) E5-2697 v3 (6 ਕੋਰ) 10GB DDR4 480GB SSD 1Gbps ਤੋਂ $19 ਜਾਂ ਸਰਵਰ ਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਨਾ ਹੈ ਬਾਰੇ ਪੂਰੀ ਸੱਚਾਈ? (RAID1 ਅਤੇ RAID10 ਦੇ ਨਾਲ ਉਪਲਬਧ, 24 ਕੋਰ ਤੱਕ ਅਤੇ 40GB DDR4 ਤੱਕ)।

ਡੈਲ R730xd ਐਮਸਟਰਡਮ ਵਿੱਚ ਈਕੁਇਨਿਕਸ ਟੀਅਰ IV ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 2 ਗੁਣਾ ਸਸਤਾ? ਇੱਥੇ ਹੀ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ਟੀਵੀ $199 ਤੋਂ ਨੀਦਰਲੈਂਡ ਵਿੱਚ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ਤੋਂ! ਬਾਰੇ ਪੜ੍ਹੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਾਰਪੋਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਡੇਲ R730xd E5-2650 v4 ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਸ 9000 ਯੂਰੋ ਦੀ ਕੀਮਤ ਦੇ ਇੱਕ ਪੈਸੇ ਲਈ?

ਸਰੋਤ: www.habr.com