ਡਿਲੀਵਰੀ ਟੂਲਸ ਦਾ ਵਿਕਾਸ, ਜਾਂ ਡੌਕਰ, ਡੇਬ, ਜਾਰ ਅਤੇ ਹੋਰ ਬਾਰੇ ਵਿਚਾਰ

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

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

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

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

ਕੈਲਕੂਲੇਟਰਾਂ ਦਾ ਯੁੱਗ

ਨਹੀਂ, ਪਹਿਲਾਂ ਵੀ ਇੱਕ ਪਲ ਸੀ, ਇੱਕ ਕੈਲਕੁਲੇਟਰ ਵੀ ਸੀ MK-61 и MK-52.

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

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

ਕੈਲਕੁਲੇਟਰ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮ ਦਾ ਆਕਾਰ 105 ਕਦਮ ਸੀ, ਅਤੇ MK-52 ਵਿੱਚ ਸਥਾਈ ਮੈਮੋਰੀ ਦਾ ਆਕਾਰ 512 ਕਦਮ ਸੀ।

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

• ਐਂਡਰੌਇਡ ਲਈ ਏਮੂਲੇਟਰ MK-61
• MK-61 ਲਈ ਪ੍ਰੋਗਰਾਮ ਕੈਟਾਲਾਗ

MK-52 ਬਾਰੇ ਇੱਕ ਛੋਟਾ ਵਿਚਾਰ (ਵਿਕੀਪੀਡੀਆ ਤੋਂ)

MK-52 ਨੇ Soyuz TM-7 ਪੁਲਾੜ ਯਾਨ 'ਤੇ ਪੁਲਾੜ ਵਿੱਚ ਉਡਾਣ ਭਰੀ। ਆਨ-ਬੋਰਡ ਕੰਪਿਊਟਰ ਫੇਲ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਲੈਂਡਿੰਗ ਟ੍ਰੈਜੈਕਟਰੀ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਣੀ ਸੀ।

52 ਤੋਂ, ਐਮਕੇ-1988 ਇਲੈਕਟ੍ਰੋਨਿਕਾ-ਐਸਟਰੋ ਮੈਮੋਰੀ ਐਕਸਪੈਂਸ਼ਨ ਯੂਨਿਟ ਦੇ ਨਾਲ ਨੇਵੀਗੇਸ਼ਨਲ ਕੰਪਿਊਟਿੰਗ ਕਿੱਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਨੇਵੀ ਜਹਾਜ਼ਾਂ ਨੂੰ ਸਪਲਾਈ ਕੀਤਾ ਗਿਆ ਹੈ।

ਪਹਿਲੇ ਨਿੱਜੀ ਕੰਪਿਊਟਰ

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

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

ਭਰੋਸੇਮੰਦ ਅਤੇ ਵੱਡੇ ਸਟੋਰੇਜ਼ ਮੀਡੀਆ ਦਾ ਉਭਾਰ

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

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

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

ਉਸ ਸਮੇਂ, ਲੀਨਕਸ ਦੀ ਹੋਂਦ ਮੇਰੇ ਲਈ ਅਜੇ ਖੁੱਲੀ ਨਹੀਂ ਸੀ; ਮੈਂ MS DOS ਅਤੇ, ਬਾਅਦ ਵਿੱਚ, ਵਿੰਡੋਜ਼ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਰਹਿੰਦਾ ਸੀ, ਅਤੇ ਬੋਰਲੈਂਡ ਪਾਸਕਲ ਅਤੇ ਡੇਲਫੀ ਵਿੱਚ ਲਿਖਿਆ ਸੀ, ਕਈ ਵਾਰ C++ ਵੱਲ ਵੇਖਦਾ ਸੀ। ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੇ ਉਸ ਸਮੇਂ ਉਤਪਾਦਾਂ ਨੂੰ ਡਿਲੀਵਰ ਕਰਨ ਲਈ InstallShield ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ru.wikipedia.org/wiki/InstallShield, ਜਿਸ ਨੇ ਸੌਫਟਵੇਅਰ ਦੀ ਤੈਨਾਤੀ ਅਤੇ ਸੰਰਚਨਾ ਦੇ ਸਾਰੇ ਨਿਰਧਾਰਤ ਕੰਮਾਂ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਹੱਲ ਕੀਤਾ ਹੈ।

ਇੰਟਰਨੈੱਟ ਯੁੱਗ

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

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

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

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

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

RPM ਅਤੇ DEB ਪੈਕੇਜ

ਦੂਜੇ ਪਾਸੇ, ਇੰਟਰਨੈਟ ਦੇ ਵਿਕਾਸ ਦੇ ਨਾਲ, UNIX-ਵਰਗੇ ਸਿਸਟਮਾਂ ਨੇ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ, ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਉਸ ਸਮੇਂ ਸੀ ਜਦੋਂ ਮੈਂ ਲਗਭਗ 6 ਵਿੱਚ RedHat Linux 2000 ਦੀ ਖੋਜ ਕੀਤੀ ਸੀ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਸਾਫਟਵੇਅਰ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਕੁਝ ਸਾਧਨ ਵੀ ਸਨ; ਵਿਕੀਪੀਡੀਆ ਦੇ ਅਨੁਸਾਰ, RPM ਮੁੱਖ ਪੈਕੇਜ ਮੈਨੇਜਰ ਵਜੋਂ 1995 ਵਿੱਚ, RedHat Linux 2.0 ਦੇ ਸੰਸਕਰਣ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ। ਅਤੇ ਉਦੋਂ ਤੋਂ ਅਤੇ ਅੱਜ ਤੱਕ, ਸਿਸਟਮ RPM ਪੈਕੇਜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਡਿਲੀਵਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕਾਫ਼ੀ ਸਫਲਤਾਪੂਰਵਕ ਮੌਜੂਦ ਅਤੇ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ।

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

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

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

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਵਰਤਮਾਨ ਵਿੱਚ ਡੈਬ ਤੋਂ ਦੂਰ ਜਾਣ ਅਤੇ ਸਨੈਪ ਪੈਕੇਜਾਂ ਵਿੱਚ ਸਵਿਚ ਕਰਨ ਵੱਲ ਕੁਝ ਕਦਮ ਹਨ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ.

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

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

ਮੈਂ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਕਿ ਅਸੀਂ ਡੌਕਰ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਕੀ ਹੋਇਆ.

ਸਵੈ-ਲਿਖਤ ਸਕ੍ਰਿਪਟਾਂ

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

ਪਰ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਕਈ ਨੁਕਸਾਨ ਹਨ:

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

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

ਇਹ ਸਭ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਤੈਨਾਤੀ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਦੀ ਸੀਮਾ ਨੂੰ ਸਿਰਫ਼ ਸਰਲ ਸਿਸਟਮਾਂ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਬਦਲਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ।

ਡੌਕਰ

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

ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਅਸੁਵਿਧਾਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ?

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

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

ਜਿਵੇਂ ਕਿ ਅਭਿਆਸ ਨੇ ਦਿਖਾਇਆ ਹੈ, ਅਸਲ ਵਿੱਚ ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ, ਡੇਬ ਪੈਕੇਜ 90% ਮਾਮਲਿਆਂ ਵਿੱਚ ਕਾਫ਼ੀ ਹੈ.

ਚੰਗਾ ਪੁਰਾਣਾ ਡੈਬ ਕਦੋਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਾਨੂੰ ਅਸਲ ਵਿੱਚ ਡੌਕਰ ਦੀ ਕਦੋਂ ਲੋੜ ਹੁੰਦੀ ਹੈ?

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

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

ਸਨੈਪ ਪੈਕੇਜ

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

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

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਤੁਸੀਂ ਡਿਲੀਵਰੀ ਲਈ ਕੀ ਵਰਤਦੇ ਹੋ?

• ਸਵੈ-ਲਿਖਤ ਸਕ੍ਰਿਪਟਾਂ

• FTP 'ਤੇ ਦਸਤੀ ਕਾਪੀ ਕਰੋ

• deb ਪੈਕੇਜ

• rpm ਪੈਕੇਜ

• ਸਨੈਪ ਪੈਕੇਜ

• ਡੌਕਰ-ਚਿੱਤਰ

• ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਚਿੱਤਰ

• ਪੂਰੇ HDD ਨੂੰ ਕਲੋਨ ਕਰੋ

• ਕਠਪੁਤਲੀ

• ਜਵਾਬਦੇਹ

• ਹੋਰ

109 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਪਾਈ। 32 ਉਪਭੋਗਤਾ ਪਰਹੇਜ਼ ਰਹੇ।

ਸਰੋਤ: www.habr.com