ლოკალური ფაილები აპლიკაციის Kubernetes-ში გადატანისას

Kubernetes-ის გამოყენებით CI/CD პროცესის აგებისას, ზოგჯერ ჩნდება პრობლემა ახალი ინფრასტრუქტურის მოთხოვნებსა და მასზე გადატანილ აპლიკაციას შორის შეუთავსებლობის შესახებ. კერძოდ, განაცხადის შექმნის ეტაპზე მნიშვნელოვანია მიიღოთ ერთი სურათი, რომელიც გამოყენებული იქნება ყველა პროექტის გარემო და კლასტერები. ეს პრინციპი საფუძვლად უდევს სწორს Google-ის მიხედვით კონტეინერის მართვა (ამაზე არაერთხელ ისაუბრა და ჩვენი ტექნიკური განყოფილება).

თუმცა, ვერავის ნახავთ ისეთ სიტუაციებში, როდესაც საიტის კოდი იყენებს მზა ფრეიმიკს, რომლის გამოყენება აწესებს შეზღუდვებს მის შემდგომ გამოყენებაზე. და მიუხედავად იმისა, რომ "ნორმალურ გარემოში" ადვილია ამის მოგვარება, Kubernetes-ში ეს ქცევა შეიძლება პრობლემად იქცეს, განსაკუთრებით მაშინ, როდესაც მას პირველად შეხვდებით. მიუხედავად იმისა, რომ გამომგონებელ გონებას შეუძლია მოიფიქროს ინფრასტრუქტურული გადაწყვეტილებები, რომლებიც ერთი შეხედვით აშკარად ან თუნდაც კარგი ჩანს... მნიშვნელოვანია გვახსოვდეს, რომ სიტუაციების უმეტესობას შეუძლია და უნდა გადაწყდეს არქიტექტურულად.

მოდით გადავხედოთ ფაილების შესანახად პოპულარულ გამოსავალს, რამაც შეიძლება გამოიწვიოს უსიამოვნო შედეგები კლასტერის მუშაობისას და ასევე აღვნიშნოთ უფრო სწორი გზა.

სტატიკური საცავი

საილუსტრაციოდ, განიხილეთ ვებ აპლიკაცია, რომელიც იყენებს რაიმე სახის სტატიკური გენერატორს სურათების, სტილის და სხვა ნივთების ნაკრების მისაღებად. მაგალითად, Yii PHP Framework-ს აქვს ჩაშენებული აქტივების მენეჯერი, რომელიც ქმნის უნიკალურ დირექტორიათა სახელებს. შესაბამისად, გამომავალი არის ბილიკები სტატიკური საიტისთვის, რომლებიც აშკარად არ იკვეთება ერთმანეთთან (ეს გაკეთდა რამდენიმე მიზეზის გამო - მაგალითად, დუბლიკატების აღმოსაფხვრელად, როდესაც მრავალი კომპონენტი იყენებს ერთსა და იმავე რესურსს). ასე რომ, გარედან, როდესაც პირველად შედიხართ ვებ რესურსის მოდულზე, სტატიკური ფაილები (სინამდვილეში, ხშირად სიმბოლური ბმულები, მაგრამ უფრო მოგვიანებით) იქმნება და განლაგებულია საერთო root დირექტორიაში, რომელიც უნიკალურია ამ განლაგებისთვის:

• 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 კონტეინერში. მაგრამ ერთ პოდში ორი კონტეინერის შემთხვევაში, nginx-მა არაფერი იცის ამ სტატიკური ფაილების შესახებ, რომლებიც (კონფიგურაციის მიხედვით) უნდა მიეცეს მათ. შედეგად, კლიენტი დაინახავს 404 შეცდომას CSS და JS ფაილების ყველა მოთხოვნისთვის. აქ ყველაზე მარტივი გამოსავალი იქნება კონტეინერებისთვის საერთო დირექტორიას ორგანიზება. პრიმიტიული ვარიანტი - ზოგადი 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 on hostPath, ფიზიკურად სტატიკური დამატება კასეტური კვანძისთვის. ეს მიდგომა ცუდია, რადგან რეალურად გვიწევს მიბმა კონკრეტულ კლასტერულ კვანძთან თქვენი აპლიკაცია, რადგან - სხვა კვანძებში გადასვლის შემთხვევაში - დირექტორია არ შეიცავს საჭირო ფაილებს. ან საჭიროა რაიმე სახის ფონის დირექტორიას სინქრონიზაცია კვანძებს შორის.

რა არის გადაწყვეტილებები?

1. თუ აპარატურა და რესურსები იძლევა საშუალებას, შეგიძლიათ გამოიყენოთ ცეფფს სტატიკური საჭიროებისთვის თანაბრად ხელმისაწვდომი დირექტორიას ორგანიზება. ოფიციალური დოკუმენტაცია გირჩევთ SSD დისკებს, მინიმუმ სამჯერ გამეორებას და სტაბილურ „სქელ“ კავშირს კლასტერულ კვანძებს შორის.
2. ნაკლებად მოთხოვნადი ვარიანტი იქნება NFS სერვერის ორგანიზება. ამასთან, მაშინ თქვენ უნდა გაითვალისწინოთ ვებ სერვერის მიერ მოთხოვნების დამუშავების დროს პასუხის დროის შესაძლო ზრდა და შეცდომების ტოლერანტობა სასურველს დატოვებს. წარუმატებლობის შედეგები კატასტროფულია: მთის დაკარგვა კასეტურს სიკვდილით სწირავს ცაში შემოვარდნილი LA დატვირთვის ზეწოლის ქვეშ.

სხვა საკითხებთან ერთად, საჭირო იქნება მუდმივი შენახვის შექმნის ყველა ვარიანტი ფონის გაწმენდა გარკვეული პერიოდის განმავლობაში დაგროვილი ფაილების მოძველებული ნაკრები. კონტეინერების წინ შეგიძლიათ დააყენოთ PHP DaemonSet nginx-ის ქეშირებიდან, რომელიც შეინახავს აქტივების ასლებს შეზღუდული დროით. ეს ქცევა ადვილად კონფიგურირებადია გამოყენებით proxy_cache შენახვის სიღრმით დღეებში ან გიგაბაიტი დისკზე.

ამ მეთოდის გაერთიანება ზემოხსენებულ განაწილებულ ფაილურ სისტემებთან იძლევა წარმოსახვის უზარმაზარ ველს, რომელიც შემოიფარგლება მხოლოდ ბიუჯეტით და ტექნიკური პოტენციალით, ვინც განახორციელებს და მხარს დაუჭერს მას. გამოცდილებიდან შეგვიძლია ვთქვათ, რომ რაც უფრო მარტივია სისტემა, მით უფრო სტაბილურად მუშაობს. როდესაც ასეთი ფენები ემატება, ბევრად უფრო რთული ხდება ინფრასტრუქტურის შენარჩუნება და ამავდროულად იზრდება დრო, რომელიც დახარჯულია დიაგნოსტირებისა და ნებისმიერი წარუმატებლობის გამოსწორებაზე.

რეკომენდაცია

თუ შემოთავაზებული შენახვის ვარიანტების განხორციელებაც გაუმართლებლად გეჩვენებათ (რთული, ძვირი...), მაშინ ღირს სიტუაციის მეორე მხრიდან შეხედვა. კერძოდ, პროექტის არქიტექტურაში ჩაძირვა და დააფიქსირეთ პრობლემა კოდში, მიბმული სურათზე სტატიკურ მონაცემთა სტრუქტურასთან, შიგთავსის ან პროცედურის ცალსახა განმარტება „გახურებისთვის“ და/ან აქტივების წინასწარ შედგენისთვის გამოსახულების აწყობის ეტაპზე. ამ გზით ჩვენ ვიღებთ აბსოლუტურად პროგნოზირებად ქცევას და ფაილების ერთსა და იმავე კომპლექტს ყველა გარემოსთვის და გაშვებული აპლიკაციის ასლისთვის.

თუ კონკრეტულ მაგალითს დავუბრუნდებით Yii ჩარჩოთი და არ ჩავუღრმავდებით მის სტრუქტურას (რაც არ არის სტატიის მიზანი), საკმარისია აღვნიშნოთ ორი პოპულარული მიდგომა:

1. შეცვალეთ გამოსახულების შექმნის პროცესი, რათა განათავსოთ აქტივები პროგნოზირებად ადგილას. ეს არის შემოთავაზებული/დანერგილი გაფართოებებში, როგორიცაა yii2-სტატიკური-აქტივები.
2. განსაზღვრეთ კონკრეტული ჰეშები აქტივების დირექტორიებისთვის, როგორც ეს განხილულია მაგ. ამ პრეზენტაციას (დაწყებული სლაიდ No35-დან). სხვათა შორის, ანგარიშის ავტორი საბოლოოდ (და არა უსაფუძვლოდ!) გვირჩევს, რომ build სერვერზე აქტივების აწყობის შემდეგ, ატვირთოთ ისინი ცენტრალურ საცავში (როგორც S3), რომლის წინ მოათავსეთ CDN.

ჩამოტვირთვადი ფაილები

კიდევ ერთი შემთხვევა, რომელიც აუცილებლად გამოვა აპლიკაციის Kubernetes კლასტერში გადატანისას, არის მომხმარებლის ფაილების ფაილურ სისტემაში შენახვა. მაგალითად, ჩვენ კვლავ გვაქვს PHP აპლიკაცია, რომელიც იღებს ფაილებს ატვირთვის ფორმის საშუალებით, აკეთებს მათთან რაღაცას ოპერაციის დროს და აგზავნის მათ უკან.

Kubernetes-ში, მდებარეობა, სადაც ეს ფაილები უნდა განთავსდეს, უნდა იყოს საერთო აპლიკაციის ყველა ასლისთვის. აპლიკაციის სირთულიდან და ამ ფაილების მდგრადობის ორგანიზების საჭიროებიდან გამომდინარე, ზემოაღნიშნული საერთო მოწყობილობის ვარიანტები შეიძლება იყოს ასეთი ადგილი, მაგრამ, როგორც ვხედავთ, მათ აქვთ ნაკლოვანებები.

რეკომენდაცია

ერთი გამოსავალი არის S3-თან თავსებადი მეხსიერების გამოყენებით (თუნდაც ეს არის ერთგვარი თვითმასპინძელი კატეგორია, როგორიცაა minio). 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

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ფაილების პროქსირება AWS S3-დან nginx-ის გამოყენებით";
• «კონტეინერების გამოყენების 7 საუკეთესო პრაქტიკა Google-ის მიხედვით";
• «კონტეინერზე დაფუძნებული აპლიკაციების დიზაინის 7 პრინციპი» (წითელი ქუდისგან);
• «7 დაკარგული ფაქტორი 12 ფაქტორის აპლიკაციაში".

წყარო: www.habr.com