Microservices៖ ទំហំមានសារៈសំខាន់ ទោះបីជាអ្នកមាន Kubernetes ក៏ដោយ។

ថ្ងៃទី ១៩ ខែកញ្ញានៅទីក្រុងមូស្គូ បានកើតឡើង ការប្រជុំប្រធានបទដំបូង HUG (Highload++ User Group) ដែលត្រូវបានឧទ្ទិសដល់សេវាកម្មមីក្រូ។ មានបទបង្ហាញមួយ “ប្រតិបត្តិការខ្នាតតូច៖ បញ្ហាទំហំ ទោះបីជាអ្នកមាន Kubernetes” ដែលយើងចែករំលែកបទពិសោធន៍យ៉ាងទូលំទូលាយរបស់ Flan ក្នុងគម្រោងប្រតិបត្តិការជាមួយស្ថាបត្យកម្មមីក្រូសេវាកម្ម។ ជាដំបូង វានឹងមានប្រយោជន៍សម្រាប់អ្នកអភិវឌ្ឍន៍ទាំងអស់ដែលកំពុងគិតអំពីការប្រើប្រាស់វិធីសាស្រ្តនេះនៅក្នុងគម្រោងបច្ចុប្បន្ន ឬអនាគតរបស់ពួកគេ។

ការណែនាំ វីដេអូនៃរបាយការណ៍ (៥០ នាទី ផ្តល់ព័ត៌មានច្រើនជាងអត្ថបទ) ក៏ដូចជាការដកស្រង់សំខាន់ៗពីវាក្នុងទម្រង់ជាអត្ថបទ។

NB: វីដេអូ និងបទបង្ហាញក៏មាននៅចុងបញ្ចប់នៃការបង្ហោះនេះផងដែរ។

សេចក្តីណែនាំ

ជា​ធម្មតា​រឿង​ដែល​ល្អ​មាន​ការ​ចាប់​ផ្តើម គ្រោង​សំខាន់ និង​ការ​ដោះស្រាយ។ របាយ​ការណ៍​នេះ​គឺ​ដូច​ជា​ការ​លើក​ឡើង​មួយ​និង​សោកនាដកម្ម​នៅ​ទីនោះ​។ វាក៏សំខាន់ផងដែរក្នុងការកត់សម្គាល់ថាវាផ្តល់នូវទិដ្ឋភាពរបស់អ្នកខាងក្រៅចំពោះសេវាកម្មមីក្រូ។ ការកេងប្រវ័ញ្ច.

ខ្ញុំនឹងចាប់ផ្តើមជាមួយនឹងក្រាហ្វនេះ អ្នកនិពន្ធដែល (ក្នុងឆ្នាំ 2015) បានក្លាយជា។ Martin Fowler៖

វាបង្ហាញពីរបៀបនៅក្នុងករណីនៃកម្មវិធី monolithic ដែលឈានដល់តម្លៃជាក់លាក់មួយ ផលិតភាពចាប់ផ្តើមធ្លាក់ចុះ។ Microservices មានភាពខុសប្លែកគ្នាត្រង់ថាផលិតភាពដំបូងជាមួយពួកគេគឺទាបជាង ប៉ុន្តែនៅពេលដែលភាពស្មុគស្មាញកើនឡើង ការរិចរិលនៃប្រសិទ្ធភាពគឺមិនគួរឱ្យកត់សម្គាល់សម្រាប់ពួកគេ។

ខ្ញុំនឹងបន្ថែមទៅក្រាហ្វនេះសម្រាប់ករណីនៃការប្រើប្រាស់ Kubernetes៖

ហេតុអ្វីបានជាកម្មវិធីជាមួយមីក្រូសេវាល្អជាង? ដោយសារតែស្ថាបត្យកម្មបែបនេះផ្តល់នូវតម្រូវការធ្ងន់ធ្ងរសម្រាប់ស្ថាបត្យកម្ម ដែលនៅក្នុងវេនត្រូវបានគ្របដណ្តប់យ៉ាងល្អឥតខ្ចោះដោយសមត្ថភាពរបស់ Kubernetes ។ ម្យ៉ាងវិញទៀត មុខងារមួយចំនួននេះនឹងមានប្រយោជន៍សម្រាប់ monolith ជាពិសេសដោយសារតែ monolith ធម្មតានាពេលបច្ចុប្បន្ននេះ មិនមែនជា monolith ពិតប្រាកដនោះទេ (ព័ត៌មានលម្អិតនឹងមាននៅពេលក្រោយក្នុងរបាយការណ៍)។

ដូចដែលអ្នកអាចមើលឃើញ ក្រាហ្វចុងក្រោយ (នៅពេលដែលទាំងកម្មវិធី monolithic និង microservice ស្ថិតនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធជាមួយ Kubernetes) គឺមិនខុសគ្នាខ្លាំងពីកម្មវិធីដើមនោះទេ។ បន្ទាប់មកយើងនឹងនិយាយអំពីកម្មវិធីដែលដំណើរការដោយប្រើប្រាស់ Kubernetes។

សេវាមីក្រូដែលមានប្រយោជន៍ និងបង្កគ្រោះថ្នាក់

ហើយនេះគឺជាគំនិតចម្បង៖

តើអ្វីទៅ ធម្មតា ស្ថាបត្យកម្ម microservice? វាគួរតែនាំមកជូនអ្នកនូវអត្ថប្រយោជន៍ពិតប្រាកដ បង្កើនប្រសិទ្ធភាពការងាររបស់អ្នក។ ប្រសិនបើយើងត្រលប់ទៅក្រាហ្វវិញ វាគឺ៖

ប្រសិនបើអ្នកហៅនាង មានប្រយោជន៍បន្ទាប់មកនៅផ្នែកម្ខាងទៀតនៃក្រាហ្វនឹងមាន គ្រោះថ្នាក់ សេវាមីក្រូ (រំខានដល់ការងារ)៖

ត្រលប់ទៅ "គំនិតចម្បង"៖ តើខ្ញុំគួរជឿជាក់លើបទពិសោធន៍របស់ខ្ញុំទាំងស្រុងទេ? តាំងពីដើមឆ្នាំនេះ ខ្ញុំបានមើល ៨៥ គម្រោង. មិនមែនទាំងអស់សុទ្ធតែជាសេវាមីក្រូ (ប្រហែលមួយភាគបីទៅពាក់កណ្តាលនៃពួកគេមានស្ថាបត្យកម្មបែបនេះ) ប៉ុន្តែនេះនៅតែមានចំនួនច្រើន។ យើង (ក្រុមហ៊ុន Flant) ក្នុងនាមជាអ្នកផ្គត់ផ្គង់ខាងក្រៅគ្រប់គ្រងដើម្បីមើលកម្មវិធីជាច្រើនដែលត្រូវបានបង្កើតឡើងទាំងនៅក្នុងក្រុមហ៊ុនតូចៗ (ជាមួយអ្នកអភិវឌ្ឍន៍ 5 នាក់) និងនៅក្នុងក្រុមហ៊ុនធំ (~ 500 អ្នកអភិវឌ្ឍន៍)។ អត្ថប្រយោជន៍បន្ថែមគឺថាយើងឃើញកម្មវិធីទាំងនេះរស់នៅ និងវិវឌ្ឍក្នុងរយៈពេលជាច្រើនឆ្នាំ។

ហេតុអ្វីបានជាសេវាមីក្រូ?

ចំពោះសំណួរអំពីអត្ថប្រយោជន៍នៃសេវាមីក្រូមាន ចម្លើយជាក់លាក់ណាស់។ ពី Martin Fowler ដែលបានរៀបរាប់រួចហើយ៖

1. ព្រំដែនច្បាស់លាស់នៃម៉ូឌុល;
2. ការដាក់ពង្រាយឯករាជ្យ;
3. សេរីភាពក្នុងការជ្រើសរើសបច្ចេកវិទ្យា។

ខ្ញុំបាននិយាយច្រើនជាមួយស្ថាបត្យករ និងអ្នកអភិវឌ្ឍន៍កម្មវិធី ហើយសួរថាហេតុអ្វីបានជាពួកគេត្រូវការសេវាមីក្រូ។ ហើយខ្ញុំបានធ្វើបញ្ជីរបស់ខ្ញុំតាមការរំពឹងទុករបស់ពួកគេ។ នេះជាអ្វីដែលបានកើតឡើង៖

ប្រសិនបើយើងពិពណ៌នាអំពីចំណុចមួយចំនួន “ក្នុងអារម្មណ៍” នោះ៖

• ព្រំដែនច្បាស់លាស់នៃម៉ូឌុល៖ នៅទីនេះយើងមាន monolith ដ៏គួរឱ្យភ័យខ្លាចហើយឥឡូវនេះអ្វីគ្រប់យ៉ាងនឹងត្រូវបានរៀបចំយ៉ាងស្អាតនៅក្នុងឃ្លាំង Git ដែលអ្វីៗទាំងអស់គឺ "នៅលើធ្នើ" ភាពកក់ក្តៅនិងទន់មិនត្រូវបានលាយបញ្ចូលគ្នាទេ។
• ឯករាជ្យនៃការដាក់ពង្រាយ៖ យើងនឹងអាចដាក់ចេញសេវាកម្មដោយឯករាជ្យ ដើម្បីឱ្យការអភិវឌ្ឍន៍កាន់តែលឿន (ផ្សព្វផ្សាយមុខងារថ្មីៗស្របគ្នា);
• ឯករាជ្យភាពនៃការអភិវឌ្ឍន៍៖ យើងអាចផ្តល់សេវាមីក្រូនេះដល់ក្រុមមួយ/អ្នកអភិវឌ្ឍន៍ ហើយមួយទៅក្រុមមួយទៀត អរគុណដែលយើងអាចអភិវឌ្ឍបានលឿនជាងមុន។
• боភាពជឿជាក់កាន់តែច្រើន៖ ប្រសិនបើការរិចរិលដោយផ្នែកកើតឡើង (សេវាមីក្រូមួយក្នុងចំនោម 20 ធ្លាក់) នោះប៊ូតុងតែមួយនឹងឈប់ដំណើរការ ហើយប្រព័ន្ធទាំងមូលនឹងបន្តដំណើរការ។

ស្ថាបត្យកម្មមីក្រូសេវាធម្មតា (បង្កគ្រោះថ្នាក់)

ដើម្បីពន្យល់ពីមូលហេតុដែលការពិតមិនមែនជាអ្វីដែលយើងរំពឹងទុក ខ្ញុំនឹងបង្ហាញជូន សមូហភាព រូបភាពនៃស្ថាបត្យកម្មមីក្រូសេវាផ្អែកលើបទពិសោធន៍ពីគម្រោងផ្សេងៗគ្នាជាច្រើន។

ឧទាហរណ៍មួយនឹងជាហាងអនឡាញអរូបីដែលនឹងប្រកួតប្រជែងជាមួយ Amazon ឬយ៉ាងហោចណាស់ OZON ។ ស្ថាបត្យកម្ម microservice របស់វាមើលទៅដូចនេះ៖

សម្រាប់ការរួមបញ្ចូលគ្នានៃហេតុផល សេវាមីក្រូទាំងនេះត្រូវបានសរសេរនៅលើវេទិកាផ្សេងៗគ្នា៖

ដោយសារសេវាមីក្រូនីមួយៗត្រូវតែមានស្វ័យភាព ពួកគេជាច្រើនត្រូវការមូលដ្ឋានទិន្នន័យ និងឃ្លាំងសម្ងាត់ផ្ទាល់ខ្លួនរបស់ពួកគេ។ ស្ថាបត្យកម្មចុងក្រោយមានដូចខាងក្រោម៖

តើ​មាន​ផល​វិបាក​អ្វី​ខ្លះ?

Fowler ក៏មានរឿងនេះដែរ។ មានអត្ថបទមួយ។ - អំពី "ការទូទាត់" សម្រាប់ការប្រើប្រាស់សេវាមីក្រូ៖

ហើយយើងនឹងមើលថាតើការរំពឹងទុករបស់យើងត្រូវបានបំពេញ។

ជម្រះ​ព្រំដែន​នៃ​ម៉ូឌុល...

ប៉ុន្តែ តើ​យើង​ត្រូវ​ជួសជុល​មីក្រូ​សេវា​ប៉ុន្មាន​?ដើម្បីចាប់ផ្តើមការផ្លាស់ប្តូរ? តើយើងអាចគិតថាតើអ្វីៗដំណើរការដោយរបៀបណាដោយគ្មានដានចែកចាយ (បន្ទាប់ពីទាំងអស់ សំណើណាមួយត្រូវបានដំណើរការដោយពាក់កណ្តាលនៃសេវាមីក្រូ)?

មានលំនាំ "ដុំដីដ៏ធំ“ ហើយនៅទីនេះវាបានប្រែក្លាយទៅជាដុំដីដែលចែកចាយ។ ដើម្បីបញ្ជាក់នេះ នេះគឺជាការបង្ហាញប្រហាក់ប្រហែលនៃរបៀបដែលសំណើទៅ៖

ឯករាជ្យភាពនៃការដាក់ពង្រាយ...

តាមបច្ចេកទេស វាត្រូវបានសម្រេច៖ យើងអាចដាក់ចេញសេវាមីក្រូនីមួយៗដោយឡែកពីគ្នា។ ប៉ុន្តែនៅក្នុងការអនុវត្តអ្នកត្រូវយកទៅក្នុងគណនីដែលវាតែងតែរមៀលចេញ សេវាមីក្រូជាច្រើន។ហើយយើងត្រូវយកទៅពិចារណា លំដាប់នៃការចេញរបស់ពួកគេ។. តាមរបៀបដ៏ល្អ ជាទូទៅយើងត្រូវធ្វើតេស្តនៅក្នុងសៀគ្វីដាច់ដោយឡែកមួយថាតើយើងកំពុងដំណើរការការចេញផ្សាយតាមលំដាប់ត្រឹមត្រូវដែរឬទេ។

សេរីភាពក្នុងការជ្រើសរើសបច្ចេកវិទ្យា...

នាង​គឺ។ សូមចាំថា សេរីភាពច្រើនតែជាប់ព្រំដែនលើភាពគ្មានច្បាប់។ វាមានសារៈសំខាន់ណាស់នៅទីនេះមិនត្រូវជ្រើសរើសបច្ចេកវិទ្យាដើម្បី "លេង" ជាមួយពួកគេ។

ឯករាជ្យភាពនៃការអភិវឌ្ឍន៍...

តើធ្វើដូចម្តេចដើម្បីធ្វើឱ្យរង្វិលជុំសាកល្បងសម្រាប់កម្មវិធីទាំងមូល (ជាមួយសមាសធាតុជាច្រើន)? ប៉ុន្តែអ្នកនៅតែត្រូវរក្សាវាឱ្យទាន់សម័យ។ ទាំងអស់នេះនាំទៅរកការពិតដែលថា ចំនួនពិតនៃសៀគ្វីសាកល្បងដែលយើងអាចជាគោលការណ៍មាន វាប្រែជាតិចតួចបំផុត។.

តើ​ការ​ដាក់​ពង្រាយ​អ្វី​ទាំង​អស់​នេះ​នៅ​ក្នុង​ស្រុក​យ៉ាង​ណា?... វា​ប្រែ​ថា​ជា​ញឹក​ញាប់​អ្នក​អភិវឌ្ឍន៍​ធ្វើ​ការ​ដោយ​ឯករាជ្យ ប៉ុន្តែ "ចៃដន្យ" ដោយ​សារ​គាត់​ត្រូវ​បាន​បង្ខំ​ឱ្យ​រង់ចាំ​រហូត​ដល់​សៀគ្វី​ទំនេរ​សម្រាប់​ការ​សាកល្បង។

ការធ្វើមាត្រដ្ឋានដោយឡែក...

បាទ / ចាសប៉ុន្តែវាត្រូវបានកំណត់នៅក្នុងតំបន់នៃ DBMS ដែលបានប្រើ។ នៅក្នុងឧទាហរណ៍ស្ថាបត្យកម្មដែលបានផ្តល់ឱ្យ Cassandra នឹងមិនមានបញ្ហាទេប៉ុន្តែ MySQL និង PostgreSQL នឹង។

Боភាពជឿជាក់កាន់តែខ្លាំង...

មិនត្រឹមតែការបរាជ័យនៃសេវាមីក្រូមួយនៅក្នុងការពិតជាញឹកញាប់ធ្វើឱ្យខូចមុខងារត្រឹមត្រូវនៃប្រព័ន្ធទាំងមូលប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានបញ្ហាថ្មីមួយផងដែរ៖ ការធ្វើឱ្យរាល់ microservice មានភាពអត់ធ្មត់គឺពិបាកណាស់។. ដោយសារតែសេវាកម្មមីក្រូប្រើប្រាស់បច្ចេកវិទ្យាផ្សេងៗគ្នា (memcache, Redis ។

ការផ្ទុកការវាស់វែង...

នេះពិតជាល្អណាស់។

"ពន្លឺ" នៃសេវាកម្មមីក្រូ...

យើងមិនត្រឹមតែមានធំប៉ុណ្ណោះទេ បណ្តាញលើស (សំណើ DNS កំពុងកើនឡើង ចម្លងទិន្នន័យ (ឃ្លាំងផ្ទុកទិន្នន័យ) ដែលនាំទៅដល់ទំហំផ្ទុកយ៉ាងច្រើន។

ហើយនេះគឺជាលទ្ធផលនៃការបំពេញតាមការរំពឹងទុករបស់យើង៖

ប៉ុន្តែនោះមិនមែនទាំងអស់ទេ!

ដោយសារតែ៖

• ភាគច្រើនទំនងជាយើងនឹងត្រូវការឡានក្រុងសារ។
• តើធ្វើដូចម្តេចដើម្បីធ្វើឱ្យការបម្រុងទុកជាប់លាប់នៅពេលត្រឹមត្រូវក្នុងពេលវេលា? តែមួយគត់ ពិតប្រាកដ ជម្រើសគឺដើម្បីបិទចរាចរណ៍សម្រាប់ការនេះ។ ប៉ុន្តែតើធ្វើដូចម្តេចដើម្បីធ្វើរឿងនេះនៅក្នុងផលិតកម្ម?
• ប្រសិនបើយើងកំពុងនិយាយអំពីការជួយដល់តំបន់មួយចំនួន នោះការរៀបចំនិរន្តរភាពនៅក្នុងពួកគេនីមួយៗ គឺជាការងារដែលពឹងផ្អែកខ្លាំងលើកម្លាំងពលកម្ម។
• បញ្ហានៃការផ្លាស់ប្តូរកណ្តាលកើតឡើង។ ឧទាហរណ៍ ប្រសិនបើយើងត្រូវការធ្វើបច្ចុប្បន្នភាពកំណែ PHP នោះ យើងនឹងត្រូវការប្តេជ្ញាចិត្តចំពោះឃ្លាំងនីមួយៗ (ហើយវាមានរាប់សិប)។
• ការរីកចម្រើននៃភាពស្មុគស្មាញនៃប្រតិបត្តិការគឺ ហួសចិត្ត និទស្សន្ត។

អ្វីដែលត្រូវធ្វើជាមួយទាំងអស់នេះ?

ចាប់ផ្តើមជាមួយកម្មវិធី monolithic. បទពិសោធន៍របស់ Fowler និយាយ ថាកម្មវិធីមីក្រូសេវាជោគជ័យស្ទើរតែទាំងអស់បានចាប់ផ្តើមជា monolith ដែលធំពេក ហើយក្រោយមកត្រូវបានខូច។ ក្នុងពេលជាមួយគ្នានោះ ប្រព័ន្ធស្ទើរតែទាំងអស់ដែលត្រូវបានបង្កើតឡើងជាសេវាមីក្រូតាំងពីដំបូង ឆាប់ឬក្រោយមកជួបប្រទះបញ្ហាធ្ងន់ធ្ងរ។

គំនិតដ៏មានតម្លៃមួយទៀតគឺថា សម្រាប់គម្រោងដែលមានស្ថាបត្យកម្មមីក្រូសេវាដើម្បីទទួលបានជោគជ័យ អ្នកត្រូវតែដឹងយ៉ាងច្បាស់ និងប្រធានបទ និងរបៀបបង្កើតសេវាកម្មមីក្រូ. ហើយវិធីល្អបំផុតក្នុងការរៀនមុខវិជ្ជាគឺ បង្កើត monolith ។

ប៉ុន្តែចុះយ៉ាងណាបើយើងស្ថិតក្នុងស្ថានភាពនេះ?

ជំហានដំបូងក្នុងការដោះស្រាយបញ្ហាណាមួយគឺត្រូវយល់ព្រមជាមួយវា ហើយយល់ថាវាជាបញ្ហា ដែលយើងមិនចង់រងទុក្ខទៀតទេ។

ប្រសិនបើនៅក្នុងករណីនៃ monolith មួយ overgrown (នៅពេលដែលយើងអស់ឱកាសដើម្បីទិញធនធានបន្ថែមសម្រាប់វា) យើងបានកាត់បន្ថយវាបន្ទាប់មកក្នុងករណីនេះរឿងផ្ទុយបានប្រែក្លាយ: នៅពេលដែល microservices ហួសប្រមាណលែងជួយ, ប៉ុន្តែរារាំង - កាត់លើសនិងពង្រីក!

ឧទាហរណ៍ សម្រាប់រូបភាពរួមដែលបានពិភាក្សាខាងលើ...

កម្ចាត់សេវាមីក្រូដែលគួរឱ្យសង្ស័យបំផុត៖

រួមបញ្ចូលគ្នានូវសេវាកម្មមីក្រូទាំងអស់ដែលទទួលខុសត្រូវសម្រាប់ការបង្កើតផ្នែកខាងមុខ៖

... ចូលទៅក្នុងសេវាមីក្រូមួយ ដែលសរសេរក្នុងមួយ (ទំនើប និងធម្មតា ដូចដែលអ្នកគិត) ភាសា/ក្របខ័ណ្ឌ៖

វានឹងមាន ORM មួយ (DBMS មួយ) និងកម្មវិធីពីរបីដំបូង៖

... ប៉ុន្តែជាទូទៅ អ្នកអាចផ្ទេរបានច្រើននៅទីនោះ ដោយទទួលបានលទ្ធផលដូចខាងក្រោម៖

ជាងនេះទៅទៀត នៅក្នុង Kubernetes យើងដំណើរការទាំងអស់នេះនៅក្នុងករណីដាច់ដោយឡែក ដែលមានន័យថាយើងនៅតែអាចវាស់បន្ទុក និងធ្វើមាត្រដ្ឋានដោយឡែកពីគ្នា។

សង្ខេប

សូមក្រឡេកមើលរូបភាពធំជាងនេះ។ ជាញឹកញយ បញ្ហាទាំងអស់នេះជាមួយសេវាមីក្រូ កើតឡើងដោយសារតែមាននរណាម្នាក់បានយកភារកិច្ចរបស់ពួកគេ ប៉ុន្តែចង់ "លេងជាមួយសេវាមីក្រូ"។

នៅក្នុងពាក្យ "សេវាមីក្រូ" ផ្នែក "មីក្រូ" គឺមិនអាចខ្វះបាន។. ពួកវាជា "មីក្រូ" តែប៉ុណ្ណោះ ព្រោះវាតូចជាងម៉ូណូលីតដ៏ធំ។ ប៉ុន្តែកុំគិតថាវាជារឿងតូចតាច។

ហើយសម្រាប់ការគិតចុងក្រោយ សូមត្រលប់ទៅតារាងដើមវិញ៖

កំណត់ចំណាំមួយសរសេរនៅលើវា។ (ខាងលើស្តាំ) ពុះកញ្ជ្រោលទៅនឹងការពិតដែលថា ជំនាញរបស់ក្រុមដែលបង្កើតគម្រោងរបស់អ្នកគឺតែងតែជាចម្បង — ពួកគេនឹងដើរតួយ៉ាងសំខាន់ក្នុងជម្រើសរបស់អ្នករវាងសេវាមីក្រូ និងម៉ូណូលីត។ ប្រសិនបើក្រុមមិនមានជំនាញគ្រប់គ្រាន់ ប៉ុន្តែចាប់ផ្តើមបង្កើតសេវាមីក្រូ នោះរឿងនឹងអាចស្លាប់ជាមិនខាន។

វីដេអូ និងស្លាយ

វីដេអូពីសុន្ទរកថា (~50 នាទី ជាអកុសល វាមិនបង្ហាញពីអារម្មណ៍ជាច្រើនរបស់អ្នកទស្សនាទេ ដែលភាគច្រើនកំណត់អារម្មណ៍នៃរបាយការណ៍ ប៉ុន្តែនោះជារបៀបដែលវា):

បទបង្ហាញនៃរបាយការណ៍៖

PS

របាយការណ៍ផ្សេងទៀតនៅលើប្លក់របស់យើង៖

• «ការត្រួតពិនិត្យ និង Kubernetes» (Dmitry Stolyarov; 28 ឧសភា 2018 នៅ RootConf);
• «CI/CD ការអនុវត្តល្អបំផុតជាមួយ Kubernetes និង GitLab» (Dmitry Stolyarov; ថ្ងៃទី 7 ខែវិច្ឆិកាឆ្នាំ 2017 នៅលើ HighLoad ++);
• «បទពិសោធន៍របស់យើងជាមួយ Kubernetes ក្នុងគម្រោងតូចៗ» (Dmitry Stolyarov; ថ្ងៃទី 6 ខែមិថុនា ឆ្នាំ 2017 នៅ RootConf);
• «យើងបង្កើតរូបភាព Docker សម្រាប់ CI/CD យ៉ាងរហ័ស និងងាយស្រួលជាមួយ dapp» (Dmitry Stolyarov; ថ្ងៃទី 8 ខែវិច្ឆិកាឆ្នាំ 2016 នៅលើ HighLoad ++);
• «ការអនុវត្តការចែកចាយបន្តជាមួយ Docker» (Dmitry Stolyarov; 31 ឧសភា 2016 នៅ RootConf).

អ្នកក៏អាចចាប់អារម្មណ៍លើការបោះពុម្ពខាងក្រោម៖

• «ការ​ស្លាប់​នៃ​ការ​ឆ្កួត​នឹង​សេវា​មីក្រូ​ក្នុង​ឆ្នាំ 2018»
• «ការអនុវត្តល្អបំផុតចំនួន 7 សម្រាប់ការប្រើប្រាស់កុងតឺន័រយោងទៅតាម Google»
• «ស្ថិតិពី The New Stack ស្តីពីបញ្ហាប្រឈមនៃការអនុវត្ត Kubernetes"។

ប្រភព: www.habr.com