ਲੋਕਲ ਫਾਈਲਾਂ ਜਦੋਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ CI/CD ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਣਾਉਣ ਵੇਲੇ, ਕਈ ਵਾਰ ਸਮੱਸਿਆ ਨਵੇਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਲੋੜਾਂ ਅਤੇ ਇਸ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤੀ ਜਾ ਰਹੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿਚਕਾਰ ਅਸੰਗਤਤਾ ਦੀ ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਐਪਲੀਕੇਸ਼ਨ ਬਿਲਡ ਪੜਾਅ 'ਤੇ ਇਹ ਪ੍ਰਾਪਤ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ один ਵਿੱਚ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਜੋ ਕਿ ਚਿੱਤਰ всех ਪ੍ਰੋਜੈਕਟ ਵਾਤਾਵਰਣ ਅਤੇ ਕਲੱਸਟਰ। ਇਹ ਸਿਧਾਂਤ ਸਹੀ ਦੇ ਅਧੀਨ ਹੈ ਗੂਗਲ ਦੇ ਅਨੁਸਾਰ ਕੰਟੇਨਰ ਪ੍ਰਬੰਧਨ (ਇਸ ਬਾਰੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਬੋਲਿਆ ਅਤੇ ਸਾਡਾ ਤਕਨੀਕੀ ਵਿਭਾਗ)।

ਹਾਲਾਂਕਿ, ਤੁਸੀਂ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਦੇਖੋਗੇ ਜਿੱਥੇ ਸਾਈਟ ਦਾ ਕੋਡ ਇੱਕ ਤਿਆਰ-ਬਣਾਇਆ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸਦੀ ਵਰਤੋਂ ਇਸਦੇ ਅੱਗੇ ਵਰਤੋਂ 'ਤੇ ਪਾਬੰਦੀਆਂ ਲਗਾਉਂਦੀ ਹੈ। ਅਤੇ ਜਦੋਂ ਇੱਕ "ਆਮ ਵਾਤਾਵਰਣ" ਵਿੱਚ ਇਸ ਨਾਲ ਨਜਿੱਠਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇਹ ਵਿਵਹਾਰ ਇੱਕ ਸਮੱਸਿਆ ਬਣ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲੀ ਵਾਰ ਇਸਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਕਿ ਇੱਕ ਖੋਜੀ ਦਿਮਾਗ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹੱਲਾਂ ਨਾਲ ਆ ਸਕਦਾ ਹੈ ਜੋ ਸਪੱਸ਼ਟ ਜਾਂ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਵੀ ਵਧੀਆ ਜਾਪਦਾ ਹੈ... ਇਹ ਯਾਦ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸਥਿਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਆਰਕੀਟੈਕਚਰਲ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤਾ ਜਾਵੇ.

ਆਉ ਫਾਈਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਹਰਮਨਪਿਆਰੇ ਹੱਲਾਂ ਨੂੰ ਵੇਖੀਏ ਜੋ ਇੱਕ ਕਲੱਸਟਰ ਨੂੰ ਚਲਾਉਣ ਵੇਲੇ ਅਣਸੁਖਾਵੇਂ ਨਤੀਜੇ ਲੈ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਹੋਰ ਸਹੀ ਮਾਰਗ ਵੀ ਦਰਸਾਉਂਦੇ ਹਨ।

ਸਥਿਰ ਸਟੋਰੇਜ਼

ਦਰਸਾਉਣ ਲਈ, ਇੱਕ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਚਿੱਤਰਾਂ, ਸਟਾਈਲਾਂ ਅਤੇ ਹੋਰ ਚੀਜ਼ਾਂ ਦਾ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਿਸੇ ਕਿਸਮ ਦੇ ਸਥਿਰ ਜਨਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, 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 ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਦੇ ਸਾਹਮਣੇ ਤੁਸੀਂ ਪਾ ਸਕਦੇ ਹੋ ਡੈਮਨਸੈੱਟ ਕੈਚਿੰਗ nginx ਤੋਂ, ਜੋ ਸੀਮਤ ਸਮੇਂ ਲਈ ਸੰਪਤੀਆਂ ਦੀਆਂ ਕਾਪੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰੇਗਾ। ਇਹ ਵਿਵਹਾਰ ਆਸਾਨੀ ਨਾਲ ਵਰਤ ਕੇ ਸੰਰਚਿਤ ਹੈ proxy_cache ਦਿਨਾਂ ਵਿੱਚ ਸਟੋਰੇਜ ਡੂੰਘਾਈ ਜਾਂ ਗੀਗਾਬਾਈਟ ਡਿਸਕ ਸਪੇਸ ਦੇ ਨਾਲ।

ਉੱਪਰ ਦੱਸੇ ਗਏ ਡਿਸਟਰੀਬਿਊਟਿਡ ਫਾਈਲ ਸਿਸਟਮਾਂ ਦੇ ਨਾਲ ਇਸ ਵਿਧੀ ਨੂੰ ਜੋੜਨਾ ਕਲਪਨਾ ਲਈ ਇੱਕ ਵਿਸ਼ਾਲ ਖੇਤਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਸਿਰਫ ਬਜਟ ਅਤੇ ਤਕਨੀਕੀ ਸਮਰੱਥਾ ਦੁਆਰਾ ਸੀਮਿਤ ਹੈ ਜੋ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨਗੇ ਅਤੇ ਸਮਰਥਨ ਕਰਨਗੇ। ਤਜਰਬੇ ਤੋਂ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਸਿਸਟਮ ਜਿੰਨਾ ਸਰਲ ਹੈ, ਇਹ ਓਨਾ ਹੀ ਸਥਿਰ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਅਜਿਹੀਆਂ ਪਰਤਾਂ ਨੂੰ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਕਿਸੇ ਵੀ ਅਸਫਲਤਾ ਦਾ ਨਿਦਾਨ ਕਰਨ ਅਤੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਖਰਚਿਆ ਸਮਾਂ ਵੱਧ ਜਾਂਦਾ ਹੈ.

ਸਿਫਾਰਸ਼

ਜੇ ਪ੍ਰਸਤਾਵਿਤ ਸਟੋਰੇਜ ਵਿਕਲਪਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਵੀ ਤੁਹਾਡੇ ਲਈ ਬੇਇਨਸਾਫ਼ੀ ਜਾਪਦਾ ਹੈ (ਗੁੰਝਲਦਾਰ, ਮਹਿੰਗਾ ...), ਤਾਂ ਇਹ ਦੂਜੇ ਪਾਸੇ ਤੋਂ ਸਥਿਤੀ ਨੂੰ ਦੇਖਣ ਦੇ ਯੋਗ ਹੈ. ਅਰਥਾਤ, ਪ੍ਰੋਜੈਕਟ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਖੋਦਣ ਲਈ ਅਤੇ ਕੋਡ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰੋ, ਚਿੱਤਰ ਵਿੱਚ ਕੁਝ ਸਥਿਰ ਡੇਟਾ ਢਾਂਚੇ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਸਮਗਰੀ ਦੀ ਇੱਕ ਅਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਜਾਂ ਚਿੱਤਰ ਅਸੈਂਬਲੀ ਪੜਾਅ 'ਤੇ "ਵਾਰਮਿੰਗ ਅੱਪ" ਅਤੇ/ਜਾਂ ਸੰਪਤੀਆਂ ਨੂੰ ਪ੍ਰੀ-ਕੰਪਾਇਲ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਯੋਗ ਵਿਵਹਾਰ ਅਤੇ ਸਾਰੇ ਵਾਤਾਵਰਣਾਂ ਅਤੇ ਚੱਲ ਰਹੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਫਾਈਲਾਂ ਦਾ ਇੱਕੋ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

ਜੇਕਰ ਅਸੀਂ Yii ਫਰੇਮਵਰਕ ਦੇ ਨਾਲ ਖਾਸ ਉਦਾਹਰਣ 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ ਅਤੇ ਇਸਦੇ ਢਾਂਚੇ (ਜੋ ਲੇਖ ਦਾ ਉਦੇਸ਼ ਨਹੀਂ ਹੈ) ਵਿੱਚ ਖੋਜ ਨਹੀਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਦੋ ਪ੍ਰਸਿੱਧ ਪਹੁੰਚਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਕਾਫੀ ਹੈ:

1. ਸੰਪਤੀਆਂ ਨੂੰ ਅਨੁਮਾਨਿਤ ਸਥਾਨ 'ਤੇ ਰੱਖਣ ਲਈ ਚਿੱਤਰ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਦਲੋ। ਇਹ ਜਿਵੇਂ ਐਕਸਟੈਂਸ਼ਨਾਂ ਵਿੱਚ ਸੁਝਾਇਆ/ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ yii2-ਸਥਿਰ-ਸੰਪੱਤੀ.
2. ਸੰਪਤੀ ਡਾਇਰੈਕਟਰੀਆਂ ਲਈ ਖਾਸ ਹੈਸ਼ਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਜਿਵੇਂ ਕਿ ਉਦਾਹਰਨ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ ਇਹ ਪੇਸ਼ਕਾਰੀ (ਸਲਾਈਡ ਨੰ. 35 ਤੋਂ ਸ਼ੁਰੂ)। ਤਰੀਕੇ ਨਾਲ, ਰਿਪੋਰਟ ਦੇ ਲੇਖਕ ਆਖਰਕਾਰ (ਅਤੇ ਬਿਨਾਂ ਕਾਰਨ ਨਹੀਂ!) ਸਲਾਹ ਦਿੰਦੇ ਹਨ ਕਿ ਬਿਲਡ ਸਰਵਰ 'ਤੇ ਸੰਪਤੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਉਹਨਾਂ ਨੂੰ ਕੇਂਦਰੀ ਸਟੋਰੇਜ (ਜਿਵੇਂ ਕਿ S3) ਤੇ ਅਪਲੋਡ ਕਰੋ, ਜਿਸ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਸੀ.ਡੀ.ਐਨ.

ਡਾਊਨਲੋਡ ਕਰਨ ਯੋਗ ਫ਼ਾਈਲਾਂ

ਇੱਕ ਹੋਰ ਕੇਸ ਜੋ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੋਵੇਗਾ ਜਦੋਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ Kubernetes ਕਲੱਸਟਰ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨਾ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ ਉਪਭੋਗਤਾ ਫਾਈਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰ ਰਿਹਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੋਲ ਦੁਬਾਰਾ ਇੱਕ PHP ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਇੱਕ ਅਪਲੋਡ ਫਾਰਮ ਦੁਆਰਾ ਫਾਈਲਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ ਉਹਨਾਂ ਨਾਲ ਕੁਝ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਭੇਜਦੀ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ, ਉਹ ਸਥਾਨ ਜਿੱਥੇ ਇਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਸਾਂਝਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਗੁੰਝਲਤਾ ਅਤੇ ਇਹਨਾਂ ਫਾਈਲਾਂ ਦੀ ਨਿਰੰਤਰਤਾ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਉੱਪਰ ਦੱਸੇ ਗਏ ਸ਼ੇਅਰਡ ਡਿਵਾਈਸ ਵਿਕਲਪ ਅਜਿਹੇ ਸਥਾਨ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ, ਉਹਨਾਂ ਦੀਆਂ ਕਮੀਆਂ ਹਨ.

ਸਿਫਾਰਸ਼

ਇੱਕ ਹੱਲ ਹੈ S3-ਅਨੁਕੂਲ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ (ਭਾਵੇਂ ਇਹ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਵੈ-ਮੇਜ਼ਬਾਨੀ ਵਰਗੀ ਹੋਵੇ ਜਿਵੇਂ ਕਿ ਮਿਨੀਓ)। S3 'ਤੇ ਜਾਣ ਲਈ ਬਦਲਾਅ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਕੋਡ ਪੱਧਰ 'ਤੇ, ਅਤੇ ਕਿਵੇਂ ਸਮੱਗਰੀ ਨੂੰ ਫਰੰਟ ਐਂਡ 'ਤੇ ਡਿਲੀਵਰ ਕੀਤਾ ਜਾਵੇਗਾ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ ਲਿਖੀ.

ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਉਪਭੋਗਤਾ ਸੈਸ਼ਨਾਂ ਦੇ ਸਟੋਰੇਜ ਦੇ ਸੰਗਠਨ ਨੂੰ ਧਿਆਨ ਵਿਚ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ. ਅਕਸਰ ਇਹ ਡਿਸਕ 'ਤੇ ਫਾਈਲਾਂ ਵੀ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਉਪਭੋਗਤਾ ਤੋਂ ਨਿਰੰਤਰ ਅਧਿਕਾਰ ਬੇਨਤੀਆਂ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ ਜੇਕਰ ਉਸਦੀ ਬੇਨਤੀ ਕਿਸੇ ਹੋਰ ਕੰਟੇਨਰ ਵਿੱਚ ਖਤਮ ਹੁੰਦੀ ਹੈ।

ਚਾਲੂ ਕਰਕੇ ਸਮੱਸਿਆ ਦਾ ਅੰਸ਼ਕ ਹੱਲ ਹੋ ਜਾਂਦਾ ਹੈ 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-ਫੈਕਟਰ ਐਪ. ਹਾਲਾਂਕਿ, ਇਹ - ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਟੇਟਲੈੱਸ ਰੂਪ ਵਿੱਚ ਲਿਆਉਣਾ - ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਅਤੇ ਇੱਥੇ ਕਾਰੋਬਾਰ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ/ਲੋੜਾਂ ਅਤੇ ਚੁਣੇ ਹੋਏ ਮਾਰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਬਣਾਈ ਰੱਖਣ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਲੱਭਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। .

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «nginx ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ AWS S3 ਤੋਂ ਫਾਈਲਾਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰਨਾ";
• «ਗੂਗਲ ਦੇ ਅਨੁਸਾਰ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ 7 ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ";
• «ਕੰਟੇਨਰ-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ 7 ਸਿਧਾਂਤ» (Red Hat ਤੋਂ);
• «7 ਫੈਕਟਰ ਐਪ ਵਿੱਚ 12 ​​ਲਾਪਤਾ ਕਾਰਕ".

ਸਰੋਤ: www.habr.com