🥇Pelên herêmî dema ku serîlêdanek ji Kubernetes re koç dikin

Dema ku pêvajoyek CI/CD-ê bi karanîna Kubernetes ava dike, carinan pirsgirêk di navbera hewcedariyên binesaziya nû û serîlêdana ku jê re tê veguheztin de pirsgirêk derdikeve. Bi taybetî, di qonaxa avakirina serîlêdanê de girîng e ku were girtin один wêneyê ku dê tê de were bikar anîn всех hawîrdor û komên projeyê. Ev prensîb di bingehê rast de ye li gorî Google rêveberiya konteyneran (ji carekê zêdetir li ser vê peyivî û beşa teknîkî ya me).

Lêbelê, hûn ê di rewşên ku koda malperê çarçoveyek amadekirî bikar tîne de kesek nabînin, ku karanîna wê li ser karanîna wê ya pêşdetir sînoran ferz dike. Û dema ku di "hawirdorek normal" de bi vê re hêsan e ku meriv pê re mijûl bibe, di Kubernetes de ev tevger dikare bibe pirsgirêk, nemaze gava ku hûn yekem car pê re rû bi rû dibin. Digel ku hişê dahênerek dikare çareseriyên binesaziyê yên ku di nihêrîna pêşîn de eşkere an jî baş xuya dikin… girîng e ku ji bîr mekin ku pir rewşan dikarin û divê mîmarî bê çareserkirin.

Ka em ji bo hilanîna pelan li çareseriyên rêgezên populer ên ku dema xebitandina komekê dibe sedema encamên ne xweş binihêrin, û her weha rêyek rasttir destnîşan bikin.

Depoya statîk

Ji bo ronîkirinê, serîlêdanek webê bihesibînin ku celebek jeneratorek statîk bikar tîne da ku komek wêne, şêwaz û tiştên din bistîne. Mînakî, di çarçoweya Yii PHP-ê de rêveberek malperek çêkirî heye ku navên pelrêça bêhempa diafirîne. Li gorî vê yekê, derketin ji bo malpera statîk komek rêgez e ku eşkere bi hevûdu re naqetin (ev ji ber çend sedeman hate kirin - mînakî, ji bo rakirina dubareyan dema ku heman çavkaniyê ji hêla gelek pêkhateyan ve tê bikar anîn). Ji ber vê yekê, ji hundurê qutikê, cara yekem ku hûn digihîjin modulek çavkaniyek malperê, pelên statîk (bi rastî, pir caran hevgirêdan, lê li ser wê paşê bêtir) têne çêkirin û bi pelrêça root ya hevpar a ku ji bo vê bicîhkirinê yekta ye têne danîn:

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

Wateya vê yekê di warê komekê de çi ye?

Mînaka herî hêsan

Werin em dozek pir gelemperî bigirin, dema ku PHP ji hêla nginx ve tê pêşiyê da ku daneyên statîk belav bike û daxwazên hêsan pêvajoyê bike. Rêya herî hêsan - Dêrîn bi du konteynir:

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

Di formek sadekirî de, konfigurasyona nginx li jêr vedigere:

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

Dema ku hûn yekem car xwe digihînin malperê, hebûn di konteynera PHP-ê de xuya dibin. Lê di mijara du konteyneran de di nav yek pod de, nginx di derheqê van pelên statîk de, ku (li gorî veavakirinê) divê ji wan re were dayîn, tiştek nizane. Wekî encamek, xerîdar dê ji bo hemî daxwazên pelên CSS û JS xeletiyek 404 bibîne. Li vir çareseriya herî hêsan dê organîzekirina pelrêçek hevpar ji bo konteyneran be. Vebijêrk primitive - gelemperî 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

Naha pelên statîk ên ku di konteynerê de têne çêkirin ji hêla nginx ve rast têne xizmet kirin. Lê bihêle ez ji we re bînim bîra we ku ev çareseriyek primitive e, ku tê vê wateyê ku ew ji îdealê dûr e û hûrgulî û kêmasiyên xwe hene, ku li jêr têne nîqaş kirin.

Depoya pêşkeftîtir

Naha rewşek bifikirin ku bikarhênerek serdana malperê kir, rûpelek bi şêwazên ku di konteynerê de peyda dibin bar kir, û dema ku wî vê rûpelê dixwend, me konteynir ji nû ve bi cih kir. Kataloga malzemeyan vala bûye û daxwazek ji PHP-ê re hewce ye ku dest bi çêkirina yên nû bike. Lêbelê, piştî vê yekê jî, girêdanên bi statîkên kevin re dê ne girîng bin, ku dê di nîşandana statîkê de bibe sedema xeletiyan.

Digel vê yekê, bi îhtîmalek me projeyek kêm-zêde barkirî heye, ku tê vê wateyê ku yek kopiyek serîlêdanê dê ne bes be:

Ka em wê mezin bikin Dêrîn heta du replicas.
Dema ku malper yekem car hat gihîştin, malper di yek kopiyek de hatin afirandin.
Di hin xalan de, ketinê biryar da (ji bo mebestên hevsengkirina barkirinê) ku daxwazek ji kopya duyemîn re bişîne, û ev hebûn hîn li wir nebûne. An jî dibe ku ew êdî ne li wir bin ji ber ku em bikar tînin RollingUpdate û vê gavê em bicihkirinê dikin.

Bi gelemperî, encam dîsa xelet e.

Ji bo ku hûn hebûnên kevn winda nekin, hûn dikarin biguherînin emptyDir li ser hostPath, bi fizîkî statîk li girêkek komê zêde dike. Ev nêzîkatî xirab e ji ber ku em bi rastî neçar in bi girêkek koma taybetî ve girêdin serîlêdana we, ji ber ku - di bûyera guheztina girêkên din de - pelrêç dê pelên pêwîst nehewîne. An jî cûreyek hevdengkirina pelrêça paşîn di navbera girêkan de hewce ye.

Çareserî çi ne?

Ger hardware û çavkaniyan destûrê bidin, hûn dikarin bikar bînin cephfs ji bo hewcedariyên statîk pelrêçekek wekhev gihîştî organîze bike. Belgeya fermî ajokarên SSD, bi kêmî ve dubarekirina sê qat û pêwendiyek "stûr" a domdar di navbera girêkên komê de pêşniyar dike.
Vebijarkek kêmtir daxwaz dê bibe organîzekirina serverek NFS. Lêbelê, wê hingê hûn hewce ne ku zêdebûna gengaz a dema bersivdayînê ji bo pêvajoyên daxwaznameyên ji hêla servera malperê ve bihesibînin, û tolerasyona xeletiyê dê pir xwestek bihêle. Encamên têkçûnê felaket in: windabûna çiyê komê di bin zexta barkirina LA ya ku ber bi ezmên ve diherike, mehkûmê mirinê dike.

Di nav tiştên din de, hemî vebijarkên ji bo afirandina hilanîna domdar dê hewce bike paqijkirina paşnavê Komên pelên kevnar ên ku di heyamek diyarkirî de hatine berhev kirin. Hûn dikarin li ber konteynerên bi PHP-ê deynin DaemonSet ji caching nginx, ku dê kopiyên malûmilkan ji bo demek sînordar hilîne. Ev tevger bi hêsanî tê bikar anîn proxy_cache bi kûrahiya hilanînê bi rojan an gigabytes cîhê dîskê.

Tevhevkirina vê rêbazê bi pergalên pelan ên belavbûyî yên ku li jor hatine destnîşan kirin qadek mezin ji xeyalê re peyda dike, ku tenê ji hêla budce û potansiyela teknîkî ya kesên ku dê wê bicîh bikin û piştgirî bikin ve tê sînordar kirin. Ji ezmûnê, em dikarin bibêjin ku pergal her ku hêsantir be, ew qas aramtir dixebite. Gava ku qatên weha têne zêdekirin, domandina binesaziyê pir dijwartir dibe, û di heman demê de dema ku ji bo teşhîskirin û xelaskirina ji her têkçûnek tê derbas kirin zêde dibe.

Pêşniyar

Ger pêkanîna vebijarkên hilanînê yên pêşniyarkirî jî ji we re neheq xuya dike (tevlihev, biha ...), wê hingê hêja ye ku ji alîyê din ve li rewşê binihêrin. Ango, ku di mîmariya projeyê de bikolin û pirsgirêkê di kodê de çareser bikin, bi hin strukturên daneya statîk ên di wêneyê de ve girêdayî ye, pênaseyek nezelal ya naverok an prosedurek ji bo "germkirin" û/an berhevkirina malûmilkan di qonaxa komkirina wêneyê de. Bi vî rengî em tevgerek bêkêmasî ya pêşbînîkirî û heman pelan ji bo hemî hawîrdor û kopiyên serîlêdana xebitandinê digirin.

Ger em vegerin ser mînaka taybetî ya bi çarçoweya Yii û nekevin nav avahiya wê (ku ne mebesta gotarê ye), bes e ku em du nêzîkatiyên populer destnîşan bikin:

Pêvajoya avakirina wêneyê biguhezînin da ku malûmilkan li cîhek pêşbînîkirî bi cîh bikin. Ev di pêvekên mîna de tê pêşniyar kirin/pêkanînan yii2-statîk-serwetên.
Ji bo pelrêçikên maldariyê, wekî ku di mînakî de hatî nîqaş kirin, heşeyên taybetî diyar bikin. vê pêşkêşiyê (ji slide Hejmar 35 dest pê dike). Bi awayê, nivîskarê raporê di dawiyê de (û ne bê sedem!) şîret dike ku piştî berhevkirina hebûnên li ser servera çêkirinê, wan li depoyek navendî (wek S3) barkirin, li ber wê CDN-ê bi cîh bikin.

Daxistin

Bûyerek din a ku dê bê guman gava ku serîlêdanek berbi komek Kubernetes veguhezîne, pelên bikarhêner di pergala pelan de hilîne. Mînakî, me dîsa serîlêdanek PHP heye ku pelan bi forma barkirinê qebûl dike, di dema xebatê de tiştek bi wan re dike, û wan paşde dişîne.

Di Kubernetes de, cîhê ku divê ev pel werin danîn divê ji hemî kopiyên serîlêdanê re hevpar be. Bi tevliheviya serîlêdanê û hewcedariya organîzekirina domdariya van pelan ve girêdayî, vebijarkên cîhaza hevpar a jorîn dibe ku cîhek wusa bin, lê, wekî ku em dibînin, kêmasiyên wan hene.

Pêşniyar

Yek çareserî ye bikaranîna hilanînê S3-lihevhatî (tevî ku ew celebek kategoriyek xwe-mêvandar e mîna minio). Veguheztina S3 dê hewceyê guhertinan bike di asta kodê de, û naverok dê çawa li pêşiyê were radest kirin, me berê jî daye nivîsand.

Danişînên bikarhêner

Ji hev veqetandî, hêjayî balkişandina rêxistina hilanîna danişînên bikarhêner e. Bi gelemperî ev jî pelên li ser dîskê ne, ku di çarçoweya Kubernetes de dê bibe sedema daxwazên destûrnameyê yên domdar ji bikarhêner ku ger daxwaza wî di konteynerek din de biqede.

Pirsgirêk bi zivirandinê hinekî çareser dibe stickySessions li ser ketinê (taybetmendî di hemî kontrolkerên têketina populer de piştgirî ye - ji bo bêtir agahdarî, binêre nirxandina me)ku bikarhêner bi serîlêdanê re bi podek taybetî ve girêdin:

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

Lê ev ê pirsgirêkên bi şandinên dubare ji holê ranebe.

Pêşniyar

Rêyek rasttir dê veguhastina serîlêdanê be hilanîna danişînan di memcached, Redis û çareseriyên mîna wan de - bi gelemperî, vebijarkên pelê bi tevahî berdin.

encamê

Çareseriyên binesaziyê yên ku di metnê de hatine nîqaş kirin tenê di forma "kûçikên" demî de hêjayî karanîna ne (ku di îngilîzî de wekî karekî xweştir xuya dike). Dibe ku ew di qonaxên yekem ên koçkirina serîlêdanek li Kubernetes de têkildar bin, lê divê bingeh negirin.

Rêya pêşniyarkirî ya gelemperî ev e ku meriv ji wan xilas bibe di berjewendiya guheztina mîmarî ya serîlêdanê de li gorî ya ku jixwe ji gelek kesan re baş tê zanîn. 12-Faktor App. Lêbelê, ev - anîna serîlêdanê bi rengek bêdewlet - bê guman tê vê wateyê ku dê guhartinên kodê hewce bike, û li vir girîng e ku meriv hevsengiyek di navbera kapasîteyên / hewcedariyên karsaziyê û perspektîfên bicîhkirin û domandina riya bijartî de bibîne. .

PS

Li ser bloga me jî bixwînin:

«Proxykirina pelên ji AWS S3 bi karanîna nginx»;
«7 pratîkên çêtirîn ên ji bo karanîna konteyneran li gorî Google»;
«7 Prensîbên Sêwirana Serlêdanên Bingeha Konteyner» (ji Red Hat);
«7 Faktorên Wenda Di Serlêdana 12 Faktorî de".

Source: www.habr.com

Pelên herêmî dema ku serîlêdanek berbi Kubernetes veguhezînin

Depoya statîk

Mînaka herî hêsan

Depoya pêşkeftîtir

Pêşniyar

Daxistin

Pêşniyar

Danişînên bikarhêner

Pêşniyar

encamê

PS

Add a comment cancel reply