हमने रिपब्लिक वेबसाइट को कुबेरनेट्स में कैसे अनुवादित किया

प्रतिदिन मीडिया में परिवादात्मक, महत्वपूर्ण और बहुत ही शांत सामग्री प्रकाशित नहीं की जाती है, और कोई भी संपादक 100% सटीकता के साथ एक लेख की सफलता की भविष्यवाणी करने का कार्य नहीं करेगा। टीम के पास "मजबूत" सामग्री या "साधारण" कहने के लिए वृत्ति स्तर पर अधिकतम है। वह सब है। इसके बाद मीडिया का अप्रत्याशित जादू शुरू होता है, जिसकी बदौलत यह लेख अन्य प्रकाशनों के दर्जनों लिंक के साथ खोज परिणामों के शीर्ष पर पहुंच सकता है या सामग्री विस्मरण में डूब जाएगी। और सिर्फ शांत लेखों के प्रकाशन के मामले में, मीडिया साइटें समय-समय पर उपयोगकर्ताओं की राक्षसी आमद के अंतर्गत आती हैं, जिसे हम मामूली रूप से "हैब्रेफेक्ट" कहते हैं।

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

वॉइस्ड विशलिस्ट के कार्यान्वयन के लिए विभिन्न विकल्पों के रिपब्लिक विशेषज्ञों के साथ एक संयुक्त चर्चा के परिणामों के आधार पर, हमने प्रकाशन की वेबसाइट को कुबेरनेट्स * में स्थानांतरित करने का निर्णय लिया। इस बारे में कि यह सब हमारे लिए क्या है, और हमारी आज की कहानी होगी।

* इस कदम के दौरान, एक भी रिपब्लिकन तकनीकी विशेषज्ञ घायल नहीं हुआ

यह सामान्य शब्दों में कैसे दिखता है

यह सब निश्चित रूप से शुरू हुआ, इस बारे में बातचीत के साथ कि सब कुछ कैसे होगा "अब" और "बाद में"। दुर्भाग्य से, आईटी बाजार में आधुनिक प्रतिमान का अर्थ है कि जैसे ही कोई कंपनी किसी तरह के बुनियादी ढांचे के समाधान के लिए पक्ष में जाती है, वे इसे टर्नकी सेवा मूल्य सूची में बदल देते हैं। ऐसा लगता है कि काम "टर्नकी" है - एक सशर्त निदेशक या व्यवसाय के मालिक की तुलना में अच्छे और अच्छे व्यक्ति क्या हो सकते हैं? मैंने भुगतान किया, और मेरे सिर में चोट नहीं लगी: नियोजन, विकास, समर्थन - सब कुछ है, ठेकेदार की ओर से, व्यवसाय केवल इस तरह की सुखद सेवा के लिए भुगतान करने के लिए पैसे कमा सकता है।

हालांकि, आईटी अवसंरचना का पूर्ण हस्तांतरण ग्राहक के लिए दीर्घकालिक रूप से उचित नहीं है। यह एक बड़ी टीम के रूप में काम करने के लिए सभी दृष्टिकोणों से अधिक सही है, ताकि परियोजना पूरी होने के बाद, ग्राहक यह समझे कि आगे नए बुनियादी ढांचे के साथ कैसे रहना है, और दुकान के फर्श पर सहयोगियों के पास सवाल नहीं है "ओह, लेकिन आपने यहां क्या किया?" परिणामों के पूरा होने और प्रदर्शन के प्रमाण पत्र पर हस्ताक्षर करने के बाद। रिपब्लिक लोग एक ही राय के थे। नतीजतन, दो महीने के लिए हमने चार लोगों को ग्राहक के लिए उतारा, जिन्होंने न केवल हमारे विचार को महसूस किया, बल्कि कुबेरनेट्स की वास्तविकताओं में आगे के काम और अस्तित्व के लिए गणतंत्र की ओर से तकनीकी रूप से प्रशिक्षित विशेषज्ञ भी।

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

हम एक ब्रिजहेड तैयार कर रहे हैं

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

शुरुआत के बारे में, हमने साइट के संचालन को सुनिश्चित करने के लिए इस तरह के समाधान के बारे में देखा:


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

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

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

सभी आवश्यक अनुप्रयोग अलग-अलग डॉकटर कंटेनरों में चलने लगे - और यह नगीनक्स के साथ एक नियमित php साइट है, बहुत सी स्टैटिक्स, छवियों के साथ काम करने के लिए सेवाएं (आकार, अनुकूलन, आदि), और ... डी में लिखे गए वेब सॉकेट्स के लिए एक अलग सेवा। सभी कॉन्फ़िगरेशन फ़ाइलें (nginx-conf, php-conf ...) भी प्रोजेक्ट कोड बेस का हिस्सा बन गईं।

तदनुसार, स्थानीय वातावरण पूरी तरह से "रीक्रिएटेड" था, पूरी तरह से वर्तमान सर्वर इन्फ्रास्ट्रक्चर के समान। इस प्रकार, डेवलपर्स के स्थानीय मशीनों और उत्पादों पर दोनों पर एक ही वातावरण बनाए रखने के लिए आवश्यक समय कम हो गया था। बदले में, प्रत्येक डेवलपर के स्व-लिखित स्थानीय कॉन्फ़िगरेशन के कारण पूरी तरह से अनावश्यक समस्याओं से बचने में बहुत मदद मिली।

परिणामस्वरूप, निम्नलिखित सेवाओं को डॉक-कम्पोज़ वातावरण में उठाया गया:

• php-fpm एप्लिकेशन के लिए वेब;
• nginx;
• impproxy और कैरोवग (छवियों के साथ काम करने के लिए सेवाएं);
• postgres;
• Redis;
• लोचदार-खोज;
• तुरही (डी पर वेब सॉकेट के लिए एक ही सेवा)।

डेवलपर्स के दृष्टिकोण से, कोड आधार के साथ काम अपरिवर्तित रहा - यह आवश्यक सेवाओं में एक अलग निर्देशिका (साइट कोड के साथ आधार भंडार) से आवश्यक सेवाओं में मुहिम शुरू की गई थी: नग्नेक्स सेवा में सार्वजनिक निर्देशिका, php-fpm सेवा में सभी php अनुप्रयोग कोड। अलग निर्देशिका (जिसमें सभी कम्पोज़ वातावरण कॉन्फ़िगर किए गए हैं) से, संबंधित कॉन्फ़िगरेशन फ़ाइलें nginx और php-fpm सेवाओं में आरोहित हैं। डेवलपर के स्थानीय मशीन पर डेटा पोस्टग्रेज, इलास्टिक्स और रेडिस के साथ निर्देशिकाएँ भी माउंट किए जाते हैं, ताकि यदि सभी कंटेनरों को फिर से बनाया / हटाया जाए, तो इन सेवाओं में डेटा खो न जाए।

एप्लिकेशन लॉग के साथ काम करने के लिए - डॉकटर-कम्पोजिट वातावरण में भी - ईएलके स्टैक की सेवाओं को उठाया गया था। पहले, एप्लिकेशन लॉग का हिस्सा मानक / var / log / ... में लिखा गया था, php एप्लिकेशन लॉग और निष्पादन सेंट्री में लिखे गए थे, और "विकेंद्रीकृत" लॉग स्टोरेज का यह विकल्प काम करने के लिए बेहद असुविधाजनक था। अब, अनुप्रयोगों और सेवाओं को कॉन्फ़िगर किया गया है और ईएलके स्टैक के साथ बातचीत करने के लिए परिष्कृत किया गया है। लॉग का उपयोग करना बहुत आसान हो गया है, डेवलपर्स के पास अब लॉग को खोजने और छानने के लिए एक सुविधाजनक इंटरफ़ेस है। भविष्य में (पहले से ही घन में) - आप एप्लिकेशन के एक विशिष्ट संस्करण के लॉग देख सकते हैं (उदाहरण के लिए, कल से एक दिन पहले एक क्रोनज़ोबा लॉन्च किया गया था)।

इसके अलावा, गणराज्य की टीम ने अनुकूलन की एक छोटी अवधि शुरू की। टीम को नए विकास प्रतिमान में काम करने और समझने की जरूरत है, जिसमें निम्नलिखित पर विचार किया जाना चाहिए:

1. एप्लिकेशन स्टेटलेस हो जाते हैं, और वे किसी भी समय डेटा खो सकते हैं, इसलिए डेटाबेस, सत्र, स्थिर फ़ाइलों के साथ काम करना अलग तरीके से बनाया जाना चाहिए। PHP सत्रों को केंद्र में संग्रहीत किया जाना चाहिए और सभी एप्लिकेशन इंस्टेंस के बीच साझा किया जाना चाहिए। यह फ़ाइलों के लिए जारी रह सकता है, लेकिन प्रबंधन के अधिक से अधिक आसानी के कारण इन उद्देश्यों के लिए अधिक बार रेडिस लिया जाता है। डेटाबेस के लिए कंटेनरों को या तो डेटादिर को "माउंट" करना चाहिए, या डेटाबेस को कंटेनर इंफ्रास्ट्रक्चर के बाहर चलाया जाना चाहिए।
2. लगभग 50-60 GB की छवियों का एक फ़ाइल संग्रहण "वेब एप्लिकेशन के अंदर" नहीं होना चाहिए। इस तरह के उद्देश्यों के लिए, कुछ बाहरी भंडारण, सीडीएन-सिस्टम आदि का उपयोग करना आवश्यक है।
3. सभी एप्लिकेशन (डेटाबेस, एप्लिकेशन सर्वर ...) अब अलग-अलग "सेवाएं" हैं, और उनके बीच की बातचीत नए नामस्थान के सापेक्ष कॉन्फ़िगर की जानी चाहिए।

गणतंत्र विकास दल को नवाचारों की आदत पड़ने के बाद, हमने प्रकाशन की बिक्री के बुनियादी ढांचे को कुबेरनेट्स में स्थानांतरित करना शुरू कर दिया।

और यहाँ कुबेरनेट्स है

स्थानीय विकास के लिए निर्मित डॉक-कम्पोज़ पर्यावरण के आधार पर, हमने परियोजना को "क्यूब" में बदलना शुरू किया। सभी सेवाएँ जिन पर प्रोजेक्ट स्थानीय स्तर पर बनाया गया है, हम “कंटेनरों में पैक” करते हैं: हमने आँकड़ों को संकलित करते हुए, अनुप्रयोगों के निर्माण के लिए एक रैखिक और समझने योग्य प्रक्रिया का आयोजन किया। एक विकास के दृष्टिकोण से, उन्होंने पर्यावरण के चर में आवश्यक कॉन्फ़िगरेशन मापदंडों को हटा दिया, सत्रों को फाइलों में नहीं, बल्कि मूली में संग्रहीत करना शुरू किया। हमने परीक्षण वातावरण को उठाया, जहां हमने साइट का एक कार्यशील संस्करण तैनात किया।

चूंकि यह एक पूर्व अखंड परियोजना है, इसलिए यह स्पष्ट है कि क्रमशः दृश्यपटल और बैकएंड संस्करणों के बीच एक सख्त संबंध था, और इन दो घटकों को एक ही समय में तैनात किया गया था। इसलिए, हमने वेब एप्लिकेशन की पॉड्स को इस तरह से बनाने का फैसला किया कि दो कंटेनर एक पॉड में स्पिन करेंगे: php-fpm और nginx।

हमने ऑटो-स्केलिंग का भी निर्माण किया, ताकि ट्रैफ़िक के चरम पर वेब एप्लिकेशन अधिकतम 12 तक बढ़ें, कुछ निश्चितता / तत्परता परीक्षण सेट करें, क्योंकि एप्लिकेशन को चलाने के लिए कम से कम 2 मिनट की आवश्यकता होती है (क्योंकि आपको कैश को गर्म करने की आवश्यकता है, कॉन्फ़िगर करें ...

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

हम शुरू करते हैं

पहली पुनरावृत्ति में फ़ाइलों के साथ काम करने के लिए, हमने एक सामान्य निर्देशिका बनाई जो सभी कामकाजी मशीनों के लिए सिंक्रनाइज़ है। "सिंक्रोनाइज़्ड" शब्द से मेरा मतलब यहाँ है कि आप पहली बार में डरावने से क्या सोच सकते हैं - एक सर्कल में rsync। जाहिर है एक बुरा फैसला। परिणामस्वरूप, हमें GlusterFS पर सभी डिस्क स्थान मिले, चित्रों के साथ काम सेट किया ताकि वे किसी भी मशीन से हमेशा सुलभ रहें और कुछ भी धीमा न हो। भंडारण प्रणालियों (पोस्टग्रेज, इलास्टिक्स, रेडिस) के साथ हमारे अनुप्रयोगों की बातचीत के लिए, k8s में एक्सटर्नल नेम सेवाएं बनाई गई थीं, ताकि, उदाहरण के लिए, बैकअप डेटाबेस में तत्काल स्विच के मामले में, एक स्थान पर कनेक्शन मापदंडों को अपडेट करें।

क्रोंस के साथ सभी काम नए k8s संस्थाओं - क्रोनजॉब में ले जाया गया, जो कि एक विशेष कार्यक्रम के अनुसार चल सकते हैं।

परिणामस्वरूप, हमें यह वास्तुकला मिली:


क्लिक करने योग्य

अरे मुश्किल है

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

हमें विभिन्न रिपॉजिटरी और विभिन्न वातावरणों से तैनाती और नियंत्रण करने के लिए यह सब सिखाने के लिए CI \ CD सिस्टम के चारों ओर तंबूओं के साथ नृत्य करना था। आखिरकार, एप्लिकेशन संस्करणों पर निरंतर नियंत्रण की आवश्यकता होती है ताकि आप समझ सकें कि जब कोई सेवा या कोई अन्य सेवा तैनात की गई थी और अनुप्रयोग के किस संस्करण के साथ एक या कोई अन्य त्रुटि शुरू हुई थी। ऐसा करने के लिए, हमने सही लॉगिंग सिस्टम (साथ ही लॉगिंग कल्चर) स्थापित किया और ईएलके को लागू किया। सहकर्मियों ने कुछ चयनकर्ताओं को सेट करना सीखा, देखें कि क्रोन कौन सी त्रुटियों को उत्पन्न करता है, यह आम तौर पर कैसे निष्पादित होता है, क्योंकि क्रोन-कंटेनर निष्पादित होने के बाद "क्यूब" में, आप अब इसमें नहीं आएंगे।

लेकिन हमारे लिए सबसे कठिन काम पूरे कोड बेस को फिर से बनाना और संशोधित करना था।

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

कहीं फेल नहीं होता

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

रिपब्लिक के डेवलपर्स की टीम ने कैसे सामना किया

हमारी गतिविधियों में बहुत सारे बदलाव आए, और हमने इसे समझा। वास्तव में, हमने न केवल "मुख्य-बैकअप सर्वर" बंडल के बजाय प्रकाशन के बुनियादी ढांचे को फिर से तैयार किया, एक कंटेनर समाधान लागू किया जो अतिरिक्त संसाधनों को आवश्यकतानुसार जोड़ता है, लेकिन आगे के विकास के लिए दृष्टिकोण को पूरी तरह से बदल दिया।

कुछ समय बाद, लोग यह समझने लगे कि यह सीधे कोड के साथ काम नहीं कर रहा है, बल्कि एक सार एप्लिकेशन के साथ काम कर रहा है। CI \ CD प्रक्रियाओं (जेनकिन्स पर निर्मित) को देखते हुए, उन्होंने परीक्षण लिखना शुरू कर दिया, उन्हें पूर्ण विकसित देव-मंच-ठेस वातावरण मिला, जहां वे वास्तविक समय में अपने आवेदन के नए संस्करणों का परीक्षण कर सकते हैं, जहां सब कुछ गिर जाता है, और में रहना सीखते हैं नई आदर्श दुनिया।

क्लाइंट को क्या मिला

सबसे पहले, गणतंत्र को अंततः एक नियंत्रित तैनाती प्रक्रिया मिली! यह हुआ करता था: गणतंत्र में एक जिम्मेदार व्यक्ति था जो सर्वर पर गया, मैन्युअल रूप से सब कुछ शुरू किया, फिर स्टैटिक्स एकत्र किए, अपने हाथों से जांच की कि कुछ भी नहीं गिरा था ... अब तैनाती की प्रक्रिया का निर्माण किया जाता है ताकि डेवलपर्स विकास में लगे रहें और किसी और चीज़ पर समय बर्बाद न करें। । और जिम्मेदार व्यक्ति के पास अब एक काम है - यह देखने के लिए कि रिहाई सामान्य रूप से कैसे हुई।

मास्टर शाखा को एक धक्का के बाद, या तो स्वचालित रूप से या "पुश-बटन" तैनाती द्वारा (समय-समय पर, कुछ व्यावसायिक आवश्यकताओं के कारण, स्वचालित तैनाती अक्षम हो जाती है), जेनकिंस मैदान में प्रवेश करती है: परियोजना की विधानसभा शुरू होती है। सबसे पहले, सभी डॉकटर कंटेनरों को इकट्ठा किया जाता है: तैयारी कंटेनरों में निर्भरता (संगीतकार, यार्न, एनपीएम) स्थापित की जाती है, जो आपको निर्माण प्रक्रिया को गति देने की अनुमति देती है यदि तैनाती के दौरान आवश्यक पुस्तकालयों की सूची नहीं बदली गई है; फिर php-fpm, nginx, अन्य सेवाओं के लिए कंटेनरों को एकत्र किया जाता है, जिसमें, docker- कम्पोज़ पर्यावरण के साथ सादृश्य द्वारा, कोड आधार के केवल आवश्यक भागों की प्रतिलिपि बनाई जाती है। उसके बाद, परीक्षण लॉन्च किए जाते हैं और परीक्षणों के सफल पारित होने के मामले में, निजी स्टोर में छवियों का एक धक्का होता है और वास्तव में, क्यूबेर में तैनाती को बाहर करना।

K8s को गणतंत्र हस्तांतरण के लिए धन्यवाद, हमें तीन वास्तविक मशीनों के एक क्लस्टर का उपयोग करके एक आर्किटेक्चर मिला, जिस पर एक ही समय में वेब एप्लिकेशन की बारह प्रतियां "स्पिन" कर सकती हैं। उसी समय, वर्तमान लोड के आधार पर सिस्टम स्वयं निर्णय लेता है कि उसे अभी कितनी प्रतियों की आवश्यकता है। हमने स्थैतिक प्राथमिक और बैकअप सर्वरों के साथ "काम करता है - काम नहीं करता है" लॉटरी से रिपब्लिक लिया और साइट पर लोड में हिमस्खलन जैसी वृद्धि के लिए तैयार उनके लिए एक लचीली प्रणाली का निर्माण किया।

इस समय, यह सवाल उठ सकता है कि "दोस्तों, आपने लोहे के दो टुकड़ों को लोहे के एक ही टुकड़े में बदल दिया, लेकिन वर्चुअलाइजेशन के साथ, लाभ क्या है, क्या आप ठीक हैं?" और, ज़ाहिर है, यह तर्कसंगत होगा। लेकिन केवल भाग में। नतीजतन, हमें वर्चुअलाइजेशन के साथ न केवल हार्डवेयर के टुकड़े मिले। हमें एक स्थिर कामकाजी माहौल मिला, भोजन और कुंवारी दोनों में समान। एक पर्यावरण जो सभी परियोजना प्रतिभागियों के लिए केंद्र द्वारा प्रबंधित किया जाता है। हमें पूरे प्रोजेक्ट को असेंबल करने और रिलीज़ को दोबारा चालू करने के लिए एक मैकेनिज़्म मिला, जो सभी के लिए समान हो। हमें एक सुविधाजनक परियोजना आर्केस्ट्रा सिस्टम मिला। जैसे ही रिपब्लिक टीम ने नोटिस किया कि वे आम तौर पर पर्याप्त वर्तमान संसाधनों और अल्ट्रा-हाई लोड (या जब यह पहले से ही हो चुका है और सब कुछ बस गया है) के जोखिमों को खत्म कर देते हैं, तो वे बस एक और सर्वर लेते हैं, 10 मिनट में उस पर एक क्लस्टर नोड की भूमिका निभाते हैं, और ऑप-ऑप सब कुछ सुंदर और फिर से अच्छा है। पिछली परियोजना संरचना में इस तरह के दृष्टिकोण का सुझाव नहीं दिया गया था; ऐसी समस्याओं का न तो धीमा और न ही त्वरित समाधान था।

दूसरे, एक सहज तैनाती दिखाई दी है: आगंतुक या तो आवेदन के पुराने संस्करण में मिलेगा, या एक नए के लिए। और पहले की तरह नहीं, जब सामग्री नई हो सकती थी, लेकिन शैली पुरानी हैं।
नतीजतन, व्यवसाय संतुष्ट है: सभी प्रकार की नई चीजें अब तेजी से और अधिक बार की जा सकती हैं।
कुल मिलाकर, "लेकिन चलो कोशिश करते हैं" से "किया", परियोजना पर काम करने में 2 महीने लगे। हमारी ओर से टीम कोड और परीक्षणों के सत्यापन के दौरान "आधार" के लिए चार लोगों + समर्थन की एक वीर लैंडिंग है।

उपयोगकर्ताओं को क्या मिला

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