ProHoster > Blog > башкаруу > Колдонмону Kubernetesке көчүрүү учурунда локалдык файлдар

Колдонмону Kubernetesке көчүрүү учурунда локалдык файлдар

Колдонмону Kubernetesке көчүрүү учурунда локалдык файлдар

Kubernetes'тин жардамы менен CI/CD процессин курууда, кээде жаңы инфраструктуранын талаптары менен ага өткөрүлүп берилген тиркеменин ортосунда келишпестик көйгөйү пайда болот. Атап айтканда, тиркемени түзүү стадиясында алуу маанилүү один колдонулган сүрөт всех долбоордун чөйрөлөрү жана кластерлери. Бул принцип тууранын негизинде жатат Google боюнча контейнер башкаруу (бул жөнүндө бир нече жолу Ал мындай деди: жана биздин техникалык бөлүм).

Бирок, сиз сайттын коду даяр алкакты колдонгон кырдаалдарда эч кимди көрбөйсүз, аны колдонуу андан ары колдонууга чектөөлөрдү киргизет. Ал эми "кадимки чөйрөдө" муну менен күрөшүү оңой болсо да, Кубернетеде бул жүрүм-турум көйгөйгө айланышы мүмкүн, айрыкча, сиз аны биринчи жолу көргөндө. Ойлоп табуучу акыл инфраструктуралык чечимдерди ойлоп таба алат, алар бир караганда ачык-айкын же ал тургай жакшы көрүнгөн... архитектуралык жактан чечилет.

Келгиле, кластерди иштетүүдө жагымсыз кесепеттерге алып келиши мүмкүн болгон файлдарды сактоо боюнча популярдуу чечүү жолдорун карап көрөлү, ошондой эле туура жолду көрсөтөбүз.

Статикалык сактагыч

Мисал үчүн, сүрөттөрдүн, стилдердин жана башка нерселердин жыйындысын алуу үчүн кандайдыр бир статикалык генераторду колдонгон веб тиркемени карап көрөлү. Мисалы, 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 контейнеринде пайда болот. Бирок бир поддондун ичинде эки контейнер болсо, 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 жүкүнүн асманга шашылган басымы астында кластерди өлүмгө алып келет.

Башка нерселер менен катар, туруктуу сактагычты түзүү үчүн бардык параметрлер талап кылынат фон тазалоо белгилүү бир убакыттын ичинде топтолгон файлдардын эскирген топтомдору. PHP менен контейнерлердин алдына коюуга болот DaemonSet nginx кэштөөдөн, ал активдердин көчүрмөлөрүн чектелген убакытка сактайт. Бул жүрүм-турумду колдонуу менен оңой конфигурациялоого болот proxy_cache күн же гигабайт диск мейкиндигинде сактоо тереңдиги менен.

Бул ыкманы жогоруда айтылган бөлүштүрүлгөн файл тутумдары менен айкалыштыруу, аны ишке ашыра турган жана колдой тургандардын бюджети жана техникалык мүмкүнчүлүктөрү менен гана чектелип, кыялдануу үчүн чоң талааны камсыз кылат. Тажрыйбага таянсак, система канчалык жөнөкөй болсо, ошончолук туруктуу иштейт деп айта алабыз. Мындай катмарлар кошулганда инфраструктураны тейлөө бир топ кыйындайт, ошол эле учурда диагностикага жана ар кандай мүчүлүштүктөрдү калыбына келтирүүгө кеткен убакыт көбөйөт.

сунуш кылуу

Эгер сунушталган сактоо варианттарын ишке ашыруу да сизге негизсиз болуп көрүнсө (татаал, кымбат...), анда кырдаалды башка тараптан карап чыгуу зарыл. Тактап айтканда, долбоордун архитектурасын казып алуу жана коддогу көйгөйдү чечүү, сүрөттөлүштөгү кээ бир статикалык маалымат түзүмүнө байланган, мазмундун же процедуранын бир түшүнүктүү аныктамасы "жылытуу" жана/же сүрөттөрдү чогултуу баскычында активдерди алдын ала компиляциялоо. Ошентип, биз бардык чөйрөлөр жана иштеп жаткан тиркеменин репликалары үчүн таптакыр болжолдонгон жүрүм-турумду жана бирдей файлдар топтомун алабыз.

Эгерде биз Yii алкактары менен конкреттүү мисалга кайрылып, анын түзүмүн изилдебесек (бул макаланын максаты эмес), эки популярдуу ыкманы белгилей кетүү жетиштүү:

  1. Активдерди болжолдуу жерге жайгаштыруу үчүн сүрөт түзүү процессин өзгөртүңүз. Бул сыяктуу кеңейтүүлөрдө сунушталат/ишке ашырылат yii2-статикалык-активдер.
  2. М. бул презентация (№35 слайддан баштап). Айтмакчы, отчеттун автору акырында (жана себепсиз эмес!) активдерди куруу серверине чогулткандан кийин, аларды борбордук сактагычка (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

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Комментарий кошуу