Docker images और containers में क्या अंतर है?

Question

Accepted Answer

एक Docker **image** एक read-only **template** है (dependencies के साथ पैक किया गया एक application); एक **container** एक image का **running instance** है। यह संबंध एक class और एक object जैसा है: एक image कई containers को जन्म दे सकती है। ## image बनाम container ```text IMAGE → a read-only TEMPLATE: the app + dependencies + config, built in layers (like a blueprint/class; stored, shared, versioned) CONTAINER → a RUNNING INSTANCE of an image (with a writable layer on top) (like an object created from a class; has runtime state) One IMAGE → many CONTAINERS (run the same image multiple times) ``` ## images के साथ काम करना ```bash docker build -t myapp:1.0 . # BUILD an image from a Dockerfile docker images # list local images docker pull nginx # download an image from a registry docker push myapp:1.0 # upload an image to a registry docker rmi myapp:1.0 # remove an image ``` Images को build किया जाता है (एक Dockerfile से), स्थानीय रूप से या registries में संग्रहीत किया जाता है, tags के साथ versioned किया जाता है (`myapp:1.0`), और साझा किया जाता है। ## containers के साथ काम करना ```bash docker run -d -p 80:80 nginx # RUN a container from an image (-d = background) docker ps # list RUNNING containers docker ps -a # list all (including stopped) docker stop # stop a container docker start # start a stopped container docker rm # remove a container docker logs # view a container's logs docker exec -it bash # run a command inside a running container ``` Containers को images से बनाया जाता है, उनका एक lifecycle होता है (run, stop, start, remove), और आप logs का निरीक्षण कर सकते हैं या उनमें exec कर सकते हैं। ## layered संबंध ```text → Images are built in LAYERS (each Dockerfile instruction adds a layer, cached/shared) → A container = the image's read-only layers + a thin WRITABLE layer on top → Changes in a running container go to its writable layer (lost when removed, unless persisted via volumes) — the underlying image is unchanged ``` ## यह क्यों महत्वपूर्ण है images और containers के बीच के भेद को समझना Docker के साथ काम करने के लिए मौलिक है, इसलिए यह आवश्यक, अवश्य-जानने योग्य ज्ञान है। संबंध — एक **image** एक read-only **template** है (dependencies के साथ पैक किया गया application, एक blueprint या class की तरह) जबकि एक **container** उस image का एक **running instance** है (एक class से बनाए गए object की तरह, runtime state के साथ) — Docker का मूल वैचारिक मॉडल है, और दोनों को भ्रमित करने से इस बारे में भ्रम होता है कि Docker कैसे काम करता है। यह समझना कि **एक image कई containers को जन्म दे सकती है** (एक ही image को कई बार चलाना) इस बात के लिए मुख्य है कि Docker scaling और consistency को कैसे सक्षम करता है। व्यावहारिक संचालन जानना — **images** को build करना, list करना, pull करना, push करना, और version करना (`myapp:1.0` जैसे tags के साथ), और **containers** को run करना, stop करना, निरीक्षण करना (logs), और exec करना (उनके lifecycle का प्रबंधन) — Docker के उपयोग के लिए रोज़मर्रा का व्यावहारिक ज्ञान है। **layered संबंध** को समझना (images cached, shareable layers में बनाई जाती हैं; एक container image की read-only layers के साथ एक पतली writable layer है जहाँ runtime परिवर्तन जाते हैं, जो volumes के माध्यम से persist न किए जाने पर removal पर खो जाते हैं) Docker की efficiency (layer sharing/caching) और एक महत्वपूर्ण gotcha (volumes के बिना container परिवर्तन क्षणिक हैं) दोनों को समझाता है। चूँकि image/container भेद Docker के लिए मूलभूत मानसिक मॉडल है, और चूँकि इसे समझना (और संबंधित संचालन और layered संरचना) Docker workloads को सही ढंग से build करने, run करने और प्रबंधित करने के लिए आवश्यक है, images और containers के बीच के अंतर को समझना आवश्यक, मौलिक Docker ज्ञान है — मूल अवधारणा जिस पर Docker में बाकी सब कुछ निर्मित होता है, और एक भेद जिसे हर Docker उपयोगकर्ता को स्पष्ट रूप से समझना चाहिए।