Code10x

Ek containerization platform hai — application aur uski saari dependencies ko ek isolated "container" mein pack kar deta hai, taaki wo kisi bhi machine par consistently chale.

VM poora guest OS virtualize karti hai (hypervisor ke saath, GBs mein size, minutes mein boot). Container host ke kernel ko share karta hai (MBs mein size, seconds mein start) — bahut lightweight hai.

Client (CLI), Daemon (dockerd — asli kaam karta hai), aur Registry (jahan images store hoti hain, jaise Docker Hub). Client REST API ke zariye Daemon se baat karta hai.

Poora daemon-to-container flow test karti hai — image local mein nahi hai to registry se pull karti hai, phir ek container banakar run karti hai jo ek message print karke exit ho jaata hai.

Kyunki container host machine ke hi OS kernel ko share karta hai, poora alag OS virtualize nahi karta — jaise VM hardware-level virtualization karti hai.

docker ps sirf currently RUNNING containers dikhata hai. docker ps -a saare containers dikhata hai — running aur stopped/exited dono.

Docker Desktop Mac/Windows ke liye ek GUI application hai jisme Docker Engine ek lightweight VM ke andar chalta hai. Linux par Docker Engine directly kernel par chalta hai, extra VM layer ki zaroorat nahi.

Docker daemon ke baare mein detailed info — containers count, images count, storage driver, kernel version, memory, CPUs waghera. Troubleshooting ke liye useful hai.

Docker 2013 mein launch hua tha aur software deploy karne ka tareeka hamesha ke liye badal diya — "works on my machine" problem ko solve karke industry standard ban gaya.

Image ek read-only template hai (jaise recipe). Container us image se bana hua running instance hai (jaise recipe se banayi gayi dish). Ek image se multiple containers ban sakte hain.

Har Dockerfile instruction (FROM, RUN, COPY) ek nayi read-only layer banata hai. Union filesystem saari layers ko ek single unified view mein merge karta hai.

Agar ek instruction aur uski previous layers same hain, to Docker us layer ko dobara build nahi karta, cache se reuse kar leta hai. Isliye rarely-changing instructions ko Dockerfile ke start mein rakhna best practice hai.

FROM instruction — ye base image define karti hai jiske upar poori image banegi. Bina base image ke koi bhi image build nahi ho sakti.

Image ko ek readable tag (naam:version) deta hai. Bina -t ke Docker ek random ID assign kar deta hai jise yaad rakhna mushkil hota hai.

Kyunki wo bahut chote hote hain (5-10MB vs 900MB+ full OS images ke muqable) — minimal Alpine Linux par based hain, ISSE image size aur attack surface dono kam ho jaate hain.

Ek image ki saari layers aur unka individual size — ye samajhne ke liye useful hai ki image ka size kahan se aa raha hai aur kaunsi layer optimize ki ja sakti hai.

Docker ka modern default builder hai jo parallel layer builds, better caching, aur build-time secrets (jo final image mein leak nahi hote) jaise advanced features provide karta hai.

Jab image ko poori tarah fresh build karna ho, bina kisi cached layer ke — usually debugging ke liye ya latest security patches guarantee karne ke liye.

Ye "docker create" (image se naya container banana) aur "docker start" (use start karna) ka shortcut hai — dono steps ek command mein combine ho jaate hain.

docker stop gracefully (SIGTERM bhejkar, phir timeout ke baad SIGKILL) container ko rokta hai. docker kill immediately SIGKILL bhejkar force stop karta hai — koi graceful shutdown time nahi milta.

Ye do flags ka combo hai — "-i" (interactive, STDIN khula rakhta hai) aur "-t" (pseudo-TTY allocate karta hai). Dono milkar ek usable terminal session dete hain.

Ek already-running container ke andar ek new process (usually shell) start karta hai — debugging ke liye sabse zyada use hone waali command hai. Sirf running containers par kaam karta hai.

Container ke STDOUT/STDERR output ko real-time mein stream karta hai — jaise "tail -f" — jab tak manually stop na kiya jaaye.

Container ki poori JSON configuration — IP address, mounted volumes, environment variables, network settings, restart policy waghera sab kuch.

Container ke exit hote hi use automatically remove kar deta hai — short-lived testing ya one-off commands ke liye useful hai taaki stopped containers ka dher jama na ho.

Container ka apna internal network namespace — HOST machine ko refer nahi karta. Host ko access karne ke liye "host.docker.internal" special DNS naam use hota hai.

Live resource usage — CPU percentage, memory usage/limit, network I/O, disk I/O — har running container ke liye real-time.

CMD poori tarah override ho sakta hai jab "docker run" ke saath extra command di jaaye. ENTRYPOINT override nahi hota (jab tak --entrypoint flag use na karo) — CLI par di gayi cheezein sirf arguments ki tarah ENTRYPOINT ko pass ho jaati hain.

Shell form ("CMD npm start") ek shell ke andar run hota hai, signals properly pass nahi hote. Exec form ("CMD ["npm", "start"]") directly process ki tarah run hota hai, signals (jaise SIGTERM) correctly pass hote hain.

Build tools (compiler, npm) sirf ek intermediate stage mein use hote hain aur final production image mein include nahi hote — isse final image size bahut chota ho jaata hai.

Multi-stage build mein pehle stage (naam "builder") se sirf zaroori output files ko current stage mein copy karta hai — poora build environment copy nahi hota.

Isme node_modules, .git, .env jaisi files list ki jaati hain jo build context mein daemon ko send hi nahi ki jaatin — isse build fast hota hai aur sensitive data image mein leak nahi hota.

ARG sirf build-time par available hota hai (runtime container mein nahi dikhta). ENV build aur runtime dono mein available rehta hai.

"cd" sirf usi RUN layer ke liye effective hota hai — agli layer mein phir se root directory mein wapas aa jaate ho. WORKDIR har agli instruction ke liye persist hota hai.

Dockerfile mein defined ARG values ko command line se override karta hai — ek hi Dockerfile se multiple versions banane ke liye useful hai.

Sirf documentation ke liye hai ki container kaunse port par listen karta hai — actual port publish karne ke liye runtime par -p flag zaroori hai.

Docker daemon ke managed storage area mein exist karne waala persistent storage — container ke lifecycle se independent, container delete hone ke baad bhi data safe rehta hai.

Volume Docker-managed storage hai (path Docker khud manage karta hai). Bind mount ek specific HOST machine path ko directly container mein mount karta hai — tum khud exact host path specify karte ho.

Kyunki bina volume ke, container restart ya remove hone par saara database data permanently kho jaata hai — volume data ko container ke bahar persist karta hai.

Data ko host machine ki memory (RAM) mein store karta hai, disk par kabhi write nahi hota. Container stop hote hi tmpfs ka saara data chala jaata hai — sensitive temporary data ke liye ideal.

Anonymous volumes ko Docker ek random hash naam deta hai, track karna mushkil hota hai. Named volumes easily identifiable aur reusable hote hain (jaise "-v mydata:/data").

Bind mounts — kyunki code ko host machine par edit karo aur changes instantly running container ke andar dikhne lagte hain, bina image rebuild kiye.

Kyunki wo portable hain (host filesystem structure ki chinta nahi), Docker ke backup/restore tools ke saath kaam karte hain, aur multiple storage drivers support karte hain.

Volume ya bind mount ko read-only banata hai — container us path par write nahi kar sakta, sirf read kar sakta hai.

Bridge (default, isolated private network), Host (container directly host ki network use karta hai, isolation khatam), aur None (koi networking hi nahi, poori tarah isolated).

Custom (user-defined) bridge networks mein built-in DNS resolution milta hai — containers naam se ek doosre ko resolve kar sakte hain. Default bridge par sirf IP se hi connect ho sakta hai.

Host machine ke ek specific port ko container ke andar ke ek port se map karta hai — jaise "-p 8080:80" host ke port 8080 ko container ke port 80 se connect kar deta hai.

"-p" specific port mapping deta hai (jo tum manually specify karo). "-P" Dockerfile mein EXPOSEd saari ports ko host ke random available ports par automatically map kar deta hai.

Kyunki same custom network par containers ek doosre se directly naam use karke baat kar sakte hain — port mapping sirf outside world (jaise browser) se access ke liye chahiye hoti hai.

Multiple Docker hosts (jaise Swarm cluster mein) ke containers ko ek doosre se talk karne deta hai jaise wo same machine par hon — multi-host orchestration ke liye zaroori hai.

Ek network ke andar ke saare connected containers, unke IPs, aur network ki configuration (subnet, gateway) — sab ek jagah dikhta hai.

"-p 53:53/udp" — "/udp" suffix zaroori hai, warna default mein TCP hi map hota hai.

Ek tool hai jisse multi-container applications ko ek single YAML file (docker-compose.yml) mein define kiya ja sakta hai — saari services (web, database, cache) ek hi jagah configure hoti hain.

Saari defined services ko correct order mein start karti hai, unka apna network banati hai, aur unhe ek doosre se automatically connect kar deti hai — sab kuch background (detached) mode mein.

services (har container ki definition), volumes (named volumes ki definition), aur networks (custom networks ki definition, agar default se alag chahiye).

Sirf start order control karta hai — ki container "started" ho chuka hai. Ye guarantee nahi deta ki database "ready" hai, application-level retry logic abhi bhi zaroori hoti hai.

down saare containers aur networks stop karke remove karta hai lekin volumes safe rehte hain. down -v volumes ko bhi delete kar deta hai — saara data permanently kho jaata hai.

Compose automatically same directory mein maujood .env file ko padh leta hai aur uski variables ko "${VARIABLE_NAME}" syntax se compose file ke andar use kiya ja sakta hai.

Compose single-host local development aur small deployments ke liye ideal hai. Kubernetes multi-host cluster orchestration, self-healing aur large-scale production workloads ke liye design kiya gaya hai.

Ek specific service ke logs ko real-time mein follow karta hai — poori stack ke logs ke bajay sirf us ek service par focus karne deta hai.

"image" ek existing pre-built image use karta hai (jaise registry se pull karke). "build" local Dockerfile se image build karta hai — development mein usually build, production mein usually pre-built image.

Sabse bada aur default public image registry hai — jab bhi ek image naam (jaise "nginx") ke saath docker pull/run kiya jaata hai, default rup se Docker Hub se hi image search hoti hai.

Official images Docker ki team ya trusted organizations maintain karti hain, regularly security patches milte hain. Community images koi bhi user upload kar sakta hai — quality aur security vary karti hai.

Image ko "username/repo-name:tag" format mein tag karna padta hai — Docker tabhi samajh paata hai ki image kahan aur kaunse account ke andar upload karni hai.

Ye sirf ek default tag naam hai, "naya version" ka matlab nahi. Production mein "latest" avoid karke exact version tags (jaise "1.2.0") use karna reliable hota hai.

MAJOR.MINOR.PATCH format follow hota hai (jaise 1.2.0) — MAJOR breaking changes, MINOR new features, PATCH bug fixes ko represent karta hai.

Companies apni proprietary/internal images ko public Docker Hub par expose nahi karna chahtin — private registry (self-hosted jaise Harbor, ya cloud-managed jaise AWS ECR) unhe secure rakhti hai.

Tag (jaise "latest") change ho sakta hai aur kisi bhi image version ko point kar sakta hai. Digest (SHA256 hash) hamesha ek exact immutable version ko point karta hai.

Anonymous (bina login) pulls par rate limit lagti hai (per 6 hours) — server load manage karne ke liye. Logged-in aur paid accounts ko zyada/unlimited limit milta hai.

"--platform" flag se specific architecture specify ki ja sakti hai — jaise "docker pull --platform linux/arm64" Mac M1/M2 chips ke liye.

Docker ka own built-in orchestration tool hai — multiple Docker hosts ko ek single virtual host ki tarah manage karne deta hai. Manager nodes scheduling decisions lete hain, worker nodes containers run karte hain.

Container ek single running instance hai. Service ek higher-level definition hai jo batati hai kaunsi image chalani hai aur kitne replicas chahiye — Swarm automatically unhe available workers par distribute karta hai.

Limits ek hard ceiling hain — container isse zyada use nahi kar sakta. Reservations ek guaranteed minimum hain jo scheduler ensure karta hai container ko mile hi mile.

Container apni memory limit cross kar chuka tha, isliye Linux kernel ke OOM (Out-Of-Memory) killer ne uske process ko kill kar diya.

Kyunki default rup se containers root user ke roop mein run hote hain — agar container compromise ho jaaye to attacker ke paas root-level access hoga. USER instruction se non-root user set karna security best practice hai.

Kyunki wo image layers mein permanently visible reh jaate hain — "docker history" se bhi dekhe ja sakte hain. Secrets ke liye dedicated secret management (jaise docker secrets) use karna chahiye.

Docker ko periodically check karne deta hai ki container ke andar ki app actually healthy hai ya nahi — na ki sirf "running", kyunki process running ho sakta hai lekin app khud hang ho sakti hai.

Container ko crash ya host reboot ke baad automatically restart karti hai, lekin agar tum manually stop karo to us decision ko respect karti hai (dobara restart nahi karti).

Kyunki isse Docker ki logging drivers (jaise json-file ya specialized log aggregators) logs ko easily collect kar sakte hain — files mein log karna Docker ke standard log collection ke saath integrate nahi hota.

Container se saari Linux capabilities hata deta hai (jaise raw sockets banana) — principle of least privilege follow karte huye, phir sirf zaroori capabilities (--cap-add se) wapas di jaati hain.

Taaki in-flight requests complete ho sakein, database connections gracefully close ho sakein, phir exit ho — warna "docker stop" force kill (SIGKILL) tak pahunch jaata hai aur data corrupt ho sakta hai.