Files
customerTicket/docs/PRODUCTION_SEED.md
T
2026-09-10 16:39:02 +03:30

80 lines
4.5 KiB
Markdown

# انتقال خودکار SQLite به PostgreSQL Production
این فرایند تمام داده‌های پایدار فعلی را منتقل می‌کند:
- کاربران، hash رمزهای قابل استفاده، superuser، گروه‌ها و permissionها
- واحدهای سازمانی، عضویت‌ها، نقش‌ها و پروفایل پرسنل
- مشتریان، گروه مخاطبان، دسته‌بندی‌ها و SLA
- branding، عنوان صفحات، SMS templateها، NotificationPolicy و سیاست فایل‌ها
- تیکت‌ها، ارسال‌های گروهی، رویدادها، پیام‌ها، رسیدهای خواندن و attachmentها
- تمام فایل‌های موجود در `MEDIA_ROOT`، شامل branding، avatar و فایل تیکت
داده‌های موقتی و خطرناک زیر عمداً منتقل نمی‌شوند: sessionها، OTPهای قبلی، Magic Linkهای قبلی، admin log و `NotificationJob`. انتقال outbox قبلی می‌توانست بعد از بالا آمدن worker باعث ارسال مجدد SMS یا Bale شود.
## خروجی ساخته‌شده
دستور زیر از SQLite فعلی snapshot می‌گیرد:
```powershell
.\.venv\Scripts\python.exe manage.py export_production_seed --output production-seed --force
```
برای وضعیت فعلی پروژه خروجی قبلاً تولید شده و شامل ۳۹۵ رکورد پایدار و ۵۷ فایل media است:
```text
production-seed/
data.json.gz
media.tar.gz
manifest.json
```
این پوشه شامل اطلاعات شخصی و password hash است و عمداً توسط Git و Docker ignore می‌شود. آن را commit، ایمیل یا در فضای عمومی بارگذاری نکنید.
## انتقال امن به volume سرور
در Coolify volume خارجی `customer_ticket_seed` را ایجاد کنید. سه فایل بالا باید مستقیماً در ریشه آن قرار بگیرند، به شکلی که container مسیر زیر را ببیند:
```text
/app/production-seed/manifest.json
/app/production-seed/data.json.gz
/app/production-seed/media.tar.gz
```
فایل‌ها را با قابلیت Persistent Storage/File Mount خود Coolify یا یک انتقال امن مانند SCP به سرور ببرید. اگر روی سرور در `/tmp/customer-ticket-seed` قرار گرفته‌اند، مدیر سرور می‌تواند volume را این‌گونه پر کند:
```bash
docker run --rm \
-v customer_ticket_seed:/target \
-v /tmp/customer-ticket-seed:/source:ro \
alpine:3.20 sh -c 'cp /source/data.json.gz /source/media.tar.gz /source/manifest.json /target/'
```
پس از کپی، نسخه موجود در `/tmp` را امن حذف کنید. volume seed در Compose فقط read-only داخل web mount می‌شود.
## اجرای خودکار
در اولین startup سرویس web ترتیب زیر اجرا می‌شود:
1. انتظار برای PostgreSQL
2. اجرای migrationها
3. اعتبارسنجی SHA-256 فایل‌های seed
4. اطمینان از خالی بودن PostgreSQL و media volume
5. حذف defaultهای data migration و import کامل snapshot
6. انتقال media به volume اصلی
7. ثبت `ProductionSeedState`
8. رد کردن `bootstrap` برای حفظ دقیق snapshot به‌عنوان منبع authoritative
9. اجرای `collectstatic` و Gunicorn
در deployهای بعدی checksum قبلاً ثبت‌شده تشخیص داده می‌شود و import دوباره انجام نمی‌شود. اگر bundle نباشد، با `REQUIRE_PRODUCTION_SEED=1` سرویس عمداً متوقف می‌شود تا production ناقص بالا نیاید.
## محدودیت‌های ایمنی
- import فقط روی PostgreSQL اجرا می‌شود.
- دیتابیس دارای User یا seed قبلی با checksum متفاوت پذیرفته نمی‌شود.
- media volume غیرخالی overwrite نمی‌شود.
- مسیرهای مشکوک، symlink و path traversal در archive رد می‌شوند.
- checksum هر دو فایل پیش از هر تغییر بررسی می‌شود.
- شکست import باعث rollback دیتابیس و حذف فایل‌های کپی‌شده همان اجرا می‌شود.
اگر واقعاً می‌خواهید production بدون snapshot بالا بیاید، `REQUIRE_PRODUCTION_SEED=0` بگذارید؛ در این حالت فقط bootstrap استاندارد اجرا می‌شود و کاربران دارای password فعلی SQLite منتقل نخواهند شد.