ځایی فایلونه کله چې یو غوښتنلیک Kubernetes ته لیږدول کیږي

کله چې د کوبرنیټس په کارولو سره د CI/CD پروسې رامینځته کول ، ځینې وختونه ستونزه د نوي زیربنا اړتیاو او غوښتنلیک ته د سپارلو ترمینځ د نه مطابقت له امله رامینځته کیږي. په ځانګړې توګه، د غوښتنلیک جوړولو په مرحله کې دا مهمه ده چې ترلاسه کړئ один هغه انځور چې په کې کارول کیږي всех د پروژې چاپیریال او کلسترونه. دا اصل په سمه توګه تعقیبوي د ګوګل په وینا د کانټینر مدیریت (د دې په اړه له یو ځل څخه ډیر خبرې وکړې او زموږ تخنیکي څانګه).

په هرصورت، تاسو به هیڅوک په داسې شرایطو کې ونه ګورئ چیرې چې د سایټ کوډ یو چمتو شوی چوکاټ کاروي، چې کارول یې د هغې په نورو کارولو محدودیتونه وضع کوي. او پداسې حال کې چې په "عادي چاپیریال" کې دا معامله کول اسانه دي، په کوبرنیټس کې دا چلند کولی شي ستونزه شي، په ځانګړې توګه کله چې تاسو د لومړي ځل لپاره ورسره مخ شئ. پداسې حال کې چې یو اختراعي ذهن کولی شي د زیربنا حلونو سره راشي چې په لومړي نظر کې څرګند یا حتی ښه ښکاري ... دا مهمه ده چې په یاد ولرئ چې ډیری حالتونه کولی شي او باید په معمارۍ کې حل شي.

راځئ چې د فایلونو ذخیره کولو لپاره مشهور حل حلونه وګورو چې کولی شي د کلستر چلولو پرمهال د ناخوښ پایلو لامل شي ، او نور سمه لاره هم په ګوته کړي.

جامد ذخیره

د روښانه کولو لپاره، یو ویب غوښتنلیک په پام کې ونیسئ چې د عکسونو، سټایلونو او نورو شیانو سیټ ترلاسه کولو لپاره یو ډول جامد جنریټر کاروي. د مثال په توګه، د Yii PHP چوکاټ یو جوړ شوی شتمني مدیر لري چې د ځانګړي لارښود نومونه رامینځته کوي. په دې اساس، محصول د جامد سایټ لپاره د لارو یوه مجموعه ده چې په ښکاره ډول یو له بل سره نه نښلوي (دا د ډیری دلایلو لپاره ترسره شوی - د بیلګې په توګه، د نقلونو له منځه وړل کله چې ډیری برخې ورته سرچینې کاروي). نو، د بکس څخه بهر، لومړی ځل چې تاسو د ویب سرچینې ماډل ته لاسرسی ومومئ، جامد فایلونه (په حقیقت کې، ډیری وختونه سیملنکونه، مګر وروسته نور) د دې ګمارلو لپاره د یو عام روټ ډایرکټر سره جوړ شوي او ترتیب شوي:

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

دا د کلستر په شرایطو کې څه معنی لري؟

تر ټولو ساده مثال

راځئ چې یو عادلانه عام قضیه واخلو، کله چې پی ایچ پی د جامد معلوماتو توزیع کولو او ساده غوښتنو پروسس کولو لپاره د نګینکس لخوا مخکې وي. تر ټولو اسانه لار - تعین کول د دوو کانتینرونو سره:

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

کله چې تاسو لومړی سایټ ته لاسرسی ومومئ، شتمنۍ د پی ایچ پی کانټینر کې ښکاري. مګر په یوه پوډ کې د دوه کانټینرونو په حالت کې ، نګینکس د دې جامد فایلونو په اړه هیڅ نه پوهیږي ، کوم چې (د ترتیب سره سم) باید دوی ته ورکړل شي. د پایلې په توګه، پیرودونکي به د 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

اوس په کانټینر کې رامینځته شوي جامد فایلونه د نګینکس لخوا په سمه توګه خدمت کیږي. مګر اجازه راکړئ تاسو ته یادونه وکړم چې دا یو ابتدايي حل دی، پدې معنی چې دا د مثالي څخه لرې دی او خپل نیمګړتیاوې او نیمګړتیاوې لري، کوم چې لاندې بحث کیږي.

ډیر پرمختللی ذخیره

اوس یو داسې حالت تصور کړئ چیرې چې یو کارونکي سایټ ته مراجعه کړې، په کانټینر کې د موجود سټایلونو سره یوه پاڼه پورته کړه، او پداسې حال کې چې هغه دا پاڼه لوستل، موږ کانټینر بیا ځای پرځای کړ. د شتمنیو کتلاګ خالي شوی او د نوي تولید پیل کولو لپاره PHP ته غوښتنه اړینه ده. په هرصورت، حتی له دې وروسته، د پخوانیو احصایو سره اړیکې به غیر متناسب وي، چې دا به د احصایې په ښودلو کې د غلطیو لامل شي.

سربیره پردې ، موږ ډیری احتمال د ډیر یا لږ بار شوي پروژه لرو ، پدې معنی چې د غوښتنلیک یوه کاپي به کافي نه وي:

• راځئ چې دا اندازه کړو تعین کول تر دوو نقلونو پورې.
• کله چې سایټ په لومړي ځل لاسرسی وموند، شتمنۍ په یوه نقل کې رامینځته شوې.
• په ځینو وختونو کې، ننوتل پریکړه وکړه (د بار توازن موخو لپاره) دویم نقل ته غوښتنه واستوي، او دا شتمنۍ لاهم شتون نلري. یا شاید دوی نور شتون نلري ځکه چې موږ یې کاروو RollingUpdate او دا مهال موږ ګمارنه کوو.

په عموم کې، پایله بیا غلطی دی.

د زړو شتمنیو له لاسه ورکولو څخه مخنیوي لپاره، تاسو کولی شئ بدل کړئ emptyDir په hostPathد کلستر نوډ ته په فزیکي توګه جامد اضافه کول. دا طریقه خرابه ده ځکه چې موږ واقعیا باید وکړو د ځانګړي کلستر نوډ سره تړل ستاسو غوښتنلیک، ځکه چې - نورو نوډونو ته د تګ په صورت کې - لارښود به اړین فایلونه ونه لري. یا د نوډونو ترمینځ یو ډول شالید لارښود ترکیب ته اړتیا ده.

د حل لارې څه دي؟

1. که هارډویر او سرچینې اجازه ورکړي، تاسو کولی شئ وکاروئ cephfs د جامد اړتیاو لپاره د مساوي لاسرسي وړ لارښود تنظیم کول. رسمي اسناد د SSD ډرایو وړاندیز کوي، لږترلږه درې چنده نقل او د کلستر نوډونو ترمنځ یو مستحکم "غاړ" اړیکه.
2. یو لږ غوښتنې اختیار به د NFS سرور تنظیم کول وي. په هرصورت، بیا تاسو اړتیا لرئ چې د ویب سرور لخوا د غوښتنو پروسس کولو لپاره د ځواب وخت احتمالي زیاتوالی په پام کې ونیسئ، او د غلطۍ زغم به ډیر څه پریږدي ترڅو مطلوب وي. د ناکامۍ پایلې ناورین دي: د غره له لاسه ورکول د LA بار د فشار لاندې اسمان ته د ګړندي کیدو کلستر د مرګ لامل کیږي.

د نورو شیانو په مینځ کې، د دوامداره ذخیره کولو لپاره ټول اختیارونه به اړتیا ولري د شاليد پاکول د فایلونو زاړه سیټونه د یوې ټاکلې مودې په اوږدو کې راټول شوي. د PHP سره د کانټینرونو مخې ته تاسو کولی شئ واچوئ DaemonSet د نګینکس کیچ کولو څخه، کوم چې به د محدود وخت لپاره د شتمنیو کاپي ذخیره کړي. دا چلند په اسانۍ سره د کارولو وړ دی proxy_cache په ورځو کې د ذخیره کولو ژوروالی یا ګیګابایټ ډیسک ځای سره.

د پورته ذکر شوي توزیع شوي فایل سیسټمونو سره د دې میتود ترکیب کول د تصور لپاره خورا لوی ډګر چمتو کوي ، یوازې د بودیجې او تخنیکي ظرفیت لخوا محدود دی څوک چې پلي کوي او ملاتړ کوي. د تجربې څخه، موږ کولی شو ووایو چې سیسټم ساده دی، ډیر باثباته دا کار کوي. کله چې دا ډول پرتونه اضافه شي، د زیربنا ساتل خورا ستونزمن کیږي، او په ورته وخت کې د هر ډول ناکامۍ تشخیص او بیا رغولو کې مصرف شوي وخت ډیریږي.

وړاندیز

که چیرې د وړاندیز شوي ذخیره کولو اختیارونو پلي کول هم تاسو ته غیر عادلانه ښکاري (پیچلي ، ګران ...) ، نو دا د بل اړخ څخه وضعیت ته د کتلو ارزښت لري. د بیلګې په توګه، د پروژې جوړښت ته کیندل او په کوډ کې ستونزه حل کړئ، په عکس کې د ځینې جامد ډیټا جوړښت سره تړلی ، د مینځپانګې یو مبهم تعریف یا د "تودوخې" او / یا د عکس غونډې په مرحله کې د شتمنیو دمخه تنظیم کولو لپاره طرزالعمل. پدې توګه موږ په بشپړ ډول د وړاندوینې وړ چلند ترلاسه کوو او د ټولو چاپیریالونو لپاره د فایلونو ورته سیټ او د روان غوښتنلیک عکس العملونه.

که موږ د Yii چوکاټ سره ځانګړي مثال ته راستون شو او د هغې جوړښت (کوم چې د مقالې هدف نه دی) ته پام ونه کړو ، دا کافي ده چې دوه مشهورې لارې په ګوته کړو:

1. د وړاندوینې وړ ځای کې شتمنیو ځای په ځای کولو لپاره د عکس جوړولو پروسه بدل کړئ. دا په تمدیدونو کې وړاندیز شوی / پلي کیږي لکه yii2-static-assets.
2. د اثاثو لارښودونو لپاره ځانګړي هشونه تعریف کړئ ، لکه څنګه چې بحث شوی د مثال په توګه دا پریزنټشن (د 35 شمیرې سلایډ څخه پیل کیږي). په هرصورت ، د راپور لیکوال په نهایت کې (او پرته له کوم دلیل نه!) مشوره ورکوي چې په جوړ سرور کې د شتمنیو راټولولو وروسته ، دوی مرکزي ذخیره (لکه S3) ته اپلوډ کړئ ، د کوم په مخ کې چې CDN ځای په ځای کړي.

د ډاونلوډ وړ فایلونه

بله قضیه چې یقینا به په عمل کې راشي کله چې د کوبرنیټس کلستر ته د غوښتنلیک لیږدول د فایل سیسټم کې د کارونکي فایلونه ذخیره کول دي. د مثال په توګه، موږ بیا د PHP غوښتنلیک لرو چې د اپلوډ فارم له لارې فایلونه مني، د عملیاتو په جریان کې د دوی سره یو څه کوي، او بیرته یې لیږي.

په Kubernetes کې، هغه ځای چیرې چې دا فایلونه باید ځای په ځای شي باید د غوښتنلیک ټولو نقلونو لپاره عام وي. د غوښتنلیک پیچلتیا او د دې فایلونو دوام تنظیم کولو اړتیا پورې اړه لري ، پورته ذکر شوي شریک شوي وسیلې اختیارونه ممکن داسې ځای وي ، مګر لکه څنګه چې موږ ګورو ، دوی خپل نیمګړتیاوې لري.

وړاندیز

یو حل دی د S3 سره مطابقت لرونکی ذخیره کارول (حتی که دا د ځان کوربه شوي کټګورۍ یو ډول وي لکه مینیو). S3 ته بدلول به بدلونونو ته اړتیا ولري د کوډ په کچه، او څنګه به مینځپانګه په لومړي پای کې تحویل شي ، موږ دمخه لرو لیکلی.

د کارن ناستې

په جلا توګه، دا د کاروونکي غونډو ذخیره کولو تنظیم په پام کې نیولو سره ارزښت لري. ډیری وختونه دا په ډیسک کې فایلونه هم دي ، کوم چې د کوبرنیټس په شرایطو کې به د کارونکي څخه د دوامداره جواز غوښتنې لامل شي که چیرې د هغه غوښتنه په بل کانټینر کې پای ته ورسیږي.

ستونزه تر یوې اندازې په فعالولو سره حل کیږي 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 او ورته حلونو کې د غونډو ذخیره کول - په عموم کې ، په بشپړ ډول د فایل اختیارونه پریږدئ.

پایلې

زیربنا حلونه چې په متن کې بحث شوي یوازې د لنډمهاله "کرچچونو" په شکل کې د کارولو وړ دي (کوم چې په انګلیسي کې د کار په توګه ډیر ښکلی ښکاري). دوی ممکن د کوبرنیټس ته د غوښتنلیک مهاجرت په لومړیو مرحلو کې اړوند وي ، مګر باید ریښه ونه نیسي.

عمومي وړاندیز شوی لاره دا ده چې د غوښتنلیک د معماري ترمیم په ګټه له دوی څخه خلاصون ترلاسه کړئ د هغه څه سره سم چې دمخه ډیری خلکو ته پیژندل شوي. 12-فکتور ایپ. په هرصورت، دا - د غوښتنلیک بې ریاسته بڼه ته راوړل - حتمي معنی دا ده چې په کوډ کې بدلون ته اړتیا وي، او دلته دا مهمه ده چې د سوداګرۍ وړتیاو/اړتیاو او د غوره شوي لارې پلي کولو او ساتلو امکاناتو ترمنځ توازن ومومئ. .

PS

زموږ په بلاګ کې هم ولولئ:

• «د نګینکس په کارولو سره د AWS S3 څخه د فایلونو پراکسي کول»
• «د ګوګل په وینا د کانټینرونو کارولو لپاره 7 غوره تمرینونه»
• «د کانټینر پر بنسټ غوښتنلیکونو ډیزاین کولو لپاره 7 اصول» (د ریډ هټ څخه);
• «په 7 فکتور ایپ کې 12 ورک فاکتورونه".

سرچینه: www.habr.com