សួស្តី​អ្នក​ទាំងអស់គ្នា! ឈ្មោះរបស់ខ្ញុំគឺ Pavel Agaletsky ។ ខ្ញុំ​ធ្វើ​ការ​ជា​អ្នក​ដឹក​នាំ​ក្រុម​ក្នុង​ក្រុម​ដែល​បង្កើត​ប្រព័ន្ធ​ចែកចាយ​ Lamoda។ នៅឆ្នាំ 2018 ខ្ញុំបាននិយាយនៅឯសន្និសីទ HighLoad++ ហើយថ្ងៃនេះខ្ញុំចង់បង្ហាញប្រតិចារិកនៃរបាយការណ៍របស់ខ្ញុំ។

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

ការដាក់ពង្រាយកម្មវិធីទៅ VM

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

ហេតុអ្វីបានជានេះត្រូវបានធ្វើ?

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

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

តើ​អ្វី​ដែល​យើង​បាន​ឃើញ​នៅ​ក្នុង​ការ​ទាំង​អស់​នេះ?

1. ដំបូងវាគ្រប់គ្រាន់ហើយ។ វាគ្រាន់តែដំណើរការ។ មនុស្សគ្រប់គ្នាយល់ពីរបៀបដែលគ្រោងការណ៍ដាក់ពង្រាយបែបនេះដំណើរការ ពីព្រោះមនុស្សភាគច្រើនធ្លាប់ដាក់ពង្រាយទៅកាន់ម៉ាស៊ីនមេនិម្មិតធម្មតា។
2. នេះគឺគ្រប់គ្រាន់ហើយ។ អាចជឿទុកចិត្តបានចាប់តាំងពីបច្ចេកវិទ្យាដាក់ពង្រាយគឺសាមញ្ញ សាកល្បងដោយក្រុមហ៊ុនរាប់ពាន់។ ម៉ាស៊ីនមេរាប់លានត្រូវបានដាក់ពង្រាយតាមវិធីនេះ។ វាពិបាកក្នុងការបំបែកអ្វីមួយ។
3. ហើយទីបំផុតយើងអាចទទួលបាន ការដាក់ពង្រាយបរមាណូ. ការដាក់ឱ្យប្រើប្រាស់ដែលកើតឡើងក្នុងពេលដំណាលគ្នាសម្រាប់អ្នកប្រើប្រាស់ ដោយគ្មានដំណាក់កាលគួរឱ្យកត់សម្គាល់នៃការប្តូររវាងកំណែចាស់ និងកំណែថ្មី។

ប៉ុន្តែ​យើង​ក៏​បាន​ឃើញ​ចំណុច​ខ្វះខាត​មួយ​ចំនួន​ក្នុង​រឿង​ទាំង​អស់​នេះ​ដែរ៖

1. ក្រៅ​ពី​បរិយាកាស​ផលិតកម្ម បរិស្ថាន​អភិវឌ្ឍន៍​ក៏​មាន​បរិស្ថាន​ផ្សេង​ទៀត។ ឧទាហរណ៍ q និង preproduction ។ នៅពេលនោះ យើងមានម៉ាស៊ីនមេជាច្រើន និងសេវាកម្មប្រហែល 60 ។ សម្រាប់ហេតុផលនេះវាចាំបាច់ សម្រាប់សេវាកម្មនីមួយៗ សូមរក្សាកំណែចុងក្រោយបំផុតសម្រាប់វា។ ម៉ាស៊ីននិម្មិត។ ជាងនេះទៅទៀត ប្រសិនបើអ្នកចង់ធ្វើបច្ចុប្បន្នភាពបណ្ណាល័យ ឬដំឡើងភាពអាស្រ័យថ្មី អ្នកត្រូវធ្វើវានៅគ្រប់បរិស្ថានទាំងអស់។ អ្នកក៏ត្រូវការដើម្បីធ្វើសមកាលកម្មពេលវេលាដែលអ្នកនឹងដាក់ពង្រាយកំណែថ្មីបន្ទាប់នៃកម្មវិធីរបស់អ្នកជាមួយនឹងពេលដែល devops អនុវត្តការកំណត់បរិស្ថានចាំបាច់។ ក្នុងករណីនេះ វាងាយស្រួលក្នុងការចូលទៅក្នុងស្ថានភាពដែលបរិស្ថានរបស់យើងនឹងមានភាពខុសប្លែកគ្នាខ្លះនៅក្នុងគ្រប់មជ្ឈដ្ឋានក្នុងពេលតែមួយ។ ជាឧទាហរណ៍ នៅក្នុងបរិយាកាស QA នឹងមានកំណែមួយចំនួននៃបណ្ណាល័យ ហើយនៅក្នុងបរិយាកាសផលិតកម្មនឹងមានកំណែផ្សេងៗគ្នា ដែលនឹងនាំឱ្យមានបញ្ហា។
2. ភាពលំបាកក្នុងការធ្វើបច្ចុប្បន្នភាពភាពអាស្រ័យ កម្មវិធីរបស់អ្នក។ វាមិនអាស្រ័យលើអ្នកទេ ប៉ុន្តែនៅលើក្រុមផ្សេងទៀត។ ពោលគឺមកពីក្រុម devops ដែលរក្សាម៉ាស៊ីនមេ។ អ្នកត្រូវតែផ្តល់ឱ្យពួកគេនូវកិច្ចការសមស្រប និងការពិពណ៌នាអំពីអ្វីដែលអ្នកចង់ធ្វើ។
3. នៅពេលនោះ យើងក៏ចង់បែងចែក monoliths ធំៗដែលយើងមានទៅជាសេវាកម្មតូចៗដាច់ដោយឡែកពីគ្នា ដោយសារយើងយល់ថានឹងមានកាន់តែច្រើនឡើង។ នៅពេលនោះ យើងមានច្រើនជាង 100 នៃពួកគេរួចហើយ។ សម្រាប់សេវាកម្មថ្មីនីមួយៗ ចាំបាច់ត្រូវបង្កើតម៉ាស៊ីននិម្មិតថ្មីដាច់ដោយឡែក ដែលចាំបាច់ត្រូវថែទាំ និងដាក់ឱ្យប្រើប្រាស់ផងដែរ។ លើសពីនេះទៀតអ្នកមិនត្រូវការឡានមួយទេប៉ុន្តែយ៉ាងហោចណាស់ពីរ។ បន្ថែមទៅទាំងអស់នេះគឺជាបរិស្ថាន QA ។ វាបណ្តាលឱ្យមានបញ្ហា និងធ្វើឱ្យអ្នកកាន់តែលំបាកក្នុងការសាងសង់ និងដំណើរការប្រព័ន្ធថ្មី។ ដំណើរការស្មុគស្មាញ ថ្លៃ និងវែង។

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

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

ប្តូរទៅ Nomad

Nomad គឺជាផលិតផលរបស់ក្រុមហ៊ុន HashiCorp ។ ពួកគេត្រូវបានគេស្គាល់ផងដែរសម្រាប់ដំណោះស្រាយផ្សេងទៀតរបស់ពួកគេ:

"កុងស៊ុល" គឺជាឧបករណ៍សម្រាប់ការរកឃើញសេវាកម្ម។

"ដីឥដ្ឋ" - ប្រព័ន្ធសម្រាប់គ្រប់គ្រងម៉ាស៊ីនមេ ដែលអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធពួកវាតាមរយៈការកំណត់រចនាសម្ព័ន្ធ ដែលគេហៅថាហេដ្ឋារចនាសម្ព័ន្ធ-as-a-code ។

"Vagrant" អនុញ្ញាតឱ្យអ្នកដាក់ពង្រាយម៉ាស៊ីននិម្មិតក្នុងមូលដ្ឋាន ឬក្នុងពពកតាមរយៈឯកសារកំណត់រចនាសម្ព័ន្ធជាក់លាក់។

Nomad នៅ​ពេល​នោះ​ហាក់​ដូច​ជា​ដំណោះ​ស្រាយ​ដ៏​សាមញ្ញ​មួយ​ដែល​អាច​ត្រូវ​បាន​ប្ដូរ​ទៅ​យ៉ាង​ឆាប់​រហ័ស​ដោយ​មិន​មាន​ការ​ផ្លាស់​ប្តូរ​ហេដ្ឋារចនាសម្ព័ន្ធ​ទាំង​មូល។ លើសពីនេះទៀតវាងាយស្រួលរៀនណាស់។ នោះហើយជាមូលហេតុដែលយើងជ្រើសរើសវាជាប្រព័ន្ធចម្រោះសម្រាប់ធុងរបស់យើង។

តើអ្នកត្រូវការអ្វីខ្លះដើម្បីដាក់ពង្រាយប្រព័ន្ធរបស់អ្នកទៅ Nomad?

1. ដំបូងអ្នកត្រូវការ រូបភាព docker កម្មវិធីរបស់អ្នក។ អ្នកត្រូវបង្កើតវា ហើយដាក់វានៅក្នុងឃ្លាំងរូបភាព docker ។ ក្នុងករណីរបស់យើងនេះគឺជាវត្ថុបុរាណ - ប្រព័ន្ធដែលអនុញ្ញាតឱ្យអ្នករុញវត្ថុបុរាណផ្សេងៗនៃប្រភេទផ្សេងៗគ្នាចូលទៅក្នុងវា។ វាអាចរក្សាទុកប័ណ្ណសារ រូបភាព docker កញ្ចប់កម្មវិធីនិពន្ធ PHP កញ្ចប់ NPM ជាដើម។
2. ទាមទារផងដែរ។ ឯកសារកំណត់រចនាសម្ព័ន្ធដែលនឹងប្រាប់ Nomad ពីអ្វី កន្លែងណា និងក្នុងបរិមាណអ្វីដែលអ្នកចង់ដាក់ពង្រាយ។

នៅពេលយើងនិយាយអំពី Nomad វាប្រើភាសា HCL ជាទម្រង់ឯកសារព័ត៌មានរបស់វា ដែលតំណាងឱ្យ ភាសាកំណត់រចនាសម្ព័ន្ធ HashiCorp. នេះគឺជា Superset របស់ Yaml ដែលអនុញ្ញាតឱ្យអ្នកពិពណ៌នាអំពីសេវាកម្មរបស់អ្នកនៅក្នុងលក្ខខណ្ឌ Nomad ។

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

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

ដូច្នេះហើយ យើងបានសម្រេចចិត្តថា វានឹងមានភាពងាយស្រួលសម្រាប់យើងក្នុងការរក្សាទុកឯកសារកំណត់រចនាសម្ព័ន្ធរបស់យើងទាំងអស់សម្រាប់ការដាក់ពង្រាយនៅក្នុងឃ្លាំងទូទៅមួយ។ វិធីនេះពួកវាអាចមើលឃើញ៖ ពួកវាងាយស្រួលក្នុងការថែទាំ ហើយយើងអាចមើលថាតើយើងមានប្រព័ន្ធអ្វីខ្លះ។ បើចាំបាច់ វាក៏ងាយស្រួលក្នុងការអាប់ដេត ឬផ្លាស់ប្តូរអ្វីមួយ។ ការបន្ថែមប្រព័ន្ធថ្មីក៏មិនពិបាកដែរ - អ្នកគ្រាន់តែត្រូវការបង្កើតឯកសារកំណត់រចនាសម្ព័ន្ធមួយនៅខាងក្នុងថតថ្មី។ នៅខាងក្នុងវាមានឯកសារដូចខាងក្រោម៖ service.hcl ដែលមានការពិពណ៌នាអំពីសេវាកម្មរបស់យើង និងឯកសារ env មួយចំនួនដែលអនុញ្ញាតឱ្យសេវាកម្មនេះ ត្រូវបានដាក់ពង្រាយក្នុងការផលិត ត្រូវបានកំណត់រចនាសម្ព័ន្ធ។

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

លើសពីនេះទៀត យើងបានដាក់នៅក្នុងឃ្លាំងនូវស្គ្រីបដាក់ពង្រាយទូទៅសម្រាប់គម្រោងទាំងអស់ ដែលអនុញ្ញាតឱ្យអ្នកចាប់ផ្តើម និងដាក់ពង្រាយសេវាកម្មរបស់អ្នកទៅក្នុងផលិតកម្ម ទៅក្នុងបរិយាកាសដែលចង់បាន ចូលទៅក្នុងគោលដៅដែលចង់បាន។ ក្នុងករណីនៅពេលដែលយើងប្រែក្លាយការកំណត់រចនាសម្ព័ន្ធ HCL របស់យើងទៅជាគំរូ នោះឯកសារ HCL ដែលពីមុនជាការកំណត់រចនាសម្ព័ន្ធ Nomad ធម្មតា ក្នុងករណីនេះចាប់ផ្តើមមើលទៅខុសគ្នាបន្តិចបន្តួច។

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

ឧទាហរណ៍ អ្នកចង់ដាក់ពង្រាយសេវាកម្មរបស់អ្នកទៅផលិតកម្មមុន និងផលិតកម្ម។ ចូរនិយាយថានៅក្នុងការផលិតជាមុន អ្នកមិនចង់ដំណើរការស្គ្រីប cron ទេ ប៉ុន្តែគ្រាន់តែចង់ឃើញសេវាកម្មនៅលើដែនដាច់ដោយឡែក ដើម្បីប្រាកដថាវាដំណើរការ។ សម្រាប់នរណាម្នាក់ដែលដាក់ពង្រាយសេវាកម្ម ដំណើរការមើលទៅសាមញ្ញ និងមានតម្លាភាព។ អ្វីដែលអ្នកត្រូវធ្វើគឺប្រតិបត្តិឯកសារ deploy.sh បញ្ជាក់សេវាកម្មណាមួយដែលអ្នកចង់ដាក់ពង្រាយ និងទៅកាន់គោលដៅណាមួយ។ ឧទាហរណ៍ អ្នកចង់ដាក់ពង្រាយប្រព័ន្ធជាក់លាក់មួយទៅកាន់ប្រទេសរុស្ស៊ី បេឡារុស្ស ឬកាហ្សាក់ស្ថាន។ ដើម្បីធ្វើដូចនេះគ្រាន់តែផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រមួយហើយអ្នកនឹងមានឯកសារកំណត់រចនាសម្ព័ន្ធត្រឹមត្រូវ។

នៅពេលដែលសេវាកម្ម Nomad ត្រូវបានដាក់ពង្រាយទៅកាន់ចង្កោមរបស់អ្នករួចហើយ វាមើលទៅដូចនេះ។

ជាដំបូង អ្នកត្រូវការតុល្យភាពមួយចំនួននៅខាងក្រៅ ដែលនឹងទទួលបានចរាចរណ៍អ្នកប្រើប្រាស់ទាំងអស់។ វានឹងធ្វើការរួមគ្នាជាមួយកុងស៊ុល ហើយស្វែងយល់ពីវាពីកន្លែងដែលថ្នាំងណា នៅឯអាសយដ្ឋាន IP ដែលសេវាកម្មជាក់លាក់មួយស្ថិតនៅដែលត្រូវនឹងឈ្មោះដែនជាក់លាក់មួយ។ សេវាកម្មនៅក្នុងកុងស៊ុលគឺមកពី Nomad ផ្ទាល់។ ដោយសារទាំងនេះជាផលិតផលពីក្រុមហ៊ុនតែមួយ ពួកគេមានទំនាក់ទំនងគ្នាទៅវិញទៅមក។ យើងអាចនិយាយបានថា Nomad ចេញពីប្រអប់អាចចុះឈ្មោះសេវាកម្មទាំងអស់ដែលបានបើកនៅក្នុងវានៅខាងក្នុងកុងស៊ុល។

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

តើ​ការ​ផ្លាស់​ប្តូរ​នេះ​បាន​ធ្វើ​ឱ្យ​យើង​ចំណាយ​ប្រាក់​ប៉ុន្មាន​ក្នុង​ផ្នែក​ធនធាន​មនុស្ស?

ការផ្លាស់ប្តូរក្រុមហ៊ុនទាំងមូលទៅ Nomad ចំណាយពេលប្រហែល 5-6 ខែ។ យើងបានផ្លាស់ប្តូរតាមមូលដ្ឋានសេវាកម្មមួយ ប៉ុន្តែក្នុងល្បឿនដ៏លឿនគួរសម។ ក្រុមនីមួយៗត្រូវបង្កើតធុងផ្ទាល់ខ្លួនរបស់ពួកគេសម្រាប់សេវាកម្ម។

យើងបានអនុវត្តវិធីសាស្រ្តបែបនេះ ដែលក្រុមនីមួយៗទទួលខុសត្រូវចំពោះរូបភាព docker នៃប្រព័ន្ធរបស់ពួកគេដោយឯករាជ្យ។ DevOps ផ្តល់នូវហេដ្ឋារចនាសម្ព័ន្ធទូទៅដែលចាំបាច់សម្រាប់ការដាក់ពង្រាយ ពោលគឺការគាំទ្រសម្រាប់ក្រុមខ្លួនវា ការគាំទ្រសម្រាប់ប្រព័ន្ធ CI និងអ្វីៗផ្សេងទៀត។ ហើយនៅពេលនោះ យើងមានប្រព័ន្ធជាង 60 បានផ្លាស់ប្តូរទៅ Nomad ដែលមានចំនួនប្រហែល 2 ពាន់កុងតឺន័រ។

Devops ទទួលខុសត្រូវចំពោះហេដ្ឋារចនាសម្ព័ន្ធទូទៅនៃអ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹងការដាក់ពង្រាយ និងម៉ាស៊ីនមេ។ ហើយក្រុមអភិវឌ្ឍន៍នីមួយៗ ទទួលខុសត្រូវក្នុងការអនុវត្តកុងតឺន័រសម្រាប់ប្រព័ន្ធជាក់លាក់របស់វា ដោយសារវាជាក្រុមដែលដឹងពីអ្វីដែលជាទូទៅវាត្រូវការនៅក្នុងកុងតឺន័រជាក់លាក់មួយ។

ហេតុផលសម្រាប់ការបោះបង់ចោល Nomad

តើយើងទទួលបានអត្ថប្រយោជន៍អ្វីខ្លះដោយការប្តូរទៅការដាក់ពង្រាយដោយប្រើ Nomad និង docker ក្នុងចំណោមអ្នកផ្សេងទៀត?

1. Мы បានផ្តល់លក្ខខណ្ឌស្មើគ្នា សម្រាប់បរិស្ថានទាំងអស់។ នៅក្នុងការអភិវឌ្ឍន៍ បរិស្ថាន QA ការផលិតមុន ការផលិត រូបភាពធុងដូចគ្នាត្រូវបានប្រើ ដោយមានភាពអាស្រ័យដូចគ្នា។ ដូច្នោះហើយ អ្នកស្ទើរតែគ្មានឱកាសដែលថាអ្វីដែលនឹងបញ្ចប់នៅក្នុងផលិតកម្មមិនមែនជាអ្វីដែលអ្នកបានសាកល្បងពីមុននៅក្នុងមូលដ្ឋាន ឬនៅក្នុងបរិយាកាសសាកល្បងរបស់អ្នកនោះទេ។
2. យើងក៏បានរកឃើញថាវាគ្រប់គ្រាន់ហើយ។ ងាយស្រួលបន្ថែមសេវាកម្មថ្មី។. តាមទស្សនៈនៃការដាក់ពង្រាយ ប្រព័ន្ធថ្មីណាមួយត្រូវបានដាក់ឱ្យដំណើរការយ៉ាងសាមញ្ញ។ គ្រាន់តែចូលទៅកាន់ឃ្លាំងដែលរក្សាទុក configs បន្ថែម config មួយផ្សេងទៀតសម្រាប់ប្រព័ន្ធរបស់អ្នកនៅទីនោះ ហើយអ្នករួចរាល់ហើយ។ អ្នកអាចដាក់ពង្រាយប្រព័ន្ធរបស់អ្នកទៅផលិតកម្មដោយមិនចាំបាច់ប្រឹងប្រែងបន្ថែមពី devops
3. ទាំងអស់ ឯកសារកំណត់រចនាសម្ព័ន្ធ នៅក្នុងឃ្លាំងទូទៅមួយ។ បានប្រែក្លាយថាស្ថិតនៅក្រោមការត្រួតពិនិត្យ. នៅពេលដែលយើងដាក់ពង្រាយប្រព័ន្ធរបស់យើងដោយប្រើម៉ាស៊ីនមេនិម្មិត យើងបានប្រើ Ansible ដែលការកំណត់គឺស្ថិតនៅក្នុងឃ្លាំងតែមួយ។ ទោះយ៉ាងណាក៏ដោយ សម្រាប់អ្នកអភិវឌ្ឍន៍ភាគច្រើន វាពិបាកជាងបន្តិចក្នុងការធ្វើការជាមួយ។ នៅទីនេះបរិមាណនៃការកំណត់រចនាសម្ព័ន្ធ និងកូដដែលអ្នកត្រូវបន្ថែមដើម្បីដាក់ឱ្យប្រើប្រាស់សេវាកម្មបានកាន់តែតូចជាងមុន។ លើសពីនេះ វាងាយស្រួលណាស់សម្រាប់ devops ដើម្បីជួសជុល ឬផ្លាស់ប្តូរវា។ ឧទាហរណ៍ ក្នុងករណីមានការផ្លាស់ប្តូរទៅកាន់កំណែថ្មីរបស់ Nomad ពួកគេអាចទទួលយក និងធ្វើបច្ចុប្បន្នភាពឯកសារប្រតិបត្តិការទាំងអស់ដែលមានទីតាំងនៅកន្លែងតែមួយ។

ប៉ុន្តែ​យើង​ក៏​បាន​ជួប​ប្រទះ​នឹង​គុណវិបត្តិ​មួយ​ចំនួន​ដែរ៖

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

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

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

ក្នុងន័យនេះ ជម្រើសរបស់យើងបានធ្លាក់លើ Kubernetes ជាវេទិកាពេញនិយមបំផុតសម្រាប់ការបើកដំណើរការចង្កោម។ ជាពិសេសបានផ្តល់ឱ្យថាទំហំនិងចំនួនធុងរបស់យើងមានទំហំធំល្មម។ សម្រាប់គោលបំណងបែបនេះ Kubernetes ហាក់ដូចជាប្រព័ន្ធសមស្របបំផុតដែលយើងអាចមើលបាន។

ការផ្លាស់ប្តូរទៅ Kubernetes

ខ្ញុំនឹងប្រាប់អ្នកបន្តិចអំពីគោលគំនិតជាមូលដ្ឋានរបស់ Kubernetes និងរបៀបដែលវាខុសគ្នាពី Nomad ។

ជាដំបូង គោលគំនិតជាមូលដ្ឋានបំផុតនៅក្នុង Kubernetes គឺជាគោលគំនិតរបស់ pod ។ ផត គឺជាក្រុមនៃធុងមួយ ឬច្រើនដែលតែងតែដំណើរការជាមួយគ្នា។ ហើយពួកគេតែងតែធ្វើការដូចជាយ៉ាងតឹងរឹងនៅលើម៉ាស៊ីននិម្មិតមួយ។ ពួកវាអាចចូលប្រើគ្នាទៅវិញទៅមកតាមរយៈ IP 127.0.0.1 នៅលើច្រកផ្សេងៗគ្នា។

ឧបមាថាអ្នកមានកម្មវិធី PHP ដែលមាន nginx និង php-fpm - គ្រោងការណ៍បុរាណ។ ភាគច្រើន អ្នកនឹងចង់រក្សាទាំង nginx និង php-fpm containers ជាមួយគ្នាគ្រប់ពេលវេលា។ Kubernetes អនុញ្ញាតឱ្យអ្នកសម្រេចបានវាដោយពិពណ៌នាពួកវាថាជាផតទូទៅមួយ។ នេះគឺជាអ្វីដែលយើងមិនអាចទទួលបានជាមួយ Nomad ។

គំនិតទីពីរគឺ ការដាក់ពង្រាយ. ការពិតគឺថា pod ខ្លួនឯងគឺជារឿងមិនប្រក្រតី វាចាប់ផ្តើមហើយបាត់ទៅវិញ។ តើ​អ្នក​ចង់​សម្លាប់​កុងតឺន័រ​ពីមុន​ទាំងអស់​របស់អ្នក​ជាមុន​សិន ហើយ​បន្ទាប់​មក​បើក​ដំណើរការ​កំណែ​ថ្មី​ក្នុង​ពេល​តែ​មួយ ឬ​តើ​អ្នក​ចង់​ដាក់​វា​ចេញ​ជា​បណ្តើរៗ​ឬ? វាពិពណ៌នាអំពីរបៀបដែលអ្នកដាក់ពង្រាយ pods របស់អ្នក ក្នុងបរិមាណ និងរបៀបធ្វើបច្ចុប្បន្នភាពពួកវា។

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

ហើយគោលគំនិតទីបួនគឺ Ingress. នេះគឺជាសេវាកម្មដែលដំណើរការលើចង្កោម Kubernetes ។ វាដើរតួជាឧបករណ៍តុល្យភាពបន្ទុកខាងក្រៅដែលគ្រប់គ្រងលើសំណើទាំងអស់។ ដោយប្រើ Kubernetes API Ingress អាចកំណត់កន្លែងដែលសំណើទាំងនេះគួរតែត្រូវបានផ្ញើ។ លើស​ពី​នេះ​ទៅ​ទៀត គាត់​ធ្វើ​បែប​នេះ​យ៉ាង​បត់បែន។ អ្នកអាចនិយាយបានថាសំណើទាំងអស់ទៅកាន់ម៉ាស៊ីននេះ និង URL បែបនេះត្រូវបានផ្ញើទៅកាន់សេវាកម្មនេះ។ ហើយសំណើទាំងនេះមកដល់ម៉ាស៊ីននេះ និងទៅកាន់ URL ផ្សេងទៀតត្រូវបានផ្ញើទៅសេវាកម្មផ្សេងទៀត។

អ្វី​ដែល​ត្រជាក់​បំផុត​តាម​ទស្សនៈ​របស់​អ្នក​ដែល​បង្កើត​កម្មវិធី​មួយ​គឺ​អ្នក​អាច​គ្រប់គ្រង​វា​បាន​ដោយ​ខ្លួន​ឯង។ តាមរយៈការកំណត់ Ingress config អ្នកអាចផ្ញើចរាចរទាំងអស់ដែលចូលមកដូច និង API ទៅកាន់ធុងដាច់ដោយឡែកដែលបានសរសេរឧទាហរណ៍នៅក្នុង Go ។ ប៉ុន្តែចរាចរនេះដែលមកដល់ដែនដូចគ្នា ប៉ុន្តែទៅកាន់ URL ផ្សេង គួរតែផ្ញើទៅកាន់កុងតឺន័រដែលសរសេរក្នុង PHP ដែលវាមានតក្កវិជ្ជាច្រើន ប៉ុន្តែវាមិនលឿនពេកទេ។

បើ​យើង​ប្រៀប​ធៀប​គោល​គំនិត​ទាំង​អស់​នេះ​ជា​មួយ​នឹង Nomad យើង​អាច​និយាយ​បាន​ថា គោល​គំនិត​ទាំង​បី​ដំបូង​គឺ​រួម​គ្នា​ជាមួយ​សេវា។ ហើយគំនិតចុងក្រោយគឺអវត្តមាននៅក្នុង Nomad ខ្លួនឯង។ យើងបានប្រើឧបករណ៍តុល្យភាពខាងក្រៅដូចដែលវា: វាអាចជា haproxy, nginx, nginx+ ជាដើម។ ក្នុងករណីគូបមួយ អ្នកមិនចាំបាច់ណែនាំគំនិតបន្ថែមនេះដោយឡែកពីគ្នានោះទេ។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកក្រឡេកមើល Ingress ខាងក្នុង វាគឺជា nginx, haproxy, ឬ traefik ប៉ុន្តែត្រូវបានបង្កើតឡើងនៅក្នុង Kubernetes ។

តាមពិតគំនិតទាំងអស់ដែលខ្ញុំបានពិពណ៌នាគឺជាការពិត ធនធានដែលមាននៅក្នុងចង្កោម Kubernetes ។ ដើម្បីពណ៌នាពួកវាក្នុងគូប ទម្រង់ yaml មួយត្រូវបានប្រើ ដែលអាចអានបាន និងស៊ាំជាងឯកសារ HCL ក្នុងករណី Nomad ។ ប៉ុន្តែតាមរចនាសម្ព័នពួកគេពណ៌នារឿងដូចគ្នានៅក្នុងករណីឧទាហរណ៍ pod ។ ពួកគេនិយាយថា - ខ្ញុំចង់ដាក់ពង្រាយផតថលបែបនេះ នៅទីនោះ ជាមួយនឹងរូបភាពបែបនេះ និងក្នុងបរិមាណបែបនេះ។

លើសពីនេះ យើងបានដឹងថាយើងមិនចង់បង្កើតធនធានបុគ្គលនីមួយៗដោយដៃទេ៖ ការដាក់ពង្រាយ សេវាកម្ម Ingress ជាដើម។ ជំនួសមកវិញ យើងចង់ពណ៌នាអំពីប្រព័ន្ធនីមួយៗរបស់យើងទាក់ទងនឹង Kubernetes កំឡុងពេលដាក់ឱ្យប្រើប្រាស់ ដូច្នេះយើងនឹងមិនចាំបាច់បង្កើតធនធានចាំបាច់ទាំងអស់ឡើងវិញដោយដៃតាមលំដាប់ត្រឹមត្រូវ។ Helm ត្រូវបានជ្រើសរើសជាប្រព័ន្ធដែលអនុញ្ញាតឱ្យយើងធ្វើកិច្ចការនេះ។

គោលគំនិតជាមូលដ្ឋាននៅក្នុង Helm

មួកគឺ អ្នកគ្រប់គ្រងកញ្ចប់ សម្រាប់ Kubernetes ។ វាស្រដៀងទៅនឹងរបៀបដែលអ្នកគ្រប់គ្រងកញ្ចប់នៅក្នុងភាសាសរសេរកម្មវិធីដំណើរការ។ ពួកគេអនុញ្ញាតឱ្យអ្នករក្សាទុកសេវាកម្មដែលមានឧទាហរណ៍ ការដាក់ពង្រាយ nginx ការដាក់ពង្រាយ php-fpm ការកំណត់សម្រាប់ Ingress ការកំណត់រចនាសម្ព័ន្ធ (នេះគឺជាអង្គភាពដែលអនុញ្ញាតឱ្យអ្នកកំណត់ env និងប៉ារ៉ាម៉ែត្រផ្សេងទៀតសម្រាប់ប្រព័ន្ធរបស់អ្នក) ក្នុងទម្រង់ជា ហៅថាគំនូសតាង។ ក្នុងពេលជាមួយគ្នានេះ Helm ដំណើរការនៅលើកំពូលនៃ Kubernetes. នោះគឺ នេះមិនមែនជាប្រព័ន្ធមួយចំនួនដែលឈរនៅម្ខាងនោះទេ ប៉ុន្តែគ្រាន់តែជាសេវាកម្មមួយផ្សេងទៀតដែលបើកដំណើរការនៅខាងក្នុងគូបប៉ុណ្ណោះ។ អ្នកធ្វើអន្តរកម្មជាមួយវាតាមរយៈ API របស់វាតាមរយៈពាក្យបញ្ជាកុងសូល។ ភាពងាយស្រួល និងភាពស្រស់ស្អាតរបស់វាគឺថា ទោះបីជាមួកខូច ឬអ្នកយកវាចេញពីចង្កោមក៏ដោយ ក៏សេវាកម្មរបស់អ្នកនឹងមិនរលាយបាត់ដែរ ព្រោះថាមួកសុវត្ថិភាពបម្រើតែដើម្បីចាប់ផ្តើមប្រព័ន្ធប៉ុណ្ណោះ។ បន្ទាប់មក Kubernetes ខ្លួនវាទទួលខុសត្រូវចំពោះការអនុវត្ត និងស្ថានភាពនៃសេវាកម្ម។

យើង​ក៏​បាន​ដឹង​រឿង​នោះ​ដែរ។ គំរូដែលពីមុនយើងត្រូវបានបង្ខំឱ្យធ្វើដោយខ្លួនឯងដោយណែនាំ jinja ទៅក្នុងការកំណត់រចនាសម្ព័ន្ធរបស់យើង គឺជាលក្ខណៈពិសេសចម្បងមួយនៃមួក។ ការកំណត់រចនាសម្ព័ន្ធទាំងអស់ដែលអ្នកបង្កើតសម្រាប់ប្រព័ន្ធរបស់អ្នកត្រូវបានរក្សាទុកក្នុងទម្រង់ជាគំរូ ស្រដៀងនឹង jinja ប៉ុន្តែតាមពិត ការប្រើប្រាស់គំរូនៃភាសា Go ដែលមួកត្រូវបានសរសេរដូចជា Kubernetes ជាដើម។

Helm បន្ថែមគោលគំនិតពីរបីទៀតសម្រាប់ពួកយើង។

តារាង - នេះគឺជាការពិពណ៌នាអំពីសេវាកម្មរបស់អ្នក។ នៅក្នុងកម្មវិធីគ្រប់គ្រងកញ្ចប់ផ្សេងទៀត វានឹងត្រូវបានគេហៅថា កញ្ចប់ កញ្ចប់ ឬអ្វីមួយដែលស្រដៀងគ្នា។ នៅទីនេះគេហៅថាគំនូសតាង។

គុណតម្លៃ គឺជាអថេរដែលអ្នកចង់ប្រើដើម្បីបង្កើតការកំណត់រចនាសម្ព័ន្ធរបស់អ្នកពីគំរូ។

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

ក្នុងករណីដែលយើងប្រើមួក ការកំណត់ធម្មតាសម្រាប់ Kubernetes ក៏ប្រែទៅជាគំរូដែលវាអាចប្រើអថេរ មុខងារ និងអនុវត្តសេចក្តីថ្លែងតាមលក្ខខណ្ឌ។ វិធីនេះអ្នកអាចប្រមូលការកំណត់សេវាកម្មរបស់អ្នកអាស្រ័យលើបរិស្ថាន។

នៅក្នុងការអនុវត្ត យើងបានសម្រេចចិត្តធ្វើអ្វីៗខុសពីអ្វីដែលយើងបានធ្វើជាមួយ Nomad ។ ប្រសិនបើនៅក្នុង Nomad ទាំងពីរ deployment configs និង n-variables ដែលត្រូវការដើម្បីដាក់សេវារបស់យើងត្រូវបានរក្សាទុកក្នុង repository មួយ នៅទីនេះយើងបានសម្រេចចិត្តបែងចែកវាទៅជា repositories ពីរដាច់ដោយឡែក។ ឃ្លាំង "ដាក់ពង្រាយ" រក្សាទុកតែអថេរ n ដែលត្រូវការសម្រាប់ការដាក់ពង្រាយ ហើយឃ្លាំង "មួក" រក្សាទុកការកំណត់រចនាសម្ព័ន្ធ ឬគំនូសតាង។

តើនេះបានផ្តល់ឱ្យយើងនូវអ្វី?

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

ដោយសារយើងមិនត្រឹមតែមានផលិតកម្មប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានបរិយាកាសផ្សេងទៀតដែរ ដោយសារការបំបែកនេះ យើងអាចប្រើតារាងមួករបស់យើងឡើងវិញ ដើម្បីដាក់ពង្រាយសេវាកម្មមិនត្រឹមតែសម្រាប់ផលិតកម្មប៉ុណ្ណោះទេ ប៉ុន្តែឧទាហរណ៍ផងដែរ ចំពោះបរិស្ថាន QA ផងដែរ។ សូម្បីតែដើម្បីដាក់ពង្រាយពួកវាដោយប្រើមូលដ្ឋាន មីនីគូប - នេះគឺជារឿងសម្រាប់ដំណើរការ Kubernetes ក្នុងស្រុក។

នៅខាងក្នុងឃ្លាំងនីមួយៗ យើងបានចាកចេញពីផ្នែកមួយទៅជាថតដាច់ដោយឡែកសម្រាប់សេវាកម្មនីមួយៗ។ នោះគឺនៅខាងក្នុងថតនីមួយៗមានគំរូដែលទាក់ទងនឹងតារាងដែលត្រូវគ្នា និងពណ៌នាអំពីធនធានដែលត្រូវការដាក់ពង្រាយដើម្បីបើកដំណើរការប្រព័ន្ធរបស់យើង។ យើងទុកតែ envs នៅក្នុងឃ្លាំង "ដាក់ពង្រាយ" ប៉ុណ្ណោះ។ ក្នុងករណីនេះ យើងមិនបានប្រើគំរូដោយប្រើ jinja ទេ ពីព្រោះ helm ខ្លួនវាផ្តល់នូវគំរូចេញពីប្រអប់ - នេះគឺជាមុខងារសំខាន់មួយរបស់វា។

យើងបានចាកចេញពីស្គ្រីបសម្រាប់ដាក់ពង្រាយ - deploy.sh ដែលសម្រួល និងធ្វើឱ្យមានស្តង់ដារនៃការចាប់ផ្តើមសម្រាប់ការដាក់ពង្រាយដោយប្រើមួកសុវត្ថិភាព។ ដូច្នេះសម្រាប់អ្នកដែលចង់ដាក់ពង្រាយ ចំណុចប្រទាក់ដាក់ពង្រាយមើលទៅដូចគ្នាទៅនឹងអ្វីដែលបានធ្វើនៅពេលដាក់ពង្រាយតាមរយៈ Nomad ។ deploy.sh ដូចគ្នា ឈ្មោះសេវាកម្មរបស់អ្នក និងកន្លែងដែលអ្នកចង់ដាក់ពង្រាយវា។ នេះបណ្តាលឱ្យមេចាប់ផ្តើមដំណើរការខាងក្នុង។ វាប្រមូលការកំណត់រចនាសម្ព័ន្ធពីគំរូ បញ្ចូលឯកសារតម្លៃចាំបាច់ទៅក្នុងពួកវា បន្ទាប់មកដាក់ពង្រាយពួកវា បើកដំណើរការពួកវាទៅក្នុង Kubernetes ។

ការរកឃើញ

សេវា Kubernetes ហាក់ដូចជាស្មុគស្មាញជាង Nomad ។

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

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

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

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

ប្រភព: www.habr.com