គោលការណ៍យល់ទូទៅចំនួន 5 សម្រាប់បង្កើតកម្មវិធី Cloud-Native

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

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

គោលការណ៍រចនាកម្មវិធី

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

• KISS (រក្សាវាឱ្យសាមញ្ញ, ឆោតល្ងង់) - កុំស្មុគស្មាញវា;
• ស្ងួត (កុំនិយាយឡើងវិញដោយខ្លួនឯង) - កុំធ្វើម្តងទៀតដោយខ្លួនឯង;
• YAGNI (អ្នកនឹងមិនត្រូវការវាទេ) - កុំបង្កើតអ្វីមួយដែលមិនចាំបាច់ភ្លាមៗ។
• SoC ការបែងចែកកង្វល់ - ចែករំលែកការទទួលខុសត្រូវ។

ដូចដែលអ្នកអាចឃើញ គោលការណ៍ទាំងនេះមិនកំណត់ច្បាប់ជាក់លាក់ណាមួយឡើយ ប៉ុន្តែជាកម្មសិទ្ធិរបស់ប្រភេទនៃអ្វីដែលហៅថាការពិចារណាលើសុភវិនិច្ឆ័យដោយផ្អែកលើបទពិសោធន៍ជាក់ស្តែង ដែលត្រូវបានចែករំលែកដោយអ្នកអភិវឌ្ឍន៍ជាច្រើន និងដែលពួកគេយោងជាប្រចាំ។
លើសពីនេះទៀតមាន រឹង - សំណុំនៃគោលការណ៍ប្រាំដំបូងនៃការសរសេរកម្មវិធី និងការរចនាតម្រង់ទិសវត្ថុ បង្កើតដោយ Robert Martin ។ SOLID រួមបញ្ចូលគោលការណ៍ទូលំទូលាយ បើកចំហ និងបំពេញបន្ថែមដែល—នៅពេលអនុវត្តជាមួយគ្នា—ជួយបង្កើតប្រព័ន្ធកម្មវិធីដែលប្រសើរជាងមុន និងរក្សាវាឱ្យបានល្អក្នុងរយៈពេលវែង។

គោលការណ៍ SOLID ជាកម្មសិទ្ធិរបស់ផ្នែក OOP ហើយត្រូវបានបង្កើតជាភាសានៃគោលគំនិត និងគោលគំនិតដូចជាថ្នាក់ ចំណុចប្រទាក់ និងមរតក។ ដោយភាពស្រដៀងគ្នា គោលការណ៍អភិវឌ្ឍន៍ក៏អាចបង្កើតបានសម្រាប់កម្មវិធីពពកដែរ មានតែធាតុមូលដ្ឋាននៅទីនេះនឹងមិនមែនជាថ្នាក់ទេ ប៉ុន្តែជាកុងតឺន័រ។ ដោយធ្វើតាមគោលការណ៍ទាំងនេះ អ្នកអាចបង្កើតកម្មវិធីដែលមានកុងតឺន័រ ដែលបំពេញតាមគោលដៅ និងគោលបំណងកាន់តែប្រសើរឡើងនៃវេទិកាពពកដូចជា Kubernetes ជាដើម។

កុងតឺន័រដើមកំណើតពពក៖ វិធីសាស្រ្ត Red Hat

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

គោលការណ៍នៃការព្រួយបារម្ភតែមួយ (SCP)

គោលការណ៍​នេះ​មាន​លក្ខណៈ​ជា​ច្រើន​ស្រដៀង​នឹង​គោលការណ៍​ទំនួលខុសត្រូវ​តែមួយ។ សមរង្ស៊ី។) ដែលជាផ្នែកមួយនៃសំណុំ SOLID ហើយចែងថាគ្រប់វត្ថុទាំងអស់ត្រូវតែមានទំនួលខុសត្រូវតែមួយ ហើយទំនួលខុសត្រូវនោះត្រូវតែត្រូវបានបញ្ចូលទាំងស្រុងនៅក្នុងថ្នាក់មួយ។ ចំណុចរបស់ សម រង្ស៊ី គឺថា រាល់ទំនួលខុសត្រូវគឺជាហេតុផលសម្រាប់ការផ្លាស់ប្តូរ ហើយវណ្ណៈមួយត្រូវតែមានហេតុផលតែមួយគត់សម្រាប់ការផ្លាស់ប្តូរ។

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

គោលការណ៍ SCP ចែងថាកុងតឺន័រនីមួយៗគួរតែដោះស្រាយបញ្ហាតែមួយ ហើយធ្វើវាឱ្យបានល្អ។ លើសពីនេះទៅទៀត SCP នៅក្នុងពិភពកុងតឺន័រមានភាពងាយស្រួលក្នុងការសម្រេចបានជាង SRP នៅក្នុងពិភព OOP ចាប់តាំងពីកុងតឺន័រជាធម្មតាដំណើរការតែមួយដំណើរការ ហើយភាគច្រើននៃដំណើរការនេះដោះស្រាយកិច្ចការតែមួយ។

ប្រសិនបើសេវាមីក្រូកុងតឺន័រត្រូវតែដោះស្រាយបញ្ហាជាច្រើនក្នុងពេលតែមួយ នោះវាអាចត្រូវបានបែងចែកទៅជាធុងកិច្ចការតែមួយ ហើយរួមបញ្ចូលគ្នាក្នុងផតតែមួយ (ឯកតានៃការដាក់ពង្រាយវេទិកាកុងតឺន័រ) ដោយប្រើគំរូធុងចំហៀង និង init ។ លើសពីនេះ SCP ធ្វើឱ្យមានភាពងាយស្រួលក្នុងការជំនួសកុងតឺន័រចាស់ (ដូចជាម៉ាស៊ីនមេគេហទំព័រ ឬឈ្មួញកណ្តាលសារ) ជាមួយនឹងឧបករណ៍ថ្មីមួយដែលដោះស្រាយបញ្ហាដូចគ្នា ប៉ុន្តែបានពង្រីកមុខងារ ឬមាត្រដ្ឋានកាន់តែប្រសើរ។

គោលការណ៍សង្កេតខ្ពស់ (HOP)

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

នៅក្នុងការអនុវត្ត កម្មវិធីដែលដាក់ក្នុងកុងតឺន័រ គួរតែមាន API សម្រាប់ការពិនិត្យសុខភាពជាច្រើនប្រភេទ៖ ការធ្វើតេស្តភាពរស់រវើក និងការធ្វើតេស្តត្រៀមខ្លួន។ ប្រសិនបើកម្មវិធីទាមទារឱ្យធ្វើច្រើនជាងនេះ វាត្រូវតែផ្តល់មធ្យោបាយផ្សេងទៀតក្នុងការត្រួតពិនិត្យស្ថានភាពរបស់វា។ ឧទាហរណ៍ ការកត់ត្រាព្រឹត្តិការណ៍សំខាន់ៗតាមរយៈ STDERR និង STDOUT សម្រាប់ការប្រមូលផ្តុំកំណត់ហេតុដោយប្រើ Fluentd, Logstash និងឧបករណ៍ស្រដៀងគ្នាផ្សេងទៀត។ ក៏ដូចជាការរួមបញ្ចូលជាមួយបណ្ណាល័យប្រមូលការតាមដាន និងម៉ែត្រ ដូចជា OpenTracing, Prometheus ជាដើម។

ជាទូទៅ កម្មវិធីនៅតែអាចចាត់ទុកជាប្រអប់ខ្មៅ ប៉ុន្តែវាត្រូវតែផ្តល់ឱ្យនូវ APIs ទាំងអស់ដែលវេទិកាត្រូវការ ដើម្បីត្រួតពិនិត្យ និងគ្រប់គ្រងវាតាមរបៀបដែលល្អបំផុត។

គោលការណ៍អនុលោមតាមវដ្តជីវិត (LCP)

LCP គឺជាការប្រឆាំងរបស់ HOP ។ ខណៈពេលដែល HOP បញ្ជាក់ថាកុងតឺន័រត្រូវតែបង្ហាញ APIs អានទៅកាន់វេទិកានោះ LCP ទាមទារឱ្យកម្មវិធីអាចទទួលយកព័ត៌មានពីវេទិកា។ លើសពីនេះទៅទៀត កុងតឺន័រត្រូវតែមិនត្រឹមតែទទួលព្រឹត្តិការណ៍ប៉ុណ្ណោះទេ ថែមទាំងអាចសម្របខ្លួនបាន ម្យ៉ាងវិញទៀតមានប្រតិកម្មចំពោះពួកគេ។ ដូច្នេះឈ្មោះនៃគោលការណ៍ដែលអាចត្រូវបានចាត់ទុកថាជាតម្រូវការក្នុងការផ្តល់វេទិកាជាមួយនឹងការសរសេរ APIs ។

វេទិកាមានព្រឹត្តិការណ៍ផ្សេងៗគ្នា ដើម្បីជួយគ្រប់គ្រងវដ្តជីវិតរបស់កុងតឺន័រ។ ប៉ុន្តែ​វា​អាស្រ័យ​លើ​កម្មវិធី​ខ្លួន​ឯង​ក្នុង​ការ​សម្រេច​ចិត្ត​មួយ​ណា​ក្នុង​ចំណោម​ពួកគេ​ដើម្បី​យល់​ឃើញ និង​របៀប​ប្រតិកម្ម។

វាច្បាស់ណាស់ថាព្រឹត្តិការណ៍ខ្លះមានសារៈសំខាន់ជាងព្រឹត្តិការណ៍ផ្សេងទៀត។ ឧទាហរណ៍ ប្រសិនបើកម្មវិធីមិនអត់ធ្មត់នឹងការគាំងបានល្អ វាត្រូវតែទទួលយកសញ្ញា៖ បញ្ចប់សារ (SIGTERM) ហើយចាប់ផ្តើមទម្លាប់នៃការបញ្ចប់របស់វាឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន ដើម្បីចាប់សញ្ញា៖ សម្លាប់ (SIGKILL) ដែលមកក្រោយ SIGTERM ។

លើសពីនេះទៀត ព្រឹត្តិការណ៍ដូចជា PostStart និង PreStop អាចមានសារៈសំខាន់ចំពោះវដ្តជីវិតរបស់កម្មវិធី។ ជាឧទាហរណ៍ បន្ទាប់ពីបើកដំណើរការកម្មវិធី វាអាចត្រូវការពេលកម្តៅខ្លះ មុនពេលដែលវាអាចឆ្លើយតបទៅនឹងសំណើ។ ឬកម្មវិធីត្រូវតែបញ្ចេញធនធានតាមរបៀបពិសេសមួយចំនួននៅពេលបិទ។

គោលការណ៍នៃភាពមិនប្រែប្រួលនៃរូបភាព (IIP)

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

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

គោលការណ៍នៃភាពមិនអាចទៅរួចនៃដំណើរការ (PDP)

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

ជាលទ្ធផល កម្មវិធីដែលបានដាក់កុងតឺន័រត្រូវតែរក្សាស្ថានភាពរបស់ពួកគេដោយប្រើមធ្យោបាយខាងក្រៅមួយចំនួន ឬប្រើគ្រោងការណ៍ចែកចាយខាងក្នុងជាមួយនឹងភាពច្របូកច្របល់សម្រាប់ការនេះ។ លើសពីនេះ កម្មវិធីត្រូវតែចាប់ផ្តើមយ៉ាងឆាប់រហ័ស និងបិទយ៉ាងឆាប់រហ័ស ហើយត្រូវបានរៀបចំសម្រាប់ការបរាជ័យផ្នែករឹងធ្ងន់ធ្ងរភ្លាមៗ។

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

គោលការណ៍នៃការបង្ខាំងខ្លួនឯង (S-CP)

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

ករណីលើកលែងត្រូវបានបង្កើតឡើងសម្រាប់ការកំណត់រចនាសម្ព័ន្ធដែលប្រែប្រួលពីបរិស្ថានមួយទៅបរិស្ថានមួយ ហើយត្រូវតែផ្តល់ឱ្យនៅពេលដំណើរការ ឧទាហរណ៍តាមរយៈ Kubernetes ConfigMap ។

កម្មវិធីមួយអាចរួមបញ្ចូលសមាសធាតុកុងតឺន័រជាច្រើន ឧទាហរណ៍ ធុង DBMS ដាច់ដោយឡែកមួយនៅក្នុងកម្មវិធីគេហទំព័រដែលមានកុងតឺន័រ។ យោងតាមគោលការណ៍ S-CP កុងតឺន័រទាំងនេះមិនគួរត្រូវបានបញ្ចូលគ្នាជាតែមួយទេ ប៉ុន្តែគួរតែត្រូវបានធ្វើឡើងដើម្បីឱ្យកុងតឺន័រ DBMS មានអ្វីគ្រប់យ៉ាងដែលចាំបាច់សម្រាប់ប្រតិបត្តិការនៃមូលដ្ឋានទិន្នន័យ ហើយធុងផ្ទុកកម្មវិធីគេហទំព័រមានអ្វីគ្រប់យ៉ាងដែលចាំបាច់សម្រាប់ប្រតិបត្តិការគេហទំព័រ។ កម្មវិធី, ម៉ាស៊ីនមេគេហទំព័រដូចគ្នា។ ជាលទ្ធផល នៅពេលដំណើរការ កុងតឺន័រកម្មវិធីបណ្ដាញនឹងពឹងផ្អែកលើកុងតឺន័រ DBMS ហើយចូលប្រើវាតាមតម្រូវការ។

គោលការណ៍បង្ខាំងពេលដំណើរការ (RCP)

គោលការណ៍ S-CP កំណត់ពីរបៀបដែលធុងគួរត្រូវបានសាងសង់ និងអ្វីដែលប្រព័ន្ធគោលពីររូបភាពគួរមាន។ ប៉ុន្តែកុងតឺន័រមិនគ្រាន់តែជា "ប្រអប់ខ្មៅ" ដែលមានលក្ខណៈតែមួយទេ - ទំហំឯកសារ។ កំឡុងពេលប្រតិបត្តិ កុងតឺន័រយកទំហំផ្សេងទៀត៖ ចំនួនអង្គចងចាំដែលបានប្រើ ពេលវេលាស៊ីភីយូ និងធនធានប្រព័ន្ធផ្សេងទៀត។

ហើយនៅទីនេះ គោលការណ៍ RCP មកជាប្រយោជន៍ ដោយយោងទៅតាមកុងតឺន័រត្រូវតែកាត់ផ្តាច់តម្រូវការរបស់វាសម្រាប់ធនធានប្រព័ន្ធ និងផ្ទេរពួកវាទៅវេទិកា។ ជាមួយនឹងទម្រង់ធនធានរបស់កុងតឺន័រនីមួយៗ (ចំនួនស៊ីភីយូ អង្គចងចាំ បណ្តាញ និងធនធានថាសដែលវាត្រូវការ) វេទិកានេះអាចដំណើរការកាលវិភាគ និងការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ គ្រប់គ្រងសមត្ថភាពព័ត៌មានវិទ្យា និងរក្សាកម្រិត SLA សម្រាប់កុងតឺន័រ។

បន្ថែមពីលើការបំពេញតម្រូវការធនធានរបស់កុងតឺន័រ វាក៏មានសារៈសំខាន់ផងដែរសម្រាប់កម្មវិធីមិនឱ្យហួសពីព្រំដែនរបស់វាឡើយ។ បើមិនដូច្នេះទេ នៅពេលដែលមានការខ្វះខាតធនធានកើតឡើង វេទិកាទំនងជានឹងបញ្ចូលវាទៅក្នុងបញ្ជីនៃកម្មវិធីដែលត្រូវបញ្ចប់ ឬផ្លាស់ប្តូរ។

នៅពេលដែលយើងនិយាយអំពីការធ្វើជា cloud-first យើងកំពុងនិយាយអំពីវិធីដែលយើងធ្វើការ។
ខាងលើ យើងបានបង្កើតគោលការណ៍ទូទៅមួយចំនួនដែលកំណត់មូលដ្ឋានគ្រឹះនៃវិធីសាស្ត្រសម្រាប់បង្កើតកម្មវិធីកុងតឺន័រដែលមានគុណភាពខ្ពស់សម្រាប់បរិស្ថានពពក។

ចំណាំថាបន្ថែមពីលើគោលការណ៍ទូទៅទាំងនេះ អ្នកក៏នឹងត្រូវការវិធីសាស្រ្ត និងបច្ចេកទេសកម្រិតខ្ពស់បន្ថែមទៀតសម្រាប់ធ្វើការជាមួយធុង។ លើសពីនេះ យើងមានការណែនាំខ្លីៗមួយចំនួនដែលជាក់លាក់ជាងនេះ ហើយគួរអនុវត្ត (ឬមិនអនុវត្ត) អាស្រ័យលើស្ថានភាព៖

• ព្យាយាមកាត់បន្ថយទំហំនៃរូបភាព៖ លុបឯកសារបណ្ដោះអាសន្ន ហើយកុំដំឡើងកញ្ចប់ដែលមិនចាំបាច់ - ទំហំកុងតឺន័រកាន់តែតូច វាកាន់តែលឿនវាត្រូវបានផ្គុំ និងចម្លងទៅកាន់ម៉ាស៊ីនគោលដៅតាមបណ្តាញ។
• ផ្តោតលើលេខសម្គាល់អ្នកប្រើប្រាស់បំពាន៖ កុំប្រើពាក្យបញ្ជា sudo ឬ userid ពិសេសណាមួយដើម្បីបើកដំណើរការកុងតឺន័ររបស់អ្នក។
• សម្គាល់ច្រកសំខាន់ៗ៖ អ្នកអាចកំណត់លេខច្រកនៅពេលដំណើរការ ប៉ុន្តែវាជាការប្រសើរក្នុងការបញ្ជាក់ពួកវាដោយប្រើពាក្យបញ្ជា EXPOSE - វានឹងធ្វើឱ្យវាកាន់តែងាយស្រួលសម្រាប់មនុស្ស និងកម្មវិធីផ្សេងទៀតក្នុងការប្រើប្រាស់រូបភាពរបស់អ្នក។
• រក្សាទុកទិន្នន័យជាប់លាប់នៅលើភាគ៖ ទិន្នន័យដែលគួរនៅមានបន្ទាប់ពីធុងត្រូវបានបំផ្លាញ គួរតែត្រូវបានសរសេរទៅជាភាគ។
• សរសេរទិន្នន័យមេតារូបភាព៖ ស្លាក ស្លាក និងចំណារពន្យល់ធ្វើឱ្យរូបភាពកាន់តែងាយស្រួលប្រើ - អ្នកអភិវឌ្ឍន៍ផ្សេងទៀតនឹងអរគុណអ្នក។
• ធ្វើសមកាលកម្មម៉ាស៊ីន និងរូបភាព៖ កម្មវិធីដែលមានកុងតឺន័រមួយចំនួនតម្រូវឱ្យកុងតឺន័រធ្វើសមកាលកម្មជាមួយម៉ាស៊ីននៅលើលក្ខណៈជាក់លាក់មួយចំនួន ដូចជាពេលវេលា ឬលេខសម្គាល់ម៉ាស៊ីន។
• សរុបសេចក្តី យើងចែករំលែកគំរូ និងការអនុវត្តល្អបំផុត ដែលនឹងជួយអ្នកឱ្យអនុវត្តកាន់តែមានប្រសិទ្ធភាពនូវគោលការណ៍ដែលបានរាយខាងលើ៖
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

Webinar លើកំណែថ្មីនៃ OpenShift Container Platform – 4
ថ្ងៃទី 11 ខែមិថុនា វេលាម៉ោង 11.00:XNUMX

តើអ្នកនឹងរៀនអ្វីខ្លះ៖

• សហគ្រាស Red Hat ដែលមិនអាចផ្លាស់ប្តូរបាន Linux CoreOS
• សំណាញ់សេវាកម្ម OpenShift
• ក្របខ័ណ្ឌប្រតិបត្តិករ
• ក្របខណ្ឌគំនិត

ប្រភព: www.habr.com