குபெர்னெட்டஸுக்கு பயன்பாட்டை நகர்த்தும்போது உள்ளூர் கோப்புகள்

Kubernetes ஐப் பயன்படுத்தி 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 போன்ற) பதிவேற்றம் செய்யுமாறு அறிவுறுத்துகிறார், அதன் முன் CDN ஐ வைக்கவும்.

பதிவிறக்கங்கள்

ஒரு பயன்பாட்டை குபெர்னெட்ஸ் கிளஸ்டருக்கு மாற்றும்போது நிச்சயமாக செயல்படும் மற்றொரு வழக்கு கோப்பு முறைமையில் பயனர் கோப்புகளை சேமிப்பது. எடுத்துக்காட்டாக, எங்களிடம் மீண்டும் ஒரு 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-காரணி பயன்பாடு. இருப்பினும், இது - விண்ணப்பத்தை நிலையற்ற படிவத்திற்கு கொண்டு வருவது - தவிர்க்க முடியாமல் குறியீட்டில் மாற்றங்கள் தேவைப்படும், மேலும் இங்கே வணிகத்தின் திறன்கள்/தேவைகள் மற்றும் தேர்ந்தெடுக்கப்பட்ட பாதையை செயல்படுத்துவதற்கும் பராமரிப்பதற்கும் உள்ள வாய்ப்புகளுக்கு இடையில் சமநிலையைக் கண்டறிவது முக்கியம். .

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• «nginx ஐப் பயன்படுத்தி AWS S3 இலிருந்து ப்ராக்ஸி கோப்புகள்";
• «Google இன் படி கொள்கலன்களைப் பயன்படுத்துவதற்கான 7 சிறந்த நடைமுறைகள்";
• «கொள்கலன் அடிப்படையிலான பயன்பாடுகளை வடிவமைப்பதற்கான 7 கோட்பாடுகள்» (Red Hat இலிருந்து);
• «7 காரணி பயன்பாட்டில் 12 விடுபட்ட காரணிகள்".

ஆதாரம்: www.habr.com