به‌روز رسانی وب‌ سایت

ric upgrade نسخه‌ی به‌روزرسانی‌شده‌ی یک پروژه‌ی از قبل deploy شده را منتشر می‌کند. دیتابیس، credentialهای production، nginx مشترک و پیکربندی آینه‌ی رجیستری حفظ می‌شوند — فقط ایمیج اپلیکیشن و site config شما تازه می‌شوند.

# داخل پوشه‌ی پروژه‌ای که قبلا deploy شده

$  ric upgrade

بدون flag، بدون آرگومان. از همان .ric/deploy.yml که ric deploy استفاده می‌کند، استفاده می‌کند.

۱. اعتبارسنجی محلی (همان بررسی‌های deploy). ۲. ساخت یک ایمیج production تازه (assets precompile → commit → save → sha256). ۳. باز کردن master SSH با multiplex. ۴. تشخیص دسترسی، اطمینان از وجود docker، به‌روزرسانی پیکربندی آینه‌ی رجیستری در صورت تغییر، اعتبارسنجی آن. ۵. ensureExistingDeploy — وجود نشانگر current_sha را بررسی می‌کند. اگر نباشد، خطا می‌دهد و می‌گوید اول ric deploy را اجرا کنید. ۶. تازه‌سازی layout مشترک (اگر از قبل وجود دارد، کاری نمی‌کند). ۷. آپلود فایل tar ایمیج جدید (اگر همان tar با آدرس‌دهی محتوایی از قبل روی سرور باشد، رد می‌شود — dedup)، گواهی‌های SSL، و site config تازه‌تولیدشده. ۸. docker load و تگ کردن ایمیج جدید به نام <name>:<sha>. ۹. کشیدن master key از سرور به .ric/keys/production.key محلی (تا یک clone تازه بتواند key را بازیابی کند). ۱۰. اجرای db:migrate — فقط migrationها؛ نه seed، نه db:create. داده‌های شما دست نخورده می‌مانند. ۱۱. جایگزینی کانتینر اپلیکیشن با ایمیج جدید — docker rm -f <name> و سپس docker run با تگ ایمیج جدید. bind mountها (credentials، storage) منتقل می‌شوند، پس کانتینر جدید دیتابیس موجود و credentialهای نگه‌داشته‌شده را برمی‌دارد. ۱۲. Reload کردن ric-nginx (docker exec ric-nginx nginx -s reload). خود nginx مشترک restart نمی‌شود، پس بقیه‌ی پروژه‌های روی سرور مختل نمی‌شوند. ۱۳. نوشتن current_sha جدید.

سطر پایانی: Upgraded <name> @ <short_sha> on <host>. Live at https://<domain>.

• دیتابیس — storage/ که bind mount شده در /var/lib/ric/<name>/storage/، تمام دیتابیس‌های SQLite (primary، queue، cache، cable) را حمل می‌کند.

• Credentialهای production — production.key و production.yml.enc فقط در اولین deploy یک‌بار تولید می‌شوند و دیگر دست نمی‌خورند.

• artifactهای ایمیج — .tar هر upgrade موفق در /var/lib/ric/<name>/images/<sha>.tar با آدرس‌دهی محتوایی نگه می‌ماند. پشتیبانی از rollback در آینده روی این بنا می‌شود.

• ric-nginx — دروازه‌ی ورودی مشترک در حال اجرا می‌ماند؛ فقط پیکربندی آن reload می‌شود.

• کانتینر اپلیکیشن جایگزین می‌شود (یک downtime کوتاه در حد چند ثانیه — docker rm سپس docker run).

• site config بازنویسی می‌شود؛ اگر domain یا ssl_dir را در .ric/deploy.yml تغییر داده باشید، تغییرات در همین upgrade اعمال می‌شوند.

• اگر محتوای پیکربندی آینه‌ی رجیستری تغییر کرده باشد، بازنویسی می‌شود.

• deploy قبلی وجود ندارد — current_sha وجود ندارد، ric رد می‌کند و شما را به ric deploy ارجاع می‌دهد.

• db:migrate شکست می‌خورد — کانتینر قبلی همچنان در حال اجراست، دیتابیس شما دست نخورده است، و پیام خطا می‌گوید migration را اصلاح کرده و دوباره امتحان کنید. کانتینر جدید شروع نمی‌شود.

نام فایل tar ایمیج، sha256 آن است، پس اگر همان محتوا دو بار آپلود شود تشخیص داده می‌شود و آپلود دوم رد می‌شود. اگر بدون تغییر چیزی در اپلیکیشن upgrade کنید، رفت و برگشت شبکه‌ای سریع است.

• یک REPL production: ric console --remote.

• مدیریت jobهای زمان‌بندی‌شده و موارد مشابه: فقط از Rails استفاده کنید — همراه اپلیکیشن می‌آیند.