🥇Kohalikud failid rakenduse üleviimisel Kubernetesesse

CI/CD protsessi loomisel Kubernetesega võivad esineda probleemid, kui uue infrastruktuuri nõuded ja sinna viidav rakendus on omavahel vastuolus. Erilist tähelepanu tuleb pöörata rakenduse ehitamise etapis, et saada ühte pilt, mida kasutatakse projekti kõigi keskkondades ja klastrites. See põhimõte on õigete aluste allikas Google'i arvates konteinerite haldamisel (on korduvalt mainitud ja meie tehniline direktor). Siiski ei näe te olukordi, kus veebisaidi koodis kasutatakse valmis raamistikke, mille kasutamine seab piiranguid selle edasisele kasutusele. Ja kui "tavapärases keskkonnas" on sellega lihtne toime tulla, võib Kuberneteses selline käitumine muutuda probleemiks, eriti kui seisate selle ees esmakordselt. Kuigi leidlik meel võib pakkuda infrastruktuurlahendusi, mis esmapilgul tunduvad ilmsete ja isegi heade lahendustena... on oluline meeles pidada, et enamik olukordi saab ja peab olema

lahendatud arhitektuurselt Vaatame üle populaarsed workaround-lahendused failide salvestamiseks, mis võivad tuua ebameeldivaid tagajärgi klastri kasutamisel, ning juhime tähelepanu õigematele lahendustele..

Statika hoidmine

Kujutame ette veebirakendust, mis kasutab mingit statika generaatorit piltide, stiilide ja muu komplekti saamiseks. Näiteks PHP-raamistikus Yii on sisseehitatud varade haldaja, mis genereerib unikaalsed kataloogide nimed. Seetõttu on tulemuseks komplekt, millel on ilmselgelt üksteisega mitteületavad teed veebisaidi statikaks (see on saavutatud mitmetel põhjustel - näiteks duplikaatide vältimiseks, kui sama ressursi kasutavad mitmed komponendid). Nii korraldavad need sisseehitatud süsteemid esmakordsel veebiresursi mooduli juurdepääsul staatika genereerimise ja paigutamise (päris tihti on tegemist sümboolsete linkidega, kuid sellest räägime hiljem) unikaalse üldise juurkatalooge jaoks, mis on seotud selle väljastusprotsessiga:

webroot/assets/2072c2df/css/…

webroot/assets/2072c2df/images/…
webroot/assets/2072c2df/js/…
Mida see tähendab klastrist vaadatuna?

Lihtsaim näide

Võtame üsna levinud juhtumi, kus PHP ees on nginx staatika edastamiseks ja lihtsate päringute töötlemiseks. Lihtsaim lahendus on

kahe konteineriga: Deployment kahe konteineriga:

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

Lihtsustatud vormis nginx-i konfiguratsioon kokkuvõttes on järgmine:

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

Esimese külastuse puhul veebisaidile PHP konteineris ilmuvad varad. Kuid kahe konteineriga sama pod'i raames — nginx ei tea neist staatilistest failidest, mis (vastavalt konfiguratsioonile) peaks neid edastama. Tulemusena näeb klient kõigis CSS- ja JS-failide päringutes viga 404. Lihtsaim lahendus oleks korraldada konteinerite vahel ühine kataloog. Primitiivne variant — ühine 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

Nüüd konteineris genereeritud staatilised failid edastatakse nginx'i kaudu õigesti. Kuid tuletan meelde, et see on primitiivne lahendus, seega — see on kaugel ideest ja sellel on omad nüansid ja puudused, millest allpool.

Kaugtöötlemiseks arenenum salvestus

Kujutage ette, et kasutaja siseneb veebisaitile, laadib lehe, kus on konteineris olemasolevad stiilid, ja samal ajal, kui ta seda lehte loeb, deployime konteineri uuesti. Varade kataloog on tühjaks jäänud ja on vajalik päring PHP-le, et käivitada uute genereerimine. Kuid isegi pärast seda on linke vana staatika juurde endiselt aegunud, mis viib staatika kuvamise vigadeni.

Lisaks on meie projekt tõenäoliselt rohkem või vähem koormatud, seega ei piisa ühest rakenduse koopiast:

Suurendame Deployment kuni kahe koopiani.
Esimese päringu korral said ühes koopias loodud varad.
Mõnes punktis otsustas ingress (koormuse tasakaalustamise eesmärgil) saata päringu teisele koopiale, ja seal ei ole neid varasid veel. Võib-olla ei ole neid seal juba ka seetõttu, et me kasutame RollingUpdate ja hetkel teeme deploy'i.

Kokkuvõttes — taas vead.

Kuna vanade varade kaotamine on vältimatu, saab muuta emptyDir . Tundub, et hostPath, ladustades staatika füüsiliselt klastri sõlmele. See lähenemine on halb, kuna me tegelikult peame seotuks olema konkreetse klastri sõlmega oma rakendusega, sest — kui liigume teistesse sõlmedesse — ei sisalda kataloog vajalikke faile. Vastasel juhul on vajalik mingi taustasünkroonimine sõlmede vahel.

Millised on lahenduseed?

Kui riistvara ja ressursid lubavad, saab kasutada cephfs staatika vajaduste jaoks ligipääsetava katalooge korraldamiseks. Ametlik dokumentatsioon soovitatakse SSD-diske, vähemalt kolme kordset koopiat ja stabiilset "paksu" ühendust klastri sõlmede vahel.
Vähem nõudlik variant oleks NFS-serveri korraldamine. Siiski tuleb arvestada võimaliku hilinemise suurenemisega veebiserveri päringute töötlemisel, ning ka töökindlus ei ole parimal tasemel. Vea tagajärjed on katastroofilised: mount'i kadumine condeneerib klastrit surmale laadimise LA surve all, mis tõuseb taevasse.

Kõigi püsiva salvestuse loomise variantide puhul on aga vajalik taustapuhastus aegunud failide komplektide osas, mis on kogunenud teatud ajavahemiku jooksul. PHP konteinerite ette saab paigaldada DaemonSet caching nginx-d, mis hoiavad varade koopiaid piiratud ajaks. See käitusmuster on lihtsalt seadistatav proxy_cache salvestusaja või gigabaitide kettaruumiga.

Selle meetodi ühendamine ülalpool mainitud jaotatud failisüsteemidega avab tohutu võimaluse, kus piiranguks on ainult eelarve ja tehnilised võimalused nende rakendamiseks ja hooldamiseks. Kogemuste kohaselt toimib lihtsam süsteem stabiilsemalt. Lisakihtide lisamine muudab infrastruktuuri toetamise palju keerulisemaks, mis omakorda suurendab diagnoosimiseks ja taastamiseks kuluvat aega.

Soovitus

Kui pakutud salvestuslahenduste rakendamine tundub teile õigustamata (keeruline, kallis...), siis tasub olukorda vaadata teise nurga alt. Täpsemalt – uurida projekti arhitektuuri ja eemaldada probleem koodist, seostades teatud staatilise andmestruktuuriga pildis, sisu või protseduuri „ädaldamine“ ja/või varasem kompileerimine varade kogumise etapis. Nii saame täiesti ettenähtava käitumise ja ühtse failide komplekti kõigis keskkondades ja rakenduse replikates.

Kui naasta konkreetse näite juurde raamistikust Yii, ilma et süveneksime selle struktuuri (mis ei ole artikli eesmärk), piisab, kui osutada kahele populaarsele lähenemisele:

Muuda pildikogumise protsessi, et asetada varad ettenähtud kohta. Nii pakuvad/realiseerivad selliseid laiendusi nagu yii2-static-assets.
Määra konkreetseid räsikoodide varade kataloogide jaoks, nagu on räägitud näiteks, selles esitluses (alates slaidist №35). Muide, esitaja soovitab lõpuks (ja mitte ilma põhjuseta!) pärast varade kogumist build-serveril need üles laadida keskseks salvestamiseks (nt S3), mille ette paigutada CDN.

Üles laaditud failid

Teine juhtum, mis kindlasti töötab rakenduse viimise ajal Kubernetes klastrisse, on kasutajafailide hoidmine failisüsteemis. Näiteks on meil taas PHP rakendus, mis võtab faile üleslaadimisvormi kaudu, teeb nendega midagi töö käigus ja tagastab need tagasi.

Koht, kuhu need failid peavad minema, peab Kuberneteses olema rakenduse replikate jaoks ühine. Sõltuvalt rakenduse keerukusest ja vajadusest organiseerida nende failide püsimine võivad sellised kohad olla ülal mainitud jagatud seadmed, kuid nagu me näeme, on neil oma miinused.

Soovitus

Üks lahendus on kasutada S3-ühilduvat salvestust (isegi kui tegemist on mingi sarnase variandiga iseseisvalt majutatavast nagu minio). Üleminek S3 kasutamisele nõuab muudatusi koodi tasandil, kuidas sisu edastamine frontendis toimub, oleme juba me.

Kasutaja sessioonid

Eraldi tuleks märkida kasutaja sessioonide salvestamise korraldus. Tihti on need samuti failid kettal, mis Kuberneteses toob kaasa pidevad autentimispäringud, kui kasutaja päring satub teise konteinerisse.

Osaliselt lahendab probleemi stickySessions ingressis (seda funktsiooni toetatakse kõigis populaarsetes ingressi kontrollers — lisainfot vt meie ülevaates), et siduda kasutaja konkreetse rakenduse pod’iga:

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

Kuid see ei vabasta probleemidest korduvate juurutamiste korral.

Soovitus

Õigem viis oleks rakenduse üleviimine sessioonide salvestamiseks memcachedis, Redis ja sarnastes lahendustes — üldiselt täielik loobumine failivariantidest.

Kokkuvõte

Artiklis käsitletud infrastruktuuri lahendused väärivad rakendamist ainult ajutiste "pakkide" vormis (mis kõlab ingliskeelsena ilusamalt kui workaround). Need võivad olla asjakohased rakenduse migratsiooni varastes etappides Kubernetesesse, kuid ei tohiks "juurduda".

Üldine soovituslik tee on kõrvaldada need, et täiustada rakenduse arhitektuuri vastavalt juba laialdaselt tuntud 12-Factor App. Kuid see — rakenduse viimine stateless kujule — tähendab paratamatult, et on vajalikud muudatused koodis, ja siin on oluline leida tasakaal äri võimaluste/nõudmiste ja valitud tee elluviimise ning hooldamise perspektiivide vahel.