Kubernetes वर अनुप्रयोग स्थलांतरित करताना स्थानिक फायली

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

तथापि, साइटचा कोड रेडीमेड फ्रेमवर्क वापरतो अशा परिस्थितीत आपण कोणालाही दिसणार नाही, ज्याचा वापर त्याच्या पुढील वापरावर निर्बंध लादतो. आणि "सामान्य वातावरणात" असताना हे हाताळणे सोपे आहे, कुबर्नेट्समध्ये हे वर्तन एक समस्या बनू शकते, विशेषत: जेव्हा आपण प्रथमच त्याचा सामना करता. जरी एक कल्पक मन पायाभूत सुविधांचे निराकरण करू शकते जे स्पष्ट किंवा अगदी पहिल्या दृष्टीक्षेपात चांगले वाटू शकते... हे लक्षात ठेवणे महत्त्वाचे आहे की बहुतेक परिस्थितींमध्ये असे होऊ शकते आणि पाहिजे. आर्किटेक्चरल पद्धतीने सोडवले जावे.

क्लस्टर चालवताना अप्रिय परिणाम होऊ शकतील अशा फायली संचयित करण्यासाठी लोकप्रिय वर्कअराउंड सोल्यूशन्स पाहू आणि अधिक योग्य मार्ग देखील दर्शवू.

स्थिर संचयन

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

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

क्लस्टरच्या संदर्भात याचा अर्थ काय आहे?

साधे उदाहरण

स्टॅटिक डेटा वितरीत करण्यासाठी आणि सोप्या विनंत्यांची प्रक्रिया करण्यासाठी nginx च्या आधी PHP असेल तेव्हा एक सामान्य केस घेऊ. सर्वात सोपा मार्ग - तैनात करणे दोन कंटेनरसह:

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 सर्व्हर आयोजित करणे. तथापि, नंतर तुम्हाला वेब सर्व्हरद्वारे विनंत्यांच्या प्रक्रियेसाठी प्रतिसाद वेळेत संभाव्य वाढ लक्षात घेणे आवश्यक आहे आणि दोष सहिष्णुता इच्छित होण्यासाठी बरेच काही सोडेल. अपयशाचे परिणाम भयंकर आहेत: माउंट डूमच्या नुकसानामुळे एलए लोडच्या दबावाखाली क्लस्टरचा मृत्यू होतो.

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

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

शिफारस

जर प्रस्तावित स्टोरेज पर्यायांची अंमलबजावणी देखील तुम्हाला अन्यायकारक वाटत असेल (क्लिष्ट, महाग...), तर दुसऱ्या बाजूने परिस्थिती पाहणे योग्य आहे. बहुदा, प्रकल्प आर्किटेक्चर मध्ये खणणे आणि कोडमधील समस्येचे निराकरण करा, प्रतिमेतील काही स्थिर डेटा संरचनेशी जोडलेले, सामग्रीची एक अस्पष्ट व्याख्या किंवा "वार्मिंग अप" आणि/किंवा प्रतिमेच्या असेंब्ली स्टेजवर मालमत्ता पूर्वसंकलित करण्याची प्रक्रिया. अशा प्रकारे आम्हाला सर्व वातावरणासाठी आणि चालत असलेल्या ऍप्लिकेशनच्या प्रतिकृतींसाठी पूर्णपणे अंदाज करण्यायोग्य वर्तन आणि फाइल्सचा समान संच मिळतो.

जर आपण Yii फ्रेमवर्कसह विशिष्ट उदाहरणाकडे परतलो आणि त्याच्या संरचनेत (जे लेखाचा हेतू नाही) शोधले नाही तर, दोन लोकप्रिय दृष्टिकोन दर्शविण्यास पुरेसे आहे:

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

डाउनलोड करण्यायोग्य फायली

कुबर्नेट्स क्लस्टरमध्ये अॅप्लिकेशन स्थलांतरित करताना निश्चितपणे लागू होणारी आणखी एक केस म्हणजे फाइल सिस्टममध्ये वापरकर्ता फाइल्स संचयित करणे. उदाहरणार्थ, आमच्याकडे पुन्हा एक 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: /

परंतु यामुळे वारंवार तैनातीमुळे समस्या दूर होणार नाहीत.

शिफारस

अर्ज हस्तांतरित करणे हा अधिक योग्य मार्ग आहे मेमकॅशेड, रेडिस आणि तत्सम समाधानांमध्ये सत्रे संचयित करणे - सर्वसाधारणपणे, फाइल पर्याय पूर्णपणे सोडून द्या.

निष्कर्ष

मजकूरात चर्चा केलेले पायाभूत उपाय केवळ तात्पुरत्या “क्रचेस” (जे इंग्रजीमध्ये वर्कअराउंड म्हणून अधिक सुंदर वाटतात) स्वरूपात वापरण्यास योग्य आहेत. ते कुबर्नेट्समध्ये अनुप्रयोग स्थलांतरित करण्याच्या पहिल्या टप्प्यात संबंधित असू शकतात, परंतु ते मूळ धरू नयेत.

सामान्य शिफारस केलेला मार्ग म्हणजे अनेकांना आधीच ज्ञात असलेल्या अनुषंगाने अनुप्रयोगातील आर्किटेक्चरल फेरफारच्या बाजूने त्यांची सुटका करणे. 12-फॅक्टर अॅप. तथापि, हे - अर्जाला स्टेटलेस फॉर्ममध्ये आणणे - याचा अर्थ अपरिहार्यपणे कोडमध्ये बदल करणे आवश्यक आहे, आणि येथे व्यवसायाच्या क्षमता/आवश्यकता आणि निवडलेल्या मार्गाची अंमलबजावणी आणि देखरेख करण्याच्या शक्यता यांच्यात संतुलन शोधणे महत्वाचे आहे. .

PS

आमच्या ब्लॉगवर देखील वाचा:

• «nginx वापरून AWS S3 वरून फायली प्रॉक्सी करणे";
• «Google नुसार कंटेनर वापरण्यासाठी 7 सर्वोत्तम पद्धती";
• «कंटेनर-आधारित अनुप्रयोग डिझाइन करण्यासाठी 7 तत्त्वे» (Red Hat वरून);
• «7 फॅक्टर अॅपमध्ये 12 गहाळ घटक».

स्त्रोत: www.habr.com