រឿងនេះនិយាយអំពីរបៀបដែលយើងប្រើកុងតឺន័រនៅក្នុងបរិយាកាសផលិតកម្ម ជាពិសេស Kubernetes ។ អត្ថបទនេះត្រូវបានឧទ្ទិសដល់ការប្រមូលម៉ែត្រ និងកំណត់ហេតុពីកុងតឺន័រ ក៏ដូចជារូបភាពសាងសង់។

យើងមកពីក្រុមហ៊ុន fintech Exness ដែលអភិវឌ្ឍសេវាកម្មសម្រាប់ការជួញដូរតាមអ៊ីនធឺណិត និងផលិតផល fintech សម្រាប់ B2B និង B2C ។ R&D របស់យើងមានក្រុមផ្សេងៗគ្នាជាច្រើន នាយកដ្ឋានអភិវឌ្ឍន៍មានបុគ្គលិក 100+។

យើងតំណាងឱ្យក្រុមដែលទទួលខុសត្រូវលើវេទិកាសម្រាប់អ្នកអភិវឌ្ឍន៍របស់យើងក្នុងការប្រមូល និងដំណើរការកូដ។ ជាពិសេស យើងទទួលខុសត្រូវក្នុងការប្រមូល រក្សាទុក និងរាយការណ៍ម៉ែត្រ កំណត់ហេតុ និងព្រឹត្តិការណ៍ពីកម្មវិធី។ បច្ចុប្បន្នយើងដំណើរការកុងតឺន័រ Docker ប្រមាណជាបីពាន់នៅក្នុងបរិយាកាសផលិតកម្ម រក្សាការផ្ទុកទិន្នន័យធំ 50 TB របស់យើង និងផ្តល់នូវដំណោះស្រាយស្ថាបត្យកម្មដែលត្រូវបានសាងសង់ជុំវិញហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង៖ Kubernetes, Rancher និងអ្នកផ្តល់សេវាពពកសាធារណៈផ្សេងៗ។ 

ការលើកទឹកចិត្តរបស់យើង។

តើ​អ្វី​កំពុង​ឆេះ? គ្មាននរណាម្នាក់អាចឆ្លើយបានទេ។ តើឡៅតឿនៅឯណា? វាពិបាកយល់ណាស់។ តើវាឆេះនៅពេលណា? អ្នកអាចរកឃើញប៉ុន្តែមិនភ្លាមៗទេ។ 

ហេតុអ្វីបានជាកុងតឺន័រខ្លះឈរ ខណៈខ្លះទៀតធ្លាក់? តើធុងមួយណាដែលត្រូវស្តីបន្ទោស? យ៉ាងណាមិញនៅខាងក្រៅធុងគឺដូចគ្នាប៉ុន្តែនៅខាងក្នុងនីមួយៗមាន Neo ផ្ទាល់ខ្លួន។

អ្នកអភិវឌ្ឍន៍របស់យើងគឺជាបុរសដែលមានសមត្ថភាព។ ពួកគេបង្កើតសេវាកម្មល្អដែលនាំមកនូវប្រាក់ចំណេញដល់ក្រុមហ៊ុន។ ប៉ុន្តែមានការបរាជ័យនៅពេលដែលកុងតឺន័រដែលមានកម្មវិធីវង្វេង។ កុងតឺន័រមួយប្រើប្រាស់ស៊ីភីយូច្រើនពេក មួយទៀតប្រើប្រាស់បណ្តាញ ទីបីប្រើប្រាស់ប្រតិបត្តិការ I/O ហើយទីបួនមិនច្បាស់ថាវាធ្វើអ្វីជាមួយរន្ធនោះទេ។ វាធ្លាក់ទាំងអស់ហើយកប៉ាល់លិច។ 

ភ្នាក់ងារ

ដើម្បីយល់ពីអ្វីដែលកំពុងកើតឡើងនៅខាងក្នុង យើងបានសម្រេចចិត្តដាក់ភ្នាក់ងារដោយផ្ទាល់នៅក្នុងធុង។

ភ្នាក់ងារទាំងនេះកំពុងរារាំងកម្មវិធីដែលរក្សាកុងតឺន័រក្នុងស្ថានភាពមួយដែលពួកគេមិនធ្វើឱ្យខូចគ្នាទៅវិញទៅមក។ ភ្នាក់ងារត្រូវបានធ្វើឱ្យមានស្តង់ដារ ហើយនេះអនុញ្ញាតឱ្យមានវិធីសាស្រ្តស្ដង់ដារសម្រាប់សេវាកម្មធុង។ 

ក្នុងករណីរបស់យើង ភ្នាក់ងារត្រូវតែផ្តល់កំណត់ហេតុក្នុងទម្រង់ស្តង់ដារ ដាក់ស្លាក និងបិទបើក។ ពួកគេក៏គួរតែផ្តល់ឱ្យយើងនូវមាត្រដ្ឋានស្តង់ដារដែលអាចពង្រីកបានតាមទស្សនៈកម្មវិធីអាជីវកម្ម។

ភ្នាក់ងារក៏មានន័យថាឧបករណ៍ប្រើប្រាស់សម្រាប់ប្រតិបត្តិការ និងការថែទាំដែលអាចធ្វើការនៅក្នុងប្រព័ន្ធ orchestration ផ្សេងៗដែលគាំទ្ររូបភាពផ្សេងៗគ្នា (Debian, Alpine, Centos ។ល។)។

ជាចុងក្រោយ ភ្នាក់ងារត្រូវតែគាំទ្រ CI/CD សាមញ្ញ ដែលរួមបញ្ចូលឯកសារ Docker ។ បើមិនដូច្នេះទេ កប៉ាល់នឹងដាច់ចេញពីគ្នា ពីព្រោះកុងតឺន័រនឹងចាប់ផ្តើមដឹកជញ្ជូនតាមផ្លូវរថភ្លើង "កោង"។

បង្កើតដំណើរការ និងឧបករណ៍រូបភាពគោលដៅ

ដើម្បីរក្សាអ្វីៗគ្រប់យ៉ាងឱ្យមានលក្ខណៈស្តង់ដារ និងអាចគ្រប់គ្រងបាន ប្រភេទនៃដំណើរការសាងសង់ស្តង់ដារមួយចំនួនចាំបាច់ត្រូវអនុវត្តតាម។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តប្រមូលកុងតឺន័រដោយកុងតឺន័រ - នេះគឺជាការនិយាយឡើងវិញ។

នៅទីនេះធុងត្រូវបានតំណាងដោយគ្រោងរឹង។ ក្នុងពេលជាមួយគ្នានេះ ពួកគេបានសម្រេចចិត្តដាក់ឧបករណ៍ចែកចាយនៅក្នុងពួកគេ ដើម្បី "ជីវិតហាក់ដូចជាមិនដូចផ្លែ Raspberry" ។ ហេតុអ្វីបានជាវាត្រូវបានធ្វើ យើងនឹងពន្យល់ខាងក្រោម។
 
លទ្ធផល​គឺ​ជា​ឧបករណ៍​បង្កើត—ធុង​ផ្ទុក​កំណែ​ជាក់លាក់​ដែល​យោង​កំណែ​ចែកចាយ​ជាក់លាក់ និង​កំណែ​ស្គ្រីប​ជាក់លាក់។

តើយើងប្រើវាដោយរបៀបណា? យើងមាន Docker Hub ដែលមានកុងតឺន័រ។ យើងឆ្លុះវានៅខាងក្នុងប្រព័ន្ធរបស់យើង ដើម្បីកម្ចាត់ភាពអាស្រ័យខាងក្រៅ។ លទ្ធផលគឺធុងមួយដែលមានពណ៌លឿង។ យើងបង្កើតគំរូមួយដើម្បីដំឡើងការចែកចាយ និងស្គ្រីបទាំងអស់ដែលយើងត្រូវការទៅក្នុងកុងតឺន័រ។ បន្ទាប់ពីនោះ យើងប្រមូលផ្តុំរូបភាពដែលត្រៀមរួចជាស្រេចសម្រាប់ប្រើប្រាស់៖ អ្នកអភិវឌ្ឍន៍ដាក់កូដ និងភាពអាស្រ័យពិសេសមួយចំនួនរបស់ពួកគេទៅក្នុងវា។ 

តើ​មាន​អ្វី​ល្អ​ចំពោះ​វិធីសាស្ត្រ​នេះ? 

• ទីមួយ ការគ្រប់គ្រងកំណែពេញលេញនៃឧបករណ៍សាងសង់ - បង្កើតកុងតឺន័រ ស្គ្រីប និងកំណែចែកចាយ។ 
• ទីពីរ យើងបានសម្រេចស្តង់ដារ៖ យើងបង្កើតគំរូរូបភាពកម្រិតមធ្យម និងត្រៀមរួចរាល់ក្នុងការប្រើប្រាស់តាមរបៀបដូចគ្នា។ 
• ទីបី កុងតឺន័រផ្តល់ឱ្យយើងនូវភាពចល័ត។ ថ្ងៃនេះយើងប្រើ Gitlab ហើយថ្ងៃស្អែកយើងនឹងប្តូរទៅ TeamCity ឬ Jenkins ហើយយើងនឹងអាចដំណើរការកុងតឺន័ររបស់យើងតាមរបៀបដូចគ្នា។ 
• ទី៤ កាត់បន្ថយភាពអាស្រ័យ។ វាមិនមែនជារឿងចៃដន្យទេដែលយើងដាក់ឧបករណ៍ចែកចាយនៅក្នុងកុងតឺន័រ ពីព្រោះវាអនុញ្ញាតឱ្យយើងជៀសវាងការទាញយកវាពីអ៊ីនធឺណិតរាល់ពេល។ 
• ទីប្រាំ ល្បឿនសាងសង់បានកើនឡើង - វត្តមាននៃរូបភាពចម្លងក្នុងស្រុកអនុញ្ញាតឱ្យអ្នកជៀសវាងការខ្ជះខ្ជាយពេលវេលាក្នុងការទាញយក ព្រោះមានរូបភាពក្នុងស្រុក។ 

ម្យ៉ាងវិញទៀត យើងសម្រេចបាននូវដំណើរការដំឡើងដែលអាចគ្រប់គ្រងបាន និងអាចបត់បែនបាន។ យើងប្រើឧបករណ៍ដូចគ្នាដើម្បីបង្កើតធុងដែលមានកំណែពេញលេញ។ 

របៀបដែលដំណើរការសាងសង់របស់យើងដំណើរការ

ការជួបប្រជុំគ្នាត្រូវបានដាក់ឱ្យដំណើរការដោយប្រើពាក្យបញ្ជាមួយដំណើរការត្រូវបានប្រតិបត្តិក្នុងរូបភាព (បន្លិចជាពណ៌ក្រហម) ។ អ្នកអភិវឌ្ឍន៍មានឯកសារ Docker (បន្លិចជាពណ៌លឿង) យើងបង្ហាញវាដោយជំនួសអថេរជាមួយនឹងតម្លៃ។ ហើយនៅតាមផ្លូវយើងបន្ថែមបឋមកថានិងបាតកថា - ទាំងនេះគឺជាភ្នាក់ងាររបស់យើង។ 

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

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

ដោយសារយើងប្រើប្រព័ន្ធ orchestration ផ្សេងៗគ្នា បន្ទាប់ពីសាងសង់ និងដំណើរការ កុងតឺន័រត្រូវតែយល់ថាវាស្ថិតនៅក្នុងបរិយាកាសបែបណា ហើយធ្វើសកម្មភាពទៅតាមស្ថានភាព។ ឧទាហរណ៍:
នេះអនុញ្ញាតឱ្យយើងបង្កើតរូបភាពមួយ ហើយដំណើរការវានៅក្នុងប្រព័ន្ធវង់ភ្លេងផ្សេងៗគ្នា ហើយវានឹងត្រូវបានដាក់ឱ្យដំណើរការដោយគិតគូរពីលក្ខណៈជាក់លាក់នៃប្រព័ន្ធវង់ភ្លេងនេះ។

 

សម្រាប់កុងតឺន័រដូចគ្នា យើងទទួលបានមែកធាងដំណើរការផ្សេងៗគ្នានៅក្នុង Docker និង Kubernetes៖

បន្ទុកត្រូវបានប្រតិបត្តិក្រោមការត្រួតពិនិត្យរបស់ S6 ។ យកចិត្តទុកដាក់ចំពោះអ្នកប្រមូល និងព្រឹត្តិការណ៍ - ទាំងនេះគឺជាភ្នាក់ងាររបស់យើងដែលទទួលខុសត្រូវចំពោះកំណត់ហេតុ និងម៉ែត្រ។ Kubernetes មិនមានពួកវាទេ ប៉ុន្តែ Docker មាន។ ហេតុអ្វី? 

ប្រសិនបើយើងក្រឡេកមើលលក្ខណៈជាក់លាក់នៃ “pod” (តទៅនេះ – Kubernetes pod) យើងនឹងឃើញថាធុងព្រឹត្តិការណ៍ត្រូវបានប្រតិបត្តិក្នុង pod ដែលមានធុងប្រមូលដាច់ដោយឡែកដែលអនុវត្តមុខងារនៃការប្រមូលម៉ែត្រ និងកំណត់ហេតុ។ យើងអាចប្រើសមត្ថភាពរបស់ Kubernetes៖ កំពុងដំណើរការកុងតឺន័រក្នុងផតតែមួយ ក្នុងដំណើរការតែមួយ និង/ឬទំហំបណ្តាញ។ ណែនាំភ្នាក់ងាររបស់អ្នក និងអនុវត្តមុខងារមួយចំនួន។ ហើយប្រសិនបើកុងតឺន័រដូចគ្នាត្រូវបានបើកដំណើរការនៅក្នុង Docker នោះវានឹងទទួលបាននូវសមត្ថភាពដូចគ្នាទាំងអស់ជាមួយនឹងទិន្នផល ពោលគឺវានឹងអាចផ្តល់កំណត់ហេតុ និងម៉ែត្រ ចាប់តាំងពីភ្នាក់ងារនឹងត្រូវបានដាក់ឱ្យដំណើរការនៅខាងក្នុង។ 

ម៉ែត្រនិងកំណត់ហេតុ

ការផ្តល់ម៉ែត្រ និងកំណត់ហេតុគឺជាកិច្ចការដ៏ស្មុគស្មាញមួយ។ មានទិដ្ឋភាពជាច្រើនចំពោះការសម្រេចចិត្តរបស់នាង។
ហេដ្ឋារចនាសម្ព័ន្ធ​ត្រូវ​បាន​បង្កើត​ឡើង​សម្រាប់​ការ​ប្រតិបត្តិ​នៃ​បន្ទុក ហើយ​មិន​មែន​សម្រាប់​ការ​ចែកចាយ​កំណត់ហេតុ​ច្រើន​ទេ។ នោះគឺជាដំណើរការនេះត្រូវតែត្រូវបានអនុវត្តជាមួយនឹងតម្រូវការធនធានធុងអប្បបរមា។ យើងខិតខំជួយអ្នកអភិវឌ្ឍន៍របស់យើង៖ "យកធុង Docker Hub ដំណើរការវា ហើយយើងអាចចែកចាយកំណត់ហេតុបាន។" 

ទិដ្ឋភាពទីពីរគឺការកំណត់បរិមាណនៃកំណត់ហេតុ។ ប្រសិនបើការកើនឡើងនៃបរិមាណកំណត់ហេតុកើតឡើងនៅក្នុងកុងតឺន័រជាច្រើន (កម្មវិធីបញ្ចេញនូវដានជង់ក្នុងរង្វិលជុំ) ការផ្ទុកនៅលើស៊ីភីយូ បណ្តាញទំនាក់ទំនង និងប្រព័ន្ធដំណើរការកំណត់ហេតុកើនឡើង ហើយនេះប៉ះពាល់ដល់ប្រតិបត្តិការរបស់ម៉ាស៊ីនជា ធុងទាំងមូលនិងផ្សេងទៀតនៅលើម៉ាស៊ីនបន្ទាប់មកជួនកាលវានាំឱ្យ "ធ្លាក់" នៃម៉ាស៊ីន។ 

ទិដ្ឋភាពទីបីគឺថាវាចាំបាច់ដើម្បីគាំទ្រវិធីសាស្រ្តប្រមូលម៉ែត្រឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបានចេញពីប្រអប់។ ពីការអានឯកសារ និងការស្ទង់មតិ Prometheus-endpoint ដល់ការប្រើប្រាស់ពិធីការជាក់លាក់របស់កម្មវិធី។

ហើយទិដ្ឋភាពចុងក្រោយគឺកាត់បន្ថយការប្រើប្រាស់ធនធាន។

យើងបានជ្រើសរើសដំណោះស្រាយ Go ប្រភពបើកចំហដែលហៅថា Telegraf ។ នេះគឺជាឧបករណ៍ភ្ជាប់សកលដែលគាំទ្រច្រើនជាង 140 ប្រភេទនៃឆានែលបញ្ចូល (កម្មវិធីជំនួយបញ្ចូល) និង 30 ប្រភេទនៃឆានែលទិន្នផល (កម្មវិធីជំនួយលទ្ធផល) ។ យើងបានបញ្ចប់វាហើយ ឥឡូវនេះយើងនឹងប្រាប់អ្នកពីរបៀបដែលយើងប្រើវាដោយប្រើ Kubernetes ជាឧទាហរណ៍។ 

ចូរនិយាយថាអ្នកអភិវឌ្ឍន៍ដាក់ពង្រាយបន្ទុកការងារ ហើយ Kubernetes ទទួលបានសំណើដើម្បីបង្កើតផត។ នៅចំណុចនេះ កុងតឺន័រដែលហៅថា Collector ត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិសម្រាប់ផតនីមួយៗ (យើងប្រើ webhook ផ្លាស់ប្តូរ)។ អ្នកប្រមូលគឺជាភ្នាក់ងាររបស់យើង។ នៅពេលចាប់ផ្តើម កុងតឺន័រនេះកំណត់រចនាសម្ព័ន្ធខ្លួនវាដើម្បីធ្វើការជាមួយ Prometheus និងប្រព័ន្ធប្រមូលកំណត់ហេតុ។

• ដើម្បីធ្វើដូចនេះវាប្រើចំណារពន្យល់របស់ pod ហើយអាស្រ័យលើខ្លឹមសាររបស់វា បង្កើត និយាយថា Prometheus end-point; 
• ដោយផ្អែកលើការកំណត់របស់ផត និងការកំណត់កុងតឺន័រជាក់លាក់ វាសម្រេចចិត្តពីរបៀបចែកចាយកំណត់ហេតុ។

យើងប្រមូលកំណត់ហេតុតាមរយៈ Docker API៖ អ្នកអភិវឌ្ឍន៍គ្រាន់តែត្រូវដាក់វានៅក្នុង stdout ឬ stderr ហើយអ្នកប្រមូលនឹងតម្រៀបវាចេញ។ កំណត់ហេតុត្រូវបានប្រមូលជាកំណាត់ៗជាមួយនឹងការពន្យាពេលខ្លះ ដើម្បីការពារការផ្ទុកលើសចំណុះដែលអាចកើតមាន។ 

ម៉ែត្រត្រូវបានប្រមូលនៅទូទាំងករណីបន្ទុកការងារ (ដំណើរការ) នៅក្នុងកុងតឺន័រ។ អ្វីគ្រប់យ៉ាងត្រូវបានដាក់ស្លាក៖ namespace, under, ហើយដូច្នេះនៅលើ, ហើយបន្ទាប់មកបានបម្លែងទៅជាទម្រង់ Prometheus - ហើយក្លាយជាមានសម្រាប់ការប្រមូល (លើកលែងតែកំណត់ហេតុ) ។ យើងក៏ផ្ញើកំណត់ហេតុ រង្វាស់ និងព្រឹត្តិការណ៍ទៅ Kafka និងបន្ថែមទៀត៖

• កំណត់ហេតុមាននៅក្នុង Graylog (សម្រាប់ការវិភាគដែលមើលឃើញ);
• កំណត់ហេតុ ការវាស់វែង ព្រឹត្តិការណ៍ត្រូវបានផ្ញើទៅ Clickhouse សម្រាប់ការផ្ទុករយៈពេលវែង។

អ្វីគ្រប់យ៉ាងដំណើរការដូចគ្នានៅក្នុង AWS មានតែយើងជំនួស Graylog ជាមួយ Kafka ជាមួយ Cloudwatch ។ យើងផ្ញើកំណត់ហេតុនៅទីនោះ ហើយអ្វីៗប្រែជាងាយស្រួលណាស់៖ វាច្បាស់ភ្លាមៗថាចង្កោម និងកុងតឺន័រណាមួយដែលពួកគេជាកម្មសិទ្ធិ។ ដូចគ្នានេះដែរគឺសម្រាប់ Google Stackdriver ។ នោះគឺ គ្រោងការណ៍របស់យើងដំណើរការទាំងនៅក្នុងបរិវេណជាមួយ Kafka និងក្នុងពពក។ 

ប្រសិនបើយើងមិនមាន Kubernetes ជាមួយ pods នោះ គ្រោងការណ៍នេះគឺមានភាពស្មុគស្មាញបន្តិច ប៉ុន្តែវាដំណើរការលើគោលការណ៍ដូចគ្នា។

ដំណើរការដូចគ្នាត្រូវបានប្រតិបត្តិនៅខាងក្នុងកុងតឺន័រ ពួកគេត្រូវបានរៀបចំដោយប្រើ S6 ។ ដំណើរការដូចគ្នាទាំងអស់កំពុងដំណើរការនៅក្នុងធុងតែមួយ។

នៅចុងបញ្ចប់។

យើងបានបង្កើតដំណោះស្រាយពេញលេញមួយសម្រាប់ការកសាង និងបើកដំណើរការរូបភាព ជាមួយនឹងជម្រើសសម្រាប់ការប្រមូល និងចែកចាយកំណត់ហេតុ និងម៉ែត្រ៖

• យើងបានបង្កើតវិធីសាស្រ្តស្តង់ដារក្នុងការផ្គុំរូបភាព ហើយផ្អែកលើវា យើងបានបង្កើតគំរូ CI ។
• ភ្នាក់ងារប្រមូលទិន្នន័យគឺជាផ្នែកបន្ថែម Telegraf របស់យើង។ យើងបានសាកល្បងពួកវាយ៉ាងល្អនៅក្នុងផលិតកម្ម;
• យើងប្រើ mutation webhook ដើម្បីអនុវត្តកុងតឺន័រជាមួយភ្នាក់ងារនៅក្នុងផត។ 
• រួមបញ្ចូលទៅក្នុងប្រព័ន្ធអេកូ Kubernetes/Rancher;
• យើងអាចប្រតិបត្តិធុងដូចគ្នានៅក្នុងប្រព័ន្ធ orchestration ផ្សេងគ្នា និងទទួលបានលទ្ធផលដែលយើងរំពឹងទុក។
• បានបង្កើតការកំណត់រចនាសម្ព័ន្ធការគ្រប់គ្រងធុងថាមវន្តទាំងស្រុង។ 

សហអ្នកនិពន្ធ៖ Ilya Prudnikov

ប្រភព: www.habr.com