ឯកសារមូលដ្ឋាននៅពេលផ្ទេរកម្មវិធីទៅ Kubernetes

នៅពេលបង្កើតដំណើរការ CI/CD ដោយប្រើ Kubernetes ពេលខ្លះបញ្ហាកើតឡើងនៃភាពមិនស៊ីគ្នារវាងតម្រូវការនៃហេដ្ឋារចនាសម្ព័ន្ធថ្មី និងកម្មវិធីដែលត្រូវបានផ្ទេរទៅវា។ ជាពិសេសនៅដំណាក់កាលបង្កើតកម្មវិធីវាមានសារៈសំខាន់ក្នុងការទទួលបាន один រូបភាពដែលនឹងត្រូវបានប្រើ всех បរិស្ថានគម្រោង និងក្រុម។ គោលការណ៍​នេះ​បញ្ជាក់​ពី​ភាពត្រឹមត្រូវ នេះបើយោងតាម ​​Google ការគ្រប់គ្រងកុងតឺន័រ (ច្រើនជាងម្តងអំពីបញ្ហានេះ បាននិយាយ និងផ្នែកបច្ចេកទេសរបស់យើង) ។

ទោះជាយ៉ាងណាក៏ដោយ អ្នកនឹងមិនឃើញនរណាម្នាក់នៅក្នុងស្ថានភាពដែលកូដរបស់គេហទំព័រប្រើប្រាស់ក្របខ័ណ្ឌដែលត្រៀមរួចជាស្រេចនោះទេ ការប្រើប្រាស់ដែលដាក់កម្រិតលើការប្រើប្រាស់បន្ថែមទៀតរបស់វា។ ហើយខណៈពេលដែលនៅក្នុង "បរិយាកាសធម្មតា" វាងាយស្រួលក្នុងការដោះស្រាយនៅក្នុង Kubernetes ឥរិយាបថនេះអាចក្លាយជាបញ្ហា ជាពិសេសនៅពេលដែលអ្នកជួបប្រទះវាជាលើកដំបូង។ ខណៈពេលដែលគំនិតច្នៃប្រឌិតអាចបង្កើតដំណោះស្រាយហេដ្ឋារចនាសម្ព័ន្ធដែលមើលទៅជាក់ស្តែង ឬសូម្បីតែល្អនៅ glance ដំបូង ... វាជាការសំខាន់ដែលត្រូវចងចាំថាស្ថានភាពភាគច្រើនអាច និងគួរ ត្រូវបានដោះស្រាយតាមស្ថាបត្យកម្ម.

សូមក្រឡេកមើលដំណោះស្រាយដំណោះស្រាយដ៏ពេញនិយមសម្រាប់ការរក្សាទុកឯកសារដែលអាចនាំឱ្យមានផលវិបាកមិនល្អនៅពេលដំណើរការចង្កោម ហើយថែមទាំងចង្អុលបង្ហាញផ្លូវត្រឹមត្រូវបន្ថែមទៀតផងដែរ។

ការផ្ទុកឋិតិវន្ត

ដើម្បីបង្ហាញ សូមពិចារណាកម្មវិធីបណ្តាញដែលប្រើប្រភេទម៉ាស៊ីនភ្លើងឋិតិវន្ត ដើម្បីទទួលបានសំណុំរូបភាព រចនាប័ទ្ម និងអ្វីៗផ្សេងទៀត។ ឧទាហរណ៍ ក្របខ័ណ្ឌ Yii PHP មានកម្មវិធីគ្រប់គ្រងទ្រព្យសកម្មដែលបង្កើតនូវឈ្មោះថតតែមួយគត់។ ដូច្នោះហើយ លទ្ធផលគឺជាសំណុំផ្លូវសម្រាប់គេហទំព័រឋិតិវន្តដែលជាក់ស្តែងមិនប្រសព្វគ្នាទៅវិញទៅមក (នេះត្រូវបានធ្វើសម្រាប់ហេតុផលជាច្រើន - ឧទាហរណ៍ ដើម្បីលុបបំបាត់ការស្ទួនគ្នានៅពេលដែលសមាសធាតុជាច្រើនប្រើធនធានដូចគ្នា)។ ដូច្នេះ ចេញពីប្រអប់ ជាលើកដំបូងដែលអ្នកចូលប្រើម៉ូឌុលធនធានគេហទំព័រ ឯកសារឋិតិវន្ត (តាមពិត ជាញឹកញាប់ symlinks ប៉ុន្តែក្រោយមកទៀត) ត្រូវបានបង្កើតឡើង និងដាក់ចេញជាមួយថត root ទូទៅតែមួយគត់សម្រាប់ការដាក់ពង្រាយនេះ៖

• 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. កំណត់សញ្ញាជាក់លាក់សម្រាប់បញ្ជីទ្រព្យសកម្ម ដូចដែលបានពិភាក្សាក្នុង ឧ. បទបង្ហាញនេះ។ (ចាប់ផ្តើមពីស្លាយលេខ ៣៥)។ និយាយអីញ្ចឹង អ្នកនិពន្ធនៃរបាយការណ៍នៅទីបំផុត (ហើយមិនមែនដោយគ្មានហេតុផលទេ!) ណែនាំថាបន្ទាប់ពីការផ្គុំទ្រព្យសកម្មនៅលើម៉ាស៊ីនមេ ផ្ទុកឡើងពួកវាទៅកន្លែងផ្ទុកកណ្តាល (ដូចជា S35) នៅពីមុខកន្លែងដាក់ CDN ។

ឯកសារដែលអាចទាញយកបាន។

ករណីមួយទៀតដែលប្រាកដជានឹងចូលមកលេងនៅពេលផ្ទេរកម្មវិធីទៅចង្កោម Kubernetes គឺការរក្សាទុកឯកសារអ្នកប្រើប្រាស់នៅក្នុងប្រព័ន្ធឯកសារ។ ជាឧទាហរណ៍ យើងមានកម្មវិធី PHP ម្ដងទៀតដែលទទួលយកឯកសារតាមរយៈទម្រង់ផ្ទុកឡើង ធ្វើអ្វីមួយជាមួយពួកគេកំឡុងពេលប្រតិបត្តិការ ហើយបញ្ជូនពួកគេមកវិញ។

នៅក្នុង Kubernetes ទីតាំងដែលឯកសារទាំងនេះគួរតែត្រូវបានដាក់គួរតែជារឿងធម្មតាសម្រាប់កម្មវិធីចម្លងទាំងអស់នៃកម្មវិធី។ អាស្រ័យលើភាពស្មុគស្មាញនៃកម្មវិធី និងតម្រូវការក្នុងការរៀបចំការជាប់លាប់នៃឯកសារទាំងនេះ ជម្រើសឧបករណ៍ដែលបានចែករំលែកដែលបានរៀបរាប់ខាងលើអាចជាកន្លែងបែបនេះ ប៉ុន្តែដូចដែលយើងឃើញពួកគេមានគុណវិបត្តិរបស់វា។

អនុសាសន៍។

ដំណោះស្រាយមួយគឺ ប្រើទំហំផ្ទុកដែលត្រូវគ្នាជាមួយ S3 (ទោះបីជាវាជាប្រភេទនៃប្រភេទបង្ហោះដោយខ្លួនឯងដូចជា minio ក៏ដោយ)។ ការប្តូរទៅ S3 នឹងតម្រូវឱ្យមានការផ្លាស់ប្តូរ នៅកម្រិតលេខកូដនិងរបៀបដែលខ្លឹមសារនឹងត្រូវបានចែកចាយនៅផ្នែកខាងមុខ យើងមានរួចហើយ បានសរសេរ.

វគ្គអ្នកប្រើប្រាស់

ដោយឡែកពីគ្នាវាគួរអោយយកចិត្តទុកដាក់ចំពោះការរៀបចំការផ្ទុកវគ្គអ្នកប្រើប្រាស់។ ជារឿយៗទាំងនេះក៏ជាឯកសារនៅលើថាសផងដែរ ដែលនៅក្នុងបរិបទរបស់ Kubernetes នឹងនាំទៅរកការស្នើសុំការអនុញ្ញាតជាប្រចាំពីអ្នកប្រើប្រាស់ ប្រសិនបើសំណើរបស់គាត់បញ្ចប់នៅក្នុងកុងតឺន័រផ្សេងទៀត។

បញ្ហាត្រូវបានដោះស្រាយមួយផ្នែកដោយការបើក stickySessions នៅលើការចូល (លក្ខណៈពិសេសត្រូវបានគាំទ្រនៅក្នុងឧបករណ៍បញ្ជា ingress ដ៏ពេញនិយមទាំងអស់ - សម្រាប់ព័ត៌មានលម្អិតសូមមើល ការពិនិត្យរបស់យើង។)ដើម្បីភ្ជាប់អ្នកប្រើប្រាស់ទៅនឹង 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 Factor"។

ប្រភព: www.habr.com