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 కాన్ఫిగరేషన్ క్రిందికి మరుగుతుంది:

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 అప్లికేషన్‌ని మేము మళ్లీ కలిగి ఉన్నాము.

కుబెర్నెటీస్‌లో, ఈ ఫైల్‌లను ఉంచాల్సిన స్థానం అప్లికేషన్ యొక్క అన్ని ప్రతిరూపాలకు సాధారణంగా ఉండాలి. అప్లికేషన్ యొక్క సంక్లిష్టత మరియు ఈ ఫైల్‌ల యొక్క నిలకడను నిర్వహించాల్సిన అవసరాన్ని బట్టి, పైన పేర్కొన్న భాగస్వామ్య పరికర ఎంపికలు అటువంటి ప్రదేశం కావచ్చు, కానీ, మనం చూస్తున్నట్లుగా, వాటికి వాటి లోపాలు ఉన్నాయి.

సిఫార్సు

ఒక పరిష్కారం 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: /

కానీ ఇది పునరావృత విస్తరణలతో సమస్యలను తొలగించదు.

సిఫార్సు

దరఖాస్తును బదిలీ చేయడం మరింత సరైన మార్గం memcached, Redis మరియు ఇలాంటి సొల్యూషన్స్‌లో సెషన్‌లను నిల్వ చేయడం - సాధారణంగా, ఫైల్ ఎంపికలను పూర్తిగా వదిలివేయండి.

తీర్మానం

టెక్స్ట్‌లో చర్చించిన మౌలిక సదుపాయాల పరిష్కారాలు తాత్కాలిక “క్రచెస్” ఆకృతిలో మాత్రమే ఉపయోగించదగినవి (ఇది ఆంగ్లంలో ప్రత్యామ్నాయంగా మరింత అందంగా ఉంటుంది). కుబెర్నెట్‌లకు అప్లికేషన్‌ను తరలించే మొదటి దశల్లో అవి సంబంధితంగా ఉండవచ్చు, కానీ రూట్ తీసుకోకూడదు.

చాలా మందికి ఇప్పటికే తెలిసిన వాటికి అనుగుణంగా అప్లికేషన్ యొక్క నిర్మాణ సవరణకు అనుకూలంగా వాటిని వదిలించుకోవడమే సాధారణ సిఫార్సు మార్గం. 12-కారకాల యాప్. అయితే, ఇది - అప్లికేషన్‌ను స్థితిలేని ఫారమ్‌కి తీసుకురావడం - అనివార్యంగా కోడ్‌లో మార్పులు అవసరం అని అర్థం, మరియు ఇక్కడ వ్యాపారం యొక్క సామర్థ్యాలు/అవసరాలు మరియు ఎంచుకున్న మార్గాన్ని అమలు చేయడానికి మరియు నిర్వహించడానికి అవకాశాల మధ్య సమతుల్యతను కనుగొనడం చాలా ముఖ్యం. .

PS

మా బ్లాగులో కూడా చదవండి:

• «nginxని ఉపయోగించి AWS S3 నుండి ఫైల్‌లను ప్రాక్సీ చేస్తోంది";
• «Google ప్రకారం కంటైనర్‌లను ఉపయోగించడం కోసం 7 ఉత్తమ పద్ధతులు";
• «కంటైనర్-ఆధారిత అప్లికేషన్‌లను రూపొందించడానికి 7 సూత్రాలు» (Red Hat నుండి);
• «7 ఫ్యాక్టర్ యాప్‌లో 12 మిస్సింగ్ ఫ్యాక్టర్స్".

మూలం: www.habr.com