Docker چیست و چرا توسعه‌دهندگان باید آن را یاد بگیرند؟

Docker دائماً در آگهی‌های شغلی و راهنمای تنظیم ظاهر می‌شود، و اگر هرگز با کانتینرها سر و کار نداشته باشید می‌تواند مثل دیواری به نظر برسد که باید قبل از نوشتن کد واقعی از آن صعود کنید. وقتی از واژگان آن بگذرید کار پیچیده نیست.

کانتینر در واقع چیست

کانتینر برنامه‌ی شما را با هر چیزی که برای اجرای آن نیاز است بسته‌بندی می‌کند: کد، runtime، کتابخانه‌های سیستمی، و فایل‌های پیکربندی. این یک ماشین مجازی نیست. یک VM کل سیستم‌عامل را از جمله kernel مجازی می‌کند، که یعنی بوت کردن آن می‌تواند یک دقیقه طول بکشد و چند گیگابایت RAM مصرف کند. کانتینر kernel ماشین میزبان را به اشتراک می‌گذارد و فقط فرایند را جداسازی می‌کند، بنابراین در کمتر از یک ثانیه شروع می‌شود و معمولاً فقط دهها مگابایت به جای گیگابایت مصرف می‌کند.

این تفاوت دلیل سریع گرفتن Docker در توسعه‌ی محلی و لوله‌های CI است. می‌توانید یک پایگاه داده Postgres، یک cache Redis، و سرور برنامه‌ی خود را روی یک لپ‌تاپ راه‌اندازی کنید بدون نصب مستقیم آن‌ها روی سیستم‌عامل.

بخش‌های اصلی که باید بدانید

چهار اصطلاح وجود دارد که اکثر کاری را که روزانه با آن سر و کار دارید پوشش می‌دهند:

• Image: یک الگوی فقط‌خواندنی ساخته‌شده از Dockerfile. آن را به عنوان یک عکس از filesystem به‌علاوه فراداده‌های مربوط به نحوه‌ی اجرای آن در نظر بگیرید.
• Container: یک نمونه‌ی اجرا‌شده از یک image. می‌توانید بدون تغییر image اصلی، کانتینرها را شروع، متوقف، و حذف کنید.
• Dockerfile: یک فایل متنی با دستورات برای ساخت یک image، خط به خط.
• Registry: جایی که images ذخیره‌شده و از آن download می‌شوند، معمولاً Docker Hub.

یک Dockerfile حداقلی برای یک برنامه‌ی Node.js به این شکل است:

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

آن را با docker build -t my-app . بسازید و با docker run -p 3000:3000 my-app اجرا کنید. flag -p پورتی را روی ماشین شما به پورتی درون کانتینر نقشه‌برداری می‌کند، و این روشی است که می‌توانید برنامه را از مرورگرتان دسترسی داشته باشید.

دستوراتی که دائماً از آن‌ها استفاده خواهید کرد

تعداد کمی دستور اکثر کار روزمره را پوشش می‌دهند:

• docker ps — فهرست کانتینرهای در حال اجرا
• docker ps -a — فهرست تمام کانتینرها، شامل کانتینرهای متوقف شده
• docker images — فهرست images روی ماشین شما
• docker logs <container> — بررسی output از یک کانتینر در حال اجرا یا خراب شده
• docker exec -it <container> sh — باز کردن shell درون یک کانتینر در حال اجرا
• docker rm / docker rmi — پاکسازی کانتینرها و images که دیگر نیاز ندارید

این جفت آخری بیش از آنچه مردم انتظار می‌رود مهم است. Docker با خوشحالی فضای دیسک را به images قدیمی و کانتینرهای متوقف شده تبدیل می‌کند. اجرای docker system prune به طور تناوبی فضای شگفت‌انگیزی را بازیافت می‌کند.

چرا docker-compose جریان کار را تغییر می‌دهد

اکثر پروژه‌های واقعی به بیش از یک کانتینر نیاز دارند: یک سرور برنامه، یک پایگاه داده، شاید یک cache. نوشتن دستورات docker run برای هر کدام به سرعت خسته‌کننده می‌شود. docker-compose.yml به شما اجازه می‌دهد تا کل stack را در یک فایل تعریف کنید:

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 را اجرا کنید و هر دو سرویس با هم شروع می‌شوند، شبکه‌بندی شده تا web بتواند db را بر اساس نام سرویس دسترسی داشته باشد. این تنظیمی است که تقریباً در README هر repo متن‌باز می‌بینید، و درک آن یعنی می‌توانید یک پروژه را clone کنید و آن را در چند دقیقه اجرا کنید به جای نصب دستی Postgres، Redis، و هر چیزی که برنامه نیاز دارد.

جایی که مردم در ابتدا گیر می‌خورند

Volumes تقریباً همه را در ابتدا گیج می‌کند. بدون یک volume، هر چیزی که درون یک کانتینر نوشته می‌شود وقتی کانتینر حذف شود ناپدید می‌شود، که برای پایگاه‌های داده مشکل است. بخش volumes در فایل compose بالا یک volume نام‌گذاری شده را به مسیری درون کانتینر نقشه‌برداری می‌کند تا داده‌ها بعد از راه‌اندازی مجدد باقی بمانند.

یک اشتباه رایج دیگر کپی کردن node_modules یا .git به image است چون فایل .dockerignore وجود ندارد. یکی را درست مثل .gitignore اضافه کنید:

node_modules
.git
.env

این builds را سریع‌تر و images را کوچک‌تر نگه می‌دارد، که وقتی images را به یک registry push می‌کنید یا به Kubernetes deploy می‌کنید مهم است.

کجا برای رفتن بعد از مبانی

وقتی ساخت و اجرای کانتینرها عادی به نظر برسد، مهارت‌های بعدی مفید multi-stage builds برای images کوچک‌تر تولیدی، درک انواع شبکه‌بندی Docker، و خواندن output docker inspect زمانی که چیزی درست متصل نمی‌شود هستند. هیچ‌یک از آن‌ها سخت نیست، فقط برای اولین بار ناآشنا است.

برای اطلاعات بیش‌تر در مورد containerize کردن برنامه‌های واقعی و اتصال آن‌ها به لوله‌های deployment ابری، بخش‌های DevOps و Cloud را در Korra Studio بررسی کنید.