Kubernetes වෙත යෙදුමක් සංක්‍රමණය කරන විට දේශීය ගොනු

Kubernetes භාවිතයෙන් CI/CD ක්‍රියාවලියක් ගොඩනඟන විට, සමහර විට නව යටිතල ව්‍යුහයේ අවශ්‍යතා සහ එයට මාරු කරන යෙදුම අතර නොගැලපීම පිළිබඳ ගැටළුව පැන නගී. විශේෂයෙන්, යෙදුම් ගොඩනැගීමේ අදියරේදී එය ලබා ගැනීම වැදගත් වේ один භාවිතා කරනු ලබන රූපය всех ව්යාපෘති පරිසරයන් සහ පොකුරු. මෙම මූලධර්මය නිවැරදි යටින් පවතී Google අනුව බහාලුම් කළමනාකරණය (මේ ගැන එක් වරකට වඩා කිව්වා සහ අපගේ තාක්ෂණික දෙපාර්තමේන්තුව).

කෙසේ වෙතත්, වෙබ් අඩවියේ කේතය සූදානම් කළ රාමුවක් භාවිතා කරන අවස්ථාවන්හිදී ඔබට කිසිවෙකු නොපෙනේ, එය තවදුරටත් භාවිතා කිරීම සඳහා සීමාවන් පනවයි. “සාමාන්‍ය පරිසරයක” මෙය සමඟ කටයුතු කිරීමට පහසු වන අතර, Kubernetes හි මෙම හැසිරීම ගැටලුවක් බවට පත්විය හැකිය, විශේෂයෙන් ඔබ එය පළමු වරට හමු වූ විට. නව නිපැයුම් මනසකට බැලූ බැල්මට පැහැදිලිව පෙනෙන හෝ හොඳ යැයි පෙනෙන යටිතල පහසුකම් විසඳුම් ඉදිරිපත් කළ හැකි අතර, බොහෝ අවස්ථාවන්හිදී කළ හැකි සහ කළ යුතු බව මතක තබා ගැනීම වැදගත්ය. වාස්තු විද්‍යාත්මකව විසඳන්න.

පොකුරක් ක්රියාත්මක කිරීමේදී අප්රසන්න ප්රතිවිපාකවලට තුඩු දිය හැකි ගොනු ගබඩා කිරීම සඳහා ජනප්රිය විසඳුම් විසඳුම් දෙස බලමු, එසේම වඩාත් නිවැරදි මාර්ගයක් පෙන්වා දෙන්න.

ස්ථිතික ගබඩාව

නිදර්ශනය කිරීම සඳහා, රූප, මෝස්තර සහ වෙනත් දේවල් කට්ටලයක් ලබා ගැනීම සඳහා යම් ආකාරයක ස්ථිතික උත්පාදකයක් භාවිතා කරන වෙබ් යෙදුමක් සලකා බලන්න. උදාහරණයක් ලෙස, Yii PHP රාමුවට අනන්‍ය නාමාවලි නාම ජනනය කරන බිල්ට් වත්කම් කළමණාකරුවෙකු ඇත. ඒ අනුව, ප්‍රතිදානය යනු ස්ථිතික අඩවිය සඳහා පැහැදිලිවම එකිනෙක ඡේදනය නොවන මාර්ග සමූහයකි (මෙය හේතු කිහිපයක් නිසා සිදු කරන ලදී - නිදසුනක් ලෙස, බහු සංරචක එකම සම්පත භාවිතා කරන විට අනුපිටපත් ඉවත් කිරීමට). එබැවින්, කොටුවෙන් පිටත, ඔබ ප්‍රථම වරට වෙබ් සම්පත් මොඩියුලයකට ප්‍රවේශ වූ විට, ස්ථිතික ගොනු (ඇත්ත වශයෙන්ම, බොහෝ විට සිම්ලින්ක්, නමුත් පසුව වැඩි විස්තර) මෙම යෙදවීම සඳහා අනන්‍ය වූ පොදු මූල නාමාවලියක් සමඟ පිහිටුවා ඇත:

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

පොකුරක් අනුව මෙයින් අදහස් කරන්නේ කුමක්ද?

සරලම උදාහරණය

ස්ථිතික දත්ත බෙදා හැරීමට සහ සරල ඉල්ලීම් ක්‍රියාවට නැංවීමට PHP nginx විසින් පෙර කරන විට, තරමක් පොදු අවස්ථාවක් ගනිමු. පහසුම ක්රමය - යෙදවීම බහාලුම් දෙකක් සමඟ:

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

සරල කළ ආකාරයෙන්, nginx වින්‍යාසය පහත දක්වා පහත වැටේ:

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

ඔබ මුලින්ම අඩවියට පිවිසෙන විට, වත්කම් PHP කන්ටේනරය තුළ දිස්වේ. නමුත් එක් පොඩ් එකක් තුළ ඇති බහාලුම් දෙකක් සම්බන්ධයෙන්, nginx මෙම ස්ථිතික ගොනු ගැන කිසිවක් නොදනී, ඒවා (වින්‍යාසයට අනුව) ලබා දිය යුතුය. එහි ප්‍රතිඵලයක් වශයෙන්, CSS සහ JS ගොනු සඳහා වන සියලුම ඉල්ලීම් සඳහා සේවාලාභියා 404 දෝෂයක් දකිනු ඇත. මෙහි ඇති සරලම විසඳුම වනුයේ බහාලුම් සඳහා පොදු නාමාවලියක් සංවිධානය කිරීමයි. ප්රාථමික විකල්පය - සාමාන්ය 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

දැන් කන්ටේනරය තුළ ජනනය කරන ලද ස්ථිතික ගොනු nginx විසින් නිවැරදිව සපයනු ලැබේ. නමුත් මෙය ප්‍රාථමික විසඳුමක් බව මම ඔබට මතක් කරමි, එයින් අදහස් කරන්නේ එය පරමාදර්ශී නොවන අතර එහි සූක්ෂ්මතා සහ අඩුපාඩු ඇති අතර ඒවා පහත සාකච්ඡා කෙරේ.

වඩා දියුණු ගබඩා

පරිශීලකයෙකු වෙබ් අඩවියට පිවිසි, බහාලුම්වල ඇති මෝස්තර සහිත පිටුවක් පටවා, ඔහු මෙම පිටුව කියවන අතරතුර, අපි කන්ටේනරය නැවත යෙදවූ තත්වයක් දැන් සිතන්න. වත්කම් නාමාවලිය හිස් වී ඇති අතර නව ඒවා උත්පාදනය කිරීම ආරම්භ කිරීමට PHP වෙත ඉල්ලීමක් අවශ්‍ය වේ. කෙසේ වෙතත්, මෙයින් පසුව පවා, පැරණි ස්ථිතික වෙත සබැඳි අනදාල වනු ඇත, එය ස්ථිතික පෙන්වීමේ දෝෂ වලට තුඩු දෙනු ඇත.

ඊට අමතරව, අපට බොහෝ විට වැඩි හෝ අඩුවෙන් පටවන ලද ව්‍යාපෘතියක් ඇත, එයින් අදහස් වන්නේ යෙදුමේ එක් පිටපතක් ප්‍රමාණවත් නොවන බවයි:

• අපි එය පරිමාණය කරමු යෙදවීම අනුපිටපත් දෙකක් දක්වා.
• වෙබ් අඩවියට ප්‍රථම වරට ප්‍රවේශ වූ විට, වත්කම් එක් අනුරුවකින් නිර්මාණය විය.
• යම් අවස්ථාවක, දෙවන අනුරුව වෙත ඉල්ලීමක් යැවීමට ඇතුල්වීම (බර සමතුලිත කිරීමේ අරමුණු සඳහා) තීරණය කළ අතර, මෙම වත්කම් තවමත් නොතිබුණි. එහෙමත් නැත්නම් අපි පාවිච්චි කරන නිසා ඒවා දැන් නැහැ RollingUpdate සහ මේ මොහොතේ අපි යෙදවීම සිදු කරමින් සිටිමු.

පොදුවේ ගත් කල, ප්රතිඵලය නැවතත් වැරදියි.

පැරණි වත්කම් අහිමි වීම වළක්වා ගැනීම සඳහා, ඔබට වෙනස් කළ හැකිය emptyDir මත hostPath, පොකුරු නෝඩයකට ස්ථිතික භෞතිකව එකතු කිරීම. මෙම ප්රවේශය නරකයි, මන්ද අපට ඇත්ත වශයෙන්ම සිදු විය යුතුය නිශ්චිත පොකුරු නෝඩයකට බැඳෙන්න ඔබගේ යෙදුම, මක්නිසාද - වෙනත් නෝඩ් වෙත යාමේදී - නාමාවලියෙහි අවශ්‍ය ගොනු අඩංගු නොවේ. නැතහොත් නෝඩ් අතර යම් ආකාරයක පසුබිම් නාමාවලියක් සමමුහුර්ත කිරීම අවශ්ය වේ.

විසඳුම් මොනවාද?

1. දෘඩාංග සහ සම්පත් ඉඩ දෙන්නේ නම්, ඔබට භාවිතා කළ හැකිය cephfs ස්ථිතික අවශ්‍යතා සඳහා සමානව ප්‍රවේශ විය හැකි නාමාවලියක් සංවිධානය කිරීමට. නිල ලියකියවිලි SSD ධාවකයන්, අවම වශයෙන් තුන් ගුණයකින් අනුකරණය කිරීම සහ පොකුරු නෝඩ් අතර ස්ථාවර "ඝන" සම්බන්ධතාවයක් නිර්දේශ කරයි.
2. අඩු ඉල්ලුමක් ඇති විකල්පයක් වනුයේ NFS සේවාදායකයක් සංවිධානය කිරීමයි. කෙසේ වෙතත්, එවිට ඔබ වෙබ් සේවාදායකයේ ඉල්ලීම් සැකසීම සඳහා ප්‍රතිචාර දැක්වීමේ කාලය වැඩි කිරීම සැලකිල්ලට ගත යුතු අතර, වැරදි ඉවසීම අපේක්ෂා කිරීමට බොහෝ දේ ඉතිරි කරයි. අසාර්ථක වීමේ ප්‍රතිවිපාක ව්‍යසනකාරී ය: කන්ද නැතිවීම අහසට වේගයෙන් දිවෙන LA භාරයේ පීඩනය යටතේ පොකුර මරණයට පත් කරයි.

වෙනත් දේ අතර, ස්ථීර ගබඩා කිරීම සඳහා සියලු විකල්ප අවශ්ය වනු ඇත පසුබිම පිරිසිදු කිරීම යම් කාල සීමාවක් තුළ එකතු වූ යල් පැන ගිය ගොනු කට්ටල. PHP සහිත බහාලුම් ඉදිරිපිට ඔබට තැබිය හැකිය DaemonSet සීමිත කාලයක් සඳහා වත්කම්වල පිටපත් ගබඩා කරන nginx හැඹිලියෙන්. මෙම හැසිරීම භාවිතයෙන් පහසුවෙන් වින්යාසගත කළ හැකිය proxy_cache තැටි අවකාශය දින හෝ ගිගාබයිට් ගබඩා ගැඹුර සමග.

ඉහත සඳහන් කළ බෙදා හරින ලද ගොනු පද්ධති සමඟ මෙම ක්‍රමය ඒකාබද්ධ කිරීම පරිකල්පනය සඳහා විශාල ක්ෂේත්‍රයක් සපයයි, එය ක්‍රියාත්මක කරන සහ සහාය දෙන අයගේ අයවැය සහ තාක්ෂණික හැකියාවන්ගෙන් පමණක් සීමා වේ. අත්දැකීමෙන්, පද්ධතිය සරල වන තරමට එය ක්‍රියා කරන බව අපට පැවසිය හැකිය. එවැනි ස්ථර එකතු කළ විට, යටිතල පහසුකම් නඩත්තු කිරීම වඩාත් අපහසු වන අතර, ඒ සමඟම ඕනෑම අසාර්ථකත්වය හඳුනා ගැනීමට සහ යථා තත්ත්වයට පත් කිරීමට ගත කරන කාලය වැඩි වේ.

නිර්දේශය

යෝජිත ගබඩා විකල්පයන් ක්‍රියාත්මක කිරීම ද ඔබට අසාධාරණ ලෙස පෙනේ නම් (සංකීර්ණ, මිල අධික ...), එවිට අනෙක් පැත්තෙන් තත්වය දෙස බැලීම වටී. එනම්, ව්‍යාපෘති ගෘහ නිර්මාණ ශිල්පය හාරා ගැනීමට සහ කේතයේ ඇති ගැටළුව විසඳන්න, රූපයේ යම් ස්ථිතික දත්ත ව්‍යුහයකට බැඳී ඇත, රූප එකලස් කිරීමේ අදියරේදී වත්කම් "උණුසුම් කිරීම" සහ/හෝ පූර්ව සම්පාදනය සඳහා අන්තර්ගතය හෝ ක්‍රියා පටිපාටිය පිළිබඳ පැහැදිලි අර්ථ දැක්වීමකි. මේ ආකාරයෙන් අපට නියත වශයෙන්ම පුරෝකථනය කළ හැකි හැසිරීම් සහ සියලු පරිසරයන් සහ ධාවනය වන යෙදුමේ අනුරූ සඳහා එකම ගොනු කට්ටලයක් ලැබේ.

අපි Yii රාමුව සමඟ නිශ්චිත උදාහරණයට ආපසු ගොස් එහි ව්‍යුහය (ලිපියේ අරමුණ නොවේ) ගැන සොයා නොබලන්නේ නම්, ජනප්‍රිය ප්‍රවේශයන් දෙකක් පෙන්වා දීමට එය ප්‍රමාණවත් වේ:

1. වත්කම් පුරෝකථනය කළ හැකි ස්ථානයක තැබීමට රූපය ගොඩනැගීමේ ක්‍රියාවලිය වෙනස් කරන්න. වැනි දිගු වල මෙය යෝජිත/ක්‍රියාත්මක වේ yii2-ස්ථිතික වත්කම්.
2. e.g හි සාකච්ඡා කර ඇති පරිදි වත්කම් නාමාවලි සඳහා නිශ්චිත හැෂ් නිර්වචනය කරන්න. මෙම ඉදිරිපත් කිරීම (විනිවිදක අංක 35 සිට ආරම්භ වේ). මාර්ගය වන විට, වාර්තාවේ කතුවරයා අවසානයේ (සහ හේතුවක් නොමැතිව නොවේ!) උපදෙස් දෙන්නේ ගොඩනැගීමේ සේවාදායකයේ වත්කම් එකලස් කිරීමෙන් පසු ඒවා මධ්‍යම ගබඩාවකට (S3 වැනි) උඩුගත කරන ලෙසයි, එය ඉදිරියෙන් CDN එකක් තබන්න.

භාගත කිරීම

යෙදුමක් Kubernetes පොකුරකට සංක්‍රමණය කිරීමේදී අනිවාර්යයෙන්ම ක්‍රියාත්මක වන තවත් අවස්ථාවක් වන්නේ ගොනු පද්ධතිය තුළ පරිශීලක ගොනු ගබඩා කිරීමයි. උදාහරණයක් ලෙස, අපට නැවතත් PHP යෙදුමක් තිබේ, එය උඩුගත කිරීමේ පෝරමයක් හරහා ගොනු පිළිගන්නා, ක්‍රියාත්මක වන විට ඒවා සමඟ යමක් කර ආපසු යවයි.

Kubernetes හි, මෙම ගොනු තැබිය යුතු ස්ථානය යෙදුමේ සියලුම අනුරූ සඳහා පොදු විය යුතුය. යෙදුමේ සංකීර්ණත්වය සහ මෙම ලිපිගොනු වල නොනැසී පැවතීම සංවිධානය කිරීමේ අවශ්‍යතාවය මත පදනම්ව, ඉහත සඳහන් කළ හවුල් උපාංග විකල්පයන් එවැනි ස්ථානයක් විය හැකි නමුත්, අප දකින පරිදි, ඒවායේ අඩුපාඩු තිබේ.

නිර්දේශය

එක විසඳුමක් තමයි S3-අනුකූල ආචයනය භාවිතා කරමින් (එය minio වැනි ස්වයං-සත්කාරක කාණ්ඩයක් වුවද). S3 වෙත මාරු වීමට වෙනස්කම් අවශ්ය වනු ඇත කේත මට්ටමින්, සහ ඉදිරි අන්තයේ අන්තර්ගතය බෙදා හරින ආකාරය, අප දැනටමත් ඇත ලියා.

පරිශීලක සැසි

වෙනමම, පරිශීලක සැසි ගබඩා කිරීමේ සංවිධානය සඳහන් කිරීම වටී. බොහෝ විට මේවා තැටියේ ඇති ගොනු ද වන අතර, Kubernetes හි සන්දර්භය තුළ පරිශීලකයාගේ ඉල්ලීම වෙනත් බහාලුමකින් අවසන් වුවහොත් ඔහුගෙන් නිරන්තර අවසර ඉල්ලීම් වලට තුඩු දෙනු ඇත.

සක්‍රිය කිරීමෙන් ගැටළුව අර්ධ වශයෙන් විසඳනු ලැබේ stickySessions ඇතුල්වීම මත (සියලුම ජනප්‍රිය ඇතුල්වීමේ පාලකයන් තුළ විශේෂාංගය සඳහා සහය දක්වයි - වැඩි විස්තර සඳහා, බලන්න අපගේ සමාලෝචනය)යෙදුම සමඟ පරිශීලකයා නිශ්චිත පොඩ් එකකට බැඳීමට:

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

නමුත් මෙය නැවත නැවත යෙදවීම සමඟ ගැටළු ඉවත් නොකරනු ඇත.

නිර්දේශය

වඩාත් නිවැරදි ක්රමයක් වනුයේ අයදුම්පත මාරු කිරීමයි memcached, Redis සහ සමාන විසඳුම්වල සැසි ගබඩා කිරීම - පොදුවේ, ගොනු විකල්ප සම්පූර්ණයෙන්ම අත්හැර දමන්න.

නිගමනය

පෙළෙහි සාකච්ඡා කර ඇති යටිතල පහසුකම් විසඳුම් තාවකාලික "කිහිලිකරු" ආකෘතියෙන් පමණක් භාවිතා කිරීමට සුදුසු වේ (එය ඉංග්‍රීසි භාෂාවෙන් වඩාත් අලංකාර ලෙස පෙනේ). යෙදුමක් Kubernetes වෙත සංක්‍රමණය කිරීමේ පළමු අදියරේදී ඒවා අදාළ විය හැකි නමුත් මුල් බැස නොගත යුතුය.

සාමාන්‍ය නිර්දේශිත මාර්ගය වන්නේ බොහෝ දෙනා දැනටමත් දන්නා දේට අනුකූලව යෙදුමේ වාස්තුවිද්‍යාත්මක වෙනස් කිරීම් සඳහා ඒවායින් මිදීමයි. 12-සාධක යෙදුම. කෙසේ වෙතත්, මෙය - යෙදුම අස්ථායී පෝරමයකට ගෙන ඒම - අනිවාර්යයෙන්ම කේතයේ වෙනස්කම් අවශ්‍ය වනු ඇති අතර, මෙහිදී ව්‍යාපාරයේ හැකියාවන්/අවශ්‍යතා සහ තෝරාගත් මාර්ගය ක්‍රියාත්මක කිරීම සහ පවත්වාගෙන යාමේ අපේක්ෂාවන් අතර සමතුලිතතාවයක් සොයා ගැනීම වැදගත් වේ. .

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• «nginx භාවිතයෙන් AWS S3 වෙතින් ගොනු ප්‍රොක්සි කිරීම»;
• «Google අනුව බහාලුම් භාවිතා කිරීම සඳහා හොඳම භාවිතයන් 7 ක්»;
• «බහාලුම් පාදක යෙදුම් සැලසුම් කිරීම සඳහා 7 මූලධර්ම» (Red Hat වෙතින්);
• «7 Factor යෙදුමේ නැතිවූ සාධක 12ක්".

මූලාශ්රය: www.habr.com