پرش به محتویات

استقرار و عملیات بک‌اند

هر Push یا Merge به main پس از عبور از Gateهای کیفیت، Image تغییرناپذیر Docker را در GHCR خصوصی منتشر و محیط Development روی VPS ایران را به همان Digest ارتقا می‌دهد. Production تا تصمیم جداگانه به‌صورت خودکار از main Deploy نمی‌شود.

محیط‌ها

محیط هدف سیاست Deploy
Local توسعه روزانه با Compose دستی
CI آزمون ایزوله و موقت خودکار برای PR و main
Development تست یکپارچه روی VPS خودکار پس از موفقیت main
Production سرویس کاربران واقعی فعلا Manual Promotion با Approval؛ سیاست نهایی باز است

Database، Bucket، Credential، Domain و کلید امضا بین محیط‌ها مشترک نیستند. استفاده از داده Production در Development ممنوع است مگر نسخه ناشناس‌سازی‌شده با تایید امنیتی.

Docker Image

  • Dockerfile چندمرحله‌ای است: Build با Go Toolchain Pin‌شده و Runtime حداقلی.
  • Image نهایی Compiler، Source، Cache، Shell و Package Manager غیرضروری ندارد.
  • Binary با User غیرRoot، Filesystem تا حد ممکن Read-only و Capability حداقلی اجرا می‌شود.
  • Base Image با Tag کامل و Digest Pin و به‌صورت منظم برای Patch امنیتی بازسازی می‌شود.
  • OCI Label شامل Repository، Commit، Version و Build Time قابل بازتولید است.
  • Image فقط یک مسئولیت دارد؛ API، Worker و Migration از یک Artifact با Command متفاوت یا Artifactهای هم‌Commit ساخته می‌شوند.
  • Secret در Build Arg، Layer، Image، Label یا Compose Commit‌شده قرار نمی‌گیرد.
  • Health Check سبک و Shutdown Graceful دارد.

Build باید تا حد امکان Reproducible، با CGO_ENABLED=0 در صورت سازگاری Dependencyها و دارای SBOM باشد. اگر CGO لازم شد، Runtime و Patch Strategy در ADR ثبت می‌شود.

Pipeline Pull Request

Pull Request هیچ دسترسی Deploy یا Secret محیط ندارد. Workflow آن موارد زیر را اجرا می‌کند:

  1. Format، Generate و Dependency consistency
  2. Vet، Lint، Test، Race و Integration
  3. govulncheck، Secret Scan و OpenAPI Check
  4. Build Binary و Image بدون Push
  5. Scan آسیب‌پذیری Image و تولید گزارش

Workflow از Fork نباید Secret دریافت کند. Permission پیش‌فرض GITHUB_TOKEN برابر Read-only است و هر Job فقط Permission لازم خود را می‌گیرد.

Pipeline main

flowchart LR Main[Push یا Merge به main] --> Verify[Quality و Security Gates] Verify --> Build[Build یک Image] Build --> Scan[Scan و SBOM] Scan --> GHCR[Push به GHCR خصوصی] GHCR --> Deploy[Deploy Digest در Development] Deploy --> Health[Health و Smoke Test] Health -->|موفق| Keep[ثبت Release] Health -->|ناموفق| Rollback[بازگشت به Digest قبلی]
  • Image یک‌بار Build و با Digest همان Artifact در تمام مرحله‌ها استفاده می‌شود؛ بازسازی در Server ممنوع است.
  • Tagهای sha-<commit> و در صورت Release نسخه SemVer قابل استفاده‌اند؛ Deploy با Digest انجام می‌شود و latest منبع Deploy نیست.
  • GHCR و Repository Private هستند.
  • Attestation و SBOM برای Private Repository در صورت پشتیبانی Plan فعال می‌شوند؛ نبود قابلیت Plan نباید Deploy را پنهانی ناامن کند.
  • Actionهای Third-party و GitHub با Full Commit SHA Pin و به‌صورت دوره‌ای بازبینی می‌شوند.
  • Environment development دارای Concurrency Group است تا دو Deploy هم‌زمان اجرا نشوند.

دسترسی Server

  • Deploy با User اختصاصی غیرRoot و کلید SSH اختصاصی انجام می‌شود.
  • Host Key به‌صورت Pin‌شده بررسی می‌شود؛ خاموش کردن Host Verification ممنوع است.
  • Deploy User فقط Commandهای لازم در مسیر مشخص پروژه را اجرا می‌کند و به Shell یا فایل‌های دیگر دسترسی گسترده ندارد.
  • Credential GHCR روی Server فقط read:packages دارد و Token انتشار در VPS نگهداری نمی‌شود.
  • Secretهای Runtime با فایل محافظت‌شده یا Secret Manager تزریق و Permission آن‌ها محدود می‌شود.
  • Port PostgreSQL، Metrics و Admin به اینترنت عمومی Bind نمی‌شوند.
  • Firewall فقط 80/443، SSH محدودشده و مسیرهای واقعا لازم را باز می‌کند.

فرایند Deploy

  1. Digest جدید و Compose Config Validate می‌شوند.
  2. Image پیش از توقف نسخه فعلی Pull می‌شود.
  3. Backup و سازگاری Migration طبق Risk تغییر بررسی می‌شوند.
  4. Migration یک‌بار با Lock و Timeout اجرا می‌شود.
  5. Container جدید با Resource Limit و Config نسخه‌دار بالا می‌آید.
  6. Readiness و Smoke Test جریان‌های اصلی اجرا می‌شوند.
  7. در موفقیت Release ثبت و نسخه‌های قدیمی طبق Retention پاک می‌شوند.
  8. در شکست، App به Digest قبلی بازمی‌گردد؛ Schema باید با نسخه قبلی سازگار باشد.

Migration مخرب در همان Release حذف کد قدیمی اجرا نمی‌شود. Expand/Contract شرط Rollback امن است.

Rollback

  • حداقل دو Digest سالم قبلی روی Server یا Registry قابل دریافت نگهداری می‌شوند.
  • Trigger شامل شکست Health، افزایش Error Rate، نقض SLO یا Smoke Test ناموفق است.
  • Rollback App خودکار می‌تواند باشد، اما Rollback داده فقط از Runbook و با تصمیم انسانی انجام می‌شود.
  • Release، Actor، Digest مبدا و مقصد، علت و نتیجه در Deployment Log ثبت می‌شوند.
  • پس از Rollback، Incident و اقدام اصلاحی بدون حذف شواهد ثبت می‌شود.

توپولوژی VPS

تصمیم نهایی میان یک VPS و جداسازی App/Database باز است. قواعد زیر از ابتدا ثابت‌اند:

  • کد از DNS و Config استفاده می‌کند و به localhost یا IP ثابت وابسته نیست.
  • Volume PostgreSQL روی Storage پایدار، رمزگذاری‌شده و دارای Backup است.
  • Database به شبکه عمومی ارائه نمی‌شود.
  • یک VPS Single Point of Failure است و پیش از تعهد Availability باید Risk آن پذیرفته شود.
  • جداسازی Database، Replica یا Failover وقتی SLO، ظرفیت یا Restore Test نیاز را نشان دهد انجام می‌شود.

پایداری ارتباط از ایران

  • Server حداقل دو Image سالم قبلی را نگه می‌دارد تا قطع GHCR مانع Rollback نشود.
  • Pull پیش از Stop انجام می‌شود و شکست Download سرویس فعلی را متوقف نمی‌کند.
  • Timeout و Retry محدود برای GHCR تعریف و وضعیت Registry در Preflight بررسی می‌شود.
  • اگر دسترسی GHCR به‌طور پایدار SLO Deploy را نقض کند، Registry Mirror یا Registry ثانویه داخل ایران با ADR اضافه می‌شود.
  • بسته دستی امضاشده فقط مسیر اضطراری Runbook و دارای Checksum و Audit است.

سخت‌سازی و نگهداری

  • سیستم‌عامل Minimal، Patchشده و دارای به‌روزرسانی امنیتی زمان‌بندی‌شده است.
  • SSH با Password و ورود مستقیم Root غیرفعال و Keyها دوره‌ای Rotate می‌شوند.
  • NTP، Firewall، Fail2ban یا کنترل معادل و Log امنیتی فعال‌اند.
  • Container دارای CPU/Memory/PID Limit و Restart Policy کنترل‌شده است؛ Loop شکست Alert ایجاد می‌کند.
  • Disk، Inode، Certificate، Domain، Backup، WAL، Queue و Image age Alert دارند.
  • دسترسی عملیاتی Least Privilege، شخصی، قابل ابطال و Auditپذیر است؛ Account مشترک ممنوع است.

معیار آمادگی Production

  • سیاست Deploy Production، Approval و Rollback در ADR تصویب شده است.
  • Restore Test روی زیرساخت واقعی RPO و RTO را اثبات کرده است.
  • TLS، Secret Rotation، Firewall، Backup، Alert و Runbookها بازبینی شده‌اند.
  • Load Test ظرفیت و Headroom را تایید کرده است.
  • درگاه و Providerهای Production Security Review و Contract Test دارند.
  • Disaster Recovery و قطع GHCR حداقل یک‌بار تمرین شده‌اند.

منابع رسمی