يعتمد نشر OpenReplay على Helm Charts مما يجعله متوافقًا تمامًا مع Kubernetes. نقوم بتغليف PostgreSQL وRedis، وهما مطلوبان لـ OpenReplay. إليك كيفية القيام بذلك.

يتطلب نشر OpenReplay على Kubernetes ما يلي:

• Kubernetes v1.18+
• helm 3.10+
• RWX PVC مع صلاحية القراءة والكتابة (RW) لمعرّف المستخدم 1001 (للمكونات المشتركة، إذا كان العنقود يحتوي على أكثر من عقدة واحدة). تأكد من استبدال hostPath باسم الـ pvc الذي تم إنشاؤه في /var/lib/openreplay/vars.yaml.

# In case of multiple nodes in the kubernetes cluster,
# You'll have to create an RWX PVC for shared components.
# If it's a single node, we'll use hostVolume, which is the default for the community/oss edition.
pvcRWXName: "hostPath"

كما يتطلب OpenReplay 2 vCPUs, 8 GB of RAM, 50 GB of storage للعمل بشكل صحيح، وإلا فإن خدمات الواجهة الخلفية لـ OpenReplay لن تبدأ ببساطة. هذه المواصفات كافية لحجم معتدل، ولكن إذا كنت تتوقع حركة مرور عالية، فعليك التوسّع انطلاقًا من هنا.

تم اختبار النشر على المنصات التالية:

• عنقود Kube محلي بعقدة واحدة
• Google Kubernetes Engine (GKE)
• Amazon Elastic Kubernetes Service (EKS)
• Microsoft Azure Kubernetes Service (AKS)
• Scaleway Elements Kubernetes (Kapsule)

اتصل بعنقودك واستنسخ مستودع OpenReplay:

git clone https://github.com/openreplay/openreplay.git
cd openreplay/scripts/helmcharts

إذا كانت هناك عقد متعددة في عنقود Kubernetes، فسيتعين عليك إنشاء RWX PVC (على سبيل المثال efs، في حالة AWS) لكي تتشارك الحاويات البيانات. وإذا كانت عقدة واحدة، فسنستخدم hostVolume، وهو الافتراضي لتثبيت community.

ثم، افتح ملف vars.yaml باستخدام الأمر vim vars.yaml ثم استبدل:

• domainName: هذا هو المكان الذي سيكون فيه OpenReplay متاحًا (أي openreplay.mycompany.com)
• postgresqlPassword: كلمة مرور Postgres (قم بتعيينها أو أنشئ كلمة عشوائية)
• accessKey: مطلوب لخدمة تخزين الكائنات (استخدم سلسلة نصية مُولّدة عشوائيًا)
• secretKey: مطلوب لخدمة تخزين الكائنات (استخدم سلسلة نصية مُولّدة عشوائيًا)
• jwt_secret: مطلوب لـ API (استخدم سلسلة نصية مُولّدة عشوائيًا)

تأكد من أن لديك helm مثبتًا ثم قم بإعداد OpenReplay:

cd openreplay/scripts/helmcharts
helm upgrade --install databases ./databases -n db --create-namespace --wait -f ./vars.yaml --atomic
helm upgrade --install openreplay ./openreplay -n app --create-namespace --wait -f ./vars.yaml --atomic

يتعامل OpenReplay مع بيانات حساسة للمستخدمين، وبالتالي يتطلب HTTPS للعمل. هذا إلزامي، وإلا فإن الـ tracker لن يبدأ التسجيل ببساطة. الأمر نفسه ينطبق على لوحة التحكم، فبدون HTTPS لن تتمكن من إعادة تشغيل جلسات المستخدمين.

إذا كان عنقود Kubernetes الخاص بك في السحابة (مثل EKS أو AKS أو GKE)، فإن أسهل طريقة للتعامل مع SSL هي إعداد موازِن تحميل سحابي وتشغيل عنقودك خلفه. والخيار الآخر هو إنشاء أو استخدام شهادة SSL الخاصة بك وتوجيه نطاقك الفرعي (أي openreplay.mycompany.com) إلى عنقودك. المزيد عن كلا الخيارين أدناه.

من أهم فوائد تشغيل OpenReplay خلف موازِن تحميل سحابي هو أن يتولى مزوّد الخدمة السحابية إدارة الشهادة. فيما يلي أدلة خطوة بخطوة حول كيفية الإنشاء:

• AWS - Elastic Load Balancing
• Google - Cloud Load Balancing
• Azure - Load Balancer
• Digital Ocean - تكوين TLS/SSL

ثم تأكد من أن عنقودك يوفّر نوع خدمة LoadBalancer حتى يمكن توجيه حركة المرور القادمة من موازِن التحميل السحابي إلى الواجهة الخلفية لـ OpenReplay. الآن، انتقل إلى مزوّد خدمة DNS الخاص بك وأنشئ A Record يشير إلى العنقود باستخدام عنوان IP العام الخاص به.

أخيرًا، فعّل use-forwarded-headers عن طريق إلغاء التعليق عن السطر أدناه ضمن قسم ingress-nginx، في /var/lib/openreplay/vars.yaml:

ingress-nginx: &ingress-nginx
  controller:
    config:
      use-forwarded-headers: true

أصبح كل شيء جاهزًا الآن، ومن المفترض أن يكون OpenReplay متاحًا على نطاقك الفرعي. يمكنك إنشاء حساب بزيارة صفحة /signup (أي openreplay.mycompany.com/signup).

كبديل لإنشاء موازِن تحميل، يمكنك إحضار (أو إنشاء) شهادة SSL الخاصة بك.

1. أولًا، انتقل إلى مزوّد خدمة DNS الخاص بك وأضف A Record. استخدم النطاق الذي قدّمته سابقًا أثناء خطوة التثبيت ووجّهه إلى العنقود باستخدام عنوان IP العام الخاص به.

2. إذا كنت تحضر شهادتك الخاصة، فأنشئ سرّ SSL باستخدام الأمر التالي: kubectl create secret tls openreplay-ssl -n app --key="private_key_file.pem" --cert="certificate.crt".

ملاحظة: إذا لم تكن لديك شهادة، فأنشئ واحدة تتجدّد تلقائيًا، لنطاقك الفرعي (الذي قُدّم أثناء التثبيت) باستخدام Let’s Encrypt. ما عليك سوى الاتصال بنسخة OpenReplay، وتشغيل cd /var/lib/openreplay/openreplay/scripts/helmcharts && bash certmanager.sh واتباع الخطوات.

3. إذا كنت ترغب في تمكين إعادة التوجيه من http إلى https (موصى به)، فألغِ التعليق عن الكتلة أدناه، ضمن قسم ingress-nginx، في /var/lib/openreplay/vars.yaml:

ingress-nginx: &ingress-nginx
  controller:
    config:
      ssl-redirect: true
      force-ssl-redirect: true

تجدر الإشارة إلى أن ingress-nginx الخاص بنا يعمل افتراضيًا على المنفذين 80|443، ولكن يمكن تغيير ذلك بسهولة، عند الحاجة، في vars.yaml:

ingress-nginx: &ingress-nginx
  controller:
    service:
      ports:
        http: 80
        https: 443

4. أخيرًا، أعد تثبيت NGINX الخاص بـ OpenReplay:

openreplay -R

أصبح كل شيء جاهزًا الآن، ومن المفترض أن يكون OpenReplay متاحًا على نطاقك الفرعي. يمكنك إنشاء حساب بزيارة صفحة /signup (أي openreplay.mycompany.com/signup).

يرجى إخبارنا عبر Slack أو من خلال Github Issue إذا كنت تواجه مشكلة على منصتك. سيسعدنا مساعدتك في تشغيله.