دردی که داکر درمان می‌کندThe pain Docker treats

داستان همیشه یکی است. برنامه‌ات روی لپ‌تاپ خودت اجرا می‌شود. آن را به یک نفر دیگر می‌دهی و اجرا نمی‌شود. این جمله را می‌گویی: «روی سیستم من که کار می‌کرد.» و راست هم می‌گویی.

The story is always the same. Your program runs on your laptop. You hand it to someone else and it does not run. You say the sentence: “it worked on my machine.” And you are telling the truth.

فرض کن یک برنامهٔ کوچک پایتون نوشته‌ای که از یک پایگاه‌دادهٔ PostgreSQL می‌خواند و یک گزارش می‌سازد. روی لپ‌تاپ خودت بی‌عیب کار می‌کند. فایل را برای همکارت می‌فرستی. ده دقیقه بعد این عکس صفحه را می‌فرستد:

Say you wrote a small Python program that reads from a PostgreSQL database and produces a report. It works flawlessly on your laptop. You send the file to a colleague. Ten minutes later they send you this screenshot:

python report.py
Traceback (most recent call last):
  File "report.py", line 3, in <module>
    import psycopg2
ModuleNotFoundError: No module named 'psycopg2'

می‌گویی: «نصبش کن.» نصب می‌کند. حالا این می‌آید:

You say: “install it.” They do. Now this shows up:

pip install psycopg2
  Error: pg_config executable not found.
  pg_config is required to build psycopg2 from source.

حالا معلوم می‌شود که کتابخانهٔ پایتون به یک کتابخانهٔ سیستمی نیاز دارد که روی ماشین تو سال‌ها پیش موقع یک کار دیگر نصب شده بود و اصلاً یادت نیست. این دقیقاً همان چیزی است که آدم‌ها به آن می‌گویند «درد محیط» (environment drift): تفاوت بی‌سروصدا میان ماشین‌ها که تا لحظهٔ خراب شدن دیده نمی‌شود.

It turns out the Python library needs a system library that was installed on your machine years ago for something unrelated and that you have long forgotten. This is exactly what people mean by environment drift: the silent difference between machines that stays invisible until it breaks.

سه لایه‌ای که فرق می‌کنند

The three layers that differ

وقتی دو ماشین «یکسان» نیستند، تفاوت تقریباً همیشه در یکی از این سه لایه است:

When two machines are not “the same”, the difference is almost always in one of three layers:

1. نسخهٔ زبان و کتابخانه‌های آن Language runtime and its libraries

   تو Python 3.12 داری، او 3.9. کدی که با نحو جدید نوشته‌ای، آنجا خطای نحوی می‌دهد. یا Node 22 در برابر Node 18، که یک تابع در یکی هست و در دیگری نیست.

   You have Python 3.12, they have 3.9. Code written with newer syntax is a syntax error over there. Or Node 22 versus Node 18, where a function exists in one and not the other.

2. کتابخانه‌های سیستمی System libraries

   همان libpq، libssl، ImageMagick و امثالش. اینها بخشی از پروژهٔ تو نیستند، پس در فایل‌های پروژه هم ثبت نشده‌اند. نامرئی‌اند تا وقتی که غایب باشند.

   Things like libpq, libssl, ImageMagick. They are not part of your project, so they are not recorded in your project files. Invisible until absent.

3. پیکربندی و مسیرها Configuration and paths

   متغیر محیطی که فقط در فایل .bashrc تو هست. مسیری که روی ویندوز C:\data است و روی لینوکس /var/data. سرویسی که روی پورت ۵۴۳۲ بالا است چون تو دستی بالا آورده‌ای.

   An environment variable that lives only in your .bashrc. A path that is C:\data on Windows and /var/data on Linux. A service listening on port 5432 because you started it by hand.

راه‌حل‌های قبلی و اینکه چرا کافی نبودند

Earlier answers, and why they fell short

این مسئله جدید نیست و آدم‌ها قبلاً سه جواب برایش داشتند. هر سه جواب کار می‌کنند، فقط هزینهٔ متفاوتی دارند.

This is not a new problem, and people had three answers for it. All three work; they just cost different amounts.

جواب داکر از جنس دیگری است: به‌جای اینکه توضیح بدهی برنامه به چه چیزهایی نیاز دارد، آن چیزها را کنار خود برنامه بسته‌بندی کن و همه را با هم تحویل بده. نه یک راهنما، نه یک اسکریپت، بلکه یک بستهٔ آماده که همه‌جا یکسان باز می‌شود.

Docker's answer is of a different kind: instead of describing what your program needs, package those things next to the program and ship them together. Not a README, not a script — a ready-made bundle that opens the same way everywhere.

داکر دقیقاً چیستWhat Docker actually is

دو جمله، بدون تعارف: داکر ابزاری است که برنامه‌ات را همراه با تمام وابستگی‌هایش در یک بستهٔ استاندارد و تغییرناپذیر به نام image (ایمیج) بسته‌بندی می‌کند. سپس آن بسته را به‌صورت یک پروسهٔ ایزوله روی هستهٔ لینوکس ماشین میزبان اجرا می‌کند؛ به آن پروسهٔ در حال اجرا می‌گوییم container (کانتینر).

Two sentences, no ceremony: Docker packages your program together with every dependency into a standard, immutable bundle called an image. It then runs that bundle as an isolated process on the host machine's Linux kernel; that running process is a container.

این تعریف دو کلمهٔ مهم دارد که باید رویشان مکث کنی.

That definition has two words worth pausing on.

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

Immutable means an image does not change after it is built. To change something, you build a new image. The constraint sounds annoying, but it is exactly what guarantees that the image you tested today behaves the same on the server tomorrow. Anything that can change quietly eventually does.

روی هستهٔ ماشین میزبان یعنی کانتینر سیستم‌عامل خودش را ندارد. با ماشین میزبان یک هسته (kernel) مشترک دارد و فقط فایل‌سیستم و دیدش جدا است. این تفاوت اصلی با ماشین مجازی است و در بخش بعد کاملاً بازش می‌کنیم.

On the host's kernel means a container has no operating system of its own. It shares one kernel with the host and only its filesystem and its view are separate. That is the key difference from a virtual machine, and the next section unpacks it fully.

داکر چه چیزی نیست

What Docker is not

این فهرست به اندازهٔ تعریف مهم است، چون بیشتر سردرگمی‌های ماه اول از همین‌ها می‌آید.

This list matters as much as the definition; most first-month confusion comes from these.

سه قطعه‌ای که باید از هم تشخیص بدهی

Three pieces you must tell apart

وقتی می‌گوییم «داکر»، در واقع سه چیز جدا را با یک اسم صدا می‌زنیم. تشخیص ندادنشان باعث می‌شود خطاها بی‌معنی به نظر برسند.

When we say “Docker” we are calling three separate things by one name. Not telling them apart is what makes error messages look meaningless.

این معماری یعنی docker فقط یک پیام‌رسان است. وقتی این خطا را می‌بینی:

This architecture means docker is only a messenger. When you see this error:

docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?

مشکل «داکر نصب نیست» نیست. دستور docker کاملاً سالم اجرا شده و پیامش را فرستاده؛ کسی آن طرف خط جواب نداده. یعنی سرویس پس‌زمینه بالا نیست. درمانش در فصل ۲ است.

The problem is not “Docker is not installed”. The docker command ran perfectly and sent its message; nobody answered on the other end. The background service is not up. The cure is in chapter 2.

ماشین مجازی یا کانتینر؟Virtual machine or container?

این مقایسه مهم‌ترین نمودار این فصل است. تفاوت در یک چیز خلاصه می‌شود: کانتینر هستهٔ سیستم‌عامل را قرض می‌گیرد، ماشین مجازی هستهٔ خودش را می‌آورد.

This comparison is the most important diagram in the chapter. The difference reduces to one thing: a container borrows the operating system kernel; a virtual machine brings its own.

آن لایهٔ تکراری همان چیزی است که هزینه دارد. یک سیستم‌عامل کامل یعنی صدها مگابایت فایل، یک هستهٔ جدا در حافظه، و یک فرایند بوت کامل هر بار که روشنش می‌کنی. سه ماشین مجازی یعنی سه بار همهٔ اینها — حتی اگر هر سه دقیقاً یک اوبونتوی یکسان باشند.

That repeated layer is what costs. A full operating system means hundreds of megabytes of files, a separate kernel in memory, and a complete boot sequence every time you start it. Three VMs mean three of all that — even if all three are the identical Ubuntu.

چهار قطعه‌ای که همه‌چیز از آنها ساخته می‌شودThe four pieces everything is built from

اگر فقط چهار کلمه از این فصل یادت بماند، همین‌ها باشند: image، container، volume، registry. هر خطایی که در شش ماه آینده می‌بینی، دربارهٔ یکی از این چهارتاست.

If only four words survive this chapter, make them these: image, container, volume, registry. Every error you meet in the next six months is about one of them.

رابطهٔ ایمیج و کانتینر

How image and container relate

این مهم‌ترین رابطه در کل داکر است و بیشتر آدم‌ها اولش قاطی‌اش می‌کنند. ساده‌ترین تشبیهی که درست از آب درمی‌آید این است:

This is the most important relationship in all of Docker, and most people confuse it at first. The simplest analogy that actually holds up:

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

An image is like an installer; a container is like the program once you have opened it. You have one installer, but you can open the program three times at once. Each window has its own state, and closing one does nothing to the others. The installer itself never changes.

برای کسانی که برنامه‌نویسی شیءگرا بلدند، تشبیه دقیق‌تر این است: ایمیج class است و کانتینر instance. از یک کلاس، هر تعداد شیء که بخواهی می‌سازی.

If you know object-oriented programming, the tighter analogy is: the image is a class and the container is an instance. One class, as many instances as you like.

لایه‌ها: چرا ایمیج شبیه کیک استLayers: why an image is like a cake

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

An image is not one solid file. It is a stack of layers, each holding only its difference from the one below. This sounds like an implementation detail. It is not: half the odd behaviour you meet in your first month comes from it.

فرض کن ایمیجی می‌سازی که بر پایهٔ اوبونتو است، بعد پایتون نصب می‌کند، بعد کتابخانه‌های پروژه را نصب می‌کند، و آخر کد خودت را کپی می‌کند. نتیجه چهار لایه است که روی هم چیده شده‌اند. داکر این را به تو نشان می‌دهد:

Say you build an image based on Ubuntu, then install Python, then install project libraries, then copy in your own code. The result is four stacked layers. Docker will show them to you:

# تاریخچهٔ لایه‌های یک ایمیج آماده را ببین
docker image history nginx:1.27-alpine

IMAGE          CREATED       CREATED BY                                      SIZE
<image id>     3 weeks ago   CMD ["nginx" "-g" "daemon off;"]                0B
<missing>      3 weeks ago   STOPSIGNAL SIGQUIT                              0B
<missing>      3 weeks ago   EXPOSE map[80/tcp:{}]                           0B
<missing>      3 weeks ago   ENTRYPOINT ["/docker-entrypoint.sh"]            0B
<missing>      3 weeks ago   COPY docker-entrypoint.sh / # buildkit          1.62kB
<missing>      3 weeks ago   RUN /bin/sh -c set -x && addgroup ...           41.2MB
<missing>      3 weeks ago   ENV NGINX_VERSION=1.27.3                        0B
<missing>      4 weeks ago   ADD alpine-minirootfs.tar.gz / # buildkit       8.42MB

از پایین به بالا بخوانش. پایین‌ترین لایه فایل‌سیستم پایهٔ آلپاین است. رویش لایه‌ای که خود Nginx را نصب کرده. بالاتر لایه‌هایی که فقط تنظیمات‌اند و صفر بایت حجم دارند، چون هیچ فایلی اضافه نکرده‌اند — فقط ابرداده‌اند.

Read it bottom-up. The bottom layer is the Alpine base filesystem. Above it, the layer that installed Nginx itself. Higher up, layers that are pure configuration and take zero bytes, because they add no files — they are only metadata.

چرا این طراحی؟ دو دلیل محکم

Why this design? Two solid reasons

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

One: sharing on disk. If ten different images all sit on that same Alpine base, the base layer is stored on disk exactly once. Ten images, one copy of the base. That is why the second and third image download far faster than the first.

دو: کش هنگام ساخت. وقتی ایمیجت را دوباره می‌سازی و فقط کد خودت عوض شده، داکر لایه‌های پایینی را دست‌نخورده برمی‌دارد و فقط لایهٔ آخر را از نو می‌سازد. تفاوتش بین بیلد دو ثانیه‌ای و بیلد دو دقیقه‌ای است. فصل ۴ کاملاً روی همین سوار است.

Two: build cache. When you rebuild and only your own code changed, Docker reuses the lower layers untouched and rebuilds only the last one. That is the difference between a two-second and a two-minute build. Chapter 4 is built entirely on this.

لایهٔ نوشتنی — و اولین دام بزرگ

The writable layer — and the first big trap

لایه‌های ایمیج فقط‌خواندنی‌اند. پس وقتی کانتینر اجرا می‌شود و برنامه می‌خواهد فایلی بنویسد، چه اتفاقی می‌افتد؟ داکر یک لایهٔ نازک و نوشتنی روی همهٔ لایه‌های ایمیج اضافه می‌کند. هر تغییری — فایل جدید، ویرایش، حذف — فقط در آن لایه ثبت می‌شود.

Image layers are read-only. So when a container runs and the program wants to write a file, what happens? Docker adds a thin writable layer on top of all the image layers. Every change — a new file, an edit, a deletion — is recorded only in that layer.

اولین اجراYour first run

تا اینجا حرف زدیم. حالا دست به کار شویم. برای این بخش داکر باید نصب باشد؛ اگر نیست، فصل ۲ را ببین و برگرد. هیچ‌کدام از این دستورها به سیستم تو آسیب نمی‌زنند.

Enough talk. Hands on the keyboard. This section needs Docker installed; if it is not, see chapter 2 and come back. None of these commands can hurt your system.

اول مطمئن شو که همه‌چیز سر جایش است:

First, confirm everything is in place:

docker --version
Docker version 27.3.1, build ce12230

# این یکی مهم‌تر است: نشان می‌دهد سرویس پس‌زمینه هم جواب می‌دهد
docker info --format '{{.ServerVersion}}'
27.3.1

اگر دستور دوم خطای Cannot connect to the Docker daemon داد، یعنی CLI سالم است ولی سرویس بالا نیست — برگرد به جدول بخش دوم.

If the second command gives Cannot connect to the Docker daemon, the CLI is fine but the service is down — go back to the table in section two.

اجرای اول: hello-world

First run: hello-world

docker run hello-world

بار اول خروجی چیزی شبیه این است:

The first time, the output looks something like this:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:305243c73…
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

این پنج خط اول، تمام معماری داکر را در خودش دارد. بیایید خط‌به‌خط بخوانیمش:

Those first five lines contain the whole architecture. Let us read them line by line:

1. Unable to find image … locally

   داکر اول انبار محلی خودت را نگاه کرد. ایمیج آنجا نبود. توجه کن که این خطا نیست، فقط گزارش است.

   Docker looked in your local store first. The image was not there. Note that this is not an error, only a report.

2. Pulling from library/hello-world

   پس رفت سراغ رجیستری پیش‌فرض. library یعنی این ایمیج «رسمی» است و صاحب مشخصی ندارد؛ ایمیج‌های شخصی به شکل username/image هستند.

   So it went to the default registry. library means this is an “official” image with no individual owner; personal images look like username/image.

3. c1ec31eb5944: Pull complete

   این عدد شناسهٔ یک لایه است. ایمیج‌های بزرگ‌تر اینجا چند خط دارند — هر خط یک لایه، و همه به‌صورت موازی دانلود می‌شوند.

   That identifier is a layer. Larger images show several lines here — one per layer, all downloading in parallel.

4. Digest: sha256:…

   اثر انگشت رمزنگاری‌شدهٔ دقیقاً همین ایمیج. برچسب (tag) ممکن است فردا به ایمیج دیگری اشاره کند، اما این عدد هرگز عوض نمی‌شود. فصل ۱۱ رویش کار می‌کند.

   The cryptographic fingerprint of exactly this image. A tag may point somewhere else tomorrow; this number never changes. Chapter 11 works with it.

5. و بعد برنامه اجرا شد و تمام شد and then the program ran and finished

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

   The container printed its message and its process ended. A container lives exactly as long as its main process. Memorise this one too.

حالا همان دستور را دوباره بزن. این بار پنج خط اول نیست، چون ایمیج دیگر محلی است:

Now run the same command again. This time the first five lines are gone, because the image is local:

docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.

اجرای دوم: وارد یک لینوکس کامل شو

Second run: step inside a whole Linux

این تمرین بیشتر از هر توضیحی مفهوم کانتینر را جا می‌اندازد. با یک دستور، وارد یک سیستم لینوکسی مستقل می‌شوی:

This exercise lands the concept better than any explanation. One command drops you inside a separate Linux system:

docker run -it --rm alpine:3.20 sh

سه سوئیچ اینجا هست که باید بشناسی‌شان:

Three flags here are worth knowing:

حالا داخل کانتینری. این‌ها را امتحان کن:

You are inside the container now. Try these:

/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.20.3
PRETTY_NAME="Alpine Linux v3.20"

/ # ls /
bin    dev    etc    home   lib    media  mnt    opt    proc   root
run    sbin   srv    sys    tmp    usr    var

/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 sh
    7 root      0:00 ps aux

/ # whoami
root

/ # exit

سه چیز در این خروجی باید توجهت را جلب کند.

Three things in that output deserve your attention.

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

First: you have a complete Linux filesystem, even though your own OS may be neither Ubuntu nor Alpine. If you are on Windows, you are standing inside an Alpine Linux right now.

دوم: خروجی ps aux فقط دو پروسه دارد. روی سیستم واقعی تو الان صدها پروسه در حال اجراست، اما این کانتینر آنها را نمی‌بیند. این همان namespace است — بخش هشتم بازش می‌کند.

Second: ps aux shows just two processes. Your real system is running hundreds right now, but this container cannot see them. That is a namespace — section eight unpacks it.

سوم: تو root هستی. داخل کانتینر، پیش‌فرض داکر کاربر روت است. این راحت است و خطرناک — دقیقاً موضوع فصل ۱۳.

Third: you are root. Inside a container, Docker's default user is root. That is convenient and dangerous — precisely the subject of chapter 13.

اجرای سوم: یک وب‌سرور واقعی

Third run: a real web server

حالا کاری کنیم که واقعاً به درد بخورد. یک وب‌سرور Nginx بالا می‌آوریم، بدون اینکه چیزی روی سیستم نصب کنیم:

Now something genuinely useful. We will start an Nginx web server without installing anything on your system:

docker run -d --name web -p 8080:80 nginx:1.27-alpine
4f2a9c1b7e3d5a8f0c6b2d4e9a1f3c7b5d8e0a2c4f6b9d1e3a5c7f9b1d3e5a7c

آن رشتهٔ طولانی شناسهٔ کانتینر است. دو سوئیچ جدید:

That long string is the container ID. Two new flags:

• -d یا --detach: کانتینر را در پس‌زمینه اجرا کن و ترمینال را به من برگردان. بدون این، ترمینالت تا وقتی Nginx زنده است قفل می‌ماند.
• -d or --detach: run in the background and give me my terminal back. Without it, your terminal stays occupied for as long as Nginx runs.
• -p 8080:80: پورت ۸۰۸۰ روی ماشین خودم را به پورت ۸۰ داخل کانتینر وصل کن. ترتیب مهم است و همیشه میزبان:کانتینر است.
• -p 8080:80: connect port 8080 on my machine to port 80 inside the container. The order matters and is always host:container.

ببینیم زنده است:

Let us check that it is alive:

docker ps
CONTAINER ID   IMAGE                COMMAND                  STATUS         PORTS                  NAMES
4f2a9c1b7e3d   nginx:1.27-alpine    "/docker-entrypoint.…"   Up 12 seconds  0.0.0.0:8080->80/tcp   web

ستون PORTS دقیقاً همان نگاشتی است که خواستیم. حالا از سیستم خودت صدایش کن:

The PORTS column is exactly the mapping we asked for. Now call it from your own system:

curl -I http://localhost:8080
HTTP/1.1 200 OK
Server: nginx/1.27.3
Content-Type: text/html
Content-Length: 615
Connection: keep-alive

# همان کار روی ویندوز، بدون curl
Invoke-WebRequest -Uri http://localhost:8080 -Method Head | Select-Object StatusCode

مرورگر را هم باز کن و http://localhost:8080 را ببین. صفحهٔ خوش‌آمد Nginx آنجاست. حالا لاگ‌ها را نگاه کن — درخواست خودت را می‌بینی:

Open a browser at http://localhost:8080 too. The Nginx welcome page is there. Now look at the logs — your own request is in them:

docker logs web
172.17.0.1 - - [08/Sep/2026:09:12:44 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.5.0" "-"
172.17.0.1 - - [08/Sep/2026:09:13:02 +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 …" "-"

# دنبال کردن زنده — مثل tail -f ؛ با Ctrl+C خارج شو
docker logs -f web

و برای اینکه داخل همین کانتینرِ در حال اجرا یک شل باز کنی:

And to open a shell inside that same running container:

docker exec -it web sh
/ # nginx -v
nginx version: nginx/1.27.3
/ # ls /usr/share/nginx/html
50x.html    index.html
/ # exit

و در پایان، تمیزکاری. توجه کن که stop و rm دو کار متفاوت‌اند:

Finally, cleaning up. Note that stop and rm are two different things:

# متوقف کن — کانتینر هست، فقط خاموش است
docker stop web
web

# ps خالی است، اما ps -a هنوز نشانش می‌دهد
docker ps
docker ps -a
CONTAINER ID   IMAGE               STATUS                     NAMES
4f2a9c1b7e3d   nginx:1.27-alpine   Exited (0) 8 seconds ago   web

# دوباره روشنش کن — همان کانتینر، نه یکی جدید
docker start web

# حالا واقعاً حذفش کن
docker stop web
docker rm web
web

و ایمیج‌هایی که تا الان دانلود شده‌اند هنوز روی دیسک‌اند:

And the images downloaded so far are still on disk:

docker images
REPOSITORY    TAG           IMAGE ID       CREATED        SIZE
nginx         1.27-alpine   1ff4bb4faebc   3 weeks ago    52.5MB
alpine        3.20          63b790fccc9f   2 months ago   7.83MB
hello-world   latest        d2c94e258dcb   8 months ago   13.3kB

# داکر روی دیسک چقدر جا گرفته؟
docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          3         0         60.4MB    60.4MB (100%)
Containers      0         0         0B        0B
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

به حجم‌ها نگاه کن: کل Nginx با سیستم‌عامل پایه‌اش حدود ۵۰ مگابایت است. یک ماشین مجازی اوبونتو برای همین کار، چند گیگابایت می‌شد. این همان صرفه‌جویی نمودار بخش سوم است، به عدد.

Look at the sizes: all of Nginx with its base OS is around 50 MB. A Ubuntu VM for the same job would be several gigabytes. That is the saving from the section-three diagram, in numbers.

چرخهٔ عمر یک کانتینرA container's life cycle

کانتینر همیشه در یکی از چند حالت مشخص است. اگر این نمودار را در ذهن داشته باشی، دیگر گیج نمی‌شوی که چرا docker ps کانتینرت را نشان نمی‌دهد ولی اسمش «اشغال» است.

A container is always in one of a few defined states. Keep this diagram in mind and you will stop being puzzled by why docker ps shows nothing yet the name is “taken”.

نکتهٔ کلیدی این است: کانتینر متوقف‌شده هنوز وجود دارد. فضای دیسکش را گرفته، اسمش رزرو است، و لایهٔ نوشتنی‌اش دست‌نخورده باقی مانده. برای همین است که این دستور خطا می‌دهد:

The key point: a stopped container still exists. It occupies disk, reserves its name, and its writable layer is intact. That is why this command fails:

docker run -d --name web -p 8080:80 nginx:1.27-alpine
docker stop web
docker run -d --name web -p 8080:80 nginx:1.27-alpine
docker: Error response from daemon: Conflict. The container name "/web" is
already in use by container "4f2a9c1b7e3d". You have to remove (or rename)
that container to be able to reuse that name.

داکر دقیقاً می‌گوید چه کار کن. یا کانتینر قدیمی را حذف کن، یا دوباره روشنش کن:

Docker tells you exactly what to do. Either delete the old container, or start it again:

راه اول: کانتینر قبلی را روشن کن (همان دادهٔ قبلی سر جایش است)
docker start web

راه دوم: قبلی را حذف کن و از نو بساز (لایهٔ نوشتنی قبلی از بین می‌رود)
docker rm web
docker run -d --name web -p 8080:80 nginx:1.27-alpine

و برای پاک کردن انبوه کانتینرهای متوقف‌شده‌ای که در طول تمرین جمع شده‌اند:

And to clear out the pile of stopped containers you accumulate while practising:

# اول ببین چه چیزی قرار است حذف شود
docker ps -a --filter status=exited

# بعد حذف کن — تأیید می‌خواهد
docker container prune

زیر کاپوت: کانتینر فقط یک پروسه استUnder the hood: a container is just a process

این بخش برای عیب‌یابی است، نه برای حفظ کردن. اگر بدانی کانتینر واقعاً چیست، خطاهای عجیب دیگر عجیب نیستند.

This section is for debugging, not memorisation. Once you know what a container really is, strange errors stop being strange.

حقیقت ساده این است: کانتینر یک پروسهٔ معمولی روی ماشین میزبان است که هسته چند محدودیت رویش گذاشته. نه بیشتر. اگر روی لینوکس کار می‌کنی، همین الان می‌توانی ببینی‌اش:

The plain truth: a container is an ordinary process on the host machine with a few kernel restrictions applied to it. Nothing more. If you are on Linux, you can see it right now:

docker run -d --name web -p 8080:80 nginx:1.27-alpine

# روی خودِ ماشین میزبان، نه داخل کانتینر
ps -ef | grep -m2 nginx
root      284915  284893  0 09:31 ?  00:00:00 nginx: master process nginx -g daemon off;
101       284962  284915  0 09:31 ?  00:00:00 nginx: worker process

آنجاست. یک پروسهٔ کاملاً عادی با یک PID عادی، در فهرست پروسه‌های سیستم خودت. اما داخل کانتینر، همان پروسه خودش را با شمارهٔ 1 می‌بیند:

There it is. A perfectly ordinary process with an ordinary PID, in your own system's process list. But from inside the container, that same process sees itself as number 1:

docker exec web ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 nginx: master process nginx -g daemon off;
   30 nginx     0:00 nginx: worker process
   38 root      0:00 ps -ef

یک پروسه، دو شماره، دو دیدگاه. این هستهٔ کل ماجراست و اسمش namespace (فضای نام) است.

One process, two numbers, two points of view. This is the heart of the whole thing, and it is called a namespace.

دو مکانیزمی که همه‌چیز را می‌سازند

The two mechanisms behind everything

هر سهٔ اینها قابلیت‌های هستهٔ لینوکس هستند، نه اختراع داکر. داکر آنها را بسته‌بندی کرده و پشت چند دستور ساده گذاشته. برای همین است که کانتینر سربار محاسباتی ندارد: چیزی شبیه‌سازی نمی‌شود، فقط هسته چند قانون اضافه اعمال می‌کند.

All three are Linux kernel features, not Docker inventions. Docker packaged them behind a few simple commands. That is why containers carry no compute overhead: nothing is emulated, the kernel simply applies a few extra rules.

و از همین‌جا یک نتیجهٔ امنیتی مهم درمی‌آید: چون هسته مشترک است، اگر کسی از داخل کانتینر بتواند از یک آسیب‌پذیری هسته استفاده کند، به کل ماشین دسترسی دارد. ماشین مجازی این مرز را در سخت‌افزار می‌کشد و شکستنش سخت‌تر است. پس کد نامطمئن دیگران را داخل کانتینر ساده اجرا نکن و فرض نکن ایزوله است.

From which follows an important security consequence: because the kernel is shared, anyone who can exploit a kernel vulnerability from inside a container reaches the whole machine. A VM draws that boundary in hardware and it is harder to break. So do not run other people's untrusted code in a plain container and assume it is isolated.

کجا خراب می‌شودWhere it breaks

پنج خطایی که تقریباً همه در هفتهٔ اول می‌بینند. پیام خطا را دقیق آورده‌ایم تا وقتی همان را دیدی، بشناسی‌اش.

The five errors nearly everyone meets in their first week. The exact messages are here so you recognise them when they show up.

مرجع سریع این فصلQuick reference

همهٔ دستورهایی که در این فصل دیدی، یک‌جا. این جدول را نگه دار؛ ۹۰ درصد کار روزمره همین‌هاست.

Every command from this chapter in one place. Keep this table; it covers 90% of daily work.

تمرین‌هاExercises

هشت تمرین، از ساده به سخت. همه پاسخ کامل دارند — اما اول خودت انجامش بده. بعد از هر تمرین، تیک «انجام شد» را بزن تا نوار پیشرفت جلو برود.

Eight exercises, easy to hard. All have full solutions — but do them yourself first. Tick “Done” after each one to move the progress bar.

# ۱) سلامت CLI
docker --version

# ۲) سلامت سرویس پس‌زمینه — این مهم‌ترین بخش است
docker info --format '{{.ServerVersion}}'

# ۳) اگر ایمیج را از قبل داری، حذفش کن تا خروجی کامل را ببینی
docker rmi hello-world

# ۴) اجرا
docker run hello-world

docker run -it --rm ubuntu:24.04 bash

root@8f21c4d90b7e:/# cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"

root@8f21c4d90b7e:/# echo "سلام از داخل کانتینر" > /tmp/note.txt
root@8f21c4d90b7e:/# cat /tmp/note.txt
سلام از داخل کانتینر

root@8f21c4d90b7e:/# exit

# هیچ کانتینر اوبونتویی باقی نمانده است
docker ps -a --filter ancestor=ubuntu:24.04
CONTAINER ID   IMAGE   COMMAND   CREATED   STATUS   PORTS   NAMES

# ۱) بالا آوردن
docker run -d --name lab-web -p 9090:80 nginx:1.27-alpine

# ۲) بررسی — سوئیچ -I فقط هدر را می‌گیرد
curl -I http://localhost:9090
HTTP/1.1 200 OK
Server: nginx/1.27.3

# ۳) لاگ
docker logs lab-web
172.17.0.1 - - [08/Sep/2026:09:44:10 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.5.0" "-"

# ۴) تمیزکاری — هر دو دستور لازم است
docker stop lab-web
docker rm lab-web

# ۵) تأیید
docker ps -a --filter name=lab-web

docker run -d --name w1 -p 8081:80 nginx:1.27-alpine
docker run -d --name w2 -p 8082:80 nginx:1.27-alpine
docker run -d --name w3 -p 8083:80 nginx:1.27-alpine

curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8081
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8082
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8083
200
200
200

docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          1         1         52.5MB    0B (0%)
Containers      3         3         3.27kB    0B (0%)
Local Volumes   0         0         0B        0B

# تمیزکاری — چند کانتینر را می‌شود با هم داد
docker rm -f w1 w2 w3

# ۱) کانتینری که زنده می‌ماند — بدون --rm
docker run -d --name box alpine:3.20 sleep infinity

# ۲) فایل بنویس
docker exec box sh -c 'echo "داده مهم" > /data.txt'
docker exec box cat /data.txt
داده مهم

# ۳) توقف و روشن کردن دوباره
docker stop box
docker start box
docker exec box cat /data.txt
داده مهم        ← فایل سر جایش است

# ۴) حالا حذف کامل و ساخت یک کانتینر تازه از همان ایمیج
docker rm -f box
docker run -d --name box alpine:3.20 sleep infinity
docker exec box cat /data.txt
cat: can't open '/data.txt': No such file or directory

docker rm -f box

docker pull python:3.12-alpine
docker pull node:22-alpine

# اولین لایهٔ هر ایمیج را جدا بگیر
docker image inspect python:3.12-alpine --format '{{index .RootFS.Layers 0}}'
sha256:4a2c4e35d0e5a2c8b6f9d1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3

docker image inspect node:22-alpine --format '{{index .RootFS.Layers 0}}'
sha256:4a2c4e35d0e5a2c8b6f9d1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3

↑ دقیقاً یکی — هر دو روی همان آلپاین ساخته شده‌اند

docker images --filter reference=python --filter reference=node
REPOSITORY   TAG           IMAGE ID       SIZE
python       3.12-alpine   f4a1c9e02b73   58.1MB
node         22-alpine     8b3d7f1c4e90   152MB

# مجموع سادهٔ ستون SIZE ≈ ۲۱۰ مگابایت — اما روی دیسک:
docker system df
TYPE      TOTAL   ACTIVE   SIZE      RECLAIMABLE
Images    2       0        202MB     202MB (100%)

docker run -d --name probe alpine:3.20 sleep infinity

# ۱) شناسهٔ پروسه از دید میزبان
docker inspect probe --format '{{.State.Pid}}'
291744

# ۲) همان پروسه در فهرست پروسه‌های میزبان
ps -p 291744 -o pid,ppid,cmd
    PID    PPID CMD
 291744  291721 sleep infinity

# ۳) همان پروسه از دید داخل کانتینر
docker exec probe ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 sleep infinity
   14 root      0:00 ps -ef

docker rm -f probe

# بخش دوم: سقف حافظه ۲۰ مگابایت، و تلاش برای گرفتن ۲۰۰ مگابایت
docker run --name hog --memory 20m alpine:3.20 \
  sh -c 'dd if=/dev/zero of=/dev/shm/fill bs=1M count=200'

# کد خروج را بخوان
docker inspect hog --format '{{.State.ExitCode}} {{.State.OOMKilled}}'
137 true

docker rm hog

# ۱) صفحهٔ خودت را بساز
cat > index.html <<'HTML'
<!doctype html>
<html lang="fa" dir="rtl"><meta charset="utf-8">
<title>اولین کانتینر من</title>
<h1>این صفحه از داخل یک کانتینر می‌آید</h1>
HTML

# ۲) کانتینر را بالا بیاور
docker run -d --name myweb -p 8080:80 nginx:1.27-alpine

# ۳) فایل را داخلش کپی کن
docker cp index.html myweb:/usr/share/nginx/html/index.html

# ۴) بررسی
curl -s http://localhost:8080 | head -n 3
<!doctype html>
<html lang="fa" dir="rtl"><meta charset="utf-8">
<title>اولین کانتینر من</title>

docker diff myweb
C /usr/share/nginx/html
C /usr/share/nginx/html/index.html

# C یعنی Changed ، A یعنی Added ، D یعنی Deleted

docker rm -f myweb

پروژهٔ پایان فصلEnd-of-chapter project

# ۲) بالا آوردن و قرار دادن صفحه
docker run -d --name ch01-site -p 8080:80 nginx:1.27-alpine
docker cp site/index.html ch01-site:/usr/share/nginx/html/index.html

# ۳) ثبت رفتار
curl -s -o /dev/null http://localhost:8080
curl -s -o /dev/null http://localhost:8080/nothing
docker logs ch01-site
172.17.0.1 - - [...] "GET / HTTP/1.1" 200 412 "-" "curl/8.5.0" "-"
172.17.0.1 - - [...] "GET /nothing HTTP/1.1" 404 153 "-" "curl/8.5.0" "-"
2026/09/08 10:02:31 [error] 30#30: *3 open() "/usr/share/nginx/html/nothing"
  failed (2: No such file or directory), client: 172.17.0.1, request: "GET /nothing HTTP/1.1"

# ۴) آزمون مقاومت
docker stop ch01-site
docker start ch01-site
curl -s http://localhost:8080 | head -n 1
<!doctype html>        ← صفحه هست

docker rm -f ch01-site
docker run -d --name ch01-site -p 8080:80 nginx:1.27-alpine
curl -s http://localhost:8080 | grep -o '<title>.*</title>'
<title>Welcome to nginx!</title>        ← صفحهٔ خودت رفت

docker rm -f ch01-site