🥇الانتقال السلس لـ RabbitMQ إلى Kubernetes

RabbitMQ هو وسيط رسائل مكتوب بلغة Erlang يسمح لك بتنظيم مجموعة تجاوز الفشل مع النسخ المتماثل الكامل للبيانات عبر عقد متعددة، حيث يمكن لكل عقدة خدمة طلبات القراءة والكتابة. نظرًا لوجود العديد من مجموعات Kubernetes في عملية الإنتاج، فإننا ندعم عددًا كبيرًا من عمليات تثبيت RabbitMQ ونواجه الحاجة إلى ترحيل البيانات من مجموعة إلى أخرى دون توقف.

كنا بحاجة إلى هذه العملية في حالتين على الأقل:

نقل البيانات من مجموعة RabbitMQ غير الموجودة في Kubernetes إلى مجموعة جديدة - "kubernetized" بالفعل (أي تعمل في كبسولات K8s) -.
ترحيل RabbitMQ داخل Kubernetes من مساحة اسم إلى أخرى (على سبيل المثال، إذا كانت الدوائر محددة بمساحات الأسماء، فسيتم نقل البنية التحتية من دائرة إلى أخرى).

تركز الوصفة المقترحة في المقالة على المواقف (ولكنها لا تقتصر عليها على الإطلاق) حيث توجد مجموعة RabbitMQ قديمة (على سبيل المثال، من 3 عقد)، موجودة إما بالفعل في K8s أو على بعض الخوادم القديمة. يعمل معه تطبيق مستضاف على Kubernetes (موجود بالفعل أو في المستقبل):

... ونحن نواجه مهمة ترحيله إلى الإنتاج الجديد في Kubernetes.

أولاً، سيتم وصف النهج العام للترحيل نفسه، وبعد ذلك سيتم وصف التفاصيل الفنية لتنفيذه.

خوارزمية الهجرة

المرحلة الأولية الأولى قبل أي إجراء هي التحقق من تمكين وضع الإتاحة العالية في تثبيت RabbitMQ القديم (HA). السبب واضح - لا نريد أن نفقد أي بيانات. لإجراء هذا التحقق، يمكنك الانتقال إلى لوحة إدارة RabbitMQ وفي علامة التبويب المسؤول → السياسات والتأكد من تعيين القيمة ha-mode: all:

الخطوة التالية هي رفع مجموعة RabbitMQ جديدة في كبسولات Kubernetes (في حالتنا، على سبيل المثال، تتكون من 3 عقد، ولكن قد يكون عددها مختلفًا).

بعد ذلك، نقوم بدمج مجموعات RabbitMQ القديمة والجديدة، ونحصل على مجموعة واحدة (من 6 عقد):

تبدأ عملية مزامنة البيانات بين مجموعات RabbitMQ القديمة والجديدة. بمجرد مزامنة جميع البيانات بين جميع العقد في المجموعة، يمكننا تبديل التطبيق لاستخدام المجموعة الجديدة:

بعد هذه العمليات، يكفي إزالة العقد القديمة من مجموعة RabbitMQ، ويمكن اعتبار هذه الخطوة كاملة:

لقد استخدمنا هذا المخطط عدة مرات في الإنتاج. ومع ذلك، ومن أجل راحتنا، قمنا بتنفيذه ضمن نظام متخصص يوزع تكوينات RMQ القياسية عبر مجموعات Kubernetes المتعددة (لأولئك الذين لديهم فضول: نحن نتحدث عن عامل إضافيحول الذي نحن قال للتو مؤخرا). سنقدم أدناه تعليمات فردية يمكن لأي شخص تطبيقها على عمليات التثبيت الخاصة به لتجربة الحل المقترح عمليًا.

دعنا نحاول في الممارسة

متطلبات

التفاصيل بسيطة للغاية:

مجموعة Kubernetes (سيفعل minikube)
مجموعة RabbitMQ (يمكن نشرها على المعدن، وصنعها مثل مجموعة عادية في Kubernetes من مخطط Helm الرسمي).

في المثال أدناه، قمت بنشر RMQ في Kubernetes وقمت بتسميته rmq-old.

إعداد الوقوف

1. قم بتنزيل مخطط Helm وقم بتحريره قليلاً:

helm fetch --untar stable/rabbitmq-ha

من أجل الراحة، قمنا بتعيين كلمة مرور، ErlangCookie وصنع السياسة ha-allبحيث تتم مزامنة قوائم الانتظار بشكل افتراضي بين جميع العقد في مجموعة RMQ:

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. تثبيت المخطط:

helm install . --name rmq-old --namespace rmq-old

3. انتقل إلى لوحة إدارة RabbitMQ، وأنشئ قائمة انتظار جديدة وأضف عدة رسائل. ستكون هناك حاجة إليها حتى نتمكن بعد الترحيل من التأكد من الحفاظ على جميع البيانات وعدم فقدان أي شيء:

منصة الاختبار جاهزة: لدينا RabbitMQ "القديم" مع البيانات التي يجب نقلها.

ترحيل مجموعة RabbitMQ

1. أولاً، لننشر RabbitMQ الجديد другом مساحة الاسم مع نفس ErlangCookie وكلمة المرور للمستخدم. للقيام بذلك، سنقوم بتنفيذ العمليات الموضحة أعلاه، مع تغيير الأمر النهائي لتثبيت RMQ إلى ما يلي:

helm install . --name rmq-new --namespace rmq-new

2. أنت الآن بحاجة إلى دمج المجموعة الجديدة مع المجموعة القديمة. للقيام بذلك، انتقل إلى كل من القرون جديد RabbitMQ وتنفيذ الأوامر:

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

ثابت OLD_RMQ تم العثور على عنوان إحدى العقد قديم مجموعة RMQ.

ستوقف هذه الأوامر العقدة الحالية جديد مجموعة RMQ، قم بإرفاقها بالمجموعة القديمة وتشغيلها مرة أخرى.

3. مجموعة RMQ المكونة من 6 عقد جاهزة:

يجب عليك الانتظار حتى تتم مزامنة الرسائل بين كافة العقد. ليس من الصعب تخمين أن وقت مزامنة الرسائل يعتمد على سعة الجهاز الذي تم نشر المجموعة عليه وعلى عدد الرسائل. في السيناريو الموصوف، هناك 10 منها فقط، لذلك تمت مزامنة البيانات على الفور، ولكن مع وجود عدد كبير بما فيه الكفاية من الرسائل، يمكن أن تستمر المزامنة لساعات.

لذلك، حالة المزامنة:

ومن +5 يعني أن الرسائل موجودة بالفعل أكثر على 5 عقد (باستثناء ما هو موضح في الحقل Node). وهكذا كانت المزامنة ناجحة.

4. كل ما تبقى هو تبديل عنوان RMQ في التطبيق إلى المجموعة الجديدة (تعتمد الإجراءات المحددة هنا على حزمة التكنولوجيا التي تستخدمها وتفاصيل التطبيق الأخرى)، وبعد ذلك يمكنك أن تقول وداعًا للمجموعة القديمة.

بالنسبة للعملية الأخيرة (أي بالفعل بعد تبديل التطبيق إلى مجموعة جديدة) انتقل إلى كل عقدة قديم الكتلة وتنفيذ الأوامر:

rabbitmqctl stop_app
rabbitmqctl reset

"نسيت" المجموعة العقد القديمة: يمكنك حذف RMQ القديم، وعند هذه النقطة سيتم إكمال النقل.

لاحظ: إذا كنت تستخدم RMQ مع الشهادات، فلن يتغير شيء بشكل أساسي - سيتم تنفيذ عملية النقل بنفس الطريقة تمامًا.

النتائج

يعد المخطط الموصوف مناسبًا لجميع الحالات تقريبًا عندما نحتاج إلى ترحيل RabbitMQ أو ببساطة الانتقال إلى مجموعة جديدة.

في حالتنا، ظهرت الصعوبات مرة واحدة فقط، عندما تم الوصول إلى RMQ من العديد من الأماكن، ولم تتح لنا الفرصة لتغيير عنوان RMQ إلى عنوان جديد في كل مكان. ثم أطلقنا RMQ جديد في نفس مساحة الاسم وبنفس التسميات بحيث تندرج تحت الخدمات والدخولات الموجودة، وعند إطلاق الكبسولة قمنا بالتلاعب بالتسميات يدويًا، وإزالتها في البداية حتى لا تقع الطلبات على إفراغ RMQ وإضافتها مرة أخرى بعد مزامنة الرسائل.

لقد استخدمنا نفس الإستراتيجية عند تحديث RabbitMQ إلى إصدار جديد بتكوين متغير - كل شيء يعمل كالساعة.

PS

كاستمرار منطقي لهذه المادة، نقوم بإعداد مقالات حول MongoDB (الانتقال من خادم الأجهزة إلى Kubernetes) وMySQL (كيف نقوم بإعداد نظام إدارة قواعد البيانات هذا داخل Kubernetes). وسيتم نشرها في الأشهر المقبلة.

ذكر المكتب الصحفى

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

سلس RabbitMQ للهجرة Kubernetes