17 ਸਤੰ 2025·8 ਮਿੰਟ
ਕੈਨ ਥੌਮਪਸਨ ਦੇ UNIX ਸਿਧਾਂਤ: ਕੰਟੇਨਰ ਅਤੇ ਕਲਾਉਡ ਓਐਸ ਦੇ ਪਿੱਛੇ
Ken Thompson ਦੇ UNIX ਸਿਧਾਂਤ — ਛੋਟੇ ਟੂਲ, ਪਾਈਪ, ਫਾਇਲ-ਇੰਟਰਫੇਸ ਅਤੇ ਸਾਫ਼ ਇੰਟਰਫੇਸ — ਅਤੇ ਇਹ ਕੰਟੇਨਰ, Linux ਅਤੇ ਕਲਾਉਡ ਇੰਫ੍ਰਾਸਟਰਕਚਰ ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੰਦੇ ਹਨ, ਉਸਦੀ ਖੋਜ।
Ken Thompson ਦੇ UNIX ਸਿਧਾਂਤ — ਛੋਟੇ ਟੂਲ, ਪਾਈਪ, ਫਾਇਲ-ਇੰਟਰਫੇਸ ਅਤੇ ਸਾਫ਼ ਇੰਟਰਫੇਸ — ਅਤੇ ਇਹ ਕੰਟੇਨਰ, Linux ਅਤੇ ਕਲਾਉਡ ਇੰਫ੍ਰਾਸਟਰਕਚਰ ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੰਦੇ ਹਨ, ਉਸਦੀ ਖੋਜ।
Ken Thompson ਦਾ ਮਕਸਦ ਕੋਈ “ਸਦੀਵੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ” ਬਣਾਉਣਾ ਨਹੀਂ ਸੀ। Dennis Ritchie ਅਤੇ Bell Labs ਦੀ ਟੀਮ ਨਾਲ ਉਹ ਇੱਕ ਛੋਟਾ, ਵਰਤੋਂਯੋਗ ਸਿਸਟਮ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸਨ ਜੋ ਡਿਵੈਲਪਰ ਸਮਝ ਸਕਣ, ਸੁਧਾਰ ਸਕਣ ਅਤੇ ਮਸ਼ੀਨਾਂ ਵੱਛਲੇ-ਵੱਛਲੇ ਲੈ ਕੇ ਜਾ ਸਕਣ। UNIX ਵਿਹਾਰਕ ਲਕੜਾਂ ਨਾਲ ਸਧਾਰਨ ਰੂਪ ਵਿੱਚ ਬਣਿਆ: ਕੋਰ ਨੂ ਸਾਫ਼ ਰੱਖੋ, ਟੂਲਾਂ ਨੂੰ ਇਕੱਠੇ ਚੰਗੇ ਬਣਾਓ, ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਇਕ ਹੀ ਕੰਪਿਊਟਰ ਮਾਡਲ ਵਿੱਚ ਫਸਾਉਣ ਤੋਂ ਬਚੋ।
ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹ ਸ਼ੁਰੂਆਤੀ ਚੋਣਾਂ ਆਧੁਨਿਕ ਕੰਪਿਊਟਿੰਗ ਨਾਲ ਕਿੰਨੀ ਵਧੀਆ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਅਸੀਂ ਟਰਮੀਨਲ ਦੀ ਜਗ੍ਹਾ ਵੈੱਬ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਇਕਲ ਸਰਵਰ ਦੀ ਜਗ੍ਹਾ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੇ ਫਲੀਟ ਵਰਤ ਰਹੇ ਹਾਂ, ਪਰ ਉਹੀ ਸਵਾਲ ਮੁੜ ਮੁੜ ਉਠਣਗੇ:
ਖਾਸ UNIX ਫੀਚਰ ਵਿਕਸਤ ਹੋਏ (ਜਾਂ ਬਦਲ ਗਏ) ਹਨ, ਪਰ ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ ਲਾਭਦਾਇਕ ਰਹੇ ਕਿਉਂਕਿ ਉਹ "ਕਿਸ ਤਰ੍ਹਾਂ ਸਿਸਟਮ ਬਣਾਉਣੇ" ਦੀ ਵਰਣਨਾ ਕਰਦੇ ਹਨ:
ਇਹ ਵਿਚਾਰ ਹਰ ਥਾਂ ਮਿਲਦੇ ਹਨ—Linux ਅਤੇ POSIX ਸੰਗਤਿਤਾ ਤੋਂ ਲੈ ਕੇ ਉਹ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਜਿਹੜੇ ਪ੍ਰੋਸੈਸ ਆਈਸੋਲੇਸ਼ਨ, namespaces ਅਤੇ ਫਾਇਲਸਿਸਟਮ ਦੇ ਚਾਲਾਕ ਉਪਾਅ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ।
ਅਸੀਂ Thompson-ਯੁੱਗ ਦੇ UNIX ਸੰਕਲਪਾਂ ਨੂੰ ਅੱਜ ਦੀ ਵਰਤੋਂ ਨਾਲ ਜੋੜਾਂਗੇ:
ਇਹ ਇੱਕ ਪਰਯੋਗਿਕ ਗਾਈਡ ਹੈ: ਘੱਟ ਜਾਰਗਨ, ਠੋਸ ਉਦਾਹਰਨਾਂ, ਅਤੇ "ਕਿਉਂ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ" ਤੇ ਧਿਆਨ—ਤਥਾਂ ਦੀ ਥਾਂ। ਜੇ ਤੁਸੀਂ ਕੰਟੇਨਰਾਂ ਅਤੇ ਕਲਾਉਡ ਓਐਸ ਵਿਹਾਰ ਲਈ ਇੱਕ ਤੇਜ਼ ਮਾਨਸਿਕ ਮਾਡਲ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਥਾਂ ਤੇ ਹੋ।
ਤੁਸੀਂ ਚਾਹੋ ਤਾਂ ਅੱਗੇ ਵੱਧ ਕੇ ਬਲੌਗ ਪੋਸਟ "How UNIX ideas show up in containers" ਵੇਖ ਸਕਦੇ ਹੋ।
UNIX ਕਿਸੇ ਵੱਡੇ ਰਣਨੀਤੀ ਦਾ ਹਿੱਸਾ ਬਣ ਕੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ। ਇਹ Ken Thompson (Dennis Ritchie ਅਤੇ ਹੋਰਾਂ ਦੇ ਯੋਗਦਾਨ ਦੇ ਨਾਲ) ਵੱਲੋਂ ਬਣਾਇਆ ਗਿਆ ਇੱਕ ਛੋਟਾ, ਕੰਮ ਕਰਨਯੋਗ ਸਿਸਟਮ ਸੀ ਜਿਸ ਨੇ ਸਪੱਸ਼ਟਤਾ, ਸਾਦਗੀ ਅਤੇ ਉਪਯੋਗੀ ਕੰਮ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ।
ਉਹ ਦਿਨਾਂ ਵਿੱਚ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਕਸਰ ਕਿਸੇ ਖਾਸ ਕੰਪਿਊਟਰ ਮਾਡਲ ਨਾਲ ਤੰਗ ਤੌਰ 'ਤੇ ਜੁੜੇ ਹੁੰਦੇ ਸਨ। ਹਾਰਡਵੇਅਰ ਬਦਲਿਆਂ ਤਾਂ OS (ਅਤੇ ਅਕਸਰ ਸਾਫਟਵੇਅਰ) ਨੂੰ ਵੀ ਬਦਲਣਾ ਪੈਂਦਾ ਸੀ।
ਇੱਕ ਪਰਟੇਬਲ OS ਦਾ ਪ੍ਰਯੋਗਿਕ ਮਤਲਬ ਸੀ: ਇੱਕੋ ਓਐਸ ਸੰਕਲਪ ਅਤੇ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਘੱਟ ਮੁੜ-ਲਿਖਾਈ ਨਾਲ ਚੱਲ ਸਕੇ। UNIX ਨੂੰ C ਵਿੱਚ ਲਿਖਕੇ ਟੀਮ ਨੇ ਕਿਸੇ ਇਕ CPU 'ਤੇ ਨਿਰਭਰਤਾ ਘਟਾਈ ਅਤੇ ਹੋਰਾਂ ਲਈ UNIX ਅਪਣਾਉਣਾ ਆਸਾਨ ਕੀਤਾ।
ਜਦੋਂ ਲੋਕ "UNIX" ਕਹਿੰਦੇ ਹਨ, ਉਹ Bell Labs ਦਾ ਅਸਲ ਵਰਜਨ, ਕੋਈ ਵਪਾਰੀ ਰੂਪ ਜਾਂ ਆਧੁਨਿਕ UNIX-ਨੁਮਾ ਸਿਸਟਮ (ਜਿਵੇਂ Linux ਜਾਂ BSD) ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮੰਨ ਸਕਦੇ ਹਨ। ਸਾਂਝਾ ਧਾਰਾ ਇੱਕੇ ਬ੍ਰਾਂਡ ਦੀ ਥਾਂ ਇੱਕ ਸਾਂਝੇ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਅਤੇ ਇੰਟਰਫੇਸ ਦਾ ਹੋਣਾ ਹੈ।
ਇਸੇ ਲਈ POSIX ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇਹ ਬਹੁਤ ਸਾਰੇ UNIX ਵਿਹਾਰਾਂ ਨੂੰ ਕੋਡਬੱਧ ਕਰਦਾ ਹੈ (ਕਮਾਂਡਾਂ, ਸਿਸਟਮ ਕਾਲ, ਰਿਵਾਜ) ਤਾਂ ਜੋ ਸਾਫਟਵੇਅਰ ਵੱਖ-ਵੱਖ UNIX ਅਤੇ UNIX-ਨੁਮਾ ਸਿਸਟਮਾਂ 'ਤੇ ਥੋੜ੍ਹੀ ਘੱਟ ਹੈਰਾਨੀ ਨਾਲ ਚੱਲ ਸਕੇ।
UNIX ਨੇ ਇੱਕ ਅਸਾਨ ਨਿਯਮ ਪ੍ਰਚਲਿਤ ਕੀਤਾ: ਐਹੋ-ਜਿਹੇ ਪ੍ਰੋਗਰਾਮ ਬਣਾਓ ਜੋ ਇੱਕ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹੋਣ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਨਾ ਆਸਾਨ ਹੋਵੇ। Ken Thompson ਅਤੇ ਸ਼ੁਰੂਆਤੀ UNIX ਟੀਮ ਦਾ ਲਕਸ਼ ਵੱਡੇ ਆਲ-ਇਨ-ਵਨ ਐਪ ਨਹੀਂ ਬਨਾਉਣਾ ਸੀ। ਉਹ ਛੋਟੀਆਂ ਉਟਿਲਿਟੀਆਂ ਚਾਹੁੰਦੇ ਸਨ ਜਿਨ੍ਹਾਂ ਦਾ ਵਿਵਹਾਰ ਸਪੱਸ਼ਟ ਹੋਵੇ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਅਸਲੀ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰ ਸਕੋ।
ਇੱਕ ਟੂਲ ਜੋ ਇੱਕ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ ਸਮਝਣਾ ਅਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਘੱਟ ਹਿੱਸੇ ਹਿਲਦੇ ਹਨ। ਇਹ ਟੈਸਟ ਕਰਨ ਲਈ ਵੀ ਆਸਾਨ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਇਸਨੂੰ ਜਾਣਿਆ ਹੋਇਆ ਇਨਪੁੱਟ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰਾ ਮਾਹੌਲ ਸੈਟਅਪ ਕਰਕੇ। ਜਦੋਂ ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਬਿਨਾਂ ਸਾਰੇ ਕੁਝ ਮੁੜ-ਲਿਖੇ ਬਦਲ ਸਕਦੇ ਹੋ।
ਇਹ ਦ੍ਰਿਸ਼ਟੀ "ਬਦਲੀਯੋਗਤਾ" ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ। ਜੇ ਕੋਈ ਯੂਟਿਲਿਟੀ ਹੌਲੀ ਹੈ ਜਾਂ ਸੀਮਤ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਜਾਂ ਨਵੀਂ ਲਿਖ ਸਕਦੇ ਹੋ, ਜੇਕਰ ਨਵਾਂ ਟੂਲ ਇੱਕੋ ਆਧਾਰਭੂਤ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ ਉਮੀਦ ਨੂੰ ਪੂਰਾ ਕਰੇ।
UNIX ਟੂਲਾਂ ਨੂੰ LEGO ਇੱਟਾਂ ਦੀ ਤਰ੍ਹਾਂ ਸੋਚੋ। ਹਰ ਇੱਟ ਸਧਾਰਨ ਹੈ। ਸ਼ਕਤੀ ਇਸ ਗੱਲ ਵਿੱਚ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ।
ਇੱਕ ਪੁਰਾਣਾ ਉਦਾਹਰਨ ਟੈਕਸਟ ਪ੍ਰੋਸੈਸਿੰਗ ਹੈ, ਜਿਥੇ ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਤਬਦੀਲ ਕਰਦੇ ਹੋ:
cat access.log | grep " 500 " | sort | uniq -c | sort -nr | head
ਜੇਕਰ ਤੁਸੀਂ commands ਯਾਦ ਨਾ ਰੱਖੋ ਤਾਂ ਵੀ ਵਿਚਾਰ ਸਪੱਸ਼ਟ ਹੈ: ਡੇਟਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਲਟਰ ਲਗਾਓ, ਸੰਖੇਪ ਬਣਾਓ, ਅਤੇ ਸਭ ਤੋਂ ਉੱਪਰ ਨਤੀਜੇ ਦਿਖਾਓ।
Microservices ਨੂੰ ਸੀਧਾ "ਨੈਟਵਰਕ ਤੇ UNIX ਟੂਲ" ਨਹੀਂ ਕਹਿਣਾ ਚਾਹੀਦਾ—ਇਹ ਮਿਸਲ ਗਲਤ ਰਾਹ ਵਿਖਾ ਸਕਦੀ ਹੈ। ਪਰ ਨੀਵਾਂ ਅਧਾਰ ਉਹੀ ਹੈ: ਭਾਗਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖੋ, ਸਾਫ਼ ਬਾਊਂਡਰੀਆਂ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਵੱਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਤੋਂ ਬਣਾਓ ਜੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਵਿਕਸਿਤ ਹੋ ਸਕਦੇ ਹਨ।
UNIX ਨੂੰ ਇੱਕ ਰਿਵਾਜ ਨੇ ਬਹੁਤ ਤਾਕਤ ਦਿੱਤੀ: ਪ੍ਰੋਗਰਾਮ ਇਕ ਨਿਰਧਾਰਿਤ ਢੰਗ ਨਾਲ ਇੱਕਥੇ ਇਨਪੁੱਟ ਪੜ੍ਹਨ ਅਤੇ ਆਉਟਪੁੱਟ ਲਿਖਣ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਸ ਰਿਵਾਜ ਨੇ ਛੋਟੇ ਟੂਲਾਂ ਨੂ ਬਿਨਾਂ ਮੁੜ-ਲਿਖੇ ਵੱਡੇ ਸਿਸਟਮਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਜੋੜਨਾ ਸੰਭਵ ਕੀਤਾ।
ਇੱਕ ਪਾਈਪ ਇੱਕ ਕਮਾਂਡ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸਿਧਾ ਦੂਜੇ ਦੇ ਇਨਪੁੱਟ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਗੋਸ਼ੇ ਵਿਚ ਨੋਟ ਪਾਸ ਕਰਨਾ ਸਮਝੋ: ਇੱਕ ਟੂਲ ਟੈਕਸਟ ਉਤਪੱਨ ਕਰਦਾ ਹੈ, ਅਗਲਾ ਉਹ ਖਪਤ ਕਰਦਾ ਹੈ।
UNIX ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਮਿਆਰੀ ਚੈਨਲ ਵਰਤਦੇ ਹਨ:
ਇਨ੍ਹਾਂ ਚੈਨਲਾਂ ਦੀ ਸੰਗਤਤਾ ਕਾਰਨ ਤੁਸੀਂ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਇਕੱਠੇ ਵਿਹਾਰ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹੋ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਬਾਰੇ ਜਾਣਨ ਦੀ ਲੋੜ ਹੋਏ।
ਪਾਈਪ ਛੋਟੇ ਅਤੇ ਕੇਂਦਰਿਤ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਉਤਸ਼ਾਹਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਪ੍ਰੋਗਰਾਮ stdin ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ stdout ਜਾਰੀ ਕਰ सकता ਹੈ, ਤਾਂ ਇਹ ਕਈ ਪ੍ਰਸੰਗਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ: ਇੰਟਰਐਕਟਿਵ ਵਰਤੋਂ, ਬੈਚ ਜੌਬ, ਸ਼ੈਡਿਊਲ ਕੰਮ, ਅਤੇ ਸਕ੍ਰਿਪਟ। ਇਸੇ ਲਈ UNIX-ਨੁਮਾ ਸਿਸਟਮ ਸਕ੍ਰਿਪਟ-ਪ੍ਰਯੋਗਕਾਰੀ ਹਨ: ਆਟੋਮੇਸ਼ਨ ਅਕਸਰ ਸਿਰਫ਼ "ਇਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਜੋੜੋ" ਹੁੰਦੀ ਹੈ।
ਇਹ ਜੋੜਨਯੋਗਤਾ ਸ਼ੁਰੂਆਤੀ UNIX ਤੋਂ ਲੈ ਕੇ ਅੱਜ ਦੇ ਕਲਾਉਡ ਵਰਕਫ਼ਲੋਜ਼ ਤੱਕ ਦੀ ਸਿੱਧੀ ਲਕੀਰ ਹੈ।
UNIX ਨੇ ਇੱਕ ਬੜਾ ਸਰਲਪਨ ਕੀਤਾ: ਵੱਖ-ਵੱਖ ਸੰਸਾਧਨਾਂ ਨੂੰ ਜੇੜ ਕੇ ਫਾਇਲ ਵਾਂਗ ਪੇਸ਼ ਕਰੋ। ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਡਿਸਕ ਫਾਇਲ ਅਤੇ ਕੀਬੋਰਡ ਇਕੋ ਜਿਹੇ ਹਨ, ਪਰ ਇਹ ਦਿੰਦਾ ਹੈ ਇੱਕ ਸਾਂਝਾ ਇੰਟਰਫੇਸ (open, read, write, close) ਜੋ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਾ ਅਤੇ ਆਟੋਮੇਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
/dev/ ਹੇਠਾਂ ਆ ਸਕਦੇ ਹਨ। /dev/urandom ਨੂੰ ਪੜ੍ਹਨਾ ਇੱਕ ਫਾਇਲ ਪੜ੍ਹਨ ਵਰਗਾ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਇਹ ਇੱਕ ਡਿਵਾਈਸ ਡ੍ਰਾਈਵਰ ਦੁਆਰਾ ਬਾਈਟ ਉਤਪੰਨ ਕਰ ਰਿਹਾ ਹੋਵੇ।ਜਦੋਂ ਸੰਸਾਧਨ ਇੱਕੋ ਇੰਟਰਫੇਸ ਸਾਂਝੇ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਲਾਭ ਮਿਲਦਾ ਹੈ: ਇੱਕ ਛੋਟੇ ਜਿਹੇ ਟੂਲ ਸੈੱਟ ਨੇ ਬਹੁਤ ਸਾਰਿਆਂ ਪ੍ਰਸੰਗਾਂ 'ਚ ਕੰਮ ਕੀਤਾ। ਜੇ "ਆਉਟਪੁੱਟ ਬਾਈਟਸ" ਅਤੇ "ਇਨਪੁੱਟ ਬਾਈਟਸ" ਹਨ, ਤਾਂ ਸਧਾਰਨ ਯੂਟਿਲਿਟੀਜ਼ ਅਨੇਕ ਤਰੀਕਿਆਂ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਬਿਨਾਂ ਹਰ ਟੂਲ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ ਤੇ ਡਿਵਾਈਸ, ਨੈੱਟਵਰਕ ਜਾਂ ਕਰਨਲ ਦੀ ਜਾਣਕਾਰੀ ਹੋਣ ਦੀ ਲੋੜ ਹੋਵੇ।
ਇਹ ਸਥਿਰਤਾ ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਟੀਮਾਂ ਕੁਝ ਪ੍ਰਿਮਿਟਿਵਸ (read/write streams, file paths, permissions) ਦੇ ਆਧਾਰ ‘ਤੇ ਸਕ੍ਰਿਪਟ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਆਦਤਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ ਕਿ ਜਦੋਂ ਵੀ ਅਧਾਰਭੂਤ ਤਕਨੀਕ ਬਦਲੇਗੀ, ਇਹ ਆਦਤ ਇੱਕ-ਦੋ ਸਟੈਪ ਵਿੱਚ ਨਹੀਂ ਟੁਟਣਗੀਆਂ।
ਆਧੁਨਿਕ ਕਲਾਉਡ ਓਪਰੇਸ਼ਨ ਵੀ ਇਸ ਵਿਚਾਰ ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਹਨ। ਕੰਟੇਨਰ ਲੌਗ ਆਮ ਤੌਰ 'ਤੇ ਅਜਿਹਾ ਹਨ ਜੋ ਤੁਸੀ tail ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਅੱਗੇ ਭੇਜ ਸਕਦੇ ਹੋ। Linux ਦਾ /proc ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਸਿਸਟਮ ਟੈਲੀਮੇਟਰੀ ਨੂੰ ਫਾਇਲਾਂ ਵਾਂਗ ਦਰਸਾਉਂਦਾ ਹੈ, ਤਾਂ ਕਿ ਮਾਨਿਟਰਿੰਗ ਏਜੇਟ CPU, ਮੈਮੋਰੀ ਅਤੇ ਪ੍ਰੋਸੈੱਸ ਸਟੈਟਸ ਨੂੰ ਆਮ ਟੈਕਸਟ ਵਾਂਗ ਪੜ੍ਹ ਸਕਣ। ਇਹ "ਫਾਇਲ-ਆਕਾਰ" ਇੰਟਰਫੇਸ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਵੱਧ ਪੈਮਾਨੇ 'ਤੇ ਆਬਜ਼ਰਵੈਬਿਲਿਟੀ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਸਹਿਜ ਬਣਾਉਂਦਾ ਹੈ।
UNIX ਦਾ ਅਧਿਕਾਰ ਮਾਡਲ ਬੇਹੱਦ ਸਧਾਰਨ ਹੈ: ਹਰ ਫਾਇਲ (ਅਤੇ ਕਈ ਸਿਸਟਮ ਸੰਸਾਧਨ ਜੋ ਫਾਇਲ ਵਾਂਗ ਵਰਤਦੇ ਹਨ) ਦਾ ਇੱਕ owner, ਇੱਕ group, ਅਤੇ ਤਿੰਨ ਦਰਸ਼ਕਾਂ ਲਈ permissions ਹੁੰਦੇ ਹਨ—user, group, ਅਤੇ others। ਸਿਰਫ read/write/execute ਬਿੱਟਸ ਨਾਲ UNIX ਇੱਕ ਸਾਂਝਾ ਭਾਸ਼ਾ ਕਾਇਮ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਦੇ -rwxr-x--- ਵਰਗਾ ਕੁਝ ਵੇਖਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਇੱਕ ਹੀ ਲਾਈਨ ਵਿੱਚ ਵੇਖ ਰਹੇ ਹੋ:
ਇਹ ਢਾਂਚਾ ਆਸਾਨੀ ਨਾਲ ਸੋਚਣਯੋਗ ਅਤੇ ਆਡਿਟ ਕਰਨਯੋਗ ਹੈ। ਇਸ ਨਾਲ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਵੱਲ ਧਕੇਲਦਾ ਹੈ: "ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕੰਮ ਕਰਵਾਉਣ ਲਈ ਸਭ ਕੁਝ ਖੋਲ੍ਹ ਕੇ ਨਾ ਰੱਖੋ"।
Least privilege ਦਾ ਮਤਲਬ ਹੈ ਕਿਸੇ ਵਿਅਕਤੀ, ਪ੍ਰੋਸੈਸ ਜਾਂ ਸੇਵਾ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਅਧਿਕਾਰ ਦਿੱਤੇ ਜਾਣ ਜੋ ਉਸਦੇ ਕੰਮ ਲਈ ਜ਼ਰੂਰੀ ਹਨ—ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਅਮਲ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਮਤਲਬ ਰੱਖਦਾ ਹੈ:
ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਅਤੇ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਇੱਕੋ ਹੀ ਵਿਚਾਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਸੰਦਾਂ ਨਾਲ ਦੁਹਰਾਉਂਦੇ ਹਨ:
UNIX ਅਧਿਕਾਰ ਕੀਮਤੀ ਹਨ—ਪਰ ਇਹ ਪੂਰੀ ਸੁਰੱਖਿਆ ਰਣਨੀਤੀ ਨਹੀਂ ਹਨ। ਇਹ ਸਾਰੀਆਂ ਡਾਟਾ ਲੀਕ ਰੋਕਦੇ ਨਹੀਂ, ਨਾਜੁਕ ਕੋਡ ਦੇ ਸ਼ੋਧ ਹੋਣ ਨੂੰ ਰੋਕਦੇ ਨਹੀਂ, ਜਾਂ ਨੈਟਵਰਕ ਕੰਟਰੋਲ ਅਤੇ ਸੀਕ੍ਰੇਟ ਪ੍ਰਬੰਧਨ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ। ਇਹਨਾਂ ਨੂੰ ਮੂਲ ਆਧਾਰ ਸਮਝੋ: ਲਾਜ਼ਮੀ, ਸਮਝਣਯੋਗ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ—ਪਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਾਫੀ ਨਹੀਂ।
UNIX ਇੱਕ ਚੱਲ ਰਹੀ ਇਕਾਈ—ਪ੍ਰੋਸੈਸ—ਨੂੰ ਮੁੱਖ ਨਿਰਮਾਣ ਖੰਡ ਵਜੋਂ ਦੇਖਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਪਿੱਛੋਕੜ ਵਿਚੋਂ। ਇਹ ਧਾਰਣਾ ਅਬਸਟ੍ਰੈਕਟ ਲੱਗਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਨਹੀਂ ਵੇਖਦੇ ਕਿ ਇਹ ਕਿਵੇਂ ਭਰੋਸੇਯੋਗਤਾ, ਬਹੁ-ਟਾਸਕਿੰਗ ਅਤੇ ਮਸ਼ੀਨ 'ਤੇ ਸਾਂਝੀ ਵਰਤੋਂ ਨੂੰ ਅਕਾਰ ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਰੈਸਿਪੀ ਕਾਰਡ ਵਾਂਗ ਹੈ: ਇਹ ਦੱਸਦਾ ਹੈ ਕੀ ਕਰਨਾ ਹੈ।
ਇੱਕ ਪ੍ਰੋਸੈਸ ਉਸ ਰੈਸਿਪੀ ਨੂੰ ਵਰਤ ਕੇ ਖਾਣਾ ਬਣਾਉਂਦੇ ਰਸੋਈਏ ਵਾਂਗ ਹੈ: ਇਸਦਾ ਆਪਣਾ ਵਤਾਂ-ਵਸਤਾਂ, ਚਲਦਾ ਰਹਿ ਰਹਾ ਸਟੇਟ, ਚੁੱਲ੍ਹਾ ਅਤੇ ਟਾਇਮਰ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕੋ ਰੈਸਿਪੀ ਦੇ ਅਨੇਕੇ ਰਸੋਈਏ ਰੱਖ ਸਕਦੇ ਹੋ—ਹਰ ਇੱਕ ਆਪਣਾ ਪ੍ਰੋਸੈਸ ਹੈ।
UNIX ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਬਣੇ ਹਨ ਕਿ ਹਰ ਪ੍ਰੋਸੈਸ ਦਾ ਆਪਣਾ "ਬਬਲ" ਹੁੰਦਾ ਹੈ: ਆਪਣੀ ਯਾਦਦਾਸ਼ਤ, ਖੁੱਲ੍ਹੀਆਂ ਫਾਇਲਾਂ ਦਾ ਆਪਣਾ ਨਜ਼ਰੀਆ, ਅਤੇ ਕੀ ਚੀਜ਼ ਛੂਹ ਸਕਦਾ ਹੈ ਦੀਆਂ ਸਪষ্ট ਸੀਮਾਵਾਂ।
ਇਹ ਆਈਸੋਲੇਸ਼ਨ ਇਸ ਲਈ मायਨੇ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਨਾਕਾਮੀਆਂ ਅਕਸਰ ਸੀਮਿਤ ਰਹਿੰਦੀਆਂ ਹਨ। ਜੇ ਇੱਕ ਪ੍ਰੋਸੈਸ ਕਰੈਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੋਰ ਪ੍ਰੋਸੈੱਸਾਂ ਨੂੰ ਨਹੀਂ ਗਿਰਾਉਂਦਾ। ਇਸੇ ਕਾਰਨ ਇਕ ਮਸ਼ੀਨ 'ਤੇ ਕਈ ਸੇਵਾਵਾਂ ਚਲਾਉਣਾ ਆਮ ਹੁੰਦਾ ਹੈ: ਵੈੱਬ ਸਰਵਰ, ਡੇਟਾਬੇਸ, ਬੈਕਗ੍ਰਾਊਂਡ ਸ਼ਡਿਊਲਰ, ਲੌਗ ਸ਼ਿੱਪਰ—ਹਰ ਇੱਕ ਵੱਖਰਾ ਪ੍ਰੋਸੈਸ ਜਿਸਨੂੰ ਅਲੱਗ-ਅਲੱਗ ਸ਼ੁਰੂ, ਰੋਕ, ਰੀਸਟਾਰਟ ਤੇ ਨਿਗਰਾਨੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਸ਼ੇਅਰ ਕੀਤੇ ਸਿਸਟਮਾਂ 'ਤੇ ਆਈਸੋਲੇਸ਼ਨ ਸਾਂਝੇ ਸਰੋਤਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ ਵਾਲੀ ਸਹਾਇਤਾ ਵੀ ਦਿੰਦੀ ਹੈ: OS ਲਿਮਿਟਜ਼ (CPU ਸਮਾਂ ਜਾਂ ਮੈਮੋਰੀ) ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਰੰਨਅਵੇ ਪ੍ਰੋਸੈਸ ਨੂੰ ਹੋਰਾਂ ਨੂੰ ਭੁੱਖਾ ਨਹੀਂ ਹੋਣ ਦਿੰਦਾ।
UNIX signals ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਪ੍ਰਣਾਲੀ (ਜਾਂ ਤੁਸੀਂ) ਵੱਲੋਂ ਇੱਕ ਪ੍ਰੋਸੈਸ ਨੂੰ ਹਲਕਾ ਸੰਦੇਸ਼ ਭੇਜਣ ਦਾ ਤਰੀਕਾ ਹੈ:
ਇੰਟਰਐਕਟਿਵ ਵਰਤੋਂ ਵਿੱਚ ਜੌਬ ਕੰਟਰੋਲ ਇਹ ਵਿਚਾਰ ਅੱਗੇ ਵਧਾਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ, ਅੱਗੇ ਲੈ ਕੇ ਆ ਸਕਦੇ ਹੋ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ। ਮਕਸਦ ਕੇਵਲ ਸੁਵਿਧਾ ਨਹੀਂ—ਬਲਕਿ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਸੈੱਸ ਜੀਵੰਤ ਇਕਾਈਆਂ ਵਜੋਂ ਪ੍ਰਬੰਧਿਤ ਕੀਤੀਆਂ ਜਾਣ।
ਜਦੋਂ ਪ੍ਰੋਸੈਸ ਬਣਾਉਣਾ, ਆਈਸੋਲੇਟ ਕਰਨਾ ਅਤੇ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਕਈ ਵਰਕਲੋਡ ਚਲਾਉਣਾ ਸਧਾਰਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਮਾਨਸਿਕ ਮਾਡਲ—ਛੋਟੇ ਯੂਨਿਟ ਜਿਨ੍ਹਾਂ ਨੂੰ ਨਿਗਰਾਨੀ, ਰੀਸਟਾਰਟ ਅਤੇ ਸੀਮਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਅੱਜ ਦੇ ਸਰਵਿਸ ਮੈਨੇਜਰ ਅਤੇ ਕੰਟੇਨਰ ਰਨਟਾਈਮਾਂ ਦਾ ਸਿੱਧਾ ਪੂਰਵਜ ਹੈ।
UNIX ਨੇ ਜਿੱਤ ਇਸ ਲਈ ਨਹੀਂ ਹਾਸਲ ਕੀਤੀ ਕਿ ਇਸ ਦੇ ਕੋਲ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਫੀਚਰ ਸੀ। ਇਸ ਲਈ ਟਿਕਿਆ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੇ ਕਈ ਇੰਟਰਫੇਸ ਨੂ “ਉਦਾਸੀਨ” ਬਣਾਇਆ—ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਦਾਸੀਨ ਰੱਖਿਆ। ਜਦੋਂ ਡਿਵੈਲਪਰ ਸਾਲਾਂ ਤੱਕ ਇੱਕੋ ਸਿਸਟਮ ਕਾਲ, ਇੱਕੋ ਕਮਾਂਡ ਲਾਈਨ ਵਿਹਾਰ, ਅਤੇ ਇੱਕੋ ਫਾਇਲ ਰਿਵਾਜ ਉੱਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਟੂਲ ਇਕੱਠੇ ਬਣਦੇ ਹਨ ਨਾ ਕਿ ਮੁੜ ਲਿਖੇ ਜਾਂਦੇ।
ਇੰਟਰਫੇਸ ਇੱਕ ਸਮਝੌਤਾ ਹੈ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਇਨ੍ਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਪ੍ਰਣਾਲੀ ਵਿਚਕਾਰ: "ਜੇ ਤੁਸੀਂ X ਮੰਗਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ Y ਮਿਲੇਗਾ।" UNIX ਨੇ ਕੁਝ ਮੁੱਖ ਸਮਝੌਤਿਆਂ (ਪ੍ਰੋਸੈਸ, ਫਾਇਲ ਡਿਸਕ੍ਰਿਪਟਰ, ਪਾਈਪ, ਅਧਿਕਾਰ) ਨੂੰ ਸਥਿਰ ਰੱਖਿਆ, ਜਿਸ ਨਾਲ ਨਵੀਆਂ ਧਾਰਣਾਵਾਂ ਉੱਪਰ ਵਧ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਪੁਰਾਣੀ ਸਾਫਟਵੇਅਰ ਨੂੰ ਤੋੜੇ।
ਲੋਕ ਅਕਸਰ "API compatibility" ਕਹਿੰਦੇ ਹਨ, ਪਰ ਦਰਅਸਲ ਦੋ ਪੱਧਰ ਹੁੰਦੇ ਹਨ:
ਸਥਿਰ ABIs ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹਨ ਜਿਨ੍ਹਾਂ ਕਰਕੇ ਇਕੋ ਇਕੋਸਿਸਟਮ ਲੰਮਾ ਸਮਾਂ ਜਿਉਂਦਾ ਹੈ: ਉਹ ਪਹਿਲਾਂ-ਬਣੇ ਸਰਪਲਾਈਡ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਨ।
POSIX ਇੱਕ ਮਿਆਰੀਕਰਨ ਯਤਨ ਹੈ ਜੋ ਸਾਂਝੇ "UNIX-ਨੁਮਾ" ਯੂਜ਼ਰ-ਸਪੇਸ (ਸਿਸਟਮ ਕਾਲ, ਯੂਟਿਲਿਟੀਜ਼, ਸ਼ੈੱਲ ਵਿਵਹਾਰ ਅਤੇ ਰਿਵਾਜ) ਨੂੰ ਫੜਦਾ ਹੈ। ਇਹ ਹਰ ਸਿਸਟਮ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਪਰ ਇਹ ਵੱਡਾ ਓਵਰਲੈਪ ਬਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕੋ ਹੀ ਸਾਫਟਵੇਅਰ Linux, BSD ਅਤੇ ਹੋਰ UNIX-ਉਤਪੰਨ ਸਿਸਟਮਾਂ 'ਤੇ ਬਣ ਅਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਕੰਟੇਨਰ ਇਮੇਜ ਸਧਾਰਨਤ: UNIX-ਨੁਮਾ ਵਿਹਾਰ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ images ਇਸਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੀਆਂ ਹਨ:
ਕੰਟੇਨਰ ਪੋਰਟੇਬਲ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਨਾ ਇਸ ਲਈ ਕਿ ਉਹ "ਸਭ ਕੁਝ" ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ, ਪਰ ਇਸ ਲਈ ਕਿ ਉਹ ਇੱਕ ਵਿਸ਼ਾਲ ਸਾਂਝੇ, ਸਥਿਰ ਕਰਾਰ ਉੱਤੇ ਬੈਠਦੇ ਹਨ। ਇਹ ਕਰਾਰ UNIX ਦਾ ਸਭ ਤੋਂ ਟਿਕਾਊ ਯੋਗਦਾਨ ਹੈ।
ਕੰਟੇਨਰ ਆਧੁਨਿਕ ਲਗਦੇ ਹਨ, ਪਰ ਮਾਨਸਿਕ ਮਾਡਲ ਬਹੁਤ UNIX-ਸਮਾਨ ਹੈ: ਇੱਕ ਚੱਲ ਰਹੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸ ਵਜੋਂ ਲੈਓ ਜਿਸਦਾ ਆਪਣੇ ਫਾਇਲ, ਅਧਿਕਾਰ ਅਤੇ ਸਰੋਤ-ਸੀਮਾਵਾਂ ਦਾ ਸੈੱਟ ਹੋਵੇ।
ਇੱਕ ਕੰਟੇਨਰ "ਹਲਕੀ VM" ਨਹੀਂ ਹੈ। ਇਹ ਹੋਸਟ ਉੱਤੇ ਚਲ ਰਹੇ ਆਮ ਪ੍ਰੋਸੈੱਸਾਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਪੈਕੇਜ (ਐਪਲਿਕੇਸ਼ਨ ਨਾਲ ਉਸ ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਕੰਫਿਗ) ਅਤੇ ਆਈਸੋਲੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਉਹ ਅਕੇਲਾ ਮਹਿਸੂਸ ਕਰਨ। ਵੱਡਾ ਫਰਕ: ਕੰਟੇਨਰ ਹੋਸਟ kernel ਭਾਗੀਦਾਰ ਕਰਦੇ ਹਨ, ਜਦਕਿ VMs ਆਪਣੇ kernel ਚਲਾਉਂਦੇ ਹਨ।
ਕਈ ਕੰਟੇਨਰ ਫੀਚਰ UNIX ਵਿਚਾਰਾਂ ਦੇ ਸਿੱਧੇ ਵਿਸਥਾਰ ਹਨ:
ਦੋ kernel ਮਕੈਨਿਜ਼ਮ ਜ਼ਿਆਦਾ ਤੋ ਜ਼ਿਆਦਾ ਭਾਰ ਉਠਾਉਂਦੇ ਹਨ:
ਕੰਟੇਨਰ ਹੋਸਟ kernel ਸਾਂਝੇ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਆਈਸੋਲੇਸ਼ਨ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ। ਇੱਕ kernel ਦੀ ਕਮਜ਼ੋਰੀ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਗਲਤ ਕਨਫਿਗਰ (root ਵਜੋਂ ਚਲਾਉਣਾ, ਚੌੜੀਆਂ capabilities ਦੇਣਾ, ਸੰਵੇਦਨਸ਼ੀਲ ਹੋਸਟ ਪਾਥ ਮਾਊਂਟ ਕਰਨਾ) ਬਾਊਂਡਰੀ ਵਿੱਚ ਛੇਦ ਕਰ ਸਕਦੇ ਹਨ। "ਐਸਕੇਪ" ਖ਼ਤਰੇ ਹਕੀਕਤ ਹਨ—ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਧਿਆਨਵਾਲੇ ਡੀਫਾਲਟ, ਘੱਟ ਅਧਿਕਾਰ ਅਤੇ ਚੰਗੀ ਓਪਰੇਸ਼ਨਲ ਹਾਈਜੀਨ ਨਾਲ ਘਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।
UNIX ਨੇ ਇੱਕ ਸਧਾਰਣ ਆਦਤ ਨੂੰ ਲੋਕਪ੍ਰિય ਕੀਤਾ: ਛੋਟੇ ਟੂਲ ਬਣਾਓ ਜੋ ਇੱਕ ਕੰਮ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਸਾਫ਼ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਜੋੜੋ, ਅਤੇ ਮਾਹੌਲ ਨੂੰ ਵਾਇਰਿੰਗ ਸੰਭਾਲਣ ਦਿਓ। Cloud-native ਸਿਸਟਮ ਬਾਹਰੋਂ ਵੱਖਰੇ ਲੱਗਦੇ ਹਨ, ਪਰ ਇੱਕੋ ਵਿਚਾਰ ਵੰਡੇ ਕੰਮ ਲਈ ਹੈ: ਸੇਵਾਵਾਂ ਕੇਂਦਰਿਤ ਰਹਿੰਦੀਆਂ ਹਨ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਪੁਆਇੰਟ ਸਪਸ਼ਟ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਓਪਰੇਸ਼ਨ ਪੇਸ਼ਗੀਯੋਗ ਰਹਿੰਦੀ ਹੈ।
ਕਲੱਸਟਰ ਵਿੱਚ, "ਛੋਟਾ ਟੂਲ" ਅਕਸਰ "ਛੋਟਾ ਕੰਟੇਨਰ" ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵੱਡਾ ਇਮੇਜ ਨਾ ਭੇਜਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਵਿਹਾਰ ਸਹੀ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਹੁੰਦੀ ਹੈ।
ਕੁਝ ਆਮ ਉਦਾਹਰਨ ਜੋ ਪੁਰਾਣੇ UNIX composition ਨੂੰ ਮਿਰਰ ਕਰਦੇ ਹਨ:
ਹਰ ਹਿੱਸਾ ਇੱਕ ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਰੱਖਦਾ ਹੈ: ਇੱਕ ਪੋਰਟ, ਇੱਕ ਫਾਇਲ, ਇੱਕ HTTP ਐਂਡਪੌਇੰਟ, ਜਾਂ stdout/stderr।
ਪਾਈਪਾਂ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਜੋੜਦੀਆਂ ਸਨ; ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ ਟੈਲੀਮੇਟਰੀ ਸਟਰੀਮ ਨੂੰ ਜੋੜਦੇ ਹਨ। ਲੌਗ, ਮੈਟਰਿਕਸ ਅਤੇ ਟ੍ਰੇਸਜ਼ ਏਜੈਂਟਾਂ, ਕਲੈਕਟਰਾਂ ਅਤੇ ਬੈਕਐਂਡਾਂ ਰਾਹੀਂ ਬਹਿ ਰਹੇ ਹੁੰਦੇ ਹਨ—ਬਿਲਕੁਲ ਇੱਕ ਪਾਈਪਲਾਈਨ:
application → node/sidecar agent → collector → storage/alerts.
ਫਾਇਦਾ ਉਹੀ ਹੈ ਜੋ ਪਾਈਪ ਵਿੱਚ ਸੀ: ਤੁਸੀਂ ਮੱਧ-ਸਥਰ (filtering, sampling, enrichment) ਨੂੰ ਦਾਖਲ, ਬਦਲ ਜਾਂ ਹਟਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪ੍ਰੋਡਯੂਸਰ ਨੂੰ ਮੁੜ-ਲਿਖੇ।
ਜੋੜਨਯੋਗ ਬਣਤਰਾਂ deployments ਨੂੰ ਦੁਹਰਾਏਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ: "ਇਹ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ" ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਡੈਕਲੇਅਰਟਿਵ ਮੈਨਿਫੈਸਟਾਂ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਕਿਸੇ ਦੀ ਯਾਦਸ਼ਕਤੀ ਵਿੱਚ ਨਹੀਂ। ਸਥਿਰ ਇੰਟਰਫੇਸ ਤੁਹਾਨੂੰ ਬਦਲਾਵ ਰੋਲ-ਆਉਟ ਕਰਨ, ਡਾਇਗਨੌਸਟਿਕਸ ਜੋੜਨ ਅਤੇ ਨੀਤੀ ਲਗੂ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ—ਇਕ ਛੋਟੇ ਯੂਨਿਟ ਤੇ ਇੱਕ ਵਾਰੀ।
ਇੱਕ ਕਾਰਨ ਜਿਸ ਕਰਕੇ UNIX ਸਿਧਾਂਤ ਮੁੜ-ਮੁੜ ਆਉਂਦੇ ਹਨ ਇਹ ਹੈ ਕਿ ਇਹ ਉਹ ਤਰੀਕਾ ਮਿਲਦਾ ਹੈ ਜਿਸੇ ਟੀਮਾਂ ਵਾਸਤਵਿਕ ਤੌਰ ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਇਟਰੈਟ ਕਰੋ, ਇੰਟਰਫੇਸ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਜਦੋਂ ਹੈਰਾਨੀ ਹੋਏ ਤਾਂ ਰੋਲਬੈਕ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਅੱਜ ਵੈੱਬ ਸੇਵਾਵਾਂ ਜਾਂ ਅੰਦਰੂਨੀ ਉਪਕਰਣ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਸ ਮਨੋਭਾਵ ਨੂੰ ਘੱਟ ਘਰਝ ਨਾਲ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕ ਰਾਏ ਦਿੰਦੇ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਸਿਸਟਮ ਦੀ ਵਰਣਨਾ ਕਰਦੇ ਹੋ, ਛੋਟੇ ਭਾਗਾਂ 'ਤੇ ਇਟਰੈਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਬਾਊਂਡਰੀਆਂ ਸਪਸ਼ਟ ਰੱਖਦੇ ਹੋ। planning mode, snapshots and rollback, ਅਤੇ source code export ਵਰਗੀਆਂ ਖਾਸੀਤਾਂ ਉਹੀ ਓਪਰੇਸ਼ਨਲ ਅਭਿਆਸ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ ਜੋ UNIX ਨੇ ਉਤਸ਼ਾਹਿਤ ਕੀਤੇ—ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲੋ, ਨਤੀਜੇ ਦੇਖੋ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਵਿਆਖ੍ਯਾਤਯੋਗ ਰੱਖੋ।
UNIX ਵਿਚਾਰ ਸਿਰਫ਼ kernel ਡਿਵੈਲਪਰਾਂ ਲਈ ਨਹੀਂ ਹਨ। ਇਹ ਦਿਨ-प्रतिदਿਨ ਇੰਜੀਨੀਅਰਿੰਗ ਲਈ ਪਰਯੋਗਿਕ ਆਦਤਾਂ ਹਨ: ਘੱਟ ਹੈਰਾਨੀਆਂ, ਸਪਸ਼ਟ ਫੇਲਿਅਰ, ਅਤੇ ਉਹ ਸਿਸਟਮ ਜੋ ਮੁੜ-ਲਿਖਾਏ ਬਿਨਾਂ ਵਿਕਸਤ ਹੋ ਸਕਦੇ ਹਨ।
ਛੋਟੇ ਇੰਟਰਫੇਸ ਆਸਾਨੀ ਨਾਲ ਸਮਝਿਆ, ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ, ਟੈਸਟ ਅਤੇ ਬਦਲਾ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸੇਵਾ ਐਂਡਪੌਇੰਟ, CLI ਫਲੈਗ ਸੈਟ, ਜਾਂ ਅੰਦਰੂਨੀ ਲਾਇਬ੍ਰੇਰੀ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ:
UNIX ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ ਪਾਰਦਰਸ਼ੀ ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਉਹ ਕੀ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਜੋ ਉਤਪੰਨ ਕਰਦੇ ਹਨ ਉਹਨੂੰ ਜਾਂਚ ਸਕਦੇ ਹੋ। ਇਹੀ ਮਿਆਰ ਸੇਵਾਵਾਂ ਅਤੇ ਪਾਈਪਲਾਈਨਾਂ ਲਈ ਲਾਗੂ ਕਰੋ:
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਕੰਟੇਨਰਾਈਜ਼ਡ ਸੇਵਾਵਾਂ ਬਣਾ ਰਹੀ ਹੈ, ਤਾਂ ਬੇਸਿਕਸ ਨੂੰ ਦੁਬਾਰਾ ਵੇਖੋ (blog post: containers-basics).
ਆਟੋਮੇਸ਼ਨ ਰਿਸਕ ਘਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾਂ ਕਿ ਵਧਾਉਣਾ। ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ ਵਰਤੋ:
permissions ਦੀ ਪ੍ਰਯੋਗਿਕ ਤਾਜ਼ਾ ਜਾਣਕਾਰੀ ਲਈ blog post: linux-permissions-explained.
ਕੋਈ ਨਵੀਂ dependency (ਫ੍ਰੇਮਵਰਕ, ਵਰਕਫ਼ਲੋ ਇੰਜਨ, ਪਲੇਟਫਾਰਮ ਫੀਚਰ) ਅਪਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਸਵਾਲ ਪੁੱਛੋ:
ਜੇ ਕਿਸੇ ਦਾ ਉੱਤਰ "ਨਹੀਂ" ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਟੂਲ ਨਹੀਂ ਖਰੀਦਦੇ—ਤੁਸੀਂ ਲਾਕ-ਇਨ ਅਤੇ ਛੁਪੇ ਹੋਏ ਜਟਿਲਤਾ ਵੀ ਖਰੀਦ ਰਹੇ ਹੋ।
UNIX ਦੋ ਵਿਰੋਧੀ ਮਿਥਾਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਦੋਹਾਂ ਗਲਤ ਹਨ।
UNIX ਕੋਈ ਇੰਸਟਾਲ ਕਰਨ ਵਾਲੀ ਉਤਪਾਦ ਨਹੀਂ—ਇਹ ਇੰਟਰਫੇਸਾਂ ਬਾਰੇ ਵਿਚਾਰਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ। ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿਕਸਤ ਹੋਈਆਂ (Linux, POSIX, systemd, containers), ਪਰ ਉਹ ਆਦਤਾਂ ਜੋ UNIX ਨੂੰ ਕਦਰਯੋਗ ਬਣਾਉਂਦੀਆਂ ਰਿਹਾੜੀਆਂ ਹਨ ਉਹ ਅਜੇ ਵੀ ਜਿੱਥੇ ਵੀ ਲੋਕ ਉਹ ਸਿਸਟਮ ਗੱਲਾਂ ਸਮਝਣ, ਡੀਬੱਗ ਕਰਨ ਅਤੇ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਉਥੇ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੰਟੇਨਰ ਲੌਗ stdout ਨੂੰ ਭੇਜਦੇ ਹਨ, ਜਦੋਂ ਇੱਕ ਟੂਲ pipe ਤੋਂ ਇਨਪੁੱਟ ਲੈਂਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਅਧਿਕਾਰ blast radius ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇੱਕੋ ਮਨੋਮਾਡਲ ਵਰਤ ਰਹੇ ਹੋ।
ਛੋਟੇ ਟੂਲਾਂ ਦੀ ਜੋੜਨਯੋਗਤਾ ਟੀਮਾਂ ਨੂੰ ਕਈ ਵਾਰੀ "ਚਤੁਰ" ਬਣਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ "ਸਪਸ਼ਟ"। composition ਇੱਕ ਤਾਕਤਵਰ ਔਜ਼ਾਰ ਹੈ: ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਮਜ਼ਬੂਤ ਰਿਵਾਜ ਅਤੇ ਧਿਆਨ ਵਾਲੀਆਂ ਹੱਦਾਂ ਹੋਣ।
ਅਤਿ-ਖੰਡਣ ਆਮ ਹੈ: ਕੰਮ ਨੂੰ ਦਹਾਂ Microservices ਜਾਂ ਬੇਹੱਦ ਛੋਟੇ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਵੰਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ "ਛੋਟਾ ਵਧੀਆ ਹੈ", ਫਿਰ ਕੋਆਰਡੀਨੇਸ਼ਨ, ਵਰਜਨਿੰਗ, ਅਤੇ ਕਰੋਸ-ਸੇਵਾ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਮਿਹਨਤ ਵਧ ਜਾਂਦੀ ਹੈ।
ਸ਼ੈੱਲ-ਸਕ੍ਰਿਪਟ ਵਿਸਤਾਰ ਵੀ ਇੱਕ ਹੋਰ ਮਸਲਾ ਹੈ: ਤੇਜ਼ ਗਲੂ ਕੋਡ ਪ੍ਰੋਡਕਸ਼ਨ-ਮੇਹਤਵਪੂਰਨ ਬਿਨਾਂ ਟੈਸਟ, ਗਲਤ ਸੰਭਾਲ, ਅਬਜ਼ਰਵੇਬਿਲਿਟੀ ਜਾਂ ਮਾਲਕੀ ਦੇ ਬਣ ਜਾਂਦਾ ਹੈ। ਨਤੀਜਾ ਕੋਈ ਸਾਦਗੀ ਨਹੀਂ—ਇਕ ਨਾਜੁਕ ਨੈੱਟ ਵਰਕ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਓਪਰੇਸ਼ਨਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸਪਸ਼ਟ ਨਹੀਂ।
ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ UNIX ਦੀਆਂ ਖੂਬੀਆਂ (ਸਥਿਰ ਇੰਟਰਫੇਸ, ਆਈਸੋਲੇਸ਼ਨ, ਆਟੋਮੇਸ਼ਨ) ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ, ਪਰ ਉਹ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਦੀ ਇੱਕ ਲੜੀ ਵੀ ਜੋੜਦੇ ਹਨ: ਕੰਟੇਨਰ ਰਨਟਾਈਮ, ਆਰਕੈਸਟਰੇਟਰ, ਸਰਵਿਸ ਮੇਸ਼, ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ, IAM ਲੇਅਰ। ਹਰ ਇਕ ਪਰਤ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੋਸ਼ਿਸ਼ ਘਟਾਂਦੀ ਹੈ ਪਰ ਜਗਤ-ਪੱਧਰ 'ਤੇ "ਕਿੱਥੇ ਫੇਲ ਹੋਇਆ?" ਦੀ ਅਨਿਸ਼ਚਿਤਤਾ ਵਧਾ ਦਿੰਦੀ ਹੈ। ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਕੰਮ ਕੋਡ ਲਿਖਣ ਤੋਂ ਜ਼ਿਆਦਾ ਇਹ ਸਮਝਣ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ ਕਿ ਸੀਮਾਵਾਂ, ਡੀਫਾਲਟ ਅਤੇ ਫੇਲਿਅਰ ਮੋਡ ਕਿਹੜੇ ਹਨ।
Ken Thompson ਦੇ UNIX ਸਿਧਾਂਤ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਿਸਟਮਾਂ ਨੂੰ ਸਧਾਰਨ ਇੰਟਰਫੇਸ, ਜੋੜਨਯੋਗ ਨਿਰਮਾਣ-ਖੰਡ ਅਤੇ least privilege ਵੱਲ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਸੋਚ-ਵਿਥਿਰਤ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਨ 'ਤੇ ਇਹ ਆਧੁਨਿਕ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਚਲਾਉਣਾ ਆਸਾਨ ਅਤੇ ਬਦਲਾਅ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ। ਸਖਤ ਰੀਤ ਨਾਲ ਲਾਗੂ ਕਰਨ 'ਤੇ ਇਹ ਬੇਕਾਰ ਤਫਰੀਕ ਅਤੇ ਮੁਸ਼ਕਲ-ਡੀਬੱਗ ਕਰਨ ਵਾਲੀ ਜਟਿਲਤਾ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਲਕਸ਼ ਹੈ 1970s UNIX ਦੀ ਨਕਲ ਨਹੀਂ ਕਰਨੀ—ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤਣਾਅ ਹੇਠਾਂ ਸਿਸਟਮ ਸਮਝਣਯੋਗ ਰਹੇ।
Ken Thompson ਅਤੇ Bell Labs ਦੀ ਟੀਮ ਨੇ ਸਮਝਣਯੋਗ, ਸੰਸ਼ੋਧਨਯੋਗ ਸਿਸਟਮਾਂ ਲਈ ਵਿਕਲਪ ਚੁਣੇ: ਇੱਕ ਛੋਟਾ ਕੇਂਦਰ, ਸਧਾਰਨ ਰਿਵਾਜ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਟੂਲ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਚੋਣਾਂ ਅਜੇ ਵੀ ਆਟੋਮੇਸ਼ਨ, ਆਈਸੋਲੇਸ਼ਨ ਅਤੇ ਵੱਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਵਰਗੀਆਂ ਆਧੁਨਿਕ ਲੋੜਾਂ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ।
UNIX ਨੂੰ C ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਣਾ ਹਾਰਡਵੇਅਰ-ਨਿਰਭਰਤਾ ਘਟਾਉਣ ਦਾ ਮੂਲ ਕਾਰਨ ਸੀ। ਇਸ ਨਾਲ OS ਅਤੇ ਉਸ ‘ਤੇ ਬਣੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ‘ਤੇ ਲੈ ਜਾਣਾ ਆਸਾਨ ਹੋ ਗਿਆ, ਜਿਸ ਨੇ POSIX ਵਰਗੀਆਂ ਮਿਆਰ-ਵਾਦੀ ਉਪਰਾਲਿਆਂ ਅਤੇ ਪੋਰਟੇਬਿਲਿਟੀ ਮਾਹਿਰਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
POSIX ਇੱਕ ਸਟੈਂਡਰਡ ਹੈ ਜੋ UNIX-ਨੁਮਾ ਤਰਤੀਆਂ (ਸਿਸਟਮ ਕਾਲ, ਯੂਟਿਲਿਟੀਜ਼, ਸ਼ੈੱਲ ਰਿਵਾਜ) ਨੂੰ ਨਿਯਮਬੱਧ ਕਰਦਾ ਹੈ। ਇਹ ਹਰ ਸਿਸਟਮ ਨੂ ਠੀਕ ਇਕੋ ਜਿਹਾ ਨਹੀਂ ਬਣਾੂੰਦਾ, ਪਰ ਇੱਕ ਵੱਡਾ ਅੰਸ਼ ਸਾਂਝਾ ਕਰਕੇ ਸਾਫਟਵੇਅਰ ਨੂ ਵੱਖ-ਵੱਖ UNIX ਅਤੇ UNIX-ਨੁਮਾ ਸਿਸਟਮਾਂ ਉੱਤੇ ਘੱਟ ਹੈਰਾਨੀ ਨਾਲ ਚਲਾਉਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਛੋਟੇ ਟੂਲ ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਆਉਂਦੇ ਹਨ, ਟੈਸਟ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਬਦਲੇ ਜਾ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਹਰ ਇੱਕ ਟੂਲ ਦਾ ਆਉਟਪੁੱਟ/ਇਨਪੁੱਟ ਨਿਰਧਾਰਿਤ ਹੋਵੇ, ਤਾਂ ਵੱਡੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਕੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਅਕਸਰ ਬਿਨਾਂ ਮੂਲ ਟੂਲਾਂ ਨੂੰ ਬਦਲੇ।
ਪਾਈਪ (|) ਇੱਕ ਕੰਮਾਂਡ ਦੇ stdout ਨੂੰ ਦੂਸਰੇ ਦੀ stdin ਨਾਲ ਜੋੜਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤਬਦੀਲੀਆਂ ਦੀ ਇੱਕ ਸਿੱਕੜ ਬਣਦੀ ਹੈ। stderr ਨੂੰ ਅਲੱਗ ਰੱਖਣ ਨਾਲ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ: ਆਮ ਨਤੀਜੇ ਪਰੋਸੈਸ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਗਲਤੀਆਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖੀਆਂ ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।
UNIX ਨੇ ਬਹੁਤ ਸਾਰੀਆਂ ਵਸਤਾਂ ਨੂੰ ਜਿਵੇਂ-ਕਿ ਫਾਈਲ ਮੰਨਣ ਦਾ ਸਧਾਰਨ ਇੰਟਰਫੇਸ ਦਿੱਤਾ—open, read, write, close। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਉੱਤੇ ਇੱਕੋ ਜਿਹੇ ਟੂਲ ਅਤੇ ਆਦਤਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (ਕੰਫਿਗ ਐਡੀਟ ਕਰਨਾ, ਲੌਗ ਟੇਲ ਕਰਨਾ, ਸਿਸਟਮ ਜਾਣਕਾਰੀ ਪੜ੍ਹਨਾ)।
ਆਮ ਉਦਾਹਰਨਾਂ ਵਿੱਚ /dev ਦੇ ਡਿਵਾਈਸ ਫਾਈਲ ਅਤੇ /proc-ਸਟਾਈਲ ਟੈਲੀਮੇਟਰੀ ਆਉਂਦੇ ਹਨ।
ਮਾਲਕ/ਗਰੁੱਪ/ਦੂਜੇ (owner/group/others) ਅਤੇ read/write/execute ਬਿੱਟਸ ਦੇ ਕੇ ਮੂਲ ਅਧਿਕਾਰਾਂ ਦੀ ਮਾਡਲ ਆਸਾਨੀ ਨਾਲ ਸੋਚਣਯੋਗ ਅਤੇ ਆਡਿਟ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। Least privilege ਦਾ ਅਰਥ ਹੈ ਕਿ ਕਿਸੇ ਵਿਅਕਤੀ, ਪ੍ਰੋਸੈਸ ਜਾਂ ਸੇਵਾ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਅਧਿਕਾਰ ਦਿੱਤੇ ਜਾਣ ਜੋ ਉਸਦੇ ਕੰਮ ਲਈ ਲਾਜ਼ਮੀ ਹਨ।
ਵਾਸਤਵਿਕ ਕਦਮ:
ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਸਥਿਰ ਕੋਡ ਹੈ; ਇੱਕ ਪ੍ਰੋਸੈਸ ਉਸ ਕੋਡ ਦੀ ਚੱਲ ਰਹੀ ਨਕਲ ਹੈ ਜਿਸਦੀ ਆਪਣੀ ਰਾਜ-ਅਵਸਥਾ ਹੁੰਦੀ ਹੈ। UNIX ਦੀ ਪ੍ਰੋਸੈਸ ਆਈਸੋਲੇਸ਼ਨ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਪ੍ਰੋਸੈਸ ਦੀ ਨਾਕਾਮੀ ਆਮ ਤੌਰ 'ਤੇ ਹੋਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੀ।
ਇਹ ਮਾਡਲ ਨਿਗਰਾਨੀ ਅਤੇ ਸੇਵਾ ਪ੍ਰਬੰਧਨ (start/stop/restart/monitor) ਦੇ ਆਧਾਰ 'ਤੇ ਅਧਾਰਿਤ ਹੈ।
Stable interfaces ਉਹ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਟਿਕਣ ਵਾਲੇ ਕਰਾਰ ਹਨ (ਜਿਵੇਂ ਕਿ ਸਿਸਟਮ ਕਾਲ, ਫਾਇਲ ਡਿਸਕ੍ਰਿਪਟਰ, ਸਿਗਨਲ) ਜੋ ਹਜ਼ਾਰਾਂ ਟੂਲਾਂ ਨੂੰ ਇਕੱਠੇ ਬਣਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਕਿਸੇ ਵੀ ਵੱਡੇ ਇਕੋਸਿਸਟਮ ਦੇ ਟਿਕਾਊ ਰਹਿਣ ਦਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ABI ਸਕੇਟ ਹੈ।
ਕੰਟੇਨਰ ਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸ-ਆਧਾਰਿਤ ਪੈਕੇਜਿੰਗ ਅਤੇ ਆਈਸੋਲੇਸ਼ਨ ਸਮਝੋ, ਨਾਂ ਕਿ ਹਲਕੀ VM। ਕੰਟੇਨਰ ਹੋਸਟ kernel ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਜਦਕਿ VM ਆਪਣੇ kernel ਚਲਾਉਂਦੇ ਹਨ।
ਮੁੱਖ ਕਨਰਲ ਮਕੈਨਿਜ਼ਮ:
ਗ਼ਲਤ ਕਨਫਿਗਰ (root ਵਜੋਂ ਚਲਾਉਣਾ, ਚੌੜੀ capabilities, ਹੋਸਟ ਪਾਥ ਮਾਉਂਟ ਕਰਨਾ) ਆਈਸੋਲੇਸ਼ਨ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹਨ।