> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# استضافة Failproof AI Cloud ذاتياً

> نشر مستوى التحكم في Failproof AI على مجموعة Kubernetes التي يديرها العميل.

<Note>
  الاستضافة الذاتية هي نشر Enterprise. [تواصل مع Failproof AI](mailto:support@befailproof.ai) للحصول على ترخيص enterprise.
</Note>

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

* Kubernetes 1.27 أو أحدث مع وصول cluster-admin
* `kubectl` مع دعم Kustomize
* Helm 3
* الوصول إلى صور `ghcr.io/agenteye-enterprise` الخاصة
* اسما نطاق DNS: واحد للوحة التحكم وواحد للبيانات الواردة
* تخزين دائم لـ PostgreSQL و ClickHouse
* cert-manager و Traefik، أو بنية ingress وشهادات معادلة متكيفة في overlay خاصتك
* SMTP للإنتاج لتسجيل OTP والإخطارات

تقدم شجرة المصدر overlay موجهة نحو AWS/EKS وoverlay منفصل لـ GCP/GKE. لا تجمع بين تعليماتهم الخاصة بالشهادات أو موازن الحمل أو النسخ الاحتياطية: GKE يستخدم DNS-01 و GCS وتكوين التوسع التلقائي الخاص به.

## تسلسل النشر

<Steps>
  <Step title="تحضير المجموعة">
    ثبّت cert-manager ومتحكمات ingress العامة/لوحة التحكم، تحقق من موازنات الحمل الخاصة بها، ثم أنشئ مساحة الأسماء وبيانات اعتماد سحب الصور وبيانات اعتماد قاعدة البيانات ومفتاح admin للتمهيد وأسرار المصادقة/SMTP.
  </Step>

  <Step title="تكوين النطاقات العامة">
    اضبط `INGEST_DOMAIN` و `DASHBOARD_DOMAIN` في ملف بيئة النطاق المُنشأ في overlay وأنشئ سجلات DNS تشير إلى موازنات الحمل المطابقة.
  </Step>

  <Step title="تطبيق والتحقق من overlay للمنصة">
    استخدم overlay customer/EKS أو GCP. افحص الإخراج المُصيّر لـ Kustomize، طبّقه، وأكّد أن جميع الأحمال والشهادات تصل إلى حالتها المقصودة قبل تسجيل الأجهزة.
  </Step>

  <Step title="تمهيد الوصول والبيانات الواردة">
    سجّل الدخول كمسؤول محمي، أنشئ مفتاح جهاز محدود النطاق للمنظمة، وأرسل جلسة اختبار صغيرة عبر نقطة نهاية البيانات الواردة العامة.
  </Step>
</Steps>

## الخدمات المطلوبة والاختيارية

| المكون                           | المتطلب                                                                                  |
| -------------------------------- | ---------------------------------------------------------------------------------------- |
| ClickHouse                       | مطلوب. يرفض الخادم البدء بدون مخزن الأحداث الأساسي الخاص به.                             |
| PostgreSQL                       | مطلوب للمستخدمين والمنظمات والكائنات المحفوظة وحالة مستوى التحكم.                        |
| Redis                            | اختياري. يتدهور الخادم ولوحة التحكم إلى السلوك المدعوم من قاعدة البيانات عند عدم توفره.  |
| SMTP                             | اختياري للتطوير، مطلوب للإنتاج لـ OTP البريد الإلكتروني وتوصيل الإخطارات.                |
| Evaluator                        | اختياري. يبقى التقييم التلقائي معطلاً بدون `EVALUATOR_ENDPOINT`.                         |
| LLM للمساعد/التدقيق              | اختياري. تبقى ميزات المساعد والتدقيق المدعومة بـ LLM غير فعّالة حتى يتم تكوين اتصال LLM. |
| النسخ الاحتياطية لتخزين الكائنات | موصى به بشدة لأرشيفات النسخ الاحتياطية لـ PostgreSQL و ClickHouse.                       |

### السعة التدقيقية وتوصيل الفشل

قم بتشغيل التدقيقات على نشر audit-agent المخصص عند توفره. تقبل كل pod audit-agent تحقيقاً واحداً بشكل افتراضي؛ قم بتغيير الإنتاجية باستخدام النسخ المتماثلة بدلاً من رفع التزامن لكل pod دون زيادة الذاكرة أيضاً. يمكن للخادم إرسال `server replicas × AUDIT_WORKERS` تدقيقات بشكل متزامن، لذلك يجب أن تكون السعة الموزعة كبيرة بما يكفي لملء أسطول audit-agent.

عندما تكون كل فتحة audit-agent مشغولة، ينتظر التدقيق ويحاول مجدداً لمدة تصل إلى ربع الدورة الزمنية، مع حد أقصى قدره ست ساعات. إذا لم تتوفر أي فتحة، يكتمل التشغيل بدون نتائج ويرسل بريداً إلكترونياً بالفشل. تتطلب فشل "مشغول" المتكررة مزيداً من نسخ audit-agent أو نقاط تثبيت جدول زمني أكثر تباعداً. يشير فشل "الإيقاف" المتكرر إلى أجهزة غير مستقرة أو rollout حلقي بدلاً من عدم كفاية السعة.

تتطلب إخطارات الفشل قناة بريد إلكتروني مفعّلة و SMTP. فهي تستخدم متلقي التدقيق، ثم تعود إلى `alerts.email_default_recipients` عندما لا يحتوي التدقيق على قناة بريد إلكترونية.

## التحقق من النشر

<Tabs>
  <Tab title="لوحة التحكم">
    1. افتح نطاق لوحة التحكم المكوّن، أكمل تدفق admin OTP، وأكّد اسم المنظمة والـ slug الخاص بها.
    2. انتقل إلى **Administration → Keys** وأنشئ مفتاح جهاز محدود النطاق.
    3. أرسل جلسة اختبار، ثم أكّدها في **Observe → Events** و **Observe → Sessions**.
    4. اختبر قناة تنبيه وعند التكوين تقييماً يدوياً وتدقيقاً.
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    kubectl get pods -n agenteye
    kubectl get certificates -n agenteye
    kubectl logs -n agenteye deploy/server --tail=100

    fp --base-url https://failproof.example.com login
    fp --base-url https://failproof.example.com whoami
    fp --base-url https://failproof.example.com usage
    ```

    تحقق من نقطة نهاية الصحة العامة وطلب `/v1` موثق واحد قبل تسجيل أجهزة الإنتاج.
  </Tab>
</Tabs>

## المصادقة والبريد الإلكتروني

تستخدم لوحة التحكم البريد الإلكتروني والرموز لمرة واحدة. بدون SMTP، يسجل نشر التطوير رموز OTP في إخراج الخادم. عندما يتم تعيين `SMTP_HOST`، يكون اسم المستخدم وكلمة المرور والمرسل مطلوبين كمجموعة أو يرفض الخادم البدء.

`SMTP_TLS` هو منطقي. النقل المشفر المدعوم هو STARTTLS، عادة على المنفذ 587؛ SMTPS الضمني على المنفذ 465 غير مدعوم من قبل نقل الخادم الحالي.

عيّن عنوان لوحة التحكم العام بشكل صحيح لأن بريد OTP والتنبيهات والحوادث والتدقيق يستخدمه للروابط العميقة. تتحكم العضوية في المنظمة في من قد يطلب رمزاً؛ يمكن لكل منظمة تقييد عمليات تسجيل الدخول للأعضاء الخاصة بها بشكل إضافي في **Administration → Settings**.

## متطلبات متعدد المستأجرين

قبل إنشاء منظمة ثانية، كوّن مشتقة ClickHouse قوية وثابتة لسر المنظمة واحتفظ بها متطابقة عبر جميع نسخ الخادم. قد يؤدي تدويرها دون هجرة منسقة إلى فقدان مستخدمي ClickHouse الخاصين بالمنظمة.

اجعل مستمع admin للمثيل داخلياً. وحدة التحكم المشغل المُقدمة طوعية وتم تصميمها لـ `kubectl port-forward`، وليس للـ ingress العام. يتطلب تفعيلها مفتاح API قوياً خاصاً بها وصندوق بريد super-admin وعامل SMTP مشفر للمرة الثانية.

### CLI المنظمة للحالات الطارئة

يتم شحن `agenteye-orgctl` داخل صورة الخادم ويتحدث مباشرة إلى PostgreSQL و ClickHouse. يبقى متاحاً عندما يكون الخادم العام أو وحدة التحكم المشغل غير صحية.

```bash theme={null}
kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org create --slug acme --name "Acme Corp"
kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list
kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email ops@acme.com --set admin --protected
```

تتضمن عمليات المنظمة المدعومة الإنشاء والقائمة وإعادة التسمية والحذف الناعم والاستعادة وإعادة توفير مستخدم ClickHouse وإدارة تاريخ الفواتير وأعلام الميزات والتطهير غير القابل للعكس. تتضمن عمليات الأعضاء الإضافة والقائمة والتحديث والإزالة وتجاوزات الأذونات وحالة admin المحمي.

استخدم soft-delete قبل purge. `org purge` غير قابل للعكس ويتطلب حذف المنظمة أولاً. لا يمكن إزالة الأعضاء المحميين أو خفض رتبتهم من خلال صفحة المستخدمين العادية للمنظمة حتى يقوم المشغل بإلغاء حمايتهم صراحة.

## قائمة التحقق من جاهزية الإنتاج

* يتم حل نطاق DNS للبيانات الواردة ولوحة التحكم إلى مسارات ingress مختلفة مقصودة.
* TLS صحيح؛ استخدم TLS متبادل على البيانات الواردة حيث يتطلب النشر ذلك.
* تحتوي مجلدات PostgreSQL و ClickHouse على تنبيهات السعة.
* تتضمن النسخ الاحتياطية كلا مخزن البيانات ولديها إجراء استعادة مختبر.
* تنبه فحوصات الصحة على صمت البيانات الواردة والأحمال الفاشلة وانتهاء الشهادة والضغط على التخزين والنسخ الاحتياطية القديمة.
* يتم جمع السجلات المنظمة بدون تكرار خط أنابيب سجل مجموعة موجودة.
* لم يتم تغيير التزامن للمُقيّم والمدقق والعامل التنبيهي بدون دليل قائمة الانتظار المقاس.
* يتم تسجيل إصدار تطبيق مثبت وإجراء rollback قبل الترقيات.

<Warning>
  تحتوي بيانات النشر على افتراضات أمان وتوفر خاص بالمنصة. راجع الموارد المُصيّرة وسياسات الشبكة وتعريض Ingress ومراجع الأسرار وفئات التخزين وميزانيات الانقطاع وأهداف النسخ الاحتياطية مع فريق المنصة الخاص بك قبل تطبيقها.
</Warning>