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

مثير للاهتمام؟ ثم أسأل تحت الخفض ، سنخبر ونعرض كل شيء.

لنبدأ بمثال

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

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

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

من الأقوال إلى الأفعال

لذلك ، دعنا ننشر تطبيقنا على جهازين افتراضيين وننشئ هيكلًا بسيطًا:

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

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

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

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

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

نرفع الآلات الافتراضية:

$ vagrant up

قم بتثبيت دور Tarantool Cartridge المريح:

$ 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، الموجود في نموذج المستودع.

إدارة المثيل

من حيث 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.
فيما يلي معلمات المثيل app-1 и storage-1-replica.

نحتاج إلى إخبار Ansible بمعلمات الاتصال لكل حالة. يبدو من المنطقي تجميع المثيلات في مجموعات أجهزة افتراضية. للقيام بذلك ، يتم دمج الحالات في مجموعات. host1 и host2وفي كل مجموعة في القسم vars قيم ansible_host и ansible_user لجهاز افتراضي واحد. وفي القسم 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.

العودة إلى Web UI http://localhost:8181/admin/cluster/dashboard ولاحظ حالاتنا الجديدة:

لن نكتفي بما حققناه وسنتقن التحكم في الطوبولوجيا.

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

دعنا ندمج مثيلاتنا الجديدة في نسخة طبق الأصل 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:

لنبدأ كتاب التشغيل مرة أخرى:

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

في المعلمة --limit لقد مررنا هذه المرة اسم المجموعة الذي يتوافق مع مجموعتنا المتماثلة.

ضع في اعتبارك الخيار tags.

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

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

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

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

الصيحة!

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

لا تنسى الركض vagrant haltلإيقاف الأجهزة الافتراضية عند الانتهاء منها.

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

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

دعنا نلقي نظرة على نشر تطبيق Cartridge خطوة بخطوة.

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

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

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

$ systemctl start myapp@storage-1

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

ملف الوحدة /etc/systemd/system/[email protected] لخدمة systemd سيتم تسليمها مع الحزمة.

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

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

وهنا يبدأ الشيء الأكثر إثارة للاهتمام. موافق ، سيكون من الغريب الاهتمام بدور خاص غير صالح لتثبيت الحزم والتشغيل systemd-خدمات.

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

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

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

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

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

نتائج

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

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

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

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

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