Wann Dir e CI / CD-Prozess mam Kubernetes baut, entsteet heiansdo de Problem vun der Inkompatibilitéit tëscht den Ufuerderunge vun der neier Infrastruktur an der Applikatioun déi op se transferéiert gëtt. Besonnesch an der Applikatiounsbaustadium ass et wichteg ze kréien один Bild dat benotzt gëtt всех Projet Ëmfeld a Cluster. Dëse Prinzip ënnersträicht déi richteg Containermanagement (méi wéi eemol iwwer dëst an eisen techneschen Departement).
Wéi och ëmmer, Dir gesitt keen an Situatiounen wou de Code vum Site e fäerdege Kader benotzt, d'Benotzung vun deem Restriktiounen op seng weider Notzung setzt. A wann an engem "normalen Ëmfeld" dëst einfach ze këmmeren ass, an Kubernetes kann dëst Verhalen e Problem ginn, besonnesch wann Dir et fir d'éischte Kéier begéint. Wärend en inventive Geescht mat Infrastrukturléisungen ka kommen, déi op den éischte Bléck offensichtlech oder souguer gutt schéngen ... et ass wichteg ze erënneren datt déi meescht Situatioune kënnen a sollen architektonesch geléist ginn.
Loosst eis déi populär Ëmgéigend Léisunge kucken fir Dateien ze späicheren, déi zu onsympathesche Konsequenze kënne féieren wann Dir e Cluster bedreift, an och e méi korrekte Wee weisen.
Statesch Stockage
Fir ze illustréieren, betruecht eng Webapplikatioun déi eng Aart vu statesche Generator benotzt fir eng Rei vu Biller, Stiler an aner Saachen ze kréien. Zum Beispill huet de Yii PHP Kader en agebaute Verméigenmanager deen eenzegaarteg Verzeichnisnimm generéiert. Deementspriechend ass d'Ausgab eng Rei vu Weeër fir de statesche Site, déi selbstverständlech net matenee kräizen (dëst gouf aus verschiddene Grënn gemaach - zum Beispill fir Duplikater ze eliminéieren wann verschidde Komponenten déiselwecht Ressource benotzen). Also, aus der Këscht, déi éischte Kéier wann Dir op e Webressource Modul zougitt, ginn statesch Dateien (tatsächlech dacks Symlinks, awer méi spéit) geformt a mat engem gemeinsame Root-Verzeichnis eenzegaarteg fir dës Deployment ausgeluecht:
-
webroot/assets/2072c2df/css/… -
webroot/assets/2072c2df/images/… -
webroot/assets/2072c2df/js/…
Wat heescht dat am Sënn vun engem Cluster?
Am einfachsten Beispill
Loosst eis e relativ heefegste Fall huelen, wann PHP vun nginx viraus ass fir statesch Donnéeën ze verdeelen an einfach Ufroen ze veraarbecht. Deen einfachste Wee - Détachement mat zwee Container:
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.confAn enger vereinfachter Form kacht d'nginx Config op déi folgend:
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;
}
}
Wann Dir fir d'éischt op de Site zougitt, erschéngen Verméigen am PHP Container. Awer am Fall vun zwee Container an engem Pod, weess nginx näischt iwwer dës statesch Dateien, déi (no der Konfiguratioun) hinnen solle ginn. Als Resultat gesäit de Client e 404 Fehler fir all Ufro un CSS- a JS-Dateien. Déi einfachst Léisung hei wier e gemeinsame Verzeechnes fir Container ze organiséieren. Primitiv Optioun - allgemeng 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.confElo statesch Dateien, déi am Container generéiert ginn, gi vum nginx korrekt zerwéiert. Awer loosst mech Iech drun erënneren datt dëst eng primitiv Léisung ass, dat heescht datt et wäit vun ideal ass an seng eegen Nuancen a Mängel huet, déi hei ënnen diskutéiert ginn.
Méi fortgeschratt Stockage
Stellt Iech elo eng Situatioun vir, wou e Benotzer de Site besicht huet, eng Säit gelueden huet mat de Stiler, déi am Container verfügbar sinn, a wärend hien dës Säit gelies huet, hu mir de Container nei ofgebaut. De Verméigenkatalog ass eidel ginn an eng Ufro un PHP ass erfuerderlech fir nei ze generéieren. Wéi och ëmmer, och duerno, Linken op al Statik wäerten irrelevant sinn, wat zu Feeler beim Affichage vun der Statik féiert.
Zousätzlech hu mir héchstwahrscheinlech e méi oder manner gelueden Projet, dat heescht datt eng Kopie vun der Applikatioun net genuch ass:
- Loosst eis et opbauen Détachement bis zu zwee Repliken.
- Wann de Site fir d'éischt zougänglech war, goufen Verméigen an enger Replik erstallt.
- Irgendwann huet d'Ingress decidéiert (fir Laaschtbalancéierungszwecker) eng Ufro un déi zweet Replica ze schécken, an dës Verméigen waren nach net do. Oder vläicht sinn se net méi do well mir benotzen
RollingUpdatean de Moment maache mir Deployment.
Am Allgemengen ass d'Resultat erëm Feeler.
Ze vermeiden al Verméigen Verléierer, Dir kënnt änneren emptyDir op hostPath, derbäi statesch kierperlech zu engem Cluster Node. Dës Approche ass schlecht, well mer eigentlech mussen un engem spezifesche Cluster Node binden Är Applikatioun, well - am Fall vun Plënneren op aner Wirbelen - de Verzeechnes wäert net déi néideg Fichieren enthalen. Oder eng Aart vun Hannergrond Verzeechnes Synchroniséierung tëscht Noden ass erfuerderlech.
Wat sinn d'Léisungen?
- Wann Hardware a Ressourcen erlaben, kënnt Dir benotzen fir eng gläich zougänglech Verzeechnes fir statesch Bedierfnesser z'organiséieren. recommandéiert SSD fiert, op d'mannst dräifach Replikatioun an eng stabil "déck" Verbindung tëscht Cluster Wirbelen.
- Eng manner exigent Optioun wier en NFS Server z'organiséieren. Wéi och ëmmer, da musst Dir déi méiglech Erhéijung vun der Äntwertzäit fir d'Veraarbechtung vun Ufroe vum Webserver berücksichtegen, a Feeler Toleranz léisst vill ze wënschen. D'Konsequenze vum Echec si katastrophal: de Verloscht vum Mount veruerteelt de Cluster zum Doud ënner dem Drock vun der LA Laascht, déi an den Himmel rennt.
Ënner anerem all Optiounen fir eng persistent Lagerung erfuerderen Hannergrond Botzen verouderte Sätz vu Dateien, déi iwwer eng gewëssen Zäit accumuléiert sinn. Virun Container mat PHP kënnt Dir setzen DaemonSet aus Caching nginx, déi Kopien vun Verméigen fir eng limitéiert Zäit späichert. Dëst Verhalen ass einfach konfiguréierbar benotzt proxy_cache mat Späicherdéift an Deeg oder gigabytes Disk Space.
D'Kombinatioun vun dëser Methode mat den uewe genannte verdeelte Dateiesystemer bitt e grousst Feld fir Fantasi, limitéiert nëmme vum Budget an dem technesche Potenzial vun deenen, déi et ëmsetzen an ënnerstëtzen. Aus Erfahrung kënne mir soen datt de méi einfach de System, dest méi stabil funktionnéiert et. Wann esou Schichten bäigefüügt ginn, gëtt et vill méi schwéier d'Infrastruktur z'erhalen, a gläichzäiteg gëtt d'Zäit fir d'Diagnostik an d'Erhuelung vun all Feeler erop.
Empfehlung
Wann d'Ëmsetzung vun de proposéierte Späicheroptiounen Iech och ongerechtfäerdegt schéngt (komplizéiert, deier ...), dann ass et derwäert d'Situatioun vun der anerer Säit ze kucken. Nämlech an de Projet Architektur an fixen de Problem am Code, gebonnen un e puer statesch Datestruktur am Bild, eng eendeiteg Definitioun vum Inhalt oder Prozedur fir "Erwiermung" an / oder Precompiling Verméigen op der Bildversammlungsstadium. Op dës Manéier kréie mir absolut prévisibel Verhalen an deeselwechte Set vu Dateien fir all Ëmfeld an Repliken vun der lafender Applikatioun.
Wa mir op dat spezifescht Beispill mam Yii Kader zréckkommen an net a seng Struktur verdéiwen (wat net den Zweck vum Artikel ass), ass et genuch fir zwee populär Approche ze weisen:
- Ännert de Bildbauprozess fir Verméigen op eng prévisibel Plaz ze placéieren. Dëst gëtt proposéiert / ëmgesat an Extensiounen wéi .
- Definéiert spezifesch Hashes fir Asset Verzeichnungen, wéi z.B. (vum Rutsch Nummer 35 un). Iwwregens, beréit den Auteur vum Bericht schlussendlech (an net ouni Grond!) datt no der Assemblée vum Verméigen um Build-Server se op eng zentrale Späicher eropluede (wéi S3), virun deem en CDN plazéiert.
Downloads
En anere Fall deen definitiv an d'Spill kënnt wann Dir eng Applikatioun an e Kubernetes Cluster migréiert ass d'Späichere vu Benotzerdateien am Dateiesystem. Zum Beispill, hu mir erëm eng PHP Applikatioun datt Fichieren duerch eng eropluede Form akzeptéiert, mécht eppes mat hinnen während Operatioun, a schéckt hinnen zréck.
A Kubernetes soll d'Plaz wou dës Dateie solle placéiert ginn fir all Repliken vun der Applikatioun gemeinsam sinn. Ofhängeg vun der Komplexitéit vun der Applikatioun an der Bedierfnes fir d'Persistenz vun dësen Dateien z'organiséieren, kënnen déi uewe genannte gemeinsame Gerätoptioune sou eng Plaz sinn, awer, wéi mir gesinn, hunn se hir Nodeeler.
Empfehlung
Eng Léisung ass benotzt S3-kompatibel Stockage (och wann et eng Aart vu selbstgehoste Kategorie wéi Minio ass). Wiessel op S3 wäert Ännerungen verlaangen um Code Niveau, a wéi Inhalt op de Frontend geliwwert gëtt, hu mir schonn .
Benotzer Sessiounen
Separat ass et derwäert op d'Organisatioun vun der Späichere vu Benotzersessiounen ze notéieren. Dacks sinn dat och Dateien op Disk, déi am Kontext vu Kubernetes zu stännegen Autorisatiounsufroe vum Benotzer féieren, wa seng Demande an engem anere Container endet.
De Problem gëtt deelweis geléist andeems Dir uschalt stickySessions op Agrëff (d'Feature gëtt an alle populäre Ingress Controller ënnerstëtzt - fir méi Detailer, kuckt )fir de Benotzer un e spezifesche Pod mat der Applikatioun ze binden:
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: /Awer dëst wäert d'Problemer mat widderholl Deployement net eliminéieren.
Empfehlung
Eng méi korrekt Manéier wier d'Applikatioun ze transferéieren op Späicheren Sessiounen a memcached, Redis an ähnlech Léisungen - am Allgemengen, komplett opginn Fichier Optiounen.
Konklusioun
D'Infrastrukturléisungen, déi am Text diskutéiert ginn, si wäertvoll ze benotzen nëmmen am Format vun temporäre "krutches" (wat méi schéin op Englesch kléngt als Léisung). Si kënne relevant sinn an den éischte Stadien vun der Migratioun vun enger Applikatioun op Kubernetes, awer sollten net root ginn.
Den allgemenge recommandéierte Wee ass se lass ze ginn zugonschte vun der architektonescher Ännerung vun der Applikatioun am Aklang mat deem wat scho vill bekannt ass . Wéi och ëmmer, dëst - d'Applikatioun an eng statelos Form ze bréngen - bedeit zwangsleefeg datt Ännerungen am Code erfuerderlech sinn, an hei ass et wichteg e Gläichgewiicht tëscht de Fäegkeeten / Ufuerderunge vum Geschäft an de Perspektiven fir d'Ëmsetzung an d'Erhale vum gewielte Wee ze fannen .
PS
Liest och op eisem Blog:
- «";
- «";
- «» (vum Red Hat);
- «".
Source: will.com