hello-world کجا رفت؟Run hello-world slowly this time

در فصل قبل hello-world را اجرا کردیم و پیامش را دیدیم. حالا یک سؤال ساده: بعد از چاپ آن پیام، container هنوز زنده است یا تمام شده؟ و اگر تمام شده، آیا پاک هم شده؟ بیایید به‌جای جواب حفظی، خودمان ببینیم.

In the previous chapter, docker run hello-world was a health check. Now we use the same command as a lifecycle experiment. Predict first: after the message prints, is the container still Running? If not, has it disappeared completely?

docker run hello-world

docker ps
docker ps -a --filter ancestor=hello-world

Hello from Docker!
...

# docker ps
CONTAINER ID   IMAGE   COMMAND   CREATED   STATUS   PORTS   NAMES

# docker ps -a
CONTAINER ID   IMAGE         STATUS                      NAMES
a1b2c3d4e5f6   hello-world   Exited (0) 4 seconds ago    lucid_morse

اگر docker ps چیزی نشان نداد، عجله نکن و نگو «پس هیچ containerی ساخته نشد». این دستور فقط containerهای در حال اجرا را نشان می‌دهد. با docker ps -a می‌بینی همان container هنوز وجود دارد، فقط پردازشش تمام شده و وضعیتش Exited است.

docker ps lists only Running containers, so an empty table does not mean “no container was created.” docker ps -a reveals the container identity and history: it was created, its process ran, exited with code zero, and the state became Exited.

docker run پشت صحنه چه کارهایی می‌کند؟docker run looks like one action, but several stages happen underneath

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

docker run IMAGE is one command from the user’s perspective. Conceptually, the Engine resolves the image, pulls if policy requires and the image is absent, creates container identity/configuration, starts the main process, and in foreground mode attaches its streams to the CLI.

برای اینکه این دو مرحله را ببینی، یک بار میان‌بُر را کنار بگذار:

To make those stages visible, temporarily avoid the shortcut:

docker create --name created-demo hello-world
docker ps -a --filter name=created-demo

docker start -a created-demo
docker ps -a --filter name=created-demo

docker rm created-demo

بعد از create شناسه و تنظیمات وجود دارد ولی پردازش هنوز شروع نشده و وضعیت معمولاً Created است. start -a همان container را اجرا می‌کند؛ container دوم نمی‌سازد. -a خروجی را اتصال می‌کند تا hello-world را ببینی.

After create, identity and configuration exist but the process has not started, so state is normally Created. start -a runs that same container rather than creating another one. -a attaches output so you can observe hello-world.

توقف container با حذف‌شدنش یکی نیستRead lifecycle from state, not guesswork

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

docker run -d --name web nginx:alpine
docker ps --filter name=web

docker stop web
docker ps
docker ps -a --filter name=web

docker start web
docker restart web

docker inspect web --format \
'status={{.State.Status}} running={{.State.Running}} exit={{.State.ExitCode}}'

هر دستور یک وضعیت transition مشخص دارد. stop پردازش اصلی را متوقف می‌کند ولی مورد را نگه می‌دارد. start همان شناسه را دوباره راه می‌اندازد. restart convenience operation است؛ container جدیدی نمی‌سازد.

Each command has a specific state effect. stop stops the main process while keeping the object. start runs the same identity again. restart is a convenience operation; it does not create a new container.

چرا یک بار ترمینال گیر می‌کند و یک بار آزاد می‌ماند؟Foreground and detached: the difference is CLI attachment, not whether the process is real

برای دیدن تفاوت، یک سرویس واقعی‌تر لازم داریم. Nginx را اول بدون -d اجرا می‌کنیم. این‌بار ترمینال آزاد نمی‌شود، چون CLI هنوز به اجرای container وصل است. بعد همان مثال را جداشده اجرا می‌کنیم تا فرقشان را با چشم ببینیم.

We need a long-running service, so use the official nginx:alpine image. First run it without -d:

docker run --name foreground-web nginx:alpine
# observe startup output
# press Ctrl+C

docker ps
docker ps -a --filter name=foreground-web

وقتی در حالت متصل Ctrl+C می‌زنی، وقفه به پردازش اصلی می‌رسد و در این مثال Nginx متوقف می‌شود. مهم است این را با docker stop یکی نگیری؛ چیزی که می‌بینی نتیجهٔ نحوهٔ اتصال ترمینال و مدیریت سیگنال توسط همان پردازش است.

In attached mode, the CLI is connected to the container process streams, so the terminal remains occupied. When you press Ctrl+C, an interrupt/signal travels through the attachment path to the main process, and in this scenario Nginx stops. Do not simplify this into “Docker always ran stop”; exact behavior depends on attachment and the process’s signal handling.

docker run -d --name web nginx:alpine
docker ps --filter name=web

-d پردازش را «background Linux پردازش معمولی روی شل تو» نمی‌کند؛ container را راه‌اندازی می‌کند و CLI بعد از گرفتن شناسه برمی‌گردد، درحالی‌که Engine چرخهٔ عمر پردازش را ادامه می‌دهد.

-d does not turn the workload into an ordinary background process of your shell. It starts the container and returns control to the CLI while the Engine continues managing the process lifecycle.

name collision یک مشکل برنامه نیست

A name collision is not an application failure

docker run -d --name web nginx:alpine

docker: Error response from daemon:
Conflict. The container name "/web" is already in use.

docker ps -a --filter name=web

Engine حتی به مرحلهٔ راه‌اندازی Nginx جدید نرسیده؛ شناسه موردنظر از قبل اشغال است. بنابراین debug کردن image یا پورت اشتباه است. مورد موجود را پیدا کن و تصمیم بگیر استفادهٔ دوباره، rename یا remove شود.

The Engine never reached the point of starting a new Nginx process; the requested identity is already taken. Debugging the image or port is therefore the wrong direction. Find the existing object and decide whether to reuse, rename, or remove it.

اگر برنامه چیزی برای گفتن داشته باشد، کجا دنبالش بگردیم؟Logs: what did the process write to stdout and stderr?

فرض کن container بالا آمده ولی نمی‌دانی داخلش چه می‌گذرد. اولین جای خوب برای سرک‌کشیدن معمولاً لاگ‌هاست. برنامه‌های containerized معمولاً پیام‌هایشان را روی stdout و stderr می‌نویسند و Docker، بسته به تنظیم ثبت لاگ، می‌تواند آن‌ها را با docker logs در اختیارت بگذارد.

Many containerized applications write normal logs to stdout and errors to stderr. Docker captures those streams through the container’s logging configuration, and with drivers that support reading, docker logs returns them. It is not shell history; it is process/application output.

docker logs web
docker logs --tail 20 web
docker logs -f web

docker logs -f یعنی «از این لحظه به بعد هم پیام‌های جدید را نشانم بده». اگر روی همین دستور Ctrl+C بزنی، فقط دنبال‌کردن لاگ را قطع می‌کنی. container باید همچنان در حال اجرا باشد؛ با docker ps خودت بررسی‌اش کن.

docker logs -f is not just a snapshot; it follows new log output. Pressing Ctrl+C on the logs command stops the following client, not the container. Verify that claim with docker ps afterward.

یک درخواست بفرست تا لاگ معنی پیدا کندGenerate a real request so logs are not just decorative text

دیدن چند خط لاگ آماده خیلی آموزشی نیست. بهتر است خودمان یک درخواست بسازیم و بعد همان درخواست را در لاگ پیدا کنیم. برای این کار Nginx را روی یک پورت از سیستم خودمان در دسترس قرار می‌دهیم و با curl به آن درخواست می‌زنیم.

To generate a request log, run Nginx with a published port. We use the syntax now, then unpack its meaning carefully in the ports section.

docker rm -f web 2>/dev/null || true
docker run -d --name web -p 8080:80 nginx:alpine

curl -I http://localhost:8080
docker logs --tail 5 web

127.0.0.1 - - [23/Sep/2026:10:15:22 +0000]
"HEAD / HTTP/1.1" 200 0 "-" "curl/8.x" "-"

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

Now the log is tied to a real observation: method, path, and status code correspond to the request you sent. If the browser fails and no new request log appears, the problem may be before the application receives the request—for example at port publishing.

docker exec یعنی یک پردازش تازه در همان containerdocker exec: you are not entering a “new container”; you are starting another process

وقتی می‌گویی «وارد container شدم»، از نظر فنی اتفاق دقیق‌تری افتاده: docker exec یک دستور تازه را داخل همان container در حال اجرا راه می‌اندازد. container دوم ساخته نمی‌شود و image هم تغییر نمی‌کند. فقط یک پردازش دیگر کنار پردازش اصلی اجرا می‌شود.

docker exec runs another command inside an existing Running container. It creates neither a new image nor a second container. The exec process exists only while the container’s primary process is running.

docker exec web nginx -v
docker exec web pwd
docker exec -it web sh

docker stop web
docker exec web sh

Error response from daemon:
container ... is not running

این خطا خودش مدل را تأیید می‌کند: exec «محیط ذخیره‌شده‌ای که هر وقت خواستیم باز می‌کنیم» نیست؛ دستور جدیدی است که برای اجرا به container Running نیاز دارد.

This error reinforces the model: exec is not “opening a saved environment at any time”; it starts a new command and therefore requires the container to be Running.

چرا زنده‌بودن پردازش اصلی، عمر container را تعیین می‌کند؟Why does the main process matter so much? Container lifecycle is tied to it

hello-world سریع تمام شد ولی Nginx می‌تواند ساعت‌ها Running بماند. تفاوت اصلی در این است که پردازش اصلی آن‌ها چه می‌کند. تا وقتی پردازش اصلی زنده است، container هم Running می‌ماند؛ وقتی آن پردازش تمام شود، container از حالت Running خارج می‌شود.

You do not need every namespace or init-system detail yet. One practical rule is enough: a container’s lifecycle revolves around its primary process. When that process exits, the container leaves Running state.

docker start web
docker top web

UID   PID    PPID   C   STIME   TTY   TIME      CMD
root  18432  18410  0   10:24   ?     00:00:00  nginx: master process nginx -g daemon off;
101   18471  18432  0   10:24   ?     00:00:00  nginx: worker process

docker top processهای container را از دید Docker/سیستم میزبان ابزارها نشان می‌دهد؛ PIDهایی که می‌بینی الزاماً همان شماره‌هایی نیستند که پردازش داخل فضای نام PID خودش می‌بیند. نکتهٔ این فصل شماره PID نیست؛ رابطهٔ پردازش اصلی و Running وضعیت است.

docker top shows container processes through Docker/host-side tooling; the host PIDs shown are not necessarily the same numbers a process sees inside its own PID namespace. The lesson here is not PID numbering; it is the relationship between the primary process and Running state.

docker run --name one-shot hello-world
docker ps -a --filter name=one-shot

docker run -d --name long-lived nginx:alpine
docker ps --filter name=long-lived

hello-world یک کار کوتاه دارد؛ پردازش تمام می‌شود و container Exited می‌شود. Nginx master پردازش زنده می‌ماند، پس container Running می‌ماند. Docker «خودش تصمیم نگرفته» یکی را ببندد و دیگری را باز نگه دارد؛ چرخهٔ عمر پردازش تفاوت را ساخته است.

hello-world performs a short task; the process ends and the container becomes Exited. Nginx keeps its master process alive, so the container remains Running. Docker did not arbitrarily choose one to keep alive; process lifecycle created the difference.

کد خروج یک سرنخ است، نه جواب نهاییAn exit code is evidence, not a complete diagnosis

اگر container بسته شد، کد خروج یکی از اولین چیزهایی است که نگاه می‌کنیم. صفر معمولاً یعنی خود پردازش کارش را موفق تمام کرده و عدد غیرصفر یعنی مشکلی گزارش شده. اما خود عدد علت را توضیح نمی‌دهد؛ برای فهمیدن «چرا» باید لاگ و دستور اجرا را هم ببینیم.

Exit code zero usually means the process reported successful completion by convention; non-zero indicates some failure or abnormal result. The number alone rarely explains why. Read it alongside the command, logs, and execution context.

docker run --name exit0 alpine sh -c 'exit 0'
docker run --name exit7 alpine sh -c 'echo broken >&2; exit 7'

docker inspect exit0 --format '{{.State.Status}} {{.State.ExitCode}}'
docker inspect exit7 --format '{{.State.Status}} {{.State.ExitCode}}'
docker logs exit7

exited 0
exited 7

broken

برای exit7، عدد 7 می‌گوید پردازش موفق تمام نشده، ولی متن broken context بیشتری می‌دهد. در برنامه واقعی هم همین مدل را حفظ کن: وضعیت → کد خروج → لاگ‌ها → دستور/تنظیمات.

For exit7, the number tells you the process did not report success, while broken gives more context. Use the same model for real apps: state → exit code → logs → command/configuration.

قبل از پاک‌کردن container، چیزی برای بررسی باقی بگذارRemove discards the object; collect useful evidence first

docker stop web
docker logs --tail 20 web
docker inspect web --format '{{json .State}}'
docker rm web

وقتی container خراب است، اولین واکنش خیلی‌ها این است که پاکش کنند و از نو بسازند. گاهی جواب می‌دهد، ولی یک مشکل دارد: همان چیزی را که می‌توانستی بررسی کنی از بین می‌بری. بهتر است اول وضعیت، لاگ و تنظیمات لازم را برداری و بعد سراغ پاک‌سازی بروی.

During debugging, removing too early can destroy the very object you wanted to inspect. Capture the required state/log/configuration first, then clean up.

docker rm -f دقیقاً چه shortcutی است؟

What exactly does docker rm -f shortcut?

-f برای container Running یعنی Docker آن را به‌اجبار متوقف/kill می‌کند و سپس مورد را remove می‌کند. برای آزمایشگاه پاک‌سازی مفید است، ولی نباید پیش‌فرض عیب‌یابی عادت باشد.

For a Running container, -f means Docker forcibly stops/kills it and then removes the object. It is useful for lab cleanup, but it should not become the default debugging reflex.

docker rm -f long-lived

container روشن است؛ چرا localhost هنوز جواب نمی‌دهد؟The container is Running; why can’t the browser reach it?

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

Running only tells you the primary process is alive. It proves nothing yet about the network path from host to application. For that path, separate two numbers: the host port and the container port.

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

docker ps --filter name=web
curl -I http://localhost:8080

PORTS
0.0.0.0:8080->80/tcp, [::]:8080->80/tcp

این خروجی می‌گوید پورت سیستم میزبان 8080 انتشار شده و به پورت 80 داخل container map می‌شود. اگر دستور را اشتباه -p 80:8080 بنویسی، مفهوم را برعکس کرده‌ای: سیستم میزبان:80 → container:8080، درحالی‌که Nginx پیش‌فرض روی 80 گوش می‌دهد.

This output says host port 8080 is published and mapped to port 80 in the container. If you accidentally use -p 80:8080, you reverse the model: host:80 → container:8080, while default Nginx listens on 80.

سه خرابی شبیه هم که راه‌حل یکسان ندارندThree port failures that look similar but need different diagnoses

docker run -d --name web2 -p 8080:80 nginx:alpine

# representative error
Bind for 0.0.0.0:8080 failed: port is already allocated

وقتی docker ps کافی نیست، سؤال دقیق‌تر بپرسdocker inspect: when summary tables are not enough

docker ps برای نگاه سریع عالی است، ولی گاهی سؤال دقیق‌تری داری: این container دقیقاً با چه commandی ساخته شده؟ کد خروجش چند بوده؟ چه پورتی map شده؟ آن‌وقت docker inspect به درد می‌خورد. لازم نیست همهٔ JSON را بخوانی؛ فقط همان چیزی را بپرس که لازم داری.

docker ps is excellent for an overview, but inspect gives lower-level object configuration and state. You do not need to read the entire JSON every time; use --format to ask a focused question.

docker inspect web --format \
'name={{.Name}} status={{.State.Status}} exit={{.State.ExitCode}}'

docker inspect web --format \
'image={{.Config.Image}} cmd={{json .Config.Cmd}}'

docker inspect web --format \
'ports={{json .NetworkSettings.Ports}}'

قدرت inspect در این نیست که «اطلاعات زیاد» دارد؛ در این است که احتمال را با فیلد مشخص امتحان می‌کنی. اگر سؤال پورت است، لازم نیست environment variableهای بی‌ربط را بخوانی.

The power of inspect is not merely “lots of information”; it lets you test a hypothesis with specific fields. If your question is about port bindings, there is little value in scanning unrelated environment variables.

وقتی container کار نمی‌کند، این مسیر را قدم‌به‌قدم بروDebugging workflow: from object existence to the application itself

فرض کن فقط می‌دانیم «سایت باز نمی‌شود». اگر مستقیم port، image و Dockerfile را با هم دست‌کاری کنیم، هر بار چند چیز عوض می‌شود و فهمیدن علت سخت‌تر می‌شود. بهتر است از ساده‌ترین سؤال شروع کنیم و هر مرحله فقط یک چیز را روشن کند.

When someone says “the container does not work,” do not jump to the end of the chain. Do not memorize this as a ritual; understand the logic: each question establishes a prerequisite for the next.

1. Object: docker ps -a --filter name=web
2. State: status=_____ exit=_____
3. Logs: last meaningful line = _____
4. Process/config: command=_____ ports=_____
5. Request: curl result = _____
6. Diagnosis: _____
7. Fix + verification: _____

از جدول docker ps بیشتر از اسم container بخوانRead docker ps as a diagnostic table, not just a container list

وقتی تازه Docker یاد می‌گیری، معمولاً فقط ستون NAMES را نگاه می‌کنی. اما همین جدول کوچک خیلی بیشتر می‌گوید: container از چه imageای آمده، الآن در چه وضعیتی است، چه commandی دارد و آیا پورتی از آن روی سیستم میزبان باز شده یا نه.

When you are new to Docker, your eyes often go straight to NAME. But this small table answers several questions at once: which image created the container, what command it uses, whether it is Running or Exited, whether ports are published, and what human-friendly identity it has.

docker ps -a

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS                     PORTS                  NAMES
a1b2c3d4e5f6   nginx:alpine   "/docker-entrypoint…"   2 minutes ago    Up 2 minutes               0.0.0.0:8080->80/tcp   web
c7d8e9f0a1b2   hello-world    "/hello"                 8 minutes ago    Exited (0) 8 minutes ago                          one-shot

در ردیف اول، Up 2 minutes می‌گوید پردازش اصلی هنوز زنده است؛ ستون PORTS یک نگاشت سیستم میزبان را نشان می‌دهد. در ردیف دوم، Exited (0) می‌گوید پردازش تمام شده و کد خروج صفر داشته. همین دو ردیف نشان می‌دهند «container وجود دارد» و «container Running است» دو سؤال جدا هستند.

In the first row, Up 2 minutes says the main process is still alive and PORTS shows a host mapping. In the second, Exited (0) says the process ended with exit code zero. These two rows make the distinction clear: “the container exists” and “the container is Running” are separate questions.

ستون دستور هم سرنخ است، نه همیشه کل حقیقت. برای دستور/تنظیمات دقیق‌تر از docker inspect استفاده کن. جدول ps برای triage سریع عالی است؛ inspect برای سؤال دقیق‌تر.

The COMMAND column is a clue, not always the full truth. Use docker inspect for exact command/configuration. docker ps is excellent for quick triage; inspect answers focused questions.

وقتی docker stop می‌زنی، Docker چطور فرصت خاموش‌شدن می‌دهد؟Stop, signals, and kill: why the main process is not just theory

توقف خوب این نیست که پردازش را همان لحظه نابود کنیم. docker stop اول به پردازش اصلی فرصت می‌دهد خودش مرتب کارش را جمع کند. اگر در زمان تعیین‌شده خارج نشود، Docker سراغ توقف اجباری می‌رود. فعلاً همین مدل برایمان کافی است.

docker stop attempts a controlled shutdown: a stop signal reaches the primary process and Docker waits for graceful exit for a period; if the process does not exit, forced termination eventually follows. You do not need every image-specific signal detail yet, but you should distinguish “request shutdown” from “remove the object.”

docker run -d --name signal-demo nginx:alpine

docker inspect signal-demo --format \
'status={{.State.Status}} pid={{.State.Pid}}'

docker stop signal-demo

docker inspect signal-demo --format \
'status={{.State.Status}} exit={{.State.ExitCode}} finished={{.State.FinishedAt}}'

بعد از توقف، مورد هنوز برای inspect و لاگ‌ها وجود دارد. این دقیقاً دلیل خوبی است که در مشکل واقعی واقعی اول توقف/لاگ/inspect را از remove جدا نگه داری. docker kill ابزار دیگری است و برای این فصل لازم نیست آن را به پیش‌فرض خاموش‌کردن تبدیل کنی.

After stop, the object still exists for inspect and logs. That is exactly why, during a real incident, it helps to keep stop/log/inspect separate from removal. docker kill is another tool, but this chapter does not treat it as a default shutdown strategy.

یک container، چند پردازش؛ exec را با چشم ببینObserve exec in the process list: one container, multiple processes

این جمله که «exec یک پردازش جدید می‌سازد» ممکن است خشک به نظر برسد. پس بیایید واقعاً یک پردازش کوتاه sleep داخل همان container راه بیندازیم و هم‌زمان با docker top ببینیم کنار پردازش‌های Nginx ظاهر می‌شود.

The sentence “exec starts a new process inside an existing container” is easy to forget if it stays abstract. Make that process observable.

docker start web
docker top web

docker exec web sh -c 'sleep 30' &

docker top web

# representative extra process
UID   PID     PPID   ...   CMD
root  18432   ...          nginx: master process nginx -g daemon off;
101   18471   18432        nginx: worker process
root  19102   ...          sleep 30

container جدیدی ساخته نشد؛ NAME همان web است. فقط یک پردازش موقت دیگر کنار processهای Nginx دیده می‌شود. بعد از ۳۰ ثانیه sleep تمام می‌شود ولی container هنوز Running است، چون پردازش اصلی Nginx زنده است.

No new container was created; the NAME is still web. A temporary process appears beside the Nginx processes. After thirty seconds, sleep exits while the container remains Running because the Nginx primary process is still alive.

یک نمونهٔ واقعی: container بالا است، ولی سایت باز نمی‌شودCase study: “the container is Up but localhost does not respond”

این سناریو زیاد پیش می‌آید: docker ps می‌گوید container بالا است، اما localhost جواب نمی‌دهد. وسوسه‌برانگیز است که فوری پورت را عوض کنیم. این‌بار این کار را نمی‌کنیم؛ از اول مسیر را می‌خوانیم و در هر مرحله فقط یک احتمال را کنار می‌گذاریم.

This is one of the best scenarios for practicing diagnostic order because it is tempting to start changing ports immediately. Instead, walk the chain and let each step answer one question.

docker ps -a --filter name=web

NAMES   STATUS         PORTS
web     Up 3 minutes   0.0.0.0:8080->80/tcp

مورد وجود دارد، پردازش اصلی هنوز Up است و نگاشت ظاهراً 8080→80 است. پس «container اصلاً راه‌اندازی نشده» و «پورت انتشار نشده» فعلاً hypothesisهای ضعیف‌تری هستند.

The object exists, the primary process remains Up, and the mapping appears to be 8080→80. “The container never started” and “no port was published” are now weaker hypotheses.

docker logs --tail 20 web
docker top web

اگر لاگ‌ها راه‌اندازی عادی Nginx را نشان دهند و پردازش list master/worker را داشته باشد، برنامه چرخهٔ عمر هم معقول است. حالا درخواست واقعی می‌فرستیم.

If logs show normal Nginx startup and the process list contains master/worker processes, application lifecycle looks plausible. Now send a real request.

curl -v http://localhost:8080/

اگر connection refused شد ولی PORTS درست به نظر می‌رسد، inspect bindings و سیستم میزبان-side conflict/firewall را بررسی می‌کنی. اگر connection برقرار شد ولی HTTP خطا گرفتی، درخواست به برنامه رسیده و مسئله یک لایه جلوتر است. اگر درخواست لاگ جدید در Nginx ظاهر شد، می‌دانی مسیر شبکه تا برنامه طی شده.

If you get connection refused while PORTS looks correct, inspect bindings and possible host-side conflict/firewall behavior. If the connection succeeds but HTTP returns an application error, traffic reached a later layer. If a new Nginx request log appears, you know the network path reached the application.

نکتهٔ اصلی این case study دستور خاص نیست؛ ترتیب کم‌کردن ambiguity است. هر مشاهده باید تعداد hypothesisها را کمتر کند.

The main lesson is not any particular command; it is reducing ambiguity in order. Every observation should eliminate hypotheses.

به‌جای غرق‌شدن در JSON، از inspect سؤال مشخص بپرسTurn inspect into questions instead of dumping thousands of JSON lines

خروجی کامل docker inspect می‌تواند خیلی طولانی باشد. اگر از قبل ندانی دنبال چه هستی، بین ده‌ها فیلد گم می‌شوی. بهتر است قبل از دستور، سؤال را بنویسی: «وضعیت چیست؟ دستور چیست؟ پورت‌ها چطور map شده‌اند؟» بعد فقط همان فیلد را بگیری.

When a container misbehaves, raw docker inspect NAME can return so much data that the useful fact disappears. Write the question before the command.

وقتی پاسخ سؤال اول Exited است، سؤال پورت معمولاً اولویت ندارد. وقتی Running و لاگ‌ها سالم‌اند، پورت/تنظیمات ارزش بررسی پیدا می‌کند. این یعنی inspect فقط ابزار نمایش نیست؛ بخشی از ترتیب استدلال است.

If the first answer is Exited, port configuration is usually not the first priority. If the container is Running and logs look healthy, port/configuration becomes more relevant. Inspect is not just a display tool; it participates in diagnostic reasoning.

۱۸ تمرین؛ این بار از روی رفتار container جواب بده18 exercises: reason about state instead of memorizing commands

تمرین‌های آخر عمداً کمی شبیه مسئله‌های واقعی‌ترند. قبل از بازکردن پاسخ، برای خودت بگو الآن چه چیزی را می‌دانم، چه چیزی را هنوز نمی‌دانم و کدام دستور می‌تواند سؤال بعدی را جواب بدهد.

The final third should not become shallower than the opening. The later scenarios deliberately combine multiple pieces of evidence. Before revealing an answer, ask, “what do I still not know?”

آزمایشگاه: یک container را اجرا کن، خرابش کن و خودت پیدایش کنLab: run a web container, break it, and repair it without random commands

در پایان یک گزارش کوتاه و قابل‌فهم تحویل بدهLab handoff: produce a short incident report, not scattered screenshots

گزارش خوب لازم نیست رسمی و طولانی باشد. کافی است نفر بعدی بفهمد container در چه وضعیتی بود، لاگ چه می‌گفت، پورت چطور map شده بود، چه چیزی را تغییر دادی و با چه آزمایشی مطمئن شدی مشکل حل شده است.

If the report ends with “after a few restarts it worked,” diagnosis is still incomplete. If you can connect symptom, observation, hypothesis, fix, and verification, even a small failure becomes reusable experience for later chapters.

مرجع سریعQuick reference and official sources

docker run IMAGE
docker run -d --name NAME IMAGE
docker create --name NAME IMAGE
docker start NAME
docker stop NAME
docker restart NAME
docker rm NAME
docker rm -f NAME

docker ps
docker ps -a
docker logs NAME
docker logs -f NAME
docker exec -it NAME sh
docker top NAME
docker inspect NAME
docker run -p HOST:CONTAINER IMAGE