تحدثنا بالفعل عن خرطوشة Tarantool ، التي تتيح لك تطوير التطبيقات الموزعة وتعبئتها . كل ما تبقى هو معرفة كيفية نشر هذه التطبيقات وإدارتها. لا تقلق ، لقد قدمنا ​​لكل شيء! جمعنا جميعًا أفضل الممارسات للعمل مع Tarantool Cartridge وكتبنا دورًا غير مرئي يحلل الحزمة إلى خوادم ، ويطلق المثيلات ، ويجمعها في كتلة ، ويؤلف الترخيص ، ويبدأ vshard ، ويمكّن من الفشل التلقائي ، ويصحح تكوين الكتلة.

المهتمة؟ ثم أطلب قطعًا ، وسنخبر ونظهر كل شيء.

لنبدأ بمثال.

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

يحتوي Tarantool Cartridge على برنامج تعليمي حول إنشاء تطبيق Cartridge صغير يخزن معلومات حول عملاء البنوك وحساباتهم ، ويوفر أيضًا واجهة برمجة تطبيقات لإدارة البيانات من خلال HTTP. للقيام بذلك ، يصف التطبيق اثنين من الأدوار الممكنة: api storage ، والتي يمكن تخصيصها لمثيلات.

لا توضح الخرطوشة نفسها شيئًا عن كيفية بدء العمليات ، فهي توفر فقط القدرة على تكوين المثيلات التي تعمل بالفعل. يجب على المستخدم القيام بالباقي: فك ملفات التهيئة وبدء الخدمات وتكوين الهيكل. لكننا لن نفعل كل هذا ، وسوف نفعل ذلك Ansible بالنسبة لنا.

يرجى ملاحظة أنه إذا كنت تقوم بتطوير التطبيق الخاص بك على OS X ، ثم تعبئته على جهاز محلي ثم تفشل في تثبيته على Centos أو Debian ستفشل ، لأن الحزمة سوف تحتوي على وحدات الصخور وملفات قابلة للتنفيذ خاصة بنظام OS X. في هذه الحالة ، سيكون عليك جعل التغليف على النظام المستهدف.

من الكلمات إلى الأفعال

لذلك ، دعنا نثبت تطبيقنا على جهازين ظاهريين ونضع طوبولوجيا بسيطة:

• سيقوم app-1 النسخة المتماثلة app-1 بتطبيق دور api ، والذي يتضمن دور vshard-router . سيكون هناك مثيل واحد فقط.
• تطبق storage-1 النسخ المتماثلة storage-1 دور storage (وفي نفس الوقت vshard-storage ) ، نضيف هنا حالتين من أجهزة مختلفة.

لتشغيل المثال ، نحتاج إلى Vagrant and Ansible (الإصدار 2.8 أو الأحدث).

الدور نفسه في Ansible Galaxy . هذا مستودع يسمح لك بمشاركة أفضل الممارسات الخاصة بك واستخدام الأدوار الجاهزة.

نقوم باستنساخ المستودع بمثال:

 $ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git $ cd deploy-tarantool-cartridge-app && git checkout 1.0.0 

رفع الأجهزة الافتراضية:

 $ vagrant up 

تثبيت دور ansible خرطوشة Tarantool:

 $ ansible-galaxy install tarantool.cartridge,1.0.1 

قم بتشغيل الدور المثبت:

 $ ansible-playbook -i hosts.yml playbook.yml 

نحن في انتظار استكمال قواعد اللعبة ، انتقل إلى http: // localhost: 8181 / admin / cluster / dashboard واستمتع بالنتيجة:

يمكنك صب البيانات. رائع ، أليس كذلك؟

الآن ، دعونا نتعرف على كيفية التعامل مع هذا ، وفي نفس الوقت نضيف مجموعة متماثلة أخرى إلى الهيكل.

البدء في فهم

إذن ماذا حدث؟

لقد التقطنا جهازين ظاهريين وأطلقنا كتاب اللعب غير المرئي الذي قام بتكوين مجموعتنا. دعونا نلقي نظرة على محتويات ملف playbook.yml :

 --- - name: Deploy my Tarantool Cartridge app hosts: all become: true become_user: root tasks: - name: Import Tarantool Cartridge role import_role: name: tarantool.cartridge 

لا شيء مثير للاهتمام يحدث هنا ، نطلق دورًا واضحًا يسمى tarantool.cartridge .

الأهم (بالتحديد ، تكوين الكتلة) هو في ملف مخزون hosts.yml :

 --- all: vars: # common cluster variables cartridge_app_name: getting-started-app cartridge_package_path: ./getting-started-app-1.0.0-0.rpm # path to package cartridge_cluster_cookie: app-default-cookie # cluster cookie # common ssh options ansible_ssh_private_key_file: ~/.vagrant.d/insecure_private_key ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' # INSTANCES hosts: storage-1: config: advertise_uri: '172.19.0.2:3301' http_port: 8181 app-1: config: advertise_uri: '172.19.0.3:3301' http_port: 8182 storage-1-replica: config: advertise_uri: '172.19.0.3:3302' http_port: 8183 children: # GROUP INSTANCES BY MACHINES host1: vars: # first machine connection options ansible_host: 172.19.0.2 ansible_user: vagrant hosts: # instances to be started on the first machine storage-1: host2: vars: # second machine connection options ansible_host: 172.19.0.3 ansible_user: vagrant hosts: # instances to be started on the second machine app-1: storage-1-replica: # GROUP INSTANCES BY REPLICA SETS replicaset_app_1: vars: # replica set configuration replicaset_alias: app-1 failover_priority: - app-1 # leader roles: - 'api' hosts: # replica set instances app-1: replicaset_storage_1: vars: # replica set configuration replicaset_alias: storage-1 weight: 3 failover_priority: - storage-1 # leader - storage-1-replica roles: - 'storage' hosts: # replica set instances storage-1: storage-1-replica: 

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

إدارة المثيلات

بالنسبة إلى Ansible ، كل مثيل هو مضيف (لا يجب الخلط بينه وبين خادم حديد) ، أي عقدة بنية أساسية ستقوم Ansible بإدارتها. لكل مضيف ، يمكننا تحديد معلمات الاتصال (مثل ansible_host و ansible_user ) ، بالإضافة إلى تكوين المثيل. وصف الحالات في قسم hosts .

النظر في تكوين مثيل storage-1 :

 all: vars: ... # INSTANCES hosts: storage-1: config: advertise_uri: '172.19.0.2:3301' http_port: 8181 ... 

في متغير config ، حددنا معلمات المثيل - advertise URI HTTP port advertise URI و HTTP port .
فيما يلي معلمات مثيل app-1 storage-1-replica .

نحن بحاجة إلى توفير معلمات اتصال Ansible لكل مثيل. يبدو منطقياً تجميع المثيلات في مجموعات الجهاز الظاهري. للقيام بذلك ، يتم تجميع host1 في host2 و host2 ، وفي كل مجموعة في قسم ansible_host ، تتم الإشارة إلى القيم ansible_host و ansible_user لجهاز vars واحد. وفي قسم hosts توجد مضيفات (وهي حالات) مدرجة في هذه المجموعة:

 all: vars: ... hosts: ... children: # GROUP INSTANCES BY MACHINES host1: vars: # first machine connection options ansible_host: 172.19.0.2 ansible_user: vagrant hosts: # instances to be started on the first machine storage-1: host2: vars: # second machine connection options ansible_host: 172.19.0.3 ansible_user: vagrant hosts: # instances to be started on the second machine app-1: storage-1-replica: 

نبدأ في تغيير hosts.yml . أضف حالتين أخريين ، storage-2-replica على أول جهاز ظاهري storage-2 في الثاني:

 all: vars: ... # INSTANCES hosts: ... storage-2: # <== config: advertise_uri: '172.19.0.3:3303' http_port: 8184 storage-2-replica: # <== config: advertise_uri: '172.19.0.2:3302' http_port: 8185 children: # GROUP INSTANCES BY MACHINES host1: vars: ... hosts: # instances to be started on the first machine storage-1: storage-2-replica: # <== host2: vars: ... hosts: # instances to be started on the second machine app-1: storage-1-replica: storage-2: # <== ... 

قم بتشغيل كتاب اللعب غير المرئي:

 $ ansible-playbook -i hosts.yml \ --limit storage-2,storage-2-replica \ playbook.yml 

إيلاء الاهتمام لخيار - --limit . نظرًا لأن كل مثيل من الكتلة هو مضيف من حيث Ansible ، يمكننا الإشارة صراحة إلى الحالات التي يجب تكوينها عند تشغيل playbook.

مرة أخرى ، انتقل إلى الويب UI http: // localhost: 8181 / admin / cluster / dashboard ولاحظ حالاتنا الجديدة:

لن نتطرق إلى ما تم إنجازه ونتقن إدارة الطوبولوجيا.

إدارة الطوبولوجيا

ادمج مثيلاتنا الجديدة في storage-2 نسخ متماثلة storage-2 . أضف مجموعة جديدة replicaset_storage_2 ووصف معلمات مجموعة replicaset_storage_2 المتماثلة في متغيراتها ، على غرار replicaset_storage_1 . في قسم hosts ، نشير إلى الحالات التي سيتم تضمينها في هذه المجموعة (أي ، مجموعة النسخ المتماثلة الخاصة بنا):

 --- all: vars: ... hosts: ... children: ... # GROUP INSTANCES BY REPLICA SETS ... replicaset_storage_2: # <== vars: # replicaset configuration replicaset_alias: storage-2 weight: 2 failover_priority: - storage-2 - storage-2-replica roles: - 'storage' hosts: # replicaset instances storage-2: storage-2-replica: 

ابدأ في playbook مرة أخرى:

 $ ansible-playbook -i hosts.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets \ playbook.yml 

هذه المرة ، مررنا اسم المجموعة التي تتوافق مع مجموعة النسخ المتماثل الخاصة بنا إلى المعلمة - حد أقصى.

النظر في خيار tags .

يؤدي دورنا باستمرار العديد من المهام ، والتي تتميز بالعلامات التالية:

• cartridge-instances : إدارة المثيلات (الإعداد ، الاتصال بالعضوية) ؛
• cartridge-replicasets : إدارة الطوبولوجيا (إدارة النسخ المتماثلة وحذف مثيلات (الطرد) نهائيًا من الكتلة) ؛
• cartridge-config : إدارة المعلمات الكتلة المتبقية (vshard bootstrapping ، وضع الفشل التلقائي ، معلمات التخويل وتكوين التطبيق).

يمكننا الإشارة بوضوح إلى أي جزء من العمل الذي نريد القيام به ، ثم سيتخطى الدور تنفيذ المهام المتبقية. في حالتنا ، نريد العمل فقط مع الهيكل ، لذلك أشرنا إلى cartridge-replicasets .

دعونا تقييم نتيجة جهودنا. ابحث عن مجموعة النسخ المتماثلة الجديدة على الموقع http: // localhost: 8181 / admin / cluster / dashboard .

الصيحة!

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

لا تنسى أن تبدأ vagrant halt عند الانتهاء من العمل معهم.

وماذا تحت الغطاء؟

هنا سوف أخبركم أكثر حول ما حدث تحت غطاء الدور غير المرئي خلال تجاربنا.

النظر في خطوات نشر تطبيق خرطوشة.

تثبيت حزمة وبدء مثيلات

تحتاج أولاً إلى تسليم الحزمة إلى الخادم وتثبيتها. الآن الدور قادر على العمل مع حزم RPM و DEB.

بعد ذلك ، قم بتشغيل المثيلات. كل شيء بسيط للغاية هنا: كل مثيل هو خدمة systemd منفصلة. أنا أقول مع مثال:

 $ systemctl start myapp@storage-1 

سيُطلق هذا الأمر مثيل storage-1 من myapp . سيبحث المثيل الجاري تشغيله في /etc/tarantool/conf.d/ . يمكن الاطلاع على journald باستخدام journald .

سيتم تسليم ملف الوحدة /etc/systemd/system/myapp@.sevice لخدمة systemd مع الحزمة.

يحتوي Ansible على وحدات مدمجة لتثبيت الحزم وإدارة خدمات systemd ، وهنا لم نخترع أي شيء جديد.

تكوين طبولوجيا الكتلة

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

يمكنك تكوين الكتلة يدويًا:

• الخيار الأول: افتح Web UI وانقر على الأزرار. لبداية عدة مرات لمرة واحدة ، إنها مناسبة تمامًا.
• الخيار الثاني: يمكنك استخدام واجهة برمجة تطبيقات GraphQl. هنا يمكنك بالفعل أتمتة شيء ما ، على سبيل المثال ، كتابة نص في Python.
• الخيار الثالث (بالنسبة لأولئك الذين يتمتعون بالقوة في الروح): نذهب إلى الخادم ، tarantoolctl connect الحالات التي تستخدم tarantoolctl connect وتنفيذ جميع المعالجات اللازمة مع وحدة cartridge Lua.

الهدف الرئيسي من اختراعنا هو القيام بذلك بالضبط ، وهو الجزء الأكثر صعوبة في العمل بالنسبة لك.

يسمح لك Ansible بكتابة وحدتك واستخدامها في دور ما. يستخدم دورنا مثل هذه الوحدات النمطية لإدارة مكونات الكتلة المختلفة.

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

النتائج

تحدثنا اليوم وأظهرنا كيفية نشر التطبيق الخاص بك على Tarantool Cartridge وإعداد طبولوجيا بسيطة. للقيام بذلك ، استخدمنا Ansible ، وهي أداة قوية سهلة الاستخدام وتتيح لك تكوين العديد من عقد البنية التحتية في وقت واحد (في حالتنا ، هذه هي حالات نظام المجموعة).

أعلاه ، اكتشفنا إحدى الطرق العديدة لوصف تكوين الكتلة باستخدام Ansible. بمجرد أن تدرك أنك على استعداد للمضي قدمًا ، تعرف على أفضل الممارسات لكتابة كتب اللعب. قد تجد أنه أكثر ملاءمة لإدارة الطوبولوجيا باستخدام group_vars و host_vars .

في الجزء التالي ، سوف نتعلم كيفية إزالة المثيلات (الطرد) نهائيًا من الهيكل ، و bootstrap vshard ، وإدارة وضع الفشل التلقائي ، وتكوين التخويل وتصحيح تكوين الكتلة. لا تتوقف عند هذا الحد ، واصل دراسة الوثائق وتجربة تغيير معلمات الكتلة.

إذا لم ينجح شيء ما ، فتأكد من إعلامنا بالمشكلة. سوف ندمر بسرعة كل شيء!