Docker کیا ہے اور ڈویلپرز کو اسے سیکھنا کیوں چاہیے؟

Docker مسلسل job postings اور setup guides میں آ رہا ہے، اور اگر آپ نے کبھی containers کے ساتھ کام نہیں کیا تو یہ ایک دیوار کی طرح محسوس ہو سکتا ہے جو آپ کو حقیقی code لکھنے سے پہلے پار کرنی ہوگی۔ یہ اتنا پیچیدہ نہیں ہے جب تک آپ لفظیات سے آگے نکل جائیں۔

ایک container اصل میں کیا ہے

ایک container آپ کی application کو اس کے ساتھ package کرتا ہے جو اسے چلانے کے لیے درکار ہے: 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 ہیں جو اس کا احاطہ کرتے ہیں جو آپ روز مرہ کے کام میں سے بیشتر سے واسطہ رکھیں گے:

• Image: ایک read-only template جو Dockerfile سے بنایا جاتا ہے۔ اسے filesystem کے snapshot کے طور پر سوچیں اور کچھ metadata کے ساتھ کہ اسے کیسے چلایا جائے۔
• Container: ایک image کا running instance۔ آپ containers کو start، stop، اور delete کر سکتے ہیں بغیر اس image کو چھوئے جس سے یہ آیا ہے۔
• Dockerfile: ایک text file جس میں ایک image بنانے کی ہدایات ہیں، لائن در لائن۔
• 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 کے ساتھ چلائیں۔ -p flag آپ کے machine پر ایک port کو container کے اندر ایک port سے map کرتا ہے، یہ وہ طریقہ ہے جس سے آپ اصل میں اپنے browser سے app تک پہنچتے ہیں۔

Commands جو آپ مسلسل استعمال کریں گے

کچھ commands روز مرہ کے کام کا بیشتر احاطہ کرتے ہیں:

• docker ps — running containers کی فہرست
• docker ps -a — تمام containers کی فہرست، stopped والے سمیت
• docker images — آپ کے machine پر images کی فہرست
• docker logs <container> — ایک running یا crashed container سے output دیکھیں
• docker exec -it <container> sh — ایک running container کے اندر shell کھولیں
• docker rm / docker rmi — اان containers اور images کو صاف کریں جن کی آپ کو ضرورت نہیں ہے

یہ آخری جوڑی اس سے زیادہ اہم ہے جتنا لوگ سوچتے ہیں۔ Docker خوشی سے disk space کو پرانے images اور stopped containers میں غائب ہونے دے گا۔ docker system prune کو کبھی کبھار چلانے سے حیرت انگیز مقدار میں space خالی ہوتی ہے۔

docker-compose workflow کو کیسے تبدیل کرتا ہے

زیادہ تر حقیقی projects کو ایک سے زیادہ containers کی ضرورت ہے: ایک app server، ایک database، شاید ایک cache۔ ہر ایک کے لیے docker run commands لکھنا جلد بوریت ہو جاتی ہے۔ 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 ایک ساتھ شروع ہوں، networked تاکہ web db کو service name سے پہنچ سکے۔ یہ وہ setup ہے جو آپ تقریباً ہر open-source repo کے README میں دیکھیں گے، اور اسے سمجھنا مطلب ہے کہ آپ ایک project کو clone کر سکتے ہیں اور اسے منٹوں میں چلا سکتے ہیں بجائے Postgres، Redis، اور جو کچھ اور app کو ضرورت ہے اسے دستی طور پر install کرنے کے۔

جہاں لوگ شروع میں پھنستے ہیں

Volumes تقریباً سب کو شروع میں الجھاتے ہیں۔ ایک volume کے بغیر، کوئی بھی چیز جو ایک container کے اندر لکھی جائے وہ container کو ہٹانے پر غائب ہو جاتی ہے، جو databases کے لیے مسئلہ ہے۔ compose file میں volumes section ایک named volume کو container کے اندر ایک path سے map کرتا ہے تاکہ data restarts کو survive کرے۔

ایک اور عام غلطی node_modules یا .git کو image میں copy کرنا ہے کیونکہ کوئی .dockerignore file نہیں ہے۔ ایک شامل کریں جیسے .gitignore:

node_modules
.git
.env

یہ builds کو تیز رکھتا ہے اور images کو چھوٹا رکھتا ہے، جو اہم ہے جب آپ images کو registry میں push کر رہے ہوں یا Kubernetes پر deploy کر رہے ہوں۔

بنیادی چیزوں کے بعد کہاں جائیں

جب containers بنانا اور چلانا معمول سا لگے، اگلی مفید skills چھوٹے production images کے لیے multi-stage builds، Docker networking modes کو سمجھنا، اور اس وقت docker inspect output کو پڑھنا ہے جب کچھ connect نہ ہو رہا ہو۔ کوئی بھی مشکل نہیں ہے، یہ صرف پہلی بار غیر مانوس ہے۔

حقیقی applications کو containerize کرنے اور انہیں cloud deployment pipelines سے جوڑنے کے بارے میں مزید کے لیے، Korra Studio پر DevOps اور Cloud segments دیکھیں۔