מסד נתונים

Nodaro שומר את מסד הנתונים שלו ב-Supabase: Postgres לנתונים, GoTrue להתחברות ו-PostgREST ל-API של הנתונים, שהעורך קורא ממנו וכותב אליו. מערך השירותים של Compose כולל את שלושתם ומחיל בשבילכם את המיגרציות של מסד הנתונים. אפשר גם לכוון את Nodaro לפרויקט Supabase מנוהל ולהחיל את המיגרציות בעצמכם.

המערך המובנה

הדפדפן וה-API מגיעים לשירות ההתחברות ול-API של הנתונים דרך ה-origin של האפליקציה עצמה, בכתובת PUBLIC_URL/supabase. שרת הווב בקונטיינר של Nodaro מעביר את /supabase/auth/v1 ל-GoTrue ואת /supabase/rest/v1 ל-PostgREST, כך שלא צריך פורט או דומיין נוספים.

המערך המובנה לא שולח אימיילים: חשבונות עובדים מיד אחרי ההרשמה.

מיגרציות במערך המובנה

הקונטיינר של האפליקציה מחיל את כל הקבצים ב-supabase/migrations/ לפני שה-API עולה. הוא צריך את RUN_MIGRATIONS_ON_BOOT=true ואת DATABASE_URL, שקובץ ה-Compose מגדיר בשבילכם.

• קבצים שהוחלו נרשמים, ובאתחול הבא המערך מדלג עליהם.
• ה-API אף פעם לא רץ מול מסד נתונים שהמיגרציות שלו הוחלו רק בחלקן. כשמיגרציה נכשלת, ה-API מסרב לעלות, והיומן של הקונטיינר מציין את שם הקובץ.
• מתקנים ומפעילים שוב. אחרי שתיקנתם את הגורם, הריצו שוב את docker compose -f docker-compose.community.yml up. המערך מדלג על קבצים שכבר הוחלו.

אבטחת מסד הנתונים המובנה

המפתחות והסיסמאות של ברירת המחדל הם ציבוריים. לפני שחושפים את המערך לרשת:

1. צרו מפתחות אימות חדשים עם node tools/generate-selfhost-keys.mjs >> .env. הסקריפט מדפיס את SUPABASE_JWT_SECRET, SUPABASE_ANON_KEY ו-SUPABASE_SERVICE_ROLE_KEY. שלושתם חייבים להגיע מאותה הרצה: המפתחות חתומים עם הסוד.
2. הגדירו את POSTGRES_PASSWORD ו-DATABASE_URL תואם, כגון postgres://postgres:<new-password>@db:5432/postgres.
3. החילו את השינויים עם docker compose -f docker-compose.community.yml up -d.

מסד הנתונים מתאים את הסיסמאות של התפקידים הפנימיים שלו, כגון supabase_auth_admin ו-authenticator, ל-POSTGRES_PASSWORD רק בהפעלה הראשונה שלו. אם ה-volume db-data כבר קיים, מחקו את ה-volume, מה שמוחק את הנתונים שלכם, או שנו ידנית את סיסמאות התפקידים בתור supabase_admin. אחרת ההתחברות נכשלת עם password authentication failed for user "supabase_auth_admin" (אימות הסיסמה נכשל עבור המשתמש supabase_auth_admin).

שימוש בפרויקט Supabase מנוהל

פרויקט ב-supabase.com מחליף את השירותים המובנים db, auth ו-rest. המסלול החינמי של Supabase מספיק. הגדירו את המשתנים האלה ב-.env:

SUPABASE_URL=https://YOUR-PROJECT.supabase.co
SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_ROLE_KEY=eyJ...
FRONTEND_SUPABASE_URL=https://YOUR-PROJECT.supabase.co
RUN_MIGRATIONS_ON_BOOT=false
NODARO_ENCRYPTION_KEY=<64-character hex>

• FRONTEND_SUPABASE_URL הוא העותק של כתובת הפרויקט שהדפדפן משתמש בו. האימג׳ שפורסם בנוי למערך המובנה, והוא לומד כתובת אחרת רק מהמשתנה הזה, באתחול.
• RUN_MIGRATIONS_ON_BOOT=false משבית את מריץ המיגרציות. החילו את המיגרציות בעצמכם, כמו שמתואר בהמשך.
• NODARO_ENCRYPTION_KEY חייב להיות מוגדר, למשל עם openssl rand -hex 32. המערך יוצר את המפתח בשבילכם רק כשמריץ המיגרציות מופעל. בלי המפתח, הדבקה של מפתחות ספק וחיבור ל-Nodaro Cloud נכשלים עם EncryptionKeyMissingError.

אם ההתקנה כבר רצה על המערך המובנה, השתמשו שוב במפתח שלה. הוא נמצא ב-volume app-data, בנתיב /data/nodaro/encryption-key. מפתח חדש לא יכול לקרוא את מה שהמפתח הישן הצפין.

החלת המיגרציות על פרויקט מנוהל

החילו את כל הקבצים ב-supabase/migrations/ לפי סדר שמות הקבצים. הקידומות המרופדות באפסים, כגון 001_ ו-002_, קובעות את הסדר.

• בעורך ה-SQL. בלוח הבקרה של Supabase, פתחו את SQL editor (עורך SQL) והריצו את הקבצים אחד אחרי השני.
• עם ה-CLI של Supabase. כך זה מהיר יותר:

supabase link --project-ref YOUR-REF
supabase db push

אפשר להריץ את המיגרציות שוב על מסד נתונים שכבר עבר מיגרציה, חוץ ממקומות שבהם קובץ אומר אחרת, למשל לגבי נתונים התחלתיים. הרצה שלהן על מסד נתונים חדש תמיד תקינה.

בכל עדכון, החילו את הקבצים החדשים לפי סדר שמות הקבצים לפני שאתם מפעילים מחדש עם האימג׳ החדש. מיגרציה חסרה בדרך כלל לא עוצרת את ה-API, אבל היכולות שזקוקות לה מחזירות 500 עד שהטבלאות שלהן קיימות.

הגשת פרויקט מנוהל דרך ה-origin שלכם

יש רשתות שמסננות כל בקשה מהדפדפן לפי שם המארח וחוסמות את הדומיין של Supabase. ברשתות כאלה, שרת הווב בקונטיינר של Nodaro יכול להעביר פרויקט מנוהל דרך ה-origin של האפליקציה עצמה. הגדירו את שלושת המשתנים יחד:

SUPABASE_MANAGED_PROXY=true
FRONTEND_SUPABASE_URL=/supabase
SUPABASE_PROXY_UPSTREAM=https://YOUR-PROJECT.supabase.co

• המשתנה SUPABASE_PROXY_UPSTREAM הוא origin בלי נתיב.
• השאירו את SUPABASE_URL מוגדר לכתובת ה-HTTPS של הפרויקט. ה-API ממשיך להתחבר אליה ישירות.
• הדפדפן משלים את /supabase לכתובת מלאה לפי ה-origin של הדף. שרת הווב מעביר לפרויקט בקשות התחברות, REST, אחסון ו-realtime, כולל שדרוגים ל-WebSocket.
• אסימונים ומפתחות API עוברים בלי שינוי. הפרוקסי לא מוסיף פרטי גישה עם הרשאות מוגברות.
• כמה דומיינים יכולים להשתמש באותה הגדרה, בלי דומיין מותאם אישית נוסף ב-Supabase.

קובץ ה-Compose לא מעביר את SUPABASE_MANAGED_PROXY ואת SUPABASE_PROXY_UPSTREAM מ-.env: הוסיפו אותם תחת environment: של השירות nodaro. כשהם לא מוגדרים, הפרוקסי כבוי, והנתיבים המובנים מתנהגים כמו קודם.

כשמסד הנתונים לא זמין

אם Postgres לא זמין, בזמן מיגרציה או התאוששות, ה-API עולה מחדש בלולאה עד שמסד הנתונים שוב נגיש. זה צפוי. כש-Postgres חוזר לפעול, הפעילו מחדש את הקונטיינר של Nodaro:

docker compose -f docker-compose.community.yml restart nodaro

מה נשמר במסד הנתונים

תהליכים ופרויקטים, פרופילי משתמשים, הרצות וההתקדמות שלהן, משימות, הרשומות של המדיה שנוצרה, אסימוני API ואפליקציות OAuth, ומפתחות הספק ואסימוני ההתחברות לרשתות חברתיות, בהצפנה. בכל טבלה נאכפת אבטחה ברמת השורה, כך שמשתמשים רואים רק את השורות שלהם. קובצי המדיה עצמם נמצאים באחסון האובייקטים, ו-Redis שומר רק מצב זמני של משימות.

גבו את מסד הנתונים יחד עם מפתח ההצפנה: ראו את הדף גיבוי ושחזור. כדי להריץ שתי התקנות על מסד נתונים אחד, ראו את הדף הרחבת קיבולת.