مقامي فائلون جڏهن ڪوبرنيٽس ڏانهن ايپليڪيشن لڏڻ

جڏهن Kubernetes استعمال ڪندي هڪ CI/CD پروسيس ٺاهي رهيا آهن، ڪڏهن ڪڏهن مسئلو پيدا ٿئي ٿو نئين انفراسٽرڪچر جي ضرورتن جي وچ ۾ مطابقت ۽ ايپليڪيشن ان کي منتقل ڪيو وڃي. خاص طور تي، ايپليڪيشن جي تعمير واري مرحلي ۾ اهو حاصل ڪرڻ ضروري آهي один تصوير جيڪا استعمال ڪئي ويندي всех پروجيڪٽ ماحول ۽ ڪلستر. اهو اصول صحيح جي بنياد تي آهي گوگل جي مطابق ڪنٽينر جو انتظام (هن بابت هڪ ڀيرو کان وڌيڪ ڳالهايو ۽ اسان جي ٽيڪنيڪل ڊپارٽمينٽ).

بهرحال، توهان ڪنهن کي به حالتن ۾ نه ڏسندا جتي سائيٽ جو ڪوڊ هڪ تيار ڪيل فريم ورڪ استعمال ڪري ٿو، جنهن جو استعمال ان جي وڌيڪ استعمال تي پابنديون لاڳو ڪري ٿو. ۽ جڏهن "عام ماحول" ۾ اهو معاملو ڪرڻ آسان آهي، 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 ڪنٽينر ۾. پر هڪ پوڊ اندر ٻن ڪنٽينرز جي صورت ۾، نينڪس انهن جامد فائلن جي باري ۾ ڪجھ به نه ڄاڻي ٿو، جيڪي (ترتيب جي مطابق) انهن کي ڏنو وڃي. نتيجي طور، ڪلائنٽ 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 پاران صحيح طور تي. پر مان توهان کي ياد ڏيان ٿو ته اهو هڪ ابتدائي حل آهي، جنهن جو مطلب آهي ته اهو مثالي کان پري آهي ۽ ان جي پنهنجي nuances ۽ گهٽتائي آهي، جنهن هيٺ بحث ڪيو ويندو.

وڌيڪ ترقي يافته اسٽوريج

ھاڻي ھڪڙي صورتحال جو تصور ڪريو جتي ھڪڙو صارف سائيٽ جو دورو ڪيو، ڪنٽينر ۾ موجود اسلوب سان ھڪڙو صفحو لوڊ ڪيو، ۽ جڏھن ھو ھي صفحو پڙھي رھيو ھو، اسان ڪنٽينر کي ٻيهر ترتيب ڏنو. اثاثن جي فهرست خالي ٿي چڪي آهي ۽ PHP کي هڪ درخواست گهربل آهي نئين ٺاهڻ شروع ڪرڻ لاءِ. بهرحال، ان کان پوءِ به، پراڻن انگن اکرن سان ڳنڍڻ غير لاڳاپيل هوندا، جنهن ڪري شماريات کي ظاهر ڪرڻ ۾ غلطيون ٿينديون.

ان کان علاوه، اسان وٽ گهڻو ڪري هڪ وڌيڪ يا گهٽ لوڊ ٿيل منصوبو آهي، جنهن جو مطلب آهي ته ايپليڪيشن جي هڪ ڪاپي ڪافي نه هوندي:

• اچو ته ان کي وڌايو رنيجرز ٻن نقلن تائين.
• جڏهن سائيٽ پهرين پهچ هئي، اثاثا ٺاهيا ويا هڪ نقل ۾.
• ڪجهه نقطي تي، داخل ٿيڻ جو فيصلو ڪيو (لوڊ بيلنس جي مقصدن لاءِ) ٻي ريپليڪا ڏانهن درخواست موڪلڻ لاءِ، ۽ اهي اثاثا اڃا تائين موجود نه هئا. يا شايد اهي هاڻي نه آهن ڇو ته اسان استعمال ڪندا آهيون RollingUpdate ۽ هن وقت اسان ڪم ڪري رهيا آهيون.

عام طور تي، نتيجو ٻيهر غلطي آهي.

پراڻي اثاثن کي وڃائڻ کان بچڻ لاء، توهان تبديل ڪري سگهو ٿا emptyDir تي hostPath، جامد جسماني طور تي ڪلستر نوڊ ۾ شامل ڪرڻ. اهو طريقو خراب آهي ڇو ته اسان کي اصل ۾ ڪرڻو پوندو هڪ مخصوص ڪلستر نوڊ تي پابند توهان جي ايپليڪيشن، ڇاڪاڻ ته - ٻين نوڊس ڏانهن منتقل ٿيڻ جي صورت ۾ - ڊاريڪٽري ۾ ضروري فائلون شامل نه هونديون. يا نوڊس جي وچ ۾ ڪجهه قسم جي پس منظر ڊاريڪٽري هم وقت سازي جي ضرورت آهي.

حل ڪهڙا آهن؟

1. جيڪڏهن هارڊويئر ۽ وسيلن جي اجازت ڏيو، توهان استعمال ڪري سگهو ٿا ڪيفف جامد ضرورتن لاءِ برابر رسائي واري ڊاريڪٽري کي منظم ڪرڻ لاءِ. سرڪاري دستاويز سفارش ڪري ٿو ايس ايس ڊي ڊرائيو، گهٽ ۾ گهٽ ٽي ڀيرا نقل ۽ ڪلستر نوڊس جي وچ ۾ هڪ مستحڪم "ٿلهي" ڪنيڪشن.
2. هڪ گهٽ گهربل اختيار هڪ NFS سرور کي منظم ڪرڻ لاء هوندو. جڏهن ته، پوءِ توهان کي ويب سرور طرفان درخواستن جي پروسيسنگ لاءِ جوابي وقت ۾ ممڪن اضافو کي نظر ۾ رکڻو پوندو، ۽ غلطي رواداري گهڻو ڪجهه ڇڏي ويندي جيڪا گهربل هجي. ناڪامي جا نتيجا تباهي وارا آهن: جبل جي ضايع ٿيڻ سان ڪلستر کي موت ڏانهن ڌڪيندو آهي LA لوڊ جي دٻاءُ هيٺ آسمان ڏانهن وڌي رهيو آهي.

ٻين شين مان، مسلسل اسٽوريج ٺاهڻ لاء سڀني اختيارن جي ضرورت هوندي پس منظر جي صفائي فائلن جا پراڻا سيٽ هڪ خاص عرصي دوران گڏ ڪيا ويا. PHP سان ڪنٽينرز جي سامهون توهان رکي سگهو ٿا ڊيمون سيٽ ڪيچنگ nginx کان، جيڪو محدود وقت لاءِ اثاثن جون ڪاپيون محفوظ ڪندو. اهو رويو استعمال ڪندي آساني سان ترتيب ڏئي سگهجي ٿو proxy_cache ڏينهن ۾ اسٽوريج جي کوٽائي سان يا ڊسڪ اسپيس جي گيگا بائيٽ سان.

مٿي ذڪر ڪيل ورهايل فائل سسٽم سان هن طريقي کي گڏ ڪرڻ تخيل لاءِ هڪ وڏو ميدان مهيا ڪري ٿو، صرف انهن جي بجيٽ ۽ ٽيڪنيڪل صلاحيت تائين محدود آهي جيڪي ان کي لاڳو ۽ سپورٽ ڪندا. تجربي مان، اسان اهو چئي سگهون ٿا ته سسٽم آسان، وڌيڪ مستحڪم اهو ڪم ڪري ٿو. جڏهن اهڙيون پرتون شامل ڪيون وينديون آهن، انفراسٽرڪچر کي برقرار رکڻ تمام گهڻو ڏکيو ٿي ويندو آهي، ۽ ساڳئي وقت ڪنهن به ناڪامي جي تشخيص ۽ بحالي تي خرچ ٿيل وقت وڌائي ٿو.

تجويز

جيڪڏهن تجويز ڪيل اسٽوريج اختيارن تي عمل درآمد پڻ توهان لاءِ ناانصافي لڳي ٿي (پيچيده، قيمتي ...)، پوء اهو ٻئي پاسي کان صورتحال کي ڏسڻ جي قابل آهي. يعني، پروجيڪٽ جي فن تعمير ۾ کوٽڻ ۽ ڪوڊ ۾ مسئلو حل ڪريو, تصوير ۾ ڪجهه جامد ڊيٽا جي جوڙجڪ سان ڳنڍيل آهي، مواد جي هڪ غير واضح تعريف يا "گرم اپ" ۽ / يا تصوير اسيمبلي جي اسٽيج تي اثاثن کي گڏ ڪرڻ لاء طريقيڪار. انهي طريقي سان اسان حاصل ڪندا آهيون بلڪل پيش گوئي واري رويي ۽ فائلن جو ساڳيو سيٽ سڀني ماحولن لاءِ ۽ هلندڙ ايپليڪيشن جي نقلن لاءِ.

جيڪڏهن اسان Yii فريم ورڪ سان مخصوص مثال ڏانهن واپس وڃون ٿا ۽ ان جي جوڙجڪ (جيڪو مضمون جو مقصد نه آهي) تي ڌيان نه ڏيون، اهو ڪافي آهي ته ٻه مشهور طريقا بيان ڪرڻ لاء:

1. تبديل ڪريو تصوير ٺاھڻ واري عمل کي اثاثن کي ھڪڙي اندازي واري جڳھ ۾ رکڻ لاء. هي تجويز ڪيل آهي / واڌارن ۾ لاڳو ڪيو ويو آهي جهڙوڪ yii2- جامد- اثاثو.
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 ۽ ساڳي حل - عام طور تي، مڪمل طور تي فائل اختيارن کي ڇڏي ڏيو.

ٿڪل

بنيادي ڍانچي جي حلن جو متن ۾ بحث ڪيو ويو آهي صرف استعمال جي لائق آهي عارضي ”بيچين“ جي شڪل ۾ (جيڪو انگريزيءَ ۾ وڌيڪ خوبصورت لڳي ٿو workaround). اهي ڪبرنيٽس ڏانهن ايپليڪيشن لڏڻ جي پهرين مرحلن ۾ لاڳاپيل هوندا، پر روٽ نه وٺڻ گهرجي.

عام تجويز ڪيل رستو اھو آھي انھن مان نجات حاصل ڪرڻ لاءِ ايپليڪيشن جي آرڪيٽيڪچرل ترميم جي حق ۾ جيڪي اڳ ۾ ئي ڪيترن ئي لاءِ سڃاتل آھن. 12-فيڪٽر ايپ. بهرحال، هي - ايپليڪيشن کي غير رياستي شڪل ۾ آڻڻ - لازمي طور تي مطلب اهو آهي ته ڪوڊ ۾ تبديلين جي ضرورت پوندي، ۽ هتي اهو ضروري آهي ته ڪاروبار جي صلاحيتن / ضرورتن جي وچ ۾ توازن ڳولڻ ۽ چونڊيل رستي کي لاڳو ڪرڻ ۽ برقرار رکڻ جي امڪانن جي وچ ۾. .

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «nginx استعمال ڪندي AWS S3 مان فائلن کي پراکسي ڪرڻ"؛
• «گوگل جي مطابق ڪنٽينر استعمال ڪرڻ لاءِ 7 بهترين طريقا"؛
• «ڪنٽينر تي ٻڌل ايپليڪيشنن کي ڊزائين ڪرڻ لاءِ 7 اصول» (Red Hat تان);
• «7 فيڪٽر ايپ ۾ 12 غائب عنصر».

جو ذريعو: www.habr.com