Локални файлове при мигриране на приложение към Kubernetes

При изграждането на CI/CD процес с помощта на Kubernetes понякога възниква проблемът с несъвместимостта между изискванията на новата инфраструктура и приложението, което се прехвърля към нея. По-специално, на етапа на изграждане на приложението е важно да получите един изображение, което ще се използва в всички проектни среди и клъстери. Този принцип е в основата на правилното според Google управление на контейнери (повече от веднъж за това говореше и нашия технически отдел).

Въпреки това, няма да видите никого в ситуации, когато кодът на сайта използва готова рамка, чието използване налага ограничения върху по-нататъшното му използване. И докато в „нормална среда“ това е лесно за справяне, в Kubernetes това поведение може да се превърне в проблем, особено когато го срещнете за първи път. Докато един изобретателен ум може да измисли инфраструктурни решения, които изглеждат очевидни или дори добри на пръв поглед... важно е да запомните, че повечето ситуации могат и трябва да бъдат решени архитектурно.

Ще анализираме популярни заобиколни решения за съхраняване на файлове, които могат да доведат до неприятни последици при работа с клъстер, а също така ще посочим по-правилен път.

Статично съхранение

За да илюстрираме, помислете за уеб приложение, което използва някакъв вид статичен генератор, за да получи набор от изображения, стилове и други неща. Например 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 не знае нищо за тези статични файлове, които (според конфигурацията) трябва да им бъдат дадени. В резултат на това клиентът ще види грешка 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, за да започнете да генерирате нови. Въпреки това, дори след това, връзките към стари статики ще бъдат неуместни, което ще доведе до грешки при показването на статики.

Освен това най-вероятно имаме повече или по-малко зареден проект, което означава, че едно копие на приложението няма да е достатъчно:

• Нека го увеличим внедряване до две реплики.
• Когато сайтът беше достъпен за първи път, активите бяха създадени в една реплика.
• В даден момент ingress реши (за целите на балансирането на натоварването) да изпрати заявка до втората реплика и тези активи все още не бяха там. Или може би вече не са там, защото използваме 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 при влизане (функцията се поддържа във всички популярни входни контролери - за повече подробности вижте нашия преглед)за обвързване на потребителя към конкретен pod с приложението:

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 принципа за проектиране на приложения, базирани на контейнери» (от Red Hat);
• «7 липсващи фактора в приложението с 12 фактора".

Източник: www.habr.com