עדכון גרסה

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

תגי אימג׳

כל בנייה של הענף main מפרסמת את האימג׳ של האפליקציה, ghcr.io/nodaroai/nodaro-community, בתג latest ובתג של ה-commit שלה. כל שחרור גרסה מוסיף שלושה תגי גרסה.

בחרו את התג במשתנה NODARO_IMAGE בקובץ .env, למשל NODARO_IMAGE=ghcr.io/nodaroai/nodaro-community:v1.23.0.

עדכון ההתקנה

כדי לעדכן רק את האפליקציה:

docker compose -f docker-compose.community.yml pull nodaro
docker compose -f docker-compose.community.yml up -d nodaro

כדי לעדכן גם את קובץ ה-Compose, את הסקריפטים שב-tools/ ואת השירותים המובנים:

git pull
docker compose -f docker-compose.community.yml pull
docker compose -f docker-compose.community.yml up -d

אם אתם בונים את האימג׳ מקוד המקור, למשל עבור מהדורת Business, החליפו את pull ב-build. הפקודה pull הייתה מורידה את האימג׳ של מהדורת Community שפורסם.

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

לפני גרסה ראשית

גרסה ראשית משנה את המספר הראשון, למשל מ-v1 ל-v2. רק בגרסאות ראשיות מותר לשנות משתני סביבה, את הטופולוגיה של ה-Compose או התנהגות שאתם עשויים להסתמך עליה.

1. קראו את עדכוני הגרסה ב-GitHub.
2. צרו גיבוי עם tools/community-backup.sh. ראו את הדף גיבוי ושחזור.
3. עדכנו, ואז בדקו את הדף /setup: כל הכרטיסים צריכים להיות ירוקים.

חזרה לגרסה קודמת

אין דרך לבטל מיגרציות: מסד הנתונים מתקדם רק קדימה. כדי לחזור לגרסה קודמת:

1. שחזרו את הגיבוי שיצרתם לפני העדכון: tools/community-restore.sh <archive>.
2. קבעו את ההתקנה על האימג׳ הישן, למשל NODARO_IMAGE=ghcr.io/nodaroai/nodaro-community:v1.25.1. תגי vX.Y.Z מלאים אף פעם לא זזים.
3. הפעילו את האפליקציה עם docker compose -f docker-compose.community.yml up -d nodaro.

עם פרויקט Supabase מנוהל

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

איזו גרסה רצה אצלכם

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

בדיקת העדכונים שולחת בקשה אנונימית אחת ביום ל-API של GitHub. אחרי בדיקה שנכשלה, Nodaro מנסה שוב אחרי 5 דקות, ואחר כך בתדירות הולכת ופוחתת, עד שבדיקה מצליחה.

GitHub מאפשר 60 בקשות אנונימיות בשעה לכל כתובת יציאה. התקנה עם כתובת משלה אף פעם לא צריכה אסימון. בהתקנה שחולקת את הכתובת שלה עם אחרים, ייתכן שזרים כבר מיצו את המכסה הזאת. אז תווית הגרסה חוזרת לגרסה המובנית, ורשימת עדכוני הגרסה נשארת ריקה עד שניסיון חוזר מצליח. שורת היומן [update-check] … read failed: HTTP 403 (rate limit: 0 of 60 left…) היא הסימן לכך. האסימון נשלח רק ל-api.github.com ולעולם לא נרשם ביומן.

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

  nodaro:
    environment:
      # ...the variables already listed...
      NODARO_UPDATE_CHECK: "off"

הפעילו מחדש כדי שהשינוי ייכנס לתוקף.

עדכון שרת מ-GitHub Actions

במאגר הקוד יש workflow לדוגמה, examples/deploy-host.yml, שמעדכן שרת Nodaro דרך SSH:

1. העתיקו אותו למאגר הקוד שלכם, לתיקייה .github/workflows/.
2. הגדירו את הסודות של מאגר הקוד DEPLOY_HOST, DEPLOY_USER ו-DEPLOY_SSH_KEY.
3. התאימו לשרת שלכם את תיקיית ההתקנה ואת פקודת ה-Compose שבסקריפט שלו.
4. הריצו אותו ידנית מהלשונית Actions, ובחרו את תג האימג׳ לפריסה.

ה-workflow מתחבר לשרת, מריץ docker compose pull ו-docker compose up -d, מחכה עד 90 שניות לתשובה מ-/health, ואז מוחק שכבות ישנות של אימג׳ים. לעולם אל תתחילו פריסה לסביבת ייצור בעקבות push לענף, והשתמשו בשמות סודות נפרדים לכל סביבה.