ਜਾਣੋ ਕਿ Docker ਕਿਵੇਂ ਟੀਮਾਂ ਨੂੰ ਇੱਕੋ ਐਪ ਲੈਪਟੌਪ ਤੋਂ ਕਲਾਊਡ ਤੱਕ ਇਕਸਾਰ ਚਲਾਉਣ, deployment ਸਧਾਰਨ ਕਰਨ, portability ਸੁਧਾਰਨ ਅਤੇ environment ਸਮੱਸਿਆਵਾਂ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਅਕਸਰ ਕਲਾਊਡ ਡਿਪਲੌਯਮੈਂਟ ਦੇ ਦਰਦ ਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਪਰਿਚਿਤ ਹੈਰਾਨੀ ਨਾਲ ਹੁੰਦੀ ਹੈ: ਐਪ ਲੈਪਟੌਪ 'ਤੇ ਚੱਲਦੀ ਹੈ, ਪਰ ਕਲਾਊਡ ਸਰਵਰ 'ਤੇ ਜਾ ਕੇ fail ਹੋ ਜਾਂਦੀ ਹੈ। ਸ਼ਾਇਦ ਸਰਵਰ 'ਤੇ Python ਜਾਂ Node ਦਾ ਵੱਖਰਾ ਵਰਜ਼ਨ ਹੋਵੇ, ਕੋਈ ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀ ਗਈ ਹੋਵੇ, configuration ਫਾਇਲ ਥੋੜ੍ਹੀ ਵੱਖਰੀ ਹੋਵੇ, ਜਾਂ ਕੋਈ background ਸੇਵਾ ਚੱਲ ਨਹੀਂ ਰਹੀ। ਇਹ ਛੋਟੇ-ਛੋਟੇ ਫਰਕ ਮਿਲ ਕੇ ਵੱਡੇ ਸਮੱਸਿਆਵਾਂ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਮਾਹੌਲ debug ਕਰਨ ਵਿੱਚ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ ਬਜਾਏ ਕਿ ਉਤਪਾਦ ਸੁਧਾਰਣ ਦੇ।
Docker ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਉਸਦੇ ਰਨਟਾਈਮ ਅਤੇ dependencies ਦੇ ਨਾਲ ਪੈਕੇਜ ਕਰਕੇ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ। "ਸੰਸਥਾ ਕਰੋ: version X install ਕਰੋ, ਫਿਰ library Y ਜੋੜੋ, ਫਿਰ ਇਹ config ਸੈੱਟ ਕਰੋ" ਦੇ ਜਗ੍ਹਾ, ਤੁਸੀਂ ਇੱਕ container image ਭੇਜਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਇਹ ਸਾਰਾ ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਹੋਵੇ।
ਇੱਕ ਲਾਭਦਾਇਕ ਮਨੋ-ਨਕਸ਼ਾ ਹੈ:
ਜਦੋਂ ਤੁਸੀਂ ਉਹੀ image ਕਲਾਊਡ 'ਤੇ ਚਲਾਉਂਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਲੋਕਲ 'ਤੇ ਟੈਸਟ ਕੀਤਾ ਸੀ, ਤਾਂ "ਪਰ ਮੇਰਾ ਸਰਵਰ ਵੱਖਰਾ ਹੈ" ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਹੁਤ ਘੱਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
Docker ਵੱਖ-ਵੱਖ ਰੋਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਲਈ ਮਦਦ ਕਰਦਾ ਹੈ:
Docker ਬਹੁਤ ਮਦਦਗਾਰ ਹੈ, ਪਰ ਇਹ ਇਕੱਲਾ ਟੂਲ ਨਹੀਂ ਹੈ ਜਿਸ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਪਵੇਗੀ। ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ configuration, secrets, data storage, networking, monitoring ਅਤੇ scaling ਜਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਮੈਨੇਜ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ, Docker ਇਕ ਬਿਲਡਿੰਗ ਬਲਾਕ ਹੈ ਜੋ Docker Compose ਵਰਗੇ ਟੂਲਾਂ ਨਾਲ ਲੋਕਲ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਅਤੇ production ਵਿੱਚ orchestration ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।
Docker ਨੂੰ ਆਪਣੀ ਐਪ ਲਈ ਇੱਕ shipping container ਦੀ ਤਰ੍ਹਾਂ ਸੋਚੋ: ਇਹ delivery ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਬੰਦਰਗਾਹ (ਕਲਾਊਡ ਸੈਟਅਪ ਅਤੇ ਰਨਟਾਈਮ) 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ, ਉਹ ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ—ਪਰ ਜਦੋਂ ਹਰ shipment ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਪੈਕ ਹੋਵੇ ਤਾਂ ਸਭ ਕੁਝ ਕਾਫੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
Docker ਵਿੱਚ ਨਵੇਂ ਸ਼ਬਦਾਵਲੀ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਅਸਲ ਵਿਚਾਰ ਸਧਾਰਣ ਹੈ: ਆਪਣੀ ਐਪ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਪੈਕੇਜ ਕਰੋ ਕਿ ਇਹ ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ ਤਰ੍ਹਾਂ ਚੱਲੇ।
A virtual machine ਇੱਕ ਪੂਰੇ guest operating system ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਦੇ ਨਾਲ ਬੰਡਲ ਕਰਦੀ ਹੈ। ਇਹ ਲਚਕੀਲਾ ਹੈ ਪਰ ਭਾਰੀ ਅਤੇ ਸਟਾਰਟ ਕਰਨ ਵਿੱਚ ਧੀਮਾ ਹੁੰਦਾ ਹੈ।
A container ਤੁਹਾਡੀ ਐਪ ਅਤੇ ਇਸ ਦੀਆਂ dependencies ਨੂੰ ਬੰਡਲ ਕਰਦਾ ਹੈ, ਪਰ host ਮਸ਼ੀਨ ਦੇ OS kernel ਨੂੰ ਸ਼ੇਅਰ ਕਰਦਾ ਹੈ। ਇਸ ਕਰਕੇ containers ਆਮ ਤੌਰ 'ਤੇ ਲੈਟਰ ਹਨ, ਸਕਿੰਟਾਂ ਵਿੱਚ ਸਟਾਰਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕੋ ਸਰਵਰ 'ਤੇ ਹੋਰ ਜ਼ਿਆਦਾ ਚਲਾਉਣ ਦੀ ਸਮਰੱਥਾ ਹੁੰਦੀ ਹੈ।
Image: ਤੁਹਾਡੀ ਐਪ ਲਈ ਇੱਕ read-only ਟੈਮਪਲੇਟ। ਇਸਨੂੰ ਇੱਕ packaged artifact ਵਜੋਂ ਸੋਚੋ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡਾ ਕੋਡ, ਰਨਟਾਈਮ, ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਡੀਫ਼ੌਲਟ ਸੈਟਿੰਗਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ।
Container: ਇੱਕ image ਦੀ ਚੱਲ ਰਹੀ ਨਕਲ। ਜੇ image ਇੱਕ ਨਕਸ਼ਾ ਹੈ ਤਾਂ container ਉਹ ਘਰ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਰਹਿ ਰਹੇ ਹੋ।
Dockerfile: ਉਹ ਕਦਮ-ਬਦ-ਕਦਮ ਨਿਰਦੇਸ਼ ਜੋ Docker image ਬਣਾਉਂਦੇ ਸਮੇਂ ਵਰਤਦਾ ਹੈ (dependencies install ਕਰਨਾ, ਫਾਇਲਾਂ copy ਕਰਨਾ, startup command ਸੈੱਟ ਕਰਨਾ)।
Registry: images ਲਈ ਸਟੋਰੇਜ ਅਤੇ distribution ਸਰਵਿਸ। ਤੁਸੀਂ images ਨੂੰ registry 'ਤੇ push ਕਰਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ servers ਤੋਂ pull ਕਰਦੇ ਹੋ (public registries ਜਾਂ ਕੰਪਨੀ ਦੇ ਅੰਦਰ private ones)।
ਇੱਕ ਵਾਰੀ ਤੁਹਾਡੀ ਐਪ Dockerfile ਤੋਂ ਬਣੀ image ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਹੋ ਜਾਵੇ, ਤੁਹਾਨੂੰ ਇੱਕ standardized delivery ਯੂਨਿਟ ਮਿਲਦਾ ਹੈ। ਇਹ standardization releases ਨੂੰ repeatable ਬਣਾਉਂਦੀ ਹੈ: ਉਹੀ image ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕੀਤਾ ਸੀ, ਉਹੀ ਤੁਸੀਂ deploy ਕਰਦੇ ਹੋ।
ਇਹ handoffs ਨੂੰ ਵੀ ਸਧਾਰਨ ਕਰਦਾ ਹੈ। "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ" ਦੀ ਬਜਾਏ, ਤੁਸੀਂ registry ਵਿੱਚ ਇੱਕ ਖਾਸ image ਵਰਜ਼ਨ ਨੂੰ ਨਿਸ਼ਾਨ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕਹਿ ਸਕਦੇ ਹੋ: ਇਹ container ਚਲਾਓ, ਇਹਨਾਂ environment variables ਨਾਲ, ਇਸ ਪੋਰਟ 'ਤੇ। ਇਹ development ਅਤੇ production ਵਾਤਾਵਰਣਾਂ ਲਈ ਸਥਿਰਤਾ ਦੀ ਨੀਂਹ ਹੈ।
Docker ਕਲਾਊਡ ਡਿਪਲੌਯਮੈਂਟ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡਾ ਫਾਇਦਾ consistency ਹੈ। ਲੈਪਟੌਪ, CI runner, ਜਾਂ cloud VM 'ਤੇ ਜੋ ਕੁਝ ਵੀ ਇੰਸਟਾਲ ਹੈ ਉਸ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ environment Dockerfile ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਹਰ ਸਟੇਜ ਵਿੱਚ ਦੁਹਰਾਉਂਦੇ ਹੋ।
ਵਰਤੋਂਕਾਰਕ ਤੌਰ 'ਤੇ consistency ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਸਦੀ ਹੈ:
ਇਹ consistency ਜਲਦੀ ਹੀ ਲਾਭ ਦਿੰਦੀ ਹੈ। ਜੋ bug production ਵਿੱਚ ਆ ਰਿਹਾ ਹੈ, ਉਸਨੂੰ ਲੋਕਲ 'ਤੇ ਉਸੋ image tag ਚਲਾਕੇ reproduce ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ deploy ਕਿਸੇ ਮਿਸਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਕਰਕੇ fail ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਹ ਘੱਟ ਸੰਭਵ ਹੈ ਕਿਉਂਕਿ ਉਹੀ ਲਾਇਬ੍ਰੇਰੀ ਤੁਹਾਡੇ test container ਵਿੱਚ ਵੀ ਗਾਇਬ ਰਹਿੰਦੀ।
ਟੀਮਾਂ ਅਕਸਰ setup docs ਜਾਂ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ standardize ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ। ਮੁਸਲਸਲ drift ਮੁੱਖ ਸਮੱਸਿਆ ਹੈ: ਮਸ਼ੀਨਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ ਜਦੋਂ patches ਅਤੇ package updates ਆਉਂਦੇ ਹਨ, ਅਤੇ ਫਰਕ ਹੌਲੇ-ਹੌਲੇ ਵਧਦੇ ਜਾਂਦੇ ਹਨ।
Docker ਨਾਲ, environment ਨੂੰ ਇੱਕ artifact ਵਜੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤੁਸੀਂ ਨਵੀਂ image rebuild ਕਰਦੇ ਹੋ ਅਤੇ deploy ਕਰਦੇ ਹੋ—ਜਿਸ ਨਾਲ ਬਦਲਾਵਾਂ ਖੁੱਲ੍ਹੇ ਅਤੇ reviewable ਬਣ ਜਾਂਦੇ ਹਨ। ਜੇ ਅਪਡੇਟ ਸਮੱਸਿਆ ਕਰਦਾ ਹੈ, ਤਾਂ rollback ਆਮ ਤੌਰ 'ਤੇ ਪਿਛਲੇ ਜਾਣੇ-ਪਛਾਣੇ tag ਨੂੰ deploy ਕਰਨਾ ਹੀ ਹੁੰਦਾ ਹੈ।
Docker ਦਾ ਦੂਸਰਾ ਵੱਡਾ ਫਾਇਦਾ portability ਹੈ। ਇੱਕ container image ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇੱਕ portable artifact ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਇੱਕ ਵਾਰੀ ਬਣਾਓ, ਫਿਰ ਜਿੱਥੇ ਵੀ compatible container runtime ਹੋਵੇ, ਚਲਾਓ।
Docker image ਤੁਹਾਡੇ ਐਪ ਕੋਡ ਅਤੇ ਇਸਦੇ runtime ਨਿਰਭਰਤਾਵਾਂ (ਉਦਾਹਰਣ ਲਈ Node.js, Python packages, ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀਆਂ) ਨੂੰ ਬੰਡਲ ਕਰਦਾ ਹੈ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਇਕ image ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਲੈਪਟੌਪ 'ਤੇ ਚਲਾਉਂਦੇ ਹੋ, ਉਹ ਇਹਨਾਂ 'ਤੇ ਵੀ ਚਲ ਸਕਦੀ ਹੈ:
ਇਸ ਨਾਲ application runtime ਪੱਧਰ 'ਤੇ vendor lock-in ਘੱਟ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਫਿਰ ਵੀ cloud-native ਸੇਵਾਵਾਂ ਵਰਤ ਸਕਦੇ ਹੋ (DBs, queues, storage), ਪਰ ਤੁਹਾਡੀ ਕੋਰ ਐਪ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ ਜੇਕਰ ਤੁਸੀਂ host ਬਦਲਦੇ ਹੋ।
Portability ਉਸ ਵੇਲੇ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ images ਨੂੰ ਇੱਕ registry ਵਿੱਚ store ਅਤੇ version ਕੀਤਾ ਜਾਂਦਾ ਹੈ—public ਜਾਂ private। ਆਮ ਵਰਕਫਲੋ ਇਹ ਹੈ:
myapp:1.4.2).Registries deployments ਨੂੰ reproduce ਅਤੇ audit ਕਰਨਾ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਜੇ production 1.4.2 ਚੱਲ ਰਿਹਾ ਹੈ, ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਉਹੀ artifact pull ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਕਸੇ ਬਿਟਸ ਪ੍ਰਾਪਤ ਕਰੋ।
ਹੋਸਟਾਂ ਮਾਈਗ੍ਰੇਟ ਕਰਨੀ ਹੋਵੇ: ਜੇ ਤੁਸੀਂ ਇੱਕ VM ਪ੍ਰੋਵਾਈਡਰ ਤੋਂ ਦੂਜੇ 'ਤੇ ਜਾ ਰਹੇ ਹੋ, ਤੁਹਾਨੂੰ stack ਨੂੰ ਮੁੜ install ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ। ਨਵੇਂ ਸਰਵਰ ਨੂੰ registry ਵਲ ਇੰਗਾ ਕਰੋ, image pull ਕਰੋ, ਅਤੇ same config ਨਾਲ container start ਕਰੋ।
ਸਕੇਲ ਆਉਟ ਕਰਨਾ: ਵਧੇਰੇ capacity ਚਾਹੀਦੀ ਹੋਵੇ? ਉਹੀ image ਤੋਂ ਹੋਰ containers start ਕਰੋ ਵਧੇਰੇ ਸਰਵਰਾਂ 'ਤੇ। ਹਰ instance ਇੱਕੋ ਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ scaling ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਹੱਥੋਂ-ਹੱਥ ਸੈਟਅਪ।
ਅਚ্ছে Docker image ਦਾ ਮਤલਬ ਸਿਰਫ਼ "ਓਹ ਚੱਲ ਜਾਂਦੀ ਹੈ" ਨਹੀਂ। ਇਹ ਇੱਕ ਪੈਕੇਜਡ, versioned artifact ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ rebuild ਕਰਕੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ। ਇਹੀ ਗੱਲ cloud deployments ਨੂੰ predictable ਬਣਾਉਂਦੀ ਹੈ।
Dockerfile ਵੇਖਣ ਵਿੱਚ ਇੱਕ recipe ਵਾਂਗ ਹੈ—ਕਦਮ-ਬ-ਕਦਮ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਆਪਣੀ ਐਪ imageassemble ਕਰਨੀ ਹੈ। ਹਰ ਲਾਈਨ ਇੱਕ layer ਬਣਾਉਂਦੀ, ਅਤੇ ਮਿਲ ਕੇ ਇਹ ਦਰਸਾਉਂਦੀ:
ਇਸ ਫਾਇਲ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਮੰਤਵਪੂਰਨ ਰੱਖਣਾ image ਨੂੰ debug, review ਅਤੇ maintain ਕਰਨ 'ਚ ਅਸਾਨੀ ਲਿਆਉਂਦਾ ਹੈ।
ਛੋਟੇ images ਤੇਜ਼ੀ ਨਾਲ pull ਹੁੰਦੇ ਹਨ, ਤੇਜ਼ੀ ਨਾਲ start ਹੁੰਦੇ ਹਨ, ਅਤੇ ਘੱਟ "ਫਜ਼ੂਲ ਚੀਜ਼ਾਂ" ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਟੂਟ ਸਕਦੀਆਂ ਹਨ ਜਾਂ vulnerabilities ਰੱਖਦੀਆਂ ਹਨ।
alpine ਜਾਂ slim variants) ਜੇ ਇਹ ਤੁਹਾਡੇ ਐਪ ਨਾਲ compatible ਹੋਵੇ।ਕਈ ਐਪਸ ਨੂੰ compilers ਅਤੇ build tools ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ runtime 'ਚ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਹੀਂ। Multi-stage builds ਤੁਹਾਨੂੰ ਇੱਕ stage build ਲਈ ਅਤੇ ਇੱਕ ਦੂਜੀ minimal stage production ਲਈ ਵਰਤਣ ਦਿੰਦੇ ਹਨ.
# build stage
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# runtime stage
FROM nginx:1.27-alpine
COPY --from=build /app/dist /usr/share/nginx/html
ਨਤੀਜਾ ਇੱਕ ਛੋਟੀ production image ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਘੱਟ dependencies ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ patch ਕਰਨਾ ਪੈਂਦਾ।
Tags ਤੁਹਾਨੂੰ ਇਸ ਗੱਲ ਦੀ ਪਛਾਣ ਦਿੰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਆ deploy ਕੀਤਾ।
latest ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ; ਇਹ ਅਸਪਸ਼ਟ ਹੈ।1.4.2)।1.4.2-<sha> ਜਾਂ ਸਿੱਧਾ <sha>) ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਇੱਕ image ਨੂੰ ਕੋਡ ਨਾਲ trace ਕਰ ਸਕੋ।ਇਹ clean rollbacks ਅਤੇ ਸੁਪਾਟ audits ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਬਦਲਦਾ ਹੈ।
ਇੱਕ "ਅਸਲ" ਕਲਾਊਡ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਹੀ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇੱਕ ਛੋਟਾ ਸਿਸਟਮ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਵੈਬ frontend, ਇੱਕ API, ਸ਼ਾਇਦ ਇੱਕ background worker, ਨਾਲ ਹੀ ਇੱਕ ਡੇਟਾਬੇਸ ਜਾਂ cache। Docker ਸਧਾਰਨ ਅਤੇ multi-service ਸੈਟਅਪ ਦੋਹਾਂ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ—ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇਹ ਸਮਝਣਾ ਹੁੰਦਾ ਹੈ ਕਿ containers ਇਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹਨ, configuration ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ data restarts ਤੋਂ ਬਾਅਦ ਕਿਵੇਂ survive ਕਰਦੀ ਹੈ।
Single-container app ਇੱਕ static site ਜਾਂ ਇੱਕ ਐਸੀ API ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ। ਤੁਸੀਂ ਇੱਕ ਪੋਰਟ expose ਕਰਦੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ 8080) ਅਤੇ ਚਲਾਉਂਦੇ ਹੋ।
Multi-service apps ਜ਼ਿਆਦਾਤਰ ਆਮ ਹਨ: web api 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, api db 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ worker queue ਤੋਂ jobs ਖਾਂਦਾ ਹੈ। IP addresses hard-code ਕਰਨ ਦੀ ਥਾਂ, containers ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ shared network 'ਤੇ service name ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਣ: db:5432)।
Docker Compose ਲੋਕਲ development ਅਤੇ staging ਲਈ ਇੱਕ ਪ੍ਰੈਗਟਿਕਲ ਚੋਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਸਾਰੀ stack start ਕਰਨ ਦਿੰਦਾ। ਇਹ ਤੁਹਾਡੇ ਐਪ ਦੀ "ਆਕਾਰ" (services, ports, dependencies) ਨੂੰ ਇੱਕ ਫਾਇਲ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਜੋ ਪੂਰੀ ਟੀਮ ਸਾਂਝਾ ਕਰ ਸਕਦੀ ਹੈ।
ਇੱਕ ਆਮ ਤਰੱਕੀ ਇਹ ਹੈ:
Images ਨੂੰ reusable ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਯੋਗ ਰੱਖੋ। ਵਾਤਾਵਰਣ-ਖਾਸ ਸੈਟਿੰਗਾਂ image ਤੋਂ ਬਾਹਰ ਰੱਖੋ:
ਇਹਨਾਂ ਨੂੰ environment variables, ਇੱਕ .env ਫਾਇਲ (ਸਾਵਧਾਨ: commit ਨਾ ਕਰੋ), ਜਾਂ ਤੁਹਾਡੇ ਕਲਾਊਡ ਦੇ secrets manager ਰਾਹੀਂ ਪਾਸ ਕਰੋ।
Containers disposable ਹੁੰਦੇ ਹਨ; ਤੁਹਾਡਾ ਡੇਟਾ ਨਹੀਂ। ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਜੋ restart ਤੋਂ ਬਾਅਦ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ volumes ਵਰਤੋ:
ਕਲਾਊਡ ਡਿਪਲੌਯਮੈਂਟ ਵਿੱਚ, ਸਮਾਨ-ਅਰਥ managed storage ਹੁੰਦੀ ਹੈ (managed databases, network disks, object storage)। ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ: containers ਐਪ ਚਲਾਉਂਦੇ ਹਨ; persistent storage state ਨੂੰ ਰੱਖਦੀ ਹੈ।
ਇੱਕ ਸਿਹਤਮੰਦ Docker deployment workflow ਜ਼ਿਆਦਾਤਰ ਸਧਾਰਣ ਹੁੰਦੀ ਹੈ: ਇਕ ਵਾਰੀ image ਬਣਾਓ, ਫਿਰ ਓਹੀ image ਹਰ ਜਗ੍ਹਾ ਚਲਾਓ। ਫਾਇਲਾਂ ਨੂੰ servers 'ਤੇ copy ਕਰਨ ਜਾਂ installers ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਜਗ੍ਹਾ, deployment ਇੱਕ repeatable routine ਬਣ ਜਾਂਦਾ ਹੈ: image pull ਕਰੋ, container run ਕਰੋ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇਹ pipeline follow ਕਰਦੀਆਂ ਹਨ:
myapp:1.8.3).ਇਹ ਆਖਰੀ ਕਦਮ Docker ਨੂੰ "boring" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ—ਅਚਛੀ ਤਰ੍ਹਾਂ:
# build locally or in CI
docker build -t registry.example.com/myapp:1.8.3 .
docker push registry.example.com/myapp:1.8.3
# on the server / cloud runner
docker pull registry.example.com/myapp:1.8.3
docker run -d --name myapp -p 80:8080 registry.example.com/myapp:1.8.3
Dockerized apps ਨੂੰ ਕਲਾਊਡ ਵਿੱਚ ਚਲਾਉਣ ਦੇ ਦੋ ਆਮ ਤਰੀਕੇ ਹਨ:
ਰਿਲੀਜ਼ਾਂ ਦੌਰਾਨ outage ਘਟਾਉਣ ਲਈ, production deployments ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ building blocks ਵਰਤਦੇ ਹਨ:
Registry ਸਿਰਫ਼ ਸਟੋਰੇਜ ਨਹੀਂ—ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ environments ਨੂੰ consistent ਰੱਖਦੇ ਹੋ। ਇੱਕ ਆਮ ਅਭਿਆਸ ਇਹ ਹੈ ਕਿ ਉਹੀ image dev → staging → prod ਵੱਲ promote ਕੀਤੀ ਜਾਵੇ (ਅਕਸਰ re-tag ਕੀਤੀ ਜਾਂਦੀ ਹੈ), ਬਜਾਏ ਹਰ ਵਾਰ rebuild ਕਰਨ ਦੇ। ਇਸ ਤਰ੍ਹਾਂ production ਉਹੀ artifact ਚਲਾਉਂਦੀ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕੀਤਾ ਸੀ, ਜੋ "staging ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਸੀ" ਵਾਲੀਆਂ ਹੈਰਾਨੀਆਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
CI/CD (Continuous Integration ਅਤੇ Continuous Delivery) ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਸਾਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰਨ ਲਈ ਇੱਕ assembly line ਹੈ। Docker ਇਹ assembly line ਨੂੰ ਜ਼ਿਆਦਾ predictable ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕਦਮ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਵਾਤਾਵਰਣ 'ਤੇ ਚੱਲਦਾ ਹੈ।
Docker-friendly pipeline ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਸਟੇਜਾਂ ਵਿੱਚ ਹੁੰਦੀ ਹੈ:
myapp:1.8.3).ਇਹ flow non-technical stakeholders ਨੂੰ ਸਮਝਾਉਣਾ ਵੀ ਆਸਾਨ ਹੈ: "ਅਸੀਂ ਇੱਕ ਸੀਲ ਕੀਤਾ ਡੱਬਾ ਬਣਾਉਂਦੇ ਹਾਂ, ਡੱਬੇ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ, ਫਿਰ ਉਹੀ ਡੱਬਾ ਹਰ environment ਨੂੰ ਭੇਜਦੇ ਹਾਂ।"
ਟੈਸਟ ਅਕਸਰ ਲੋਕਲ 'ਤੇ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ ਪਰ production ਵਿੱਚ fail ਕਰ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ runtimes mismatched, system libraries ਗੰਵਾਂ ਜਾਂ environment variables ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। containers ਵਿੱਚ tests ਚਲਾਉਣ ਨਾਲ ਇਹ ਗੈਪ ਘੱਟ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਡੇ CI runner ਨੂੰ ਇੱਕ barabar tuned machine ਦੀ ਲੋੜ ਨਹੀਂ—ਸਿਰਫ Docker ਚਾਹੀਦਾ ਹੈ।
Docker "promote, don’t rebuild" ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ। ਬਦਲੇ ਵਿੱਚ rebuild ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ:
myapp:1.8.3 ਇਕ ਵਾਰੀ build ਅਤੇ test ਕਰੋ।ਸਿਰਫ਼ configuration environments ਵਿੱਚ ਵੱਖਰੀ ਰਹਿੰਦੀ ਹੈ (URLs ਜਾਂ credentials ਵਰਗੀਆਂ), ਨਾ ਕਿ application artifact। ਇਸ ਨਾਲ release-day uncertainty ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ rollbacks ਸਿੱਧੇ ਹੁੰਦੇ ਹਨ: ਪਿਛਲਾ image tag ਮੁੜ deploy ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਰਹੇ ਹੋ ਅਤੇ Docker ਦੇ ਫਾਇਦਿਆਂ ਨੂੰ ਮਨਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਦਿਨਾਂ ਦਾ scaffold ਬਣਾਉਣ ਲਈ ਸਮਾਂ ਗਵਾਉਣ ਦੇ, Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਇਹ ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਤੋਂ production-shaped ਐਪ ਬਣਾਉਣ ਅਤੇ ਉਸਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ containerize ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਣ ਲਈ, ਟੀਮਾਂ ਅਕਸਰ Koder.ai ਇਸ ਲਈ ਵਰਤਦੀਆਂ ਹਨ:
docker-compose.yml ਸ਼ੁਰੂ ਵਿੱਚ ਜੋੜਨ ਲਈ (ਤਾਂ ਜੋ dev ਅਤੇ prod ਬਿਹਿਵਿਯਰ aligned ਰਹੇ),ਮੁੱਖ ਫ਼ਾਇਦਾ ਇਹ ਹੈ ਕਿ Docker deployment primitive ਬਣੀ ਰਹਿੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ Koder.ai ਵਿਚਾਰ ਤੋਂ container-ready codebase ਤੱਕ ਦਾ ਰਾਸ্তা ਤੇਜ਼ ਕਰਦਾ ਹੈ।
Docker ਇੱਕ ਸੇਵਾ ਨੂੰ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਪੈਕੇਜ ਅਤੇ ਚਲਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਸੇਵਾਵਾਂ, ਹਰ ਸੇਵਾ ਦੀਆਂ ਕਈ ਨਕਲਾਂ, ਅਤੇ ਕਈ ਸਰਵਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਐਸੇ ਸਿਸਟਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਹਰ ਚੀਜ਼ ਨੂੰ coordinate ਕਰੇ। ਇਹ orchestration ਹੈ: ਉਹ software ਨਿਰਣਯ ਕਰਦਾ ਹੈ ਕਿ containers ਕਿੱਥੇ ਚੱਲਣ, ਉਹਨਾਂ ਨੂੰ healthy ਰੱਖਣਾ, ਅਤੇ ਮੰਗ ਦੇ ਅਨੁਸਾਰ capacity adjust ਕਰਨਾ।
ਸਿਰਫ਼ ਕੁਝ containers ਹੋਣ ਤਕ ਤੁਸੀਂ manually ਉਹਨਾਂ ਨੂੰ start ਅਤੇ restart ਕਰ ਸਕਦੇ ਹੋ। ਵੱਡੇ scale 'ਤੇ ਇਹ ਤਰੱਕੀ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਹੁੰਦੀ ਹੈ:
Kubernetes (ਅਕਸਰ "K8s") ਸਭ ਤੋਂ ਆਮ orchestrator ਹੈ। ਇੱਕ ਸਧਾਰਣ ਮਨੋ-ਮਾਡਲ:
Kubernetes containers build ਨਹੀਂ ਕਰਦਾ; ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਹੂੰ ਵੀ Docker image build ਕਰਦੇ ਹੋ, registry ਵਿੱਚ push ਕਰਦੇ ਹੋ, ਫਿਰ Kubernetes nodes 'ਤੇ ਉਹ image pull ਕਰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ containers start ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ image ਹਰ ਜਗ੍ਹਾ ਵਰਤੋਂ ਲਈ portable ਅਤੇ versioned artifact ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਰਵਰ 'ਤੇ ਕੁਝ ਸੇਵਾਵਾਂ ਨਾਲ ਹੋ, ਤਾਂ Docker Compose ਕਾਫੀ ਹੋ ਸਕਦਾ ਹੈ। Orchestration ਕੀਮਤ ਵਾਪਸ ਦੇਣੀ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ high availability, frequent deployments, auto-scaling, ਜਾਂ capacity ਅਤੇ resilience ਲਈ multiple servers ਦੀ ਲੋੜ ਹੋਵੇ।
Containers ਆਪਣੀ ਆਪ ਵਿੱਚ ਐਪ ਨੂੰ secure ਨਹੀ ਬਣਾਉਂਦੇ—ਪਰ ਇਹ ਉਹ ਸੁਰੱਖਿਆ ਕੰਮ ਜੋ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, automate ਅਤੇ standardize ਕਰਨਾ ਆਸਾਨ ਕਰ ਦਿੰਦੇ ਹਨ। ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ Docker ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ, repeatable ਨੁਕਤੇ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ auditors ਅਤੇ security ਟੀਮਾਂ ਲਈ ਕੰਟਰੋਲ ਜੋੜ ਸਕਦੇ ਹੋ।
ਇੱਕ container image ਤੁਹਾਡੀ ਐਪ ਅਤੇ ਇਸਦੇ dependencies ਦਾ ਬੰਡਲ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ vulnerabilities ਅਕਸਰ base images ਜਾਂ system packages ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖੇ। Image scanning deploy ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਜਾਣੇ-ਪਛਾਣੇ CVEs ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ।
ਇਸਨੂੰ pipeline ਵਿੱਚ ਇੱਕ gate ਬਣਾਓ: ਜੇ critical vulnerability ਮਿਲੇ, build fail ਕਰੋ ਅਤੇ patched base image ਨਾਲ rebuild ਕਰੋ। scan ਨਤੀਜੇ artifacts ਵਜੋਂ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ compliance reviews ਲਈ ਦਿਖਾ ਸਕੋ ਕਿ ਤੁਸੀਂ ਕੀ ship ਕੀਤਾ।
ਜੱਦੋਂ ਸੰਭਵ ਹੋ, non-root user ਵਜੋਂ ਚਲਾਓ। ਕਈ attacks root access ਦਾ ਫਾਇਦਾ ਲੈ ਕੇ container ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਜਾਂ filesystem ਨੂੰ ਤਬਾਹ ਕਰਦੇ ਹਨ।
ਇਸ ਦੇ ਨਾਲ-read-only filesystem ਵੀ ਸੋਚੋ ਅਤੇ ਸਿਰਫ਼ ਵਿਸ਼ੇਸ਼ writable paths mount ਕਰੋ (logs ਜਾਂ uploads ਲਈ)। ਇਹ ਘਟਾਉਂਦਾ ਹੈ ਕਿ ਜੇ attacker ਦਾਖਲ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਹ ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ।
ਕਦੇ ਵੀ API keys, passwords, ਜਾਂ private certificates Docker image ਵਿੱਚ copy ਨਾ ਕਰੋ ਜਾਂ Git ਵਿੱਚ commit ਨਾ ਕਰੋ। images cache, share ਅਤੇ registries 'ਤੇ push ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ—secrets ਆਮ ਤੌਰ 'ਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ leak ਹੋ ਸਕਦੇ ਹਨ।
ਇਸ ਦੀ ਥਾਂ, runtime 'ਤੇ secrets inject ਕਰੋ ਤੁਹਾਡੇ platform ਦੇ secret store (ਉਦਾਹਰਣ Kubernetes Secrets ਜਾਂ cloud provider ਦਾ secrets manager) ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਅਤੇ access ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੋੜ ਹੈ।
Traditional servers ਦੇ ਬਰਛਲੇ, containers ਆਪ-ਚਲਾਕੀ ਤਰੀਕੇ ਨਾਲ patch ਨਹੀਂ ਹੁੰਦੇ। ਸਾਹਮਣੇ ਰੀਤੀ ਇਹ ਹੈ: updated dependencies ਨਾਲ image rebuild ਕਰੋ, ਫਿਰ redeploy ਕਰੋ।
ਇੱਕ cadence (ਹਫਤਾਵਾਰੀ ਜਾਂ ਮਹੀਨਾਵਾਰੀ) ਸੈੱਟ ਕਰੋ rebuild ਕਰਨ ਲਈ ਚਾਹੇ ਤੁਹਾਡੇ ਕੋਡ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਾ ਹੋਵੇ, ਅਤੇ ਜਦੋਂ high-severity CVEs ਤੁਹਾਡੇ base image ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਤਾਂ ਤੁਰੰਤ rebuild ਕਰੋ। ਇਹ ਅਭ્યાસ ਤੁਹਾਡੇ deployments ਨੂੰ audit ਕਰਨ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਜੋਖਮ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਅਜੇ ਵੀ ਉਹ ਟੀਮਾਂ ਜੋ "Docker ਵਰਤਦੀਆਂ" ਹਨ, ਅਣਕਈ ਆਦਤਾਂ ਦੇ ਕਾਰਨ ਅਣਭਰੋਸੇਯੋਗ ਕਲਾਊਡ deployments ਭੇਜ ਸਕਦੀਆਂ ਹਨ। ਇੱਥੇ ਉਹ ਗਲਤੀਆਂ ਹਨ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਦਰਦ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ—ਅਤੇ ਅਮਲਯੋਗ ਤਰੀਕੇ ਉਹਨਾਂ ਤੋਂ بچਣ ਦੇ।
Aam anti-pattern ਹੈ "server ਵਿੱਚ SSH ਕਰਕੇ ਕੁਝ tweak ਕਰਨਾ," ਜਾਂ ਚੱਲ ਰਹੇ container ਵਿੱਚ exec ਕਰਕੇ hot-fix ਕਰਨਾ। ਇਹ ਇੱਕ ਵਾਰੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ fail ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਵੀ exact state recreate ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਇਸ ਦੀ ਥਾਂ, containers ਨੂੰ cattle ਵਾਂਗ treat ਕਰੋ: disposable ਅਤੇ replaceable। ਹਰ ਬਦਲਾਅ image build ਅਤੇ deployment pipeline ਰਾਹੀਂ ਕਰੋ। ਜੇ debug ਕਰਨਾ ਹੈ, temporary environment ਵਿੱਚ ਕਰੋ ਅਤੇ ਫਿਰ fix ਨੂੰ Dockerfile, config, ਜਾਂ infrastructure settings ਵਿੱਚ codify ਕਰੋ।
ਬਹੁਤ ਵੱਡੇ images CI/CD ਨੂੰ slow ਕਰਦੇ ਹਨ, storage costs ਵਧਾਉਂਦੇ ਹਨ, ਅਤੇ security surface area ਨੂੰ ਵੱਡਾ ਕਰਦੇ ਹਨ।
ਇਸ ਤੋਂ ਬਚਣ ਲਈ Dockerfile ਦੀ ਰਚਨਾ કੱੜੀ ਰੱਖੋ:
.dockerignore ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ node_modules, build artifacts, ਜਾਂ ਲੋਕਲ secrets ship ਨਾ ਹੋਣ।ਲੱਛਣ ਇਹ ਹੈ ਕਿ build repeatable ਅਤੇ ਤੇਜ਼ ਹੋਵੇ—even ਇੱਕ clean machine 'ਤੇ।
Containers ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਕੀ ਕਰ ਰਿਹਾ ਹੈ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੇ। ਬਿਨਾਂ logs, metrics, ਅਤੇ traces ਦੇ, ਤੁਸੀਂ ਸਿਰਫ਼ ਉਪਭੋਗਤਿਆਂ ਦੀ ਸ਼ਿਕਾਇਤ ਤੋਂ ਬਾਅਦ ਹੀ ਮੁੱਦੇ ਨੂੰ ਮਹਿਸੂਸ ਕਰੋਂਗੇ।
ਕਮ-ਸੇ-ਕਮ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਐਪ logs stdout/stderr 'ਤੇ ਲਿਖਦੀ ਹੈ (local files 'ਤੇ ਨਹੀਂ), ਬੁਨਿਆਦੀ health endpoints ਹਨ, ਅਤੇ ਕੁਝ ਮੁੱਖ ਮੈਟਰਿਕਸ (error rate, latency, queue depth) emit ਹੁੰਦੇ ਹਨ। ਫਿਰ ਉਹਨਾਂ signals ਨੂੰ ਆਪਣੇ cloud stack ਦੇ monitoring ਨਾਲ ਜੋੜੋ।
Stateless containers replace ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ; stateful data ਨਹੀਂ। ਟੀਮਾਂ ਅਕਸਰ ਦੇਰ ਨਾਲ ਪਤਾ ਲਾਉਂਦੀਆਂ ਹਨ ਕਿ container ਵਿੱਚ database ਚਲਾਉਣਾ "ਠੀਕ" ਸੀ ਜਦ ਤੱਕ restart ਨੇ data ਮਿਟਾ ਨਾ ਦਿੱਤਾ ਹੋਵੇ।
ਸ਼ੁਰੂ ਤੋਂ ਇਹ ਨਿਰਣਾ ਕਰੋ ਕਿ state ਕਿੱਥੇ ਰਹੇਗੀ:
Docker ਐਪਸ ਪੈਕੇਜ ਕਰਨ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹੈ—ਪਰ ਭਰੋਸੇਯੋਗਤਾ ਉਸ ਗੱਲ ਤੋਂ ਆਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹ containers ਕਿਵੇਂ ਬਣਾਉਂਦੇ, ਨਿਗਰਾਨੀ ਕਰਦੇ, ਅਤੇ persistent data ਨਾਲ ਜੋੜਦੇ ਹੋ, ਇਸ ਬਾਰੇ ਸੋਚ ਸਮਝ ਕੇ ਕੰਮ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Docker ਵਿੱਚ ਨਵੇਂ ਹੋ, ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਅਸਲ ਸੇਵਾ ਨੂੰ end-to-end containerize ਕਰਨਾ ਹੈ: build, lokaal ਚਲਾਓ, registry 'ਤੇ push ਕਰੋ, ਅਤੇ deploy ਕਰੋ। ਇਹ ਚੈਕਲਿਸਟ ਦਾਇਰਾ ਛੋਟਾ ਰੱਖਣ ਅਤੇ ਨਤੀਜੇ ਉਪਯੋਗੀ ਬਣਾਉਣ ਲਈ ਹੈ।
ਪہਲੇ ਇੱਕ ਸੇਵਾ ਚੁਣੋ ਜੋ stateless ਹੋਵੇ (ਇੱਕ API, ਇੱਕ worker, ਜਾਂ ਸਰਲ web app)। ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਇਸਨੂੰ start ਕਰਨ ਲਈ ਕੀ-ਕੀ ਚਾਹੀਦਾ ਹੈ: ਜਿਹੜਾ ਪੋਰਟ ਇਹ ਸੁਣਦਾ ਹੈ, ਲੋੜੀਂਦੇ environment variables, ਅਤੇ ਕੋਈ ਬਾਹਰੀ ਨਿਰਭਰਤਾਵਾਂ (ਜਿਵੇਂ database ਜੋ ਤੁਸੀਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਚਲਾ ਸਕਦੇ ਹੋ)।
ਲਕਸ਼ ਨਿਰਧਾਰਿਤ ਰੱਖੋ: "ਮੈਂ ਇੱਕੋ image ਨਾਲ ਲੋਕਲ ਅਤੇ ਕਲਾਊਡ ਵਿੱਚ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਐਪ ਚਲਾ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।"
ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ Dockerfile ਲਿਖੋ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਵਿਸ਼ਵਾਸਯੋਗ ਤਰੀਕੇ ਨਾਲ build ਅਤੇ run ਕਰ ਸਕੇ। ਪਸੰਦ ਕਰੋ:
ਫਿਰ ਲੋਕਲ development ਲਈ docker-compose.yml ਜੋੜੋ ਜੋ environment variables ਅਤੇ dependencies (ਜਿਵੇਂ database) ਨੂੰ wire ਕਰੇ ਬਿਨਾਂ ਤੁਹਾਡੇ ਲੈਪਟੌਪ 'ਤੇ ਕੁਝ install ਕੀਤੇ ਬਿਨਾਂ।
ਜੇ ਤੁਸੀਂ ਚਾਹੋ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਡੂੰਘਾ ਲੋਕਲ ਸੈਟਅਪ ਕਰੋ—ਪਹਿਲਾਂ ਸਧਾਰਨ ਰੱਖੋ।
ਫੈਸਲਾ ਕਰੋ ਕਿ images ਕਿੱਥੇ ਰਹਿਣਗੇ (Docker Hub, GHCR, ECR, GCR, ਆਦਿ)। ਫਿਰ ਉਹ tags ਪਕੜੋ ਜੋ deployments ਨੂੰ predictable ਬਣਾਉਂਦੀਆਂ ਹਨ:
:dev ਲੋਕਲ ਟੈਸਟਿੰਗ ਲਈ (ਵਿਕਲਪਿਕ):git-sha (immutable, deployments ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ):v1.2.3 ਰਿਲੀਜ਼ ਲਈਉਤਪਾਦਨ ਲਈ :latest 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ।
CI ਸੈਟ ਕਰੋ ਤਾਂ ਕਿ main branch 'ਤੇ ਹਰ merge 'ਤੇ image build ਹੋਵੇ ਅਤੇ registry 'ਤੇ push ਕੀਤਾ ਜਾਵੇ। ਤੁਹਾਡੀ pipeline ਨੂੰ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
ਇਹ ਕੰਮ ਕਰਨ ਲੱਗਣ 'ਤੇ, ਤੁਸੀਂ publish ਕੀਤੀ image ਨੂੰ cloud deploy step ਨਾਲ ਜੋੜਨ ਲਈ ਤਿਆਰ ਹੋ ਅਤੇ ਉਥੋਂ ਤੋਂ iteration ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ।
Docker "ਮੇਰੇ ਕੰਪਿਊਟਰ ਤੇ ਚੱਲਦਾ ਹੈ" ਸਮੱਸਿਆਵਾਂ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇਸਦੇ ਰਨਟਾਈਮ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਨਾਲ ਇੱਕ ਚੀਜ਼ (image) ਵਿੱਚ ਪੈਕ ਕਰਦਾ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਇਹੀ image ਲੋਕਲ, CI ਅਤੇ ਕਲਾਊਡ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ, ਇਸ ਲਈ OS ਪੈਕੇਜ, ਭਾਸ਼ਾ ਵਰਜ਼ਨ ਅਤੇ ਇੰਸਟਾਲ ਕੀਤੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਫਰਕ ਬੋਹਤ ਘੱਟ ਰਹਿੰਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇਕ ਵਾਰੀ image ਬਣਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਣ: myapp:1.8.3) ਅਤੇ ਵੱਖ-ਵੱਖ ਮਾਹੌਲਾਂ 'ਚ ਉਹਨਾਂ ਤੋਂ ਕਈ containers ਚਲਾਉਂਦੇ ਹੋ।
VM ਇੱਕ ਪੂਰਾ guest operating system ਸਮੇਤ ਆਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਭਾਰੀ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸਲੋਅ ਸਟਾਰਟ ਹੁੰਦੀ ਹੈ। ਇੱਕ container ਹੋਸਟ ਦੇ kernel ਨੂੰ ਸਾਂਝਾ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਐਪ ਲਈ ਲੋੜੀਦਾ ਰਨਟਾਈਮ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਆਮ ਤੌਰ 'ਤੇ:
Registry ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ images ਸੰਭਾਲੀ ਜਾਂਦੀਆਂ ਅਤੇ ਵਰਜ਼ਨ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਹੋਰ ਮਸ਼ੀਨ ਉਹਨੂੰ pull ਕਰ ਸਕਣ।
ਆਮ ਵਰਕਫਲੋ:
docker build -t myapp:1.8.3 .docker push <registry>/myapp:1.8.3ਇਸ ਨਾਲ ਰੋਲਬੈਕ ਵੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਪਹਿਲਾ tag ਮੁੜ ਡਿਪਲੌਯ ਕਰੋ।
ਉਤਪਾਦਨ ਲਈ ਅਜਿਹੇ tags ਵਰਤੋ ਜੋ ਅਪਰਿਵਰਤਨਸ਼ੀਲ ਅਤੇ ਪਛਾਣਯੋਗ ਹੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਪਤਾ ਲਗਾ ਸਕੋ ਕਿ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ।
ਵਹਾਵਟੀ ਰੀਤੀਆਂ:
:1.8.3:<git-sha>:latest ਤੋਂ ਬਚੋ (ਇਹ ਅਸਪਸ਼ਟ ਹੈ)ਇਸ ਨਾਲ ਸਾਫ਼ ਰੋਲਬੈਕ ਅਤੇ ਆਡਿਟ ਹੋ ਸਕਦਾ ਹੈ।
ਵਾਤਾਵਰਣ-ਖਾਸ ਕੰਫਿਗਰেশন ਨੂੰ image ਵਿੱਚ ਨਾ ਪਾਵੋ। Dockerfile ਵਿੱਚ API keys, ਪਾਸਵਰਡ ਜਾਂ ਪਰਾਈਵੇਟ ਸਰਟੀਫਿਕੇਟ ਨਾ ਰੱਖੋ।
ਇਸ ਦੀ ਥਾਂ:
.env ਫਾਇਲ Git 'ਚ commit ਨਾ ਕਰੋਇਸ ਨਾਲ images ਰੀਯੂਜ਼ੇਬਲ ਅਤੇ ਗੱਡਾ-ਲੀਕ ਘੱਟ ਰਹਿੰਦੀ ਹੈ।
Containers ਵੀ ਬਦਲਣਯੋਗ ਹੁੰਦੇ ਹਨ; ਉਹਨਾਂ ਦੀ ਫਾਇਲਸਿਸਟਮ restart ਜਾਂ redeploy 'ਤੇ ਬਦਲ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ:
Rule of thumb: ਐਪਸ containers ਵਿੱਚ ਚਲਾਓ, state purpose-built storage ਵਿੱਚ ਰੱਖੋ।
Compose lokaI dev ਜਾਂ ਇੱਕ single host ਲਈ ਵਧੀਆ ਹੈ:
db:5432)ਅਹਲੇ production ਲਈ ਜਿੱਥੇ multi-server, HA ਅਤੇ autoscaling ਲੋੜੀਏ ਹੋਣ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ orchestration (ਅਕਸਰ Kubernetes) ਸ਼ਾਮਲ ਕਰੋਗੇ।
ਸਾਰਥਕ pipeline ਹੈ build → test → publish → deploy:
“promote, don’t rebuild” ਨੂੰ ਤਰਜੀਹ ਦਿਓ (dev → staging → prod) ਤਾਂ ਕਿ artifact ਇੱਕੋ ਰਹੇ।
ਸਧਾਰਨ ਕਾਰਣ ਜੋ locality ਵਿੱਚ ਚਲਦਾ ਹੈ ਪਰ ਕਲਾਊਡ ਵਿੱਚ fail ਹੁੰਦਾ:
-p 80:8080).ਡਿਬੱਗ ਕਰਨ ਲਈ, production tag ਨੂੰ ਲੋਕਲ 'ਤੇ ਚਲਾਕੇ ਪਹਿਲਾਂ config ਦੀ ਤੁਲਨਾ ਕਰੋ।