مقامی فائلیں جب کسی ایپلیکیشن کو کبرنیٹس میں منتقل کرتے ہیں۔

کبرنیٹس کا استعمال کرتے ہوئے ایک CI/CD عمل کی تعمیر کرتے وقت، بعض اوقات نئے بنیادی ڈھانچے کی ضروریات اور اس میں منتقل ہونے والی درخواست کے درمیان عدم مطابقت کا مسئلہ پیدا ہوتا ہے۔ خاص طور پر، درخواست کی تعمیر کے مرحلے میں یہ حاصل کرنا ضروری ہے ایک تصویر جس میں استعمال کیا جائے گا۔ تمام پروجیکٹ کے ماحول اور کلسٹرز۔ یہ اصول صحیح پر مبنی ہے۔ گوگل کے مطابق کنٹینر مینجمنٹ (اس بارے میں ایک سے زیادہ بار بات کی اور ہمارا تکنیکی شعبہ)۔

تاہم، آپ کسی کو ایسے حالات میں نہیں دیکھیں گے جہاں سائٹ کا کوڈ ایک ریڈی میڈ فریم ورک استعمال کرتا ہے، جس کا استعمال اس کے مزید استعمال پر پابندیاں عائد کرتا ہے۔ اور جب "عام ماحول" میں اس سے نمٹنا آسان ہوتا ہے، تو Kubernetes میں یہ رویہ ایک مسئلہ بن سکتا ہے، خاص طور پر جب آپ کا پہلی بار سامنا ہو۔ اگرچہ ایک اختراعی ذہن بنیادی ڈھانچے کے حل کے ساتھ آ سکتا ہے جو پہلی نظر میں واضح یا اس سے بھی اچھے لگتے ہیں... یہ یاد رکھنا ضروری ہے کہ زیادہ تر حالات ہو سکتے ہیں اور تعمیراتی طور پر حل کیا جائے.

آئیے فائلوں کو سٹور کرنے کے لیے مقبول حل کو دیکھتے ہیں جو کلسٹر کو چلاتے وقت ناخوشگوار نتائج کا باعث بن سکتے ہیں، اور مزید درست راستے کی نشاندہی بھی کرتے ہیں۔

جامد اسٹوریج

مثال کے طور پر، ایک ویب ایپلیکیشن پر غور کریں جو تصاویر، سٹائلز اور دیگر چیزوں کا سیٹ حاصل کرنے کے لیے کسی قسم کے جامد جنریٹر کا استعمال کرتی ہے۔ مثال کے طور پر، Yii PHP فریم ورک میں ایک بلٹ ان اثاثہ مینیجر ہے جو منفرد ڈائرکٹری کے نام تیار کرتا ہے۔ اس کے مطابق، آؤٹ پٹ جامد سائٹ کے لیے راستوں کا ایک مجموعہ ہے جو ظاہر ہے کہ ایک دوسرے کو نہیں کاٹتے ہیں (ایسا کئی وجوہات کی بنا پر کیا گیا تھا - مثال کے طور پر، جب متعدد اجزاء ایک ہی وسائل کو استعمال کرتے ہیں تو نقل کو ختم کرنا)۔ لہذا، باکس سے باہر، پہلی بار جب آپ ویب ریسورس ماڈیول تک رسائی حاصل کرتے ہیں، جامد فائلیں (حقیقت میں، اکثر سملنک، لیکن اس کے بعد اس پر مزید) اس تعیناتی کے لیے منفرد ایک مشترکہ روٹ ڈائرکٹری کے ساتھ بنتی اور رکھی جاتی ہیں:

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

کلسٹر کے لحاظ سے اس کا کیا مطلب ہے؟

سب سے آسان مثال

آئیے ایک کافی عام معاملہ لیں، جب جامد ڈیٹا کو تقسیم کرنے اور سادہ درخواستوں پر کارروائی کرنے کے لیے پی ایچ پی سے پہلے 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;
        }
    }

جب آپ پہلی بار سائٹ تک رسائی حاصل کرتے ہیں تو پی ایچ پی کنٹینر میں اثاثے ظاہر ہوتے ہیں۔ لیکن ایک پوڈ کے اندر دو کنٹینرز کی صورت میں، 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 کو نیا بنانا شروع کرنے کے لیے درخواست درکار ہے۔ تاہم، اس کے بعد بھی، پرانے سٹیٹکس کے لنکس غیر متعلقہ ہوں گے، جس کی وجہ سے سٹیٹکس کو ظاہر کرنے میں غلطیاں پیدا ہوں گی۔

اس کے علاوہ، ہمارے پاس زیادہ یا کم بھری ہوئی پروجیکٹ ہے، جس کا مطلب ہے کہ درخواست کی ایک کاپی کافی نہیں ہوگی:

• آئیے اس کو بڑھاتے ہیں۔ تعیناتی دو نقل تک۔
• جب سائٹ تک پہلی بار رسائی حاصل کی گئی تھی، اثاثے ایک نقل میں بنائے گئے تھے۔
• کسی موقع پر، ingress نے فیصلہ کیا کہ (لوڈ بیلنسنگ کے مقاصد کے لیے) دوسری ریپلیکا کو درخواست بھیجے، اور یہ اثاثے ابھی تک وہاں نہیں تھے۔ یا شاید وہ اب وہاں نہیں ہیں کیونکہ ہم استعمال کرتے ہیں۔ RollingUpdate اور اس وقت ہم تعیناتی کر رہے ہیں۔

عام طور پر، نتیجہ دوبارہ غلطیاں ہے.

پرانے اثاثوں کو کھونے سے بچنے کے لیے، آپ تبدیل کر سکتے ہیں۔ emptyDir پر hostPath، کلسٹر نوڈ میں جسمانی طور پر جامد شامل کرنا۔ یہ نقطہ نظر برا ہے کیونکہ ہمیں اصل میں کرنا ہے۔ ایک مخصوص کلسٹر نوڈ سے جڑیں۔ آپ کی درخواست، کیونکہ - دوسرے نوڈس میں جانے کی صورت میں - ڈائریکٹری میں ضروری فائلیں نہیں ہوں گی۔ یا نوڈس کے درمیان کسی قسم کی بیک گراؤنڈ ڈائرکٹری سنکرونائزیشن کی ضرورت ہے۔

حل کیا ہیں؟

1. اگر ہارڈ ویئر اور وسائل اجازت دیتے ہیں تو آپ استعمال کر سکتے ہیں۔ cephfs جامد ضروریات کے لیے یکساں طور پر قابل رسائی ڈائریکٹری ترتیب دینے کے لیے۔ سرکاری دستاویزات SSD ڈرائیوز، کم از کم تین گنا نقل اور کلسٹر نوڈس کے درمیان ایک مستحکم "موٹی" کنکشن کی سفارش کرتا ہے۔
2. این ایف ایس سرور کو منظم کرنے کا ایک کم مطالبہ اختیار ہوگا۔ تاہم، پھر آپ کو ویب سرور کے ذریعے درخواستوں پر کارروائی کرنے کے لیے جوابی وقت میں ممکنہ اضافے کو مدنظر رکھنا ہوگا، اور غلطی کی برداشت بہت زیادہ مطلوبہ چھوڑ دے گی۔ ناکامی کے نتائج تباہ کن ہیں: پہاڑ کا نقصان آسمان کی طرف بڑھنے والے ایل اے بوجھ کے دباؤ کے تحت جھرمٹ کو موت کے منہ میں ڈال دیتا ہے۔

دوسری چیزوں کے علاوہ، مستقل اسٹوریج بنانے کے لیے تمام اختیارات درکار ہوں گے۔ پس منظر کی صفائی فائلوں کے پرانے سیٹ ایک مخصوص مدت میں جمع ہوتے ہیں۔ پی ایچ پی والے کنٹینرز کے سامنے آپ رکھ سکتے ہیں۔ ڈیمون سیٹ کیشنگ nginx سے، جو محدود وقت کے لیے اثاثوں کی کاپیاں اسٹور کرے گا۔ یہ رویہ آسانی سے قابل استعمال ہے۔ proxy_cache دنوں میں ذخیرہ کرنے کی گہرائی یا گیگا بائٹس ڈسک کی جگہ کے ساتھ۔

اس طریقہ کو اوپر بیان کردہ تقسیم شدہ فائل سسٹمز کے ساتھ ملانا تخیل کے لیے ایک بہت بڑا میدان فراہم کرتا ہے، جو صرف ان لوگوں کے بجٹ اور تکنیکی صلاحیت سے محدود ہے جو اس پر عمل درآمد اور تعاون کریں گے۔ تجربے سے، ہم کہہ سکتے ہیں کہ نظام جتنا آسان ہوگا، اتنا ہی مستحکم کام کرتا ہے۔ جب اس طرح کی تہوں کو شامل کیا جاتا ہے، تو انفراسٹرکچر کو برقرار رکھنا بہت زیادہ مشکل ہو جاتا ہے، اور ساتھ ہی ساتھ کسی بھی ناکامی کی تشخیص اور بحالی پر خرچ ہونے والا وقت بڑھ جاتا ہے۔

سفارش

اگر مجوزہ اسٹوریج آپشنز کا نفاذ بھی آپ کے لیے غیر منصفانہ لگتا ہے (پیچیدہ، مہنگا...)، تو دوسری طرف سے صورت حال کو دیکھنے کے قابل ہے۔ یعنی، منصوبے کے فن تعمیر میں کھودنے کے لئے اور کوڈ میں مسئلہ کو حل کریں, تصویر میں کچھ جامد ڈیٹا ڈھانچے سے منسلک، مشمولات کی ایک غیر مبہم تعریف یا تصویر اسمبلی کے مرحلے پر "وارمنگ اپ" اور/یا اثاثوں کو پہلے سے مرتب کرنے کے طریقہ کار۔ اس طرح ہمیں تمام ماحول اور چل رہی ایپلیکیشن کی نقلوں کے لیے بالکل قابل قیاس رویہ اور فائلوں کا ایک ہی سیٹ ملتا ہے۔

اگر ہم Yii فریم ورک کے ساتھ مخصوص مثال کی طرف لوٹتے ہیں اور اس کی ساخت (جو کہ مضمون کا مقصد نہیں ہے) پر غور نہیں کرتے ہیں، تو یہ دو مقبول طریقوں کی نشاندہی کرنا کافی ہے:

1. امیج بنانے کے عمل کو تبدیل کریں تاکہ اثاثوں کو قابل قیاس مقام پر رکھا جائے۔ یہ ایکسٹینشنز میں تجویز کردہ / نافذ کیا جاتا ہے۔ yii2-static-assets.
2. اثاثہ ڈائریکٹریز کے لیے مخصوص ہیشز کی وضاحت کریں، جیسا کہ میں بحث کی گئی ہے۔ یہ پیشکش (سلائیڈ نمبر 35 سے شروع)۔ ویسے، رپورٹ کے مصنف بالآخر (اور بغیر وجہ کے نہیں!) مشورہ دیتے ہیں کہ بلڈ سرور پر اثاثے جمع کرنے کے بعد، انہیں ایک مرکزی اسٹوریج (جیسے S3) پر اپ لوڈ کریں، جس کے سامنے CDN رکھیں۔

ڈاؤن لوڈ

ایک اور کیس جو یقینی طور پر کام میں آئے گا جب کسی ایپلیکیشن کو کبرنیٹس کلسٹر میں منتقل کرنا صارف کی فائلوں کو فائل سسٹم میں اسٹور کرنا ہے۔ مثال کے طور پر، ہمارے پاس دوبارہ ایک پی ایچ پی ایپلی کیشن ہے جو اپ لوڈ فارم کے ذریعے فائلوں کو قبول کرتی ہے، آپریشن کے دوران ان کے ساتھ کچھ کرتی ہے، اور انہیں واپس بھیجتی ہے۔

Kubernetes میں، وہ مقام جہاں ان فائلوں کو رکھا جانا چاہیے وہ ایپلیکیشن کی تمام نقلوں کے لیے عام ہونا چاہیے۔ ایپلی کیشن کی پیچیدگی اور ان فائلوں کے استقامت کو منظم کرنے کی ضرورت پر منحصر ہے، اوپر بیان کردہ مشترکہ ڈیوائس کے اختیارات ایسی جگہ ہو سکتے ہیں، لیکن جیسا کہ ہم دیکھتے ہیں، ان میں اپنی خامیاں ہیں۔

سفارش

ایک حل ہے۔ S3 کے موافق اسٹوریج کا استعمال کرتے ہوئے (یہاں تک کہ اگر یہ کسی قسم کا خود میزبان زمرہ ہے جیسے منیو)۔ 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-فیکٹر ایپ. تاہم، یہ - درخواست کو بے وطن شکل میں لانا - لامحالہ اس کا مطلب ہے کہ کوڈ میں تبدیلی کی ضرورت ہوگی، اور یہاں یہ ضروری ہے کہ کاروبار کی صلاحیتوں/ضروریات اور منتخب کردہ راستے کو نافذ کرنے اور برقرار رکھنے کے امکانات کے درمیان توازن تلاش کیا جائے۔ .

PS

ہمارے بلاگ پر بھی پڑھیں:

• «nginx کا استعمال کرتے ہوئے AWS S3 سے فائلوں کو پراکسی کرنا؛ "
• «گوگل کے مطابق کنٹینرز استعمال کرنے کے 7 بہترین طریقے؛ "
• «کنٹینر پر مبنی ایپلی کیشنز کو ڈیزائن کرنے کے 7 اصول» (ریڈ ہیٹ سے);
• «7 فیکٹر ایپ میں 12 غائب عوامل'.

ماخذ: www.habr.com