DevOps برای توسعه‌دهنده وب؛ Docker، CI/CD و Kubernetes

Release ساعت ۱۰ صبح سبز شده، اما سه دقیقه بعد کاربران خطای ۵۰۲ می‌بینند؛ Pipeline فقط ساخته‌شدن Image را سنجیده، نه آمادگی برنامه برای دریافت Traffic را. DevOps یعنی فاصله میان Commit و نتیجه Production را با مالکیت، بازخورد و کنترل کوتاه کنیم. Docker، CI/CD و Kubernetes می‌توانند این مسیر را بهتر کنند، اما هیچ‌کدام به‌تنهایی فرهنگ همکاری، امنیت زنجیره تأمین یا بازیابی را ایجاد نمی‌کنند.

این راهنما برای توسعه‌دهنده وبی است که می‌خواهد بداند چه چیزی را، به چه ترتیبی و تا چه عمقی یاد بگیرد. از Delivery contract و Container تا Pipeline امن، Orchestration، Observability و عملیات ایران پیش می‌رویم و هرجا پیچیدگی ابزار از مسئله بزرگ‌تر است، صریحاً توقف می‌کنیم.

DevOps چیست و چه چیزی نیست؟

DevOps مجموعه‌ای از شیوه‌های فنی و سازمانی برای تحویل سریع‌تر و قابل‌اعتمادتر تغییر است. نقطه اتصال Development، Operations، Security، QA، Product و Support فقط یک ابزار یا عنوان شغلی نیست؛ یک Flow مشترک با Outcome، Owner و Feedback است.

قبل از ابزار، Delivery contract بنویسید

برای یک سرویس وب، این قرارداد را در Repository نگه دارید:

• Source of truth کد، Dependency و Configuration کجاست؟
• Artifact دقیقاً چیست و چگونه به Commit/Build مربوط می‌شود؟
• Gateهای Test، Security، Policy و Approval کدام‌اند؟
• محیط‌های Local، CI، Staging و Production چه تفاوت مجازی دارند؟
• چه کسی Deploy، Rollback، Migration و Incident را مالک است؟
• Success با چه Health check، SLO و Business flowی اثبات می‌شود؟
• Secret، Data و Log چه سیاست دسترسی و Retention دارند؟
• RPO/RTO و روش بازیابی Code، Config و Data چیست؟

اگر این پرسش‌ها پاسخ ندارند، اضافه‌کردن Kubernetes فقط ابهام را به YAML منتقل می‌کند.

نردبان پیچیدگی: از Script تا Kubernetes

Kubernetes جای Docker Compose برای هر پروژه نیست. هزینه Control plane، Upgrade، Network، Security، Observability و On-call را نیز بسنجید. برای Fit، TCO و Pilot از راهنمای انتخاب و معماری Kubernetes استفاده کنید.

Container چیست؟ Image، Container و Runtime

• Image: بسته لایه‌ای و عمدتاً تغییرناپذیر شامل Filesystem و Metadata اجرا؛
• Container: یک اجرای Image با Process، Namespace، Network و Mount مشخص؛
• Registry: محل توزیع و نگه‌داری Image؛
• Runtime: مؤلفه‌ای که اجرای Container را روی Host مدیریت می‌کند؛
• Digest: شناسه محتوایی برای اشاره دقیق‌تر از Tag قابل تغییر.

Container معمولاً Kernel میزبان را به اشتراک می‌گذارد؛ VM معمولاً Guest OS و Kernel جدا دارد. بنابراین Container سبک‌تر است، اما مرز امنیتی کامل یا معادل VM نیست. همچنین «یک Image در هرجا» قید دارد: معماری CPU، OS، Kernel capability، Filesystem، Network و Runtime باید سازگار باشند.

ویژگی‌های یک برنامه Container-friendly

• Configuration از Environment/Secret store می‌آید، نه Hard-code؛
• Process اصلی Foreground است و Signal را درست دریافت می‌کند؛
• Log روی stdout/stderr یا Collector استاندارد می‌رود؛
• State پایدار بیرون از Filesystem موقت Container نگه‌داری می‌شود؛
• Startup، Readiness، Liveness و Shutdown رفتار تعریف‌شده دارند؛
• Migration از Start هر Replica جدا و Idempotent است؛
• Upload، Session، Cache و Queue مالکیت روشن دارند؛
• Dependency بیرونی Timeout، Retry محدود و Circuit/Backpressure مناسب دارد.

Containerization مشکل Lock، Consistency یا Query بد Database را حل نمی‌کند. برای Data layer، راهنمای عیب‌یابی و استقرار امن پایگاه داده را جداگانه ببینید.

Dockerfile امن و قابل بازتولید

راهنمای رسمی Docker Build بر Multi-stage build، Base image قابل اعتماد، حذف Packageهای غیرضروری، Build در CI، Pin کردن نسخه و اجرای Non-root تأکید دارد. نمونه زیر الگوست، نه فایل آماده برای هر Framework:

# syntax=docker/dockerfile:1
FROM node:24-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm test && npm run build

FROM node:24-alpine AS runtime
ENV NODE_ENV=production
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
USER node
CMD ["node", "dist/server.js"]

در Production، Base image را بر اساس سیاست Patch به نسخه یا Digest معتبر Pin کنید، مرتب Rebuild کنید و Digest/Provenance را ثبت کنید. Pin مطلق بدون فرایند Update، Patch امنیتی را متوقف می‌کند؛ Tag شناور بدون ثبت Digest نیز Reproducibility را می‌شکند.

اشتباه‌های رایج Dockerfile

• استفاده از latest بدون ثبت نسخه واقعی؛
• قرار دادن Token در ARG، ENV یا Layer؛
• کپی‌کردن کل Repository و Secretهای Local؛
• اجرای برنامه با Root بدون نیاز؛
• باقی‌گذاشتن Compiler و Package manager در Runtime image؛
• نصب Dependency بدون Lockfile؛
• Build جداگانه برای هر Environment؛
• قرار دادن Database در همان Container بدون Plan داده؛
• Health checkی که فقط Process را می‌بیند یا Dependencyهای دور را بیش‌ازحد Probe می‌کند.

Build once، Promote many

commit → test → build artifact/image → scan → sign/attest
       → deploy same digest to staging → verify
       → approve/policy gate → promote same digest to production

اگر در Staging یک Image و در Production Image دیگری Build شود، Evidence تست‌شده به Artifact نهایی تعلق ندارد. Environment-specific Config و Secret را هنگام Deploy تزریق کنید، اما Code/Dependency همان Digest بماند.

CI، Continuous Delivery و Continuous Deployment

• Continuous Integration: تغییر کوچک و مکرر با Build/Test خودکار و بازخورد سریع ادغام می‌شود.
• Continuous Delivery: Artifact همیشه آماده انتشار است، اما Production می‌تواند Approval انسانی داشته باشد.
• Continuous Deployment: هر تغییر واجد شرایط بدون Approval دستی به Production می‌رود.

Deployment خودکار مرحله بالاتر اخلاقی نیست. اگر تست، Observability، Progressive delivery و Recovery کافی ندارید، Approval کنترل‌شده منطقی است. طراحی عمیق Pipeline را در راهنمای CI/CD امن دنبال کنید.

Pipeline حداقلی اما قابل اعتماد

1. Checkout با Permission حداقلی؛
2. Dependency restore از Lockfile و Cache قابل اعتماد؛
3. Lint، Type/static check و Unit test؛
4. Integration/contract test با Dependency موقت؛
5. SAST، Secret و Dependency/IaC scan بر اساس Risk؛
6. Build یک Artifact immutable؛
7. SBOM، Provenance، Signature/Attestation و ثبت Digest؛
8. Deploy به Staging و Migration rehearsal؛
9. Smoke، API، E2E و Security/Performance gate متناسب؛
10. Approval یا Policy gate برای Production؛
11. Canary/rolling/blue-green و Release marker؛
12. Post-deploy verification و Rollback/roll-forward.

Gate باید Evidence بسازد و Owner داشته باشد. یک Scanner با هزار Warningِ بی‌مالک امنیت ایجاد نمی‌کند.

امنیت زنجیره تأمین CI/CD

Runner به Source، Token، Artifact و Production نزدیک است؛ بنابراین Pipeline بخشی از سطح حمله است. NIST SSDF حفاظت از اجزای Release، محیط توسعه امن، Provenance و پاسخ به آسیب‌پذیری را جزو Outcomeهای اصلی می‌داند.

• Workflow و Branch protection با Review و CODEOWNERS؛
• Runner موقت یا سخت‌شده و جدایی Trust zone؛
• Permission پیش‌فرض Read-only و Grant دقیق برای Job؛
• OIDC/Short-lived credential به‌جای Cloud key ثابت؛
• Third-party action محدود و Pin به Commit SHA کامل؛
• Artifact store با Retention، Integrity و Access log؛
• Dependency allowlist، Lockfile، SBOM و Vulnerability policy؛
• Secret masking همراه با جلوگیری از Echo/Artifact leak؛
• Production environment با Approval و Separation of duty متناسب.

مستند GitHub Actions امکان الزام Pin شدن Action به Full-length commit SHA را توضیح می‌دهد؛ Tag یا Branch می‌تواند بعداً به کد دیگری اشاره کند.

IaC چیست و با Config management چه فرقی دارد؟

Infrastructure as Code وضعیت مطلوب Network، Compute، IAM، Database و سرویس‌های مدیریت‌شده را در فایل Versioned تعریف می‌کند. Config management بیشتر تنظیم سیستم یا نرم‌افزار روی Node را مدیریت می‌کند؛ مرز ابزارها می‌تواند هم‌پوشان باشد.

Secret را در State یا Repository خام نگذارید و تصور نکنید Rollback فایل IaC الزاماً Data را برمی‌گرداند.

Kubernetes چه مسئله‌ای را حل می‌کند؟

Kubernetes Desired state را با Controllerها پیگیری می‌کند: Podها را Schedule و جایگزین، Rollout را مدیریت و Service discovery را فراهم می‌کند. اما Application correctness، Data consistency، Backup و SLO را خودکار نمی‌سازد.

مستند Kubernetes Ingress می‌گوید API آن Freeze شده و پروژه برای قابلیت‌های جدید Gateway را توصیه می‌کند؛ Ingress حذف‌شده نیست، اما انتخاب جدید باید Support و Migration را بسنجد.

Readiness، Liveness و Startup را قاطی نکنید

• Startup: آیا برنامه راه‌اندازی اولیه را تمام کرده است؟ تا موفق نشود، Probeهای دیگر شروع نمی‌شوند.
• Readiness: آیا همین Replica اکنون آماده Traffic است؟ شکست، آن را از Endpointهای Service خارج می‌کند.
• Liveness: آیا Process در وضعیت گیرکرده‌ای است که Restart مفید باشد؟

راهنمای رسمی Probeهای Kubernetes هشدار می‌دهد Liveness اشتباه می‌تواند زیر بار، Restart آبشاری بسازد. Readiness را با Dependency دور و ناپایدار طوری نبندید که تمام Replicaها هم‌زمان از سرویس خارج شوند. Startup کند را با Liveness تنبیه نکنید.

Resource، Shutdown و Rollout contract

Application باید با Scheduler و Load balancer قرارداد داشته باشد:

• CPU/Memory request بر پایه Profiling و Limit با شناخت OOM/Throttling؛
• Graceful shutdown، Signal handling و زمان Drain؛
• Readiness false پیش از قطع اتصال و پایان Requestهای جاری؛
• PodDisruptionBudget و topology متناسب با Fault domain؛
• MaxUnavailable/MaxSurge و Capacity برای Rolling update؛
• Session بیرونی یا Sticky strategy آگاهانه؛
• Migration Backward-compatible برای هم‌زیستی دو نسخه؛
• Queue consumer با Idempotency و Lease/Visibility timeout.

برای Backpressure، Retry، Outbox و Idempotency در سیستم Async، راهنمای معماری Event-driven مکمل این بخش است.

امنیت Container و Kubernetes

Container یک Sandbox کامل نیست. Baseline کاربردی:

• Image کمینه، Patch‌شده و از Registry قابل اعتماد؛
• Non-root، allowPrivilegeEscalation: false و Drop capabilityهای غیرلازم؛
• Filesystem فقط‌خواندنی و Mount نوشتنی محدود؛
• Seccomp/AppArmor/SELinux طبق Platform؛
• Pod Security Admission، Namespace و NetworkPolicy؛
• ServiceAccount و RBAC حداقلی؛
• Registry pull credential، Admission policy و Signature verification؛
• Node/control-plane patch، audit log و Backup etcd.

مستند Kubernetes Secrets تصریح می‌کند Secretها به‌طور پیش‌فرض در etcd بدون Encryption at rest ذخیره می‌شوند و Base64 محرمانگی نمی‌آورد. Encryption at rest، RBAC حداقلی، محدودکردن list/watch و در صورت نیاز External secret store را طراحی کنید.

Observability؛ از «CPU سبز» تا مسیر Request

Monitoring می‌گوید یک شاخص از حد گذشت؛ Observability کمک می‌کند از خروجی سیستم، علت را کشف کنید. OpenTelemetry Signalهای Trace، Metric، Log و Baggage را تعریف می‌کند.

• Correlation ID و Trace context از Edge تا Queue/DB؛
• Golden signals: Latency، Traffic، Error و Saturation؛
• Business signal: Login، Checkout، Payment یا Lead success؛
• Structured log بدون Secret/PII غیرضروری؛
• Release marker با Commit، Image digest و Owner؛
• Alert بر User impact و SLO، نه هر نوسان؛
• Retention، Sampling و Cost budget؛
• Runbook link در Alert.

برای طراحی Telemetry و Alert، راهنمای Observability سایت را اجرا کنید.

SLO، Error budget و DORA metrics

DORA اکنون مدل پنج‌معیاره تحویل نرم‌افزار را شرح می‌دهد: Change lead time، Deployment frequency، Change fail rate، Failed deployment recovery time و Deployment rework rate. این‌ها برای بهبود سیستم‌اند، نه رتبه‌بندی افراد یا اجبار به Deploy بیشتر.

SLO کاربر و Error budget باید کنار این Metricها باشد؛ سرعت بدون Reliability هدف ناقص است.

داده، Migration و Rollback

Rollback Image ساده‌تر از Rollback داده است. برای هر Release دارای Migration:

• Schema version و Compatibility matrix دو نسخه؛
• الگوی Expand → Migrate → Contract؛
• Backup/Snapshot سازگار و Restore-tested؛
• Lock، Disk، Duration و Batch/Resume؛
• Idempotency و Ownership اجرای Migration؛
• Forward fix، rollback script یا Restore decision؛
• حفظ Writeهای پس از Snapshot و Reconciliation؛
• Canary و Stop threshold.

برای RPO/RTO و Drill، راهنمای بازیابی فاجعه سایت را ببینید.

سناریوی ایران: Registry و Dependency در دسترس نیست

تیم یک فروشگاه ایرانی هنگام Incident می‌خواهد Replica جدید بسازد، اما Registry خارجی یا Package registry از مسیر شبکه در دسترس نیست. Podهای فعلی سالم‌اند، ولی Scale-out و Rollback به Pull وابسته است.

1. Artifactهای مصوب و Dependencyها با License/Policy صحیح در Registry کنترل‌شده Cache/Mirror می‌شوند.
2. Digest و Signature/Provenance ثبت و Pull قبل از Window آزمایش می‌شود.
3. Nodeهای لازم Image را پیشاپیش دارند، اما Policy Patch/Expiry مانع ماندگاری نسخه آسیب‌پذیر است.
4. DNS، Registry، CI control plane و Notification به‌عنوان Dependency مانیتور می‌شوند.
5. Runbook می‌گوید در Outage آیا Hold، Scale موجود، Rollback cached یا Failover مجاز است.
6. هیچ Mirror ناشناخته یا مسیر مغایر شرایط Provider برای «حل سریع» وارد Supply chain نمی‌شود.

Capacity و Fault domain را با راهنمای هاست سایت پرترافیک و Shared responsibility را با راهنمای هاست ابری امن تطبیق دهید.

تقسیم مسئولیت تیم

جدول عمومی کافی نیست؛ برای هر سرویس Owner، On-call، Escalation، Approval و Break-glass را نام‌گذاری کنید.

Runbook شکست Release

1. Release marker، Timeline و Scope را ثبت کنید.
2. تأثیر کاربر و Business flow را با Threshold بسنجید.
3. Traffic/Canary را Hold یا محدود کنید.
4. Health، Event، Log، Trace، Saturation و Dependency را Correlate کنید.
5. تفاوت Artifact، Config، Secret، Infra و Data را بررسی کنید.
6. Rollback یا Roll-forward را با Schema/Data compatibility انتخاب کنید.
7. پس از Recovery، Queue/Cache/Data را Reconcile کنید.
8. Root cause، Control gap و Test پیشگیرانه را ثبت کنید.

برنامه ۳۰/۶۰/۹۰ روزه یادگیری DevOps

روز ۱ تا ۳۰: Flow و Container

• Delivery map و Bottleneck واقعی؛
• Git/Review/Branch protection؛
• Test و یک CI ساده؛
• Dockerfile چندمرحله‌ای و Non-root؛
• Config/Secret/State separation؛
• Runbook Deploy/Rollback.

روز ۳۱ تا ۶۰: امن‌سازی Delivery

• Build-once artifact و Registry؛
• Dependency/Secret/Image scan؛
• SBOM/Provenance/Signature؛
• Staging و Post-deploy test؛
• Metric/Log/Trace و Alert؛
• Migration/Restore rehearsal.

روز ۶۱ تا ۹۰: Orchestration فقط با Fit

• Managed container در برابر Kubernetes scorecard؛
• Deployment/Service/Gateway/Probe lab؛
• Resource/Security/Network/Secret controls؛
• Canary و Failure game day؛
• DORA+SLO baseline؛
• Scale/Hold/Exit decision.

چک‌لیست DevOps برای توسعه‌دهنده وب

• Delivery contract، Owner و Success evidence روشن‌اند.
• پیچیدگی ابزار با مسئله و توان On-call تناسب دارد.
• Container boundary و تفاوت OS/Arch/Kernel فهمیده شده‌اند.
• Image کمینه، Non-root، Versioned و مرتب Rebuild می‌شود.
• Secret در Layer، Log، Artifact یا State افشا نمی‌شود.
• یک Artifact با Digest یکسان Promote می‌شود.
• Pipeline Permission، Action، Runner و Credential سخت‌شده‌اند.
• Test/Security/Policy gate Evidence و Owner دارند.
• Migration با Compatibility و Data plan اجرا می‌شود.
• Readiness/Liveness/Startup و Graceful shutdown جدا هستند.
• Request/Limit و Rollout بر پایه Load test تنظیم شده‌اند.
• Secretهای Kubernetes Encryption/RBAC مناسب دارند.
• Metric/Log/Trace/Business signal به Release متصل‌اند.
• SLO و DORA برای بهبود سیستم‌اند، نه رتبه‌بندی فرد.
• Registry/Dependency outage و Restore تمرین شده‌اند.

سؤالات متداول DevOps، Docker و Kubernetes

آیا DevOps یک نقش شغلی است یا فرهنگ؟

می‌تواند عنوان شغلی هم باشد، اما نتیجه DevOps به همکاری، Flow، Automation، Feedback و مالکیت مشترک وابسته است. ساخت یک تیم جدا با Ticketهای بیشتر لزوماً DevOps نیست.

آیا هر توسعه‌دهنده وب باید Kubernetes یاد بگیرد؟

مفاهیم Container، CI/CD، Health و Observability عمومی‌ترند. Kubernetes زمانی ارزش دارد که Workload و سازمان به Orchestration نیاز داشته باشند و تیم توان امنیت، Upgrade و On-call آن را داشته باشد.

تفاوت Container و VM چیست؟

Container معمولاً Kernel میزبان را به اشتراک می‌گذارد و Processها را ایزوله می‌کند؛ VM معمولاً Guest OS و Kernel جدا دارد. Container سبک‌تر است، اما Isolation و سازگاری آن به Runtime، OS و معماری وابسته است.

Continuous Delivery با Continuous Deployment چه تفاوتی دارد؟

در Delivery، Artifact همیشه آماده Production است ولی انتشار می‌تواند Approval داشته باشد؛ در Deployment، هر تغییر واجد شرایط خودکار منتشر می‌شود. انتخاب به ریسک و کنترل‌های شما بستگی دارد.

اول Docker یاد بگیریم یا CI/CD؟

ابتدا Flow، Git، Test و CI ساده را بفهمید؛ سپس پروژه‌ای را Containerize کنید. Docker بدون Test و Delivery contract فقط بسته‌بندی مشکل است. Kubernetes را بعد از مشاهده نیاز واقعی Orchestration اضافه کنید.

جمع‌بندی

مسیر DevOps از Kubernetes شروع نمی‌شود؛ از یک تغییر کوچک، Artifact قابل ردیابی، Test قابل اعتماد و مالکیت Production شروع می‌شود. Container محیط را بسته‌بندی می‌کند، CI/CD شواهد و تکرارپذیری می‌سازد، Orchestrator وضعیت مطلوب را دنبال می‌کند و Observability بازخورد واقعی می‌دهد. امنیت، Data و Recovery باید در تمام این حلقه‌ها حضور داشته باشند.

برای پروژه خود یک Delivery map از Commit تا نتیجه کاربر بکشید و طولانی‌ترین انتظار، پرخطاترین Hand-off و ضعیف‌ترین Recovery را پیدا کنید. ابزار بعدی باید یکی از همین گلوگاه‌ها را حل کند؛ وگرنه فقط سطح عملیاتی تازه‌ای ساخته‌اید.