arrow_backफ़ील्ड नोट्स पर वापस जाएँ
DEVOPS प्रकाशित 9 Aug 2026

Docker क्या है और developers को इसे क्यों सीखना चाहिए?

Developers के लिए Docker का व्यावहारिक विश्लेषण: containers बनाम VMs, मुख्य commands, Dockerfiles, और वास्तविक projects में इसे कैसे शुरू करें।

Docker job postings और setup guides में बार-बार सामने आता है, और अगर आपने कभी containers के साथ काम नहीं किया है तो यह एक दीवार जैसा लग सकता है जो आपको असली code लिखने से पहले पार करनी है। शब्दावली को समझ लेने के बाद यह उतना जटिल नहीं है।

एक container असल में क्या है

एक container आपके application को सभी चीजों के साथ पैकेज करता है जिनकी इसे चलने के लिए जरूरत है: code, runtime, system libraries, और config files। यह एक virtual machine नहीं है। एक VM एक पूरे operating system को virtualize करता है, kernel सहित, जिसका मतलब है कि एक को boot करने में एक मिनट लग सकता है और कुछ gigabytes RAM खा सकता है। एक container host machine के kernel को share करता है और सिर्फ process को isolate करता है, इसलिए यह एक सेकंड से भी कम समय में शुरू हो जाता है और आमतौर पर tens of megabytes के बजाय gigabytes का उपयोग करता है।

यह अंतर ही वह कारण है कि Docker ने local development और CI pipelines में इतनी तेजी से जगह बना ली। आप एक Postgres database, एक Redis cache, और अपने app server को एक laptop पर चला सकते हैं बिना किसी को अपने OS पर सीधे install किए।

मुख्य चीजें जो आपको जानने की जरूरत है

चार terms हैं जो cover करते हैं ज्यादातर चीजें जिनसे आप daily सामना करते हैं:

  • Image: एक Dockerfile से built read-only template। इसे एक filesystem का snapshot के रूप में सोचें साथ ही इसे कैसे चलाया जाए इसके बारे में metadata।
  • Container: एक image का running instance। आप containers को start, stop, और delete कर सकते हैं बिना उस image को छुए जिससे वह बना है।
  • Dockerfile: एक text file जिसमें एक image को build करने के लिए instructions हैं, line by line।
  • Registry: जहां images store किए जाते हैं और pull किए जाते हैं, सबसे आमतौर पर Docker Hub।

एक Node.js app के लिए minimal Dockerfile कुछ इस तरह दिखता है:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

इसे docker build -t my-app . से build करें और docker run -p 3000:3000 my-app से run करें। -p flag आपकी machine पर एक port को container के अंदर एक port से map करता है, जो कि यह है कि आप असल में app को अपने browser से कैसे reach करते हैं।

Commands जिन्हें आप लगातार use करेंगे

कुछ commands ज्यादातर daily work को cover करते हैं:

  • docker ps — running containers list करें
  • docker ps -a — सभी containers list करें, stopped वालों सहित
  • docker images — अपनी machine पर images list करें
  • docker logs <container> — एक running या crashed container से output check करें
  • docker exec -it <container> sh — एक running container के अंदर shell खोलें
  • docker rm / docker rmi — containers और images को clean up करें जिनकी अब जरूरत नहीं है

यह आखिरी pair लोग जितना सोचते हैं उससे ज्यादा मायने रखता है। Docker खुशी से disk space को old images और stopped containers में गायब होने देता है। docker system prune को occasionally चलाने से काफी disk space वापस मिल जाता है।

क्यों docker-compose workflow को बदल देता है

ज्यादातर real projects को एक से ज्यादा containers की जरूरत होती है: एक app server, एक database, शायद एक cache। हर एक के लिए docker run commands लिखना जल्दी ही boring हो जाता है। docker-compose.yml आपको पूरे stack को एक file में define करने देता है:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: devpassword
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

docker compose up चलाएं और दोनों services एक साथ start हो जाती हैं, networked तरीके से ताकि web service name से db को reach कर सके। यह setup है जो आप लगभग हर open-source repo के README में देखेंगे, और इसे समझना मतलब है आप किसी project को clone कर सकते हैं और इसे manually Postgres, Redis, और जो कुछ और app को जरूरत है को install करने के बजाय मिनटों में running करवा सकते हैं।

जहां लोग शुरुआत में stuck हो जाते हैं

Volumes लगभग सभी को पहले confuse करते हैं। एक volume के बिना, कुछ भी जो एक container के अंदर लिखा जाता है container को remove करने पर गायब हो जाता है, जो databases के लिए एक समस्या है। उपर दिए गए compose file में volumes section एक named volume को container के अंदर एक path से map करता है ताकि data restarts के बाद भी survive रहे।

एक और common mistake है node_modules या .git को image में copy करना क्योंकि कोई .dockerignore file नहीं है। एक add करें एक .gitignore की तरह:

node_modules
.git
.env

यह builds को faster और images को smaller रखता है, जो मायने रखता है एक बार जब आप images को registry पर push कर रहे हों या Kubernetes को deploy कर रहे हों।

Basics के बाद कहां जाएं

एक बार building और running containers normal feel करने लगे, अगली useful skills हैं smaller production images के लिए multi-stage builds, Docker networking modes को समझना, और जब कुछ सही से connect नहीं हो रहा हो तब docker inspect output को पढ़ना। कुछ भी hard नहीं है, बस पहली बार unfamiliar है।

Real applications को containerize करने और उन्हें cloud deployment pipelines से connect करने के बारे में अधिक जानकारी के लिए, Korra Studio पर DevOps और Cloud segments check करें।

AI सहायता से लिखा गया, माइकल पिल्च (CISSP), Korra Studio द्वारा समीक्षित और प्रकाशित।

आगे बढ़ने के लिए तैयार?

यह Korra Studio के ज्ञान आधार से एक नोट है — प्लेटफ़ॉर्म हर विषय को 1-टू-1 मेंटरिंग के साथ जोड़ता है।

मुफ़्त शुरू करेंarrow_forward