કુબરનેટ્સમાં એપ્લિકેશન સ્થાનાંતરિત કરતી વખતે સ્થાનિક ફાઇલો

કુબરનેટ્સનો ઉપયોગ કરીને સીઆઈ/સીડી પ્રક્રિયા બનાવતી વખતે, કેટલીકવાર નવા ઈન્ફ્રાસ્ટ્રક્ચરની જરૂરિયાતો અને તેમાં સ્થાનાંતરિત એપ્લિકેશન વચ્ચે અસંગતતાની સમસ્યા ઊભી થાય છે. ખાસ કરીને, એપ્લિકેશન બિલ્ડ સ્ટેજ પર તે મેળવવું મહત્વપૂર્ણ છે один છબી કે જેનો ઉપયોગ કરવામાં આવશે всех પ્રોજેક્ટ વાતાવરણ અને ક્લસ્ટરો. આ સિદ્ધાંત સાચા છે ગૂગલ અનુસાર કન્ટેનર મેનેજમેન્ટ (આ વિશે એક કરતા વધુ વાર બોલ્યા અને અમારા તકનીકી વિભાગ).

જો કે, તમે એવી પરિસ્થિતિઓમાં કોઈને જોશો નહીં જ્યાં સાઇટનો કોડ તૈયાર ફ્રેમવર્કનો ઉપયોગ કરે છે, જેનો ઉપયોગ તેના વધુ ઉપયોગ પર પ્રતિબંધ લાદે છે. અને જ્યારે "સામાન્ય વાતાવરણ" માં આનો સામનો કરવો સરળ છે, ત્યારે કુબરનેટ્સમાં આ વર્તણૂક સમસ્યા બની શકે છે, ખાસ કરીને જ્યારે તમે તેનો પ્રથમ વખત સામનો કરો છો. જ્યારે સંશોધનાત્મક મન ઇન્ફ્રાસ્ટ્રક્ચર સોલ્યુશન્સ સાથે આવી શકે છે જે સ્પષ્ટ લાગે છે અથવા તો પ્રથમ નજરમાં પણ સારા લાગે છે... તે યાદ રાખવું અગત્યનું છે કે મોટાભાગની પરિસ્થિતિઓ કરી શકે છે અને જોઈએ આર્કિટેક્ચરલ રીતે ઉકેલી શકાય.

ચાલો ફાઈલો સ્ટોર કરવા માટેના લોકપ્રિય ઉકેલો જોઈએ જે ક્લસ્ટર ચલાવતી વખતે અપ્રિય પરિણામો તરફ દોરી શકે છે, અને વધુ સાચો માર્ગ પણ દર્શાવે છે.

સ્થિર સંગ્રહ

સમજાવવા માટે, એક વેબ એપ્લિકેશનનો વિચાર કરો જે છબીઓ, શૈલીઓ અને અન્ય વસ્તુઓનો સમૂહ મેળવવા માટે અમુક પ્રકારના સ્થિર જનરેટરનો ઉપયોગ કરે છે. ઉદાહરણ તરીકે, 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 સ્થિર જરૂરિયાતો માટે સમાન રીતે સુલભ નિર્દેશિકા ગોઠવવા માટે. સત્તાવાર દસ્તાવેજીકરણ SSD ડ્રાઇવ્સ, ઓછામાં ઓછી ત્રણ-ગણી પ્રતિકૃતિ અને ક્લસ્ટર નોડ્સ વચ્ચે સ્થિર "જાડા" જોડાણની ભલામણ કરે છે.
2. NFS સર્વરને વ્યવસ્થિત કરવાનો ઓછો માગણી વિકલ્પ હશે. જો કે, પછી તમારે વેબ સર્વર દ્વારા વિનંતીઓ પર પ્રક્રિયા કરવા માટેના પ્રતિભાવ સમયમાં સંભવિત વધારાને ધ્યાનમાં લેવાની જરૂર છે, અને ખામી સહિષ્ણુતા ઇચ્છિત થવા માટે ઘણું છોડી દેશે. નિષ્ફળતાના પરિણામો આપત્તિજનક છે: માઉન્ટનું નુકશાન આકાશમાં ધસી રહેલા LA લોડના દબાણ હેઠળ ક્લસ્ટરને મૃત્યુ તરફ દોરી જાય છે.

અન્ય વસ્તુઓમાં, સતત સ્ટોરેજ બનાવવા માટેના તમામ વિકલ્પોની જરૂર પડશે પૃષ્ઠભૂમિ સફાઈ ફાઈલોના જૂના સેટ ચોક્કસ સમયગાળામાં સંચિત. PHP સાથે કન્ટેનરની સામે તમે મૂકી શકો છો ડેમનસેટ કેશીંગ nginx થી, જે અસ્કયામતોની નકલો મર્યાદિત સમય માટે સંગ્રહિત કરશે. આ વર્તન સરળતાથી રૂપરેખાંકિત કરી શકાય છે proxy_cache દિવસમાં સ્ટોરેજ ઊંડાઈ અથવા ડિસ્ક જગ્યાના ગીગાબાઈટ્સ સાથે.

ઉપરોક્ત વિતરિત ફાઇલ સિસ્ટમ્સ સાથે આ પદ્ધતિનું સંયોજન કલ્પના માટે એક વિશાળ ક્ષેત્ર પૂરું પાડે છે, જે ફક્ત બજેટ અને તકનીકી ક્ષમતા દ્વારા મર્યાદિત છે જેઓ તેનો અમલ અને સમર્થન કરશે. અનુભવથી, આપણે કહી શકીએ કે સિસ્ટમ જેટલી સરળ છે, તે વધુ સ્થિર કાર્ય કરે છે. જ્યારે આવા સ્તરો ઉમેરવામાં આવે છે, ત્યારે ઈન્ફ્રાસ્ટ્રક્ચર જાળવવું વધુ મુશ્કેલ બને છે, અને તે જ સમયે કોઈપણ નિષ્ફળતાના નિદાન અને પુનઃપ્રાપ્તિ માટે ખર્ચવામાં આવેલ સમય વધે છે.

ભલામણ

જો સૂચિત સ્ટોરેજ વિકલ્પોનો અમલ પણ તમને ગેરવાજબી લાગે છે (જટિલ, ખર્ચાળ...), તો બીજી બાજુથી પરિસ્થિતિને જોવી યોગ્ય છે. એટલે કે, પ્રોજેક્ટ આર્કિટેક્ચરમાં ખોદવું અને કોડમાં સમસ્યાને ઠીક કરો, ઇમેજમાં કેટલાક સ્ટેટિક ડેટા સ્ટ્રક્ચર સાથે જોડાયેલું છે, ઇમેજ એસેમ્બલી સ્ટેજ પર "વોર્મિંગ અપ" અને/અથવા અસ્કયામતો પ્રી-કમ્પાઇલિંગ માટેની સામગ્રી અથવા પ્રક્રિયાની અસ્પષ્ટ વ્યાખ્યા. આ રીતે અમને સંપૂર્ણપણે અનુમાનિત વર્તણૂક અને તમામ વાતાવરણ અને ચાલી રહેલ એપ્લિકેશનની પ્રતિકૃતિઓ માટે ફાઇલોનો સમાન સમૂહ મળે છે.

જો આપણે Yii ફ્રેમવર્ક સાથેના ચોક્કસ ઉદાહરણ પર પાછા આવીએ અને તેની રચના (જે લેખનો ઉદ્દેશ્ય નથી) માં તપાસ ન કરીએ, તો તે બે લોકપ્રિય અભિગમો દર્શાવવા માટે પૂરતું છે:

1. અસ્કયામતો અનુમાનિત સ્થાન પર મૂકવા માટે ઇમેજ બિલ્ડ પ્રક્રિયા બદલો. જેમ કે એક્સ્ટેંશનમાં આ સૂચન/અમલીકરણ કરવામાં આવ્યું છે yii2-સ્થિર-સંપત્તિ.
2. એસેટ ડિરેક્ટરીઓ માટે ચોક્કસ હેશ વ્યાખ્યાયિત કરો, જેમ કે દા.ત. આ રજૂઆત (સ્લાઇડ નં. 35 થી શરૂ થાય છે). માર્ગ દ્વારા, અહેવાલના લેખક આખરે (અને કારણ વિના નહીં!) સલાહ આપે છે કે બિલ્ડ સર્વર પર અસ્કયામતો એસેમ્બલ કર્યા પછી, તેમને કેન્દ્રીય સ્ટોરેજ (જેમ કે S3) પર અપલોડ કરો, જેની સામે CDN મૂકે છે.

ડાઉનલોડ્સ

કુબરનેટ્સ ક્લસ્ટરમાં એપ્લિકેશનને સ્થાનાંતરિત કરતી વખતે અન્ય એક કેસ જે ચોક્કસપણે અમલમાં આવશે તે ફાઇલ સિસ્ટમમાં વપરાશકર્તા ફાઇલોનો સંગ્રહ છે. ઉદાહરણ તરીકે, અમારી પાસે ફરીથી એક PHP એપ્લિકેશન છે જે અપલોડ ફોર્મ દ્વારા ફાઇલો સ્વીકારે છે, ઓપરેશન દરમિયાન તેમની સાથે કંઈક કરે છે અને તેમને પાછા મોકલે છે.

Kubernetes માં, જ્યાં આ ફાઇલો મૂકવી જોઈએ તે સ્થાન એપ્લિકેશનની તમામ પ્રતિકૃતિઓ માટે સામાન્ય હોવું જોઈએ. એપ્લિકેશનની જટિલતા અને આ ફાઇલોની દ્રઢતાને વ્યવસ્થિત કરવાની જરૂરિયાતને આધારે, ઉપરોક્ત શેર કરેલ ઉપકરણ વિકલ્પો આવા સ્થાન હોઈ શકે છે, પરંતુ, જેમ આપણે જોઈએ છીએ, તેમાં તેમની ખામીઓ છે.

ભલામણ

એક ઉપાય છે 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-પરિબળ એપ્લિકેશન. જો કે, આ - એપ્લિકેશનને સ્ટેટલેસ સ્વરૂપમાં લાવવું - અનિવાર્યપણે તેનો અર્થ એ છે કે કોડમાં ફેરફારોની જરૂર પડશે, અને અહીં વ્યવસાયની ક્ષમતાઓ/જરૂરિયાતો અને પસંદ કરેલા પાથને અમલમાં મૂકવા અને જાળવવાની સંભાવનાઓ વચ્ચે સંતુલન શોધવું મહત્વપૂર્ણ છે. .

PS

અમારા બ્લોગ પર પણ વાંચો:

• «nginx નો ઉપયોગ કરીને AWS S3 થી ફાઇલોને પ્રોક્સી કરવી»;
• «Google અનુસાર કન્ટેનરનો ઉપયોગ કરવા માટેની 7 શ્રેષ્ઠ પદ્ધતિઓ»;
• «કન્ટેનર-આધારિત એપ્લિકેશન ડિઝાઇન કરવા માટેના 7 સિદ્ધાંતો» (Red Hat માંથી);
• «7 ફેક્ટર એપ્લિકેશનમાં 12 ખૂટે છે».

સોર્સ: www.habr.com