ការប្រើ mcrouter ដើម្បីធ្វើមាត្រដ្ឋាន memcached ផ្ដេក

ការបង្កើតគម្រោងដែលមានបន្ទុកខ្ពស់នៅក្នុងភាសាណាមួយតម្រូវឱ្យមានវិធីសាស្រ្តពិសេស និងការប្រើប្រាស់ឧបករណ៍ពិសេស ប៉ុន្តែនៅពេលនិយាយអំពីកម្មវិធីនៅក្នុង PHP ស្ថានភាពអាចកាន់តែធ្ងន់ធ្ងរដែលអ្នកត្រូវអភិវឌ្ឍឧទាហរណ៍។ ម៉ាស៊ីនមេកម្មវិធីផ្ទាល់ខ្លួន. នៅក្នុងកំណត់សម្គាល់នេះ យើងនឹងនិយាយអំពីការឈឺចាប់ដែលធ្លាប់ស្គាល់ជាមួយការផ្ទុកវគ្គចែកចាយ និងការរក្សាទុកទិន្នន័យនៅក្នុង memcached និងរបៀបដែលយើងដោះស្រាយបញ្ហាទាំងនេះនៅក្នុងគម្រោង "វួដ" មួយ។

វីរបុរសនៃឱកាសនេះគឺជាកម្មវិធី PHP ផ្អែកលើ symfony 2.3 framework ដែលមិនត្រូវបានរួមបញ្ចូលនៅក្នុងផែនការអាជីវកម្មដើម្បីធ្វើបច្ចុប្បន្នភាពទេ។ បន្ថែមពីលើការផ្ទុកសម័យស្តង់ដារ គម្រោងនេះបានប្រើប្រាស់ពេញលេញ គោលនយោបាយ "រក្សាទុកអ្វីគ្រប់យ៉ាង" នៅក្នុង memcached៖ ការឆ្លើយតបទៅនឹងសំណើទៅកាន់មូលដ្ឋានទិន្នន័យ និងម៉ាស៊ីនមេ API ទង់ផ្សេងៗ ចាក់សោសម្រាប់ធ្វើសមកាលកម្មការប្រតិបត្តិកូដ និងច្រើនទៀត។ ក្នុងស្ថានភាពបែបនេះ ការបំបែកនៃ memcached ក្លាយជាគ្រោះថ្នាក់ដល់ប្រតិបត្តិការនៃកម្មវិធី។ លើសពីនេះទៀតការបាត់បង់ឃ្លាំងសម្ងាត់នាំឱ្យមានផលវិបាកធ្ងន់ធ្ងរ: DBMS ចាប់ផ្តើមផ្ទុះនៅស៊ាម សេវាកម្ម API ចាប់ផ្តើមហាមឃាត់សំណើ។ល។ ស្ថេរភាពស្ថានភាពអាចចំណាយពេលរាប់សិបនាទី ហើយក្នុងអំឡុងពេលនេះ សេវាកម្មនឹងយឺតយ៉ាវខ្លាំង ឬមិនអាចប្រើបានទាំងស្រុង។

យើងត្រូវការផ្តល់ជូន សមត្ថភាពក្នុងការធ្វើមាត្រដ្ឋានផ្ដេកកម្មវិធីដោយមានការខិតខំប្រឹងប្រែងតិចតួច, i.e. ជាមួយនឹងការផ្លាស់ប្តូរតិចតួចបំផុតចំពោះកូដប្រភព និងមុខងារពេញលេញត្រូវបានរក្សាទុក។ ធ្វើឱ្យឃ្លាំងសម្ងាត់មិនត្រឹមតែធន់នឹងការបរាជ័យប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងព្យាយាមកាត់បន្ថយការបាត់បង់ទិន្នន័យពីវាផងដែរ។

តើមានអ្វីខុសជាមួយ memcached ខ្លួនវា?

ជាទូទៅ ផ្នែកបន្ថែម memcached សម្រាប់ PHP គាំទ្រទិន្នន័យចែកចាយ និងការផ្ទុកសម័យចេញពីប្រអប់។ យន្តការសម្រាប់ការ hashing key ជាប់លាប់អនុញ្ញាតឱ្យអ្នកដាក់ទិន្នន័យស្មើៗគ្នានៅលើ servers ជាច្រើន ដោះស្រាយដោយឡែកពីគ្នានូវ key ជាក់លាក់នីមួយៗទៅកាន់ server ជាក់លាក់មួយពីក្រុម ហើយឧបករណ៍បរាជ័យដែលភ្ជាប់មកជាមួយធានានូវភាពអាចរកបានខ្ពស់នៃសេវាកម្មឃ្លាំងសម្ងាត់ (ប៉ុន្តែជាអកុសល គ្មាន​ទិន្នន័យ).

អ្វីៗមានភាពប្រសើរជាងមុនបន្តិចជាមួយនឹងការផ្ទុកវគ្គ៖ អ្នកអាចកំណត់រចនាសម្ព័ន្ធបាន។ memcached.sess_number_of_replicasជាលទ្ធផលទិន្នន័យនឹងត្រូវបានរក្សាទុកនៅលើម៉ាស៊ីនមេជាច្រើនក្នុងពេលតែមួយ ហើយក្នុងករណីមានការបរាជ័យនៃឧទាហរណ៍មួយ memcached ទិន្នន័យនឹងត្រូវបានផ្ទេរពីអ្នកដទៃ។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើម៉ាស៊ីនមេត្រលប់មកអ៊ីនធឺណិតវិញដោយគ្មានទិន្នន័យ (ជាធម្មតាកើតឡើងបន្ទាប់ពីការចាប់ផ្តើមឡើងវិញ) សោមួយចំនួននឹងត្រូវបានចែកចាយឡើងវិញតាមការពេញចិត្តរបស់វា។ តាមពិតនេះនឹងមានន័យ ការបាត់បង់ទិន្នន័យសម័យចាប់តាំងពីមិនមានវិធី "ទៅ" ទៅកន្លែងចម្លងផ្សេងទៀតក្នុងករណីខកខាន។

ឧបករណ៍បណ្ណាល័យស្តង់ដារមានគោលបំណងជាចម្បង ផ្ដេក ការធ្វើមាត្រដ្ឋាន៖ ពួកគេអនុញ្ញាតឱ្យអ្នកបង្កើនឃ្លាំងសម្ងាត់ដល់ទំហំមហិមា និងផ្តល់ការចូលប្រើវាពីកូដដែលបង្ហោះនៅលើម៉ាស៊ីនមេផ្សេងៗ។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងស្ថានភាពរបស់យើង បរិមាណនៃទិន្នន័យដែលបានរក្សាទុកមិនលើសពីជីហ្គាបៃច្រើនទេ ហើយដំណើរការនៃថ្នាំងមួយ ឬពីរគឺគ្រប់គ្រាន់ហើយ។ ដូច្នោះហើយ ឧបករណ៍ស្ដង់ដារដែលមានប្រយោជន៍តែមួយគត់អាចធានាបាននូវភាពអាចរកបាននៃ memcached ខណៈពេលដែលរក្សាបាននូវឃ្លាំងសម្ងាត់យ៉ាងហោចណាស់មួយនៅក្នុងលក្ខខណ្ឌការងារ។ ទោះជាយ៉ាងណាក៏ដោយ វាមិនអាចទាញយកប្រយោជន៍ពីឱកាសនេះបានទេ... នៅទីនេះវាមានតម្លៃរំលឹកឡើងវិញនូវវត្ថុបុរាណនៃក្របខ័ណ្ឌដែលបានប្រើនៅក្នុងគម្រោង ដែលជាមូលហេតុដែលវាមិនអាចឱ្យកម្មវិធីធ្វើការជាមួយម៉ាស៊ីនមេ។ យើងក៏មិនត្រូវភ្លេចអំពីការបាត់បង់ទិន្នន័យសម័យដែរ៖ ភ្នែករបស់អតិថិជនបានញ័រពីការចាកចេញពីអ្នកប្រើប្រាស់យ៉ាងច្រើន។

តាមឧត្ដមគតិវាត្រូវបានទាមទារ ការចម្លងនៃកំណត់ត្រានៅក្នុង memcached និងការឆ្លងកាត់ការចម្លង ក្នុងករណីមានកំហុសឬកំហុស។ បានជួយយើងអនុវត្តយុទ្ធសាស្ត្រនេះ។ mcrouter.

mcrouter

នេះគឺជារ៉ោតទ័រ memcached ដែលបង្កើតឡើងដោយ Facebook ដើម្បីដោះស្រាយបញ្ហារបស់វា។ វាគាំទ្រពិធីការអត្ថបទ memcached ដែលអនុញ្ញាត ការដំឡើងមាត្រដ្ឋាន memcached ទៅសមាមាត្រឆ្កួត។ ការពិពណ៌នាលម្អិតនៃ mcouter អាចរកបាននៅក្នុង សេចក្តីប្រកាសនេះ។. ក្នុងចំណោមរបស់ផ្សេងទៀត។ មុខងារធំទូលាយ វាអាចធ្វើអ្វីដែលយើងត្រូវការ៖

• ថតចម្លង;
• ត្រឡប់ទៅកាន់ម៉ាស៊ីនមេផ្សេងទៀតនៅក្នុងក្រុមប្រសិនបើមានកំហុសកើតឡើង។

ទៅធ្វើការ!

ការកំណត់រចនាសម្ព័ន្ធ mcouter

ខ្ញុំនឹងទៅការកំណត់រចនាសម្ព័ន្ធ៖

{
 "pools": {
   "pool00": {
     "servers": [
       "mc-0.mc:11211",
       "mc-1.mc:11211",
       "mc-2.mc:11211"
   },
   "pool01": {
     "servers": [
       "mc-1.mc:11211",
       "mc-2.mc:11211",
       "mc-0.mc:11211"
   },
   "pool02": {
     "servers": [
       "mc-2.mc:11211",
       "mc-0.mc:11211",
       "mc-1.mc:11211"
 },
 "route": {
   "type": "OperationSelectorRoute",
   "default_policy": "AllMajorityRoute|Pool|pool00",
   "operation_policies": {
     "get": {
       "type": "RandomRoute",
       "children": [
         "MissFailoverRoute|Pool|pool02",
         "MissFailoverRoute|Pool|pool00",
         "MissFailoverRoute|Pool|pool01"
       ]
     }
   }
 }
}

ហេតុអ្វីបានជាអាងទឹកបី? ហេតុអ្វីបានជាម៉ាស៊ីនមេកើតឡើងម្តងទៀត? ចូរយើងស្វែងយល់ពីរបៀបដែលវាដំណើរការ។

• នៅក្នុងការកំណត់រចនាសម្ព័ន្ធនេះ mcouter ជ្រើសរើសផ្លូវដែលសំណើនឹងត្រូវបានផ្ញើដោយផ្អែកលើពាក្យបញ្ជាសំណើ។ បុរសប្រាប់គាត់អំពីរឿងនេះ OperationSelectorRoute.
• ទទួលបានសំណើទៅកាន់អ្នកដោះស្រាយ RandomRouteដែលជ្រើសរើសដោយចៃដន្យនូវអាង ឬផ្លូវក្នុងចំណោមវត្ថុអារេ children. ធាតុនីមួយៗនៃអារេនេះគឺនៅក្នុងវេនជាអ្នកដោះស្រាយ MissFailoverRouteដែលនឹងឆ្លងកាត់ម៉ាស៊ីនមេនីមួយៗនៅក្នុងអាង រហូតទាល់តែវាទទួលបានការឆ្លើយតបជាមួយនឹងទិន្នន័យ ដែលនឹងត្រូវប្រគល់ជូនអតិថិជនវិញ។
• ប្រសិនបើយើងប្រើផ្តាច់មុខ MissFailoverRoute ជាមួយនឹងក្រុមនៃម៉ាស៊ីនមេចំនួនបី នោះសំណើទាំងអស់នឹងមកមុនដំបូងទៅកាន់ memcached ដំបូង ហើយនៅសល់នឹងទទួលសំណើនៅលើមូលដ្ឋានដែលនៅសល់នៅពេលដែលមិនមានទិន្នន័យ។ វិធីសាស្រ្តបែបនេះនឹងនាំឱ្យមាន បន្ទុកលើសនៅលើម៉ាស៊ីនមេដំបូងក្នុងបញ្ជីដូច្នេះវាត្រូវបានគេសម្រេចចិត្តបង្កើតក្រុមចំនួនបីដែលមានអាសយដ្ឋាននៅក្នុងលំដាប់ផ្សេងគ្នា ហើយជ្រើសរើសពួកវាដោយចៃដន្យ។
• សំណើផ្សេងទៀតទាំងអស់ (ហើយនេះគឺជាកំណត់ត្រា) ត្រូវបានដំណើរការដោយប្រើ AllMajorityRoute. កម្មវិធីគ្រប់គ្រងនេះផ្ញើសំណើទៅកាន់ម៉ាស៊ីនមេទាំងអស់នៅក្នុងអាង ហើយរង់ចាំការឆ្លើយតបពីយ៉ាងហោចណាស់ N/2 + 1 ក្នុងចំណោមពួកគេ។ ពីការប្រើប្រាស់ AllSyncRoute សម្រាប់ប្រតិបត្តិការសរសេរត្រូវតែបោះបង់ចោល ចាប់តាំងពីវិធីសាស្ត្រនេះទាមទារការឆ្លើយតបជាវិជ្ជមានពី всех ម៉ាស៊ីនមេនៅក្នុងក្រុម - បើមិនដូច្នេះទេវានឹងត្រឡប់មកវិញ SERVER_ERROR. ទោះបីជា mcrouter នឹងបន្ថែមទិន្នន័យទៅឃ្លាំងសម្ងាត់ដែលមាន មុខងារ PHP ហៅ នឹងត្រឡប់កំហុស ហើយនឹងបង្កើតការជូនដំណឹង។ AllMajorityRoute មិនមានភាពតឹងរ៉ឹងខ្លាំងទេ ហើយអនុញ្ញាតឱ្យរហូតដល់ពាក់កណ្តាលនៃអង្គភាពត្រូវបានដកចេញពីសេវាកម្មដោយគ្មានបញ្ហាដូចដែលបានពិពណ៌នាខាងលើ។

គុណវិបត្តិចម្បង គ្រោងការណ៍នេះគឺថាប្រសិនបើពិតជាមិនមានទិន្នន័យនៅក្នុងឃ្លាំងសម្ងាត់ទេនោះសម្រាប់សំណើនីមួយៗពីអតិថិជន N សំណើទៅ memcached នឹងត្រូវបានប្រតិបត្តិ - ទៅ ទៅទាំងអស់ ម៉ាស៊ីនមេនៅក្នុងអាង។ យើង​អាច​កាត់​បន្ថយ​ចំនួន​ម៉ាស៊ីន​បម្រើ​ក្នុង​អាង​ជា​ឧទាហរណ៍​មក​ជា​ពីរ៖ ការ​លះបង់​ភាព​ទុក​ចិត្ត​នៃ​ការ​ផ្ទុក យើង​ទទួល​បានоល្បឿនកាន់តែខ្ពស់ និងបន្ទុកតិចពីសំណើទៅសោដែលបាត់។

NB៖ អ្នកក៏អាចរកឃើញតំណភ្ជាប់ដែលមានប្រយោជន៍សម្រាប់ការរៀន mcouter ឯកសារនៅលើវីគី и បញ្ហាគម្រោង (រួមទាំងវត្ថុបិទជិត) តំណាងឱ្យឃ្លាំងទាំងមូលនៃការកំណត់រចនាសម្ព័ន្ធផ្សេងៗ។

ការសាងសង់និងដំណើរការ mcouter

កម្មវិធីរបស់យើង (និង memcached ខ្លួនវា) ដំណើរការនៅក្នុង Kubernetes - អាស្រ័យហេតុនេះ mcrouter ក៏មានទីតាំងនៅទីនោះផងដែរ។ សម្រាប់ ការផ្គុំធុង យើង​ប្រើ werf, ការកំណត់រចនាសម្ព័ន្ធដែលនឹងមើលទៅដូចនេះ:

NB៖ បញ្ជីដែលបានផ្តល់ឱ្យក្នុងអត្ថបទត្រូវបានបោះពុម្ពផ្សាយនៅក្នុងឃ្លាំង Flant/mcrouter.

configVersion: 1
project: mcrouter
deploy:
 namespace: '[[ env ]]'
 helmRelease: '[[ project ]]-[[ env ]]'
---
image: mcrouter
from: ubuntu:16.04
mount:
- from: tmp_dir
 to: /var/lib/apt/lists
- from: build_dir
 to: /var/cache/apt
ansible:
 beforeInstall:
 - name: Install prerequisites
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Add mcrouter APT key
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Add mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Set timezone
   timezone:
     name: "Europe/Moscow"
 - name: Ensure a locale exists
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Install mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

... ហើយគូរវាចេញ គំនូសតាងមួកសុវត្ថិភាព. អ្វី​ដែល​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​គឺ​ថា​មាន​តែ​ម៉ាស៊ីន​ភ្លើង​កំណត់​រចនាសម្ព័ន្ធ​ដែល​ផ្អែក​លើ​ចំនួន​នៃ​ការ​ចម្លង​ (ប្រសិនបើនរណាម្នាក់មានជម្រើស laconic និងឆើតឆាយជាងនេះចែករំលែកវានៅក្នុងមតិយោបល់):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Заполняем  массив двумя копиями серверов: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
   {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Смещаясь по массиву, получаем N срезов: "[0 1 2] [1 2 0] [2 0 1]" */ -}}
{{- range $i, $_ := until $count -}}
 {{- $pool := dict "servers" (slice $servers $i (add $i $count)) -}}
 {{- $_ := set $pools (printf "MissFailoverRoute|Pool|pool%02d" $i) $pool -}}
{{- end -}}
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mcrouter
data:
 config.json: |
   {
     "pools": {{- $pools | toJson | replace "MissFailoverRoute|Pool|" "" -}},
     "route": {
       "type": "OperationSelectorRoute",
       "default_policy": "AllMajorityRoute|Pool|pool00",
       "operation_policies": {
         "get": {
           "type": "RandomRoute",
           "children": {{- keys $pools | toJson }}
         }
       }
     }
   }

(10-mcrouter.yaml)

យើងរមៀលវាចូលទៅក្នុងបរិយាកាសសាកល្បង ហើយពិនិត្យមើល៖

# php -a
Interactive mode enabled

php > # Проверяем запись и чтение
php > $m = new Memcached();
php > $m->addServer('mcrouter', 11211);
php > var_dump($m->set('test', 'value'));
bool(true)
php > var_dump($m->get('test'));
string(5) "value"
php > # Работает! Тестируем работу сессий:
php > ini_set('session.save_handler', 'memcached');
php > ini_set('session.save_path', 'mcrouter:11211');
php > var_dump(session_start());
PHP Warning:  Uncaught Error: Failed to create session ID: memcached (path: mcrouter:11211) in php shell code:1
Stack trace:
#0 php shell code(1): session_start()
#1 {main}
  thrown in php shell code on line 1
php > # Не заводится… Попробуем задать session_id:
php > session_id("zzz");
php > var_dump(session_start());
PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at php shell code:1) in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Unable to clear session lock record in php shell code on line 1
PHP Warning:  session_start(): Failed to read session data: memcached (path: mcrouter:11211) in php shell code on line 1
bool(false)
php >

ការស្វែងរកអត្ថបទនៃកំហុសមិនបានផ្តល់លទ្ធផលណាមួយទេ ប៉ុន្តែសម្រាប់សំណួរ "mcrouter php"នៅជួរមុខគឺជាបញ្ហាដែលមិនទាន់ដោះស្រាយចំណាស់បំផុតនៃគម្រោង - កង្វះការគាំទ្រ ពិធីការប្រព័ន្ធគោលពីរ memcached ។

NB៖ ពិធីការ ASCII ក្នុង memcached គឺយឺតជាងប្រព័ន្ធគោលពីរ ហើយមធ្យោបាយស្តង់ដារនៃការ hashing key ជាប់លាប់ដំណើរការតែជាមួយ binary protocol ប៉ុណ្ណោះ។ ប៉ុន្តែនេះមិនបង្កើតបញ្ហាសម្រាប់ករណីជាក់លាក់នោះទេ។

ល្បិចគឺនៅក្នុងកាបូប៖ អ្វីដែលអ្នកត្រូវធ្វើគឺប្តូរទៅពិធីការ ASCII ហើយអ្វីៗនឹងដំណើរការ.... ទោះយ៉ាងណាក៏ដោយក្នុងករណីនេះទម្លាប់នៃការស្វែងរកចម្លើយនៅក្នុង ឯកសារនៅលើ php.net បានលេងរឿងកំប្លែងដ៏ឃោរឃៅ។ អ្នក​នឹង​មិន​អាច​រក​ឃើញ​ចម្លើយ​ត្រឹម​ត្រូវ​នៅ​ទី​នោះ​ទេ... លុះ​ត្រា​តែ​អ្នក​រមូរ​ទៅ​ទី​បញ្ចប់​ដែល​នៅ​ក្នុង​ផ្នែក "កំណត់ចំណាំដែលបានរួមចំណែករបស់អ្នកប្រើ" នឹងស្មោះត្រង់និង ចម្លើយ​ដែល​បាន​បោះ​ឆ្នោត​ដោយ​អយុត្តិធម៌.

បាទ ឈ្មោះជម្រើសត្រឹមត្រូវគឺ memcached.sess_binary_protocol. វាត្រូវតែត្រូវបានបិទ បន្ទាប់ពីនោះវគ្គនឹងចាប់ផ្តើមដំណើរការ។ អ្វីដែលនៅសល់គឺដាក់កុងតឺន័រជាមួយ mcouter ចូលទៅក្នុងផតជាមួយ PHP!

សេចក្តីសន្និដ្ឋាន

ដូច្នេះ ដោយគ្រាន់តែមានការផ្លាស់ប្តូររចនាសម្ព័ន្ធ យើងអាចដោះស្រាយបញ្ហាបាន៖ បញ្ហាជាមួយនឹងការអត់ឱនកំហុសរបស់ memcached ត្រូវបានដោះស្រាយ ហើយភាពជឿជាក់នៃការផ្ទុកឃ្លាំងសម្ងាត់ត្រូវបានកើនឡើង។ បន្ថែមពីលើគុណសម្បត្តិជាក់ស្តែងសម្រាប់កម្មវិធី នេះបានផ្តល់កន្លែងសម្រាប់ធ្វើសមយុទ្ធនៅពេលធ្វើការនៅលើវេទិកា៖ នៅពេលដែលសមាសធាតុទាំងអស់មានទុនបំរុង នោះជីវិតរបស់អ្នកគ្រប់គ្រងគឺសាមញ្ញណាស់។ បាទ វិធីសាស្រ្តនេះក៏មានគុណវិបត្តិរបស់វាដែរ វាអាចមើលទៅដូចជា "ឈើច្រត់" ប៉ុន្តែប្រសិនបើវាសន្សំលុយ កប់បញ្ហា ហើយមិនបង្កើតថ្មី - ហេតុអ្វីមិនធ្វើ?

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• "អនុវត្តជាមួយ dapp" (ប្រើ symfony-demo ជាឧទាហរណ៍): ផ្នែកទី 1 (បង្កើតកម្មវិធីសាមញ្ញ) и ផ្នែកទី 2 (ការដាក់ពង្រាយរូបភាព Docker ទៅ Kubernetes ដោយប្រើ Helm);
• «ពីជីវិតជាមួយ Kubernetes៖ របៀបដែលម៉ាស៊ីនមេ HTTP មិនពេញចិត្តជនជាតិអេស្ប៉ាញ"។

ប្រភព: www.habr.com