ਕਲਾਉਡ-ਨੇਟਿਵ ਐਪਸ ਬਣਾਉਣ ਲਈ 5 ਆਮ ਸੂਝ ਦੇ ਸਿਧਾਂਤ

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

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

ਸਾਫਟਵੇਅਰ ਡਿਜ਼ਾਈਨ ਦੇ ਸਿਧਾਂਤ

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

• ਚੁੰਮੀ (ਇਸ ਨੂੰ ਸਧਾਰਨ, ਮੂਰਖ ਰੱਖੋ) - ਇਸ ਨੂੰ ਗੁੰਝਲਦਾਰ ਨਾ ਕਰੋ;
• ਡਰਾਈ (ਆਪਣੇ ਆਪ ਨੂੰ ਨਾ ਦੁਹਰਾਓ) - ਆਪਣੇ ਆਪ ਨੂੰ ਨਾ ਦੁਹਰਾਓ;
• ਯਾਗੀਨੀ (ਤੁਹਾਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ) - ਅਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਨਾ ਬਣਾਓ ਜਿਸਦੀ ਤੁਰੰਤ ਲੋੜ ਨਾ ਹੋਵੇ;
• SoC ਚਿੰਤਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ - ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਸਾਂਝੀਆਂ ਕਰੋ।

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

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

ਕਲਾਉਡ-ਨੇਟਿਵ ਕੰਟੇਨਰ: ਰੈੱਡ ਹੈਟ ਪਹੁੰਚ

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

ਸਿੰਗਲ ਚਿੰਤਾ ਦਾ ਸਿਧਾਂਤ (SCP)

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

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

SCP ਸਿਧਾਂਤ ਕਹਿੰਦਾ ਹੈ ਕਿ ਹਰੇਕ ਕੰਟੇਨਰ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੰਟੇਨਰ ਸੰਸਾਰ ਵਿੱਚ SCP OOP ਸੰਸਾਰ ਵਿੱਚ SRP ਨਾਲੋਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਇਹ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਸਿੰਗਲ ਕੰਮ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ।

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

ਉੱਚ ਨਿਰੀਖਣਯੋਗਤਾ ਸਿਧਾਂਤ (HOP)

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

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

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

ਜੀਵਨ-ਚੱਕਰ ਅਨੁਕੂਲਤਾ ਸਿਧਾਂਤ (LCP)

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

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

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਕੁਝ ਘਟਨਾਵਾਂ ਦੂਜਿਆਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਕ੍ਰੈਸ਼ਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਿਗਨਲ: ਸਮਾਪਤ (SIGTERM) ਸੁਨੇਹਿਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਿਗਨਲ ਨੂੰ ਫੜਨ ਲਈ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਇਸਦੀ ਸਮਾਪਤੀ ਰੁਟੀਨ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਕਿੱਲ (SIGKILL) ਜੋ SIGTERM ਤੋਂ ਬਾਅਦ ਆਉਂਦਾ ਹੈ।

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

ਚਿੱਤਰ ਅਟੱਲਤਾ ਸਿਧਾਂਤ (IIP)

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

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

ਪ੍ਰਕਿਰਿਆ ਡਿਸਪੋਸੇਬਿਲਟੀ ਸਿਧਾਂਤ (PDP)

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

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

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

ਸਵੈ-ਰੋਕਣ ਦਾ ਸਿਧਾਂਤ (S-CP)

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

ਅਪਵਾਦ ਉਹਨਾਂ ਸੰਰਚਨਾਵਾਂ ਲਈ ਬਣਾਏ ਗਏ ਹਨ ਜੋ ਵਾਤਾਵਰਣ ਤੋਂ ਵਾਤਾਵਰਣ ਤੱਕ ਵੱਖੋ-ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਰਨਟਾਈਮ 'ਤੇ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ Kubernetes ConfigMap ਰਾਹੀਂ।

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

ਰਨਟਾਈਮ ਸੀਮਤ ਸਿਧਾਂਤ (ਆਰਸੀਪੀ)

S-CP ਸਿਧਾਂਤ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੰਟੇਨਰ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਚਿੱਤਰ ਬਾਈਨਰੀ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਇੱਕ ਕੰਟੇਨਰ ਸਿਰਫ਼ ਇੱਕ "ਬਲੈਕ ਬਾਕਸ" ਨਹੀਂ ਹੁੰਦਾ ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੁੰਦੀ ਹੈ - ਫਾਈਲ ਦਾ ਆਕਾਰ। ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੌਰਾਨ, ਕੰਟੇਨਰ ਹੋਰ ਮਾਪ ਲੈ ਲੈਂਦਾ ਹੈ: ਵਰਤੀ ਗਈ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ, CPU ਸਮਾਂ, ਅਤੇ ਹੋਰ ਸਿਸਟਮ ਸਰੋਤ।

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

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

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

ਨੋਟ ਕਰੋ ਕਿ ਇਹਨਾਂ ਆਮ ਸਿਧਾਂਤਾਂ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਕੰਟੇਨਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਵਾਧੂ ਤਕਨੀਕੀ ਢੰਗਾਂ ਅਤੇ ਤਕਨੀਕਾਂ ਦੀ ਵੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਕੋਲ ਕੁਝ ਛੋਟੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਹਨ ਜੋ ਵਧੇਰੇ ਖਾਸ ਹਨ ਅਤੇ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਜਾਂ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ):

• ਚਿੱਤਰਾਂ ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ: ਅਸਥਾਈ ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਓ ਅਤੇ ਬੇਲੋੜੇ ਪੈਕੇਜਾਂ ਨੂੰ ਸਥਾਪਿਤ ਨਾ ਕਰੋ - ਕੰਟੇਨਰ ਦਾ ਆਕਾਰ ਜਿੰਨਾ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਓਨੀ ਹੀ ਤੇਜ਼ੀ ਨਾਲ ਇਸਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਟਾਰਗੇਟ ਹੋਸਟ ਨਾਲ ਕਾਪੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• ਆਰਬਿਟਰੇਰੀ ਯੂਜ਼ਰ-ਆਈਡੀਜ਼ 'ਤੇ ਫੋਕਸ ਕਰੋ: ਆਪਣੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ sudo ਕਮਾਂਡ ਜਾਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ userid ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ।
• ਮਹੱਤਵਪੂਰਨ ਪੋਰਟਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰੋ: ਤੁਸੀਂ ਰਨਟਾਈਮ 'ਤੇ ਪੋਰਟ ਨੰਬਰ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ EXPOSE ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਬਿਹਤਰ ਹੈ - ਇਹ ਦੂਜੇ ਲੋਕਾਂ ਅਤੇ ਪ੍ਰੋਗਰਾਮਾਂ ਲਈ ਤੁਹਾਡੇ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਆਸਾਨ ਬਣਾ ਦੇਵੇਗਾ।
• ਵੌਲਯੂਮਜ਼ 'ਤੇ ਨਿਰੰਤਰ ਡੇਟਾ ਸਟੋਰ ਕਰੋ: ਉਹ ਡੇਟਾ ਜੋ ਕੰਟੇਨਰ ਦੇ ਨਸ਼ਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬਚਿਆ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਨੂੰ ਵਾਲੀਅਮਾਂ ਵਿੱਚ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਚਿੱਤਰ ਮੈਟਾਡੇਟਾ ਲਿਖੋ: ਟੈਗਸ, ਲੇਬਲ ਅਤੇ ਐਨੋਟੇਸ਼ਨ ਚਿੱਤਰਾਂ ਨੂੰ ਵਰਤਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ - ਦੂਜੇ ਵਿਕਾਸਕਾਰ ਤੁਹਾਡਾ ਧੰਨਵਾਦ ਕਰਨਗੇ।
• ਹੋਸਟ ਅਤੇ ਚਿੱਤਰਾਂ ਨੂੰ ਸਿੰਕ ਕਰੋ: ਕੁਝ ਕੰਟੇਨਰਾਈਜ਼ਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕੰਟੇਨਰ ਨੂੰ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਜਿਵੇਂ ਕਿ ਸਮਾਂ ਜਾਂ ਮਸ਼ੀਨ ID 'ਤੇ ਹੋਸਟ ਨਾਲ ਸਿੰਕ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਟੈਂਪਲੇਟਸ ਅਤੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਾਂ ਜੋ ਉੱਪਰ ਸੂਚੀਬੱਧ ਸਿਧਾਂਤਾਂ ਨੂੰ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨਗੇ:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

ਓਪਨਸ਼ਿਫਟ ਕੰਟੇਨਰ ਪਲੇਟਫਾਰਮ - 4 ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ 'ਤੇ ਵੈਬਿਨਾਰ
11 ਜੂਨ ਨੂੰ 11.00 ਵਜੇ

ਤੁਸੀਂ ਕੀ ਸਿੱਖੋਗੇ:

• ਅਟੱਲ Red Hat Enterprise Linux CoreOS
• OpenShift ਸੇਵਾ ਜਾਲ
• ਆਪਰੇਟਰ ਫਰੇਮਵਰਕ
• ਨੈਟਿਵ ਫਰੇਮਵਰਕ

ਸਰੋਤ: www.habr.com