አንድ መተግበሪያ ወደ Kubernetes በሚዛወርበት ጊዜ የአካባቢ ፋይሎች

Kubernetes ን በመጠቀም የ CI / ሲዲ ሂደትን ሲገነቡ አንዳንድ ጊዜ ችግሩ በአዲሱ መሠረተ ልማት መስፈርቶች እና ወደ እሱ በመተላለፉ መካከል አለመጣጣም ይከሰታል። በተለይም በመተግበሪያው የግንባታ ደረጃ ላይ ማግኘት አስፈላጊ ነው один ውስጥ ጥቅም ላይ የሚውል ምስል всех የፕሮጀክት አከባቢዎች እና ስብስቦች. ይህ መርህ ለትክክለኛው መሰረት ነው ጎግል እንዳለው መያዣ አስተዳደር (ስለዚህ ከአንድ ጊዜ በላይ ተናገረ እና የእኛ የቴክኒክ ክፍል).

ሆኖም ግን, የጣቢያው ኮድ ዝግጁ የሆነ ማዕቀፍ በሚጠቀምበት ሁኔታዎች ውስጥ ማንንም ማየት አይችሉም, አጠቃቀሙ ለቀጣይ አጠቃቀም ላይ ገደቦችን ያስገድዳል. እና "በተለመደው አካባቢ" ውስጥ ይህን ለመቋቋም ቀላል ነው, በ Kubernetes ውስጥ ይህ ባህሪ በተለይ ለመጀመሪያ ጊዜ ሲያጋጥመው ችግር ሊሆን ይችላል. የፈጠራ አእምሮ ግልጽ ወይም በቅድመ-እይታ ጥሩ የሚመስሉ የመሠረተ ልማት መፍትሄዎችን ሊያመጣ ቢችልም...አብዛኞቹ ሁኔታዎች ሊኖሩ እንደሚችሉ እና እንደሚገባቸው ማስታወስ ጠቃሚ ነው። በሥነ-ሕንፃ ይፈታል.

ክላስተር በሚሠራበት ጊዜ ወደ ደስ የማይል መዘዞች ሊያስከትሉ የሚችሉ ፋይሎችን ለማከማቸት ታዋቂ መፍትሄዎችን እንመልከት እና የበለጠ ትክክለኛ መንገድን እንጠቁማለን።

የማይንቀሳቀስ ማከማቻ

በምሳሌ ለማስረዳት፣ የምስሎች፣ ቅጦች እና ሌሎች ነገሮችን ለማግኘት አንዳንድ ዓይነት የማይንቀሳቀስ ጀነሬተር የሚጠቀም የድር መተግበሪያን ተመልከት። ለምሳሌ፣ የ Yii PHP ማዕቀፍ ልዩ የማውጫ ስሞችን የሚያመነጭ አብሮ የተሰራ የንብረት አስተዳዳሪ አለው። በዚህ መሠረት ውፅዓት ለስታቲስቲክ ጣቢያው የመንገዶች ስብስብ ነው, እሱም በግልጽ እርስ በርስ የማይጣረሱ (ይህ የተደረገው በበርካታ ምክንያቶች ነው - ለምሳሌ, ብዙ አካላት አንድ አይነት ሃብት ሲጠቀሙ ብዜቶችን ለማስወገድ). ስለዚህ፣ ከሳጥኑ ውስጥ፣ ለመጀመሪያ ጊዜ የድር ሃብት ሞጁሉን ሲደርሱ፣ የማይንቀሳቀሱ ፋይሎች (በእርግጥ፣ ብዙ ጊዜ ሲምሊንኮች፣ ግን ከዚያ በኋላ ላይ) ተፈጥረዋል እና ለዚህ ማሰማራቱ ልዩ በሆነ የጋራ ስር ማውጫ ተቀምጠዋል።

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

ይህ ከስብስብ አንፃር ምን ማለት ነው?

በጣም ቀላሉ ምሳሌ

የማይለዋወጥ መረጃዎችን ለማሰራጨት እና ቀላል ጥያቄዎችን ለማካሄድ ፒኤችፒ በ 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 ስህተት ያያሉ ። እዚህ ቀላሉ መፍትሄ የመያዣዎችን የጋራ ማውጫ ማደራጀት ነው ። ቀዳሚ አማራጭ - አጠቃላይ 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. ሃርድዌር እና ግብዓቶች ከፈቀዱ፣ መጠቀም ይችላሉ። ሴፍፍስ ለስታቲክ ፍላጎቶች እኩል ተደራሽ የሆነ ማውጫ ለማደራጀት. ኦፊሴላዊ ሰነዶች የኤስኤስዲ አንጻፊዎችን ይመክራል፣ ቢያንስ በሶስት እጥፍ ማባዛት እና በክላስተር ኖዶች መካከል የተረጋጋ “ወፍራም” ግንኙነት።
2. ብዙም የሚጠይቅ አማራጭ የ NFS አገልጋይ ማደራጀት ነው። ነገር ግን፣ በድር አገልጋዩ የሚቀርቡ ጥያቄዎችን ለማስኬድ የምላሽ ጊዜን መጨመር ግምት ውስጥ ማስገባት አለቦት፣ እና የስህተት መቻቻል ብዙ የሚፈለግ ይሆናል። ውድቀት የሚያስከትለው መዘዝ አስከፊ ነው፡ የተራራው መጥፋት ወደ ሰማይ በሚሮጥ የLA ጭነት ግፊት ክላስተርን ለሞት ይዳርጋል።

ከሌሎች ነገሮች በተጨማሪ, የማያቋርጥ ማከማቻ ለመፍጠር ሁሉም አማራጮች ያስፈልጋሉ የጀርባ ማጽዳት በተወሰነ ጊዜ ውስጥ የተከማቹ ጊዜ ያለፈባቸው የፋይሎች ስብስቦች. ፒኤችፒ ጋር መያዣዎች ፊት ለፊት ማስቀመጥ ይችላሉ ዴሞን አዘጋጅ ለተወሰነ ጊዜ የንብረት ቅጂዎችን የሚያከማች nginx ከመሸጎጥ። ይህ ባህሪ በመጠቀም በቀላሉ ሊዋቀር የሚችል ነው። proxy_cache በቀናት ውስጥ የማከማቻ ጥልቀት ወይም ጊጋባይት የዲስክ ቦታ.

ይህንን ዘዴ ከላይ ከተጠቀሱት የተከፋፈሉ የፋይል ስርዓቶች ጋር በማጣመር ለምናብ ትልቅ መስክ ያቀርባል, ይህም በሚተገበሩ እና በሚደግፉ ሰዎች በጀት እና ቴክኒካዊ አቅም ብቻ የተገደበ ነው. ከተሞክሮ, ስርዓቱ ቀለል ባለ መጠን, የበለጠ የተረጋጋ ይሰራል ማለት እንችላለን. እንደዚህ አይነት ሽፋኖች ሲጨመሩ, የመሠረተ ልማት አውታሮችን ለመጠበቅ በጣም አስቸጋሪ ይሆናል, እና በተመሳሳይ ጊዜ ከማንኛውም ውድቀቶች ለመፈተሽ እና ለማገገም የሚውለው ጊዜ ይጨምራል.

ምክር

የታቀዱት የማከማቻ አማራጮች አተገባበርም ለእርስዎ ተገቢ ያልሆነ መስሎ ከታየ (ውስብስብ, ውድ ...), ከዚያ ሁኔታውን ከሌላው ጎን መመልከት ተገቢ ነው. ይኸውም በፕሮጀክቱ አርክቴክቸር ውስጥ ለመቆፈር እና በኮዱ ውስጥ ያለውን ችግር ያስተካክሉ, በምስሉ ውስጥ ካሉ አንዳንድ የማይንቀሳቀስ የውሂብ መዋቅር ጋር የተሳሰረ፣ በምስል የመሰብሰቢያ ደረጃ ላይ ያሉ ንብረቶችን "ለማሞቅ" እና/ወይም ለማጠናቀር የይዘቱ ወይም የአሰራር ሂደት ግልጽ ያልሆነ ትርጉም። በዚህ መንገድ ፍፁም ሊገመት የሚችል ባህሪ እና ለሁሉም አከባቢዎች ተመሳሳይ የፋይሎች ስብስብ እና የአሂድ አፕሊኬሽኑ ቅጂዎች እናገኛለን።

ወደ ልዩ ምሳሌው በ Yii ማዕቀፍ ከተመለስን እና ወደ አወቃቀሩ ካልገባን (የጽሁፉ ዓላማ ያልሆነው) ሁለት ታዋቂ አቀራረቦችን ማመላከት በቂ ነው-

1. ንብረቶችን ሊገመት በሚችል ቦታ ለማስቀመጥ የምስል ግንባታ ሂደቱን ይለውጡ። ይህ በመሳሰሉት ቅጥያዎች ውስጥ የተጠቆመ/የተተገበረ ነው። yii2-የማይንቀሳቀስ-ንብረቶች.
2. በምሳሌ እንደተገለጸው ለንብረት ማውጫዎች የተወሰኑ ሃሽዎችን ይግለጹ። ይህ አቀራረብ (ከስላይድ ቁጥር 35 ጀምሮ). በነገራችን ላይ የሪፖርቱ ደራሲ በመጨረሻ (እና ያለ ምክንያት አይደለም!) በግንባታ አገልጋዩ ላይ ንብረቶችን ካሰባሰቡ በኋላ ወደ ማእከላዊ ማከማቻ (እንደ S3) እንዲሰቀሉ ይመክራል ፣ ከፊት ለፊት ሲዲኤን ያስቀምጡ ።

ውርዶች

አፕሊኬሽኑን ወደ ኩበርኔትስ ክላስተር ሲሸጋገር በእርግጠኝነት የሚሰራበት ሌላው ጉዳይ የተጠቃሚ ፋይሎችን በፋይል ሲስተም ውስጥ ማከማቸት ነው። ለምሳሌ፣ ፋይሎችን በሰቀላ ፎርም የሚቀበል፣ በሚሰራበት ጊዜ ከእነሱ ጋር የሆነ ነገር የሚያደርግ እና መልሶ የሚልክ የPHP አፕሊኬሽን በድጋሚ አለን።

በኩበርኔትስ ውስጥ እነዚህ ፋይሎች የሚቀመጡበት ቦታ ለሁሉም የመተግበሪያው ቅጂዎች የተለመደ መሆን አለበት። በመተግበሪያው ውስብስብነት እና የእነዚህን ፋይሎች ጽናት የማደራጀት አስፈላጊነት ላይ በመመስረት, ከላይ የተገለጹት የጋራ መገልገያ አማራጮች እንደዚህ አይነት ቦታ ሊሆኑ ይችላሉ, ነገር ግን እንደምናየው, ድክመቶች አሏቸው.

ምክር

አንዱ መፍትሔ ነው። S3-ተኳሃኝ ማከማቻን በመጠቀም (እንደ ሚኒዮ ያለ በራስ የሚስተናገደ ምድብ ቢሆንም)። ወደ 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 እና ተመሳሳይ መፍትሄዎች ማከማቸት - በአጠቃላይ ፣ የፋይል አማራጮችን ሙሉ በሙሉ መተው።

መደምደሚያ

በጽሁፉ ውስጥ የተብራሩት የመሠረተ ልማት መፍትሄዎች በጊዜያዊ "ክራችቶች" ቅርጸት ብቻ ጥቅም ላይ ሊውሉ የሚገባቸው ናቸው (ይህም በእንግሊዘኛ እንደ መፍትሄ የበለጠ ቆንጆ ነው). ማመልከቻን ወደ ኩበርኔትስ በሚሸጋገርበት የመጀመሪያ ደረጃዎች ላይ ጠቃሚ ሊሆኑ ይችላሉ ነገር ግን ሥር መስደድ የለባቸውም።

በአጠቃላይ የሚመከር መንገድ በብዙዎች ዘንድ በደንብ በሚታወቀው መሰረት የመተግበሪያውን የስነ-ህንፃ ማሻሻያ በመደገፍ እነሱን ማስወገድ ነው. 12-Factor መተግበሪያ. ነገር ግን, ይህ - ማመልከቻውን ወደ ሀገር-አልባ ቅፅ ማምጣት - በኮዱ ላይ ለውጦች መደረጉ የማይቀር ነው, እና እዚህ በንግዱ አቅም / መስፈርቶች እና የተመረጠውን መንገድ የመተግበር እና የመጠበቅ ተስፋዎች መካከል ሚዛን መፈለግ አስፈላጊ ነው. .

PS

በብሎጋችን ላይ ያንብቡ፡-

• «nginxን በመጠቀም ከAWS S3 ፋይሎችን ተኪ ማድረግ";
• «የጎግል 7 ኮንቴይነር ምርጥ ልምዶች";
• «በመያዣ ላይ የተመሰረቱ መተግበሪያዎችን ለመንደፍ 7 መርሆዎች» (ከቀይ ኮፍያ);
• «በ 7 Factor መተግበሪያ ውስጥ 12 የጎደሉ ነገሮች».

ምንጭ: hab.com