ਕੁਬਰਨੇਟਸ ਦੁਨੀਆ ਨੂੰ ਆਪਣੇ ਕਬਜ਼ੇ ਵਿੱਚ ਲੈ ਲਵੇਗਾ। ਕਦੋਂ ਅਤੇ ਕਿਵੇਂ?

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

ਮੂਲ ਇੰਟਰਵਿਊ DevOps Deflop 'ਤੇ ਪੌਡਕਾਸਟ ਰੂਪ ਵਿੱਚ ਸੁਣੋ - DevOps ਬਾਰੇ ਇੱਕ ਰੂਸੀ-ਭਾਸ਼ਾ ਪੋਡਕਾਸਟ, ਅਤੇ ਹੇਠਾਂ ਟੈਕਸਟ ਸੰਸਕਰਣ ਹੈ।

ਇੱਥੇ ਅਤੇ ਹੇਠਾਂ ਉਹ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ ਵਿਟਾਲੀ ਖਬਰਾਰੋਵ ਐਕਸਪ੍ਰੈਸ 42 ਤੋਂ ਇੰਜੀਨੀਅਰ.

"Flant" ਬਾਰੇ

- ਹੈਲੋ Dima. ਤੁਸੀਂ ਤਕਨੀਕੀ ਨਿਰਦੇਸ਼ਕ ਹੋ "ਫਲੈਂਟ” ਅਤੇ ਇਸਦੇ ਸੰਸਥਾਪਕ ਵੀ। ਕਿਰਪਾ ਕਰਕੇ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਕੰਪਨੀ ਕੀ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਕੀ ਹੋ?

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




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

ਕੁਬਰਨੇਟਸ ਬਾਰੇ

- ਹਾਲ ਹੀ ਵਿੱਚ ਮੈਂ "Flant" ਅਤੇ ਤੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਪੋਰਟਾਂ ਦੇਖ ਰਿਹਾ ਹਾਂ ਲੇਖ ਕੁਬਰਨੇਟਸ ਬਾਰੇ ਤੁਸੀਂ ਉਸ ਕੋਲ ਕਿਵੇਂ ਆਏ?

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

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

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

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

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

ਕੁਬਰਨੇਟਸ ਬਾਰੇ

- ਕੀ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੋ?

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

- ਉਸੇ ਸਮੇਂ, ਕੀ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਦੇ ਆਲੇ ਦੁਆਲੇ ਆਪਣੇ ਬਹੁਤ ਸਾਰੇ ਸਾਧਨ ਵਿਕਸਿਤ ਕਰਦੇ ਹੋ?

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

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

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

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

ਫਲਾਂਟਾ ਟੂਲ

— ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਫਲੈਂਟ ਕੋਲ ਹੁਣ ਐਡੋਨ ਓਪਰੇਟਰ, ਸ਼ੈੱਲ ਓਪਰੇਟਰ, ਅਤੇ ਡੀਏਪੀ/ਵਰਫ ਟੂਲ ਹਨ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਇਹ ਵੱਖ-ਵੱਖ ਅਵਤਾਰਾਂ ਵਿੱਚ ਇੱਕੋ ਸਾਧਨ ਹੈ। ਮੈਂ ਇਹ ਵੀ ਸਮਝਦਾ/ਸਮਝਦੀ ਹਾਂ ਕਿ Flaunt ਦੇ ਅੰਦਰ ਹੋਰ ਵੀ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਟੂਲ ਹਨ। ਇਹ ਸੱਚ ਹੈ?

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

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

ਈਕੋਸਿਸਟਮ ਵਿਕਾਸ

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

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

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

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

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

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

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

ਡੈਪ ਕਿਉਂ ਬਣਾਇਆ ਗਿਆ ਸੀ?

- ਕੀ ਤੁਸੀਂ ਸਾਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਡੈਪ ਕਿਉਂ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਇਹ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ?

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

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

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

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਹੈਲਮ ਸਿਰਫ਼ ਇੱਕ ਟੈਕਸਟ ਪ੍ਰੀਪ੍ਰੋਸੈਸਰ ਹੈ ਜੋ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਡੇਟਾ ਲੋਡ ਕਰਦਾ ਹੈ।

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

ਯੋਜਨਾਵਾਂ

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

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

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

ਇਸ ਸਾਰੀ ਕਹਾਣੀ ਨੂੰ ਸਮਾਨਤਾਵਾਂ ਨਾਲ ਵੇਖਣ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ।

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

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

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

ਕੀ ਕੁਬਰਨੇਟਸ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਮੁਸ਼ਕਲ ਹੈ?

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

ਦਮਿਤਰੀ: ਇਹ ਇੱਕ ਬਹੁਤ ਔਖਾ ਸਵਾਲ ਹੈ ਅਤੇ ਇਸ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਸਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਮਰਥਨ ਕੀ ਹੈ ਅਤੇ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਤੋਂ ਕੀ ਚਾਹੁੰਦੇ ਹਾਂ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਨੂੰ ਪ੍ਰਗਟ ਕਰੋਗੇ?

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

ਦਮਿਤਰੀ: ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ।

— ਕੁਬਰਨੇਟਸ ਨੂੰ ਕੁਝ ਵੀ ਨਹੀਂ ਲੈਣਾ ਅਤੇ ਸਥਾਪਿਤ ਕਰਨਾ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਤਾਂ ਜੋ ਇਹ ਉਤਪਾਦਨ ਤਿਆਰ ਹੋਵੇ?

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

ਕੁਬਰਨੇਟਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਕੰਮ 'ਤੇ ਲਿਆਉਣਾ ਆਸਾਨ ਹੈ: ਚਿਕ! - ਸਥਾਪਿਤ, ਇੰਸਟਾਲੇਸ਼ਨ ਦੇ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਹਨ। ਪਰ ਜਦੋਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਸਵਾਲ ਹਮੇਸ਼ਾ ਉੱਠਦੇ ਹਨ: ਅਸੀਂ ਅਜੇ ਤੱਕ ਕੀ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਲਿਆ ਹੈ? ਅਸੀਂ ਅਜੇ ਤੱਕ ਕੀ ਨਹੀਂ ਕੀਤਾ? ਕਿਹੜੇ ਲੀਨਕਸ ਕਰਨਲ ਪੈਰਾਮੀਟਰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਏ ਗਏ ਸਨ? ਪ੍ਰਭੂ, ਕੀ ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇਸ਼ਾਰਾ ਵੀ ਕੀਤਾ?! ਅਸੀਂ ਕਿਹੜੇ ਕੁਬਰਨੇਟਸ ਕੰਪੋਨੈਂਟਸ ਡਿਲੀਵਰ ਕੀਤੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਨਹੀਂ ਹਨ? ਹਜ਼ਾਰਾਂ ਸਵਾਲ ਉੱਠਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਜਵਾਬ ਲਈ, ਤੁਹਾਨੂੰ ਇਸ ਉਦਯੋਗ ਵਿੱਚ 15-20 ਸਾਲ ਬਿਤਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

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

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

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

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

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

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

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

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

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

"ਮੈਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋਵਾਂਗਾ" ਪਹੁੰਚ ਬਾਰੇ

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

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

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

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

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

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

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

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

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

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

ਕੀ ਸਾਨੂੰ ਕੰਟੇਨਰਾਂ ਦੀ ਲੋੜ ਹੈ?

- ਕੀ ਤੁਸੀਂ ਸਾਨੂੰ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਰੂਸ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਕਿੰਨੀ ਵਿਆਪਕ ਹੈ?

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

ਫਿਰ ਇੱਕ ਹੋਰ ਸਵਾਲ - ਕੀ ਸਾਨੂੰ ਕੰਟੇਨਰਾਂ ਦੀ ਲੋੜ ਹੈ? ਮੇਰੀ ਨਿੱਜੀ ਭਾਵਨਾ ਅਤੇ ਫਲੈਂਟ ਕੰਪਨੀ ਦੀ ਸਮੁੱਚੀ ਸਥਿਤੀ ਇਹ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਇੱਕ ਡੀ ਫੈਕਟੋ ਸਟੈਂਡਰਡ ਹੈ।

ਕੁਬਰਨੇਟਸ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਨਹੀਂ ਹੋਵੇਗਾ.

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

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

— ਭਾਵ, ਉਹ ਕੰਪਨੀਆਂ ਜਿਨ੍ਹਾਂ ਨੇ ਅਜੇ ਤੱਕ ਕੁਬਰਨੇਟਸ 'ਤੇ ਸਵਿਚ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਉਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇਸ 'ਤੇ ਸਵਿਚ ਕਰਨਗੀਆਂ ਜਾਂ ਭੁਲੇਖੇ ਵਿੱਚ ਰਹਿਣਗੀਆਂ। ਮੈਂ ਤੁਹਾਨੂੰ ਠੀਕ ਸਮਝਿਆ?

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

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਬਾਰੇ

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

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

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਮੋਨੋਲਿਥ ਹੈ ਜੋ 300 ਲੋਕਾਂ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਵਿਕਾਸ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਵਾਲੇ ਹਰ ਕੋਈ ਸਮਝਦਾ ਹੈ ਕਿ ਉੱਥੇ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਅਤੇ ਇਸਨੂੰ ਮਾਈਕ੍ਰੋ-ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ - ਲਗਭਗ 10 ਟੁਕੜੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ 30 ਲੋਕਾਂ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਇੱਕ ਘੱਟੋ-ਘੱਟ ਸੰਸਕਰਣ ਵਿੱਚ. ਇਹ ਮਹੱਤਵਪੂਰਨ, ਜ਼ਰੂਰੀ ਅਤੇ ਠੰਡਾ ਹੈ. ਪਰ ਜਦੋਂ ਇੱਕ ਸਟਾਰਟਅੱਪ ਸਾਡੇ ਕੋਲ ਆਉਂਦਾ ਹੈ, ਜਿੱਥੇ 3 ਬਹੁਤ ਹੀ ਸ਼ਾਨਦਾਰ ਅਤੇ ਪ੍ਰਤਿਭਾਸ਼ਾਲੀ ਮੁੰਡਿਆਂ ਨੇ ਆਪਣੇ ਗੋਡਿਆਂ 'ਤੇ 60 ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਲਿਖੀਆਂ, ਹਰ ਵਾਰ ਜਦੋਂ ਮੈਂ Corvalol ਦੀ ਭਾਲ ਕਰਦਾ ਹਾਂ.

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

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

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

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

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

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

ਐਮਾਜ਼ਾਨ ਅਤੇ ਗੂਗਲ ਬਾਰੇ

- ਕੀ ਐਮਾਜ਼ਾਨ ਜਾਂ ਗੂਗਲ ਦੇ ਹੱਲ ਤੋਂ ਇੱਕ ਹੋਸਟ ਨੂੰ ਆਊਟਸੋਰਸ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ?

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

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

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

ਇਸ ਲਈ, ਜਵਾਬ ਹਾਂ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਪਰਿਪੱਕ ਹੋਸਟ ਕੀਤੇ ਹੱਲ ਨਹੀਂ ਹਨ.

ਕਿਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਹੈ?

- ਅਤੇ ਫਿਰ ਵੀ ਕਿਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਹੈ? ਕਿਸ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਕੁਬਰਨੇਟਸ 'ਤੇ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਕੁਬਰਨੇਟਸ ਲਈ ਆਉਣ ਵਾਲੇ ਫਲਾਉਂਟ ਕਲਾਇੰਟ ਕੌਣ ਹੈ?

ਦਮਿਤਰੀ: ਇਹ ਇੱਕ ਦਿਲਚਸਪ ਸਵਾਲ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਸਮੇਂ, ਕੁਬਰਨੇਟਸ ਦੀ ਲਹਿਰ 'ਤੇ, ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸਾਡੇ ਕੋਲ ਆਉਂਦੇ ਹਨ: "ਮੁੰਡੇ, ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਬਣਾ ਰਹੇ ਹੋ, ਇਹ ਸਾਡੇ ਲਈ ਕਰੋ!" ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਜਵਾਬ ਦਿੰਦੇ ਹਾਂ: "ਸੱਜਣ, ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਨਹੀਂ ਕਰਦੇ, ਅਸੀਂ ਉਤਪਾਦ ਅਤੇ ਇਸ ਨਾਲ ਜੁੜੀ ਹਰ ਚੀਜ਼ ਕਰਦੇ ਹਾਂ।" ਕਿਉਂਕਿ CI/CD ਅਤੇ ਇਸ ਸਾਰੀ ਕਹਾਣੀ ਨੂੰ ਕੀਤੇ ਬਿਨਾਂ ਉਤਪਾਦ ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੈ। ਹਰ ਕੋਈ ਇਸ ਵੰਡ ਤੋਂ ਦੂਰ ਹੋ ਗਿਆ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਵਿਕਾਸ ਨਾਲ ਵਿਕਾਸ ਹੈ ਅਤੇ ਫਿਰ ਸ਼ੋਸ਼ਣ ਨਾਲ ਸ਼ੋਸ਼ਣ।

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

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

ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਕਿ ਕਿਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਹੈ, ਕਿਸੇ ਨੂੰ ਵੀ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

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

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

ਇਹ ਸ਼ਬਦਾਵਲੀ ਜੋ ਸਾਨੂੰ ਜਾਂ ਕਿਸੇ ਹੋਰ ਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਹੈ, ਗਲਤ ਹੈ।

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

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

ਅੰਤਮ ਜਵਾਬ ਹੈ: ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਆਪਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਤੁਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ:

• ਉਤਪਾਦ ਡਿੱਗਦਾ ਨਹੀਂ ਹੈ;
• ਭਾਵੇਂ ਉਹ ਡਿੱਗਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਉੱਥੇ ਕੁਝ ਪਾ ਸਕਦੇ ਹਾਂ;
• ਅਸੀਂ ਇਸ ਨੂੰ ਉਸ ਗਤੀ 'ਤੇ ਬਦਲ ਸਕਦੇ ਹਾਂ ਜਿਸ 'ਤੇ ਸਾਡੇ ਕਾਰੋਬਾਰ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਰ ਸਕਦੇ ਹਾਂ; ਇਸ ਨਾਲ ਸਾਨੂੰ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਆਉਂਦੀ।

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

ਸਰਵਰ ਰਹਿਤ ਬਾਰੇ

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

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

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

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

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

ਕੁਬਰਨੇਟਸ ਕਿਵੇਂ ਵਿਕਸਿਤ ਹੋਣਗੇ

— ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇਸ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਸ਼ਾਨਦਾਰ ਦੂਰ ਭਵਿੱਖ ਵੱਲ ਵਧਦੇ ਹਾਂ, ਤੁਸੀਂ ਕਿਵੇਂ ਸੋਚਦੇ ਹੋ ਕਿ ਕੁਬਰਨੇਟਸ ਅਤੇ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਦਾ ਵਾਤਾਵਰਣ ਕਿਵੇਂ ਵਿਕਸਿਤ ਹੋਵੇਗਾ?

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

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

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

ਕਿਸੇ ਨਾ ਕਿਸੇ ਰੂਪ ਵਿੱਚ ਆਪਰੇਟਰ ਵਿਕਾਸ ਦੀ ਇਹ ਕਹਾਣੀ ਅਗਲੇ ਕੁਝ ਸਾਲਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇਗੀ।

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਵਰਤੋਂ ਦੀ ਸੌਖ ਬਹੁਤ ਵਧਣੀ ਚਾਹੀਦੀ ਹੈ - ਬਕਸਾ ਵੱਧ ਤੋਂ ਵੱਧ ਕਾਲਾ, ਵੱਧ ਤੋਂ ਵੱਧ ਭਰੋਸੇਮੰਦ, ਵੱਧ ਤੋਂ ਵੱਧ ਸਧਾਰਨ ਨੋਬਾਂ ਦੇ ਨਾਲ.

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

2019 ਵਿੱਚ ਹੁਣ ਕਿਹੜਾ ਰੇਡੀਓ ਹੈ? ਕਾਰ ਵਿੱਚ, ਰੇਡੀਓ ਰਿਸੀਵਰ ਸਾਰੀਆਂ ਤਰੰਗਾਂ ਅਤੇ ਸਟੇਸ਼ਨਾਂ ਦੇ ਨਾਮ ਲੱਭਦਾ ਹੈ. ਪ੍ਰਕਿਰਿਆ ਦਾ ਭੌਤਿਕ ਵਿਗਿਆਨ 100 ਸਾਲਾਂ ਵਿੱਚ ਨਹੀਂ ਬਦਲਿਆ ਹੈ, ਪਰ ਵਰਤੋਂ ਵਿੱਚ ਅਸਾਨੀ ਹੈ. ਹੁਣ, ਅਤੇ ਹੁਣ ਹੀ ਨਹੀਂ, ਪਹਿਲਾਂ ਹੀ 1980 ਵਿੱਚ, ਜਦੋਂ ਅਜ਼ੀਮੋਵ ਨਾਲ ਇੱਕ ਇੰਟਰਵਿਊ ਸੀ, ਹਰ ਕੋਈ ਰੇਡੀਓ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਸੀ ਅਤੇ ਕਿਸੇ ਨੇ ਇਸ ਬਾਰੇ ਨਹੀਂ ਸੋਚਿਆ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ. ਇਹ ਹਮੇਸ਼ਾ ਕੰਮ ਕਰਦਾ ਹੈ — ਇਹ ਦਿੱਤਾ ਗਿਆ ਹੈ।

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

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

ਇੰਜਨੀਅਰਾਂ ਦਾ ਕੀ ਕਰੀਏ?

— ਫਿਰ ਇੰਜਨੀਅਰਾਂ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦਾ ਕੀ ਹੋਵੇਗਾ ਜੋ ਕੁਬਰਨੇਟਸ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ?

ਦਮਿਤਰੀ: 1C ਦੇ ਆਉਣ ਤੋਂ ਬਾਅਦ ਲੇਖਾਕਾਰ ਦਾ ਕੀ ਹੋਇਆ? ਇਸੇ ਬਾਰੇ. ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਕਾਗਜ਼ਾਂ 'ਤੇ ਗਿਣਦੇ ਸਨ - ਹੁਣ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ. ਕਿਰਤ ਦੀ ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਵਾਧਾ ਹੋਇਆ ਹੈ, ਪਰ ਕਿਰਤ ਆਪਣੇ ਆਪ ਅਲੋਪ ਨਹੀਂ ਹੋਈ ਹੈ। ਜੇ ਪਹਿਲਾਂ ਇੱਕ ਲਾਈਟ ਬਲਬ ਵਿੱਚ ਪੇਚ ਕਰਨ ਲਈ 10 ਇੰਜਨੀਅਰ ਲਗਦੇ ਸਨ, ਤਾਂ ਹੁਣ ਇੱਕ ਹੀ ਕਾਫ਼ੀ ਹੋਵੇਗਾ।

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

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

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

DevOps ਜਾਂ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਦੂਰ ਨਹੀਂ ਹੋਵੇਗੀ - ਉੱਚ-ਪੱਧਰੀ ਅਤੇ ਕੁਸ਼ਲ ਕੰਮ ਵਿੱਚ ਵਾਧਾ ਹੋਵੇਗਾ.

- ਮੈਂ ਇੱਕ ਦਿਲਚਸਪ ਵਿਚਾਰ ਵੀ ਸੁਣਿਆ ਹੈ ਕਿ ਕੰਮ ਅਸਲ ਵਿੱਚ ਵਧੇਗਾ.

ਦਮਿਤਰੀ: ਬੇਸ਼ੱਕ, ਸੌ ਪ੍ਰਤੀਸ਼ਤ! ਕਿਉਂਕਿ ਸਾਡੇ ਦੁਆਰਾ ਲਿਖਣ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਦੀ ਮਾਤਰਾ ਲਗਾਤਾਰ ਵਧ ਰਹੀ ਹੈ. ਉਹਨਾਂ ਮੁੱਦਿਆਂ ਦੀ ਗਿਣਤੀ ਜੋ ਅਸੀਂ ਸੌਫਟਵੇਅਰ ਨਾਲ ਹੱਲ ਕਰਦੇ ਹਾਂ ਲਗਾਤਾਰ ਵਧ ਰਹੀ ਹੈ. ਕੰਮ ਦੀ ਮਾਤਰਾ ਵਧ ਰਹੀ ਹੈ। ਹੁਣ DevOps ਮਾਰਕੀਟ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗਰਮ ਹੈ. ਇਹ ਤਨਖਾਹ ਦੀਆਂ ਉਮੀਦਾਂ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ, ਵੇਰਵਿਆਂ ਵਿੱਚ ਜਾਣ ਤੋਂ ਬਿਨਾਂ, ਇੱਥੇ ਜੂਨੀਅਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ X ਚਾਹੁੰਦੇ ਹਨ, ਮਿਡਲ ਜੋ 1,5X ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਸੀਨੀਅਰ ਜੋ 2X ਚਾਹੁੰਦੇ ਹਨ। ਅਤੇ ਹੁਣ, ਜੇ ਤੁਸੀਂ ਮਾਸਕੋ ਦੇਵਓਪਸ ਤਨਖਾਹ ਬਾਜ਼ਾਰ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਜੂਨੀਅਰ X ਤੋਂ 3X ਤੱਕ ਅਤੇ ਇੱਕ ਸੀਨੀਅਰ X ਤੋਂ 3X ਤੱਕ ਚਾਹੁੰਦਾ ਹੈ।

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

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

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

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

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

ਸ਼ੁਭਕਾਮਨਾਵਾਂ ਅਤੇ ਵਿਗਿਆਪਨ ਦਾ ਇੱਕ ਮਿੰਟ

- ਕੀ ਤੁਹਾਡੀ ਕੋਈ ਇੱਛਾ ਹੈ?

ਦਮਿਤਰੀ: ਹਾਂ, ਮੇਰੀਆਂ ਕਈ ਇੱਛਾਵਾਂ ਹਨ।

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

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

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

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

- ਤੁਹਾਡਾ ਬਹੁਤ ਧੰਨਵਾਦ!

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

ਇੰਟਰਵਿਊ ਵਿੱਚ, ਦਮਿੱਤਰੀ ਨੇ werf ਦੇ ਮੁੱਦੇ 'ਤੇ ਛੂਹਿਆ. ਹੁਣ ਇਹ ਇੱਕ ਵਿਆਪਕ ਸਵਿਸ ਚਾਕੂ ਹੈ ਜੋ ਲਗਭਗ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ. ਪਰ ਇਹ ਹਮੇਸ਼ਾ ਅਜਿਹਾ ਨਹੀਂ ਸੀ। 'ਤੇ DevOpsConf  ਤਿਉਹਾਰ 'ਤੇ RIT++ ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ ਇਸ ਸਾਧਨ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਗੱਲ ਕਰੇਗਾ. ਰਿਪੋਰਟ ਵਿੱਚ "werf ਕੁਬਰਨੇਟਸ 'ਤੇ CI/CD ਲਈ ਸਾਡਾ ਟੂਲ ਹੈ।" ਇੱਥੇ ਸਭ ਕੁਝ ਹੋਵੇਗਾ: ਕੁਬਰਨੇਟਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਛੁਪੀਆਂ ਸੂਖਮਤਾਵਾਂ, ਇਹਨਾਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਵਿਕਲਪ ਅਤੇ ਵੇਰਫ ਦੇ ਮੌਜੂਦਾ ਅਮਲ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ। 27 ਅਤੇ 28 ਮਈ ਨੂੰ ਸਾਡੇ ਨਾਲ ਜੁੜੋ, ਅਸੀਂ ਸੰਪੂਰਨ ਟੂਲ ਬਣਾਵਾਂਗੇ।

ਸਰੋਤ: www.habr.com