🥇Ilovani Kubernetesga ko'chirishda mahalliy fayllar

Kubernetes-dan foydalangan holda CI/CD jarayonini qurishda, ba'zida muammo yangi infratuzilma talablari va unga o'tkazilayotgan dastur o'rtasidagi nomuvofiqlik bilan bog'liq. Xususan, dasturni yaratish bosqichida uni olish muhimdir один ishlatiladigan rasm всех loyiha muhiti va klasterlari. Bu tamoyil to'g'rilikka asoslanadi Googlega ko'ra konteyner boshqaruvi (bu haqida bir necha marta gapirishdi va bizning texnik bo'limimiz).

Biroq, sayt kodi tayyor ramkadan foydalanadigan holatlarda siz hech kimni ko'rmaysiz, undan foydalanish undan keyingi foydalanishga cheklovlar qo'yadi. Va "oddiy muhitda" buni hal qilish oson bo'lsa-da, Kubernetesda bu xatti-harakat muammoga aylanishi mumkin, ayniqsa siz birinchi marta duch kelganingizda. Ixtirochi aql birinchi qarashda ravshan yoki hatto yaxshi ko‘rinadigan infratuzilma yechimlarini o‘ylab topishi mumkin bo‘lsa-da... shuni esda tutish kerakki, ko‘p vaziyatlar shunday bo‘lishi mumkin va kerak. arxitektura yo‘li bilan hal qilinadi.

Biz klasterni ishlatishda noxush oqibatlarga olib kelishi mumkin bo'lgan fayllarni saqlash uchun mashhur vaqtinchalik echimlarni tahlil qilamiz, shuningdek, yanada to'g'ri yo'lni ko'rsatamiz.

Statik saqlash

Tasavvur qilish uchun, tasvirlar, uslublar va boshqa narsalarni olish uchun qandaydir statik generatordan foydalanadigan veb-ilovani ko'rib chiqing. Masalan, Yii PHP ramkasida noyob katalog nomlarini yaratuvchi o'rnatilgan aktivlar menejeri mavjud. Shunga ko'ra, chiqish statik sayt uchun aniq bir-biri bilan kesishmaydigan yo'llar to'plamidir (bu bir necha sabablarga ko'ra qilingan - masalan, bir nechta komponentlar bir xil resursdan foydalanganda dublikatlarni yo'q qilish uchun). Shunday qilib, veb-resurs moduliga birinchi marta kirganingizda, statik fayllar (aslida, ko'pincha ramziy havolalar, lekin keyinroq) shakllanadi va ushbu joylashtirish uchun yagona bo'lgan umumiy ildiz katalogi bilan joylashtiriladi:

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

Bu klaster nuqtai nazaridan nimani anglatadi?

Eng oddiy misol

Keling, statik ma'lumotlarni tarqatish va oddiy so'rovlarni qayta ishlash uchun PHP dan oldin nginx bo'lgan juda keng tarqalgan holatni olaylik. Eng oson yo'li - Tarqatish ikkita konteyner bilan:

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

Soddalashtirilgan shaklda nginx konfiguratsiyasi quyidagilarga tushadi:

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

Saytga birinchi marta kirganingizda, aktivlar PHP konteynerida paydo bo'ladi. Ammo bitta pod ichidagi ikkita konteyner bo'lsa, nginx bu statik fayllar haqida hech narsa bilmaydi, ular (konfiguratsiyaga ko'ra) ularga berilishi kerak. Natijada, mijoz CSS va JS fayllariga bo'lgan barcha so'rovlar uchun 404 xatosini ko'radi.Bu erda eng oddiy yechim konteynerlar uchun umumiy katalogni tashkil qilish bo'ladi. Ibtidoiy variant - umumiy 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

Endi konteynerda yaratilgan statik fayllar nginx tomonidan to'g'ri xizmat qiladi. Ammo shuni eslatib o'tamanki, bu ibtidoiy yechim, ya'ni u idealdan uzoqda va quyida muhokama qilinadigan o'ziga xos nuances va kamchiliklarga ega.

Kengaytirilgan xotira

Endi vaziyatni tasavvur qiling-a, foydalanuvchi saytga tashrif buyurdi, konteynerda mavjud uslublar bilan sahifani yukladi va u ushbu sahifani o'qiyotganda, biz konteynerni qayta joylashtirdik. Aktivlar katalogi bo'sh bo'ldi va yangilarini yaratish uchun PHP ga so'rov talab qilinadi. Biroq, bundan keyin ham eski statikaga havolalar ahamiyatsiz bo'lib qoladi, bu esa statikani ko'rsatishda xatolarga olib keladi.

Bundan tashqari, bizda ko'proq yoki kamroq yuklangan loyiha bor, ya'ni dasturning bitta nusxasi etarli bo'lmaydi:

Keling, uni kengaytiraylik Tarqatish ikki nusxagacha.
Saytga birinchi marta kirishda aktivlar bitta nusxada yaratilgan.
Bir nuqtada kirish (yukni muvozanatlash uchun) ikkinchi nusxaga so'rov yuborishga qaror qildi va bu aktivlar hali yo'q edi. Yoki biz foydalanayotganimiz uchun ular endi yo'q RollingUpdate va hozirda biz joylashtirishni amalga oshirmoqdamiz.

Umuman olganda, natija yana xatolardir.

Eski aktivlarni yo'qotmaslik uchun siz o'zgartirishingiz mumkin emptyDir haqida hostPath, klaster tuguniga jismoniy statik qo'shish. Bu yondashuv yomon, chunki biz bunga majburmiz ma'lum bir klaster tuguniga bog'lash ilovangiz, chunki - boshqa tugunlarga ko'chgan taqdirda - katalogda kerakli fayllar bo'lmaydi. Yoki tugunlar o'rtasida qandaydir fon katalogini sinxronlashtirish talab qilinadi.

Yechimlar qanday?

Agar apparat va resurslar imkon bersa, siz foydalanishingiz mumkin sephfs statik ehtiyojlar uchun teng darajada foydalanish mumkin bo'lgan katalogni tashkil qilish. Rasmiy hujjatlar SSD drayverlarini, kamida uch marta takrorlashni va klaster tugunlari orasidagi barqaror "qalin" ulanishni tavsiya qiladi.
NFS serverini tashkil qilish kamroq talabchan variant bo'ladi. Biroq, keyin veb-server tomonidan so'rovlarni qayta ishlash uchun javob vaqtining mumkin bo'lgan o'sishini hisobga olishingiz kerak va nosozliklarga chidamlilik ko'p narsani orzu qiladi. Muvaffaqiyatsizlikning oqibatlari halokatli: tog'ning yo'qolishi osmonga shoshilayotgan LA yukining bosimi ostida klasterni o'limga olib keladi.

Boshqa narsalar qatorida, doimiy saqlashni yaratishning barcha variantlari talab qilinadi fonni tozalash ma'lum vaqt davomida to'plangan eskirgan fayllar to'plami. PHP bilan konteynerlar oldiga qo'yishingiz mumkin DaemonSet cheklangan vaqt davomida aktivlarning nusxalarini saqlaydigan nginx-ni keshlashdan. Ushbu xatti-harakat yordamida osongina sozlanishi mumkin proxy_cache kun yoki gigabayt disk maydonida saqlash chuqurligi bilan.

Ushbu usulni yuqorida aytib o'tilgan taqsimlangan fayl tizimlari bilan birlashtirish faqat uni amalga oshiradigan va qo'llab-quvvatlovchilarning byudjeti va texnik imkoniyatlari bilan cheklangan tasavvur uchun katta maydonni beradi. Tajribadan shuni aytishimiz mumkinki, tizim qanchalik sodda bo'lsa, u shunchalik barqaror ishlaydi. Bunday qatlamlar qo'shilsa, infratuzilmani saqlash ancha qiyinlashadi va shu bilan birga tashxis qo'yish va har qanday nosozliklarni bartaraf etishga sarflanadigan vaqt oshadi.

Tavsiya

Agar taklif qilingan saqlash variantlarini amalga oshirish sizga ham asossiz bo'lib tuyulsa (murakkab, qimmat ...), unda vaziyatga boshqa tomondan qarashga arziydi. Ya'ni, loyiha arxitekturasini qazish va koddagi muammoni hal qiling, tasvirdagi ba'zi statik ma'lumotlar tuzilmasi bilan bog'liq bo'lib, tasvirni yig'ish bosqichida "isitish" va/yoki aktivlarni oldindan kompilyatsiya qilish uchun tarkib yoki protseduraning aniq ta'rifi. Shunday qilib, biz barcha muhitlar va ishlaydigan ilovaning nusxalari uchun mutlaqo taxmin qilinadigan xatti-harakatlar va bir xil fayllar to'plamini olamiz.

Agar biz Yii ramkasi bilan aniq misolga qaytsak va uning tuzilishini o'rganmasak (bu maqolaning maqsadi emas), ikkita mashhur yondashuvni ta'kidlash kifoya:

Aktivlarni bashorat qilinadigan joyga joylashtirish uchun tasvirni yaratish jarayonini o'zgartiring. Bu kabi kengaytmalarda tavsiya etiladi/qo'llaniladi yii2-statik-aktivlar.
Aktiv kataloglari uchun maxsus xeshlarni aniqlang, masalan: ushbu taqdimot (35-sonli slayddan boshlab). Aytgancha, hisobot muallifi oxir-oqibat (va sababsiz emas!) o'rnatish serverida aktivlarni yig'gandan so'ng, ularni markaziy xotiraga (masalan, S3) yuklashni maslahat beradi, uning oldida CDN joylashadi.

Yuklab olinadigan fayllar

Ilovani Kubernetes klasteriga ko'chirishda albatta paydo bo'ladigan yana bir holat fayl tizimida foydalanuvchi fayllarini saqlashdir. Masalan, bizda yana yuklash formasi orqali fayllarni qabul qiladigan, ish paytida ular bilan biror narsa qiladigan va ularni qaytarib yuboradigan PHP ilovasi mavjud.

Kubernetesda ushbu fayllar joylashtiriladigan joy ilovaning barcha nusxalari uchun umumiy bo'lishi kerak. Ilovaning murakkabligi va ushbu fayllarning qat'iyligini tashkil qilish zarurligiga qarab, yuqorida aytib o'tilgan umumiy qurilma variantlari bunday joy bo'lishi mumkin, ammo biz ko'rib turganimizdek, ularning kamchiliklari bor.

Tavsiya

Bitta yechim S3-mos xotiradan foydalanish (hatto minio kabi o'z-o'zidan boshqariladigan toifa bo'lsa ham). S3 ga o'tish o'zgarishlarni talab qiladi kod darajasida, va kontentning old tomonida qanday yetkazilishini biz allaqachon bilib oldik yozgan.

Foydalanuvchi seanslari

Alohida-alohida, foydalanuvchi seanslarini saqlashni tashkil qilishni ta'kidlash kerak. Ko'pincha bular diskdagi fayllar bo'lib, ular Kubernetes kontekstida foydalanuvchining so'rovi boshqa konteynerda tugasa, doimiy avtorizatsiya so'rovlariga olib keladi.

Muammo qisman yoqish orqali hal qilinadi stickySessions kirishda (xususiyat barcha mashhur kirish kontrollerlarida qo'llab-quvvatlanadi - batafsil ma'lumot uchun qarang bizning sharhimiz)foydalanuvchini ilova bilan ma'lum bir podga ulash uchun:

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

Ammo bu takroriy joylashtirish bilan bog'liq muammolarni bartaraf etmaydi.

Tavsiya

To'g'riroq yo'l ilovani o'tkazish bo'ladi seanslarni memcached, Redis va shunga o'xshash echimlarda saqlash - umuman olganda, fayl parametrlaridan butunlay voz keching.

xulosa

Matnda muhokama qilingan infratuzilma echimlari faqat vaqtinchalik "tayoqchalar" formatida foydalanishga loyiqdir (bu ingliz tilida vaqtinchalik echim sifatida yanada chiroyli ko'rinadi). Ular ilovani Kubernetesga ko'chirishning birinchi bosqichlarida tegishli bo'lishi mumkin, ammo ildiz otmasligi kerak.

Tavsiya etilgan umumiy yo'l - bu ko'pchilikka yaxshi ma'lum bo'lgan narsaga muvofiq dasturni me'moriy o'zgartirish foydasiga ulardan xalos bo'lish. 12-faktor ilovasi. Biroq, bu - arizani fuqaroligi bo'lmagan shaklga keltirish - muqarrar ravishda kodni o'zgartirish talab qilinishini anglatadi va bu erda biznesning imkoniyatlari/talablari va tanlangan yo'lni amalga oshirish va qo'llab-quvvatlash istiqbollari o'rtasidagi muvozanatni topish muhimdir. .

PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

Ilovani Kubernetesga ko'chirishda mahalliy fayllar

Statik saqlash

Eng oddiy misol

Kengaytirilgan xotira

Tavsiya

Yuklab olinadigan fayllar

Tavsiya

Foydalanuvchi seanslari

Tavsiya

xulosa

PS

a Izoh qo'shish Bu savolga javob bekor