يتم تشغيل الحل القياسي لعميل واجهة API الخاصة بتطبيق واتساب للأعمال على حاوية Docker واحدة. وسيؤدي وجود عدة حاويات Docker قيد التشغيل إلى حدوث مشكلات وحظر حسابك مؤقتًا. سيرشدك هذا الدليل بشأن كيفية إعداد التوفّر العالي مما يتيح لك ضبط حاويات Docker على وضع الاستعداد في حالة تعطل حاوية Docker الأساسية.
يتطلب حل التوفّر العالي هذا تثبيت مثيل واحد لعميل واجهة API لتطبيق واتساب للأعمال الحالي للتشغيل على رأس ذلك. إذا لم تقم بإعداد رقم هاتف عميل واجهة API الخاصة بتطبيق واتساب للأعمال حتى الآن، فراجع وثائق التثبيت قبل متابعة هذا الحل.
تتطلب مجموعة التوفّر العالي على الأقل وجود عقدتي Master وعقدتي Coreapp كما هو موضح في المخطط التالي:
نوصي بتشغيل كل العُقد على أجهزة/أرفف مختلفة حتى لا يؤثر فشل تشغيل جهاز/رف واحد على العديد من العُقد في الوقت نفسه.
عند بدء مجموعة، ستتنافس كل عُقد Master للحصول على إيجار رئيسي لتصبح عقدة أساسية. ولن تنجح سوى عقدة واحدة، بينما ستصبح العُقد الأخرى عُقد Master ثانوية. ففي حالة وجود عدد N من عُقد Master في المجموعة، ستتوفر عقدة Master أساسية واحدة وN-1 من عُقد Master الثانوية. تكون عقدة Master الأساسية مسؤولة عن عملية التسجيل وترقية مخطط قاعدة البيانات وبث تغييرات التكوين وإحصاءات قاعدة بيانات إعداد التقارير وإدارة المجموعة وغير ذلك. ففي حالة توقف عقدة Master الأساسية وفقدانها للإيجار الرئيسي، ستتنافس عُقد m=Master الثانوية للاستيلاء على موضع عقدة Master الأساسية.
عندما تصبح عقدة Master عقدة أساسية، فستقوم أولاً بتحميل جدول خريطة القسم من قاعدة البيانات لمعرفة عقدة Coreapp الأساسية الحالية. وفي حالة عدم وجود عقدة Coreapp أساسية في المجموعة، ستقوم عقدة Master الأساسية بترويج عقدة Coreapp ثانوية صالحة واحدة إلى عقدة Coreapp أساسية وبتحديث جدول خريطة القسم في قاعدة البيانات بحيث يمكن لـ Webapp البحث عن عقدة Coreapp التي يتعين إرسال طلبات واجهة API إليها. وبهذه الطريقة وحتى في حالة فشل تشغيل كل عُقد Master، يظل بإمكانها عرض طلبات واجهة API في عُقد Coreapp للوصول إلى التوفّر العالي.
عند بدء عقدة Coreapp، ستعمل على أنها عقدة Coreapp ثانوية حتى تقوم عقدة Master الأساسية بترويجها لتكون عقدة Coreapp أساسية بغرض اتصالها بخادم واتساب. وبعد ذلك، تكون مسؤولة عن معالجة طلبات واجهة API.
ستقوم كل عُقد Coreapp بتحديث قاعدة البيانات كل دقيقة للمطالبة باستمرار صلاحيتها. وستتحقق عقدة Master الأساسية من قاعدة البيانات دوريًا للكشف عن وجود عُقد Coreapp غير صالحة. ففي حالة عدم قيام عقدة Coreapp أساسية بتحديث قاعدة البيانات لأكثر من دقيقتين، ستعتبر عقدة Master الأساسية هذه العقدة غير صالحة وتقوم بترويج عُقد Coreapp أخرى لتكون عُقدًا أساسية. وبهذه الطريقة، يتم احتساب وقت التعطل بعد مرور دقيقتين.
إذا تضمنت مجموعة ما أكثر من عقدة Master واحدة قيد التشغيل، فستكشف المراقبة المستندة على إشارة الاتصال عن وجود حالات فشل في تشغيل العقدة بشكل أسرع من المراقبة المستندة على قاعدة البيانات. في المراقبة المستندة على إشارة الاتصال، تكون كل عُقد Master مسؤولة عن مراقبة عُقد Coreapp من خلال إرسال إشارات الاتصال إليها كل 5 ثوان (يتم تكوينها من خلال heartbeat_interval
). وفي حالة عدم استجابة عقدة Coreapp أساسية لعقدة Master الأساسية ولعقدة Master ثانوية واحدة لمدة 30 ثانية (يتم تكوينها من خلال unhealthy_interval
)، فتُعتبر هذه العقدة غير صالحة وستقوم عقدة Master الأساسية بترويج عقدة Coreapp ثانوية صالحة لعقدة Coreapp أساسية. وبهذه الطريقة، يتم افتراضيًا احتساب وقت التعطل بعد مرور 30 ثانية. يمكنك تقليل قيمة unhealthy_interval
إذا كنت تفضل تقليل وقت التعطل. للحصول على مثال على حمولات البيانات، راجع وثائق الإعدادات.
في مجموعة التوفّر العالي، توجد ثلاثة أنواع من العُقد: Webapp وMaster وCoreapp. ويمكن بدء تشغيلها بشكل منفصل في أجهزة مختلفة، لكن يلزم أن تكون في الشبكة نفسها بحيث يمكنها التحدث مع بعضها البعض.
تكون عقدة Webapp مسؤولة عن معالجة زيارات واجهة API، مثل حاوية Webapp الأصلية. وتكون عقدة Coreapp مسؤولة عن معالجة زيارات المراسلة إلى واتساب ومنه. وأخيرًا، تكون عقدة Master مسؤولة عن مراقبة عُقد Coreapp في المجموعة؛ لذلك إذا تعطلت إحدى عُقد Coreapp، فستقوم بإعادة توجيه الزيارات إلى عقدة Coreapp أخرى للحصول على التوفّر العالي. يمكن أن تتضمن المجموعة عُقد Webapp متعددة وعُقد Coreapp وعُقد Master.
لم يعد يُشار إلى العُقد النشطة على أنها عُقد تابعة. وإنما يُطلق عليها عُقد Coreapp.
ملاحظة: بالنسبة لبيئات الإنتاج، في أغلب الحالات يجب تشغيل قاعدة البيانات على خادم فعلي منفصل عن حاويات Webapp وCoreapp. وللتوفّر العالي الحقيقي، يوصى بتشغيل حاويات Master وWebapp وCoreapp على أجهزة فعلية مختلفة.
إذا لم تهتم برسائل الوسائط، فتخط هذه الخطوة.
لدعم إرسال/تلقي رسائل الوسائط، يلزم إعداد نظام ملفات NFS وتحميله إلى دليل محلي على جميع عُقد Webapp وMaster وCoreapp. وتأكد من منح أذونات القراءة/الكتابة في الدليل المشترك.
mkdir new-local-directory mount -t nfs nfs_server_IP_addr:/share_directory new-local-directory
يتطلب هذا الدليل توفير Docker وهي عبارة عن منصة لإنشاء حاوية تتيح لك تشغيل عميل API الخاصة بواتساب للأعمال. كما يلزم توفيرDocker Compose. ويتم إرفاق Docker Compose مع Docker لنظامي macOS وWindows، ولكنه يتطلب تثبيتًا منفصلاً على Linux.
multiconnect-compose.yml
وdb.env
: WhatsApp_Configuration_Files.zip.
db.env
حتى تعكس تكوين MySQL. إذا لم يكن لديك MySQL مثبت، فسيتوفر لدى ملف multiconnect-compose.yml
وملف db.env
تكوينًا افتراضيًا لاستدعاء مثيل في حاوية محلية.docker-compose -f your-single-connect-yml-filename stop
docker-compose -f multiconnect-compose.yml upستحصل على بعض المخرجات أثناء تنزيل البرنامج النصي لصور Docker وإعداد كل شيء. ولتشغيل الحاويات في الخلفية، استخدم المعلمة
-d
:
docker-compose -f multiconnect-compose.yml up -d
بمجرد إكمال هذه الخطوات، تأكد من تشغيل الحاويات باستخدام الأمر التالي:
docker-compose ps
سيتم افتراضيًا تشغيل الحاوية Webapp على المنفذ 9090.
multiconnect-coreapp.yml
وmulticonnect-master.yml
وmulticonnect-webapp.yml
وdb.env
: WhatsApp_Configuration_Files.zip واحفظ كل ملف في خادمه المعني.
db.env
حتى تعكس تكوين MySQL.docker-compose -f your-single-connect-yml-filename stop
يجب أن يكون المتغير البيئي EXTERNAL_HOSTNAME هو عنوان IP أو اسم مضيف يمكن الوصول إليه من الأجهزة المثبّت عليها حاويات أخرى. ويجب أن تكون المنافذ المعروضة في ملف الخدمة YML مفتوحة للاتصالات من الأجهزة المثبّت عليها حاويات أخرى. على سبيل المثال، تحتاج المنافذ التي تم تحديدها باعتبارها COREAPP_EXTERNAL_PORTS
في multiconnect-coreapp.yml
إلى أن يتم فتحها للزيارات الواردة على المضيف الذي يشغّل حاويات coreapp
.
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml up # on the Coreapp server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml up # on the Master server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml up # on the Webapp serverستحصل على بعض المخرجات أثناء تنزيل البرنامج النصي لصور Docker وإعداد كل شيء. ولتشغيل الحاويات في الخلفية، استخدم المعلمة
-d
:
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml up -d # on the Coreapp server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml up -d # on the Master server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml up -d # on the Webapp server
بمجرد إكمال هذه الخطوات، تأكد من تشغيل الحاويات باستخدام الأمر التالي:
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml ps # on the Coreapp server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml ps # on the Master server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml ps # on the Webapp server
ولن يعمل تشغيل مثيلات متعددة للخدمة نفسها (مثل تشغيل 2 من حاويات Coreapp على المضيف نفسه) افتراضيًا بسبب تعارض منفذ المضيف. ولتجنب تعارض المنفذ، فيجب تعديل ملف الخدمة بتنسيق YML ذي الصلة، وهو multiconnect-coreapp.yml
في هذه الحالة، من أجل عرض منافذ مختلفة للمضيف لكل مثال مما يلي:
ports:
- "HOST_PORT_RANGE:6250-6253"
سيتم افتراضيًا تشغيل الحاوية Webapp على المنفذ 9090.
يحتوي ملف multiconnect-compose.yml
على حقول تشير إلى إصدارات الحاوية. على سبيل المثال:
services: ... waweb: image: docker.whatsapp.biz/web:v2.19.4 ... master: image: docker.whatsapp.biz/coreapp:v2.19.4 ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.4
لترقية التثبيت، يمكنك تغيير أرقام الإصدار في ملف multiconnect-compose.yml
:
services: ... waweb: image: docker.whatsapp.biz/web:v2.19.7 ... master: image: docker.whatsapp.biz/coreapp:v2.19.7 ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.7
بعد ذلك، أعد تشغيل حاويات Docker:
docker-compose -f multiconnect-compose.yml up
تحتوي ملفات YAML على حقول تشير إلى إصدارات الحاوية. على سبيل المثال:
services: ... waweb: image: docker.whatsapp.biz/web:v2.19.4
services: ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.4
services: ... master: image: docker.whatsapp.biz/coreapp:v2.19.4
لترقية عملية تثبيت، قم بتغيير أرقام الإصدارات في الملفات ذات الصلة:
services: ... waweb: image: docker.whatsapp.biz/web:v2.19.7
services: ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.7
services: ... master: image: docker.whatsapp.biz/coreapp:v2.19.7
بعد ذلك، أعد تشغيل حاويات Docker:
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml up # on the Coreapp server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml up # on the Master server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml up # on the Webapp server
إذا كانت لديك وحدات تخزين وسائط من عملية تثبيت سابقة، فاستبدل تعريف وحدة التخزين التالية في ملفات YAML:
volumes: whatsappData: driver: local whatsappMedia: driver: local
بـ:
volumes: whatsappData: external: true whatsappMedia: external: true
لا يوصى بذلك إلا إذا كنت تريد الحفاظ على وحدة تخزين نقطة تحميل ربط حالية.
إذا كنت تريد تحميل مسار مضيف (موقع حالي على المضيف) مباشرةً في الحاوية، فيمكنك إجراء ذلك من خلال تغيير سطر وحدة التخزين داخل قسم الخدمة للإشارة إلى مسار المضيف.
wacore: volumes: /filepath/waent/data:/usr/local/waent/data /filepath/wamedia:/usr/local/wamedia
سيكون عليك تكرار ذلك لجميع الأجهزة التي لديك عُقد تقوم بتشغيلها بها.
إذا كنت تريد إعادة تعيين بيئة التطوير لديك من خلال إزالة كل الحاويات، فيمكنك تشغيل الأمر التالي من الدليل الذي يتضمن الملف multiconnect-compose.yml
:
docker-compose -f multiconnect-compose.yml down
للتخلص من جميع وحدات التخزين المحددة في ملف multiconnect-compose.yml
وكذلك من الحاويات، فيمكنك تشغيل down
باستخدام المعلمة -v
:
docker-compose -f multiconnect-compose.yml down -v
إذا كنت تريد إعادة تعيين بيئة التطوير عن طريق إزالة كل الحاويات، فيمكنك تشغيل الأمر التالي من الدليل الذي يتضمن ملف YAML على كل خادم:
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml down # on the Coreapp server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml down # on the Master server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml down # on the Webapp server
للتخلص من جميع وحدات التخزين المحددة في ملفات YAML وكذلك من الحاويات، يمكنك تشغيل down
باستخدام المعلمة -v
:
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml down -v # on the Coreapp server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml down -v # on the Master server EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml down -v # on the Webapp server
للحصول على سجلات استكشاف الأخطاء وإصلاحها، قم بتشغيل الأمر التالي على الخوادم الخاصة بك:
docker-compose logs > debug_output.txt