🕦 👈🏾 🤼 एडब्ल्यूएस पर उत्पादन में एक अखंड आवेदन की अदृश्य तैनाती। व्यक्तिगत अनुभव 😓 ◽️ 🕳️

मैं मिरो (पूर्व-रियलटाइम बोर्ड) में एक लीड देवोप्स इंजीनियर हूं। मैं साझा करूंगा कि कैसे हमारी DevOps टीम ने एक अखंड राजकीय आवेदन के दैनिक सर्वर रिलीज की समस्या को हल किया और उन्हें स्वचालित, उपयोगकर्ताओं के लिए अदृश्य और अपने स्वयं के डेवलपर्स के लिए सुविधाजनक बनाया।

हमारा बुनियादी ढांचा

हमारी विकास टीम 60 लोग हैं, जो स्क्रैम-टीमों में विभाजित हैं, जिनमें देवओप्स टीम भी है। अधिकांश स्क्रम कमांड उत्पाद की वर्तमान कार्यक्षमता का समर्थन करते हैं और नई सुविधाओं के साथ आते हैं। DevOps का कार्य एक बुनियादी ढाँचा बनाना और बनाए रखना है जो एप्लिकेशन को तेज़ी से और मज़बूती से काम करने में मदद करता है और टीमों को उपयोगकर्ताओं को नई कार्यक्षमता प्रदान करने की अनुमति देता है।

हमारा आवेदन एक अंतहीन ऑनलाइन बोर्ड है। इसमें तीन परतें शामिल हैं: एक साइट, एक क्लाइंट, और जावा में एक सर्वर, जो एक अखंड स्टेटफुल एप्लिकेशन है। एप्लिकेशन क्लाइंट के साथ एक निरंतर वेब-सॉकेट कनेक्शन रखता है, और प्रत्येक सर्वर खुले बोर्डों के कैश में मेमोरी रखता है।

संपूर्ण अवसंरचना - 70 से अधिक सर्वर - अमेज़ॅन में स्थित है: हमारे जावा अनुप्रयोग, वेब सर्वर, डेटाबेस सर्वर, दलालों और बहुत अधिक के साथ 30 से अधिक सर्वर। कार्यक्षमता के विकास के साथ, यह सब नियमित रूप से अपडेट किया जाना चाहिए, उपयोगकर्ताओं के काम को बाधित किए बिना।
साइट और क्लाइंट को अपडेट करना सरल है: हम पुराने संस्करण को एक नए के साथ बदल देते हैं, और अगली बार जब उपयोगकर्ता एक नई साइट और एक नए क्लाइंट को एक्सेस करता है। लेकिन अगर हम सर्वर जारी होने पर ऐसा करते हैं, तो हम डाउनटाइम प्राप्त करते हैं। हमारे लिए, यह अस्वीकार्य है, क्योंकि हमारे उत्पाद का मुख्य मूल्य वास्तविक समय में उपयोगकर्ताओं का संयुक्त कार्य है।

हमारी CI / CD प्रक्रिया कैसी दिखती है

हमारे साथ CI / CD प्रक्रिया git कमिट, git पुश, फिर स्वचालित असेंबली, ऑटो-टेस्टिंग, परिनियोजन, रिलीज़ और मॉनिटरिंग है।

निरंतर एकीकरण के लिए, हम बांस और बिटबकेट का उपयोग करते हैं। स्वचालित परीक्षण के लिए - जावा और पायथन, और लुभाना - स्वचालित परीक्षण के परिणामों को प्रदर्शित करने के लिए। निरंतर वितरण के लिए - पैकर, Ansible और पायथन। सभी मॉनिटरिंग ELK Stack, Prometheus और Sentry का उपयोग करके की जाती है।

डेवलपर्स कोड लिखते हैं, इसे रिपॉजिटरी में जोड़ते हैं, जिसके बाद स्वचालित असेंबली और स्वचालित परीक्षण लॉन्च किए जाते हैं। उसी समय टीम के अंदर अन्य डेवलपर्स से इकट्ठा होता है और कोड की समीक्षा करता है। जब ऑटोटेस्ट सहित सभी आवश्यक प्रक्रियाएं पूरी हो जाती हैं, तो टीम बिल्ड को मुख्य शाखा में रखती है, और मुख्य शाखा का निर्माण शुरू होता है और स्वचालित परीक्षण के लिए भेजा जाता है। पूरी प्रक्रिया को डिबग किया जाता है और टीम द्वारा अपने दम पर प्रदर्शन किया जाता है।

एएमआई छवि

बिल्ड बिल्ड और परीक्षण के समानांतर, अमेज़ॅन के लिए एएमआई छवि का निर्माण शुरू होता है। ऐसा करने के लिए, हम HashiCorp से पैकर का उपयोग करते हैं, एक महान ओपनसोर्स टूल जो आपको एक वर्चुअल मशीन की एक छवि बनाने की अनुमति देता है। सभी पैरामीटर कॉन्फ़िगरेशन कुंजियों के सेट के साथ JSON को दिए जाते हैं। मुख्य पैरामीटर बिल्डरों है, जो इंगित करता है कि हम किस प्रदाता के लिए छवि बना रहे हैं (हमारे मामले में, अमेज़ॅन के लिए)।

"builders": [{ "type": "amazon-ebs", "access_key": "{{user `aws_access_key`}}", "secret_key": "{{user `aws_secret_key`}}", "region": "{{user `aws_region`}}", "vpc_id": "{{user `aws_vpc`}}", "subnet_id": "{{user `aws_subnet`}}", "tags": { "releaseVersion": "{{user `release_version`}}" }, "instance_type": "t2.micro", "ssh_username": "ubuntu", "ami_name": "packer-board-ami_{{isotime \"2006-01-02_15-04\"}}" }],

यह महत्वपूर्ण है कि हम न केवल एक आभासी मशीन की एक छवि बनाएं, बल्कि इसे पहले से कॉन्फ़िगर करें Ansible: एक जावा एप्लिकेशन को चलाने के लिए आवश्यक पैकेज स्थापित करें और कॉन्फ़िगरेशन सेटिंग्स बनाएं।

  "provisioners": [{ "type": "ansible", "playbook_file": "./playbook.yml", "user": "ubuntu", "host_alias": "default", "extra_arguments": ["--extra_vars=vars"], "ansible_env_vars": ["ANSIBLE_HOST_KEY_CHECKING=False", "ANSIBLE_NOCOLOR=True"] }]

Ansible-भूमिकाओं

हम सामान्य एन्सिबल प्लेबुक का उपयोग करते थे, लेकिन इससे बहुत दोहराव कोड होता था, जो आज तक बना रहना मुश्किल हो गया है। हमने एक प्लेबुक में कुछ बदला, इसे दूसरे में करना भूल गए और परिणामस्वरूप हम समस्याओं में भाग गए। इसलिए हमने Ansible-रोल्स का उपयोग करना शुरू कर दिया। हमने उन्हें यथासंभव बहुमुखी बनाया ताकि हम परियोजना के विभिन्न हिस्सों में उनका पुन: उपयोग कर सकें और बड़े दोहराए गए टुकड़ों में कोड को अधिभार न डालें। उदाहरण के लिए, हम सभी प्रकार के सर्वरों के लिए निगरानी भूमिका का उपयोग करते हैं।

 - name: Install all board dependencies hosts: all user: ubuntu become: yes roles: - java - nginx - board-application - ssl-certificates - monitoring

स्क्रम-टीमों की ओर से यह प्रक्रिया यथासंभव सरल दिखती है: टीम को स्लैक में सूचनाएं प्राप्त होती हैं कि बिल्ड और एएमआई-छवि को इकट्ठा किया गया है।

पूर्व विज्ञप्ति

हमने उपयोगकर्ताओं को उत्पाद परिवर्तन जल्द से जल्द देने के लिए पूर्व-रिलीज़ की शुरुआत की। वास्तव में, ये कैनरी रिलीज़ हैं जो आपको उपयोगकर्ताओं के एक छोटे प्रतिशत पर सुरक्षित रूप से नई कार्यक्षमता का परीक्षण करने की अनुमति देते हैं।

रिलीज को कैनरी क्यों कहा जाता है? पहले, खनिक, जब वे खदान में उतरे, उनके साथ एक कैनरी ले गए। अगर खदान में गैस होती तो कैनरी मर जाती, और खनिक तेजी से सतह पर आ गए। तो यह हमारे साथ है: अगर सर्वर में कुछ गड़बड़ होती है, तो रिलीज तैयार नहीं है और हम जल्दी से वापस रोल कर सकते हैं और अधिकांश उपयोगकर्ता कुछ भी नोटिस नहीं करेंगे।

कैनरी रिलीज़ कैसे शुरू होती है:

एक बटन पर बांस के क्लिक पर विकास टीम -> एक पायथन एप्लिकेशन को कहा जाता है जो पूर्व-रिलीज़ को लॉन्च करता है।
यह एप्लिकेशन के नए संस्करण के साथ पूर्व-तैयार एएमआई छवि से अमेज़ॅन में एक नया उदाहरण बनाता है।
इंस्टेंस को आवश्यक लक्ष्य समूहों में जोड़ा जाता है और बैलेंसरों को लोड किया जाता है।
Ansible के साथ, प्रत्येक उदाहरण के लिए एक व्यक्तिगत कॉन्फ़िगरेशन कॉन्फ़िगर किया गया है।
उपयोगकर्ता जावा एप्लिकेशन के नए संस्करण के साथ काम कर रहे हैं।

स्क्रम कमांड्स की ओर से, प्री-रिलीज़ लॉन्च प्रक्रिया फिर से यथासंभव सरल दिखती है: टीम को स्लैक में सूचनाएं मिलती हैं कि प्रक्रिया शुरू हो गई है, और 7 मिनट के बाद नया सर्वर पहले से ही चालू है। इसके अतिरिक्त, एप्लिकेशन रिलीज में होने वाले परिवर्तनों के पूरे चैंज को धीमा करने के लिए भेजता है।

इस सुरक्षा और विश्वसनीयता के लिए काम में बाधा की जाँच के लिए, स्क्रम टीमें सेंट्री में नई त्रुटियों की निगरानी करती हैं। यह वास्तविक समय में एक ओपन सोर्स बग ट्रैकिंग एप्लिकेशन है। संतरी जावा के साथ मूल एकीकृत करता है और इसमें लॉगबैक और लॉग 2 जे के साथ कनेक्टर्स होते हैं। जब आवेदन शुरू होता है, तो हम उस संस्करण पर संतरी को स्थानांतरित करते हैं जिस पर वह चल रहा है, और जब कोई त्रुटि होती है, तो हम देखते हैं कि यह किस संस्करण में हुआ है। यह स्क्रेम टीमों को त्रुटियों के लिए तुरंत प्रतिक्रिया देने और उन्हें जल्दी से ठीक करने में मदद करता है।

रिलीज से पहले कम से कम 4 घंटे काम करना चाहिए। इस समय के दौरान, टीम अपने काम की निगरानी करती है और यह तय करती है कि सभी उपयोगकर्ताओं को रिलीज़ जारी करना है या नहीं।

कई टीमें एक साथ अपनी रिलीज जारी कर सकती हैं । ऐसा करने के लिए, वे आपस में सहमत होते हैं कि पूर्व-रिलीज़ में क्या मिलता है और अंतिम रिलीज़ के लिए कौन जिम्मेदार है। उसके बाद, टीमें या तो सभी परिवर्तनों को एक पूर्व-रिलीज़ में जोड़ती हैं, या एक ही समय में कई पूर्व-रिलीज़ लॉन्च करती हैं। यदि सभी पूर्व-रिलीज़ सही हैं, तो उन्हें अगले दिन एक रिलीज़ के रूप में रिलीज़ किया जाएगा।

विज्ञप्ति

हम एक दैनिक रिलीज करते हैं:

हम काम करने के लिए नए सर्वर पेश करते हैं।
हम प्रोमेथियस का उपयोग करके नए सर्वर पर उपयोगकर्ता गतिविधि की निगरानी करते हैं।
नए उपयोगकर्ताओं के लिए पुराने सर्वरों तक पहुंच बंद करें।
हम उपयोगकर्ताओं को पुराने सर्वर से नए में स्थानांतरित करते हैं।
पुराने सर्वर को बंद करें।

सब कुछ बांस और पायथन अनुप्रयोगों का उपयोग करके बनाया गया है। एप्लिकेशन चल रहे सर्वरों की संख्या की जांच करता है और नए लोगों की समान संख्या को लॉन्च करने के लिए तैयार करता है। यदि पर्याप्त सर्वर नहीं हैं, तो वे एएमआई छवि से निर्मित हैं। एक नया संस्करण उन पर तैनात किया गया है, एक जावा एप्लिकेशन लॉन्च किया गया है, और सर्वर को ऑपरेशन में डाल दिया गया है।

निगरानी करते समय, प्रोमेथियस एपीआई का उपयोग करके पायथन एप्लिकेशन नए सर्वरों पर खुले बोर्डों की संख्या की जांच करता है। जब यह समझता है कि सब कुछ ठीक से काम कर रहा है, तो यह पुराने सर्वर तक पहुंच को बंद कर देता है और उपयोगकर्ताओं को नए में स्थानांतरित करता है।

 import requests PROMETHEUS_URL = 'https://prometheus' def get_spaces_count(): boards = {} try: params = { 'query': 'rtb_spaces_count{instance=~"board.*"}' } response = requests.get(PROMETHEUS_URL, params=params) for metric in response.json()['data']['result']: boards[metric['metric']['instance']] = metric['value'][1] except requests.exceptions.RequestException as e: print('requests.exceptions.RequestException: {}'.format(e)) finally: return boards

सर्वरों के बीच उपयोगकर्ताओं को स्थानांतरित करने की प्रक्रिया ग्राफाना में प्रदर्शित होती है। ग्राफ़ के बाएं आधे हिस्से में, पुराने संस्करण पर चलने वाले सर्वर दाईं ओर प्रदर्शित होते हैं - नए पर। चार्ट का अंतरण उपयोगकर्ता स्थानांतरण का क्षण है।

टीम स्लैक की रिलीज की देखरेख करती है। रिलीज के बाद, परिवर्तन का पूरा चैनल एक अलग चैनल स्लैक में प्रकाशित किया गया है, और जीरा में इस रिलीज से जुड़े सभी कार्य स्वचालित रूप से बंद हैं।

उपयोगकर्ता का माइग्रेशन क्या है

हम व्हाइटबोर्ड की स्थिति को संग्रहीत करते हैं जिस पर उपयोगकर्ता एप्लिकेशन मेमोरी में काम करते हैं और डेटाबेस में सभी परिवर्तनों को लगातार सहेजते हैं। क्लस्टर इंटरैक्शन स्तर पर बोर्ड को स्थानांतरित करने के लिए, हम इसे नए सर्वर पर मेमोरी में लोड करते हैं और क्लाइंट को फिर से कनेक्ट करने के लिए कमांड भेजते हैं। इस बिंदु पर, क्लाइंट पुराने सर्वर से डिस्कनेक्ट करता है और नए से जुड़ता है। कुछ सेकंड के बाद, उपयोगकर्ता शिलालेख देखते हैं - कनेक्शन बहाल। हालांकि, वे काम करना जारी रखते हैं और किसी भी असुविधा को नोटिस नहीं करते हैं।

अदृश्य को तैनात करते हुए हमने जो सीखा

एक दर्जन पुनरावृत्तियों के बाद हम क्या करने आए हैं:

स्क्रैम टीम अपने कोड की जाँच स्वयं करती है।
पूर्व-रिलीज़ को लॉन्च करने और नए उपयोगकर्ताओं के लिए कुछ बदलाव लाने के लिए स्क्रैम टीम तय करती है।
स्क्रैम-टीम यह तय करती है कि इसकी रिलीज़ सभी उपयोगकर्ताओं के लिए जाने के लिए तैयार है या नहीं।
उपयोगकर्ता काम करना जारी रखते हैं और कुछ भी नोटिस नहीं करते हैं।

यह तुरंत संभव नहीं था, हमने कई बार एक ही रेक पर कदम रखा और बहुत सारे शंकु भरे। मैं उन सबक को साझा करना चाहता हूं जो हमें मिले हैं।

सबसे पहले, मैनुअल प्रक्रिया, और उसके बाद ही इसका स्वचालन। पहले चरणों को स्वचालन में गहराई से जाने की आवश्यकता नहीं है, क्योंकि आप स्वचालित कर सकते हैं कि अंत में क्या उपयोगी नहीं है।

Ansible अच्छा है, लेकिन Ansible भूमिकाएँ बेहतर हैं। हमने अपनी भूमिकाओं को यथासंभव सार्वभौमिक बनाया: हमने दोहराव वाले कोड से छुटकारा पा लिया, इसलिए वे केवल उस कार्यक्षमता को ले जाते हैं जो उन्हें ले जानी चाहिए। यह आपको भूमिकाओं को पुन: उपयोग करके समय बचाने की अनुमति देता है, जो हमारे पास पहले से ही 50 से अधिक है।

पायथन में कोड का पुन: उपयोग करें और इसे अलग-अलग पुस्तकालयों और मॉड्यूल में तोड़ दें। यह आपको जटिल परियोजनाओं को नेविगेट करने और उनमें नए लोगों को जल्दी से विसर्जित करने में मदद करता है।

अगले चरण

अदृश्य परिनियोजन प्रक्रिया अभी खत्म नहीं हुई है। यहाँ कुछ चरण दिए गए हैं:

टीमों को न केवल पूर्व-रिलीज़, बल्कि सभी रिलीज़ को पूरा करने की अनुमति दें।
त्रुटियों के मामले में स्वचालित रोलबैक करें। उदाहरण के लिए, संतरी में महत्वपूर्ण त्रुटियों का पता चलने पर एक पूर्व-रिलीज़ को स्वचालित रूप से वापस रोल करना चाहिए।
त्रुटियों की अनुपस्थिति में रिलीज को पूरी तरह से स्वचालित करें। यदि पूर्व-रिलीज़ पर कोई त्रुटि नहीं थी, तो इसका मतलब है कि इसे स्वचालित रूप से आगे रोल किया जा सकता है।
संभावित सुरक्षा त्रुटियों के लिए स्वचालित कोड स्कैनिंग जोड़ें।

एडब्ल्यूएस पर उत्पादन में एक अखंड आवेदन की अदृश्य तैनाती। व्यक्तिगत अनुभव