ProHoster > Blog > Administrazioa > Fitxategi lokalak aplikazio bat Kubernetesera migratzean

Fitxategi lokalak aplikazio bat Kubernetesera migratzean

Fitxategi lokalak aplikazio bat Kubernetesera migratzean

Kubernetes erabiliz CI/CD prozesu bat eraikitzean, batzuetan azpiegitura berriaren eskakizunen eta hara transferitzen ari den aplikazioaren arteko bateraezintasunaren arazoa sortzen da. Bereziki, aplikazioa eraikitzeko fasean garrantzitsua da lortzea bat erabiliko den irudia guztiak proiektu-inguruneak eta klusterrak. Printzipio honen oinarrian zuzena da Googleren arabera edukiontzien kudeaketa (horri buruz behin baino gehiagotan esan zuen eta gure sail teknikoa).

Hala ere, ez duzu inor ikusiko gunearen kodeak prest egindako marko bat erabiltzen duen egoeretan, eta horren erabilerak erabilera gehiagorako murrizketak ezartzen ditu. Eta "ingurune arruntean" horri aurre egiteko erraza den arren, Kubernetesen jokabide hori arazo bihur daiteke, batez ere lehenengo aldiz topatzen duzunean. Buru asmatzaile batek lehen begiratuan agerikoak eta onak diruditen azpiegitura irtenbideak sor ditzakeen arren... garrantzitsua da gogoratzea egoera gehienek egin dezaketela eta behar dutela. arkitektonikoki konponduko da.

Ikus ditzagun kluster bat funtzionatzerakoan ondorio desatseginak ekar ditzaketen fitxategiak gordetzeko konponbide konponbide ezagunak, eta bide zuzenagoa ere adierazi.

Biltegiratze estatikoa

Irudi, estilo eta beste gauza batzuk lortzeko sorgailu estatikoren bat erabiltzen duen web-aplikazio bat. Esate baterako, Yii PHP esparruak direktorio-izen esklusiboak sortzen dituen aktiboen kudeatzailea du. Horren arabera, irteera gune estatikorako bide multzo bat da, jakina, elkarren artean gurutzatzen ez direnak (hainbat arrazoirengatik egin zen, adibidez, bikoiztuak ezabatzeko osagai anitzek baliabide bera erabiltzen dutenean). Beraz, kaxatik kanpo, web-baliabideen modulu batera sartzen zaren lehen aldian, fitxategi estatikoak (izatez, maiz, esteka sinbolikoak, baina gehiago gehiago geroago) inplementazio honetarako bakarra den erro-direktorio komun batekin eratzen dira:

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

Zer esan nahi du horrek kluster bati dagokionez?

Adibiderik errazena

Har dezagun nahiko ohikoa den kasu bat, PHP-k nginx-ek aurrea hartzen duenean datu estatikoak banatzeko eta eskaera sinpleak prozesatzeko. Modurik errazena - Inplementazio bi ontzirekin:

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

Inprimaki sinplifikatuan, nginx konfigurazioa honako hau da:

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;
        }
    }

Webgunera lehen aldiz sartzen zarenean, aktiboak PHP edukiontzian agertzen dira. Baina pod bakarreko bi edukiontziren kasuan, nginx-ek ez daki ezer fitxategi estatiko horiei buruz, zeinak (konfigurazioaren arabera) eman behar zaizkien. Ondorioz, bezeroak 404 errore bat ikusiko du CSS eta JS fitxategietarako eskaera guztietan. Hemen irtenbiderik errazena edukiontzientzako direktorio komun bat antolatzea litzateke. Aukera primitiboa - orokorra 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

Orain edukiontzian sortutako fitxategi estatikoak nginx-ek behar bezala hornitzen ditu. Baina gogorarazten dizut hau irtenbide primitiboa dela, hau da, idealetik urrun dagoela eta bere Γ±abardura eta gabeziak dituela, jarraian eztabaidatzen direnak.

Biltegiratze aurreratuagoa

Orain imajinatu egoera bat non erabiltzaile batek gunea bisitatu, edukiontzian erabilgarri dauden estiloekin orrialde bat kargatu eta orrialde hau irakurtzen ari zen bitartean edukiontzia berriro zabaldu genuen. Aktiboen katalogoa hutsik geratu da eta PHP-ri eskaera egin behar zaio berriak sortzen hasteko. Hala ere, honen ondoren ere, estatika zaharretarako estekek ez dute garrantzirik izango, eta horrek akatsak ekarriko ditu estatikoak bistaratzeko.

Horrez gain, ziurrenik proiektu bat gehiago edo gutxiago kargatuta daukagu, eta horrek esan nahi du aplikazioaren kopia bat ez dela nahikoa izango:

  • Eskala dezagun Inplementazio gehienez bi erreplika.
  • Gunera lehen aldiz sartu zenean, aktiboak erreplika batean sortu ziren.
  • Noizbait, sarrerak erabaki zuen (karga orekatzeko helburuetarako) eskaera bat bidaltzea bigarren erreplikara, eta aktibo horiek oraindik ez zeuden. Edo agian ez daude jada erabiltzen dugulako RollingUpdate eta momentuz inplementazioa egiten ari gara.

Oro har, emaitza berriro akatsak dira.

Aktibo zaharrak ez galtzeko, alda dezakezu emptyDir on hostPath, kluster-nodo bati fisikoki estatikoa gehituz. Ikuspegi hau txarra da, benetan behar dugulako lotu kluster-nodo jakin batera zure aplikazioa, zeren - beste nodo batzuetara mugituz gero - direktorioak ez ditu beharrezko fitxategiak edukiko. Edo nodoen arteko atzeko planoko direktorioen sinkronizazio motaren bat beharrezkoa da.

Zeintzuk dira irtenbideak?

  1. Hardwareak eta baliabideak ahalbidetzen badute, erabil dezakezu cephs behar estatikoetarako berdin irisgarria den direktorio bat antolatzeko. Dokumentazio ofiziala SSD unitateak, gutxienez hiru aldiz erreplikatzea eta kluster-nodoen arteko konexio "lodi" egonkorra gomendatzen du.
  2. Ez hain zorrotza den aukera bat NFS zerbitzari bat antolatzea litzateke. Hala ere, orduan kontuan hartu behar duzu web zerbitzariaren eskaerak prozesatzeko erantzun-denbora izan daitekeen handitzea, eta akatsen tolerantzia asko utziko du. Porrotaren ondorioak hondamendiak dira: mendiaren galerak kumulua hiltzera kondenatzen du zerura lasterka doan LA kargaren presiopean.

Besteak beste, biltegiratze iraunkorra sortzeko aukera guztiek beharko dute hondo garbiketa denbora-tarte jakin batean pilatutako fitxategi multzo zaharkituak. PHP duten edukiontzien aurrean jarri dezakezu DaemonSet nginx cachingetik, aktiboen kopiak denbora mugatu batean gordeko dituena. Jokabide hau erraz konfigura daiteke erabiliz proxy_cache biltegiratze-sakonera egunetan edo gigabyte-ko diskoan.

Metodo hau goian aipatutako fitxategi-sistem banatuekin konbinatzeak irudimenerako eremu izugarria eskaintzen du, berau ezarri eta lagunduko dutenen aurrekontuak eta potentzial teknikoak soilik mugatuta. Esperientziaz, sistema zenbat eta sinpleagoa izan, orduan eta egonkorrago funtzionatzen duela esan dezakegu. Horrelako geruzak gehitzen direnean, askoz zailagoa da azpiegitura mantentzea, eta, aldi berean, akatsak diagnostikatzeko eta berreskuratzeko denbora handitzen da.

gomendio

Proposatutako biltegiratze-aukeren ezarpena ere justifikatu gabea iruditzen bazaizu (konplikatua, garestia...), orduan, merezi du egoera beste aldetik begiratzea. Hots, proiektuaren arkitekturan sakontzea eta konpondu arazoa kodean, irudiko datu-egitura estatiko batzuei lotuta, irudiaren muntaketa-fasean aktiboak "berotzeko" edo/eta aldez aurretik konpilatzeko edukien edo prozeduraren definizio argia. Horrela, guztiz aurreikus daitekeen portaera eta fitxategi-multzo berdina lortzen dugu exekutatzen ari den aplikazioaren ingurune eta errepliketarako.

Yii markoarekin adibide zehatzera itzultzen bagara eta bere egituran sakontzen ez badugu (artikuluaren xedea ez dena), nahikoa da bi ikuspegi ezagun seinalatzea:

  1. Aldatu irudia sortzeko prozesua aktiboak kokapen aurreikusgarri batean kokatzeko. Hau bezalako luzapenetan iradokitzen/inplementatzen da yii2-static-assets.
  2. Definitu hash espezifikoak aktiboen direktorioetarako, adibidez. aurkezpen hau (35. diapositibatik abiatuta). Bide batez, txostenaren egileak azken finean (eta ez arrazoirik gabe!) aholkatzen du aktiboak eraikitze-zerbitzarian muntatu ondoren, biltegiratze zentral batera igotzea (S3 bezalakoa), eta horren aurrean CDN bat jarri.

Deskarga daitezkeen fitxategiak

Aplikazio bat Kubernetes kluster batera migratzean behin betiko jokoan sartuko den beste kasu bat erabiltzaile-fitxategiak fitxategi-sisteman gordetzea da. Adibidez, PHP aplikazio bat dugu berriro kargatzeko formulario baten bidez fitxategiak onartzen dituena, haiekin zerbait egiten duen funtzionamenduan eta itzultzen dituena.

Kubernetesen, fitxategi hauek jarri behar diren kokapena aplikazioaren erreplika guztientzat komuna izan behar da. Aplikazioaren konplexutasunaren eta fitxategi horien iraupena antolatzeko beharraren arabera, aipatutako gailu partekatuen aukerak halako lekua izan daitezke, baina, ikusten dugunez, bere eragozpenak dituzte.

gomendio

Irtenbide bat da S3-rekin bateragarria den biltegiratzea erabiliz (nahiz eta minio bezalako auto-ostatatutako kategoria bat izan). S3ra aldatzeko aldaketak beharko dira kode mailan, eta edukia front end-ean nola emango den, badugu dagoeneko писали.

Erabiltzaileen saioak

Bereizita, nabarmentzekoa da erabiltzaileen saioak biltegiratzeko antolaketa. Askotan hauek ere diskoan dauden fitxategiak izaten dira, eta Kubernetesen testuinguruan erabiltzaileak etengabeko baimen-eskaerak ekarriko ditu bere eskaera beste edukiontzi batean amaitzen bada.

Arazoa neurri batean konpontzen da piztuz stickySessions sartzean (Eginbidea sarrera-kontrolatzaile ezagun guztietan onartzen da - xehetasun gehiagorako, ikus gure berrikuspena)erabiltzailea aplikazioarekin pod zehatz batera lotzeko:

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: /

Baina horrek ez ditu behin eta berriz inplementazioen arazoak kenduko.

gomendio

Modu zuzenagoa aplikazioa transferitzea izango litzateke saioak memcached, Redis eta antzeko soluzioetan gordetzea - Oro har, erabat utzi fitxategi-aukerak.

Ondorioa

Testuan aztertzen diren azpiegitura-irtenbideak aldi baterako "makuluen" formatuan soilik erabiltzekoak dira (ingelesez politagoa dena konponbide gisa). Aplikazio bat Kubernetesera migratzeko lehen faseetan garrantzitsuak izan daitezke, baina ez dute errotu behar.

Gomendatutako bide orokorra horiek kentzea da aplikazioaren aldaketa arkitektonikoaren alde, askorentzat ezaguna denaren arabera. 12-Factor aplikazioa. Hala ere, horrek -aplikazioa estaturik gabeko forma batera eramateak- ezinbestean esan nahi du kodean aldaketak egin beharko direla, eta hemen garrantzitsua da negozioaren gaitasun/eskakizunen eta aukeratutako bidea ezartzeko eta mantentzeko aukeren arteko oreka bilatzea. .

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Gehitu iruzkin berria