اگر برنامه مال خودت باشد، Docker از کجا بداند چه بسازد؟From “ready-made image” to “my own application”

فصل قبل با nginx:alpine راحت بود: image آماده بود و ما فقط اجراش می‌کردیم. حالا فرض کن یک برنامهٔ ساده نوشته‌ای و می‌خواهی آن را برای همکارت بفرستی. گفتن «Node نصب کن، بعد این دستورها را بزن» دوباره ما را به همان درد فصل اول برمی‌گرداند. اینجاست که Dockerfile وارد داستان می‌شود.

In the previous chapter we worked with nginx:alpine. The image already existed; you only ran it, inspected logs, entered the container, and published a port. The next question is more important: if the application is yours, what do you give Docker so it can build the same environment every time?

فرض کن server.js روی لپ‌تاپت با npm start اجرا می‌شود. برای ساختن همان محیط روی سیستم دیگر، فقط خود فایل کافی نیست. باید نسخهٔ Node، وابستگی‌ها، پوشهٔ کاری و دستور شروع برنامه هم معلوم باشد. Dockerfile همین تصمیم‌ها را کنار هم و قابل‌تکرار ثبت می‌کند.

Suppose you have a server.js that runs on your laptop with npm start. That sentence still leaves several questions unanswered for a teammate: which Node version, how dependencies are installed, which directory the app runs from, which files belong in the environment, and which process should become the container’s main process.

Dockerfile جواب قابل‌نسخه‌بندیِ همین سؤال‌هاست. خود Dockerfile image نیست؛ یک دستور ساخت است. docker build این دستور ساخت را با ورودی‌هایش اجرا می‌کند و یک image می‌سازد. بعداً docker run از آن image یک container تازه می‌سازد. اگر این سه واژه را قاطی نکنی، نصف خطاهای این فصل از همان اول قابل‌فهم می‌شوند.

A Dockerfile is the version-controlled answer to those questions. The Dockerfile is not the image; it is a recipe. docker build executes that recipe with its inputs and produces an image. Later, docker run creates a fresh container from that image. Keeping those three objects separate makes most failures in this chapter much easier to reason about.

یک برنامهٔ خیلی کوچک می‌سازیم تا تمرکز روی Docker بماندA tiny app that keeps the focus on Docker

برای این فصل به پروژهٔ شلوغ نیاز نداریم. یک سرور HTTP کوچک کافی است: وقتی بالا آمد یک پیام می‌دهد، روی پورت مشخصی گوش می‌کند و هر درخواست را در لاگ می‌نویسد. همین سه رفتار برای تمام آزمایش‌های فصل کافی‌اند.

We do not need a large framework for this lesson. A tiny HTTP server is enough to make three things observable: the app starts, listens on a port, and writes one log line per request.

const http = require('node:http');

  const port = process.env.PORT || 3000;

  http.createServer((req, res) => {
    console.log(new Date().toISOString(), req.method, req.url);
    res.writeHead(200, { 'content-type': 'text/plain' });
    res.end('hello from CodeNames\n');
  }).listen(port, () => {
    console.log('listening on', port);
  });

{
    "name": "codenames-docker-demo",
    "version": "1.0.0",
    "private": true,
    "scripts": { "start": "node server.js" }
  }

برای اینکه npm ci رفتار تکرارپذیر داشته باشد، یک lockfile هم می‌خواهیم. یک بار روی سیستم میزبان اجرا کن:

To make npm ci reproducible, we also want a lockfile. Run this once on the host:

cd demo-web
  npm install --package-lock-only

این نقطهٔ آخر docker build دقیقاً چه کار می‌کند؟Build context: the final dot is not decoration

تقریباً همه اول کار فقط روی Dockerfile تمرکز می‌کنند و آن نقطهٔ آخر دستور را نادیده می‌گیرند. درحالی‌که همان نقطه تعیین می‌کند Docker برای این build اجازه دارد کدام فایل‌ها را ببیند.

The first thing beginners often overlook is the final dot:

docker build -t demo-web:1.0 .
                                  ^
                                  build context

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

The . says that the current directory is the build context: the set of files the builder is allowed to use for this build. When the Dockerfile says COPY server.js ./, the source is resolved relative to the context root, not from arbitrary locations on your disk.

demo-web/
  ├── Dockerfile
  ├── .dockerignore
  ├── package.json
  ├── package-lock.json
  ├── server.js
  └── node_modules/      # local files; we do not want these in the context

عمداً از context اشتباه build کن

Deliberately build from the wrong context

cd demo-web
  docker build -t demo-web:1.0 .

حالا فرض کن از parent پوشه build می‌کنی ولی Dockerfile داخل demo-web است:

Now suppose you build from the parent directory while the Dockerfile lives in demo-web:

cd ..
  docker build -f demo-web/Dockerfile -t demo-web:1.0 .

  # representative failure
  ERROR [3/5] COPY package*.json ./
  failed to compute cache key: "/package.json": not found

نکته اینجاست: -f فقط محل Dockerfile را مشخص کرد؛ context هنوز همان . است. COPY package*.json ./ دنبال package.json در root context می‌گردد، نه خودکار داخل directoryای که Dockerfile در آن قرار دارد. پس قبل از دست‌کاری COPY، سؤال درست این است: «context من کجاست؟»

The key point is that -f only selected the Dockerfile; the context is still the final .. COPY package*.json ./ looks from the context root, not automatically from the Dockerfile’s directory. Before changing COPY blindly, ask the correct question: “what is my context?”

.dockerignore؛ چیزهایی که نباید اصلاً وارد build شوند.dockerignore: not everything on disk belongs in the build

پروژهٔ واقعی پر از چیزهایی است که Docker لازم ندارد: node_modules، پوشهٔ .git، فایل‌های موقت و شاید فایل‌های حساس. اگر همه را وارد build context کنی هم کار بیشتر می‌شود، هم احتمال اشتباه بالاتر می‌رود. .dockerignore کمک می‌کند از همان اول ورودی build را تمیز نگه داری.

Think of the context as the input bundle for a build. .dockerignore is the list of things that should not enter that bundle. It keeps the context smaller and prevents irrelevant local files from becoming build inputs.

node_modules
  .git
  .env
  npm-debug.log
  *.local

node_modules را از سیستم میزبان نمی‌خواهیم چون وابستگی باید داخل image و بر اساس همان image پایه نصب شود. .git برای اجرای برنامه لازم نیست. .env هم ممکن است اطلاعات محرمانه داشته باشد. اما یک نکتهٔ مهم: .dockerignore سیستم مدیریت اطلاعات محرمانه نیست. فقط کمک می‌کند چیزی ناخواسته وارد context نشود.

We do not want host node_modules because dependencies should be installed inside the image against that base environment. .git is not needed to run the app. .env may contain secrets. But one distinction matters: .dockerignore is not a secret-management system. It only reduces the chance of sending unwanted files into the context.

یک خطا مفید

A useful failure

# temporarily add this line:
  server.js

  docker build -t demo-web:broken .

  # representative output
  ERROR [5/5] COPY server.js ./
  failed to compute cache key: "/server.js": not found

اینجا Docker «فایل را گم نکرده». تو به سازنده گفته‌ای سرور.js جزو ورودی build نباشد و چند خط بعد از او خواسته‌ای همان فایل را COPY کند. خطا دقیقاً تضاد بین دو تصمیم خودت را نشان می‌دهد.

Docker did not mysteriously “lose” the file. You told the builder that server.js was not part of the build input, then later asked it to COPY that file. The error exposes a contradiction between two choices in your own build definition.

Dockerfile را حفظ نکن؛ دلیل هر خط را بفهمDo not memorize a Dockerfile; each line is a decision

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

Instead of staring at a finished file and memorizing keywords, we will build it one instruction at a time. After each line you should be able to answer: “what did this change during the build, and does it affect runtime too?”

۱) FROM: از چه سیستم‌فایل و runtimeای شروع می‌کنیم؟

1) FROM: which filesystem and runtime do we start from?

FROM node:22-alpine

FROM image پایه را انتخاب می‌کند. اینجا یعنی build را روی سیستم‌فایل کوچک Alpine شروع می‌کنیم که Node هم از قبل داخلش هست. هنوز کد خودمان داخل image نیست. هنوز سرور هم اجرا نشده. فقط نقطهٔ شروع image را انتخاب کرده‌ایم.

FROM selects the base image. Here the build starts from a small Alpine filesystem that already contains Node. Our source code is not in the image yet, and no server is running; we have only chosen the starting point.

۲) WORKDIR: از اینجا به بعد «اینجا» کجاست؟

2) WORKDIR: what does “here” mean from now on?

FROM node:22-alpine
  WORKDIR /app

WORKDIR /app می‌گوید instructionهای بعدی relative pathهایشان را از /app حساب کنند؛ اگر پوشه نباشد، ساخته می‌شود. این با RUN cd /app یکی نیست. cd فقط همان شل invocation را جابه‌جا می‌کند، اما WORKDIR بخشی از تنظیمات image می‌شود و دستور زمان اجرا هم از همان پوشه شروع می‌شود.

WORKDIR /app makes later instructions resolve relative paths from /app, creating the directory if needed. This is not the same as RUN cd /app. A shell cd only affects that RUN invocation, while WORKDIR becomes image configuration and also sets the starting directory for the runtime command.

۳) اول فایل‌های وابستگی را COPY کن

3) Copy dependency manifests first

COPY package*.json ./

فعلاً فقط package.json و package-lock.json را می‌آوریم. چرا کد برنامه را همین الان کامل COPY نمی‌کنیم؟ چون dependencyها معمولاً کمتر از کد برنامه تغییر می‌کنند. این تصمیم چند بخش بعد، وقتی cache را می‌بینیم، اثرش را نشان می‌دهد.

For now we copy only package.json and package-lock.json. Why not copy all source code immediately? Because dependency manifests usually change less often than application source. The payoff becomes obvious when we inspect cache behavior later.

۴) RUN: کاری که هنگام build انجام می‌شود

4) RUN: work that happens during the build

RUN npm ci --omit=dev

این دستور موقع ساخت image اجرا می‌شود، نه هر بار که container بالا می‌آید. اگر وابستگی نصب ناموفق شود، build باید همان‌جا ناموفق شود. نتیجهٔ نصب، مثل node_modules، وارد سیستم‌فایل image می‌شود و build بعدی می‌تواند همین مرحله را از cache استفادهٔ دوباره کند.

This command runs while building the image, not every time a container starts. If dependency installation fails, the build should fail at this step. The result, such as node_modules, becomes part of the image filesystem, and later builds may reuse this step from cache.

۵) حالا کد برنامه را اضافه کن

5) Now add application source

COPY server.js ./

تغییرات روزمره معمولاً همین‌جاست؛ متن پاسخ، هدایت جدید یا منطق برنامه. چون این COPY بعد از npm ci آمده، تغییر کردن کد برنامه لازم نیست وابستگی نصب را دوباره اجرا کند—به شرطی که manifestها عوض نشده باشند.

Most day-to-day changes happen here: a response string, a new route, application logic. Because this COPY comes after npm ci, editing source does not need to rerun dependency installation—as long as the dependency manifests remain unchanged.

۶) ENV و EXPOSE: تنظیمات با شبکه publishing یکی نیست

6) ENV and EXPOSE: configuration is not port publishing

ENV PORT=3000
  EXPOSE 3000

ENV PORT=3000 یک مقدار پیش‌فرض داخل image تنظیمات ثبت می‌کند که پردازش زمان اجرا می‌تواند بخواند. EXPOSE 3000 هم اعلام می‌کند برنامه قرار است روی پورت 3000 گوش بدهد؛ اما هیچ سیستم میزبان portای باز نمی‌کند. برای مرورگر هنوز همان چیزی را که در فصل ۳ یاد گرفتی لازم داری: مثلاً -p 8080:3000.

ENV PORT=3000 records a default value in image configuration for the runtime process to read. EXPOSE 3000 documents that the application is expected to listen on port 3000, but it does not publish a host port. Browser access still needs what you learned in Chapter 3, for example -p 8080:3000.

۷) CMD: اگر کاربر دستور دیگری نداد، چه processی اجرا شود؟

7) CMD: what process runs when the user supplies no command?

CMD ["npm", "start"]

CMD هنگام build اجرا نمی‌شود. فقط پیش‌فرض زمان اجرا دستور را داخل image تنظیمات ثبت می‌کند. وقتی بعداً docker run demo-web:1.0 بزنی، این پیش‌فرض اجرا می‌شود. اگر خودت بعد از image name دستور دیگری بدهی، آن دستور جای CMD را برای همان container می‌گیرد.

CMD does not execute during the build. It records the default runtime command in image configuration. Later, docker run demo-web:1.0 uses that default. If you provide another command after the image name, that command replaces CMD for that container.

FROM node:22-alpine
  WORKDIR /app

  COPY package*.json ./
  RUN npm ci --omit=dev

  COPY server.js ./

  ENV PORT=3000
  EXPOSE 3000

  CMD ["npm", "start"]

RUN داخل Dockerfile با docker run چه فرقی دارد؟RUN and docker run only look similar

اسم این دو آن‌قدر شبیه است که اوایل راحت قاطی می‌شوند. RUN هنگام ساخت image اجرا می‌شود؛ اما docker run بعداً از image یک container می‌سازد و آن را اجرا می‌کند. یکی مربوط به «ساختن» است، دیگری مربوط به «اجرا کردن».

This is one of the most common beginner confusions. RUN npm ci in a Dockerfile is part of building the image. docker run ... in the terminal happens after the build and creates a container. The two commands change different state.

docker build -t demo-web:1.0 .

  # representative BuildKit output
  [+] Building 8.9s (10/10) FINISHED
  => [internal] load build definition from Dockerfile
  => [1/5] FROM docker.io/library/node:22-alpine
  => [2/5] WORKDIR /app
  => [3/5] COPY package*.json ./
  => [4/5] RUN npm ci --omit=dev
  => [5/5] COPY server.js ./
  => exporting to image
  => naming to docker.io/library/demo-web:1.0

از این خروجی چه می‌فهمیم؟ فقط اینکه build کامل شده و image با برچسب موردنظر ساخته شده. هنوز نمی‌دانیم HTTP سرور بالا می‌آید یا نه. برای آن باید زمان اجرا را جداگانه امتحان کنیم.

What does this output prove? Only that the build completed and an image was produced under the requested tag. It does not prove the HTTP server can stay alive. Runtime is a separate question.

docker run -d --name demo-web -p 8080:3000 demo-web:1.0
  docker ps --filter name=demo-web
  docker logs demo-web
  curl -i http://localhost:8080

این چهار خط چهار سؤال جدا را جواب می‌دهند: container ساخته شده؟ هنوز Running است؟ پردازش لاگ داده؟ و مسیر پورت سیستم میزبان تا خود برنامه واقعاً پاسخ می‌دهد؟ «build شد» و «برنامه سالم اجرا می‌شود» یک جمله نیستند.

These four commands answer four separate questions: does the container exist, is it still Running, did the process emit logs, and does the host-to-application path actually respond? “The image built” and “the application runs correctly” are not the same statement.

image چطور مرحله‌به‌مرحله ساخته می‌شود؟Layers: an image is not one magical monolithic file

Dockerfile از بالا به پایین اجرا می‌شود و هر دستور نتیجهٔ مرحلهٔ قبل را تحویل می‌گیرد. بعضی دستورها فایل‌های image را تغییر می‌دهند و بعضی فقط تنظیماتش را. فعلاً لازم نیست وارد جزئیات storage driver شویم؛ همین کافی است که بدانیم هر مرحله ورودی خودش را دارد و روی نتیجهٔ قبلی بنا می‌شود.

You read a Dockerfile from top to bottom, and the builder also evaluates each instruction as part of the build history. Some instructions change the filesystem, while others mainly record configuration or metadata. You do not need storage-driver internals yet; one model is enough: each step has defined inputs and builds on the result of earlier steps.

cache را با چشم ببین؛ فقط تعریفش را نخوانSee cache with your own eyes: four builds, four stories

اگر فقط بگوییم «Docker cache دارد»، احتمالاً فردا یادت می‌رود. پس چهار بار build می‌کنیم: بار اول از صفر، بار دوم بدون هیچ تغییر، بار سوم فقط با تغییر server.js و بار چهارم با تغییر وابستگی‌ها. از روی خروجی دقیقاً می‌بینیم کدام مرحله دوباره اجرا می‌شود و کدام نه.

Cache becomes intuitive when you compare several builds side by side. The goal is not to memorize the word CACHED; the useful question is “which input changed, and from which step did reuse stop being valid?”

Build #1 — هیچ cacheای برای پروژه نداریم

Build #1 — no project cache yet

docker build -t demo-web:1.0 .

  # relevant output
  => [3/5] COPY package*.json ./
  => [4/5] RUN npm ci --omit=dev
  => [5/5] COPY server.js ./

در build اول طبیعی است که کار واقعاً انجام شود. حالا بدون تغییر هیچ فایلی همان دستور را دوباره بزن.

On the first build, the work genuinely has to happen. Now run the exact same build again without changing any file.

Build #2 — بدون تغییر

Build #2 — unchanged

docker build -t demo-web:1.0 .

  # representative output
  => CACHED [2/5] WORKDIR /app
  => CACHED [3/5] COPY package*.json ./
  => CACHED [4/5] RUN npm ci --omit=dev
  => CACHED [5/5] COPY server.js ./

این یعنی سازنده برای همین ورودی‌ها نتیجهٔ قابل‌استفادهٔ دوباره پیدا کرده است. نه اینکه Docker «اجرا را حذف کرده»؛ بلکه تشخیص داده ساختن دوبارهٔ همان نتیجه لازم نیست.

This means the builder found reusable results for those inputs. Docker did not “delete RUN”; it determined that rebuilding the same result was unnecessary.

Build #3 — فقط کد برنامه را تغییر بده

Build #3 — change only application source

# change only the response text in server.js, then:
  docker build -t demo-web:1.1 .

  # expected shape
  => CACHED [3/5] COPY package*.json ./
  => CACHED [4/5] RUN npm ci --omit=dev
  =>        [5/5] COPY server.js ./

این همان لحظه‌ای است که ترتیب Dockerfile معنی پیدا می‌کند. وابستگی ورودی‌ها تغییر نکرده‌اند، پس نصب قابل‌استفادهٔ دوباره است. فقط مرحله مربوط به کد برنامه باید دوباره اجرا شود.

This is where Dockerfile ordering starts to matter. Dependency inputs did not change, so installation remains reusable. Only the step that depends on application source needs to run again.

Build #4 — lockfile را تغییر بده

Build #4 — change the lockfile

# change dependencies so package-lock.json changes, then:
  docker build -t demo-web:1.2 .

  # expected shape
  =>        [3/5] COPY package*.json ./
  =>        [4/5] RUN npm ci --omit=dev
  =>        [5/5] COPY server.js ./

وقتی ورودی مرحلهٔ COPY manifest عوض شد، cache آن مرحله دیگر نمایندهٔ وضعیت جدید نیست. از آن نقطه به بعد stepهای بعدی هم باید با وضعیت جدید بررسی و ساخته شوند. این همان cache invalidation است.

When the manifest COPY input changes, that cached result no longer represents the new state. From that point onward, later steps must be evaluated against the new state. That is cache invalidation.

چرا ترتیب خط‌های Dockerfile واقعاً مهم است؟Two Dockerfiles can build the same app but have very different rebuild cost

دو Dockerfile می‌توانند در نهایت یک برنامهٔ یکسان بسازند، ولی یکی با هر تغییر کوچک مجبور شود وابستگی‌ها را از نو نصب کند و دیگری نه. فرقشان فقط در این است که کدام فایل‌ها را زودتر وارد build کرده‌ایم.

Do not turn this into a blind rule. The deeper principle is to keep expensive work behind stable inputs. Real projects, monorepos, generated files, and build tools may require a different ordering.

اگر خواستی ببینی image چطور ساخته شده، سراغ history بروUse image history to inspect what you built—but do not overinterpret it

docker image history demo-web:1.1

  # representative output
  IMAGE        CREATED BY                                      SIZE
  <id>         CMD ["npm" "start"]                              0B
  <missing>    EXPOSE map[3000/tcp:{}]                          0B
  <missing>    ENV PORT=3000                                    0B
  <missing>    COPY server.js ./                                1.2kB
  <missing>    RUN /bin/sh -c npm ci --omit=dev                 ...

گاهی لازم است از خود image بپرسی چه مراحلی پشت سرش بوده‌اند. docker image history برای همین خوب است: یک تصویر کلی از دستورها و سهم تقریبی آن‌ها می‌دهد. فقط حواست باشد history سلامت برنامه را ثابت نمی‌کند؛ هنوز باید container را اجرا کنی.

docker image history is useful for connecting Dockerfile instructions to the resulting image: you can inspect order and approximate contribution. But history does not prove the application is healthy, the port is published correctly, or PID 1 will remain alive. Those are runtime questions.

CMD و ENTRYPOINT؛ کدام بخش قرار است قابل‌تغییر باشد؟CMD and ENTRYPOINT: a default is different from a fixed executable

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

So far our image only needs CMD, which is the clearest choice for a simple app. But you should understand why ENTRYPOINT exists, because real images often combine the two.

CMD: پیش‌فرض قابل‌جایگزینی

CMD: a replaceable default

docker image inspect demo-web:1.1 \
    --format 'cmd={{json .Config.Cmd}} entrypoint={{json .Config.Entrypoint}}'

  # representative output
  cmd=["npm","start"] entrypoint=null

  docker run --rm demo-web:1.1 node --version
  # v22.x.x

در دستور آخر، node --version جای CMD را گرفته است؛ image تغییر نکرده، فقط این container با دستور دیگری ساخته شده. اگر دوباره image را بدون دستور اجرا کنی، پیش‌فرض همان npm start است.

In the final command, node --version replaces CMD. The image itself is unchanged; only this container was created with a different command. Run the image again without a command and the default is still npm start.

ENTRYPOINT: وقتی image قرار است مثل یک فایل اجرایی مشخص رفتار کند

ENTRYPOINT: when the image is meant to behave like one executable

برای فهم تفاوت، یک image آزمایشی کوچک بساز:

To make the distinction concrete, build a tiny experimental image:

FROM alpine:3.23
  ENTRYPOINT ["printf"]
  CMD ["hello\n"]

docker build -f Dockerfile.entrypoint -t printf-demo .
  docker run --rm printf-demo
  # hello

  docker run --rm printf-demo 'CodeNames\n'
  # CodeNames

اینجا ENTRYPOINT می‌گوید فایل اجرایی اصلی printf است و CMD آرگومان پیش‌فرض آن را می‌دهد. argumentی که در docker run می‌دهی CMD را عوض می‌کند، اما ENTRYPOINT سر جای خودش می‌ماند. این همان دلیلی است که CMD و ENTRYPOINT دو مفهوم جدا هستند.

Here ENTRYPOINT fixes printf as the executable, while CMD provides its default argument. Arguments supplied to docker run replace CMD, while ENTRYPOINT remains. That is the practical reason the two concepts are separate.

EXPOSE پورت را روی سیستم تو باز نمی‌کندDo not confuse EXPOSE with publishing a port

این یکی از آن اشتباه‌هایی است که فقط با یک آزمایش کوتاه برای همیشه جا می‌افتد. داخل Dockerfile نوشته‌ایم EXPOSE 3000. حالا container را بدون -p اجرا می‌کنیم و می‌بینیم با اینکه برنامه داخل container روی 3000 گوش می‌دهد، هنوز از localhost راهی به آن نداریم.

This confusion is common enough to deserve a separate experiment. Our image contains EXPOSE 3000. Run it without -p:

docker run -d --name no-publish demo-web:1.1
  docker ps --filter name=no-publish
  curl http://localhost:8080

  # curl should fail because no host port was published

داخل container برنامه می‌تواند روی 3000 گوش بدهد و image هم 3000 را expose کرده باشد، ولی هنوز هیچ نگاشت از سیستم میزبان به container ساخته نشده. حالا container را recreate کن:

The application may be listening on 3000 inside the container and the image may document that port with EXPOSE, but no host-to-container mapping exists yet. Recreate it with publishing:

docker rm -f no-publish
  docker run -d --name demo-web -p 8080:3000 demo-web:1.1
  docker ps --filter name=demo-web
  curl http://localhost:8080

اگر این بار جواب گرفتی، فرق دو مفهوم را عملاً دیده‌ای: EXPOSE دربارهٔ intent/تنظیمات image است؛ -p دربارهٔ شبکه نگاشت در زمان ساخت container.

If the request now succeeds, you have observed the distinction directly: EXPOSE describes image intent/configuration, while -p creates a network mapping when the container is created.

وقتی build یا اجرا خراب شد، اول ببین مشکل در کدام مرحله استFailure workshop: locate the broken boundary before fixing it

از اینجا به بعد عمداً چند چیز را خراب می‌کنیم. قرار نیست با هر خطا یک دستور تصادفی بزنیم. اول می‌پرسیم خطا قبل از ساخته‌شدن image رخ داده یا بعد از آن؟ فایل پیدا نشده؟ یکی از دستورهای build شکست خورده؟ container بالا آمده ولی برنامه جواب نمی‌دهد؟ همین سؤال اول، مسیر بررسی را خیلی کوتاه‌تر می‌کند.

From here on, treat every error as a clue. Before trying random commands, ask which boundary is broken: context, build step, image artifact, startup command, or runtime/port?

۱۸ تمرین؛ اول حدس بزن، بعد با Docker امتحانش کن18 exercises: predict first, then run

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

If you open every solution immediately, this becomes just another page to read. Before revealing an answer, write at least one prediction or command.

آزمایشگاه: برنامهٔ خودت را از فایل تا container دنبال کنChapter lab: source to image, then a deliberately invalidated cache

اگر پروژه را به همکارت بدهی، چه چیزهایی باید همراهش باشد؟What evidence is enough for a teammate to reproduce your result?

مرجع سریعQuick reference

docker build -t NAME:TAG .
  docker image ls NAME
  docker image history NAME:TAG
  docker image inspect NAME:TAG
  docker run -d --name NAME -p 8080:3000 IMAGE
  docker logs NAME
  docker ps -a
  docker rm -f NAME

FROM
  WORKDIR
  COPY
  RUN
  ENV
  EXPOSE
  CMD
  ENTRYPOINT

  .dockerignore