في الآونة الأخيرة ، تحدثنا عن كيفية نشر التطبيقات المكتوبة في خرطوشة Tarantool . لكن العملية لا تنتهي عند النشر ، لذلك سنقوم اليوم بتحديث تطبيقنا وفهم كيفية إدارة الطوبولوجيا والمشاركة والترخيص ، وكذلك تغيير تكوين الأدوار.
فضولي يرجى قطع!
أين توقفنا؟
آخر مرة قمنا بتكوين الطوبولوجيا التالية:
تمكن مستودع المثال من تغيير بعض الملفات الجديدة التي ظهرت هناك ، و getting-started-app-2.0.0-0.rpm و hosts.updated.2.yml . ليس عليك سحب الإصدار الجديد ، يمكنك فقط تنزيل الحزمة من الرابط ، hosts.updated.2.yml حاجة إلى hosts.updated.2.yml فقط حتى تتمكن من hosts.updated.2.yml نظرة خاطفة عليها في حالة وجود صعوبات في تغيير المخزون الحالي.
إذا كنت قد أكملت جميع خطوات الجزء السابق من هذا البرنامج التعليمي ، فحينئذٍ في hosts.yml hosts.yml لديك تكوين كتلة به نسختان متماثلتان storage (في المستودع ، هذا هو hosts.updated.yml ).
رفع أجهزتنا الافتراضية:
$ vagrant up
قم بتثبيت الإصدار الجديد من خرطوشة Tarantool ذات Ansible-role (تمكنت من تغييرها ، للأفضل):
$ ansible-galaxy install tarantool.cartridge,1.0.2
لذلك ، تكوين الكتلة الحالي:
--- 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 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: # first machine connection options ansible_host: 172.19.0.2 ansible_user: vagrant hosts: # instances to be started on the first machine storage-1: storage-2-replica: 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: storage-2: # 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: 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:
انتقل إلى http: // localhost: 8181 / admin / cluster / dashboard وتأكد من أن نظامك في الحالة الصحيحة.
كل شيء مماثل لآخر مرة: سنقوم بتغيير هذا الملف تدريجيًا ولاحظ كيف تتغير الكتلة. يمكنك دائمًا إلقاء نظرة على الإصدار النهائي في hosts.updated.2.yml
لذلك نحن هنا نذهب!
تحديث التطبيق
لتبدأ ، دعونا تحديث التطبيق لدينا. تأكد getting-started-app-2.0.0-0.rpm ملف getting-started-app-2.0.0-0.rpm في الدليل الحالي (إن لم يكن ، getting-started-app-2.0.0-0.rpm بتنزيله من المستودع).
حدد المسار إلى الإصدار الجديد من الحزمة:
--- all: vars: cartridge_app_name: getting-started-app cartridge_package_path: ./getting-started-app-2.0.0-0.rpm # <== cartridge_enable_tarantool_repo: false # <==
لقد حددنا cartridge_enable_tarantool_repo: false بحيث لا يربط الدور مستودع التخزين بحزمة Tarantool ، التي قمنا بتثبيتها بالفعل في المرة الأخيرة. سيؤدي ذلك إلى تسريع عملية النشر قليلاً ، لكنه ليس ضروريًا على الإطلاق.
قم بتشغيل playbook باستخدام علامة cartridge-instances :
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-instances
ونحن نتحقق من أن الحزمة قد تم تحديثها:
$ vagrant ssh vm1 [vagrant@svm1 ~]$ sudo yum list installed | grep getting-started-app
تأكد من أن الإصدار أصبح 2.0.0 :
getting-started-app.x86_64 2.0.0-0 installed
يمكنك الآن تجربة الإصدار الجديد من التطبيق بأمان.
بدوره على sharding
فلنقم بتشغيل المشاركة حتى نتمكن من التحكم في النسخ المتماثلة storage لاحقًا. يتم ذلك ببساطة شديدة. أضف المتغير cartridge_bootstrap_vshard قسم all.vars :
--- all: vars: ... cartridge_cluster_cookie: app-default-cookie # cluster cookie cartridge_bootstrap_vshard: true # <== ... hosts: ... children: ...
نطلق:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
يرجى ملاحظة أننا حددنا علامة cartridge-config لتشغيل المهام فقط التي تشارك في تكوين الكتلة.
افتح Web UI http: // localhost: 8181 / admin / cluster / dashboard ونرى أن مجموعاتنا موزعة على مجموعات النسخ المتماثلة للتخزين بنسبة 2:3 (حددنا هذه الأوزان لمجموعات النسخ المتماثلة الخاصة بنا ، تذكر؟):
قم بتشغيل الفشل التلقائي
والآن سنقوم بتشغيل وضع الفشل التلقائي حتى نتمكن من معرفة ما هو عليه وكيف يعمل قليلاً في وقت لاحق.
أضف علامة cartridge_failover إلى التكوين:
--- all: vars: ... cartridge_cluster_cookie: app-default-cookie # cluster cookie cartridge_bootstrap_vshard: true cartridge_failover: true # <== ... hosts: ... children: ...
نبدأ مرة أخرى مهام إدارة الكتلة:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
بعد الانتهاء بنجاح من playbook ، يمكنك الانتقال إلى Web UI والتأكد من تبديل مفتاح Failover في الزاوية اليمنى العليا. لإيقاف تشغيل وضع الفشل التلقائي ، ما عليك سوى تغيير قيمة cartridge_failover إلى false وتشغيل Playbook مرة أخرى.
لقد حان الوقت لمعرفة نوع النظام هذا ولماذا قمنا بتشغيله.
نحن نتعامل مع الفشل
ربما لاحظت متغير failover_priority الذي حددناه لكل مجموعة نسخ متماثلة. دعونا نرى ما هو عليه.
توفر خرطوشة Tarantool وضع تجاوز الفشل التلقائي. كل نسخة متماثلة لها قائد - المثيل الذي يتم تسجيله به. إذا حدث شيء للزعيم ، فستتولى إحدى الملاحظات دوره. أي واحد؟ دعونا نلقي نظرة فاحصة على مجموعة النسخ المتماثلة storage-2 :
--- all: ... children: ... replicaset_storage_2: vars: ... failover_priority: - storage-2 - storage-2-replica
مثيل storage-2 الذي حددناه أولاً في failover_priority . في Web UI ، يظهر أولاً في قائمة مثيلات النسخ المتماثلة ويتميز بتاج أخضر. هذا هو القائد - المثيل الأول المحدد في failover_priority :
الآن دعونا نرى ما يحدث إذا حدث شيء لقائد مجموعة النسخ المتماثلة. نذهب إلى الجهاز الظاهري وإيقاف مثيل storage-2 :
$ vagrant ssh vm2 [vagrant@vm2 ~]$ sudo systemctl stop getting-started-app@storage-2
العودة إلى الويب UI:
تحول التاج في مثيل storage-2 إلى اللون الأحمر - وهذا يعني أن الزعيم المعين غير صحي. لكن storage-2-replica له storage-2-replica تاج أخضر - تولى هذا المثال مسؤوليات القيادة حتى يعود storage-2 إلى الخدمة. هذا هو الفشل التلقائي في العمل.
لنقم بإحياء storage-2 :
$ vagrant ssh vm2 [vagrant@vm2 ~]$ sudo systemctl start getting-started-app@storage-2
عاد كل شيء إلى المربع الأول:
دعنا نغير ترتيب الحالات في أولوية الفشل. سنجعل مثيل storage-2-replica قائدًا ، ونزيل storage-2 من القائمة بشكل عام:
--- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration ... failover_priority: - storage-2-replica # <== ...
قم بتشغيل cartridge-replicasets لمثيلات من مجموعة replicaset_storage_2 :
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
نذهب إلى http: // localhost: 8181 / admin / cluster / dashboard ونرى أن الزعيم قد تغير:
لكننا أزلنا مثيل storage-2 من التكوين ، لماذا لا يزال هنا؟ والحقيقة هي أن Cartridge ، التي تتلقى قيمة جديدة من failover_priority تنظم الحالات على النحو التالي: تصبح الحالة الأولى من القائمة هي الرائدة ، فيما يلي بقية الحالات المشار إليها. سيتم طلب المثيلات غير المذكورة في failover_priority بواسطة UUID وإلحاقها حتى النهاية.
حالة المنفى
ولكن ماذا لو أردنا استبعاد المثيل من الهيكل؟ كل شيء بسيط للغاية: تحتاج إلى تمرير العلم expelled . دعنا نستبعد مثيل storage-2-replica . إنه القائد الآن ، لذلك لن تسمح لنا Cartridge بالقيام بذلك. لكننا لسنا خائفين من الصعوبات ، وما زلنا نحاول:
--- all: vars: ... hosts: storage-2-replica: config: advertise_uri: '172.19.0.2:3302' http_port: 8185 expelled: true # <== ...
نحدد cartridge-replicasets ، حيث أن طرد مثيل يعد تغييرًا في الهيكل:
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
قم بتشغيل playbook وشاهد الخطأ:
كما رأينا للتو ، لا تبرر Cartridge إخراج زعيم النسخ المتماثل الحالي من الهيكل. هذا منطقي تمامًا ، نظرًا لأن النسخ المتماثل غير متزامن ، فمن المحتمل أن يؤدي استبعاد قائد إلى فقدان البيانات. نحتاج إلى تحديد قائد آخر وفقط بعد استبعاد المثيل. سيقوم الدور أولاً بتطبيق تكوين مجموعات النسخ المتماثل الجديد ثم التعامل مع الاستثناء. لذلك ، نغير failover_priority ونشغل كتاب اللعب مرة أخرى:
--- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration ... failover_priority: - storage-2 # <== ...
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
فويلا ، اختفى مثيل storage-2-replica من الطبولوجيا!
لاحظ أن نفي المثيل نهائي نهائي ولا رجعة فيه. بعد إزالة المثيل من الهيكل ، سيؤدي دورنا الظاهر إلى إيقاف خدمة systemd وحذف جميع ملفات هذه النسخة.
إذا غيرت رأيك فجأة وقررت أن مجموعة النسخ المتماثلة storage-2 لا تزال بحاجة إلى مثيل آخر ، فلن تتمكن من استعادته. تتذكر الخرطوشة UUID بجميع الحالات التي تركت الهيكل ولن تسمح للنفي بالعودة. يمكنك رفع مثيل جديد بنفس الاسم والتكوين ، ولكن من الواضح أنه سيكون له UUID مختلف ، لذلك ستسمح لك Cartridge بالانضمام.
إزالة النسخ المتماثلة
لقد اكتشفنا بالفعل أنه لن يُسمح لنا بطرد قائد مجموعة النسخ المتماثلة. ولكن ماذا لو أردنا إزالة النسخة المتماثلة storage-2 بشكل دائم؟ هناك ، بالطبع ، مخرج.
لكي لا نفقد البيانات ، يجب علينا أولاً نقل جميع المجموعات إلى storage-1 ، ولهذا قمنا بتعيين وزن النسخة المتماثلة storage-2 على 0 :
--- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration replicaset_alias: storage-2 weight: 0 # <== ... ...
إطلاق إدارة الطوبولوجيا:
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
افتح Web UI http: // localhost: 8181 / admin / cluster / dashboard وشاهد كيف تتدفق جميع المجموعات في storage-1 :
لقد قمنا بتعيين زعيم storage-2 للعلم المُطرد ونقول وداعًا لهذه النسخ المتماثلة:
--- all: vars: ... hosts: ... storage-2: config: advertise_uri: '172.19.0.3:3303' http_port: 8184 expelled: true # <== ...
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-replicasets
يرجى ملاحظة أنه في هذه المرة لم نقم بتحديد خيار limit ، لأنه يجب ألا يتم وضع علامة على الأقل على مثيل واحد على الأقل من كل شيء أطلقنا منه كتاب اللعب.
لذلك عدنا إلى الهيكل الأصلي:
ترخيص
أقترح صرف الانتباه عن إدارة مجموعات النسخ المتماثلة والتفكير في الأمان. الآن يمكن لأي مستخدم غير مصرح له إدارة الكتلة من خلال Web UI. موافق ، يبدو الأمر كذلك.
توفر Cartridge القدرة على توصيل وحدة الترخيص الخاصة بك ، مثل LDAP (أو أي شيء لديك) ، واستخدامها لإدارة المستخدمين ووصولهم إلى التطبيق. لكننا سنستخدم وحدة التخويل المدمجة ، والتي تستخدمها Cartridge افتراضيًا. تسمح لك هذه الوحدة بإجراء عمليات أساسية مع المستخدمين (حذف ، إضافة ، تحرير) وتنفيذ وظيفة التحقق من كلمة المرور.
يرجى ملاحظة أن دورنا ansible يتطلب الخلفية إذن لتنفيذ جميع هذه الوظائف.
لذلك ، نحن ننتقل من النظرية إلى الممارسة. أولاً ، جعل التفويض إلزاميًا ، واضبط معلمات الجلسة وأضف مستخدمًا جديدًا:
--- all: vars: ... # authorization cartridge_auth: # <== enabled: true # enable authorization cookie_max_age: 1000 cookie_renew_age: 100 users: # cartridge users to set up - username: dokshina password: cartridge-rullez fullname: Elizaveta Dokshina email: dokshina@example.com # deleted: true # uncomment to delete user ...
يتم تنفيذ إدارة التفويض كجزء من مهام cartridge-config إلى هذه العلامة:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
على http: // localhost: 8181 / admin / cluster / dashboard تنتظرنا مفاجأة:
يمكنك تسجيل الدخول باستخدام username password للمستخدم الجديد أو تسجيل الدخول كمسؤول - المستخدم الافتراضي. كلمة مروره هي ملف تعريف الارتباط العنقودي ، لقد حددنا هذه القيمة في cartridge_cluster_cookie المتغير (هذا هو app-default-cookie ، لا يمكنك إلقاء نظرة خاطفة عليه).
بعد تسجيل دخول ناجح ، افتح علامة التبويب Users للتأكد من أن كل شيء سار على ما يرام:
تجربة إضافة مستخدمين جدد وتغيير إعداداتهم. لحذف مستخدم ، حدد العلامة deleted: true لا تستخدم Cartridge قيم email وقيم الاسم fullname بأي طريقة ، ولكن يمكنك تحديدها للراحة.
تكوين التطبيق
دعونا نتذكر كيف بدأ كل شيء.
لقد قمنا بنشر تطبيق صغير يخزّن بيانات العملاء وحساباتهم المصرفية. كما تتذكر ، هذا التطبيق له أدوار 2: api storage . يعالج دور storage البيانات وينفذ عملية المشاركة باستخدام دور التخزين المدمج في vshard-storage . الدور الثاني ، api ، ينفذ خادم HTTP مع واجهة برمجة تطبيقات لإدارة البيانات ، بالإضافة إلى داخله متصل vshard-router قياسية أخرى ، vshard-router ، والتي تتحكم في المشاركة.
لذلك ، نحن نقدم الطلب الأول إلى API التطبيق. إضافة عميل جديد:
$ curl -X POST -H "Content-Type: application/json" \ -d '{"customer_id":1, "name":"Elizaveta", "accounts":[{"account_id": 1}]}' \ http://localhost:8182/storage/customers/create
استجابة لذلك ، حصلنا على شيء مثل هذا:
{"info":"Successfully created"}
يرجى ملاحظة أنه في عنوان URL ، حددنا app-1 port مثيل app-1 ، 8082 ، لأنه ينفذ واجهة برمجة التطبيقات هذه.
الآن دعونا نقوم بتحديث رصيد مستخدمنا الجديد:
$ curl -X POST -H "Content-Type: application/json" \ -d "{\"account_id\": 1, \"amount\": \"1000\"}" \ http://localhost:8182/storage/customers/1/update_balance
في الرد نرى الرصيد المحدث:
{"balance":"1000.00"}
عظيم ، كل شيء يعمل! يتم تنفيذ واجهة برمجة التطبيقات ، وتشارك Cartridge في مشاركة البيانات ، وقد أنشأنا بالفعل أولوية تجاوز الفشل لحالات الطوارئ وحتى تمكين التفويض. لقد حان الوقت للقيام بتكوين التطبيق.
يتم تخزين تكوين الكتلة الحالي في ملف التكوين الموزع. يحتفظ كل مثيل بنسخة من هذا الملف ، وتضمن الخرطوشة التزامن بين جميع عقد المجموعة. يمكننا تحديد تكوين أدوار تطبيقنا في هذا الملف ، وسوف تتولى Cartridge توزيع التكوين الجديد في جميع الحالات.
لنلقِ نظرة على المحتويات الحالية لهذا الملف. انتقل إلى علامة التبويب " Cofiguration files وانقر فوق الزر " Download :
في config.yml config.yml الذي تم تنزيله config.yml نجد جدولًا فارغًا. لا عجب ، لأننا لم نحدد أي معلمات حتى الآن:
--- [] ...
في الواقع ، ملف التكوين الخاص بمجموعتنا ليس فارغًا ، فهو يخزن الهيكل الحالي وإعدادات التفويض وإعدادات المشاركة. لكن لن تكون مشاركة هذه المعلومات في Cartridge سهلة ، فهي مخصصة للاستخدام الداخلي ، وبالتالي يتم تخزينها في أقسام النظام المخفية ، والتي لا يمكننا تحريرها.
يمكن لكل دور تطبيق استخدام قسم أو أكثر من أقسام التكوين. يحدث تنزيل تكوين جديد على مرحلتين: أولاً ، تحقق كل الأدوار من استعدادها لقبول معلمات جديدة. إذا لم يكن هناك اعتراض ، فسيتم تطبيق التغييرات ، وإذا كان هناك شخص ما يعارضها ، فسوف يحدث التراجع.
دعنا نعود إلى طلبنا. يستخدم دور api قسم max-balance ، حيث يتم تخزين الحد الأقصى للرصيد المسموح به على حساب عميل واحد. دعنا نهيئ هذا القسم ، لكن ، بالطبع ، ليس يدويًا ، ولكن باستخدام دورنا Ansible.
لذا ، فإن تكوين التطبيق (أو بالأحرى ، جزء منه متاح لنا) هو جدول فارغ. إضافة قسم max-balance بقيمة 100000 . نكتب المتغير cartridge_app_config في ملف مخزوننا:
--- all: vars: ... # cluster-wide config cartridge_app_config: # <== max-balance: # section name body: 1000000 # section body # deleted: true # uncomment to delete section max-balance ...
حددنا اسم القسم ، max-balance ، ومحتوياته ، body . لا يمكن أن تكون محتويات القسم مجرد رقم ، بل يمكن أن تكون أيضًا جدولًا أو صفًا بناءً على كيفية كتابة الدور ونوع القيمة التي تريد استخدامها.
نطلق:
$ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config
ونحن نتحقق من أن الحد الأقصى للرصيد المسموح به قد تغير بالفعل:
$ curl -X POST -H "Content-Type: application/json" \ -d "{\"account_id\": 1, \"amount\": \"1000001\"}" \ http://localhost:8182/storage/customers/1/update_balance
ردا على ذلك ، حصلنا على خطأ ، كما أردنا:
{"info":"Error","error":"Maximum is 1000000"}
يمكنك إعادة تنزيل ملف التكوين في علامة التبويب Configuraion files للتأكد من ظهور قسم جديد هناك:
--- max-balance: 1000000 ...
حاول إضافة أقسام جديدة إلى تكوين التطبيق أو تغيير محتوياتها أو حذفها تمامًا (لهذا تحتاج إلى تعيين العلامة deleted: true علامة deleted: true في القسم).
يمكنك معرفة كيفية استخدام التكوين الموزع في الأدوار في وثائق خرطوشة Tarantool.
تذكر أن تتصل vagrant halt لإيقاف vagrant halt عند الانتهاء من العمل معها.
في الختام
آخر مرة ، تعلمنا كيفية نشر تطبيقات خرطوشة Tarantool الموزعة باستخدام دور Ansible خاص. اليوم قمنا بتحديث التطبيق ، وكذلك أتقن إدارة الطوبولوجيا والمشاركة والتصريح والتكوين للتطبيق.
لا تتوقف عند هذا الحد ، وتعلم طرقًا مختلفة لكتابة كتب Ansible ، واستخدم تطبيقاتك بأقصى درجات الراحة.
إذا لم ينجح شيء من أجلك أو إذا كان لديك أفكار حول كيفية تحسين دورنا الظاهر ، فلا تتردد في بدء تذكرة . سنساعد دائمًا في حل مشكلتك وسنكون سعداء بعروض مثيرة للاهتمام!