امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 96

Docker/OCI: Image, Layer, Volume, Network, Digest

می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Docker/OCI: Image, Layer, Volume, Network, Digest». می‌تواند برای «Docker/OCI: Image, Layer, Volume, Network, Digest» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.

Docker/OCI: Image, Layer, Volume, Network, Digest — en-US

خلاصهٔ درس

می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Docker/OCI: Image, Layer, Volume, Network, Digest».

می‌تواند برای «Docker/OCI: Image, Layer, Volume, Network, Digest» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.

خروجی این درس

می‌تواند برای «Docker/OCI: Image, Layer, Volume, Network, Digest» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.

پیش‌نیازها

1. مسئله: یک «اسم image» چند هویت مختلف را پنهان می‌کند

در کار عملی، عبارت‌هایی مثل app:latest، یک digest، یک image manifest، یک container در حال اجرا و فایل‌هایی که داخل container دیده می‌شوند ممکن است به‌اشتباه یک چیز فرض شوند. همین shortcut باعث می‌شود rollout، rollback، persistence و عیب‌یابی قابل‌اتکا نباشند.

خروجی مالک این درس Container Image Runtime Boundary Record v1 است. این رکورد tag/reference، digest، manifest/config/layer، platform، container ID، writable layer، mountها، network attachment و evidence مربوط به replacement را جدا نگه می‌دارد.

2. OCI image یک ساختار محتوامحور است

OCI Image Specification یک image را با manifest، config، مجموعه filesystem layerها و در صورت نیاز image index توصیف می‌کند. این ساختار برای interoperability طراحی شده است و با «یک container در حال اجرا» یکسان نیست.

در Record، descriptor/manifest/config/layer evidence را از runtime observation جدا ثبت کن. اگر فقط خروجی یک CLI را داری و ساختار OCI را ندیده‌ای، آن را به‌عنوان inference علامت بزن، نه fact کامل.

3. Descriptor و digest مرز هویت محتوا را می‌سازند

OCI descriptor برای محتوای referenced، media type، size و digest دارد. digest برای verification محتوای referenced به‌کار می‌رود و باید از tag انسانی جدا بماند.

یک tag برای انسان خواناتر است، اما ممکن است در زمان دیگری به محتوای دیگری اشاره کند. پس app:stable و sha256:... دو نوع identifier با semantics متفاوت‌اند.

4. Tag با digest یکی نیست

در یک registry یا layout، tag/reference یک نام یا pointer است؛ digest هویت محتوامحور referenced content را نشان می‌دهد. اگر همان image را با یک tag دوم نام‌گذاری کنی، متن tag عوض می‌شود اما محتوای digest‌شده لزوماً عوض نشده است.

Lab یک retag synthetic دارد. نتیجه درست باید نشان دهد که تغییر tag به‌تنهایی evidence تغییر content identity نیست.

5. Manifest، config و filesystem layers نقش‌های جدا دارند

Manifest به config و layer descriptorها اشاره می‌کند. config metadata و runtime-oriented image configuration را حمل می‌کند؛ layerها filesystem changes را تشکیل می‌دهند.

در Record، «manifest digest»، «config digest» و «layer evidence» را در یک سلول ادغام نکن. یک image می‌تواند چند descriptor مرتبط داشته باشد و هر کدام باید با claim محدود خود ثبت شوند.

6. Image layer با writable container layer یکی نیست

Docker imageها immutable و layer-based هستند. وقتی container اجرا می‌شود، تغییرات runtime به writable layer مخصوص همان container می‌روند، نه اینکه image layerهای immutable به‌صورت خودکار تغییر کنند.

اگر داخل container فایلی بسازی و سپس container را حذف و از همان image دوباره ایجاد کنی، آن write باید به‌عنوان state مربوط به container قبلی تحلیل شود؛ نه «image تغییر کرد».

7. Named volume persistence یک boundary مستقل است

Volume برای data persistence خارج از lifecycle یک container منفرد طراحی شده است. جایگزینی container لزوماً volume را حذف نمی‌کند؛ بنابراین persistence در volume باید از writable layer تفکیک شود.

Lab یک case دارد که container جایگزین می‌شود اما volume data باقی می‌ماند. این evidence درباره storage boundary است، نه درباره correctness application.

8. Bind mount با volume یک coupling متفاوت دارد

Bind mount یک path میزبان را داخل container نمایان می‌کند. بنابراین state آن به host path وابسته است و همان semantics مدیریت‌شده volume را ندارد.

در Record مشخص کن mount از نوع managed volume است یا bind mount، source آن چیست و evidence persistence/coupling از کجا آمده است. صرف دیدن فایل داخل container برای تشخیص نوع mount کافی نیست.

9. Image index و platform را حدس نزن

OCI image index می‌تواند چند manifest را برای platformهای مختلف reference کند. tag مشترک ممکن است بر اساس platform به manifest متفاوتی resolve شود.

Lab یک platform variant synthetic دارد. اگر platform یا selected manifest evidence موجود نباشد، claim باید OPEN بماند؛ نام image به‌تنهایی برای نتیجه platform کافی نیست.

10. Container یک runtime instance است

Container از image/config ساخته می‌شود اما هویت runtime مستقل خود را دارد: container ID، process state، writable layer، mounts و network attachment. دو container از یک image digest می‌توانند runtime state متفاوت داشته باشند.

به همین دلیل Record همیشه image identity و container identity را در ستون‌های جدا ثبت می‌کند.

11. Network attachment جزو immutable image نیست

Network attachment در runtime تعیین می‌شود. Docker networking containerها را به networkهای مشخص متصل می‌کند؛ این attachment از image filesystem layers یا digest نتیجه‌گیری نمی‌شود.

در Lab، network name و attachment evidence صریح است. اگر این evidence حذف شود، network claim نباید از Dockerfile، tag یا image digest حدس زده شود.

12. Digest اثبات محدودی ارائه می‌کند

Matching digest می‌تواند نشان دهد referenced bytes با digest مورد انتظار سازگارند. اما digest به‌تنهایی application health، security posture، publisher trust یا business correctness را اثبات نمی‌کند.

این lesson فقط content identity boundary را می‌بندد. provenance/signing، readiness و orchestration outcomes در scope این درس نیستند مگر به‌اندازه‌ای که برای مرزبندی لازم باشد.

13. Container Image Runtime Boundary Record v1

این Artifact حداقل این fields را ثبت می‌کند: Image Tag/Reference، Image Digest، Platform، Manifest/Config، Layer Evidence، Container ID، Writable-Layer Change، Named Volume، Bind Mount، Network Attachment، Replacement Result، direct observations، inferences، unknowns و final bounded decision.

هر field باید source evidence خودش را داشته باشد. اگر evidence decisive حذف شود، decision باید EVIDENCE_INSUFFICIENT_OPEN بماند.

14. Lab و Transfer

Lab کاملاً offline و synthetic است. هشت fixture مدل می‌کنند: baseline، retag همان content، writable-layer loss پس از replacement، named-volume persistence، bind-mount host coupling، platform/manifest distinction، missing evidence و یک transfer case با context تغییرکرده.

هیچ registry، credential، production system یا network خارجی استفاده نمی‌شود. Transfer باید همه stateها را از evidence جدید بازسازی کند و اجازه copy کردن diagnosis baseline را نمی‌دهد.

15. منابع، freshness و مرز ادعا

در 2026-09-19 منابع رسمی OCI و Docker دوباره بررسی شدند. OCI Image Spec همچنان image را با manifest، optional index، filesystem layers و configuration تعریف می‌کند؛ descriptor digest برای content reference/verification استفاده می‌شود؛ Docker همچنان image را immutable/layered، container state را دارای writable layer جدا، storage را شامل volume/bind/tmpfs و network attachment را runtime concern توصیف می‌کند.

این ادعاها tool/spec-sensitive هستند. مرور بعدی برای 2026-10-17 ثبت شده است و هر تغییر material در OCI Image Spec، Docker storage/network semantics یا fixture نیازمند requalification نسخه جدید package است.

ارزیابی

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

OPS-003-S1 retrieval

State the bounded OCI/container runtime model and one non-goal.

lesson ✗AI ✗notes ✗

OPS-003-S2 application

Complete Container Image Runtime Boundary Record v1 for a supplied local fixture using only direct evidence.

lesson ✗AI ✗notes ✗

OPS-003-S3 diagnosis

Diagnose a retag, writable-layer loss, persistence, platform, or missing-evidence case without changing an unrelated boundary.

lesson ✗AI ✗notes ✗

OPS-003-S4 decision

Defend a bounded tag/digest, image/container, storage, and network conclusion against a plausible shortcut.

lesson ✗AI ✗notes ✗

OPS-003-S5 transfer

Rebuild the record for a changed digest/platform/mount/network context without copying baseline conclusions.

lesson ✗AI ✗notes ✗
ملاک‌های ارزیابی (rubric)

A sufficient submission must satisfy all critical dimensions:

  1. Runtime/configuration model correctness — tag, digest, OCI structure, container instance, writable state, mounts, and network attachment remain distinct.
  2. Evidence quality — positive and negative observations are traceable; inference and unknowns are labeled.
  3. Scope discipline — digest is not promoted to health, trust, security, or application correctness; runtime/storage/network claims stay within evidence.
  4. Transfer independence — the changed-context case is recomputed from its own evidence.

Blocking failure occurs when tag is treated as immutable identity, container writable state is called an image layer, volume/bind data is called part of the image, or transfer copies the baseline verdict.

منابع و تازگی

Open Container Initiative — Image Format Specification
·
Open Container Initiative — Descriptor Specification
·
Docker Docs — What is an image?
·
Docker Docs — Understanding image layers
·
Docker Docs — Storage
·
Docker Docs — Networking overview
·
MAKNOW instructional evidence design
·

مطالعهٔ موارد (case studies)

SIMPLE

A digest-pinned OCI image is inspected, a disposable container is run, and image identity is kept separate from container runtime identity.

WRONG_APPROACH

The same image content is retagged and a learner incorrectly treats the new tag text as a new immutable content identity.

EDGE_OR_FAILURE

Data written only to the container writable layer disappears after replacement while data in a named volume persists.

TRANSFER_NEAR

A changed tag points to a different digest/platform, the persistent mount changes, and network attachment must be recomputed from new evidence.

تصاویر درس

OPS003-V1

فایل‌های آزمایشگاه

This lab is fully local and synthetic. It models evidence that would be observed from preloaded OCI/Docker artifacts, disposable containers, a named volume, a bind-mounted test directory, and runtime network attachment.

No registry, credential, production host, privileged operation, or external network is required. Do not point the fixture at real infrastructure.

Your task is to implement analyze(case) in starter.py and produce one state for each of the eight dimensions. Keep tag/digest, image/container, writable/persistent storage, and network evidence separate. Missing decisive evidence must stay OPEN.

رسانه و اسلایدهای درس

MAKNOW_OPS-003_DECISION_EVIDENCE_TABLE_v1.0.0.svg
DECISION EVIDENCE TABLE v1.0.0.svg
MAKNOW_OPS-003_FAILURE_REPAIR_v1.0.0.svg
FAILURE REPAIR v1.0.0.svg
MAKNOW_OPS-003_PRIMARY_MODEL_v1.0.0.svg
PRIMARY MODEL v1.0.0.svg
MAKNOW_OPS-003_WORKED_EXAMPLE_v1.0.0.svg
WORKED EXAMPLE v1.0.0.svg

فایل‌های آموزشی (دانلود)

XLSXContainer Image Runtime Boundary Record v1 v1.0.0.xlsxفایل‌های آموزشی (دانلود)
DOCXContainer Image Runtime Boundary Record v1 WORKSHEET v1.0.0.docxفایل‌های آموزشی (دانلود)
PDFContainer Image Runtime Boundary Record v1 WORKSHEET v1.0.0.pdfفایل‌های آموزشی (دانلود)