Kubernetes में किसी एप्लिकेशन को पोर्ट करते समय स्थानीय फाइलें

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

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

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

स्थैतिक भंडारण

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

• webroot/assets/2072c2df/css/…
• webroot/assets/2072c2df/images/…
• webroot/assets/2072c2df/js/…

यह एक क्लस्टर के संदर्भ में क्या है?

सरलतम उदाहरण

आइए एक बहुत ही सामान्य मामला लेते हैं जब PHP स्टैटिक्स वितरित करने और सरल प्रश्नों को संभालने के लिए nginx का सामना करता है। सबसे आसान तरीका दो कंटेनरों के साथ तैनाती है :

 apiVersion: apps/v1 kind: Deployment metadata: name: site spec: selector: matchLabels: component: backend template: metadata: labels: component: backend spec: volumes: - name: nginx-config configMap: name: nginx-configmap containers: - name: php image: own-image-with-php-backend:v1.0 command: ["/usr/local/sbin/php-fpm","-F"] workingDir: /var/www - name: nginx image: nginx:1.16.0 command: ["/usr/sbin/nginx", "-g", "daemon off;"] volumeMounts: - name: nginx-config mountPath: /etc/nginx/conf.d/default.conf subPath: nginx.conf 

एक सरलीकृत रूप में, nginx config निम्नलिखित को उबालता है:

 apiVersion: v1 kind: ConfigMap metadata: name: "nginx-configmap" data: nginx.conf: | server { listen 80; server_name _; charset utf-8; root /var/www; access_log /dev/stdout; error_log /dev/stderr; location / { index index.php; try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } } 

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

 apiVersion: apps/v1 kind: Deployment metadata: name: site spec: selector: matchLabels: component: backend template: metadata: labels: component: backend spec: volumes: - name: assets emptyDir: {} - name: nginx-config configMap: name: nginx-configmap containers: - name: php image: own-image-with-php-backend:v1.0 command: ["/usr/local/sbin/php-fpm","-F"] workingDir: /var/www volumeMounts: - name: assets mountPath: /var/www/assets - name: nginx image: nginx:1.16.0 command: ["/usr/sbin/nginx", "-g", "daemon off;"] volumeMounts: - name: assets mountPath: /var/www/assets - name: nginx-config mountPath: /etc/nginx/conf.d/default.conf subPath: nginx.conf 

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

अधिक उन्नत भंडारण

अब एक ऐसी स्थिति की कल्पना करें जब एक उपयोगकर्ता ने किसी साइट का दौरा किया, कंटेनर में उपलब्ध शैलियों के साथ एक पृष्ठ लोड किया, और जब वह इस पृष्ठ को पढ़ रहा था, तो हमने कंटेनर को फिर से तैनात किया। परिसंपत्ति निर्देशिका खाली हो गई है और PHP के लिए नए लोगों को शुरू करने के लिए एक अनुरोध की आवश्यकता है। हालाँकि, इसके बाद भी, पुराने स्टैटिक्स के लिंक पुराने हो जाएंगे, जिससे स्टैटिक्स को प्रदर्शित करने में त्रुटि होगी।

इसके अतिरिक्त, हमारे पास संभवतः अधिक या कम भरी हुई परियोजना है, जिसका अर्थ है कि आवेदन की एक प्रति पर्याप्त नहीं होगी:

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

सामान्य तौर पर, परिणाम फिर से त्रुटियां हैं।

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

उपाय क्या हैं?

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

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

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

अनुशंसा

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

यदि हम Yii ढांचे के साथ एक विशिष्ट उदाहरण पर लौटते हैं और इसकी संरचना में खंडित नहीं होते हैं (जो कि लेख का उद्देश्य नहीं है), यह दो लोकप्रिय दृष्टिकोणों को इंगित करने के लिए पर्याप्त है:

1. छवि को इकट्ठा करने की प्रक्रिया को संशोधित करें ताकि परिसंपत्तियों को एक अनुमानित जगह पर रखा जाए। तो yii2- स्थैतिक संपत्ति जैसे एक्सटेंशन में प्रस्ताव / लागू करें।
2. संपत्ति निर्देशिकाओं के लिए विशिष्ट हैश को परिभाषित करें, उदाहरण के लिए, इस प्रस्तुति में (स्लाइड 35 के साथ शुरू)। वैसे, रिपोर्ट के लेखक अंततः (बिना कारण के!) सलाह देते हैं, बिल्ड सर्वर पर परिसंपत्तियों को इकट्ठा करने के बाद, उन्हें केंद्रीय भंडार (जैसे एस 3) पर अपलोड करने के लिए, जिसके सामने सीडीएन रखा जाए।

डाउनलोड करने योग्य फ़ाइलें

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

जिस स्थान पर इन फ़ाइलों को कुबेरनेट्स वास्तविकताओं में रखा जाना चाहिए, वह सभी एप्लिकेशन प्रतिकृतियों के लिए सामान्य होना चाहिए। आवेदन की जटिलता और इन फ़ाइलों की दृढ़ता को व्यवस्थित करने की आवश्यकता के आधार पर, ऐसी जगह ऊपर वर्णित साझा उपकरणों के लिए विकल्प हो सकती है, लेकिन, जैसा कि हम देखते हैं, उनकी कमियां हैं।

अनुशंसा

एक समाधान S3- संगत भंडारण का उपयोग करना है (भले ही किसी प्रकार की स्व-होस्ट श्रेणी जैसे मिनीओ)। S3 के साथ काम करने के लिए संक्रमण को कोड स्तर पर परिवर्तन की आवश्यकता होगी, और हमने पहले ही लिखा था कि सामग्री को कैसे सीमा पर वापस किया जाएगा।

कस्टम सत्र

अलग-अलग, यह उपयोगकर्ता सत्रों के भंडारण के संगठन को ध्यान देने योग्य है। अक्सर ये डिस्क पर फाइलें भी होती हैं, जो कुबेरनेट्स के संदर्भ में, उपयोगकर्ता से निरंतर प्राधिकरण अनुरोधों को जन्म देगा, यदि उसका अनुरोध किसी अन्य कंटेनर में आता है।

समस्या के कुछ भाग को stickySessions पर stickySessions शामिल करके हल किया जाता है (यह सुविधा सभी लोकप्रिय stickySessions में समर्थित है - अधिक विवरण के लिए हमारी समीक्षा देखें) ताकि उपयोगकर्ता को एप्लिकेशन के साथ एक विशिष्ट पॉड में बांधा जा सके:

 apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: nginx-test annotations: nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "route" nginx.ingress.kubernetes.io/session-cookie-expires: "172800" nginx.ingress.kubernetes.io/session-cookie-max-age: "172800" spec: rules: - host: stickyingress.example.com http: paths: - backend: serviceName: http-svc servicePort: 80 path: / 

लेकिन यह आपको बार-बार की तैनाती से नहीं बचाएगा।

अनुशंसा

एक और सही तरीका यह होगा कि एप्लीकेशन को स्टोर किए गए सत्रों को मेम्केड, रेडिस और इसी तरह के समाधानों में स्थानांतरित करना होगा - सामान्य रूप से, फ़ाइल विकल्पों को पूरी तरह से त्याग दें।

निष्कर्ष

पाठ में माना जाने वाला बुनियादी ढांचा समाधान केवल अस्थायी "बैसाखी" (जो वर्कअराउंड के रूप में अंग्रेजी में अधिक सुंदर लगता है) के प्रारूप में आवेदन के योग्य है। वे कुबेरनेट्स के लिए आवेदन प्रवास के शुरुआती चरणों में प्रासंगिक हो सकते हैं, लेकिन उन्हें "मूल" नहीं होना चाहिए।

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

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " नग्नेक्स टूल्स का उपयोग करके AWS S3 से फ़ाइलों को सम्‍मिलित करना ";
• " Google के अनुसार कंटेनरों के संचालन के लिए 7 सर्वोत्तम अभ्यास ";
• " कंटेनर आधारित अनुप्रयोगों के डिजाइन के लिए 7 सिद्धांत " (लाल टोपी से) ;
• " 12 फैक्टर ऐप दृष्टिकोण में 7 लापता कारक ।"