امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 97
Docker Compose: Dependencies, Health و Restart
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Docker Compose: Dependencies, Health و Restart». می‌تواند برای «Docker Compose: Dependencies, Health و Restart» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Docker Compose: Dependencies, Health و Restart».
می‌تواند برای «Docker Compose: Dependencies, Health و Restart» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «Docker Compose: Dependencies, Health و Restart» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
1. مسئله: «container اجرا شد» یعنی «service آماده است» نیست
در یک stack چندسرویسی، ترتیب ساخت یا start شدن containerها فقط بخشی از واقعیت runtime است. یک dependency می‌تواند Running باشد ولی هنوز endpoint موردنیاز را نپذیرد، migration تمام نشده باشد، یا healthcheck هنوز fail شود. همین‌طور restart شدن یک dependency همیشه به این معنی نیست که dependent هم restart می‌شود.
خروجی مالک این درس Compose Dependency Health Restart Record v1 است. این رکورد graph، شرط dependency، health contract، observationهای start/ready، one-shot completion، trigger مربوط به restart و recovery evidence را جدا ثبت می‌کند.
2. dependency graph ابتدا ترتیب را مشخص می‌کند
Compose از رابطه‌های dependency برای ترتیب create/start و remove استفاده می‌کند. اگر web به db وابسته باشد، Compose ابتدا dependency را ایجاد و start می‌کند.
این ordering یک observation مهم است، اما هنوز readiness یا business correctness را ثابت نمی‌کند. در رکورد، graph و startup order را مستقل از health ثبت کن.
3. short-form depends_on فقط «started» را می‌بندد
در short syntax، سرویس‌های dependency پیش از dependent start می‌شوند، اما Compose منتظر healthy شدن آن‌ها نمی‌ماند. این distinction علت رایج race در startup است: process بالا آمده ولی سرویس هنوز درخواست واقعی را قبول نمی‌کند.
در Lab یک fixture دقیقاً همین وضعیت را ایجاد می‌کند: dependency Running است ولی ready=false. نتیجه باید START_ORDER_ONLY_NOT_READY باشد، نه «Compose خراب است».
4. long-form condition قرارداد dependency را صریح می‌کند
در long-form depends_on می‌توان شرط satisfaction را مشخص کرد. سه شرط اصلی مورد استفاده این درس عبارت‌اند از service_started، service_healthy و service_completed_successfully.
شرط را باید بر اساس قرارداد واقعی dependency انتخاب کرد. برای یک سرویس طولانی‌مدت که باید آماده پاسخ‌گویی باشد، service_started ممکن است ناکافی باشد؛ برای یک job یک‌باره، health semantics ممکن است اصلاً مفهوم اصلی نباشد.
5. service_healthy به healthcheck وابسته است
service_healthy فقط وقتی معنا دارد که dependency یک healthcheck تعریف‌شده داشته باشد و آن healthcheck به وضعیت healthy برسد. Compose می‌تواند start dependent را تا رسیدن dependency به health مورد انتظار به‌تعویق بیندازد.
اما healthcheck فقط همان probe تعریف‌شده را اثبات می‌کند. سبز بودن probe به‌تنهایی تمام نیازمندی‌های business، data correctness یا downstream authorization را ثابت نمی‌کند.
6. healthcheck باید contract قابل توضیح داشته باشد
یک healthcheck خوب باید مشخص کند چه چیزی را probe می‌کند، چه چیزی را probe نمی‌کند، interval/timeout/retries/start-period چه نقشی دارند و چه evidenceی از readiness می‌سازد.
در Record، command یا contract probe را با observation واقعی health جدا نگه دار. اگر probe ناقص است، نتیجه را بیش از محدوده probe گسترش نده.
7. service_completed_successfully برای dependency یک‌باره است
بعضی dependencyها daemon نیستند؛ یک initializer یا migration job باید اجرا شود و با exit code موفق تمام شود. در چنین حالتی service_completed_successfully semantics متفاوتی از service_healthy دارد.
Lab یک one-shot initializer دارد. اگر exit result موفق نباشد، dependent نباید صرفاً به‌خاطر Running بودن بقیه سرویس‌ها «آماده» تلقی شود.
8. failure probe باید shortcut قابل‌باوری را رد کند
یک stack ممکن است با short-form شروع شود و در اجرای اول هم تصادفاً کار کند. این happy path ثابت نمی‌کند configuration درست است. evidence قوی باید failure قابل‌کنترل ایجاد کند.
در fixture، readiness dependency عمداً عقب می‌افتد. اگر dependent فقط به start order متکی باشد، race آشکار می‌شود؛ وقتی شرط به service_healthy تغییر می‌کند، همان evidence باید تغییر کند.
9. depends_on restart: true یک semantics محدود دارد
در مستندات فعلی Compose، restart: true در long-form dependency به restart/update صریح dependency توسط عملیات Compose مربوط است و dependent را برای reconnect/re-establish شدن restart می‌کند.
این رفتار را با restart policy خود container runtime یکی نکن. «dependency به‌علت crash و policy داخلی دوباره بالا آمد» یک trigger متفاوت است.
10. runtime restart policy یک لایه جداست
Policyهایی مانند restart behavior container تعیین می‌کنند runtime با container مرده چه کند. این policy مستقل از dependency restart linkage در Compose است.
در Lab، یک case explicit Compose restart و یک case runtime crash/restart جدا وجود دارد. Record باید نشان دهد چرا evidence این دو case یکسان نیست.
11. shutdown order هم از dependency graph اثر می‌گیرد
Compose در teardown نیز dependency order را لحاظ می‌کند و dependentها پیش از dependencyهای خود حذف می‌شوند. این observation برای تحلیل lifecycle مهم است، اما shutdown ordering جای graceful shutdown داخل application را نمی‌گیرد.
در این درس shutdown order را فقط در حد boundary همین dependency graph ثبت می‌کنیم.
12. application باید در برابر dependency failure مقاوم باشد
حتی یک Compose file دقیق هم تضمین نمی‌کند dependency هرگز بعداً fail نکند. retry، timeout، circuit breaking یا degraded mode مسئولیت‌های application/architecture هستند و صرف depends_on جای آن‌ها را نمی‌گیرد.
Record باید unknownها و residual riskها را باقی بگذارد؛ configuration success به معنی resilience کامل نیست.
13. Compose Dependency Health Restart Record v1
این Artifact برای هر dependency این موارد را ثبت می‌کند: dependent → dependency edge، condition، health/one-shot contract، observed startup state، ready state، failure injection، explicit restart trigger، runtime restart behavior، recovery observation و residual assumption.
Observation، inference و unknown را از هم جدا نگه دار. اگر evidence निर्णکننده وجود ندارد، claim را OPEN بگذار.
14. Lab و Transfer
Lab کاملاً offline و synthetic است و هشت fixture دارد. هر fixture event/health/completion/restart facts را از یک stack کوچک مدل می‌کند. هیچ Docker registry، production service، credential یا network خارجی لمس نمی‌شود.
Transfer یک dependency غیرسخت را تغییر می‌دهد، readiness signal را عوض می‌کند، نتیجه initializer را تغییر می‌دهد و restart linkage را حذف می‌کند. هر هشت state باید از evidence جدید دوباره محاسبه شوند.
15. منابع، freshness و مرز ادعا
در 2026-09-19 مستندات رسمی Docker دوباره بررسی شدند: Compose هنوز startup/shutdown order را از dependencyها می‌گیرد؛ Running با Ready یکی نیست؛ long-form conditionهای service_started، service_healthy و service_completed_successfully را ارائه می‌کند؛ و restart: true dependency را از restart خودکار runtime پس از مرگ container جدا می‌کند.
این رفتارها tool-sensitive هستند و مرور بعدی برای 2026-10-17 ثبت شده است. هر تغییر material در Compose docs یا fixture باعث requalification نسخه جدید package می‌شود.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
OPS-004-S1 retrieval
State the bounded Compose dependency model and one non-goal.
OPS-004-S2 application
Complete Compose Dependency Health Restart Record v1 for a supplied synthetic dependency graph using only fixture evidence.
OPS-004-S3 diagnosis
Diagnose a started-not-ready, failed-health, or failed-one-shot case without blaming an unchanged layer.
OPS-004-S4 decision
Distinguish an explicit Compose dependency restart from an automated runtime crash restart and choose a bounded recovery check.
OPS-004-S5 transfer
Rebuild the record for a changed dependency condition, readiness signal, completion result, and restart linkage without copying baseline conclusions.
ملاک‌های ارزیابی (rubric)
A sufficient submission must satisfy all critical dimensions:
- Dependency-model correctness — graph, startup order, condition, readiness, one-shot completion, and restart semantics remain distinct.
- Evidence quality — direct observations are traceable; inference and unknowns are labeled.
- Scope discipline — health is not business correctness; Compose ordering is not application resilience or universal orchestration.
- Recovery proof — the failed condition or restart distinction is re-observed after a bounded repair/change.
- Transfer independence — the changed-context case is recomputed from its own evidence.
Blocking failure occurs when Running is treated as Ready, explicit Compose restart is collapsed into runtime restart policy, or transfer copies a baseline verdict.
منابع و تازگی
مطالعهٔ موارد (case studies)
A database becomes healthy before the web service starts; startup order and readiness evidence both close.
Short-form depends_on starts the dependency but readiness remains false; treating Running as Ready is rejected.
A one-shot initializer exits non-zero, so service_completed_successfully remains unsatisfied even while long-running services are healthy.
A changed dependency condition, readiness signal, one-shot result, and restart linkage require a fresh operations record.
تصاویر درس
فایل‌های آزمایشگاه
Everything is local and synthetic. No Docker registry, production service, credential, host mutation, or external network request is used.
For each fixture produce eight states: dependency_graph_state, startup_order_state, dependency_condition_state, health_readiness_state, completion_gate_state, restart_semantics_state, evidence_boundary_state, and recovery_decision_state.
Rules:
- Dependency order is not readiness.
service_startedcloses only the start condition.service_healthyis bounded to the declared healthcheck.service_completed_successfullyis evaluated from one-shot completion evidence.- Dependency
restart: trueapplies to explicit Compose-controlled restart/update evidence, not arbitrary runtime crash restart. - Application retry/resilience remains outside the Compose ordering conclusion.
- If decisive evidence is absent, leave the conclusion OPEN.
- The transfer fixture must be recomputed from its changed condition and restart linkage.
Run python -B run_checks.py for learner-visible structural checks. Hidden acceptance lives outside learner paths.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)