داکر (Docker) چیست؟ آموزش مقدماتی کانتینر برای برنامه‌نویسان

داکر ابزاری است که برنامه شما را همراه با همه وابستگی‌هایش در یک بسته استاندارد به اسم کانتینر قرار می‌دهد تا روی هر سیستمی یک‌جور اجرا شود. در این آموزش مقدماتی می‌فهمید داکر چه مشکلی را حل می‌کند، فرق Image و Container چیست، اولین Dockerfile را برای یک پروژه جنگو می‌نویسید و با Docker Compose جنگو و PostgreSQL را با یک دستور بالا می‌آورید.

آخرین به‌روزرسانی: ۲۱ آبان ۱۴۰۵ — منابع بررسی‌شده در این روز: معرفی رسمی داکر، مرجع Dockerfile و Compose، یادداشت انتشار Docker Engine 29 و Docker Desktop، صفحه مجوز Docker Desktop، راهنمای نصب روی اوبونتو، مستندات والیوم و ساخت چندمرحله‌ای، و مستندات ایمیج رسمی PostgreSQL.

داکر چیست و چه مشکلی را حل می‌کند؟

احتمالاً این جمله را شنیده‌اید: «روی سیستم من کار می‌کند!» برنامه روی لپ‌تاپ برنامه‌نویس درست اجرا می‌شود، اما روی سرور یا سیستم همکار خطا می‌دهد. دلیلش معمولاً تفاوت‌های کوچک است: نسخه دیگری از پایتون، یک کتابخانه جاافتاده، تنظیمات متفاوت سیستم‌عامل یا متغیری که فقط روی یک سیستم تعریف شده. داکر برای حل همین مشکل ساخته شد. داکر (Docker) ابزاری است که برنامه شما را همراه با هر چیزی که برای اجرا لازم دارد، در یک بسته استاندارد قرار می‌دهد. این بسته روی هر سیستمی که داکر داشته باشد، به همان شکل اجرا می‌شود. طبق معرفی رسمی داکر، این پلتفرم برای توسعه، انتقال و اجرای برنامه‌ها طراحی شده و کمک می‌کند برنامه را از زیرساخت جدا کنید تا نرم‌افزار را سریع‌تر تحویل دهید. یک مثال ساده: فرض کنید کانتینرهای حمل بار در بندر را ببینید. مهم نیست داخل کانتینر لباس باشد یا قطعات خودرو؛ جرثقیل، کشتی و کامیون همه با یک اندازه استاندارد کار می‌کنند. کانتینر نرم‌افزاری هم همین ایده است: داخلش هر برنامه‌ای باشد، داکر آن را یک‌جور اجرا می‌کند. داکر به‌خصوص با یکی از اصول مهم نرم‌افزارهای امروزی جور است: محیط توسعه و تولید باید تا جای ممکن شبیه هم باشند. این اصل را در فاکتور توازن توسعه و تولید از مجموعه دوازده فاکتور توضیح داده‌ایم و داکر یکی از ساده‌ترین راه‌های رسیدن به آن است.

کانتینر با ماشین مجازی چه فرقی دارد؟

پیش از داکر، رایج‌ترین راه جدا کردن برنامه‌ها ماشین مجازی (Virtual Machine) بود. ماشین مجازی یک کامپیوتر کامل شبیه‌سازی‌شده است: سیستم‌عامل جداگانه، هسته جداگانه و منابع رزروشده. این کار امن و کامل است، اما سنگین است؛ هر ماشین مجازی چند گیگابایت فضا می‌گیرد و روشن شدنش زمان می‌برد. کانتینر سبک‌تر است. همه کانتینرها از هسته (Kernel) همان سیستم‌عامل میزبان استفاده می‌کنند و فقط فایل‌ها، کتابخانه‌ها و فرایندهای برنامه از بقیه جدا می‌شوند. نتیجه این است که کانتینر معمولاً در چند ثانیه بالا می‌آید و روی یک سرور می‌شود تعداد زیادی از آن‌ها را کنار هم اجرا کرد.

یک نکته مهم: چون کانتینر هسته میزبان را استفاده می‌کند، کانتینرهای لینوکسی به هسته لینوکس نیاز دارند. Docker Desktop در ویندوز و مک برای همین یک ماشین مجازی سبک لینوکسی را پشت صحنه اجرا می‌کند. پس روی ویندوز هم کانتینر لینوکسی اجرا می‌کنید، فقط داکر این بخش را از دید شما پنهان کرده است.

مفاهیم اصلی داکر به زبان ساده

قبل از اینکه دستوری بنویسیم، باید چند اسم را بشناسیم. اگر این چند مفهوم را خوب بفهمید، بقیه داکر خیلی ساده‌تر می‌شود.

Image؛ قالب آماده برنامه

ایمیج (Image) یک قالب فقط‌خواندنی است که همه چیزهای لازم برای اجرای برنامه را دارد: سیستم‌فایل پایه، زبان برنامه‌نویسی، کتابخانه‌ها، کد شما و دستوری که موقع شروع اجرا می‌شود. ایمیج را مثل دستور پخت غذا یا قالب کیک در نظر بگیرید. خودش اجرا نمی‌شود، اما از روی آن می‌شود هر چند بار که بخواهید نمونه ساخت. ایمیج‌ها لایه‌لایه ساخته می‌شوند. هر دستور در Dockerfile معمولاً یک لایه تازه می‌سازد و داکر لایه‌هایی را که تغییر نکرده‌اند، از حافظه کش دوباره استفاده می‌کند. به همین دلیل ترتیب نوشتن دستورها روی سرعت ساخت اثر زیادی دارد؛ جلوتر این را با مثال می‌بینیم.

Container؛ نمونه در حال اجرا

کانتینر (Container) نمونه زنده‌ای از یک ایمیج است. وقتی دستور docker run را می‌زنید، داکر از روی ایمیج یک کانتینر می‌سازد و برنامه داخل آن اجرا می‌شود. از یک ایمیج می‌شود ده کانتینر هم‌زمان ساخت. طبق مستندات داکر درباره کانتینر، کانتینرها از هم جدا هستند و هر کدام نرم‌افزار، کتابخانه و تنظیمات خودش را دارد. یک ویژگی مهم کانتینر این است که موقتی است. اگر کانتینر را پاک کنید، هر فایلی که داخلش نوشته شده بود هم پاک می‌شود. برای داده‌های ماندگار مثل پایگاه داده باید از Volume استفاده کنید.

Dockerfile؛ دستور ساخت ایمیج

داکرفایل (Dockerfile) یک فایل متنی ساده است که قدم‌به‌قدم می‌گوید ایمیج چطور ساخته شود: از کدام ایمیج پایه شروع کن، چه فایل‌هایی را کپی کن، چه بسته‌هایی نصب کن و در نهایت چه دستوری اجرا شود. همه این دستورها در مرجع رسمی Dockerfile آمده‌اند.

Registry و Docker Hub؛ انبار ایمیج‌ها

رجیستری (Registry) جایی است که ایمیج‌ها در آن نگهداری و به اشتراک گذاشته می‌شوند. معروف‌ترین رجیستری عمومی Docker Hub است که ایمیج‌های رسمی مثل python، postgres و nginx را دارد. وقتی می‌نویسید FROM python:3.15-slim، داکر این ایمیج را از Docker Hub دریافت می‌کند. GitHub و GitLab هم رجیستری خودشان را دارند.

Volume و Network

والیوم (Volume) فضای ذخیره‌سازی‌ای است که بیرون از چرخه عمر کانتینر نگه داشته می‌شود. اگر کانتینر پایگاه داده را پاک کنید و دوباره بسازید، داده‌ها در والیوم باقی می‌مانند. مستندات والیوم داکر آن را راه پیشنهادی برای نگه داشتن داده کانتینرها معرفی می‌کند. شبکه (Network) هم به کانتینرها اجازه می‌دهد با اسم همدیگر را پیدا کنند؛ مثلاً برنامه جنگو پایگاه داده را با اسم db صدا بزند.

نصب داکر؛ Docker Desktop یا Docker Engine؟

داکر دو شکل اصلی دارد. Docker Desktop برنامه گرافیکی برای ویندوز، مک و لینوکس است که موتور داکر، Docker Compose و ابزارهای دیگر را یک‌جا نصب می‌کند. Docker Engine موتور اصلی و متن‌باز داکر است که معمولاً روی سرورهای لینوکسی نصب می‌شود. در ۲۱ آبان ۱۴۰۵ آخرین نسخه Docker Engine طبق یادداشت‌های انتشار رسمی، نسخه 29.9.3 است که ۱۲ آبان (۳ نوامبر ۲۰۲۶) منتشر شد و چند آسیب‌پذیری امنیتی را برطرف کرد. آخرین نسخه Docker Desktop هم 4.99.0 است که ۱۸ آبان (۹ نوامبر ۲۰۲۶) منتشر شده است. این شماره‌ها زود تغییر می‌کنند؛ پس همیشه نسخه تازه را از صفحه رسمی بگیرید.

مجوز Docker Desktop؛ رایگان برای چه کسانی؟

یک نکته‌ای که خیلی‌ها نمی‌دانند: Docker Desktop برای همه رایگان نیست. طبق صفحه مجوز Docker Desktop، استفاده از آن برای کسب‌وکارهای کوچک (کمتر از ۲۵۰ کارمند و کمتر از ۱۰ میلیون دلار درآمد سالانه)، استفاده شخصی، آموزش و پروژه‌های متن‌باز غیرتجاری رایگان است. سازمان‌های بزرگ‌تر و نهادهای دولتی به اشتراک پولی نیاز دارند. Docker Engine روی لینوکس این محدودیت را ندارد.

نصب روی ویندوز، مک و لینوکس

روی ویندوز و مک، فایل نصب Docker Desktop را از سایت رسمی بگیرید و مراحل نصب را جلو بروید. روی ویندوز، Docker Desktop برای اجرای کانتینرهای لینوکسی از WSL (زیرسیستم لینوکس ویندوز) کمک می‌گیرد. روی سرور اوبونتو بهتر است Docker Engine را طبق راهنمای رسمی نصب روی اوبونتو از مخزن خود داکر نصب کنید، نه از نسخه‌های قدیمی مخزن سیستم‌عامل. بعد از نصب، این دو دستور را بزنید تا مطمئن شوید همه چیز درست است:

docker --version
docker run hello-world

اگر پیام Hello from Docker! را دیدید، داکر آماده است. ما این دستور را روی Docker Engine 29.9.3 اجرا کردیم و همین پیام را گرفتیم.

دسترسی به Docker Hub از ایران

کاربران ایرانی گاهی هنگام دریافت ایمیج از Docker Hub با خطا یا کندی روبه‌رو می‌شوند. دلیلش می‌تواند محدودیت‌های تحریمی، فیلترینگ یا قطعی شبکه باشد و وضعیت آن مدام تغییر می‌کند. بعضی شرکت‌های ابری داخلی آینه (Mirror) رجیستری ارائه می‌دهند که در تنظیمات داکر به‌عنوان registry-mirrors معرفی می‌شود. اگر از آینه استفاده می‌کنید، فقط سرویس‌های شناخته‌شده را انتخاب کنید و ایمیج‌های رسمی را ترجیح دهید؛ ایمیجی که از منبع نامعتبر بیاید، می‌تواند کد مخرب داشته باشد.

دستورات پرکاربرد داکر

بیشتر کار روزمره با داکر با همین چند دستور انجام می‌شود. لازم نیست همه را حفظ کنید؛ کافی است بدانید هر کدام چه کاری می‌کند.

یک نمونه عملی: ایمیج رسمی پایتون را بگیرید و یک دستور کوتاه داخل آن اجرا کنید، بدون اینکه پایتون روی سیستم خودتان نصب باشد:

docker pull python:3.15-slim
docker run --rm python:3.15-slim python -c "import sys; print(sys.version)"

در اجرای ما خروجی 3.15.2 بود. گزینه --rm باعث می‌شود کانتینر بعد از پایان کار خودش پاک شود و سیستم شما پر از کانتینرهای متوقف‌شده نشود.

اولین Dockerfile؛ داکرایز کردن پروژه جنگو

حالا وقت کار عملی است. یک پروژه ساده جنگو داریم که می‌خواهیم داخل کانتینر اجرا شود. اگر با ساخت پروژه جنگو آشنا نیستید، اول ساخت اپلیکیشن در جنگو را ببینید. ساختار پوشه پروژه این است:

myshop/
├── config/
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── manage.py
├── requirements.txt
├── .dockerignore
├── Dockerfile
└── compose.yaml

فایل requirements.txt

همه وابستگی‌ها را با نسخه دقیق بنویسید. این کار همان اصلی است که در فاکتور وابستگی‌ها گفته‌ایم: وابستگی‌ها باید صریح و قابل تکرار باشند.

Django==6.1.3
gunicorn==27.0.0
psycopg[binary]==3.3.8

نوشتن Dockerfile خط‌به‌خط

این Dockerfile کامل پروژه ماست:

FROM python:3.15-slim

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

RUN useradd --create-home appuser
USER appuser

EXPOSE 8000
CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "2"]

حالا هر خط را ساده توضیح می‌دهیم. FROM ایمیج پایه را مشخص می‌کند؛ نسخه slim پایتون کوچک‌تر از نسخه کامل است ولی برای بیشتر پروژه‌ها کافی است. دو متغیر ENV جلوی ساخت فایل‌های pyc را می‌گیرند و باعث می‌شوند لاگ‌ها بی‌معطلی نمایش داده شوند. WORKDIR پوشه کاری داخل کانتینر را تعیین می‌کند. مهم‌ترین نکته این فایل ترتیب دستورهاست. اول فقط requirements.txt را کپی می‌کنیم و بسته‌ها را نصب می‌کنیم، بعد بقیه کد را. چرا؟ چون کد شما مدام عوض می‌شود ولی فهرست وابستگی‌ها کمتر. با این ترتیب، اگر فقط یک فایل پایتون را تغییر دهید، داکر لایه نصب بسته‌ها را از کش برمی‌دارد و ساخت دوباره چند ثانیه طول می‌کشد، نه چند دقیقه. راهنمای بهترین روش‌های ساخت ایمیج هم همین را توصیه می‌کند. دو خط useradd و USER برنامه را با یک کاربر معمولی اجرا می‌کنند، نه با root. اگر روزی کسی از برنامه شما نفوذ کند، دسترسی کمتری داخل کانتینر خواهد داشت. EXPOSE فقط مستندسازی است و می‌گوید برنامه روی پورت 8000 گوش می‌دهد. CMD هم دستور شروع است که اینجا Gunicorn را اجرا می‌کند. اگر با Gunicorn آشنا نیستید، نقش آن را در آموزش دیپلوی جنگو با Gunicorn و Nginx توضیح داده‌ایم.

فایل .dockerignore را فراموش نکنید

دستور COPY . . همه فایل‌های پوشه را داخل ایمیج می‌برد، حتی فایل‌هایی که نباید. فایل .dockerignore مثل .gitignore کار می‌کند و جلوی کپی شدن فایل‌های اضافه یا حساس را می‌گیرد:

.git
.venv
__pycache__/
*.pyc
.env
db.sqlite3

اضافه کردن .env به این فهرست خیلی مهم است. اگر رمزها داخل ایمیج بروند، هر کسی که ایمیج را داشته باشد، می‌تواند آن‌ها را بخواند.

ساخت ایمیج و اجرای کانتینر

حالا ایمیج را بسازید و یک کانتینر از آن اجرا کنید:

docker build -t myshop:1.0 .
docker run -d --name web1 -p 8000:8000 myshop:1.0
docker ps
docker logs web1

گزینه -t به ایمیج اسم و برچسب می‌دهد. گزینه -d کانتینر را در پس‌زمینه اجرا می‌کند و -p 8000:8000 پورت 8000 سیستم شما را به پورت 8000 کانتینر وصل می‌کند. حالا اگر آدرس localhost:8000 را در مرورگر باز کنید، صفحه پروژه را می‌بینید. در آزمایش ما صفحه اصلی پیام Hello from Docker! را نشان داد و دستور whoami داخل کانتینر، کاربر appuser را برگرداند؛ یعنی برنامه واقعاً با کاربر غیر root اجرا می‌شد. ایمیج ساخته‌شده روی دیسک حدود ۲۷۷ مگابایت جا گرفت. اگر بعدها خواستید ایمیج کوچک‌تری داشته باشید، سراغ ساخت چندمرحله‌ای (Multi-stage) بروید که ابزارهای ساخت را از ایمیج نهایی حذف می‌کند.

Docker Compose؛ اجرای چند کانتینر با یک دستور

برنامه واقعی معمولاً فقط یک کانتینر نیست. پروژه جنگو به پایگاه داده نیاز دارد، شاید Redis برای کش و یک صف کار هم داشته باشد. اجرای جداگانه هر کدام با docker run و یادآوری همه گزینه‌ها سخت و پرخطاست. Docker Compose این مشکل را حل می‌کند: همه سرویس‌ها را در یک فایل YAML تعریف می‌کنید و با یک دستور همه را بالا می‌آورید.

فایل compose.yaml برای جنگو و PostgreSQL

این فایل یک سرویس web برای جنگو و یک سرویس db برای PostgreSQL تعریف می‌کند:

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DJANGO_DEBUG: "0"
      DB_HOST: db
      DB_NAME: shop
      DB_USER: shop
      DB_PASSWORD: ${DB_PASSWORD}
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:18
    environment:
      POSTGRES_DB: shop
      POSTGRES_USER: shop
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U shop -d shop"]
      interval: 5s
      retries: 10

volumes:
  pgdata:

چند نکته در این فایل هست. سرویس web با build: . از Dockerfile همین پوشه ساخته می‌شود. DB_HOST برابر db است، چون Compose برای سرویس‌ها یک شبکه می‌سازد و هر سرویس با اسم خودش در دسترس است. رمز پایگاه داده هم داخل فایل نوشته نشده و از متغیر DB_PASSWORD می‌آید که Compose آن را از فایل .env کنار پروژه می‌خواند. این همان روشی است که در فاکتور پیکربندی توصیه کرده‌ایم: تنظیمات و رمزها بیرون از کد. depends_on با شرط service_healthy باعث می‌شود جنگو فقط وقتی شروع شود که PostgreSQL واقعاً آماده پذیرش اتصال باشد، نه فقط روشن شده باشد. healthcheck هم با دستور pg_isready همین آمادگی را می‌سنجد. یک تغییر تازه را هم در نظر بگیرید: در ایمیج رسمی PostgreSQL نسخه ۱۸ به بعد، طبق مستندات ایمیج، مسیر پیش‌فرض داده عوض شده و والیوم باید به /var/lib/postgresql وصل شود، نه /var/lib/postgresql/data که در آموزش‌های قدیمی می‌بینید. اگر آموزش قدیمی را کپی کنید، ممکن است داده‌ها جایی ذخیره شوند که انتظار ندارید. در فایل‌های Compose قدیمی خط version: "3.8" را بالای فایل می‌بینید. طبق مرجع فایل Compose این فیلد منسوخ است؛ Compose همیشه از جدیدترین شِما استفاده می‌کند و اگر version را بنویسید فقط هشدار می‌دهد. پس آن را ننویسید.

اجرای پروژه با Compose

اول فایل .env را کنار compose.yaml بسازید و یک رمز قوی در آن بگذارید. بعد این دستورها را اجرا کنید:

docker compose up -d --build
docker compose ps
docker compose exec web python manage.py migrate
docker compose logs -f web
docker compose down

up -d --build ایمیج را می‌سازد و همه سرویس‌ها را در پس‌زمینه بالا می‌آورد. exec یک دستور را داخل کانتینر در حال اجرا می‌زند؛ اینجا مایگریشن‌های جنگو را روی PostgreSQL اعمال می‌کند. down همه کانتینرها و شبکه را پاک می‌کند، ولی والیوم pgdata را نگه می‌دارد. اگر down -v بزنید، والیوم و همه داده‌های پایگاه داده هم پاک می‌شوند؛ پس این گزینه را با احتیاط به کار ببرید. ما این فایل را با Docker Compose نسخه 5.7.1 و PostgreSQL 18.6 آزمایش کردیم: سرویس db سالم شد، migrate روی PostgreSQL اجرا شد و بعد از down و up دوباره، مایگریشن‌ها همچنان اعمال‌شده بودند؛ یعنی والیوم داده‌ها را نگه داشته بود. محیط آزمایش ما شبکه bridge نداشت، برای همین فقط در آن محیط یک فایل جانبی برای استفاده از شبکه میزبان اضافه کردیم؛ روی سیستم معمولی به آن نیازی ندارید.

داکر و اصول دوازده فاکتور

اگر مجموعه اصول برنامه دوازده‌فاکتوری را خوانده باشید، می‌بینید داکر بسیاری از آن اصول را عملی می‌کند. وابستگی‌ها داخل ایمیج قفل می‌شوند. تنظیمات از متغیرهای محیطی می‌آیند. برنامه با اتصال به پورت خودش سرویس می‌دهد. یک ایمیج یکسان در محیط تست و تولید اجرا می‌شود و فقط تنظیماتش فرق می‌کند. کانتینرها هم سریع روشن و خاموش می‌شوند که همان اصل قابل حذف بودن است. داکر همچنین پایه معماری میکروسرویس است، چون هر سرویس می‌تواند ایمیج و کانتینر خودش را داشته باشد. اما داکر فقط برای میکروسرویس نیست؛ یک برنامه یکپارچه هم از کانتینری شدن سود می‌برد. مقایسه این دو سبک را در معماری مونولیتیک در برابر میکروسرویس بخوانید.

اشتباهات رایج مبتدی‌ها در داکر

بیشتر مشکلاتی که تازه‌کارها با داکر دارند، از چند اشتباه تکراری می‌آید. این جدول را قبل از اولین پروژه مرور کنید:

داکر برای چه کارهایی مناسب نیست؟

داکر ابزار خیلی خوبی است، اما همه جا لازم نیست. اگر یک سایت وردپرسی ساده روی هاست اشتراکی دارید، داکر چیزی به شما اضافه نمی‌کند و هاست شما هم احتمالاً اجازه اجرای آن را نمی‌دهد. برای برنامه‌های دسکتاپ گرافیکی هم داکر انتخاب رایجی نیست. همچنین داکر جای یادگیری لینوکس و شبکه را نمی‌گیرد. وقتی کانتینر خطا می‌دهد، باید بتوانید لاگ بخوانید، پورت‌ها را بررسی کنید و بفهمید فایل کجا ذخیره شده است. اگر تازه شروع کرده‌اید، اول یک بار پروژه را بدون داکر روی سرور مستقر کنید تا بفهمید داکر دقیقاً چه کارهایی را برایتان خودکار می‌کند. قدم بعدی هم خودکار کردن ساخت و تست ایمیج است که در آموزش CI/CD با GitHub Actions و GitLab CI به آن پرداخته‌ایم.

سؤالات متداول درباره داکر

داکر رایگان است؟

Docker Engine متن‌باز و رایگان است. Docker Desktop برای استفاده شخصی، آموزش، پروژه‌های متن‌باز غیرتجاری و کسب‌وکارهای کمتر از ۲۵۰ نفر و کمتر از ۱۰ میلیون دلار درآمد سالانه رایگان است. سازمان‌های بزرگ‌تر باید اشتراک بخرند.

فرق Image و Container چیست؟

ایمیج قالب فقط‌خواندنی است و کانتینر نمونه در حال اجرای آن. از یک ایمیج می‌شود چند کانتینر هم‌زمان ساخت؛ درست مثل کلاس و شیء در برنامه‌نویسی.

آیا داکر روی ویندوز کار می‌کند؟

بله. Docker Desktop روی ویندوز با کمک WSL کار می‌کند و کانتینرهای لینوکسی را اجرا می‌کند. روی ویندوز سرور هم امکان اجرای کانتینرهای ویندوزی وجود دارد.

داکر جای ماشین مجازی را می‌گیرد؟

نه کاملاً. کانتینر سبک‌تر و سریع‌تر است، اما ماشین مجازی جداسازی کامل‌تری دارد و می‌تواند سیستم‌عامل متفاوتی با هسته خودش اجرا کند. در بسیاری از سرورها هر دو با هم استفاده می‌شوند؛ کانتینرها داخل ماشین‌های مجازی اجرا می‌شوند.

داده‌های پایگاه داده داخل کانتینر پاک می‌شوند؟

اگر والیوم تعریف نکرده باشید، بله؛ با پاک شدن کانتینر داده‌ها هم از بین می‌روند. همیشه برای پایگاه داده والیوم تعریف کنید و از آن نسخه پشتیبان بگیرید.

docker-compose با docker compose چه فرقی دارد؟

docker-compose با خط تیره نسخه قدیمی و جداگانه این ابزار بود. نسخه امروزی یک افزونه داخل خود داکر است و با docker compose (با فاصله) اجرا می‌شود. آموزش‌ها و دستورهای جدید را با همین شکل بنویسید.

منابع و مراجع