ভালো Dockerfile — multi-stage build, ছোট image আর non-root

১ · ছোট প্রোগ্রাম, কিন্তু বিশাল image

পর্ব ৩৭-এ দেখা হয়েছে container image আসলে একের ওপর এক বসানো layer, আর Dockerfile সেই layer বানানোর নির্দেশ। এবার প্রশ্ন হলো: যে Dockerfile কাজ করে, সেটিই কি ভালো Dockerfile? উত্তর হলো, না। চলা আর ভালোভাবে চলা আলাদা কথা।

একটি খুব ছোট C প্রোগ্রাম ধরুন। সে একটি লাইন ছাপে, আর কোন user হিসেবে চলছে সেটিও বলে:

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("hello from container, uid=%d\n", (int)getuid());
    return 0;
}

সবচেয়ে সরল Dockerfile হলো একই image-এ compiler বসানো, compile করা, আর সেই image-ই চালানো:

FROM alpine:3.20
RUN apk add --no-cache gcc musl-dev
WORKDIR /src
COPY hello.c .
RUN gcc -O2 -o /usr/local/bin/hello hello.c
CMD ["hello"]

এটি চলে। কিন্তু build শেষে docker history দেখুন, কোন layer কত জায়গা নিয়েছে:

$ docker history abcl-dp-fat
IMAGE          CREATED BY                                      SIZE
…              CMD ["hello"]                                   0B
<missing>      RUN /bin/sh -c gcc -O2 -o /usr/local/bin/hel…   36.9kB
<missing>      COPY hello.c . # buildkit                       12.3kB
<missing>      WORKDIR /src                                    8.19kB
<missing>      RUN /bin/sh -c apk add --no-cache gcc musl-d…   158MB
<missing>      CMD ["/bin/sh"]                                 0B
<missing>      ADD alpine-minirootfs-3.20.10-x86_64.tar.gz …   8.47MB

আসল প্রোগ্রাম মাত্র ৩৬.৯kB-এর একটি layer. কিন্তু তাকে ঘিরে বসে আছে ১৫৮MB-এর compiler. Production-এ এই compiler-এর কোনো কাজ নেই, তবু প্রতিটি সার্ভারে সে যাবে।

ছোট image শুধু জায়গা বাঁচায় না। এতে pull দ্রুত হয়, ফলে নতুন server বা autoscaling দ্রুত সাড়া দেয়। কম package মানে কম CVE, আর আক্রমণের সুযোগও কম। এই সুযোগের মোট পরিমাণকে বলে attack surface. Container-এ compiler আর package manager না থাকলে কেউ ভেতরে ঢুকলেও তার হাতের কাছে কম হাতিয়ার থাকে।

২ · Multi-stage build — রান্নাঘর আলাদা, টেবিল আলাদা

Multi-stage build মানে একটি Dockerfile-এ একাধিক FROM. প্রতিটি FROM একটি নতুন stage শুরু করে। আগের stage থেকে শুধু বেছে নেওয়া ফাইল পরের stage-এ আনা যায়, COPY --from দিয়ে। Docker 17.05 (২০১৭) থেকে এই সুবিধা আছে।

FROM alpine:3.20 AS build
RUN apk add --no-cache gcc musl-dev
WORKDIR /src
COPY hello.c .
RUN gcc -O2 -static -s -o /hello hello.c

FROM scratch
COPY --from=build /hello /hello
USER 10001:10001
ENTRYPOINT ["/hello"]

এখানে -static প্রোগ্রামের ভেতরেই C library জুড়ে দেয়, আর -s debug তথ্য বাদ দেয়। scratch হলো একদম খালি শুরু।

নিচের ধাপগুলো এই Dockerfile-এর আসল build থেকে নেওয়া। প্রতিটি ধাপের সময়ও সেই run-এর।

#5 [build 1/5] FROM docker.io/library/alpine:3.20@sha256:d9e853e8…
#5 CACHED

#6 [build 2/5] RUN apk add --no-cache gcc musl-dev
#6 …
#6 DONE 30.7s

#7 [build 3/5] WORKDIR /src
#7 DONE 0.1s
#8 [build 4/5] COPY hello.c .
#8 DONE 0.1s
#9 [build 5/5] RUN gcc -O2 -static -s -o /hello hello.c
#9 DONE 0.2s

# stage-1 এখনো পুরো খালি:
# no shell, no libc, no gcc, no files
FROM scratch

#10 [stage-1 1/1] COPY --from=build /hello /hello
#10 DONE 0.0s

$ docker history abcl-dp-multi
ENTRYPOINT ["/hello"]           0B
USER 10001:10001                0B
COPY /hello /hello # buildkit   32.8kB

এবার তিনটি পদ্ধতি পাশাপাশি। মাঝেরটিতে build stage একই, কিন্তু final image হলো alpine:3.20, আর প্রোগ্রাম dynamic linking-এ তৈরি:

$ docker image ls --format '{{.Repository}} {{.Size}}'
abcl-dp-fat 229MB
abcl-dp-alp 12.1MB
abcl-dp-multi 47kB

$ docker run --rm abcl-dp-fat
hello from container, uid=0
$ docker run --rm abcl-dp-multi
hello from container, uid=10001

Stage-এর আরও কিছু ব্যবহার আছে। docker build --target build . শুধু নামের stage পর্যন্ত build করে, তাই একই Dockerfile থেকে test চালানোর image আর ship করার image দুটোই পাওয়া যায়। COPY --from অন্য stage ছাড়াও অন্য image থেকে ফাইল আনতে পারে। আর শুধু C বা Go-র জন্য নয়: Python-এ একটি stage-এ dependency বসিয়ে পরের stage-এ কপি করা যায়, Node-এ TypeScript build-এর টুল বাদ দেওয়া যায়, Java-তে JDK build stage-এ রেখে final-এ শুধু JRE রাখা যায়। এই পর্বের শেষে এমন একটি Python উদাহরণ আছে।

যে error ভোগায়: “no such file or directory”

এবার একটি ফাঁদ। ওই Dockerfile থেকে -static বাদ দিলে build সফল হয়, কিন্তু চালাতে গেলে:

$ docker run --name abcl-dp-c1 abcl-dp-broken
exec /hello: no such file or directory
$ echo $?
255

ফাইলটি কিন্তু আছে! আসলে খুঁজে পাওয়া যাচ্ছে না তার loader. Dynamic প্রোগ্রাম চালাতে library আর loader লাগে। Alpine-এ চালিয়ে দেখলে সেটি ধরা পড়ে:

$ docker run --rm abcl-dp-alp ldd /usr/local/bin/hello
	/lib/ld-musl-x86_64.so.1 (0x…)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x…)

scratch-এ /lib/ld-musl-x86_64.so.1 নেই, তাই kernel প্রোগ্রাম চালাতে পারে না। এজন্য scratch-এ পাঠানোর প্রোগ্রাম হতে হয় static, অথবা library-গুলো হাতে কপি করতে হয়। Linking-এর ধারণা আরও জানতে দেখুন C-এর টুলচেইন পর্ব।

নিচের simulator আগের docker history-এর সংখ্যা নেয়, আর একটি size budget-এর সাথে মেলায়। Link speed, compression আর deploy-এর সংখ্যা ধরে নেওয়া মান। এগুলো বদলে চালিয়ে দেখুন।

// Image size budget. Layer sizes (MB) from one real "docker history" run.
const BUDGET_MB = 20, LINK_MBPS = 20, COMPRESS = 0.4;  // assumed link and gzip ratio
const DEPLOYS = 30, NODES = 10;                         // per month, assumed
const base = 8.47, compiler = 158, source = 0.012, binary = 0.033;
const plans = [
  ["one stage", [base, compiler, source, binary]],
  ["multi, final alpine", [base, binary]],
  ["multi, final scratch", [binary]],
];
console.log("plan                  size_MB  pull_s  GB/month  budget");
for (const [name, layers] of plans) {
  const mb = layers.reduce((a, b) => a + b, 0);
  const wireMB = mb * COMPRESS;                 // bytes on the network
  const pull = wireMB * 8 / LINK_MBPS;          // MB -> megabits -> seconds
  const gb = wireMB * DEPLOYS * NODES / 1000;   // if no layer is cached yet
  console.log(
    name.padEnd(21) + mb.toFixed(2).padStart(7) + pull.toFixed(2).padStart(8) +
    gb.toFixed(2).padStart(10) + (mb <= BUDGET_MB ? "  OK" : "  OVER by " + (mb - BUDGET_MB).toFixed(2))
  );
}
const one = base + compiler + source + binary;
console.log("final scratch is " + Math.round(one / binary) + " times smaller than one stage");

plan                  size_MB  pull_s  GB/month  budget
one stage             166.51   26.64     19.98  OVER by 146.51
multi, final alpine     8.50    1.36      1.02  OK
multi, final scratch    0.03    0.01      0.00  OK
final scratch is 5046 times smaller than one stage

৩ · Base image বাছাই — full, slim, alpine, distroless, scratch

FROM লাইনের base image হলো আপনার বাড়ির ভিত। ছোট ভিত সবসময় ভালো নয়। আপনার app কী চায়, সেটিই আসল প্রশ্ন।

মাপগুলো মোটামুটি, লেখার সময়ের ধারণা। Version আর platform-ভেদে বদলায়, তাই নিজে মেপে নেবেন।

Alpine-এর musl: ছোট হওয়ার দাম

Debian আর Ubuntu ব্যবহার করে glibc, আর Alpine ব্যবহার করে musl. দুটিই C library, কিন্তু হুবহু এক নয়। বাস্তবে যা ঘটতে পারে:

• Binary মেলে না: glibc-র জন্য build করা প্রোগ্রাম Alpine-এ সাধারণত সরাসরি চলে না। আগের “no such file” error-ই তখন দেখা যেতে পারে।
• Prebuilt package: Python-এর কিছু C extension-এর musl-এর wheel না থাকলে source থেকে build হয়, তাই build ধীর হয়।
• DNS আর locale: musl-এর resolver-এর আচরণ glibc-র থেকে আলাদা। পুরোনো version-এ TCP fallback ছিল না; musl 1.2.4 (২০২৩) থেকে সেটি যোগ হয়েছে।
• গতি: Memory allocator ভিন্ন, তাই কিছু কাজে কর্মক্ষমতা আলাদা হতে পারে। সিদ্ধান্ত নেওয়ার আগে নিজের app মেপে দেখুন।

Distroless image-এ shell নেই, তাই docker exec -it … sh কাজ করে না। এটি নিরাপত্তায় সুবিধা, কিন্তু debug-এ অসুবিধা। সমাধান হিসেবে অনেকে আলাদা debug image রাখেন, অথবা পাশে সাময়িক debug container চালান। পর্ব ৪৯-এ Kubernetes-এর দিক থেকে এই নিরাপত্তা আবার আসবে।

৪ · Version pin — latest, tag আর digest

আগে পরিষ্কার করে নিই: latest মানে “সবচেয়ে নতুন” নয়। এটি শুধু একটি ডিফল্ট tag-এর নাম। Image প্রকাশক যা push করেছেন, সেটিই latest. FROM python লিখলেও Docker python:latest ধরে নেয়। তাই আজকের build আর আগামী মাসের build-এ ভিন্ন Python আসতে পারে, অথচ আপনার Dockerfile এক অক্ষরও বদলায়নি।

Digest হলো image-এর আধেয়ের hash, তাই একে চুপচাপ বদলানো যায় না। আসল run-এ digest বের করে pin করে দেখা হলো:

$ docker image inspect alpine:3.20 --format '{{json .RepoDigests}}'
["alpine@sha256:d9e853e87e55526f6b2917df91a2115c36dd7c696a35be12163d44e6e2a4b6bc"]

$ cat Dockerfile.pin
FROM alpine:3.20@sha256:d9e853e87e55526f6b2917df91a2115c36dd7c696a35be12163d44e6e2a4b6bc
CMD ["cat", "/etc/alpine-release"]

$ docker run --rm abcl-dp-pin
3.20.10

Digest pin-এর একটি দাম আছে। Base image-এ নিরাপত্তা-সমাধান এলেও আপনার build পুরোনোটিই নেবে। তাই ভালো অভ্যাস হলো digest pin করা, আর Dependabot বা Renovate-এর মতো টুল দিয়ে আপডেটের pull request পাওয়া। পর্ব ৪১-এ registry, tag বদলানো আর signing নিয়ে বিস্তারিত আলোচনা আছে। আর এখানে alpine:3.20 শুধু উদাহরণ; নতুন কাজের আগে দেখে নেবেন কোন version এখনো সমর্থিত।

৫ · Non-root — root হিসেবে চালাবেন না

Dockerfile-এ USER না থাকলে container-এর প্রক্রিয়া ডিফল্টভাবে root হিসেবে চলে। দুটি ছোট image-এ দেখুন:

FROM alpine:3.20
RUN addgroup -S -g 10001 app && adduser -S -D -H -u 10001 -G app app
USER app
CMD ["id"]

# USER ছাড়া
$ docker run --rm abcl-dp-root
uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),…

# USER app সহ
$ docker run --rm abcl-dp-user
uid=10001(app) gid=10001(app) groups=10001(app),10001(app)

# non-root প্রক্রিয়া সিস্টেমের ফোল্ডারে লিখতে পারে না
$ docker run --rm abcl-dp-user sh -c 'touch /etc/x; echo "exit=$?"; touch /tmp/x; echo "tmp exit=$?"'
touch: /etc/x: Permission denied
exit=1
tmp exit=0

এই আউটপুট container-এর ভেতরের, এবং ওপরের উদাহরণের জন্য বানানো user-এর। Root চালিয়ে একই touch /etc/x করলে exit=0 আসে। অর্থাৎ root হলে কোনো হামলাকারী app-এর দুর্বলতা দিয়ে ঢুকে সিস্টেমের ফাইল বদলাতে পারে, non-root হলে এই পথ অনেকটা বন্ধ। এটি least privilege-এর সরল প্রয়োগ।

কিছু বাস্তব খুঁটিনাটি মনে রাখুন:

• সংখ্যায় লিখুন: USER 10001:10001 নাম ছাড়াই কাজ করে। scratch-এ /etc/passwd নেই, তাই নাম কাজ করবে না; আগের uid=10001 এভাবেই এসেছে। Kubernetes-এর runAsNonRoot যাচাইও সংখ্যা দেখে সহজে করতে পারে।
• ক্রম: USER-এর পরের RUN ওই user হিসেবে চলে। তাই package বসানো শেষ হলে তবেই USER.
• মালিকানা: COPY ডিফল্টভাবে root-এর মালিকানায় ফাইল রাখে। App-কে কোনো ফোল্ডারে লিখতে হলে COPY --chown=app:app বা RUN chown লাগবে। Code নিজে read-only থাকলেই ভালো।
• Port: ঐতিহ্যগতভাবে non-root ১০২৪-এর নিচের port খুলতে পারে না। তবে নতুন Docker-এ container-এ এই বাধা ডিফল্টভাবে তোলা থাকে; এই run-এ non-root user 80-তে bind করতে পেরেছে। এর ওপর নির্ভর না করে 8080-এর মতো port নেওয়াই সহজ।

৬ · HEALTHCHECK — process চলছে মানেই app ঠিক নয়

একটি app deadlock-এ আটকে থাকতে পারে, process চলছে অথচ কোনো অনুরোধের উত্তর দিচ্ছে না। Docker-এর চোখে তখনও container Up. HEALTHCHECK instruction Docker-কে একটি পরীক্ষা শেখায়, যা নিয়মিত container-এর ভেতরে চলে। Exit code 0 মানে ঠিক, 1 মানে সমস্যা। ধারণাটি health check-এর মতোই, যা পর্ব ১৭ আর পর্ব ১৮-এ autoscaling ও load balancer-এ দেখেছেন।

FROM python:3.12-alpine
COPY server.py /server.py
HEALTHCHECK --interval=2s --timeout=2s --start-period=3s --retries=3 \
  CMD wget -q -O /dev/null http://127.0.0.1:8080/ || exit 1
CMD ["python", "-u", "/server.py"]

এই ছোট server-এর /tmp/ok ফাইল থাকলে সে 200 দেয়, না থাকলে 503. আসল run-এ অবস্থা বদলাল এভাবে (মাঝের লাইনগুলো ছাঁটা):

$ docker inspect abcl-dp-h1 --format '{{.State.Health.Status}} streak={{.State.Health.FailingStreak}}'
starting streak=0
healthy streak=0

$ docker ps --filter name=abcl-dp-h1 --format '{{.Names}}  {{.Status}}'
abcl-dp-h1  Up 9 seconds (healthy)

$ docker exec abcl-dp-h1 rm /tmp/ok     # app-কে অসুস্থ করা হলো
# একই inspect প্রতি ২ সেকেন্ডে
healthy streak=1
healthy streak=2
unhealthy streak=3
unhealthy streak=4

$ docker ps --filter name=abcl-dp-h1 --format '{{.Names}}  {{.Status}}'
abcl-dp-h1  Up 22 seconds (unhealthy)

$ docker inspect abcl-dp-h1 --format '{{json .State.Health.Log}}'
…"ExitCode":1,"Output":"wget: server returned error: HTTP/1.0 503 Service Unavailable\n"}…

$ docker inspect abcl-dp-h1 --format 'running={{.State.Running}} restarts={{.RestartCount}}'
running=true restarts=0

দুটি জিনিস খেয়াল করুন। --retries=3 থাকায় পরপর তিনবার ব্যর্থ হওয়ার পরেই unhealthy হয়েছে, তাই একবারের সাময়িক সমস্যায় ভুল সংকেত আসে না। আর শেষ লাইনটি গুরুত্বপূর্ণ: container unhealthy হলেও restarts=0.

Distroless বা scratch-এ wget নেই। সেখানে app-এর ভেতরে একটি ছোট health subcommand রাখা যায়, যেমন HEALTHCHECK CMD ["/app", "healthcheck"]. পরীক্ষাটি হালকা রাখুন, আর এমন কিছু করবেন না যা ডেটাবেস ধীর হলেই সব container-কে অসুস্থ দেখায়।

৭ · Signal আর PID 1 — shell form বনাম exec form

docker stop প্রথমে container-এর PID 1-কে SIGTERM signal পাঠায়, অর্থাৎ ভদ্রভাবে বন্ধ হওয়ার অনুরোধ জানায়। নির্দিষ্ট সময় পরও না থামলে পাঠায় SIGKILL, যা ধরা বা আটকানো যায় না। Docker-এর নথি অনুযায়ী Linux container-এ ডিফল্ট অপেক্ষা ১০ সেকেন্ড (Windows container-এ ৩০ সেকেন্ড), আর -t দিয়ে বদলানো যায়। এখানে পরিমাপের জন্য একই মান -t 10 স্পষ্ট করে লেখা হয়েছে।

CMD লেখার দুটি রূপ আছে, এবং পার্থক্য শুধু চেহারায় নয়:

# exec form: Docker runs python directly, python becomes PID 1
CMD ["python", "-u", "/app.py"]

# shell form: Docker runs /bin/sh -c "..."
CMD python -u /app.py | tee /tmp/app.log

Exec form হলো JSON array. Shell form হলো সাধারণ লেখা, যা /bin/sh -c-এর ভেতরে চলে। App নিচের মতো SIGTERM ধরে “গুছিয়ে বন্ধ” হওয়ার চেষ্টা করে:

import signal, sys, time

def on_term(signum, frame):
    print("got SIGTERM, closing cleanly", flush=True)
    sys.exit(0)

signal.signal(signal.SIGTERM, on_term)
print("server started", flush=True)
while True:
    time.sleep(1)

এবার একই app, দুইভাবে চালিয়ে একই সময়ে বন্ধ করা হলো। ধাপগুলো দেখুন:

এবার আসল মাপ। প্রতিটি সারি একই docker stop -t 10 দিয়ে নেওয়া:

$ docker exec abcl-dp-s10 …        # shell form + pipe: প্রক্রিয়ার তালিকা
1 /bin/sh -c python -u /app.py | tee /tmp/app.log
7 python -u /app.py
8 tee /tmp/app.log
$ docker stop -t 10 abcl-dp-s10     # চারপাশে সময় মাপা হয়েছে
stop took 10.32s
$ docker inspect abcl-dp-s10 --format 'exit={{.State.ExitCode}}'
exit=137
$ docker logs abcl-dp-s10
server started

সারিগুলো থেকে তিনটি সত্য বেরিয়ে আসে, যা অনেক টিউটোরিয়ালে থাকে না:

• এক লাইনের shell form সবসময় ফাঁদ নয়। এই run-এ Alpine-এর sh CMD python -u /app.py-কে, এমনকি cd / && python …-কেও, নিজের জায়গায় exec করেছে; python-ই PID 1 হয়েছে আর 0.3s-এ থেমেছে। কিন্তু pipe বা পরে আরেকটি কমান্ড থাকলেই shell থেকে যায়। Shell-ভেদে এই আচরণ আলাদা, তাই এর ওপর নির্ভর করবেন না। Exec form লিখুন।
• Exec form একা যথেষ্ট নয়। Handler না থাকলে Python PID 1 হিসেবেও SIGTERM উপেক্ষিত হয়, কারণ kernel handler-হীন PID 1-কে বাড়তি সুরক্ষা দেয়। তাই সময় লেগেছে 10.45s.
• Script-এর শেষ লাইনে exec. ENTRYPOINT script-এ exec python … লিখলে shell নিজের জায়গা app-কে ছেড়ে দেয়। দেখুন, পরিবর্তন মাত্র এক শব্দের।

--init একটি ছোট init process (tini) PID 1-এ বসায়, যা signal এগিয়ে দেয় আর মরে যাওয়া child গুছিয়ে নেয়। তখন python আর PID 1 নয়, তাই ডিফল্ট আচরণেই থেমে যায়, exit 143 (128 + 15). তবে handler না থাকলে এটি গুছিয়ে বন্ধ হওয়া নয়, শুধু দ্রুত বন্ধ হওয়া। কিছু app আবার আলাদা signal চায়; STOPSIGNAL instruction সেটি বলে দেয়, যেমন nginx-এর official image SIGQUIT ব্যবহার করে।

// Predict "docker stop -t 10" from how the container starts.
function stop(c, grace = 10) {
  const pid1 = c.init ? "init" : c.shellStays ? "sh" : "app";
  let how;
  if (pid1 === "sh") how = "killed";            // sh has no trap, PID 1 ignores TERM
  else if (pid1 === "app") how = c.handler ? "clean" : "killed"; // no handler: ignored
  else how = c.handler ? "clean" : "term";      // init forwards; app is not PID 1
  if (how === "clean") return { pid1, sec: 0, code: 0 };
  if (how === "term") return { pid1, sec: 0, code: 128 + 15 }; // SIGTERM default action
  return { pid1, sec: grace, code: 128 + 9 };   // SIGKILL after the grace period
}
const cases = [
  ["shell form with pipe", { shellStays: true, handler: true }],
  ["exec form + handler", { handler: true }],
  ["script without exec", { shellStays: true, handler: true }],
  ["script with exec", { handler: true }],
  ["exec form, no handler", { handler: false }],
  ["--init, no handler", { init: true, handler: false }],
];
console.log("case                    PID1  wait_s  exit");
for (const [name, c] of cases) {
  const r = stop(c);
  console.log(name.padEnd(24) + r.pid1.padEnd(6) + String(r.sec).padStart(6) + String(r.code).padStart(6));
}

case                    PID1  wait_s  exit
shell form with pipe    sh        10   137
exec form + handler     app        0     0
script without exec     sh        10   137
script with exec        app        0     0
exec form, no handler   app       10   137
--init, no handler      init       0   143

৮ · Secret layer-এ রাখবেন না

পর্ব ৩৩-এ secret নিয়ে মূল নীতি দেখেছেন। Image-এর ক্ষেত্রে একটি বাড়তি বিপদ আছে: layer মুছে ফেলা যায় না। যে image পাবে, সে সব layer আর সব metadata-ও পাবে। আর image প্রায়ই অনেক হাতে যায়: registry, CI, সহকর্মী, এমনকি public repository-তে।

FROM alpine:3.20
ENV API_KEY=fake-demo-key-000
RUN echo "app configured"
CMD ["sh"]

1 warning found (use docker --debug to expand):
 - SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions
   for sensitive data (ENV "API_KEY") (line 2)

$ docker history --no-trunc --format '{{.Size}}  {{.CreatedBy}}' abcl-dp-leak
0B  CMD ["sh"]
4.1kB  RUN /bin/sh -c echo "app configured" # buildkit
0B  ENV API_KEY=fake-demo-key-000
0B  CMD ["/bin/sh"]

$ docker image inspect abcl-dp-leak --format '{{json .Config.Env}}'
["PATH=…","API_KEY=fake-demo-key-000"]

# docker build --build-arg DB_PASS=fake-pass-000 …
RUN |1 DB_PASS=fake-pass-000 /bin/sh -c echo "connecting" > /note.txt
ARG DB_PASS=fake-pass-000

# COPY api_key.txt, তারপর RUN rm:
8.19kB  RUN /bin/sh -c rm /tmp/api_key.txt # buildkit
12.3kB  COPY api_key.txt /tmp/api_key.txt # buildkit

$ docker build --secret id=api_key,src=api_key.txt …
# Dockerfile:
RUN --mount=type=secret,id=api_key \
    sh -c 'wc -c < /run/secrets/api_key > /key-bytes.txt'

$ docker history --no-trunc --format '{{.Size}}  {{.CreatedBy}}' abcl-dp-safe
0B  CMD ["sh"]
8.19kB  RUN /bin/sh -c sh -c 'wc -c < /run/secrets/api_key > /key-bytes.txt' # buildkit

$ docker run --rm abcl-dp-safe sh -c 'cat /key-bytes.txt; ls -A /run/secrets'
17
ls: /run/secrets: No such file or directory

Build secret লাগে build-এর সময়, যেমন private package registry-র token-এর জন্য। আর app চলার সময়ের secret image-এ নয়, runtime-এ আসবে: orchestrator-এর secret, secret manager, বা পর্ব ৩৩-এর পদ্ধতিতে। Multi-stage-ও এখানে একা ভরসা নয়; final image নিরাপদ হলেও build stage-এর cache-এ secret থেকে যেতে পারে, যদি তা ENV বা COPY দিয়ে আসে।

৯ · ছোট অভ্যাস, বড় ফল — ignore, ক্রম, পরিষ্কার, label আর lint

.dockerignore: বাক্সে কী যাবে

docker build শুরুতেই ফোল্ডারের ফাইলগুলো builder-এর কাছে পাঠায়। একে বলে build context. COPY . . লিখলে ওই ফোল্ডারের সব কিছু image-এ ঢোকে, এমনকি .env আর .git-ও। .dockerignore ফাইল এটি আটকায়। একটি ফোল্ডারে ২০MB .git, ৩০MB node_modules, একটি নকল .env আর ছোট app.py রেখে দেখা হলো:

# .dockerignore ছাড়া
#4 transferring context: 50.01MB 3.8s done
$ docker run --rm abcl-dp-ctx1
.
..
.env
.git
Dockerfile
app.py
node_modules
abcl-dp-ctx1 62.2MB

# .dockerignore দেওয়ার পর
$ cat .dockerignore
.git
node_modules
.env
*.log
Dockerfile
.dockerignore

#4 transferring context: 27B done
$ docker run --rm abcl-dp-ctx2
.
..
app.py
abcl-dp-ctx2 12.1MB

Context ৫০.০১MB থেকে ২৭ বাইটে নেমেছে, আর .env image-এ ঢোকেনি। অর্থাৎ এটি শুধু গতির নয়, নিরাপত্তারও বিষয়। আরেকটি ভালো অভ্যাস হলো COPY . .-এর বদলে দরকারি ফাইলের নাম লেখা।

Layer-এর ক্রম: কম বদলায় যা, তা আগে

পর্ব ৩৭-এর build cache-এর নিয়ম মনে করুন: একটি ধাপের input বদলালে সেই ধাপ আর তার পরের সব ধাপ আবার চলে। তাই যা কম বদলায় (dependency), তা আগে; যা ঘন ঘন বদলায় (আপনার code), তা পরে। একটি Python app-এ app.py-র একটি লাইন বদলে দুই Dockerfile আবার build করা হলো:

# খারাপ ক্রম: COPY . . আগে, pip পরে
#6 [2/4] WORKDIR /app
#6 CACHED
#7 [3/4] COPY . .
#7 DONE 0.1s
#8 [4/4] RUN pip install --no-cache-dir -r requirements.txt
#8 DONE 2.6s

# ভালো ক্রম: requirements.txt আগে, pip, তারপর COPY . .
#6 [2/5] WORKDIR /app
#6 CACHED
#7 [3/5] COPY requirements.txt .
#7 CACHED
#8 [4/5] RUN pip install --no-cache-dir -r requirements.txt
#8 CACHED
#9 [5/5] COPY . .
#9 DONE 0.0s

এখানে dependency মাত্র Flask, তাই ক্ষতি ২.৬ সেকেন্ড। বড় প্রজেক্টে এই ধাপ কয়েক মিনিটও হতে পারে, আর দিনে বহুবার চলে।

Package cache: একই layer-এ পরিষ্কার

আগের layer বদলানো যায় না। তাই পরের RUN-এ মুছলে ফাইল শুধু আড়াল হয়, image ছোট হয় না। আসল মাপ:

# তিনটি আলাদা RUN
16.4kB  RUN /bin/sh -c rm -rf /var/cache/apk/* # bui…
6.15MB  RUN /bin/sh -c apk add curl # buildkit
2.34MB  RUN /bin/sh -c apk update # buildkit

# একটি RUN
6.15MB  RUN /bin/sh -c apk add --no-cache curl # bui…

abcl-dp-split 25.5MB
abcl-dp-one 20.8MB

apk update-এর ২.৩৪MB layer-এ রয়ে গেছে, পরের rm তা কমাতে পারেনি। Alpine-এ সহজ পথ apk add --no-cache. Debian বা Ubuntu-তে একই নিয়ম এক RUN-এ লিখতে হয়:

RUN apt-get update \
 && apt-get install -y --no-install-recommends curl \
 && rm -rf /var/lib/apt/lists/*

apt-get update আর install একই RUN-এ রাখার আরেকটি কারণ আছে: আলাদা হলে পুরোনো cache-করা তালিকা দিয়ে পরে ভুল version খোঁজা হতে পারে।

ADD নয়, COPY

COPY শুধু build context থেকে ফাইল কপি করে। ADD বাড়তি দুটি কাজ করে: স্থানীয় tar ফাইল নিজে থেকে খুলে দেয়, আর URL থেকে ফাইল নামাতে পারে। এই লুকানো আচরণের জন্য সাধারণ ফাইলে COPY-ই ভালো, কারণ পড়লেই বোঝা যায় কী ঘটছে। সত্যিই tar খোলার দরকার হলে ADD ঠিক আছে। URL থেকে কিছু নামালে তার checksum যাচাই করা জরুরি, নইলে অন্যের ফাইল বদলালে আপনার image-ও চুপচাপ বদলে যাবে।

LABEL: image-এর পরিচয়পত্র

Label image-এ key-value তথ্য জোড়ে, যেমন version, source repository বা দলের নাম। OCI-র প্রমিত নাম org.opencontainers.image.* ব্যবহার করলে অন্য টুলও এটি বোঝে।

LABEL org.opencontainers.image.title="abcl-demo" \
      org.opencontainers.image.version="1.0.0"

$ docker image inspect abcl-dp-hc --format '{{json .Config.Labels}}'
{"org.opencontainers.image.title":"abcl-demo","org.opencontainers.image.version":"1.0.0"}

Lint: মেশিন আগে দেখুক

এত নিয়ম মনে রাখা কঠিন, তাই linter ব্যবহার করুন। নিচের ছোট simulator পাঁচটি নিয়ম দেখে। Dockerfile বদলে চালিয়ে দেখুন।

// Tiny Dockerfile linter. Edit the Dockerfiles below and run again.
const bad = `FROM python:latest
ENV API_KEY=fake-demo-key-000
ADD app.py /app/app.py
CMD python /app/app.py`;
const good = `FROM python:3.12-alpine
ARG APP_VERSION=1.0.0
RUN adduser -D -u 10001 app
COPY app.py /app/app.py
USER 10001
CMD ["python", "/app/app.py"]`;
const SECRET = /(KEY|TOKEN|SECRET|PASS(WORD)?)(=|\s|$)/i;
function lint(text) {
  const out = []; let user = "root";       // default user of a stage
  text.split("\n").forEach((line, i) => {
    const [op, ...rest] = line.trim().split(/\s+/);
    const arg = rest.join(" "), n = "line " + (i + 1) + ": ";
    if (op === "FROM") {
      user = "root";                       // USER resets in every stage
      const noPin = !/[:@]/.test(rest[0]) || /:latest$/.test(rest[0]);
      if (noPin && rest[0] !== "scratch") out.push(n + "ERROR latest or no tag");
    }
    if (op === "ADD" && !/\.tar|\.tgz/.test(arg)) out.push(n + "WARN  use COPY, not ADD");
    if ((op === "ENV" || op === "ARG") && SECRET.test(arg)) out.push(n + "ERROR secret in " + op);
    if ((op === "CMD" || op === "ENTRYPOINT") && arg[0] !== "[") out.push(n + "WARN  shell form " + op);
    if (op === "USER") user = rest[0];
  });
  if (user === "root" || user === "0") out.push("end: ERROR final stage runs as root");
  return out;
}
for (const [name, text] of [["bad", bad], ["good", good]]) {
  const found = lint(text);
  console.log(name + ": " + found.length + " finding(s)");
  found.forEach(f => console.log("  " + f));
}

bad: 5 finding(s)
  line 1: ERROR latest or no tag
  line 2: ERROR secret in ENV
  line 3: WARN  use COPY, not ADD
  line 4: WARN  shell form CMD
  end: ERROR final stage runs as root
good: 0 finding(s)

Docker-এর নিজেরও একটি পরীক্ষা আছে, docker build --check, যা image না বানিয়ে শুধু নিয়ম দেখে। ওই একই খারাপ Dockerfile-এ আসল ফল:

$ docker build --check .
…
Check complete, 2 warnings have been found!

WARNING: SecretsUsedInArgOrEnv - https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/
Do not use ARG or ENV instructions for sensitive data (ENV "API_KEY")
…
WARNING: JSONArgsRecommended - https://docs.docker.com/go/dockerfile/rule/json-args-recommended/
JSON arguments recommended for CMD to prevent unintended behavior related to OS signals
…

লক্ষ করুন, এটি দুটি ধরেছে, পাঁচটি নয়; latest, ADD বা root নিয়ে এটি কিছু বলেনি। তাই বাড়তি টুল হিসেবে hadolint ব্যবহার করতে পারেন। এটি Dockerfile-এর নিয়মের পাশাপাশি RUN-এর ভেতরের shell কোড ShellCheck দিয়ে দেখে। লেখার সময়ে এর পরিচিত নিয়মের মধ্যে আছে DL3007 (latest), DL3002 (শেষ USER root), DL3020 (ADD-এর বদলে COPY) আর DL3025 (CMD-এ JSON). এটি এই পর্বে চালানো হয়নি, তাই কোনো আউটপুট দেখানো হলো না। নিয়মের নম্বর মেলাতে অফিসিয়াল তালিকা দেখে নেবেন। পর্ব ৫৭ আর পর্ব ৬১-এ pipeline-এ এমন পরীক্ষা বসানো আসবে।

সব একসাথে

নিচের Dockerfile-এ এই পর্বের বেশিরভাগ অভ্যাস একসাথে আছে। এটি আসলেই build করে চালানো হয়েছে: docker build --check বলেছে Check complete, no warnings found., আর ভেতরে Flask পাওয়া গেছে uid 10001 হিসেবে। Image-এর মাপ এসেছে 81.4MB, যেখানে এক stage-এর ভালো ক্রমের image ছিল 94.4MB.

# ---- stage 1: install dependencies ----
FROM python:3.12-alpine AS deps
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

# ---- stage 2: what actually ships ----
FROM python:3.12-alpine
LABEL org.opencontainers.image.title="bazar-api" \
      org.opencontainers.image.version="1.0.0"
RUN addgroup -S -g 10001 app && adduser -S -D -H -u 10001 -G app app
WORKDIR /app
COPY --from=deps /install /usr/local
COPY app.py .
USER 10001:10001
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -q -O /dev/null http://127.0.0.1:8080/health || exit 1
ENTRYPOINT ["python", "-u", "app.py"]

লাইন ধরে মিলিয়ে দেখুন: dependency আলাদা stage-এ, তাই pip-এর জিনিসপত্র final-এ আসে না। requirements.txt আগে, তাই cache কাজে লাগে। USER সংখ্যায়, তাই root নয়। ENTRYPOINT JSON-এ, তাই python নিজেই PID 1. কোনো secret নেই, আর app-কে SIGTERM ধরতে হবে নিজের কোডে। Production-এ FROM-এ digest যোগ করে নিন; এখানে পড়ার সুবিধার জন্য বাদ রাখা হয়েছে।

১০ · AI-এর যুগে — Dockerfile যাচাই

AI কয়েক সেকেন্ডে Dockerfile লিখে দেয়, আর সেটি সাধারণত build-ও হয়। কিন্তু আগেই দেখেছেন, build হওয়া মানেই ভালো নয়। AI প্রায়ই latest লেখে, root-এ চালায়, ENV-এ key বসায়, COPY . . ব্যবহার করে, .dockerignore ভুলে যায়, আর শেষ হওয়া base image বা নেই এমন flag সুপারিশ করে।

AI-এর উত্তর পাওয়ার পর এই চেকলিস্ট মেলান:

• docker build --check চালিয়েছি, আর সম্ভব হলে hadolint-ও
• FROM-এর tag সত্যিই আছে এবং সমর্থিত, আর latest নেই
• docker run --rm <image> id বা app-এর log-এ uid দেখেছি, 0 নয়
• docker history --no-trunc আর docker image inspect-এ কোনো secret নেই
• docker stop-এর সময় মেপেছি, আর exit code 137 নয়
• .dockerignore-এ .env আর .git আছে; context-এর মাপ দেখেছি
• Image-এর মাপ আগের সাথে মিলিয়েছি, আর অপরিচিত flag অফিসিয়াল ডকুমেন্টে দেখেছি
• Prompt-এ কোনো আসল secret পেস্ট করিনি