အပလီကေးရှင်းတစ်ခု Kubernetes သို့ ပြောင်းရွှေ့သည့်အခါ ဒေသတွင်းဖိုင်များ

Kubernetes ကို အသုံးပြု၍ CI/CD လုပ်ငန်းစဉ်ကို တည်ဆောက်သည့်အခါ၊ အခြေခံအဆောက်အအုံအသစ်၏ လိုအပ်ချက်များနှင့် ၎င်းထံသို့ လွှဲပြောင်းပေးသည့် အပလီကေးရှင်းတို့အကြား လိုက်ဖက်မှုမရှိသည့် ပြဿနာ ဖြစ်ပေါ်လာတတ်သည်။ အထူးသဖြင့်၊ လျှောက်လွှာတည်ဆောက်မှုအဆင့်တွင်၎င်းသည်ရယူရန်အရေးကြီးသည်။ один အသုံးပြုမယ့်ပုံ всех ပရောဂျက်ပတ်ဝန်းကျင်များနှင့် အစုအဝေးများ။ ဤနိယာမသည် မှန်ကန်မှုကို အခြေခံသည်။ Google အရ ကွန်တိန်နာစီမံခန့်ခွဲမှု (ဤအကြောင်းကို တစ်ကြိမ်ထက်မက ဟုပြောသည် ကျွန်ုပ်တို့၏နည်းပညာဌာန)။

သို့သော်၊ ဝဘ်ဆိုက်၏ကုဒ်သည် အဆင်သင့်လုပ်ထားသော မူဘောင်ကို အသုံးပြုသည့် အခြေအနေမျိုးတွင်၊ ၎င်း၏နောက်ထပ်အသုံးပြုမှုအပေါ် ကန့်သတ်ချက်များချမှတ်ထားသည့် အသုံးပြုမှုကို သင်တွေ့လိမ့်မည်မဟုတ်ပါ။ “သာမန်ပတ်ဝန်းကျင်” တွင် ၎င်းကိုကိုင်တွယ်ရလွယ်ကူသော်လည်း Kubernetes တွင် ဤအပြုအမူသည် အထူးသဖြင့် သင်ပထမဆုံးအကြိမ်ကြုံတွေ့ရသောအခါတွင် ပြဿနာဖြစ်လာနိုင်သည်။ တီထွင်ဆန်းသစ်သောစိတ်သည် ပထမတစ်ချက်တွင် သိသာထင်သာမြင်သာသော သို့မဟုတ် ကောင်းမွန်သည့်အခြေခံအဆောက်အအုံဆိုင်ရာဖြေရှင်းချက်များကို ရရှိနိုင်သော်လည်း အခြေအနေအများစုသည် တတ်နိုင်သရွေ့လုပ်ဆောင်နိုင်သည်ကို သတိရရန်အရေးကြီးပါသည်။ ဗိသုကာပညာဖြင့် ဖြေရှင်းရမည်။.

အစုအဝေးတစ်ခုလည်ပတ်သည့်အခါ မနှစ်မြို့ဖွယ်အကျိုးဆက်များဖြစ်ပေါ်လာနိုင်သည့် ဖိုင်များသိမ်းဆည်းခြင်းအတွက် လူကြိုက်များသည့်ဖြေရှင်းနည်းများကို ကြည့်ကြစို့၊ နှင့် ပိုမိုမှန်ကန်သောလမ်းကြောင်းကိုလည်း ညွှန်ပြကြပါစို့။

Static storage

ရုပ်ပုံများ၊ စတိုင်များနှင့် အခြားအရာများကို ရယူရန် static generator တစ်မျိုးမျိုးကို အသုံးပြုသည့် ဝဘ်အပလီကေးရှင်းကို သရုပ်ဖော်ရန် စဉ်းစားပါ။ ဥပမာအားဖြင့်၊ Yii PHP framework တွင် ထူးခြားသော directory အမည်များကိုထုတ်ပေးသည့် built-in asset manager တစ်ခုရှိသည်။ ထို့ကြောင့်၊ output သည် တစ်ခုနှင့်တစ်ခု မဖြတ်မတောက်နိုင်သော static site အတွက် လမ်းကြောင်းများ အစုအဝေးတစ်ခုဖြစ်သည် (၎င်းကို အကြောင်းအမျိုးမျိုးကြောင့် လုပ်ဆောင်ခဲ့သည် - ဥပမာ၊ အစိတ်အပိုင်းများစွာသည် အရင်းအမြစ်တစ်ခုတည်းကို အသုံးပြုသောအခါ ထပ်နေသောများကို ဖယ်ရှားရန်)။ ထို့ကြောင့်၊ သင်သည် ဝဘ်အရင်းအမြစ် မော်ဂျူးကို ပထမဆုံးဝင်ရောက်သည့်အခါ၊ တည်ငြိမ်သောဖိုင်များ (တကယ်တော့ မကြာခဏဆိုသလို symlinks များဖြစ်သော်လည်း နောက်ပိုင်းတွင် နောက်ထပ်အရာများ) ကို ဖွဲ့စည်းကာ ဤအသုံးချမှုအတွက် ထူးခြားသော ဘုံ root directory တစ်ခုဖြင့် ခင်းကျင်းထားသည်-

• 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 config သည် အောက်ပါအတိုင်း ပြုတ်သွားသည် ။

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 သည် ၎င်းတို့အား (ဖွဲ့စည်းပုံအရ) ပေးသင့်သည့် ဤ static ဖိုင်များအကြောင်း ဘာမှမသိပါ။ ရလဒ်အနေဖြင့်၊ client သည် CSS နှင့် JS ဖိုင်များသို့ တောင်းဆိုမှုအားလုံးအတွက် 404 error ကိုတွေ့လိမ့်မည်။ ဤနေရာတွင် အရိုးရှင်းဆုံးဖြေရှင်းချက်မှာ containers အတွက် common directory တစ်ခုကို စုစည်းရန်ဖြစ်သည်။ ပဏာမရွေးချယ်မှု - အထွေထွေ 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 သို့ တောင်းဆိုချက်တစ်ခု လိုအပ်ပါသည်။ သို့သော်လည်း ယင်းနောက်ပိုင်းတွင်ပင်၊ statics အဟောင်းများသို့ လင့်ခ်များသည် မသက်ဆိုင်တော့ဘဲ၊ ၎င်းသည် statics ကိုပြသရာတွင် အမှားအယွင်းများဖြစ်စေသည်။

ထို့အပြင်၊ ကျွန်ုပ်တို့တွင် တင်နိုင်သော ပရောဂျက်တစ်ခု ရှိနိုင်သည်၊ ဆိုလိုသည်မှာ အပလီကေးရှင်း၏ မိတ္တူတစ်ခုသည် မလုံလောက်ပါ-

• အဲဒါကို စကေးချကြည့်ရအောင် ဖြန့်ကျက် ပုံတူနှစ်ခုအထိ။
• ဆိုက်ကို ပထမဆုံးဝင်ရောက်သောအခါ၊ ပိုင်ဆိုင်မှုများကို ပုံစံတူတစ်ခုဖြင့် ဖန်တီးခဲ့သည်။
• တစ်ချိန်ချိန်တွင်၊ ingress သည် ဒုတိယပုံတူသို့ တောင်းဆိုချက်တစ်ခု ပေးပို့ရန် (ဝန်ချိန်ချိန်ခွင်လျှာ ရည်ရွယ်ချက်များအတွက်) ဆုံးဖြတ်ခဲ့ပြီး ဤပိုင်ဆိုင်မှုများ မရှိသေးပါ။ ဒါမှမဟုတ် ငါတို့သုံးနေတဲ့အတွက် အဲဒါတွေမရှိတော့ဘူးလား RollingUpdate လောလောဆယ်တော့ ကျနော်တို့ တပ်ဖြန့်မှုတွေ လုပ်နေတယ်။

ယေဘူယျအားဖြင့် ရလဒ်က အမှားတွေ ထပ်ဖြစ်ပြန်တယ်။

ပစ္စည်းဟောင်းများ ဆုံးရှုံးခြင်းမှ ရှောင်ရှားရန် သင်သည် ပြောင်းလဲနိုင်သည်။ emptyDir အပေါ် hostPath၊ တည်ငြိမ်သော ရုပ်ပိုင်းဆိုင်ရာ အစုအဝေးတစ်ခုသို့ ပေါင်းထည့်ခြင်း။ ဒီချဉ်းကပ်မှုဟာ ကျွန်တော်တို့ တကယ်လုပ်ရမှာဖြစ်လို့ မကောင်းပါဘူး။ သီးခြား cluster node တစ်ခုသို့ ချိတ်ဆက်ပါ။ အကြောင်းမှာ သင်၏ အက်ပ်လီကေးရှင်းသည် အခြား node များသို့ ပြောင်းရွှေ့ပါက၊ လမ်းညွှန်တွင် လိုအပ်သော ဖိုင်များ ပါဝင်မည်မဟုတ်သောကြောင့် ဖြစ်သည်။ သို့မဟုတ် node များကြားတွင် နောက်ခံလမ်းညွှန်ချက်အချို့ကို ထပ်တူပြုခြင်း လိုအပ်ပါသည်။

ဖြေရှင်းချက်တွေက ဘာတွေလဲ။

1. ဟာ့ဒ်ဝဲနှင့် အရင်းအမြစ်များကို ခွင့်ပြုပါက သင်အသုံးပြုနိုင်ပါသည်။ cephfs static လိုအပ်ချက်များအတွက် အညီအမျှ အသုံးပြုနိုင်သော လမ်းညွှန်တစ်ခုကို စုစည်းရန်။ တရားဝင်စာရွက်စာတမ်း SSD drives များ၊ အနည်းဆုံး သုံးဆ အတုယူရန်နှင့် အစုအစည်းများကြားတွင် တည်ငြိမ်သော "ထူသော" ချိတ်ဆက်မှုကို အကြံပြုပါသည်။
2. တောင်းဆိုမှုနည်းပါးသောရွေးချယ်မှုမှာ NFS ဆာဗာတစ်ခုအား စုစည်းရန်ဖြစ်သည်။ သို့သော်၊ ထို့နောက် ဝဘ်ဆာဗာမှ တောင်းဆိုမှုများကို လုပ်ဆောင်ရန်အတွက် ဖြစ်နိုင်ခြေရှိသော တုံ့ပြန်မှု တိုးလာမှုကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပြီး အမှားခံနိုင်မှုမှာ လိုချင်စရာများစွာ ကျန်ရှိနေမည်ဖြစ်သည်။ ကျရှုံးခြင်း၏အကျိုးဆက်များမှာ ကပ်ဆိုးကြီးဖြစ်သည်- တောင်၏ဆုံးရှုံးမှုသည် LA ၏တိုက်ခိုက်မှုအောက်တွင် ကောင်းကင်သို့အဟုန်းဟုန်းတောက်ကာ အစုလိုက်အပြုံလိုက်သေဆုံးသွားစေသည်။

အခြားအရာများထဲတွင်၊ မြဲမြံသောသိုလှောင်မှုဖန်တီးရန်အတွက် ရွေးချယ်စရာများအားလုံး လိုအပ်မည်ဖြစ်သည်။ နောက်ခံသန့်ရှင်းရေး အချိန်ကာလတစ်ခုအတွင်း စုဆောင်းထားသော ဖိုင်တွဲများ ခေတ်မမီတော့ပါ။ PHP ဖြင့် container များရှေ့တွင် သင်ထည့်နိုင်သည်။ DaemonSet ပိုင်ဆိုင်မှုမိတ္တူများကို အချိန်အကန့်အသတ်ဖြင့် သိမ်းဆည်းထားမည့် caching nginx မှ။ ဤအပြုအမူကို အသုံးပြု၍ အလွယ်တကူ ပြင်ဆင်သတ်မှတ်နိုင်သည်။ proxy_cache သိုလှောင်မှုအတိမ်အနက်ဖြင့် ရက်များ သို့မဟုတ် ဒစ်ခ်နေရာ၏ ဂစ်ဂါဘိုက်။

အထက်ဖော်ပြပါ ဖြန့်ဝေထားသော ဖိုင်စနစ်များနှင့် ဤနည်းလမ်းကို ပေါင်းစပ်ခြင်းဖြင့် ၎င်းကို အကောင်အထည်ဖော်မည့်သူများ၏ ဘတ်ဂျက်နှင့် နည်းပညာဆိုင်ရာ အလားအလာများဖြင့်သာ ကန့်သတ်ထားသောကြောင့် စိတ်ကူးစိတ်သန်းအတွက် နယ်ပယ်ကြီးတစ်ခုဖြစ်သည်။ အတွေ့အကြုံအရ၊ စနစ်ပိုမိုရိုးရှင်းလေ၊ တည်ငြိမ်လေလေ အလုပ်လုပ်လေလေဟု ကျွန်ုပ်တို့ပြောနိုင်သည်။ ထိုသို့သောအလွှာများကို ထည့်သွင်းသောအခါတွင် အခြေခံအဆောက်အအုံကို ထိန်းသိမ်းရန်မှာ ပိုမိုခက်ခဲလာပြီး တစ်ချိန်တည်းတွင် ချို့ယွင်းချက်တစ်ခုခုမှ ပြန်လည်ရယူခြင်းအတွက် အသုံးပြုသည့်အချိန်သည်လည်း တိုးလာပါသည်။

ထောက်ခံချက်

အဆိုပြုထားသည့် သိုလှောင်မှုရွေးချယ်စရာများကို အကောင်အထည်ဖော်ခြင်းသည် သင့်အတွက် တရားမျှတမှုမရှိဟု ထင်ပါက (ရှုပ်ထွေးသည်၊ စျေးကြီးသည်...)၊ ထို့နောက် အခြားဘက်ခြမ်းမှ အခြေအနေကို ကြည့်ရကျိုးနပ်ပါသည်။ ပြောရရင် ပရောဂျက်ဗိသုကာနဲ့ တူးတယ်။ ကုဒ်တွင်ပြဿနာကိုဖြေရှင်းပါ။ပုံရှိ တည်ငြိမ်သောဒေတာဖွဲ့စည်းပုံအချို့နှင့် ချိတ်ဆက်ထားသော၊ "ပူနွေးလာသည်" အတွက် အကြောင်းအရာများ သို့မဟုတ် လုပ်ထုံးလုပ်နည်းများ၏ မရှင်းလင်းသော အဓိပ္ပါယ်ဖွင့်ဆိုချက်နှင့်/သို့မဟုတ် ဓါတ်ပုံစုစည်းမှုအဆင့်တွင် ပိုင်ဆိုင်မှုများကို ကြိုတင်စုစည်းခြင်း။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် လုံးဝ ခန့်မှန်းနိုင်သော အပြုအမူနှင့် ပတ်ဝန်းကျင်အားလုံးအတွက် တူညီသော ဖိုင်တွဲများနှင့် လုပ်ဆောင်နေသည့် အပလီကေးရှင်း၏ ပုံတူများကို ရရှိမည်ဖြစ်သည်။

Yii မူဘောင်ဖြင့် သီးခြားဥပမာသို့ ပြန်သွားကာ ၎င်း၏ဖွဲ့စည်းပုံကို (ဆောင်းပါး၏ရည်ရွယ်ချက်မဟုတ်သော) ထဲထဲဝင်ဝင်မလေ့လာပါက၊ လူကြိုက်များသောချဉ်းကပ်နည်းနှစ်ခုကို ထောက်ပြရန် လုံလောက်ပါသည်။

1. ခန့်မှန်းနိုင်သော တည်နေရာတစ်ခုတွင် ပိုင်ဆိုင်မှုများကို နေရာချထားရန် ပုံတည်ဆောက်မှုလုပ်ငန်းစဉ်ကို ပြောင်းလဲပါ။ ၎င်းကို ကဲ့သို့သော တိုးချဲ့မှုများတွင် အကြံပြု/အကောင်အထည်ဖော်ထားသည်။ yii2-static-ပိုင်ဆိုင်မှုများ.
2. ဥပမာ တွင် ဆွေးနွေးထားသည့်အတိုင်း ပိုင်ဆိုင်မှုလမ်းညွှန်များအတွက် သီးခြား hash များကို သတ်မှတ်ပါ။ ဤတင်ပြချက် (လျှောအမှတ် ၃၅) မှ စတင်သည်။ စကားမစပ်၊ နောက်ဆုံးတွင် အစီရင်ခံစာရေးသားသူသည် (အကြောင်းပြချက်မရှိဘဲမဟုတ်ပါ!) တည်ဆောက်ထားသောဆာဗာတွင် ပိုင်ဆိုင်မှုများကို စုစည်းပြီးနောက် CDN တစ်ခု၏ရှေ့တွင် ဗဟိုသိုလှောင်မှု (S35 ကဲ့သို့) သို့ အပ်လုဒ်လုပ်ရန် အကြံပြုထားသည်။

ဒေါင်းလုဒ်များ

အက်ပလီကေးရှင်းကို Kubernetes အစုအဝေးသို့ ပြောင်းရွှေ့သည့်အခါတွင် အမှန်တကယ်ပါဝင်လာမည့် နောက်ထပ်ကိစ္စတစ်ခုမှာ ဖိုင်စနစ်တွင် အသုံးပြုသူဖိုင်များကို သိမ်းဆည်းခြင်းဖြစ်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် ဖိုင်များကို အပ်လုဒ်ပုံစံဖြင့် လက်ခံကာ၊ လည်ပတ်နေစဉ်အတွင်း ၎င်းတို့နှင့် တစ်ခုခုလုပ်ဆောင်ကာ ၎င်းတို့ကို ပြန်လည်ပေးပို့သည့် PHP အပလီကေးရှင်းတစ်ခု ထပ်မံရှိသည်။

Kubernetes တွင်၊ ဤဖိုင်များကို ထားရှိသင့်သည့် တည်နေရာသည် အပလီကေးရှင်း၏ ပုံတူများအားလုံးအတွက် ဖြစ်သင့်သည်။ အပလီကေးရှင်း၏ ရှုပ်ထွေးမှုနှင့် ဤဖိုင်များ၏ တည်မြဲမှုကို စုစည်းရန် လိုအပ်မှုအပေါ်မူတည်၍ အထက်ဖော်ပြပါ မျှဝေထားသော စက်ရွေးချယ်မှုများသည် ထိုသို့သောနေရာတစ်ခု ဖြစ်နိုင်သော်လည်း ကျွန်ုပ်တို့မြင်ရသည့်အတိုင်း ၎င်းတို့တွင် ၎င်းတို့၏ အားနည်းချက်များရှိသည်။

ထောက်ခံချက်

ဖြေရှင်းချက်တစ်ခုဖြစ်သည်။ S3-သဟဇာတသိုလှောင်မှုအသုံးပြုခြင်း။ (၎င်းသည် minio ကဲ့သို့သော ကိုယ်တိုင်လက်ခံကျင်းပသည့် အမျိုးအစားအချို့ဖြစ်လျှင်ပင်)။ S3 သို့ပြောင်းခြင်းသည် အပြောင်းအလဲများ လိုအပ်ပါမည်။ ကုဒ်အဆင့်မှာမည်ကဲ့သို့ အကြောင်းအရာကို ရှေ့ဆုံးတွင် ပေးပို့မည်နည်း၊ ကျွန်ုပ်တို့တွင် ရှိနှင့်ပြီးဖြစ်သည်။ ရေးသားခဲ့သည်.

အသုံးပြုသူ အစည်းအဝေးများ

သီးခြားအားဖြင့်၊ အသုံးပြုသူ sessions များ၏သိုလှောင်မှုအဖွဲ့အစည်းကိုသတိပြုသင့်သည်။ မကြာခဏဆိုသလို ၎င်းတို့သည် ဒစ်ခ်ပေါ်ရှိ ဖိုင်များဖြစ်ကြသည်၊ ၎င်းသည် Kubernetes ၏အခြေအနေတွင် ၎င်း၏တောင်းဆိုချက်သည် အခြားကွန်တိန်နာတစ်ခုတွင်အဆုံးသတ်ပါက အသုံးပြုသူထံမှ အဆက်မပြတ်ခွင့်ပြုချက်တောင်းခံမှုများကို ဖြစ်ပေါ်စေမည်ဖြစ်သည်။

ပြဿနာကို ဖွင့်ထားခြင်းဖြင့် တစ်စိတ်တစ်ပိုင်း ဖြေရှင်းနိုင်သည်။ stickySessions ingress အပေါ် (အင်္ဂါရပ်ကို လူကြိုက်များသော ingress controllers များအားလုံးတွင် ပံ့ပိုးထားသည် - အသေးစိတ်အချက်အလက်များအတွက် ကြည့်ပါ။ ကျွန်ုပ်တို့၏သုံးသပ်ချက်)အသုံးပြုသူကို အပလီကေးရှင်းဖြင့် သီးခြား pod တစ်ခုသို့ ချိတ်ရန်-

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 နှင့် အလားတူဖြေရှင်းချက်များတွင် sessions များကို သိမ်းဆည်းခြင်း။ - ယေဘုယျအားဖြင့်၊ ဖိုင်ရွေးချယ်ခွင့်များကို လုံးဝစွန့်လွှတ်ပါ။

ကောက်ချက်

စာသားတွင် ဆွေးနွေးထားသော အခြေခံအဆောက်အအုံဆိုင်ရာ ဖြေရှင်းချက်များသည် ယာယီ “ချိုင်းထောက်” ပုံစံဖြင့်သာ အသုံးပြုထိုက်သည် (ဖြေရှင်းနည်းအဖြစ် အင်္ဂလိပ်လို ပိုလှသည်)။ အက်ပ်ကို Kubernetes သို့ ပြောင်းရွှေ့ခြင်း၏ ပထမအဆင့်တွင် ၎င်းတို့သည် သက်ဆိုင်ရာဖြစ်နိုင်သော်လည်း root မလုပ်သင့်ပါ။

ယေဘူယျအကြံပြုထားသောလမ်းကြောင်းမှာ လူအများသိထားပြီးဖြစ်သည့်အတိုင်း လျှောက်လွှာ၏ဗိသုကာပြုပြင်မွမ်းမံခြင်းအား ဖယ်ရှားရန်ဖြစ်သည်။ 12-အချက် အက်ပ်. သို့သော်၊ ဤသည်မှာ - လျှောက်လွှာကို နိုင်ငံမဲ့ပုံစံသို့ ယူဆောင်လာခြင်း - ကုဒ်အပြောင်းအလဲများ လိုအပ်မည်ဟု မလွဲမသွေဆိုလိုသည်၊ ဤနေရာတွင် လုပ်ငန်း၏ စွမ်းဆောင်ရည်/လိုအပ်ချက်များနှင့် ရွေးချယ်ထားသောလမ်းကြောင်းကို အကောင်အထည်ဖော်ရန်နှင့် ထိန်းသိမ်းရန်အတွက် အလားအလာများအကြား ချိန်ခွင်လျှာကို ရှာဖွေရန် အရေးကြီးပါသည်။ .

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «nginx ကို အသုံးပြု၍ AWS S3 မှ ဖိုင်များကို ပရောက်စီပေးခြင်း";
• «Google အရ ကွန်တိန်နာအသုံးပြုခြင်းအတွက် အကောင်းဆုံးအလေ့အကျင့် 7 ခု";
• «ကွန်တိန်နာအခြေခံ အပလီကေးရှင်းများ ဒီဇိုင်းရေးဆွဲခြင်းအတွက် အခြေခံမူ ၇ ချက်» (Red Hat မှ);
• «7 Factor App တွင် ပျောက်ဆုံးနေသော အချက် ၇ ချက်"။

source: www.habr.com