Wrth adeiladu proses CI/CD gan ddefnyddio Kubernetes, weithiau mae'r broblem yn codi o anghydnawsedd rhwng gofynion y seilwaith newydd a'r cais sy'n cael ei drosglwyddo iddo. Yn benodol, ar y cam adeiladu cais mae'n bwysig cael 1 delwedd a ddefnyddir yn holl amgylcheddau a chlystyrau prosiect. Mae'r egwyddor hon yn sail i'r cywir rheoli cynhwysydd (mwy nag unwaith am hyn a'n hadran dechnegol).
Fodd bynnag, ni welwch unrhyw un mewn sefyllfaoedd lle mae cod y wefan yn defnyddio fframwaith parod, y mae ei ddefnydd yn gosod cyfyngiadau ar ei ddefnydd pellach. Ac er ei fod mewn “amgylchedd arferol” mae'n hawdd delio â hyn, yn Kubernetes gall yr ymddygiad hwn ddod yn broblem, yn enwedig pan fyddwch chi'n dod ar ei draws am y tro cyntaf. Er y gall meddwl dyfeisgar ddod o hyd i atebion seilwaith sy'n ymddangos yn amlwg neu hyd yn oed yn dda ar yr olwg gyntaf... mae'n bwysig cofio y gall ac y dylai'r rhan fwyaf o sefyllfaoedd cael eu datrys yn bensaernïol.
Edrychwn ar atebion datrysiad poblogaidd ar gyfer storio ffeiliau a all arwain at ganlyniadau annymunol wrth weithredu clwstwr, a hefyd nodi llwybr mwy cywir.
Storio statig
I ddarlunio, ystyriwch raglen we sy'n defnyddio rhyw fath o gynhyrchydd statig i gael set o ddelweddau, arddulliau, a phethau eraill. Er enghraifft, mae gan fframwaith Yii PHP reolwr asedau adeiledig sy'n cynhyrchu enwau cyfeiriadur unigryw. Yn unol â hynny, mae'r allbwn yn gyfres o lwybrau ar gyfer y safle sefydlog nad yw'n amlwg yn croestorri â'i gilydd (gwnaethpwyd hyn am sawl rheswm - er enghraifft, i ddileu dyblygu pan fydd cydrannau lluosog yn defnyddio'r un adnodd). Felly, allan o'r bocs, y tro cyntaf i chi gyrchu modiwl adnoddau gwe, mae ffeiliau statig (mewn gwirionedd, yn aml yn syml, ond yn fwy am hynny yn ddiweddarach) yn cael eu ffurfio a'u gosod allan gyda chyfeiriadur gwraidd cyffredin sy'n unigryw ar gyfer y defnydd hwn:
-
webroot/assets/2072c2df/css/… -
webroot/assets/2072c2df/images/… -
webroot/assets/2072c2df/js/…
Beth mae hyn yn ei olygu o ran clwstwr?
Yr enghraifft symlaf
Gadewch i ni gymryd achos eithaf cyffredin, pan fydd PHP yn cael ei ragflaenu gan nginx i ddosbarthu data statig a phrosesu ceisiadau syml. Y ffordd hawsaf - Defnyddio gyda dau gynhwysydd:
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.confMewn ffurf symlach, mae'r ffurfwedd nginx yn dibynnu ar y canlynol:
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;
}
}
Pan fyddwch chi'n cyrchu'r wefan gyntaf, mae asedau'n ymddangos yn y cynhwysydd PHP. Ond yn achos dau gynhwysydd o fewn un pod, nid yw nginx yn gwybod dim am y ffeiliau statig hyn, y dylid eu rhoi iddynt (yn ôl y ffurfweddiad). O ganlyniad, bydd y cleient yn gweld gwall 404 ar gyfer pob cais i ffeiliau CSS a JS. Yr ateb symlaf yma fyddai trefnu cyfeiriadur cyffredin ar gyfer cynwysyddion. Opsiwn cyntefig - cyffredinol 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.confNawr mae ffeiliau statig a gynhyrchir yn y cynhwysydd yn cael eu gwasanaethu gan nginx yn gywir. Ond gadewch imi eich atgoffa mai datrysiad cyntefig yw hwn, sy'n golygu ei fod ymhell o fod yn ddelfrydol ac mae ganddo ei naws a'i ddiffygion ei hun, a drafodir isod.
Storfa fwy datblygedig
Nawr dychmygwch sefyllfa lle ymwelodd defnyddiwr â'r wefan, llwytho tudalen gyda'r arddulliau sydd ar gael yn y cynhwysydd, a thra roedd yn darllen y dudalen hon, fe wnaethom ail-leoli'r cynhwysydd. Mae'r catalog asedau wedi dod yn wag ac mae angen cais i PHP i ddechrau cynhyrchu rhai newydd. Fodd bynnag, hyd yn oed ar ôl hyn, bydd cysylltiadau â hen statigau yn amherthnasol, a fydd yn arwain at wallau wrth arddangos statigau.
Yn ogystal, mae'n debyg y bydd gennym brosiect sydd wedi'i lwytho i raddau mwy neu lai, sy'n golygu na fydd un copi o'r cais yn ddigon:
- Gadewch i ni ei gynyddu Defnyddio hyd at ddau atgynhyrchiad.
- Pan gyrchwyd y wefan gyntaf, crëwyd asedau mewn un atgynhyrchiad.
- Ar ryw adeg, penderfynodd ingress (at ddibenion cydbwyso llwyth) anfon cais i'r ail replica, ac nid oedd yr asedau hyn yno eto. Neu efallai nad ydyn nhw yno bellach oherwydd rydyn ni'n defnyddio
RollingUpdateac ar hyn o bryd rydym yn gwneud defnydd.
Yn gyffredinol, mae'r canlyniad eto yn gamgymeriadau.
Er mwyn osgoi colli hen asedau, gallwch newid emptyDir ar hostPath, gan ychwanegu statig yn gorfforol i nod clwstwr. Mae'r dull hwn yn ddrwg oherwydd mae'n rhaid i ni mewn gwirionedd rhwymo i nod clwstwr penodol eich cais, oherwydd - rhag ofn symud i nodau eraill - ni fydd y cyfeiriadur yn cynnwys y ffeiliau angenrheidiol. Neu mae angen rhyw fath o gydamseriad cyfeiriadur cefndirol rhwng nodau.
Beth yw'r atebion?
- Os yw caledwedd ac adnoddau'n caniatáu, gallwch eu defnyddio i drefnu cyfeiriadur sydd yr un mor hygyrch ar gyfer anghenion sefydlog. yn argymell gyriannau SSD, o leiaf atgynhyrchu triphlyg a chysylltiad “trwchus” sefydlog rhwng nodau clwstwr.
- Opsiwn llai beichus fyddai trefnu gweinydd NFS. Fodd bynnag, yna mae angen i chi ystyried y cynnydd posibl mewn amser ymateb ar gyfer prosesu ceisiadau gan y gweinydd gwe, a bydd goddefgarwch nam yn gadael llawer i'w ddymuno. Mae canlyniadau methiant yn drychinebus: mae colli'r mownt yn tyngu'r clwstwr i farwolaeth o dan bwysau llwyth yr ALl yn rhuthro i'r awyr.
Ymhlith pethau eraill, bydd angen pob opsiwn ar gyfer creu storfa barhaus glanhau cefndir setiau hen ffasiwn o ffeiliau a gronnwyd dros gyfnod penodol o amser. O flaen cynwysyddion gyda PHP gallwch chi roi DaemonSet o caching nginx, a fydd yn storio copïau o asedau am gyfnod cyfyngedig. Mae'r ymddygiad hwn yn hawdd ei ffurfweddu gan ddefnyddio proxy_cache gyda dyfnder storio mewn dyddiau neu gigabeit o ofod disg.
Mae cyfuno'r dull hwn â'r systemau ffeiliau dosbarthedig a grybwyllir uchod yn darparu maes enfawr ar gyfer dychymyg, wedi'i gyfyngu'n unig gan gyllideb a photensial technegol y rhai a fydd yn ei weithredu a'i gefnogi. O brofiad, gallwn ddweud po symlaf yw'r system, y mwyaf sefydlog y mae'n gweithio. Pan ychwanegir haenau o'r fath, mae'n dod yn llawer anoddach cynnal a chadw'r seilwaith, ac ar yr un pryd mae'r amser a dreulir ar wneud diagnosis ac adfer o unrhyw fethiannau yn cynyddu.
Argymhelliad
Os yw gweithredu'r opsiynau storio arfaethedig hefyd yn ymddangos yn anghyfiawn i chi (cymhleth, drud ...), yna mae'n werth edrych ar y sefyllfa o'r ochr arall. Sef, i gloddio i mewn i bensaernïaeth y prosiect a trwsio'r broblem yn y cod, ynghlwm wrth rywfaint o strwythur data statig yn y ddelwedd, diffiniad diamwys o'r cynnwys neu'r weithdrefn ar gyfer “cynhesu” a/neu rag-grynhoi asedau yn ystod y cam cydosod delweddau. Fel hyn rydym yn cael ymddygiad cwbl ragweladwy a'r un set o ffeiliau ar gyfer pob amgylchedd a chopïau o'r rhaglen redeg.
Os byddwn yn dychwelyd at yr enghraifft benodol gyda'r fframwaith Yii ac nad ydym yn ymchwilio i'w strwythur (nad yw'n ddiben yr erthygl), mae'n ddigon tynnu sylw at ddau ddull poblogaidd:
- Newidiwch y broses adeiladu delwedd i osod asedau mewn lleoliad rhagweladwy. Mae hyn yn cael ei awgrymu/gweithredu mewn estyniadau fel .
- Diffinio hashes penodol ar gyfer cyfeiriaduron asedau, fel y trafodwyd yn e.e. (gan ddechrau o sleid Rhif 35). Gyda llaw, mae awdur yr adroddiad yn y pen draw (ac nid heb reswm!) Yn cynghori, ar ôl cydosod asedau ar y gweinydd adeiladu, eu lanlwytho i storfa ganolog (fel S3), a gosod CDN o'i flaen.
Ffeiliau i'w lawrlwytho
Achos arall a fydd yn bendant yn dod i rym wrth fudo cais i glwstwr Kubernetes yw storio ffeiliau defnyddwyr yn y system ffeiliau. Er enghraifft, mae gennym eto gais PHP sy'n derbyn ffeiliau trwy ffurflen uwchlwytho, yn gwneud rhywbeth gyda nhw yn ystod gweithrediad, ac yn eu hanfon yn ôl.
Yn Kubernetes, dylai'r lleoliad lle dylid gosod y ffeiliau hyn fod yn gyffredin i bob atgynhyrchiad o'r cais. Yn dibynnu ar gymhlethdod y cais a'r angen i drefnu dyfalbarhad y ffeiliau hyn, gall yr opsiynau dyfais a rennir uchod fod yn lle o'r fath, ond, fel y gwelwn, mae ganddynt eu hanfanteision.
Argymhelliad
Un ateb yw defnyddio storfa sy'n gydnaws â S3 (hyd yn oed os yw'n rhyw fath o gategori hunangynhaliol fel mini). Bydd angen newidiadau i newid i S3 ar lefel y cod, a sut y bydd cynnwys yn cael ei gyflwyno ar y pen blaen, rydym eisoes wedi .
Sesiynau defnyddwyr
Ar wahân, mae'n werth nodi trefniadaeth storio sesiynau defnyddwyr. Yn aml mae'r rhain hefyd yn ffeiliau ar ddisg, a fydd yng nghyd-destun Kubernetes yn arwain at geisiadau awdurdodi cyson gan y defnyddiwr os bydd ei gais yn dod i ben mewn cynhwysydd arall.
Mae'r broblem yn cael ei datrys yn rhannol trwy droi ymlaen stickySessions ar ddyfodiad (cefnogir y nodwedd ym mhob rheolydd mynediad poblogaidd - am ragor o fanylion, gweler )i rwymo'r defnyddiwr i god penodol gyda'r rhaglen:
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: /Ond ni fydd hyn yn dileu problemau o ran defnyddio dro ar ôl tro.
Argymhelliad
Ffordd fwy cywir fyddai trosglwyddo'r cais i storio sesiynau mewn memcached, Redis ac atebion tebyg - yn gyffredinol, rhoi'r gorau i opsiynau ffeil yn gyfan gwbl.
Casgliad
Mae'r atebion seilwaith a drafodir yn y testun yn deilwng i'w defnyddio ar ffurf “crutches” dros dro yn unig (sy'n swnio'n fwy prydferth yn Saesneg fel ateb). Gallant fod yn berthnasol yng nghamau cyntaf mudo cais i Kubernetes, ond ni ddylent wreiddio.
Y llwybr a argymhellir yn gyffredinol yw cael gwared arnynt o blaid addasu'r cais yn bensaernïol yn unol â'r hyn sydd eisoes yn adnabyddus i lawer. . Fodd bynnag, mae hyn - dod â'r cais i ffurf ddi-wladwriaeth - yn anochel yn golygu y bydd angen newidiadau yn y cod, ac yma mae'n bwysig canfod cydbwysedd rhwng galluoedd/gofynion y busnes a'r rhagolygon ar gyfer gweithredu a chynnal y llwybr a ddewiswyd. .
PS
Darllenwch hefyd ar ein blog:
- «";
- «";
- «» (o Red Hat);
- «'.
Ffynhonnell: hab.com