हाल ही में, हमने टारनटूल कार्ट्रिज में लिखे गए एप्लिकेशन को कैसे तैनात किया जाए, इस बारे में बात की । लेकिन ऑपरेशन तैनाती पर समाप्त नहीं होता है, इसलिए आज हम अपने एप्लिकेशन को अपडेट करेंगे और समझेंगे कि टोपोलॉजी, शार्किंग और प्राधिकरण का प्रबंधन कैसे करें, साथ ही साथ भूमिकाओं के कॉन्फ़िगरेशन को भी बदलें।
जिज्ञासु कृपया कट!
हम कहां रुक गए
पिछली बार हमने निम्नलिखित टोपोलॉजी को कॉन्फ़िगर किया था:
उदाहरण रिपॉजिटरी थोड़ा बदलने में कामयाब getting-started-app-2.0.0-0.rpm , नई फाइलें वहां दिखाई दीं, getting-started-app-2.0.0-0.rpm hosts.updated.2.yml . getting-started-app-2.0.0-0.rpm और hosts.updated.2.yml । आपको नए संस्करण को खींचने की ज़रूरत नहीं है, आप बस लिंक को पैकेज से डाउनलोड कर सकते हैं, और hosts.updated.2.yml की केवल आवश्यकता है ताकि आप वर्तमान इन्वेंट्री को बदलने के साथ कठिनाइयों के मामले में वहां झांक सकें।
यदि आपने इस ट्यूटोरियल के पिछले भाग के सभी चरणों को पूरा कर लिया है, तो अब आपकी hosts.yml hosts.yml दो storage प्रतिकृतियों के साथ एक क्लस्टर कॉन्फ़िगरेशन है (रिपॉजिटरी में यह hosts.updated.yml )।
हमारी वर्चुअल मशीन उठाएँ:
$ vagrant up
अन्सिबल-रोल टारेंटूल कार्ट्रिज के नए संस्करण को स्थापित करें (यह बेहतर तरीके से, निश्चित रूप से बदलने में कामयाब रहा):
$ 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 / व्यवस्थापक / क्लस्टर / डैशबोर्ड पर जाएं और सुनिश्चित करें कि आपका क्लस्टर सही स्थिति में है।
पिछली बार की तरह ही सब कुछ है: हम धीरे-धीरे इस फाइल को बदलेंगे और देखेंगे कि क्लस्टर कैसे बदलता है। आप hosts.updated.2.yml में हमेशा अंतिम संस्करण देख सकते हैं
तो यहाँ हम चले!
एप्लिकेशन को अपडेट कर रहा है
आरंभ करने के लिए, आइए अपने एप्लिकेशन को अपडेट करें। सुनिश्चित करें कि आपके पास वर्तमान निर्देशिका में 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 # <==
हमने कारतूस_enable_tarantool_repo निर्दिष्ट किया cartridge_enable_tarantool_repo: false इसलिए कि भूमिका टारस्टूल पैकेज के साथ रिपॉजिटरी को नहीं जोड़ती है, जिसे हमने पहले ही अंतिम बार स्थापित किया था। यह तैनाती की प्रक्रिया को थोड़ा गति देगा, लेकिन यह बिल्कुल आवश्यक नहीं है।
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
अब आप एप्लिकेशन के नए संस्करण के साथ सुरक्षित रूप से प्रयोग कर सकते हैं।
शार्किंग चालू करें
आइए शार्डिंग चालू करें ताकि हम बाद में storage प्रतिकृतियों का नियंत्रण ले सकें। यह बहुत सरलता से किया जाता है। चर all.vars 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 कॉन्फिगर टैग को केवल उन्हीं कार्यों को चलाने के लिए निर्दिष्ट किया है जो क्लस्टर कॉन्फ़िगरेशन में शामिल हैं।
वेब UI http खोलें : // localhost: 8181 / admin / क्लस्टर / डैशबोर्ड और देखें कि हमारी बाल्टियाँ 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
प्लेबुक को सफलतापूर्वक पूरा करने के बाद, आप वेब UI पर जा सकते हैं और सुनिश्चित कर सकते हैं कि ऊपरी दाएं कोने में Failover स्विच बंद है। स्वचालित फ़ेलओवर मोड को बंद करने के लिए, केवल cart_failover के मान को false बदलें और प्लेबुक को फिर से चलाएँ।
यह पता लगाने का समय है कि यह किस तरह का शासन है और हमने इसे क्यों चालू किया।
हम असफलता से निपटते हैं
आपने संभवतः प्रत्येक पुनर्प्राप्ति के लिए निर्दिष्ट failover_priority चर को देखा था। आइए देखें कि यह क्या है।
टारेंटूल कार्ट्रिज एक स्वचालित विफलता मोड प्रदान करता है। प्रत्येक प्रतिकृतियों में एक नेता होता है - जिस पर यह दर्ज किया जा रहा है। अगर नेता को कुछ होता है, तो टिप्पणी में से एक उसकी भूमिका पर ले जाएगा। कौन सा? चलो storage-2 प्रतिकृति सेट पर करीब से नज़र डालें:
--- all: ... children: ... replicaset_storage_2: vars: ... failover_priority: - storage-2 - storage-2-replica
storage-2 उदाहरण हमने फेलओवर_पायरिटी में पहले दिया था। वेब UI में, यह प्रतिकृतियों के उदाहरणों की सूची में सबसे पहले दिखाई देता है और हरे रंग के मुकुट के साथ चिह्नित होता है। यह नेता है - failover_priority में निर्दिष्ट पहला 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 की सेवा में वापस आने तक नेतृत्व की जिम्मेदारियों को संभाल लिया। यह कार्रवाई में एक स्वचालित विफलता है।
आइए 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 समूह से उदाहरणों के लिए cartridge-replicasets चलाएं:
$ ansible-playbook -i hosts.yml playbook.yml \ --limit replicaset_storage_2 \ --tags cartridge-replicasets
हम http: // localhost: 8181 / admin / क्लस्टर / डैशबोर्ड पर जाते हैं और देखते हैं कि नेता बदल गया है:
लेकिन हमने कॉन्फ़िगरेशन से storage-2 इंस्टेंस को हटा दिया, यह अभी भी यहां क्यों है? तथ्य यह है कि Cartridge, failover_priority का नया मान प्राप्त कर रहा है failover_priority उदाहरणों को निम्नानुसार व्यवस्थित करता है: सूची से पहला उदाहरण नेता बन जाता है, शेष संकेत दिए गए उदाहरणों का अनुसरण करते हैं। विफलताओं_पायरिटी में उल्लेख नहीं किए गए उदाहरणों को यूयूआईडी द्वारा आदेश दिया जाएगा और अंत तक जोड़ा जाएगा।
निर्वासन का उदाहरण
लेकिन क्या होगा अगर हम टोपोलॉजी से उदाहरण को बाहर करना चाहते हैं? सब कुछ बहुत सरल है: आपको expelled ध्वज को पास करने की आवश्यकता expelled । चलो storage-2-replica उदाहरण को बाहर करते हैं। वह अब नेता है, इसलिए कार्ट्रिज हमें ऐसा करने की अनुमति नहीं देगा। लेकिन हम कठिनाइयों से डरते नहीं हैं, और फिर भी कोशिश करते हैं:
--- 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
प्लेबुक चलाएं और त्रुटि देखें:
जैसा कि हमने अभी देखा है, कार्ट्रिज वर्तमान प्रतिकृति के नेता को टोपोलॉजी से बाहर निकालने का औचित्य नहीं रखता है। यह काफी तार्किक है, क्योंकि प्रतिकृति अतुल्यकालिक है, एक नेता के बहिष्कार से डेटा हानि होने की संभावना है। हमें एक और नेता को निर्दिष्ट करने की आवश्यकता है और उसके बाद ही उदाहरण को छोड़ दें। भूमिका पहले नए प्रतिकृत विन्यास को लागू करेगी और फिर अपवाद से निपटेगी। इसलिए, हम 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
Voila, storage-2-replica उदाहरण टोपोलॉजी से गायब हो गया है!
ध्यान दें कि उदाहरण निर्वासन वास्तव में अंतिम और अपरिवर्तनीय है। टोपोलॉजी से उदाहरण को हटाने के बाद, हमारी ansible भूमिका सिस्टमड सेवा को रोक देगी और इस उदाहरण की सभी फ़ाइलों को हटा देगी।
यदि आप अचानक अपना दिमाग बदलते हैं और यह निर्णय लेते हैं कि storage-2 प्रतिकृतियों को अभी भी दूसरे उदाहरण की आवश्यकता है, तो आप इसे पुनर्स्थापित करने में सक्षम नहीं होंगे। कारतूस उन सभी उदाहरणों के यूयूआईडी को याद करता है जो टोपोलॉजी को छोड़ चुके हैं और निर्वासन को वापस लौटने की अनुमति नहीं देंगे। आप एक ही नाम और कॉन्फ़िगरेशन के साथ एक नया उदाहरण उठा सकते हैं, लेकिन इसमें स्पष्ट रूप से एक अलग यूयूआईडी होगा, इसलिए कार्ट्रिज इसे शामिल होने की अनुमति देगा।
प्रतिकृतियां निकालना
हमने पहले ही पता लगा लिया है कि हमें रेप्लिकासेट के नेता को निष्कासित करने की अनुमति नहीं दी जाएगी। लेकिन क्या होगा अगर हम 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
वेब UI http खोलें : // localhost: 8181 / admin / क्लस्टर / डैशबोर्ड और निरीक्षण करें कि सभी बाल्टियाँ storage-1 में कैसे बहती हैं: 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 विकल्प को निर्दिष्ट नहीं किया है, क्योंकि कम से कम एक उदाहरण जिसके लिए हमने प्लेबुक लॉन्च किया था, को expelled नहीं किया जाना चाहिए।
इसलिए हम मूल टोपोलॉजी में लौट आए:
प्राधिकरण
मैं प्रतिकृति सेट के प्रबंधन से ध्यान हटाने और सुरक्षा के बारे में सोचने का प्रस्ताव करता हूं। अब कोई भी अनधिकृत उपयोगकर्ता वेब UI के माध्यम से क्लस्टर का प्रबंधन कर सकता है। सहमत हूँ, ऐसा लगता है।
कारतूस अपने स्वयं के प्राधिकरण मॉड्यूल को जोड़ने की क्षमता प्रदान करता है, जैसे कि एलडीएपी (या आपके पास जो कुछ भी है), और इसका उपयोग उपयोगकर्ताओं और एप्लिकेशन तक उनकी पहुंच को प्रबंधित करने के लिए करते हैं। लेकिन हम अंतर्निहित प्राधिकरण मॉड्यूल का उपयोग करेंगे, जो कारतूस डिफ़ॉल्ट रूप से उपयोग करता है। यह मॉड्यूल आपको उपयोगकर्ताओं के साथ बुनियादी संचालन करने की अनुमति देता है (हटाएं, जोड़ें, संपादित करें) और पासवर्ड सत्यापन फ़ंक्शन को लागू करता है।
कृपया ध्यान दें कि हमारी आनुषंगिक भूमिका को इन सभी कार्यों को लागू करने के लिए प्राधिकरण बैकएंड की आवश्यकता है।
इसलिए, हम सिद्धांत से अभ्यास के लिए पास होते हैं। सबसे पहले, प्राधिकरण को अनिवार्य करें, सत्र पैरामीटर सेट करें और एक नया उपयोगकर्ता जोड़ें:
--- 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 / व्यवस्थापक / क्लस्टर / डैशबोर्ड एक आश्चर्य की प्रतीक्षा कर रहा है:
आप हमारे नए उपयोगकर्ता के उपयोगकर्ता username और password साथ लॉग इन कर सकते password या admin - डिफ़ॉल्ट उपयोगकर्ता के रूप में लॉग इन कर सकते हैं। उसका पासवर्ड क्लस्टर कुकी है, हमने चर cartridge_cluster_cookie में यह मान निर्दिष्ट किया है (यह app-default-cookie , आप झांक नहीं सकते हैं)।
एक सफल लॉगिन के बाद, यह सुनिश्चित करने के लिए Users टैब खोलें कि सब कुछ ठीक हो गया है:
नए उपयोगकर्ताओं को जोड़ने और उनकी सेटिंग्स को बदलने के साथ प्रयोग करें। किसी उपयोगकर्ता को हटाने के लिए, deleted: true निर्दिष्ट करें deleted: true उसके लिए deleted: true ध्वज। email और fullname मूल्यों का उपयोग कारतूस द्वारा किसी भी तरह से नहीं किया जाता है, लेकिन आप उन्हें सुविधा के लिए निर्दिष्ट कर सकते हैं।
अनुप्रयोग कॉन्फ़िगरेशन
आइए याद करें कि यह सब कैसे शुरू हुआ।
हमने एक छोटा एप्लिकेशन तैनात किया है जो ग्राहकों और उनके बैंक खातों के बारे में डेटा संग्रहीत करता है। जैसा कि आपको याद है, इस एप्लिकेशन की 2 भूमिकाएँ हैं: api और storage । storage भूमिका डेटा संग्रहण को संभालती है और अंतर्निहित vshard-storage भूमिका का उपयोग करते हुए vshard-storage । दूसरी भूमिका, api , डेटा प्रबंधन के लिए एक एपीआई के साथ एक HTTP सर्वर को लागू करती है, और इसके अंदर एक और मानक भूमिका, vshard-router जुड़ा हुआ है, जो vshard-router नियंत्रित करता है।
तो, हम एप्लिकेशन एपीआई के लिए पहला अनुरोध करते हैं। एक नया ग्राहक जोड़ें:
$ 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"}
कृपया ध्यान दें कि यूआरएल में हमने उदाहरण के लिए पोर्ट 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"}
महान, सब कुछ काम करता है! एपीआई को लागू किया गया है, कार्ट्रिज डेटा शार्पिंग में लगा हुआ है, हमने पहले ही आपातकालीन मामलों के लिए फेलओवर प्राथमिकता तय कर ली है और यहां तक कि अधिकृत प्राधिकरण भी। यह एप्लिकेशन के कॉन्फ़िगरेशन को करने का समय है।
वर्तमान क्लस्टर कॉन्फ़िगरेशन वितरित कॉन्फ़िगरेशन फ़ाइल में संग्रहीत है। प्रत्येक उदाहरण इस फ़ाइल की एक प्रति रखता है, और कार्ट्रिज क्लस्टर के सभी नोड्स के बीच इसका सिंक्रनाइज़ेशन सुनिश्चित करता है। हम इस फ़ाइल में हमारे एप्लिकेशन की भूमिकाओं के कॉन्फ़िगरेशन को निर्दिष्ट कर सकते हैं, और कारतूस सभी उदाहरणों में नए कॉन्फ़िगरेशन को वितरित करने का ध्यान रखेगा।
आइए इस फ़ाइल की वर्तमान सामग्री को देखें। Cofiguration files टैब पर जाएं और Download बटन पर क्लिक करें:
डाउनलोड की गई config.yml config.yml हम एक खाली तालिका पाते हैं। कोई आश्चर्य नहीं, क्योंकि हमने अभी तक कोई पैरामीटर निर्दिष्ट नहीं किया है:
--- [] ...
वास्तव में, हमारे क्लस्टर की कॉन्फ़िगरेशन फ़ाइल खाली नहीं है, यह वर्तमान टोपोलॉजी, प्राधिकरण सेटिंग्स, और सेटिंग को संग्रहीत करता है। लेकिन कार्ट्रिज इस जानकारी को साझा करना इतना आसान नहीं होगा, यह आंतरिक उपयोग के लिए है, और इसलिए इसे छिपे हुए सिस्टम अनुभागों में संग्रहीत किया जाता है, जिसे हम संपादित नहीं कर सकते।
प्रत्येक अनुप्रयोग भूमिका एक या अधिक कॉन्फ़िगरेशन अनुभागों का उपयोग कर सकती है। एक नया कॉन्फ़िगरेशन डाउनलोड करना दो चरणों में होता है: पहला, सभी भूमिकाएं सत्यापित करती हैं कि वे नए मापदंडों को स्वीकार करने के लिए तैयार हैं। यदि कोई आपत्ति नहीं है, तो परिवर्तन लागू किए जाते हैं, यदि कोई इसके खिलाफ है, तो एक रोलबैक होता है।
आइए हमारे आवेदन पर वापस जाएं। api भूमिका max-balance अनुभाग का उपयोग करती है, जहां एक ग्राहक खाते पर अधिकतम स्वीकार्य संतुलन संग्रहीत किया जाता है। आइए इस अनुभाग को कॉन्फ़िगर करें, लेकिन, निश्चित रूप से, मैन्युअल रूप से नहीं, बल्कि हमारी Ansible भूमिका का उपयोग करते हुए।
तो, अब एप्लिकेशन कॉन्फ़िगरेशन (या बल्कि, इसका एक हिस्सा हमारे पास उपलब्ध है) एक खाली तालिका है। इसमें 100000 मान के साथ एक max-balance अनुभाग जोड़ें। हम चर 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 निर्दिष्ट किया 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"}
आप कॉन्फ़िगरेशन फ़ाइल टैब पर कॉन्फ़िगरेशन फ़ाइल को फिर से डाउनलोड कर सकते हैं ताकि यह सुनिश्चित हो सके कि एक नया खंड वहां दिखाई देता है:
--- max-balance: 1000000 ...
एप्लिकेशन कॉन्फ़िगरेशन में नए अनुभागों को जोड़ने का प्रयास करें, उनकी सामग्री को बदलें या उन्हें पूरी तरह से हटा दें (इसके लिए आपको deleted: true जाने की आवश्यकता deleted: true अनुभाग में deleted: true ध्वज)।
आप पता लगा सकते हैं कि टारेंटूल कार्ट्रिज डॉक्यूमेंटेशन में भूमिकाओं में वितरित कॉन्फिगर का उपयोग कैसे करें।
जब आप उनके साथ काम कर रहे हों तब vagrant halt को बंद करने के लिए vagrant halt को बुलाना याद रखें।
निष्कर्ष में
पिछली बार, हमने सीखा कि कैसे एक विशेष एन्सिबल भूमिका का उपयोग करके वितरित टारेंटूल कार्ट्रिज एप्लिकेशन को तैनात किया जाए। आज हमने एप्लिकेशन को अपडेट किया, और आवेदन के टोपोलॉजी, शार्डिंग, प्राधिकरण और कॉन्फ़िगरेशन के प्रबंधन में भी महारत हासिल की।
वहां न रुकें, एंसेबल प्लेबुक लिखने के लिए अलग-अलग दृष्टिकोण सीखें और अधिकतम आराम के साथ अपने अनुप्रयोगों का उपयोग करें।
यदि आपके लिए कुछ काम नहीं करता है या यदि आपके पास हमारी सुयोग्य भूमिका को बेहतर बनाने के बारे में विचार हैं, तो टिकट शुरू करने के लिए स्वतंत्र महसूस करें। हम हमेशा आपकी समस्या के समाधान में मदद करेंगे और हम दिलचस्प प्रस्तावों के लिए खुश होंगे!