ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਸਤ ਕਰਨ ਲਈ ਲੋੜਾਂ

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

ਇਹ ਲੈਕਚਰ ਇਸ ਦਾ ਹਿੱਸਾ ਹੈ "ਕੁਬਰਨੇਟਸ 'ਤੇ ਸਲਰਮ ਨਾਈਟ ਸਕੂਲ" ਤੁਸੀਂ ਈਵਨਿੰਗ ਸਕੂਲ ਦੇ ਓਪਨ ਸਿਧਾਂਤਕ ਲੈਕਚਰ ਦੇਖ ਸਕਦੇ ਹੋ YouTube 'ਤੇ, ਇੱਕ ਪਲੇਲਿਸਟ ਵਿੱਚ ਗਰੁੱਪ ਕੀਤਾ ਗਿਆ. ਉਹਨਾਂ ਲਈ ਜੋ ਵੀਡੀਓ ਦੀ ਬਜਾਏ ਟੈਕਸਟ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ, ਅਸੀਂ ਇਹ ਲੇਖ ਤਿਆਰ ਕੀਤਾ ਹੈ.

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

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

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

ਜੇ ਅਸੀਂ ਉਸ ਯੋਜਨਾ ਦੇ ਅਨੁਸਾਰ ਬੋਲਦੇ ਹਾਂ ਜਿਸ ਬਾਰੇ ਮੈਂ ਗੱਲ ਕਰਾਂਗਾ, ਤਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਬਰੈਕਟਾਂ ਵਿੱਚ ਇਹ ਲਿਖਿਆ ਹੁੰਦਾ ਹੈ (TL;DR) - “ਬਹੁਤ ਲੰਮਾ; ਨਾ ਪੜ੍ਹੋ" ਮੇਰੀ ਅੱਜ ਦੀ ਪੇਸ਼ਕਾਰੀ ਵਿੱਚ ਬੇਅੰਤ ਸੂਚੀਆਂ ਸ਼ਾਮਲ ਹੋਣਗੀਆਂ।

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

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

ਇਸ ਲਈ ਪੇਸ਼ਕਾਰੀ ਇੰਨੀ ਵੱਡੀ ਸੂਚੀ ਬਣ ਗਈ। ਮਾਫ਼ ਕਰਨਾ। ਮੈਂ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਦੱਸਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਤਾਂ ਜੋ ਇਹ ਬੋਰਿੰਗ ਨਾ ਹੋਵੇ.

ਅਸੀਂ ਹੁਣ ਕੀ ਦੇਖਣ ਜਾ ਰਹੇ ਹਾਂ:

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

ਲਾਗ

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

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

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

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

ਇੱਥੇ ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਲੌਗਾਂ ਨਾਲ ਅੱਗੇ ਕੀ ਕਰੋਗੇ? ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਸਪੱਸ਼ਟ ਹੈ, ਸਾਡੇ ਕੋਲ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ kubectl logs ਅਤੇ ਇਹਨਾਂ "ਪੋਡਾਂ" ਦੇ ਇਹਨਾਂ ਲੌਗਾਂ ਨੂੰ ਦੇਖੋ। ਪਰ, ਸ਼ਾਇਦ, ਇਹ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਵਿਕਲਪ ਨਹੀਂ ਹੈ - ਲੌਗਸ ਦੇ ਨਾਲ ਕੁਝ ਹੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ.

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

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

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵਿਚਾਰ, ਮੈਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਦੁਹਰਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਇਹ ਹੈ ਕਿ ਡੌਕਰ ਦੇ ਅੰਦਰ, ਖਾਸ ਤੌਰ 'ਤੇ ਕੁਬਰਨੇਟਸ ਦੇ ਅੰਦਰ, ਤੁਹਾਡੇ ਲੌਗਸ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਇੱਕ ਬਹੁਤ ਬੁਰਾ ਵਿਚਾਰ ਹੈ.

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

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

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

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

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

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

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

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

ਕੌਨਫਿਗਰੇਸ਼ਨ

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

ਡੌਕਰ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਮਿਆਰਾਂ ਬਾਰੇ ਹੈ. ਅਤੇ ਅਮਲੀ ਤੌਰ 'ਤੇ ਹਰ ਚੀਜ਼ ਲਈ ਮਾਪਦੰਡ ਹਨ: ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਮਿਆਰ, ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਮਿਆਰ।

ਅਤੇ ਇਹ ਚੀਜ਼ - ਅਸੀਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਵਰਤਿਆ ਸੀ, ਇਹ ਕੰਟੇਨਰਾਂ ਦੇ ਆਗਮਨ ਨਾਲ ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਸਿੱਧ ਹੋ ਗਿਆ ਸੀ - ਇਸ ਚੀਜ਼ ਨੂੰ ENV (ਵਾਤਾਵਰਣ) ਵੇਰੀਏਬਲ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਯਾਨੀ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਜੋ ਤੁਹਾਡੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਹਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦਾ ਇੱਕ ਆਦਰਸ਼ ਤਰੀਕਾ ਹੈ, ਕਿਉਂਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ JAVA, Python, Go, Perl, God forbid ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਹਨ, ਅਤੇ ਉਹ ਸਾਰੇ ਡੇਟਾਬੇਸ ਹੋਸਟ, ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ, ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ ਵੇਰੀਏਬਲ ਪੜ੍ਹ ਸਕਦੇ ਹਨ, ਤਾਂ ਇਹ ਆਦਰਸ਼ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਚਾਰ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹਨ ਜੋ ਡੇਟਾਬੇਸ ਪਲਾਨ ਵਿੱਚ ਉਸੇ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਇੱਥੇ ਕੋਈ ਹੋਰ ਵੱਖਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਨਹੀਂ ਹਨ।

ਹਰ ਚੀਜ਼ ਨੂੰ ENV ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਡਿਪਲਾਇਮੈਂਟ ਦੇ ਅੰਦਰ ENV ਵੇਰੀਏਬਲ ਘੋਸ਼ਿਤ ਕਰਨ ਦਾ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਜੇਕਰ ਅਸੀਂ ਗੁਪਤ ਡੇਟਾ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਤੁਰੰਤ ENV ਵੇਰੀਏਬਲ (ਪਾਸਵਰਡ ਤੋਂ ਡੇਟਾਬੇਸ, ਆਦਿ) ਦੇ ਗੁਪਤ ਡੇਟਾ ਨੂੰ ਇੱਕ ਗੁਪਤ ਵਿੱਚ ਧੱਕ ਸਕਦੇ ਹਾਂ, ਇੱਕ ਗੁਪਤ ਕਲੱਸਟਰ ਬਣਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਤੈਨਾਤੀ ਵਿੱਚ ENV ਵਰਣਨ ਵਿੱਚ ਸੰਕੇਤ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਘੋਸ਼ਣਾ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ। ਇਸ ਵੇਰੀਏਬਲ ਦਾ ਮੁੱਲ, ਅਤੇ ਇਸ ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ ਵੇਰੀਏਬਲ ਦਾ ਮੁੱਲ ਗੁਪਤ ਤੋਂ ਪੜ੍ਹਿਆ ਜਾਵੇਗਾ। ਇਹ ਮਿਆਰੀ ਕੁਬਰਨੇਟਸ ਵਿਵਹਾਰ ਹੈ। ਅਤੇ ਇਹ ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਆਦਰਸ਼ ਵਿਕਲਪ ਹੈ। ਸਿਰਫ਼ ਕੋਡ ਪੱਧਰ 'ਤੇ, ਇਹ ਦੁਬਾਰਾ ਡਿਵੈਲਪਰਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ DevOps ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ: “ਮੁੰਡੇ, ਕਿਰਪਾ ਕਰਕੇ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਵਾਤਾਵਰਨ ਵੇਰੀਏਬਲ ਪੜ੍ਹਨਾ ਸਿਖਾਓ। ਅਤੇ ਅਸੀਂ ਸਾਰੇ ਖੁਸ਼ ਰਹਾਂਗੇ।”

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

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

ਸਿਰਫ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਸੰਰਚਨਾ ਉਹ ਨਹੀਂ ਹਨ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ. Config.pi ਇੱਕ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ ਜੋ ਵਰਤਣ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਜਾਂ ਤੁਹਾਡੇ ਆਪਣੇ ਫਾਰਮੈਟ ਵਿੱਚ ਕੁਝ ਸੰਰਚਨਾ, ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਗਿਫਟਡ - ਇਹ ਉਹ ਸੰਰਚਨਾ ਵੀ ਨਹੀਂ ਹੈ ਜਿਸਦਾ ਮੇਰਾ ਮਤਲਬ ਹੈ।

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

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

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

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

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

ਸਿਹਤ ਜਾਂਚ

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

ਇਸ URL ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਵੇਲੇ, ਇਸ ਅਨੁਸਾਰ, ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਤਾਂ "ਹਾਂ, ਠੀਕ ਹੈ, ਮੇਰੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, 200" ਜਾਂ "ਨਹੀਂ, ਮੇਰੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਨਹੀਂ ਹੈ, ਕੁਝ 500" ਕਹਿੰਦਾ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਜੇਕਰ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ http ਨਹੀਂ ਹੈ, ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਹੁਣ ਕਿਸੇ ਕਿਸਮ ਦੇ ਡੈਮਨ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਾਂ ਕਿ ਸਿਹਤ ਜਾਂਚ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਭਾਵ, ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ, ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ http ਨਹੀਂ ਹੈ, ਤਾਂ ਸਭ ਕੁਝ ਸਿਹਤ ਜਾਂਚ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਫਾਈਲ ਵਿੱਚ ਕੁਝ ਜਾਣਕਾਰੀ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਆਪਣੇ ਡੈਮਨ ਲਈ ਕੁਝ ਖਾਸ ਕਮਾਂਡ ਲੈ ਕੇ ਆ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ, daemon status, ਜੋ ਕਹੇਗਾ "ਹਾਂ, ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਡੈਮਨ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਇਹ ਜ਼ਿੰਦਾ ਹੈ।"

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

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

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

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

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

ਯਾਨੀ ਤੁਹਾਡੀ ਅਰਜ਼ੀ, ਜਦੋਂ ਕੋਈ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ /health, ਇਹ ਸਿਰਫ਼ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, “200, ਠੀਕ ਹੈ”, ਇਹ ਪਹਿਲਾਂ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਡੇਟਾਬੇਸ ਵਿੱਚ, ਇਸ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਉੱਥੇ ਕੁਝ ਬਹੁਤ ਹੀ ਬੁਨਿਆਦੀ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਨੂੰ ਚੁਣੋ, ਸਿਰਫ਼ ਇਹ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਇੱਥੇ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਹੈ। ਡਾਟਾਬੇਸ ਅਤੇ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਤੋਂ ਪੁੱਛਗਿੱਛ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਇਹ ਸਭ ਸਫਲ ਰਿਹਾ, ਤਾਂ ਜਵਾਬ ਹੈ "200, ਠੀਕ ਹੈ।" ਜੇ ਇਹ ਸਫਲ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਇਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇੱਕ ਗਲਤੀ ਹੈ, ਡੇਟਾਬੇਸ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਇਸ ਲਈ, ਇਸ ਸਬੰਧ ਵਿੱਚ, ਮੈਂ ਦੁਬਾਰਾ ਤਿਆਰੀ/ਜੀਵਨਤਾ ਟੈਸਟਾਂ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹਾਂ - ਤੁਹਾਨੂੰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਤਿਆਰੀ ਟੈਸਟ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ, ਪਰ ਇੱਕ ਜੀਵਣਤਾ ਟੈਸਟ ਸਵਾਲ ਵਿੱਚ ਹੈ। ਕਿਉਂਕਿ ਜੇ ਤੁਸੀਂ ਸਿਹਤ ਜਾਂਚਾਂ ਦਾ ਵਰਣਨ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹੋ ਜਿਵੇਂ ਮੈਂ ਕਿਹਾ ਹੈ, ਤਾਂ ਇਹ ਸਿੱਧ ਹੋ ਜਾਵੇਗਾ ਕਿ ਇਹ ਉਦਾਹਰਣ ਵਾਲੇ ਹਿੱਸੇ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹੈв или со всех instanceਇੱਕ ਡਾਟਾਬੇਸ ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ. ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰੀ ਟੈਸਟ ਦੀ ਘੋਸ਼ਣਾ ਕੀਤੀ, ਤਾਂ ਸਾਡੀਆਂ ਸਿਹਤ ਜਾਂਚਾਂ ਫੇਲ੍ਹ ਹੋਣ ਲੱਗੀਆਂ, ਅਤੇ ਇਸ ਅਨੁਸਾਰ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜਿਨ੍ਹਾਂ ਤੋਂ ਡੇਟਾਬੇਸ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸੰਤੁਲਨ ਤੋਂ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਅਸਲ ਵਿੱਚ ਇੱਕ ਅਣਗਹਿਲੀ ਵਾਲੀ ਸਥਿਤੀ ਵਿੱਚ "ਲਟਕ" ਗਿਆ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਡੇਟਾਬੇਸ ਦੀ ਉਡੀਕ ਕਰੋ. ਕੰਮ

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

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

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

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

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

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

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

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

ਜੇ ਸਭ ਕੁਝ ਠੀਕ ਰਿਹਾ, ਤਾਂ ਦੋ ਸੌਵਾਂ ਜਵਾਬ ਦਿਓ. ਸਿਧਾਂਤ ਵਿੱਚ, ਕੋਈ ਵੀ ਦੋ-ਸੌਵਾਂ ਜਵਾਬ ਤੁਹਾਡੇ ਲਈ ਅਨੁਕੂਲ ਹੋਵੇਗਾ। ਜੇ ਤੁਸੀਂ ਰੈਗਸੀ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹਦੇ ਹੋ ਅਤੇ ਜਾਣਦੇ ਹੋ ਕਿ ਕੁਝ ਜਵਾਬ ਸਥਿਤੀਆਂ ਦੂਜਿਆਂ ਤੋਂ ਵੱਖਰੀਆਂ ਹਨ, ਤਾਂ ਢੁਕਵੇਂ ਲੋਕਾਂ ਨਾਲ ਜਵਾਬ ਦਿਓ: 204, 5, 10, 15, ਜੋ ਵੀ ਹੋਵੇ। ਜੇ ਇਹ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਿਰਫ਼ "ਦੋ ਜ਼ੀਰੋ ਜ਼ੀਰੋ।" ਜੇ ਸਭ ਕੁਝ ਵਿਗੜਦਾ ਹੈ ਅਤੇ ਸਿਹਤ ਜਾਂਚ ਦਾ ਜਵਾਬ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਕਿਸੇ ਵੀ ਪੰਜ ਸੌ ਨਾਲ ਜਵਾਬ ਦਿਓ. ਦੁਬਾਰਾ ਫਿਰ, ਜੇ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਕਿਵੇਂ ਜਵਾਬ ਦੇਣਾ ਹੈ, ਤਾਂ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਸਥਿਤੀਆਂ ਇੱਕ ਦੂਜੇ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਸਮਝਦੇ, ਤਾਂ 502 ਤੁਹਾਡੀ ਸਿਹਤ ਜਾਂਚਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਦਾ ਵਿਕਲਪ ਹੈ ਜੇਕਰ ਕੁਝ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ।

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

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

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

ਅੱਗੇ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਵੇਲੇ ਸਾਡੇ ਕੋਲ ਦਰਦਨਾਕ ਮੁੱਦਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

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

ਸ਼ਾਨਦਾਰ ਬੰਦ

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

ਇੱਕ ਲਗਭਗ ਬਰਾਬਰ ਮਾੜਾ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ SIGTERM ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ ਅਤੇ "ਉਨ੍ਹਾਂ ਨੇ ਕਿਹਾ segterm, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਖਤਮ ਹੋ ਰਹੇ ਹਾਂ, ਮੈਂ ਨਹੀਂ ਦੇਖਿਆ, ਮੈਨੂੰ ਕੋਈ ਉਪਭੋਗਤਾ ਬੇਨਤੀਆਂ ਨਹੀਂ ਪਤਾ, ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਸ ਕਿਸਮ ਦੀ ਬੇਨਤੀਆਂ ਜੋ ਮੈਂ ਇਸ ਸਮੇਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ, ਉਹਨਾਂ ਨੇ ਕਿਹਾ SIGTERM, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਖਤਮ ਕਰ ਰਹੇ ਹਾਂ " ਇਹ ਵੀ ਇੱਕ ਮਾੜਾ ਵਿਕਲਪ ਹੈ।

ਕਿਹੜਾ ਵਿਕਲਪ ਚੰਗਾ ਹੈ? ਪਹਿਲਾ ਬਿੰਦੂ ਕਾਰਵਾਈਆਂ ਦੇ ਪੂਰਾ ਹੋਣ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਹੈ. ਤੁਹਾਡੇ ਸਰਵਰ ਲਈ ਇੱਕ ਵਧੀਆ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਇਹ ਇੱਕ SIGTERM ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ ਕੀ ਕਰਦਾ ਹੈ।

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

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

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

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

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

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

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

ਸਰੋਤ

ਅਸਲ ਵਿੱਚ, ਇੱਥੇ ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੱਧੀ ਕਹਾਣੀ ਦੱਸਾਂਗਾ। ਦੁਬਾਰਾ ਅਸਲ ਜ਼ਿੰਦਗੀ ਤੋਂ. ਸਭ ਤੋਂ ਬਿਮਾਰ ਚੀਜ਼ ਜੋ ਮੈਂ ਕਦੇ ਸਰੋਤਾਂ ਬਾਰੇ ਸੁਣੀ ਹੈ.

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

ਸਰੋਤਾਂ ਦੀ ਬਿਲਕੁਲ ਲੋੜ ਕਿਉਂ ਹੈ? ਕੁਬਰਨੇਟਸ ਵਿੱਚ 2 ਕਿਸਮ ਦੇ ਸਰੋਤ ਹਨ। ਕੁਝ ਨੂੰ ਬੇਨਤੀਆਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਦੂਜਿਆਂ ਨੂੰ ਸੀਮਾਵਾਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਸਰੋਤਾਂ ਦੁਆਰਾ ਅਸੀਂ ਸਮਝਾਂਗੇ ਕਿ ਅਸਲ ਵਿੱਚ ਹਮੇਸ਼ਾ ਦੋ ਬੁਨਿਆਦੀ ਪਾਬੰਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਯਾਨੀ, ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਲਈ CPU ਸਮਾਂ ਸੀਮਾਵਾਂ ਅਤੇ RAM ਸੀਮਾਵਾਂ।

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

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

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

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

ਡਾਟਾ ਸਟੋਰੇਜ

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

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

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

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

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

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

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

ਸਾਡੇ ਕੋਲ Ceph 'ਤੇ ਇੱਕ ਕੋਰਸ ਹੋਵੇਗਾ, ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਪ੍ਰੋਗਰਾਮ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਜਾਣੂ ਕਰੋ ਅਤੇ ਇੱਕ ਅਰਜ਼ੀ ਜਮ੍ਹਾਂ ਕਰੋ.

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

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

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

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

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

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

ਕਲਾਊਡਨੇਟਿਵਸ

ਅਤੇ ਅੰਤਮ ਉਪ-ਵਿਸ਼ਾ Cloudnative ਕੀ ਹੈ। ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? Cloudnativeness ਅਤੇ ਇਸ 'ਤੇ.

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

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

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

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

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

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

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

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

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

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

ਸਰੋਤ: www.habr.com