Lokala filer vid flytt av applikationen till Kubernetes

När man bygger en CI/CD-process med Kubernetes kan det ibland uppstå problem med inkompatibiliteten mellan kraven för den nya infrastrukturen och den applikation som flyttas dit. Särskilt under applikationsbyggnadssteget är det viktigt att få en en bild som kommer att användas i alla projektets miljöer och kluster. Denna princip ligger till grund för korrekt hantering av containrar (detta har Google påpekat flera gånger) och vår teknikchef). till exempel Men man ser sällan situationer där en färdig ramverk används i webbplatsens kod, vilket bygger upp begränsningar för dess framtida drift. Och om man i en "vanlig miljö" lätt kan hantera detta, kan sådant beteende i Kubernetes bli ett problem, särskilt när man stöter på det första gången. Även om en uppfinningsrik hjärna kan föreslå infrastrukturlösningar som verkar självklara och till och med bra vid första anblicken… är det viktigt att komma ihåg att de flesta situationer kan och bör

lösas arkitektoniskt. Vi ska ta en titt på populära workaround-lösningar för lagring av filer, som kan leda till obehagliga konsekvenser vid drift av klustret, och vi kommer även att peka på en mer korrekt väg..

Lagring av statiska filer

För att illustrera detta, låt oss titta på en webbapplikation som använder en slags statisk generator för att få en uppsättning bilder, stilar och annat. Till exempel har PHP-ramverket Yii en inbyggd asset-manager som genererar unika namn för katalogerna. Följaktligen får vi en uppsättning vägar för webbplatsens statiska filer som inte överlappar varandra (detta görs av flera skäl — till exempel för att undvika dubbletter när samma resurs används av flera komponenter). Så, från början, vid första anropet av en modul på webbresursen, skapas och läggs statiken ut (egentligen ofta symboliska länkar, men mer om detta senare) med en unik gemensam rotkatalog för denna distribution:

webroot/assets/2072c2df/css/…

• webroot/assets/2072c2df/images/…
• webroot/assets/2072c2df/js/…
• Vad innebär detta i relation till klustret?

Ett enkelt exempel

Låt oss ta ett ganska vanligt fall där nginx står framför PHP för att leverera statiska filer och hantera enkla förfrågningar. Det enklaste sättet är

med två containrar: Deployment с двумя контейнерами:

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

I en förenklad version sammanfattas nginx-konfigurationen till följande:

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

Vid det första besöket på webbplatsen i containern med PHP genereras tillgångar. Men när det gäller två containrar inom samma pod, vet nginx ingenting om dessa statiska filer, som enligt konfigurationen ska levereras av dem. Resultatet blir att klienten ser ett 404-fel för alla förfrågningar om CSS- och JS-filer. Den enklaste lösningen här skulle vara att skapa en gemensam katalog för containrarna. En primitiv version är gemensam. 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

Nu levereras de genererade statiska filerna i containern korrekt av nginx. Men jag påminner om att detta är en primitiv lösning, vilket innebär att den ligger långt ifrån perfekt och har sina nyanser och brister, som diskuteras nedan.

Ett mer avancerat lagringssystem

Låt oss nu föreställa oss en situation där användaren har gått in på webbplatsen, laddat sidan med de stilar som finns i containern, och medan han läste sidan har vi återigen distribuerat containern. I katalogen för tillgångar har det blivit tomt och en begäran till PHP krävs för att starta genereringen av nya. Men även efter detta kommer länkarna till den gamla statiska innehållet att vara irrelevanta, vilket kommer att leda till fel vid visning av statiskt innehåll.

Dessutom har vi troligtvis ett mer eller mindre belastat projekt, vilket innebär att en kopia av applikationen inte kommer att vara tillräcklig:

• Vi skalar Deployment upp till två repliker.
• Vid det första besöket på webbplatsen skapades tillgångar i en av replikerna.
• Vid något tillfälle bestämde ingressen (för att balansera belastningen) att skicka en begäran till den andra repliken, och där finns dessa tillgångar inte ännu. Kanske finns de redan inte där, för vi använder RollingUpdate och just nu gör vi en distribution.

I allmänhet, slutsatsen — återigen fel.

För att inte förlora gamla tillgångar kan vi ändra emptyDir till hostPath, läggande statiskt innehåll fysiskt på klusterknuten. Denna metod är dålig eftersom vi praktiskt taget måste binda vårt program till en specifik klusterknut eftersom — om vi flyttar till andra knutar — kommer katalogen inte att innehålla nödvändiga filer. Alternativt krävs det någon form av bakgrundssynkronisering av katalogen mellan knutarna.

Vilka lösningar finns det?

1. Om hårdvaran och resurserna tillåter, kan vi använda cephfs för att organisera en tillgänglighetsdirektory för statiskt innehåll. Officiell dokumentation rekommenderar SSD-diskar, minst trippelreplikering och en stabil "tjock" anslutning mellan klusterknutar.
2. Ett mindre krävande alternativ skulle vara att organisera en NFS-server. Men då måste man ta hänsyn till den möjliga ökningen av svarstiden för begärningar från webbservern, och även redundansen kommer att vara bristande. Konsekvenserna av en felaktig operation är katastrofala: förlust av mount gör klustret dömt att falla under trycket av LA-belastningen som skjuter i höjden.

Utöver allt detta kommer för alla alternativ av att skapa permanenta lagringslösningar att krävas bakgrundsrensning av föråldrade filuppsättningar som samlats under en viss tidsperiod. Framför containrar med PHP kan man ställa in DaemonSet cacheande nginx, som kommer att lagra kopior av tillgångarna under en begränsad tid. Detta beteende kan enkelt konfigureras med hjälp av proxy_cache med lagringsdjup i dagar eller gigabyte diskutrymme.

Kombineringen av denna metod med de ovan nämnda distribuerade filsystemen erbjuder enorma möjligheter, där begränsningen endast är budgeten och den tekniska kapaciteten hos dem som ska implementera och underhålla det. Utifrån erfarenhet kan vi säga att ju enklare systemet är, desto stabilare fungerar det. När man lägger till sådana lager blir det betydligt svårare att underhålla infrastrukturen, och därmed ökar också tiden som spenderas på felsökning och återställning vid eventuella fel.

Rekommendation

Om implementeringen av de föreslagna lagringsalternativen också verkar orimlig (komplicerad, dyr...), bör man se på situationen från en annan synvinkel. Nämligen att gräva djupt i projektets arkitektur och utrota problemet i koden, knutna till någon statisk databasstruktur i bilden, entydig identifiering av innehållet eller proceduren för "uppvärmning" och/eller förkompilering av tillgångar i byggprocessen. På så sätt får vi helt förutsägbart beteende och samma uppsättning filer för alla miljöer och repliker av den körda applikationen.

Om vi återgår till det specifika exemplet med ramverket Yii och inte fördjupar oss i dess struktur (vilket inte är syftet med artikeln), räcker det med att påpeka två populära tillvägagångssätt:

1. Ändra byggprocessen för bilden så att tillgångar placeras på en förutsägbar plats. Sådana förslag/implementeringar finns i tillägg som yii2-static-assets.
2. Definiera specifika hash-värden för tillgångsmappar, som det berättas om till exempel i denna presentation. (från och med bild nummer 35). För övrigt rekommenderar föredragshållaren i slutändan (och inte utan skäl!) att efter byggandet av tillgångarna på byggservern ladda upp dem till ett centralt lagringsutrymme (som S3), framför vilket man ska sätta upp en CDN.

Uppladdade filer

Ett annat fall som garanterat kommer att inträffa vid flytt av applikationen till ett Kubernetes-kluster är lagring av användarfiler i filsystemet. Till exempel har vi återigen en PHP-applikation som tar emot filer via ett inmatningsformulär, gör något med dem under drift och ger dem tillbaka.

Platsen där dessa filer ska placeras, i verkligheten av Kubernetes, bör vara gemensam för alla instanser av applikationen. Beroende på applikationens komplexitet och behovet av att organisera beständighet för dessa filer, kan sådana platser vara de nämnda tidigare delade enheterna, men som vi ser har de sina nackdelar.

Rekommendation

Ett av alternativen till lösningar är att använda S3-kompatibel lagring (även någon variant av självhostade kategorin som minio). Övergången till att arbeta med S3 kommer att kräva förändringar på kodnivå, och hur innehållet kommer att levereras på frontend har vi redan om.

Användarsessioner

Det är värt att särskilt notera hur användarsessioner lagras. Ofta handlar det också om filer på disk, vilket i Kubernetes leder till ständiga autentiseringsförfrågningar från användaren om deras begäran hamnar i en annan container.

Delvis löses problemet genom att aktivera stickySessions på ingress (denna funktion stöds av alla populära ingresskontroller — mer info kan ses i vår recension), för att binda användaren till en specifik pod med applikationen:

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

Men det kommer inte att avhjälpa problem vid upprepade distributioner.

Rekommendation

Ett mer korrekt sätt skulle vara att överföra applikationen till lagring av sessioner i memcached, Redis och liknande lösningar — i allmänhet att helt överge filalternativen.

Slutsats

De infrastrukturella lösningar som diskuteras i texten är endast värda att tillämpa som temporära "snabblösningar" (vilket låter mer elegant på engelska som workaround). De kan vara aktuella i de inledande stegen av applikationens migration till Kubernetes, men bör inte "rota sig".

Den allmänt rekommenderade vägen är att bli av med dem till förmån för en arkitekturförbättring av applikationen i enlighet med det som redan är välkänt av många 12-Factor App. Det är dock — att omvandla applikationen till ett stateless-format — oundvikligen betyder att förändringar i koden kommer att krävas, och här är det viktigt att finna en balans mellan affärens möjligheter/krav och perspektiven för implementering och underhåll av den valda vägen.

P.S.

Läs även i vår blogg:

• «Vi proxyar filer från AWS S3 med hjälp av nginx»;
• «7 bästa praxis för containerhantering enligt Google»;
• «7 principer för design av containerbaserade applikationer» (från Red Hat);
• «7 saknade faktorer i 12 Factor App-ansatsen».

Källa: habr.com