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

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

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

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

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

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

• 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 कॉन्फ़िगरेशन निम्नलिखित तक सीमित हो जाता है:

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 कंटेनर में दिखाई देती हैं। लेकिन एक पॉड के भीतर दो कंटेनरों के मामले में, nginx को इन स्थिर फ़ाइलों के बारे में कुछ नहीं पता है, जो (कॉन्फ़िगरेशन के अनुसार) उन्हें दी जानी चाहिए। परिणामस्वरूप, क्लाइंट को CSS और JS फ़ाइलों के सभी अनुरोधों के लिए 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 और फिलहाल हम तैनाती कर रहे हैं।

सामान्य तौर पर, परिणाम फिर से गलतियाँ हैं।

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

समाधान क्या हैं?

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

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

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

अनुशंसा

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

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

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

डाउनलोड

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

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

अनुशंसा

एक समाधान है S3-संगत भंडारण का उपयोग करना (भले ही यह मिनियो जैसी किसी प्रकार की स्व-होस्टेड श्रेणी हो)। S3 पर स्विच करने के लिए परिवर्तन की आवश्यकता होगी कोड स्तर पर, और सामग्री को फ्रंट एंड पर कैसे वितरित किया जाएगा, हम पहले ही जान चुके हैं писали.

उपयोगकर्ता सत्र

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

चालू करने से समस्या आंशिक रूप से हल हो जाती है 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-फैक्टर ऐप. हालाँकि, यह - एप्लिकेशन को स्टेटलेस फॉर्म में लाना - अनिवार्य रूप से इसका मतलब है कि कोड में बदलाव की आवश्यकता होगी, और यहां व्यवसाय की क्षमताओं/आवश्यकताओं और चुने गए पथ को लागू करने और बनाए रखने की संभावनाओं के बीच संतुलन खोजना महत्वपूर्ण है। .

पुनश्च

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

• «nginx का उपयोग करके AWS S3 से फ़ाइलों को प्रॉक्सी करना";
• «Google के अनुसार कंटेनरों का उपयोग करने की 7 सर्वोत्तम प्रथाएँ";
• «कंटेनर-आधारित अनुप्रयोगों को डिज़ाइन करने के लिए 7 सिद्धांत» (रेड हैट से);
• «7 फैक्टर ऐप में 12 गायब फैक्टर'.

स्रोत: www.habr.com