انتقل إلى المحتوى
Repovio

نشر Repovio

نشر الإنتاج، وكيل TLS، والنسخ الاحتياطي، والاستعادة، والترقية، وإرشادات التراجع لـ Repovio.

لقطة المصدر المؤرشفة. تم تطبيع تسميات المنتج إلى Repovio. بالنسبة لهذا الإصدار التاريخي، استخدم معرفات التكوين ومراجع الحاوية من ملفات النشر ذات العلامات دون تغيير.

يبدأ مكدس الإنشاء الخاص بـ Repovio PostgreSQL، ويطبق عمليات ترحيل Prisma مرة واحدة، ثم يبدأ واجهة برمجة التطبيقات (API) وتطبيقات الويب. لا ينهي TLS. ضع خدمات الويب وواجهة برمجة التطبيقات (API) خلف وكيل عكسي يمتلك اسم المضيف العام والشهادات.

المتطلبات الأساسية

  • محرك Docker مع Docker Compose v2.
  • سجل DNS لاسم المضيف العام.
  • وكيل عكسي يحصل على شهادات TLS ويجددها.
  • دليل خادم خاص لا يمكن قراءته إلا من قبل مسؤولي النشر.

تحتفظ مكدس الإنشاء ببيانات PostgreSQL، بما في ذلك صور ملف تعريف المستخدم التي تمت تسويتها، في وحدة التخزين المسماة PostgreSQL التي تم تكوينها في ملف الإنشاء الموسوم. لا تقم بحذف وحدة التخزين هذه إلا إذا كنت ترغب عمدًا في إزالة كافة بيانات Repovio.

النشر الأول

الخطوة 1: التحقق من إصدار Repovio وإنشاء ملف البيئة الخاص:

cp .env.example .env
chmod 600 .env

الخطوة 2: استبدل كل عنصر نائب في .env، وخاصة POSTGRES_PASSWORD، وعناوين URL لقاعدة البيانات، وAUTH_JWT_SECRET، و

TOKEN_ENCRYPTION_KEY. قم بإنشاء مفتاح التشفير باستخدام:

openssl rand -base64 32

الخطوة 3: قم بتعيين عناوين URL المرئية خارجيًا. للنشر في https://repovio.example.com، استخدم:

PUBLIC_URL=https://repovio.example.com
OIDC_CALLBACK_URL=https://repovio.example.com/api/v1/auth/oidc/callback
CORS_ORIGIN=https://repovio.example.com
NUXT_PUBLIC_API_BASE_URL=https://repovio.example.com/api/v1
OAUTH_CALLBACK_URL=https://repovio.example.com/api/v1/provider-accounts/oauth/callback

الخطوة 4: ربط منافذ الحاوية للاسترجاع عند تشغيل الوكيل العكسي على نفس المضيف:

استخدم متغيرات واجهة برمجة التطبيقات (API) ومنفذ الويب في .env.example للإصدار، مع القيمتين 127.0.0.1:3001 و127.0.0.1:3000 على التوالي. تختلف أسماء المتغيرات التاريخية عن إصدارات Repovio الحالية.

بخلاف ذلك، قم بتقييد الوصول إلى المنفذين 3000 و3001 باستخدام جدار الحماية المضيف. لا تعرض أبدًا حاوية PostgreSQL.

الخطوة 5: قم بتعيين متغير تحديد الإصدار من .env.example الموسوم في .env إلى زوج صور تم إصداره بالضبط، ثم ابدأ المكدس:

docker compose pull
docker compose up --detach --wait

احتفظ بهذه القيمة في .env بحيث يستخدم كل أمر إنشاء لاحق نفس واجهة برمجة التطبيقات وإصدار الويب.

الخطوة 6: تأكيد نقطة نهاية سلامة واجهة برمجة التطبيقات محليًا:

curl --fail http://127.0.0.1:3001/api/health

الخطوة 7: افتح عنوان URL العام لـ Repovio وأكمل الإعداد للتشغيل الأول لمرة واحدة لإنشاء أول عنوان URL

مسؤول النظام.

الوكيل العكسي وTLS

قم بتوصيل أصل الويب العام إلى المنفذ 3000، ومسارات API وSocket.IO إلى المنفذ 3001. على سبيل المثال، يمكن أن تستخدم كتلة موقع Caddy:

repovio.example.com {
  reverse_proxy /api/* 127.0.0.1:3001
  reverse_proxy /socket.io/* 127.0.0.1:3001
  reverse_proxy /mcp 127.0.0.1:3001
  reverse_proxy 127.0.0.1:3000
}

يجب على الوكيل إعادة توجيه HTTP إلى HTTPS، والتحقق من صحة الاتصالات الأولية وفقًا لسياسته المحلية، والحفاظ على اسم المضيف العام. قم بتكوين موفري OAuth بنفس عنوان URL لرد اتصال HTTPS الذي تم تعيينه في OAUTH_CALLBACK_URL.

الترقية

استخدم التكوين الدقيق ومراجع الصور المرفقة مع هذا الإصدار التاريخي. تنطبق تعليمات ترقية العلامة التجارية الحالية فقط عند الانتقال إلى إصدار أحدث من Repovio؛ لا تقم مطلقًا بنسخ معرفات التكوين المعاد تسميتها إلى ملف إنشاء قديم.

الخطوة 1: إنشاء نسخة احتياطية لقاعدة البيانات والتحقق منها قبل تغيير الصور.

الخطوة 2: قم بتعيين متغير تحديد الإصدار من .env.example الموسوم إلى إصدار الإصدار الدقيق في .env.

الخطوة 3: سحب الإصدار وتطبيقه:

docker compose pull
docker compose up --detach --wait

تطبق خدمة migrate عمليات ترحيل Prisma المعلقة قبل بدء تشغيل واجهة برمجة التطبيقات (API). قم بفحصه بعد كل تحديث:

docker compose logs migrate

الخطوة 4: تحقق من نقطة النهاية الصحية ولوحة المعلومات التي يخدمها الوكيل قبل التفكير في اكتمال التحديث.

النسخ الاحتياطي لقاعدة البيانات

قم بتشغيل النسخ الاحتياطية من دليل النشر. يؤدي هذا إلى كتابة تفريغ PostgreSQL بتنسيق مخصص إلى المضيف دون طباعة بيانات الاعتماد أو وضعها في سطر الأوامر:

mkdir -p backups
backup_file="backups/repovio-$(date +%F-%H%M%S).dump"
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' \
  > "$backup_file"
pg_restore --list "$backup_file"

قم بتخزين النسخ المشفرة خارج المضيف واختبار عمليات الاستعادة بشكل دوري على نظام منفصل.

استعادة قاعدة البيانات

تؤدي الاستعادة إلى استبدال كائنات قاعدة البيانات الحالية. خذ نسخة احتياطية جديدة أولاً وقم بجدولة وقت التوقف عن العمل.

docker compose stop api web
docker compose exec -T postgres sh -c 'pg_restore -U "$POSTGRES_USER" --clean --if-exists --no-owner -d "$POSTGRES_DB"' \
  < backups/repovio-YYYY-MM-DD-HHMMSS.dump
docker compose up --detach --wait

بعد ذلك، تحقق من docker compose logs migrate ونقطة نهاية سلامة API. قم باستعادة التفريغ الذي تم إنشاؤه بواسطة إصدار Repovio المتوافق عند التراجع عبر تغييرات المخطط.

التراجع

الخطوة 1: احتفظ بالنسخة الاحتياطية فورًا قبل فشل الترقية.

الخطوة 2: قم بتعيين متغير تحديد الإصدار من .env.example الموسوم في .env إلى آخر إصدار صورة معروف جيدًا.

الخطوة 3: تشغيل docker compose pull وdocker compose up --detach --wait.

الخطوة 4: إذا كان الإصدار الأحدث قد قام بترحيل قاعدة البيانات بشكل غير متوافق، فأوقف واجهة برمجة التطبيقات والويب، واستعد النسخة الاحتياطية المتوافقة، ثم

ابدأ إصدار الصورة السابقة مرة أخرى.

لا تستخدم أبدًا docker compose down --volumes كأمر تحديث أو التراجع: فهو يزيل وحدة التخزين PostgreSQL المسماة.

تحرير هذه الصفحة

السابق

بحث في التوثيق...