نقل مشروع من Supabase

ينسخ أمر واحد مشروع Supabase (سحابيًا كان أو مستضافًا ذاتيًا) إلى بيئة جديدة في صباربيز: الجداول، وأمان الصفوف، والمستخدمين بكلمات مرورهم، وملفات Storage. يبقى تطبيقك يستخدم supabase-js؛ ولا يتغير إلا العنوان والمفتاح.

1. افحص أولًا

من لوحة Supabase افتح Connect وانسخ سلسلة اتصال Session pooler أو الاتصال المباشر مع كلمة مرور قاعدة البيانات. ثم على خادم صباربيز:

python3 lab/import_project.py <environment> --dry-run <<'JSON'
{"database_url": "postgresql://postgres.<ref>:<db password>@aws-0-<region>.pooler.supabase.com:5432/postgres"}
JSON

يقرأ المشروع دون أن يغيّر فيه شيئًا، ويذكر ما يمنع الاستيراد (مثل أسرار Vault، أو امتداد ليس على هذا الخادم)، وما يعمل بطريقة مختلفة، وما ستضبطه يدويًا من جديد.

2. الاستيراد

أنشئ بيئة جديدة وفارغة في لوحة الإدارة، ثم شغّل الأمر نفسه دون --dry-run، وأضف عنوان API للمشروع ومفتاح service_role (من Project Settings، ثم API) لتُنسخ ملفات Storage:

python3 lab/import_project.py <environment> --report import-report.json <<'JSON'
{"database_url": "postgresql://postgres.<ref>:<db password>@aws-0-<region>.pooler.supabase.com:5432/postgres",
 "api_url": "https://<ref>.supabase.co", "service_role_key": "<service_role key>"}
JSON

تُقرأ الإعدادات من stdin، لا من سطر الأوامر أبدًا، فلا تظهر كلمات المرور في أي قائمة عمليات. والمصدر يُقرأ فقط.

ما يُنقل، بالترتيب:

1. المخطط public: الجداول والعروض والدوال والسياسات والمشغّلات الخاصة بك، مع الصلاحيات التي أعطاها المصدر لـ anon وauthenticated وservice_role، دون زيادة.
2. المستخدمون وهويات دخولهم مع بصمات كلمات المرور: يسجّل الناس الدخول بكلمات مرورهم القديمة.
3. كل الصفوف في public.
4. الـbuckets ثم كل ملف، مع مالكه، فتبقى سياسات Storage على owner_id عاملة.
5. مشغّلاتك على auth.users وstorage.objects (مثل "إنشاء ملف شخصي عند التسجيل")، تُعاد بعد الصفوف فلا تعمل مرة أخرى للمستخدمين المستوردين.
6. مقارنة أعداد الصفوف والمستخدمين والهويات والـbuckets والملفات بين المصدر والهدف. لا يعلن الاستيراد النجاح إلا إذا تطابقت كلها.

3. وجّه تطبيقك إلى صباربيز

1. أنشئ مفتاحًا عامًا في صفحة البيئة.
2. استبدل عنوان Supabase ومفتاح anon في تطبيقك بعنوان البيئة والمفتاح الجديد.
3. اضبط من جديد ما يعيش خارج قاعدة البيانات: إعدادات تسجيل الدخول ومزوّدي OAuth، والبريد، وEdge Functions (انشر مجلد supabase/functions نفسه)، وRealtime.

يسجّل الناس الدخول مرة واحدة من جديد: الجلسات لا تُنقل. أما كل ما عداها، ومنه كلمات المرور، فيُنقل.

يشغّل CI استيرادًا على جهاز نظيف مع كل تغيير، من بيئة أخرى تقوم مقام مشروع Supabase: يسجّل المستخدم الدخول بكلمة مروره القديمة، ولا يقرأ إلا صفّه، وينزّل ملفه الخاص، ويشغّل تسجيلٌ جديد المشغّلَ المستورد، ويُرفض استيراد ثانٍ إلى البيئة الممتلئة (الدليل). هذا ليس تشغيلًا على Supabase Cloud.

الحدود

• يجب أن يكون الهدف بيئة جديدة وفارغة. الاستيراد الفاشل يتركها لتُحذف وتُنشأ من جديد، ولا يُصلَح نصفها أبدًا.
• لا يُنسخ من مخططاتك الخاصة إلا public؛ والمخططات الأخرى يذكرها الفحص.
• يُرفض المشروع الذي يحمل أسرارًا في Vault، لأن مفتاحها الجذري لا يدخل في التفريغ. أفرغ Vault في المصدر أولًا، ثم أضف الأسرار من جديد في البيئة الجديدة، فلها Vault خاص بها.
• مهام cron وسر JWT للمشروع لا تُنقل؛ ويقول الفحص متى يكون لذلك أثر.
• الملفات الأكبر من حد الرفع (SBARBASE_UPLOAD_LIMIT_MB) يُبلَّغ عنها ولا تُنسخ.

عدّل على GitHub