स्थानीय फाइलहरू Kubernetes मा एक अनुप्रयोग स्थानान्तरण गर्दा

Kubernetes प्रयोग गरेर CI/CD प्रक्रिया निर्माण गर्दा, कहिलेकाहीँ नयाँ पूर्वाधारका आवश्यकताहरू र यसमा स्थानान्तरण भइरहेको अनुप्रयोग बीचको असंगतताको समस्या उत्पन्न हुन्छ। विशेष गरी, अनुप्रयोग निर्माण चरणमा यो प्राप्त गर्न महत्त्वपूर्ण छ один छवि जुन मा प्रयोग गरिनेछ всех परियोजना वातावरण र क्लस्टरहरू। यो सिद्धान्त सही आधार हो गुगल अनुसार कन्टेनर व्यवस्थापन (यस बारेमा एक पटक भन्दा बढी बोले र हाम्रो प्राविधिक विभाग)।

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

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

स्थिर भण्डारण

उदाहरणका लागि, छविहरू, शैलीहरू र अन्य चीजहरूको सेट प्राप्त गर्न कुनै प्रकारको स्थिर जनरेटर प्रयोग गर्ने वेब अनुप्रयोगलाई विचार गर्नुहोस्। उदाहरणका लागि, 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 कन्फिगरेसन निम्नमा उबलिन्छ:

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. एक कम माग गर्ने विकल्प NFS सर्भर संगठित गर्न को लागी हुनेछ। यद्यपि, त्यसोभए तपाईंले वेब सर्भरद्वारा अनुरोधहरू प्रशोधन गर्नको लागि प्रतिक्रिया समयमा सम्भावित वृद्धिलाई ध्यानमा राख्न आवश्यक छ, र गल्ती सहिष्णुताले चाहेको धेरै छोड्नेछ। असफलताका नतिजाहरू विनाशकारी हुन्छन्: माउन्ट डूमको हानिले आकाशमा दौडिरहेको LA लोडको आक्रमण अन्तर्गत क्लस्टरलाई मृत्युमा पुर्‍याउँछ।

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

माथि उल्लिखित वितरित फाइल प्रणालीहरूसँग यस विधिको संयोजनले कल्पनाको लागि ठूलो क्षेत्र प्रदान गर्दछ, केवल बजेट र प्राविधिक क्षमताहरू द्वारा सीमित जसले यसलाई कार्यान्वयन र समर्थन गर्नेछ। अनुभवबाट, हामी भन्न सक्छौं कि प्रणाली सरल, अधिक स्थिर यो काम गर्दछ। जब त्यस्ता तहहरू थपिन्छन्, यो पूर्वाधार कायम राख्न धेरै गाह्रो हुन्छ, र एकै समयमा निदान र कुनै पनि विफलताबाट पुन: प्राप्तिमा खर्च हुने समय बढ्छ।

सिफारिस

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

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

1. अनुमानित स्थानमा सम्पत्तिहरू राख्न छवि निर्माण प्रक्रिया परिवर्तन गर्नुहोस्। यो जस्तै विस्तार मा सुझाव / लागू गरिएको छ yii2-static-assets.
2. सम्पत्ति डाइरेक्टरीहरूका लागि विशिष्ट ह्यासहरू परिभाषित गर्नुहोस्, उदाहरणमा छलफल गरिए अनुसार। यो प्रस्तुति (स्लाइड नम्बर ३५ बाट सुरु हुँदै)। वैसे, रिपोर्टको लेखकले अन्ततः (र बिना कारण होइन!) सल्लाह दिन्छ कि निर्माण सर्भरमा सम्पत्तिहरू जम्मा गरेपछि, तिनीहरूलाई केन्द्रीय भण्डारण (जस्तै S35) मा अपलोड गर्नुहोस्, जसको अगाडि CDN राख्नुहोस्।

डाउनलोडहरू

Kubernetes क्लस्टरमा एप्लिकेसन माइग्रेट गर्दा निश्चित रूपमा खेलमा आउने अर्को केसले प्रयोगकर्ता फाइलहरू फाइल प्रणालीमा भण्डारण गर्दैछ। उदाहरणका लागि, हामीसँग फेरि एउटा PHP अनुप्रयोग छ जसले फाइलहरू अपलोड फारम मार्फत स्वीकार गर्छ, सञ्चालनको क्रममा तिनीहरूसँग केही गर्छ, र तिनीहरूलाई फिर्ता पठाउँछ।

Kubernetes मा, यी फाइलहरू राख्नु पर्ने स्थान अनुप्रयोगको सबै प्रतिकृतिहरूमा साझा हुनुपर्छ। अनुप्रयोगको जटिलता र यी फाइलहरूको दृढतालाई व्यवस्थित गर्न आवश्यकतामा निर्भर गर्दै, माथि उल्लेखित साझा उपकरण विकल्पहरू त्यस्तो ठाउँ हुन सक्छ, तर, हामीले देख्यौं, तिनीहरूका कमजोरीहरू छन्।

सिफारिस

एउटा उपाय हो S3-संगत भण्डारण प्रयोग गर्दै (यदि यो केहि प्रकारको सेल्फ-होस्टेड कोटी जस्तै minio हो)। 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: /

तर यसले बारम्बार डिप्लोइमेन्टको साथ समस्याहरू हटाउँदैन।

सिफारिस

एक थप सही तरिका मा आवेदन स्थानान्तरण हुनेछ memcached, Redis र समान समाधानहरूमा सत्रहरू भण्डारण गर्दै - सामान्यतया, फाइल विकल्पहरू पूर्ण रूपमा त्याग्नुहोस्।

निष्कर्षमा

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

सामान्य सिफारिश गरिएको मार्ग भनेको धेरैलाई पहिले नै थाहा भएको कुराको आधारमा एप्लिकेसनको वास्तुकला परिमार्जनको पक्षमा उनीहरूबाट छुटकारा पाउनु हो। १२-फ्याक्टर एप। यद्यपि, यो - आवेदनलाई स्टेटलेस फारममा ल्याउनु - अनिवार्य रूपमा कोडमा परिवर्तनहरू आवश्यक हुनेछ भन्ने हो, र यहाँ यो व्यवसायको क्षमताहरू/आवश्यकताहरू र छनौट गरिएको मार्ग कार्यान्वयन र कायम राख्नका लागि सम्भावनाहरू बीच सन्तुलन खोज्न महत्त्वपूर्ण छ। ।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «nginx प्रयोग गरेर AWS S3 बाट फाइलहरू प्रोक्सी गर्दै»;
• «गुगल अनुसार कन्टेनरहरू प्रयोग गर्नका लागि 7 उत्तम अभ्यासहरू»;
• «कन्टेनर-आधारित अनुप्रयोगहरू डिजाइन गर्नका लागि 7 सिद्धान्तहरू» (Red Hat बाट);
• «7 कारक एपमा 12 हराएको कारकहरू"।

स्रोत: www.habr.com