কুবারনেটসে একটি অ্যাপ্লিকেশন স্থানান্তর করার সময় স্থানীয় ফাইলগুলি

Kubernetes ব্যবহার করে একটি CI/CD প্রক্রিয়া তৈরি করার সময়, কখনও কখনও নতুন পরিকাঠামোর প্রয়োজনীয়তা এবং এতে স্থানান্তরিত অ্যাপ্লিকেশনের মধ্যে অসামঞ্জস্যতার সমস্যা দেখা দেয়। বিশেষ করে, অ্যাপ্লিকেশন বিল্ড পর্যায়ে এটি পেতে গুরুত্বপূর্ণ один ইমেজ যা ব্যবহার করা হবে всех প্রকল্প পরিবেশ এবং ক্লাস্টার. এই নীতি সঠিক অন্তর্নিহিত গুগল অনুযায়ী ধারক ব্যবস্থাপনা (এ বিষয়ে একাধিকবার তিনি বলেন, এবং আমাদের প্রযুক্তিগত বিভাগ)।

যাইহোক, আপনি এমন পরিস্থিতিতে কাউকে দেখতে পাবেন না যেখানে সাইটের কোড একটি তৈরি ফ্রেমওয়ার্ক ব্যবহার করে, যার ব্যবহার এটির পরবর্তী ব্যবহারের উপর বিধিনিষেধ আরোপ করে। এবং যখন একটি "স্বাভাবিক পরিবেশে" এটি মোকাবেলা করা সহজ, কুবারনেটসে এই আচরণটি একটি সমস্যা হয়ে উঠতে পারে, বিশেষ করে যখন আপনি প্রথমবার এটির মুখোমুখি হন। যদিও একটি উদ্ভাবনী মন পরিকাঠামোগত সমাধান নিয়ে আসতে পারে যা প্রথম নজরে সুস্পষ্ট বা এমনকি ভাল বলে মনে হয়... এটা মনে রাখা গুরুত্বপূর্ণ যে বেশিরভাগ পরিস্থিতিতে হতে পারে এবং করা উচিত স্থাপত্যগতভাবে সমাধান করা.

আসুন ফাইলগুলি সংরক্ষণের জন্য জনপ্রিয় সমাধানগুলি দেখুন যা একটি ক্লাস্টার পরিচালনা করার সময় অপ্রীতিকর পরিণতির দিকে নিয়ে যেতে পারে এবং আরও সঠিক পথ নির্দেশ করে।

স্ট্যাটিক স্টোরেজ

ব্যাখ্যা করার জন্য, একটি ওয়েব অ্যাপ্লিকেশন বিবেচনা করুন যা চিত্র, শৈলী এবং অন্যান্য জিনিসগুলির একটি সেট পেতে কিছু ধরণের স্ট্যাটিক জেনারেটর ব্যবহার করে। উদাহরণস্বরূপ, 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 কনফিগারেশন নিম্নলিখিতগুলিতে ফুটে ওঠে:

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-কে একটি অনুরোধের প্রয়োজন৷ যাইহোক, এর পরেও, পুরানো স্ট্যাটিক্সের লিঙ্কগুলি অপ্রাসঙ্গিক হবে, যা স্ট্যাটিক্স প্রদর্শনে ত্রুটির কারণ হবে।

উপরন্তু, আমাদের সম্ভবত একটি কম বা কম লোড করা প্রকল্প আছে, যার মানে হল যে অ্যাপ্লিকেশনটির একটি অনুলিপি যথেষ্ট হবে না:

• এর স্কেল আপ করা যাক বিস্তৃতি দুটি প্রতিলিপি পর্যন্ত।
• যখন সাইটটি প্রথম অ্যাক্সেস করা হয়েছিল, তখন একটি প্রতিলিপিতে সম্পদ তৈরি করা হয়েছিল।
• কিছু সময়ে, ইনগ্রেস সিদ্ধান্ত নিয়েছিল (লোড ভারসাম্যের উদ্দেশ্যে) দ্বিতীয় প্রতিলিপিতে একটি অনুরোধ পাঠানোর জন্য, এবং এই সম্পদগুলি এখনও সেখানে ছিল না। অথবা হয়তো তারা আর নেই কারণ আমরা ব্যবহার করি RollingUpdate এবং এই মুহূর্তে আমরা স্থাপনা করছি।

সাধারণভাবে, ফলাফল আবার ভুল।

পুরানো সম্পদ হারানো এড়াতে, আপনি পরিবর্তন করতে পারেন emptyDir উপর hostPath, একটি ক্লাস্টার নোডে শারীরিকভাবে স্ট্যাটিক যোগ করা হচ্ছে। এই পদ্ধতি খারাপ কারণ আমরা আসলে আছে একটি নির্দিষ্ট ক্লাস্টার নোডে আবদ্ধ আপনার অ্যাপ্লিকেশন, কারণ - অন্য নোডগুলিতে যাওয়ার ক্ষেত্রে - ডিরেক্টরিতে প্রয়োজনীয় ফাইল থাকবে না। অথবা নোডগুলির মধ্যে কিছু ধরণের ব্যাকগ্রাউন্ড ডিরেক্টরি সিঙ্ক্রোনাইজেশন প্রয়োজন।

সমাধান কি?

1. হার্ডওয়্যার এবং সংস্থান অনুমতি দিলে, আপনি ব্যবহার করতে পারেন cephfs স্ট্যাটিক প্রয়োজনের জন্য সমানভাবে অ্যাক্সেসযোগ্য ডিরেক্টরি সংগঠিত করতে। অফিসিয়াল ডকুমেন্টেশন SSD ড্রাইভ, অন্তত তিনগুণ প্রতিলিপি এবং ক্লাস্টার নোডগুলির মধ্যে একটি স্থিতিশীল "পুরু" সংযোগের সুপারিশ করে।
2. একটি কম চাহিদাপূর্ণ বিকল্প একটি NFS সার্ভার সংগঠিত হবে. যাইহোক, তারপরে আপনাকে ওয়েব সার্ভারের দ্বারা অনুরোধগুলি প্রক্রিয়া করার জন্য প্রতিক্রিয়া সময়ের সম্ভাব্য বৃদ্ধি বিবেচনা করতে হবে এবং ত্রুটি সহনশীলতা পছন্দসই হতে অনেক কিছু ছেড়ে দেবে। ব্যর্থতার পরিণতিগুলি বিপর্যয়কর: মাউন্ট ডুম হারানো LA লোডের চাপে আকাশে ছুটে আসা ক্লাস্টারটিকে মৃত্যুর দিকে নিয়ে যায়।

অন্যান্য জিনিসগুলির মধ্যে, অবিরাম স্টোরেজ তৈরির জন্য সমস্ত বিকল্পের প্রয়োজন হবে পটভূমি পরিষ্কার নির্দিষ্ট সময়ের মধ্যে জমা হওয়া ফাইলের সেকেলে সেট। পিএইচপি সহ পাত্রের সামনে রাখতে পারেন ডেমনসেট ক্যাশিং nginx থেকে, যা একটি সীমিত সময়ের জন্য সম্পদের কপি সংরক্ষণ করবে। এই আচরণটি ব্যবহার করে সহজেই কনফিগার করা যায় proxy_cache দিন বা গিগাবাইট ডিস্ক স্পেস স্টোরেজ গভীরতা সঙ্গে.

উপরে উল্লিখিত বিতরণকৃত ফাইল সিস্টেমের সাথে এই পদ্ধতির সংমিশ্রণ কল্পনা করার জন্য একটি বিশাল ক্ষেত্র প্রদান করে, যারা এটি বাস্তবায়ন এবং সমর্থন করবে তাদের বাজেট এবং প্রযুক্তিগত সম্ভাবনা দ্বারা সীমাবদ্ধ। অভিজ্ঞতা থেকে, আমরা বলতে পারি যে সিস্টেমটি যত সহজ, এটি তত বেশি স্থিতিশীল কাজ করে। যখন এই ধরনের স্তরগুলি যোগ করা হয়, তখন পরিকাঠামো বজায় রাখা অনেক বেশি কঠিন হয়ে পড়ে এবং একই সময়ে যে কোনও ব্যর্থতা নির্ণয় এবং পুনরুদ্ধারের জন্য ব্যয় করা সময় বৃদ্ধি পায়।

সুপারিশ

যদি প্রস্তাবিত স্টোরেজ বিকল্পগুলির বাস্তবায়ন আপনার কাছে অযৌক্তিক বলে মনে হয় (জটিল, ব্যয়বহুল ...), তবে পরিস্থিতিটি অন্য দিক থেকে দেখার মতো। যথা, প্রকল্প স্থাপত্য মধ্যে খনন এবং কোডে সমস্যাটি ঠিক করুন, চিত্রের কিছু স্ট্যাটিক ডাটা স্ট্রাকচারের সাথে আবদ্ধ, বিষয়বস্তুর একটি দ্ব্যর্থহীন সংজ্ঞা বা "ওয়ার্মিং আপ" এবং/অথবা ইমেজ অ্যাসেম্বলি পর্যায়ে সম্পদের প্রি-কম্পাইল করার পদ্ধতি। এইভাবে আমরা সম্পূর্ণ অনুমানযোগ্য আচরণ এবং চলমান অ্যাপ্লিকেশনের সমস্ত পরিবেশ এবং প্রতিলিপিগুলির জন্য ফাইলগুলির একই সেট পাই।

যদি আমরা Yii ফ্রেমওয়ার্কের সাথে নির্দিষ্ট উদাহরণে ফিরে আসি এবং এর কাঠামোর (যা নিবন্ধের উদ্দেশ্য নয়) অনুসন্ধান না করি তবে দুটি জনপ্রিয় পন্থা নির্দেশ করা যথেষ্ট:

1. একটি অনুমানযোগ্য অবস্থানে সম্পদ স্থাপন করতে চিত্র নির্মাণ প্রক্রিয়া পরিবর্তন করুন। এটির মত এক্সটেনশনে প্রস্তাবিত/বাস্তবায়ন করা হয় yii2-স্ট্যাটিক-সম্পদ.
2. সম্পদ ডিরেক্টরির জন্য নির্দিষ্ট হ্যাশ সংজ্ঞায়িত করুন, যেমন আলোচনা করা হয়েছে এই উপস্থাপনা (স্লাইড নং 35 থেকে শুরু)। যাইহোক, প্রতিবেদনের লেখক শেষ পর্যন্ত (এবং কারণ ছাড়াই নয়!) পরামর্শ দিয়েছেন যে বিল্ড সার্ভারে সম্পদ একত্রিত করার পরে, সেগুলিকে একটি কেন্দ্রীয় স্টোরেজে (যেমন S3) আপলোড করুন, যার সামনে একটি CDN রাখুন।

ডাউনলোডযোগ্য ফাইল

একটি কুবারনেটস ক্লাস্টারে একটি অ্যাপ্লিকেশন স্থানান্তর করার সময় অন্য একটি ক্ষেত্রে যা অবশ্যই কার্যকর হবে তা হল ফাইল সিস্টেমে ব্যবহারকারীর ফাইলগুলি সংরক্ষণ করা। উদাহরণস্বরূপ, আমাদের আবার একটি পিএইচপি অ্যাপ্লিকেশন রয়েছে যা একটি আপলোড ফর্মের মাধ্যমে ফাইলগুলি গ্রহণ করে, অপারেশন চলাকালীন তাদের সাথে কিছু করে এবং সেগুলিকে ফেরত পাঠায়।

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

তবে এটি বারবার স্থাপনার সাথে সমস্যাগুলি দূর করবে না।

সুপারিশ

একটি আরো সঠিক উপায় আবেদন স্থানান্তর করা হবে মেমক্যাশেড, রেডিস এবং অনুরূপ সমাধানগুলিতে সেশন সংরক্ষণ করা - সাধারণভাবে, ফাইল বিকল্পগুলি সম্পূর্ণরূপে পরিত্যাগ করুন।

উপসংহার

টেক্সটে আলোচনা করা অবকাঠামো সমাধানগুলি শুধুমাত্র অস্থায়ী "ক্র্যাচ" এর বিন্যাসে ব্যবহার করার যোগ্য (যেটি ইংরেজিতে ওয়ার্কঅ্যারাউন্ড হিসাবে আরও সুন্দর শোনাচ্ছে)। এগুলি কুবারনেটে একটি অ্যাপ্লিকেশন স্থানান্তর করার প্রথম পর্যায়ে প্রাসঙ্গিক হতে পারে, কিন্তু রুট করা উচিত নয়।

সাধারণ প্রস্তাবিত পথ হল অ্যাপ্লিকেশনটির আর্কিটেকচারাল পরিবর্তনের পক্ষে তাদের পরিত্রাণ পেতে যা ইতিমধ্যে অনেকের কাছে পরিচিত। 12-ফ্যাক্টর অ্যাপ. যাইহোক, এটি - আবেদনটিকে একটি রাষ্ট্রহীন আকারে নিয়ে আসা - অনিবার্যভাবে এর অর্থ হল কোডে পরিবর্তনের প্রয়োজন হবে এবং এখানে ব্যবসার সক্ষমতা/প্রয়োজনীয়তা এবং নির্বাচিত পথটি বাস্তবায়ন ও বজায় রাখার সম্ভাবনার মধ্যে একটি ভারসাম্য খুঁজে পাওয়া গুরুত্বপূর্ণ। .

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «nginx ব্যবহার করে AWS S3 থেকে ফাইল প্রক্সি করা হচ্ছে";
• «Google-এর 7টি কন্টেইনার সেরা অভ্যাস";
• «কনটেইনার-ভিত্তিক অ্যাপ্লিকেশন ডিজাইন করার জন্য 7 নীতি» (রেড হ্যাট থেকে);
• «7 ফ্যাক্টর অ্যাপে 12টি অনুপস্থিত ফ্যাক্টর».

উত্স: www.habr.com