តើ GitOps ជាអ្វី?

ចំណាំ។ បកប្រែ៖ បន្ទាប់ពីការបោះពុម្ពផ្សាយថ្មីៗនេះ សម្ភារៈ អំពីវិធីសាស្ត្រទាញ និងរុញនៅក្នុង GitOps យើងបានឃើញការចាប់អារម្មណ៍លើគំរូនេះជាទូទៅ ប៉ុន្តែមានការបោះពុម្ពផ្សាយជាភាសារុស្សីតិចតួចណាស់លើប្រធានបទនេះ (មិនមាននៅលើHabréទេ)។ ដូច្នេះ យើង​រីករាយ​នឹង​ផ្តល់​ជូន​ដល់​អ្នក​នូវ​ការ​បក​ប្រែ​អត្ថបទ​មួយ​ផ្សេង​ទៀត ទោះបី​ជិត​មួយ​ឆ្នាំ​មុន​ក៏​ដោយ! - ពី Weaveworks ដែលជាប្រធានដែលបានបង្កើតពាក្យ "GitOps" ។ អត្ថបទពន្យល់ពីខ្លឹមសារនៃវិធីសាស្រ្ត និងភាពខុសគ្នាសំខាន់ៗពីអ្វីដែលមានស្រាប់។

មួយឆ្នាំមុនយើងបានបោះពុម្ព ការណែនាំអំពី GitOps. ត្រលប់មកវិញ យើងបានចែករំលែកពីរបៀបដែលក្រុម Weaveworks បានចាប់ផ្តើម SaaS ទាំងស្រុងដោយផ្អែកលើ Kubernetes និងបានបង្កើតសំណុំនៃការអនុវត្តល្អបំផុតតាមវេជ្ជបញ្ជាសម្រាប់ការដាក់ពង្រាយ គ្រប់គ្រង និងការត្រួតពិនិត្យនៅក្នុងបរិយាកាសដែលមានមូលដ្ឋានលើពពក។

អត្ថបទបានប្រែក្លាយជាពេញនិយម។ មនុស្សផ្សេងទៀតបានចាប់ផ្តើមនិយាយអំពី GitOps ហើយបានចាប់ផ្តើមបោះពុម្ពឧបករណ៍ថ្មីសម្រាប់ ជំរុញ git, ការអភិវឌ្ឍ, អាថ៌កំបាំង, មុខងារ។, ការរួមបញ្ចូលជាបន្តបន្ទាប់ ល​ល។ បានបង្ហាញខ្លួននៅលើគេហទំព័ររបស់យើង។ ចំនួនធំ ការបោះពុម្ពផ្សាយ និងករណីប្រើប្រាស់ GitOps ។ ប៉ុន្តែមនុស្សមួយចំនួននៅតែមានសំណួរ។ តើ​គំរូ​ខុស​ប្លែក​ពី​គំរូ​បែប​ណា? ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ និងការចែកចាយបន្ត (ការចែកចាយបន្ត។)? តើចាំបាច់ត្រូវប្រើ Kubernetes ដែរឬទេ?

យើងដឹងភ្លាមៗថាត្រូវការការពណ៌នាថ្មី ដោយផ្តល់ជូន៖

1. មួយចំនួនធំនៃឧទាហរណ៍និងរឿង;
2. និយមន័យជាក់លាក់នៃ GitOps;
3. ការប្រៀបធៀបជាមួយនឹងការចែកចាយបន្តប្រពៃណី។

នៅក្នុងអត្ថបទនេះ យើងបានព្យាយាមគ្របដណ្តប់លើប្រធានបទទាំងអស់នេះ។ វាផ្តល់នូវការណែនាំថ្មីៗចំពោះ GitOps និងអ្នកអភិវឌ្ឍន៍ និងទស្សនវិស័យ CI/CD ។ យើងផ្តោតជាចម្បងលើ Kubernetes ទោះបីជាគំរូអាចមានលក្ខណៈទូទៅក៏ដោយ។

ជួបជាមួយ GitOps

ស្រមៃមើលអាលីស។ នាងបើកការធានារ៉ាប់រងគ្រួសារ ដែលផ្តល់សេវាធានារ៉ាប់រងសុខភាព រថយន្ត ផ្ទះ និងការធ្វើដំណើរដល់មនុស្សដែលមមាញឹកពេកក្នុងការស្វែងយល់ពីកិច្ចសន្យា និងកិច្ចសន្យាដោយខ្លួនឯង។ អាជីវកម្មរបស់នាងបានចាប់ផ្តើមជាគម្រោងចំហៀង នៅពេលដែល Alice កំពុងធ្វើការនៅធនាគារមួយក្នុងនាមជាអ្នកវិទ្យាសាស្ត្រទិន្នន័យ។ ថ្ងៃមួយ នាងបានដឹងថា នាងអាចប្រើក្បួនដោះស្រាយកុំព្យូទ័រកម្រិតខ្ពស់ ដើម្បីវិភាគទិន្នន័យ និងបង្កើតកញ្ចប់ធានារ៉ាប់រងកាន់តែមានប្រសិទ្ធភាព។ វិនិយោគិនបានផ្តល់ហិរញ្ញប្បទានដល់គម្រោងនេះ ហើយឥឡូវនេះក្រុមហ៊ុនរបស់នាងអាចរកចំណូលបានជាង 20 លានដុល្លារក្នុងមួយឆ្នាំ ហើយកំពុងរីកចម្រើនយ៉ាងឆាប់រហ័ស។ បច្ចុប្បន្ននេះ វាមានបុគ្គលិកចំនួន 180 នាក់ក្នុងមុខតំណែងផ្សេងៗ។ នេះរួមបញ្ចូលទាំងក្រុមបច្ចេកវិទ្យាដែលបង្កើត ថែរក្សាគេហទំព័រ មូលដ្ឋានទិន្នន័យ និងវិភាគមូលដ្ឋានអតិថិជន។ ក្រុមមនុស្ស 60 នាក់ដឹកនាំដោយលោក Bob ដែលជានាយកបច្ចេកទេសរបស់ក្រុមហ៊ុន។

ក្រុមរបស់លោក Bob ដាក់ពង្រាយប្រព័ន្ធផលិតកម្មនៅក្នុងពពក។ កម្មវិធីស្នូលរបស់ពួកគេដំណើរការលើ GKE ដោយទាញយកអត្ថប្រយោជន៍ពី Kubernetes នៅលើ Google Cloud ។ លើសពីនេះទៀត ពួកគេប្រើប្រាស់ទិន្នន័យ និងឧបករណ៍វិភាគផ្សេងៗក្នុងការងាររបស់ពួកគេ។

ការធានារ៉ាប់រងគ្រួសារមិនបានកំណត់ប្រើប្រាស់កុងតឺន័រទេ ប៉ុន្តែបានជាប់នៅក្នុងភាពរីករាយរបស់ Docker ។ ក្រុមហ៊ុនបានរកឃើញភ្លាមៗថា GKE ធ្វើឱ្យវាងាយស្រួលក្នុងការដាក់ពង្រាយក្រុមដើម្បីសាកល្បងមុខងារថ្មីៗ។ Jenkins សម្រាប់ CI និង Quay ត្រូវបានបន្ថែមដើម្បីរៀបចំបញ្ជីឈ្មោះកុងតឺន័រ ស្គ្រីបត្រូវបានសរសេរសម្រាប់ Jenkins ដែលរុញកុងតឺន័រ និងការកំណត់រចនាសម្ព័ន្ធថ្មីទៅ GKE ។

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

បន្ទាប់មកពួកគេបានរៀនអំពី GitOps ។ ការ​សម្រេច​ចិត្ត​នេះ​បាន​ក្លាយ​ជា​អ្វី​ដែល​ពួក​គេ​ត្រូវ​ការ​ដើម្បី​ឈាន​ទៅ​មុខ​ដោយ​ទំនុក​ចិត្ត។

Alice និង Bob បានឮអំពី Git, DevOps និងហេដ្ឋារចនាសម្ព័ន្ធជាលំហូរការងារកូដអស់ជាច្រើនឆ្នាំ។ អ្វីដែលពិសេសអំពី GitOps គឺថាវានាំមកនូវសំណុំនៃការអនុវត្តល្អបំផុត - ទាំងច្បាស់លាស់ និងបទដ្ឋាន - សម្រាប់ការអនុវត្តគំនិតទាំងនេះនៅក្នុងបរិបទរបស់ Kubernetes ។ ប្រធានបទនេះ។ បានកើនឡើងម្តងហើយម្តងទៀតរួមទាំងនៅក្នុង ប្លុក Weaveworks.

ការធានារ៉ាប់រងគ្រួសារសម្រេចចិត្តអនុវត្ត GitOps ។ ឥឡូវនេះក្រុមហ៊ុនមានគំរូប្រតិបត្តិការដោយស្វ័យប្រវត្តិដែលអាចប្រើបានជាមួយ Kubernetes និងរួមបញ្ចូលគ្នា ល្បឿន សែ ស្ថេរភាពពីព្រោះ​ពួកគេ:

• បានរកឃើញថាផលិតភាពរបស់ក្រុមបានកើនឡើងទ្វេដងដោយគ្មាននរណាម្នាក់ឆ្កួត។
• ឈប់​បម្រើ​ស្គ្រីប។ ជំនួសមកវិញ ឥឡូវនេះ ពួកគេអាចផ្តោតលើលក្ខណៈពិសេសថ្មី និងកែលម្អវិធីសាស្រ្តវិស្វកម្ម - ឧទាហរណ៍ ការណែនាំអំពី Canary rollouts និងធ្វើអោយប្រសើរឡើងនូវការធ្វើតេស្ត។
• យើងបានធ្វើឱ្យប្រសើរឡើងនូវដំណើរការដាក់ពង្រាយដូច្នេះវាកម្រនឹងបែកបាក់។
• ទទួលបានឱកាសដើម្បីស្តារការដាក់ពង្រាយឡើងវិញបន្ទាប់ពីការបរាជ័យដោយផ្នែកដោយគ្មានការអន្តរាគមន៍ដោយដៃ។
• បានទិញប្រើоទំនុកចិត្តកាន់តែខ្លាំងនៅក្នុងប្រព័ន្ធចែកចាយ។ Alice និង Bob បានរកឃើញថាពួកគេអាចបំបែកក្រុមទៅជាក្រុមមីក្រូសេវាដែលធ្វើការស្របគ្នា។
• អាចធ្វើការផ្លាស់ប្តូរ 30-50 ចំពោះគម្រោងជារៀងរាល់ថ្ងៃតាមរយៈការខិតខំប្រឹងប្រែងរបស់ក្រុមនីមួយៗ និងសាកល្បងបច្ចេកទេសថ្មីៗ។
• វាមានភាពងាយស្រួលក្នុងការទាក់ទាញអ្នកអភិវឌ្ឍន៍ថ្មីមកគម្រោងនេះ ដែលមានឱកាសបញ្ចេញបច្ចុប្បន្នភាពទៅផលិតកម្មដោយប្រើសំណើទាញក្នុងរយៈពេលពីរបីម៉ោង។
• ឆ្លងកាត់សវនកម្មយ៉ាងងាយស្រួលក្នុងក្របខ័ណ្ឌនៃ SOC2 (សម្រាប់ការអនុលោមតាមអ្នកផ្តល់សេវាជាមួយនឹងតម្រូវការសម្រាប់ការគ្រប់គ្រងទិន្នន័យប្រកបដោយសុវត្ថិភាព សូមអានបន្ថែម ឧទាហរណ៍ នៅទីនេះ - ប្រហែល បកប្រែ។ ).

តើមានអ្វីកើតឡើង?

GitOps គឺជារឿងពីរ៖

1. គំរូប្រតិបត្តិការសម្រាប់ Kubernetes និងពពកដើម។ វាផ្តល់នូវសំណុំនៃការអនុវត្តល្អបំផុតសម្រាប់ការដាក់ពង្រាយ គ្រប់គ្រង និងត្រួតពិនិត្យក្រុម និងកម្មវិធីដែលមានកុងតឺន័រ។ និយមន័យឆើតឆាយក្នុងទម្រង់ ស្លាយមួយ។ ពី Luis Faceira:
2. ផ្លូវទៅកាន់ការបង្កើតបរិយាកាសគ្រប់គ្រងកម្មវិធីដែលផ្តោតលើអ្នកអភិវឌ្ឍន៍។ យើងអនុវត្តលំហូរការងារ Git ទាំងប្រតិបត្តិការ និងការអភិវឌ្ឍន៍។ សូមចំណាំថានេះមិនមែនគ្រាន់តែអំពី Git push ប៉ុណ្ណោះទេ ប៉ុន្តែអំពីការរៀបចំសំណុំឧបករណ៍ CI/CD និង UI/UX ទាំងមូល។

ពាក្យពីរបីអំពី Git

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

របៀបដែល Kubernetes ដំណើរការ

នៅក្នុងរឿងរបស់យើង Alice និង Bob បានងាកទៅរក GitOps បន្ទាប់ពីធ្វើការជាមួយ Kubernetes មួយរយៈ។ ជាការពិតណាស់ GitOps មានទំនាក់ទំនងយ៉ាងជិតស្និទ្ធជាមួយ Kubernetes - វាគឺជាគំរូប្រតិបត្តិការសម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធ និងកម្មវិធីដែលមានមូលដ្ឋានលើ Kubernetes ។

តើ Kubernetes ផ្តល់ឱ្យអ្នកប្រើប្រាស់អ្វីខ្លះ?

នេះគឺជាលក្ខណៈសំខាន់ៗមួយចំនួន៖

1. នៅក្នុងគំរូ Kubernetes អ្វីគ្រប់យ៉ាងអាចត្រូវបានពិពណ៌នាជាទម្រង់ប្រកាស។
2. ម៉ាស៊ីនមេ Kubernetes API ទទួលយកការប្រកាសនេះជាការបញ្ចូល ហើយបន្ទាប់មកបន្តព្យាយាមនាំយកចង្កោមទៅក្នុងស្ថានភាពដែលបានពិពណ៌នានៅក្នុងសេចក្តីប្រកាស។
3. សេចក្តីប្រកាសគឺគ្រប់គ្រាន់ដើម្បីពិពណ៌នា និងគ្រប់គ្រងបន្ទុកការងារជាច្រើនប្រភេទ—“កម្មវិធី”។
4. ជាលទ្ធផល ការផ្លាស់ប្តូរកម្មវិធី និងចង្កោមកើតឡើងដោយសារតែ៖
   • ការផ្លាស់ប្តូរនៅក្នុងរូបភាពធុង;
   • ការផ្លាស់ប្តូរទៅការបញ្ជាក់ការប្រកាស;
   • កំហុសក្នុងបរិស្ថាន - ឧទាហរណ៍ កុងតឺន័រគាំង។

សមត្ថភាពរួមដ៏អស្ចារ្យរបស់ Kubernetes

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

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

របៀបដែល GitOps ដំណើរការ

យើងបានរៀនគ្រប់គ្រាន់អំពី Kubernetes ដើម្បីពន្យល់ពីរបៀបដែល GitOps ដំណើរការ។

តោះត្រឡប់ទៅក្រុមសេវាមីក្រូរបស់ Family Insurance វិញ។ តើពួកគេជាធម្មតាត្រូវធ្វើអ្វី? សូមក្រឡេកមើលបញ្ជីខាងក្រោម (ប្រសិនបើធាតុណាមួយនៅក្នុងវាហាក់ដូចជាចម្លែក ឬមិនច្បាស់ សូមរង់ចាំការរិះគន់ និងនៅជាមួយយើង)។ ទាំងនេះគ្រាន់តែជាឧទាហរណ៍នៃលំហូរការងារដែលមានមូលដ្ឋានលើ Jenkins ប៉ុណ្ណោះ។ មានដំណើរការផ្សេងទៀតជាច្រើននៅពេលធ្វើការជាមួយឧបករណ៍ផ្សេងទៀត។

រឿងចំបងគឺថាយើងឃើញថាការធ្វើបច្ចុប្បន្នភាពនីមួយៗបញ្ចប់ដោយការផ្លាស់ប្តូរឯកសារកំណត់រចនាសម្ព័ន្ធនិងឃ្លាំង Git ។ ការផ្លាស់ប្តូរទាំងនេះចំពោះ Git បណ្តាលឱ្យ "ប្រតិបត្តិករ GitOps" ធ្វើបច្ចុប្បន្នភាពចង្កោម៖

1. ដំណើរការការងារ៖ "Jenkins សាងសង់ - សាខាមេ"។
បញ្ជីកិច្ចការ៖

• Jenkins រុញរូបភាពដាក់ស្លាកទៅ Quay;
• Jenkins រុញតារាង config និង Helm ទៅធុងផ្ទុកមេ។
• មុខងារពពកចម្លងការកំណត់ និងគំនូសតាងពីធុងផ្ទុកមេទៅឃ្លាំង Git មេ។
• ប្រតិបត្តិករ GitOps ធ្វើបច្ចុប្បន្នភាពចង្កោម។

2. Jenkins build - ចេញផ្សាយ ឬសាខា hotfix:

• Jenkins រុញរូបភាពដែលមិនដាក់ស្លាកទៅ Quay;
• Jenkins រុញគំនូសតាង config និង Helm ទៅធុងផ្ទុកដំណាក់កាល។
• មុខងារ cloud ចម្លង config និង charts ពី staging storage bucket ទៅ staging Git repository;
• ប្រតិបត្តិករ GitOps ធ្វើបច្ចុប្បន្នភាពចង្កោម។

3. Jenkins សាងសង់ - អភិវឌ្ឍឬសាខាលក្ខណៈពិសេស:

• Jenkins រុញរូបភាពដែលមិនដាក់ស្លាកទៅ Quay;
• Jenkins រុញគំនូសតាង config និង Helm ទៅក្នុងធុងផ្ទុកដែលបានអភិវឌ្ឍ។
• មុខងារ cloud ចម្លងការកំណត់ និងគំនូសតាងពី develop bucket storage ទៅ develop Git repository;
• ប្រតិបត្តិករ GitOps ធ្វើបច្ចុប្បន្នភាពចង្កោម។

4. ការបន្ថែមអតិថិជនថ្មី។:

• អ្នកគ្រប់គ្រង ឬអ្នកគ្រប់គ្រង (LCM/ops) ហៅ Gradle ដើម្បីដាក់ពង្រាយ និងកំណត់រចនាសម្ព័ន្ធតុល្យភាពផ្ទុកបណ្តាញ (NLBs) ដំបូង។
• LCM/ops កំណត់រចនាសម្ព័ន្ធថ្មី ដើម្បីរៀបចំការដាក់ពង្រាយសម្រាប់ការអាប់ដេត។
• ប្រតិបត្តិករ GitOps ធ្វើបច្ចុប្បន្នភាពចង្កោម។

ការពិពណ៌នាសង្ខេបនៃ GitOps

1. ពិពណ៌នាអំពីស្ថានភាពដែលចង់បាននៃប្រព័ន្ធទាំងមូលដោយប្រើការបញ្ជាក់ជាក់លាក់សម្រាប់បរិស្ថាននីមួយៗ (នៅក្នុងរឿងរបស់យើង ក្រុមរបស់លោក Bob កំណត់ការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធទាំងមូលនៅក្នុង Git) ។
   • ឃ្លាំង Git គឺជាប្រភពតែមួយនៃការពិតទាក់ទងនឹងស្ថានភាពដែលចង់បាននៃប្រព័ន្ធទាំងមូល។
   • ការផ្លាស់ប្តូរទាំងអស់ចំពោះស្ថានភាពដែលចង់បានគឺធ្វើឡើងតាមរយៈការសន្យានៅក្នុង Git ។
   • ប៉ារ៉ាម៉ែត្រចង្កោមដែលចង់បានទាំងអស់ក៏អាចមើលឃើញនៅក្នុងចង្កោមខ្លួនឯងផងដែរ។ តាមវិធីនេះ យើងអាចកំណត់ថាតើវាស្របគ្នាឬអត់? បង្រួម) ឬខុសគ្នា (ខុសគ្នា, ខុសគ្នា) រដ្ឋដែលចង់បាននិងសង្កេត។
2. ប្រសិនបើរដ្ឋដែលចង់បាន និងសង្កេតខុសគ្នា នោះ៖
   • មានយន្តការបង្រួបបង្រួមដែលឆាប់ឬក្រោយមកធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិនូវគោលដៅ និងស្ថានភាពដែលបានសង្កេត។ នៅខាងក្នុងក្រុម Kubernetes ធ្វើបែបនេះ។
   • ដំណើរការចាប់ផ្តើមភ្លាមៗជាមួយនឹងការជូនដំណឹង "ការផ្លាស់ប្តូរដែលបានប្តេជ្ញាចិត្ត" ។
   • បន្ទាប់ពីរយៈពេលកំណត់រចនាសម្ព័ន្ធមួយចំនួន ការជូនដំណឹង "ភាពខុសគ្នា" អាចត្រូវបានផ្ញើប្រសិនបើរដ្ឋខុសគ្នា។
3. វិធីនេះ រាល់ការប្រព្រឹត្តនៅក្នុង Git បង្កឱ្យមានការអាប់ដេតដែលអាចផ្ទៀងផ្ទាត់បាន និងគ្មានសក្តានុពលចំពោះចង្កោម។
   • Rollback គឺ​ជា​ការ​រួម​បញ្ចូល​គ្នា​ទៅ​នឹង​ស្ថានភាព​ដែល​ចង់​បាន​ពី​មុន។
4. ការ​រួម​គ្នា​គឺ​ជា​ចុង​ក្រោយ​។ ការកើតឡើងរបស់វាត្រូវបានបង្ហាញដោយ៖
   • មិនមានការជូនដំណឹងខុសគ្នាទេសម្រាប់រយៈពេលជាក់លាក់មួយ។
   • ការជូនដំណឹង "បម្លែង" (ឧទាហរណ៍ webhook, Git writeback event) ។

តើអ្វីជាភាពខុសគ្នា?

សូម​និយាយ​ម្តង​ទៀត៖ លក្ខណសម្បត្តិចង្កោមដែលចង់បានទាំងអស់ត្រូវតែអាចមើលបាននៅក្នុងចង្កោមខ្លួនវា.

ឧទាហរណ៍ខ្លះនៃភាពខុសគ្នា៖

• ការផ្លាស់ប្តូរនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធដោយសារតែការបញ្ចូលសាខានៅក្នុង Git ។
• ការផ្លាស់ប្តូរនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធដោយសារតែ Git commit ដែលធ្វើឡើងដោយម៉ាស៊ីនភ្ញៀវ GUI ។
• ការផ្លាស់ប្តូរជាច្រើនចំពោះស្ថានភាពដែលចង់បានដោយសារតែ PR នៅក្នុង Git អមដោយការកសាងរូបភាពកុងតឺន័រ និងការផ្លាស់ប្តូរការកំណត់។
• ការផ្លាស់ប្តូរនៅក្នុងស្ថានភាពនៃចង្កោមដោយសារតែកំហុស ការប៉ះទង្គិចធនធានដែលបណ្តាលឱ្យមាន "អាកប្បកិរិយាមិនល្អ" ឬជាធម្មតាគម្លាតចៃដន្យពីស្ថានភាពដើម។

តើយន្តការនៃការបង្រួបបង្រួមគឺជាអ្វី?

ឧទាហរណ៍មួយចំនួន:

• សម្រាប់កុងតឺន័រ និងចង្កោម យន្តការបញ្ចូលគ្នាត្រូវបានផ្តល់ដោយ Kubernetes ។
• យន្តការដូចគ្នាអាចត្រូវបានប្រើដើម្បីគ្រប់គ្រងកម្មវិធី និងការរចនាដែលមានមូលដ្ឋានលើ Kubernetes (ដូចជា Istio និង Kubeflow)។
• យន្តការសម្រាប់គ្រប់គ្រងអន្តរកម្មប្រតិបត្តិការរវាង Kubernetes ឃ្លាំងរូបភាព និង Git ផ្ដល់ជូន ប្រតិបត្តិករ GitOps Weave Fluxដែលជាផ្នែក ត្បាញពពក.
• សម្រាប់ម៉ាស៊ីនមូលដ្ឋាន យន្តការបង្រួបបង្រួមត្រូវតែប្រកាស និងស្វយ័ត។ តាមបទពិសោធន៍របស់យើង យើងអាចនិយាយបានថា Terraform ជិតបំផុតទៅនឹងនិយមន័យនេះ ប៉ុន្តែនៅតែទាមទារការគ្រប់គ្រងរបស់មនុស្ស។ ក្នុងន័យនេះ GitOps ពង្រីកប្រពៃណីនៃហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។

GitOps រួមបញ្ចូលគ្នានូវ Git ជាមួយនឹងម៉ាស៊ីនបញ្ចូលគ្នាដ៏ល្អឥតខ្ចោះរបស់ Kubernetes ដើម្បីផ្តល់នូវគំរូសម្រាប់ការកេងប្រវ័ញ្ច។

GitOps អនុញ្ញាតឱ្យយើងនិយាយ៖ មាន​តែ​ប្រព័ន្ធ​ដែល​អាច​ត្រូវ​បាន​ពណ៌នា និង​សង្កេត​ប៉ុណ្ណោះ​ដែល​អាច​ត្រូវ​បាន​ស្វ័យប្រវត្តិ និង​គ្រប់គ្រង.

GitOps ត្រូវបានបម្រុងទុកសម្រាប់ជង់ដើមនៃពពកទាំងមូល (ឧទាហរណ៍ Terraform ។ល។)

GitOps មិនត្រឹមតែ Kubernetes ប៉ុណ្ណោះទេ។ យើងចង់ឱ្យប្រព័ន្ធទាំងមូលត្រូវបានជំរុញដោយប្រកាស និងប្រើការបញ្ចូលគ្នា។ តាមរយៈប្រព័ន្ធទាំងមូល យើងមានន័យថាបណ្តុំនៃបរិស្ថានដែលធ្វើការជាមួយ Kubernetes - ឧទាហរណ៍ "dev cluster 1", "production" ។ល។ បរិយាកាសនីមួយៗរួមមានម៉ាស៊ីន ចង្កោម កម្មវិធី ក៏ដូចជាចំណុចប្រទាក់សម្រាប់សេវាកម្មខាងក្រៅដែលផ្តល់ទិន្នន័យ ការត្រួតពិនិត្យ និងល។

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

មាន​ការ​ផ្តោត​ខ្លាំង​លើ​ការ​អនុវត្ត​គោល​គំនិត GitOps ទៅ​ស្រទាប់​នៅ​លើ Kubernetes។ នៅពេលនេះ មានដំណោះស្រាយប្រភេទ GitOps សម្រាប់ Istio, Helm, Ksonnet, OpenFaaS និង Kubeflow ក៏ដូចជាឧទាហរណ៍សម្រាប់ Pulumi ដែលបង្កើតស្រទាប់សម្រាប់បង្កើតកម្មវិធីសម្រាប់ពពកដើម។

Kubernetes CI/CD៖ ប្រៀបធៀប GitOps ជាមួយវិធីសាស្រ្តផ្សេងទៀត។

ដូចដែលបានបញ្ជាក់ GitOps គឺជារឿងពីរ៖

1. គំរូប្រតិបត្តិការសម្រាប់ Kubernetes និងពពកដើមដែលបានពិពណ៌នាខាងលើ។
2. ផ្លូវទៅកាន់បរិយាកាសគ្រប់គ្រងកម្មវិធីដែលផ្តោតលើអ្នកអភិវឌ្ឍន៍។

សម្រាប់មនុស្សជាច្រើន GitOps គឺជាលំហូរការងារជាចម្បងដោយផ្អែកលើ Git pushes ។ យើងក៏ចូលចិត្តគាត់ដែរ។ ប៉ុន្តែនោះមិនមែនទាំងអស់ទេ៖ ឥឡូវនេះ សូមក្រឡេកមើល CI/CD pipelines។

GitOps បើកដំណើរការបន្តដាក់ពង្រាយ (CD) សម្រាប់ Kubernetes

GitOps ផ្តល់នូវយន្តការដាក់ពង្រាយជាបន្តបន្ទាប់ដែលលុបបំបាត់តម្រូវការសម្រាប់ "ប្រព័ន្ធគ្រប់គ្រងការដាក់ពង្រាយ" ដាច់ដោយឡែក។ Kubernetes ធ្វើការងារទាំងអស់សម្រាប់អ្នក។

• ការធ្វើបច្ចុប្បន្នភាពកម្មវិធីតម្រូវឱ្យធ្វើបច្ចុប្បន្នភាពនៅក្នុង Git ។ នេះគឺជាការធ្វើបច្ចុប្បន្នភាពប្រតិបត្តិការទៅរដ្ឋដែលចង់បាន។ បន្ទាប់មក "ការដាក់ឱ្យប្រើប្រាស់" ត្រូវបានធ្វើនៅក្នុងចង្កោមដោយ Kubernetes ខ្លួនវាដោយផ្អែកលើការពិពណ៌នាដែលបានធ្វើបច្ចុប្បន្នភាព។
• ដោយសារលក្ខណៈនៃរបៀបដែល Kubernetes ដំណើរការ ការធ្វើបច្ចុប្បន្នភាពទាំងនេះត្រូវបានបញ្ចូលគ្នា។ នេះផ្តល់នូវយន្តការមួយសម្រាប់ការដាក់ពង្រាយជាបន្តបន្ទាប់ ដែលការធ្វើបច្ចុប្បន្នភាពទាំងអស់គឺជាអាតូមិក។
• ចំណាំ: ត្បាញពពក ផ្តល់ជូនប្រតិបត្តិករ GitOps ដែលរួមបញ្ចូល Git និង Kubernetes ហើយអនុញ្ញាតឱ្យស៊ីឌីដំណើរការដោយផ្សះផ្សាស្ថានភាពដែលចង់បាន និងបច្ចុប្បន្ននៃចង្កោម។

ដោយគ្មាន kubectl និងស្គ្រីប

អ្នកគួរជៀសវាងការប្រើ Kubectl ដើម្បីធ្វើបច្ចុប្បន្នភាពចង្កោមរបស់អ្នក ហើយជាពិសេសជៀសវាងការប្រើស្គ្រីបដើម្បីធ្វើជាក្រុមពាក្យបញ្ជា kubectl ។ ជំនួសមកវិញ ជាមួយនឹងបំពង់ GitOps អ្នកប្រើប្រាស់អាចធ្វើបច្ចុប្បន្នភាពក្រុម Kubernetes របស់ពួកគេតាមរយៈ Git ។

អត្ថប្រយោជន៍រួមមាន:

1. ត្រូវហើយ។. ការអាប់ដេតមួយក្រុមអាចត្រូវបានអនុវត្ត បង្រួបបង្រួម និងចុងក្រោយធ្វើឱ្យមានសុពលភាព ដែលនាំឱ្យយើងខិតទៅជិតគោលដៅនៃការដាក់ពង្រាយបរមាណូ។ ផ្ទុយទៅវិញ ការប្រើស្គ្រីបមិនផ្តល់ការធានាណាមួយនៃការបញ្ចូលគ្នាទេ (បន្ថែមលើចំណុចខាងក្រោម)។
2. សន្តិសុខ. សម្រង់ Kelsey Hightower៖ "ដាក់កម្រិតការចូលប្រើចង្កោម Kubernetes របស់អ្នកចំពោះឧបករណ៍ស្វ័យប្រវត្តិកម្ម និងអ្នកគ្រប់គ្រងដែលទទួលខុសត្រូវក្នុងការបំបាត់កំហុស ឬថែទាំវា។" សូម​មើល​ផង​ដែរ ការបោះពុម្ពរបស់ខ្ញុំ អំពីសុវត្ថិភាព និងការអនុលោមតាមលក្ខណៈបច្ចេកទេស ក៏ដូចជា អត្ថបទអំពីការលួចចូល Homebrew ដោយការលួចលិខិតសម្គាល់ពីស្គ្រីប Jenkins ដែលសរសេរដោយមិនដឹងខ្លួន។
3. បទពិសោធន៍អ្នកប្រើប្រាស់. Kubectl លាតត្រដាងមេកានិចនៃគំរូវត្ថុ Kubernetes ដែលស្មុគស្មាញណាស់។ តាមឧត្ដមគតិ អ្នកប្រើប្រាស់គួរធ្វើអន្តរកម្មជាមួយប្រព័ន្ធនៅកម្រិតខ្ពស់នៃអរូបី។ នៅទីនេះខ្ញុំនឹងយោងទៅ Kelsey ម្តងទៀត ហើយណែនាំឱ្យមើល ប្រវត្តិរូបបែបនេះ.

ភាពខុសគ្នារវាងស៊ីឌី និងស៊ីឌី

GitOps កែលម្អម៉ូដែល CI/CD ដែលមានស្រាប់។

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

CI គួរតែត្រូវបានប្រើដើម្បីជំរុញការអាប់ដេតទៅកាន់ trunk ហើយចង្កោម Kubernetes គួរតែផ្លាស់ប្តូរខ្លួនឯងដោយផ្អែកលើការអាប់ដេតទាំងនោះ ដើម្បីគ្រប់គ្រងស៊ីឌីខាងក្នុង។ យើងហៅវា។ ទាញគំរូសម្រាប់ស៊ីឌីមិនដូចគំរូជំរុញ CI ។ ស៊ីឌីជាផ្នែក ការ​ប្រគុំ​តន្ត្រី​ពេល​រត់.

ហេតុអ្វីបានជាម៉ាស៊ីនមេ CI មិនគួរធ្វើស៊ីឌីតាមរយៈការធ្វើបច្ចុប្បន្នភាពដោយផ្ទាល់នៅក្នុង Kubernetes

កុំប្រើម៉ាស៊ីនមេ CI ដើម្បីរៀបចំការធ្វើបច្ចុប្បន្នភាពដោយផ្ទាល់ទៅ Kubernetes ជាសំណុំនៃការងារ CI ។ នេះ​ជា​ការ​ប្រឆាំង​នឹង​លំនាំ​ដែល​យើង​កំពុង​និយាយ បានប្រាប់រួចហើយ នៅលើប្លក់របស់អ្នក។

តោះត្រឡប់ទៅ Alice និង Bob វិញ។

តើ​ពួក​គេ​បាន​ជួប​បញ្ហា​អ្វី​ខ្លះ? ម៉ាស៊ីនមេ CI របស់ Bob អនុវត្តការផ្លាស់ប្ដូរចំពោះចង្កោម ប៉ុន្តែប្រសិនបើវាគាំងនៅក្នុងដំណើរការនោះ លោក Bob នឹងមិនដឹងថា តើចង្កោមស្ថិតក្នុងស្ថានភាពបែបណា (ឬគួរតែ) ឬរបៀបជួសជុលវានោះទេ។ ដូចគ្នាដែរក្នុងករណីជោគជ័យ។

ឧបមាថាក្រុមរបស់លោក Bob បានបង្កើតរូបភាពថ្មីមួយ ហើយបន្ទាប់មកបានជួសជុលការដាក់ពង្រាយរបស់ពួកគេ ដើម្បីដាក់ពង្រាយរូបភាព (ទាំងអស់ចេញពីបំពង់ CI)។

ប្រសិនបើរូបភាពសាងសង់ជាធម្មតា ប៉ុន្តែបំពង់បង្ហូរប្រេងបរាជ័យ ក្រុមការងារនឹងត្រូវដោះស្រាយ៖

• តើការអាប់ដេតបានចេញហើយឬនៅ?
• តើ​យើង​ចាប់​ផ្តើម​សាងសង់​ថ្មី​ឬ​ទេ? តើនេះនឹងនាំឱ្យមានផលប៉ះពាល់ដែលមិនចាំបាច់ - ជាមួយនឹងលទ្ធភាពនៃការមានការបង្កើតពីរនៃរូបភាពដែលមិនអាចផ្លាស់ប្តូរបានដូចគ្នា?
• តើ​យើង​គួរ​រង់​ចាំ​ការ​អាប់ដេត​លើក​ក្រោយ​មុន​នឹង​ដំណើរការ​ការ​បង្កើត​ឬ?
• តើមានអ្វីខុសពិតប្រាកដ? តើជំហានណាដែលត្រូវធ្វើម្តងទៀត (ហើយជំហានណាដែលមានសុវត្ថិភាពក្នុងការធ្វើម្តងទៀត)?

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

ដើម្បីសង្ខេប នេះជាមូលហេតុដែលម៉ាស៊ីនមេ CI មិនគួរដោះស្រាយជាមួយស៊ីឌី៖

• ការអាប់ដេតស្គ្រីបមិនតែងតែកំណត់ទេ។ វាងាយស្រួលក្នុងការធ្វើឱ្យមានកំហុសនៅក្នុងពួកគេ។
• ម៉ាស៊ីនមេ CI មិនបម្លែងទៅជាគំរូចង្កោមប្រកាសទេ។
• វាពិបាកក្នុងការធានាភាពទន់ខ្សោយ។ អ្នក​ប្រើ​ត្រូវ​តែ​យល់​ពី​ន័យ​ជ្រៅ​នៃ​ប្រព័ន្ធ។
• វាពិបាកជាងក្នុងការងើបឡើងវិញពីការបរាជ័យដោយផ្នែក។

កំណត់ចំណាំអំពី Helm៖ ប្រសិនបើអ្នកចង់ប្រើ Helm យើងសូមណែនាំឱ្យផ្សំវាជាមួយប្រតិបត្តិករ GitOps ដូចជា Flux-Helm. នេះនឹងជួយធានាបាននូវការរួបរួមគ្នា។ Helm ខ្លួនវាមិនមែនជាកត្តាកំណត់ ឬអាតូមិកទេ។

GitOps ជាមធ្យោបាយដ៏ល្អបំផុតដើម្បីអនុវត្តការចែកចាយបន្តសម្រាប់ Kubernetes

ក្រុមរបស់ Alice និង Bob អនុវត្ត GitOps ហើយរកឃើញថាវាកាន់តែងាយស្រួលធ្វើការជាមួយផលិតផលសូហ្វវែរ រក្សាប្រសិទ្ធភាពខ្ពស់ និងស្ថេរភាព។ សូម​បញ្ចប់​អត្ថបទ​នេះ​ដោយ​ការ​បង្ហាញ​អំពី​អ្វី​ដែល​វិធី​សាស្រ្ដ​ថ្មី​របស់​ពួក​គេ​មើល​ទៅ​ដូច​ជា។ សូមចងចាំថាភាគច្រើនយើងកំពុងនិយាយអំពីកម្មវិធី និងសេវាកម្ម ប៉ុន្តែ GitOps អាចត្រូវបានប្រើដើម្បីគ្រប់គ្រងវេទិកាទាំងមូល។

គំរូប្រតិបត្តិការសម្រាប់ Kubernetes

សូមមើលដ្យាក្រាមខាងក្រោម។ វាបង្ហាញ Git និងឃ្លាំងរូបភាពកុងតឺន័រជាធនធានចែករំលែកសម្រាប់វដ្តជីវិតដែលបានរៀបចំពីរ៖

• បំពង់រួមបញ្ចូលគ្នាជាបន្តបន្ទាប់ដែលអាន និងសរសេរឯកសារទៅ Git និងអាចធ្វើបច្ចុប្បន្នភាពឃ្លាំងរូបភាពកុងតឺន័រ។
• បំពង់បង្ហូរ Runtime GitOps ដែលរួមបញ្ចូលគ្នានូវការដាក់ពង្រាយជាមួយនឹងការគ្រប់គ្រង និងការសង្កេត។ វាអាន និងសរសេរឯកសារទៅ Git ហើយអាចទាញយករូបភាពកុងតឺន័រ។

តើការរកឃើញសំខាន់ៗមានអ្វីខ្លះ?

1. ការបែងចែកកង្វល់៖ សូមចំណាំថា បំពង់ទាំងពីរអាចទំនាក់ទំនងបានតែតាមរយៈការអាប់ដេត Git ឬឃ្លាំងរូបភាពប៉ុណ្ណោះ។ នៅក្នុងពាក្យផ្សេងទៀត មានជញ្ជាំងភ្លើងរវាង CI និងបរិយាកាសពេលដំណើរការ។ យើងហៅវាថា "ជញ្ជាំងភ្លើងដែលមិនអាចផ្លាស់ប្តូរបាន" ។ (ជញ្ជាំងភ្លើងដែលមិនអាចផ្លាស់ប្តូរបាន)ចាប់តាំងពីការធ្វើបច្ចុប្បន្នភាពឃ្លាំងទាំងអស់បង្កើតកំណែថ្មី។ សម្រាប់ព័ត៌មានបន្ថែមអំពីប្រធានបទនេះ សូមមើលស្លាយ 72-87 បទបង្ហាញនេះ។.
2. អ្នកអាចប្រើម៉ាស៊ីនមេ CI និង Git ណាមួយ។៖ GitOps ដំណើរការជាមួយសមាសធាតុណាមួយ។ អ្នកអាចបន្តប្រើម៉ាស៊ីនមេ CI និង Git ដែលអ្នកពេញចិត្ត ឃ្លាំងរូបភាព និងឈុតសាកល្បង។ ស្ទើរតែគ្រប់ឧបករណ៍ចែកចាយបន្តផ្សេងទៀតនៅលើទីផ្សារទាមទារម៉ាស៊ីនមេ CI/Git ផ្ទាល់ខ្លួន ឬឃ្លាំងរូបភាព។ នេះអាចក្លាយជាកត្តាកំណត់ក្នុងការអភិវឌ្ឍន៍ cloud ដើម។ ជាមួយ GitOps អ្នកអាចប្រើឧបករណ៍ដែលធ្លាប់ស្គាល់។
3. ព្រឹត្តិការណ៍ជាឧបករណ៍រួមបញ្ចូល៖ ដរាបណាទិន្នន័យនៅក្នុង Git ត្រូវបានធ្វើបច្ចុប្បន្នភាព Weave Flux (ឬប្រតិបត្តិករ Weave Cloud) ជូនដំណឹងដល់ពេលដំណើរការ។ នៅពេលណាដែល Kubernetes ទទួលយកសំណុំការផ្លាស់ប្តូរ Git ត្រូវបានធ្វើបច្ចុប្បន្នភាព។ នេះផ្តល់នូវគំរូនៃការរួមបញ្ចូលដ៏សាមញ្ញមួយសម្រាប់រៀបចំលំហូរការងារសម្រាប់ GitOps ដូចដែលបានបង្ហាញខាងក្រោម។

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

GitOps ផ្តល់នូវការធានាការធ្វើបច្ចុប្បន្នភាពដ៏រឹងមាំដែលទាមទារដោយឧបករណ៍ CI/CD ទំនើបណាមួយ៖

• ស្វ័យប្រវត្តិកម្ម;
• ការបញ្ចូលគ្នា;
• អសមត្ថភាព;
• ការកំណត់។

នេះមានសារៈសំខាន់ព្រោះវាផ្តល់នូវគំរូប្រតិបត្តិការសម្រាប់អ្នកអភិវឌ្ឍន៍មូលដ្ឋានលើពពក។

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

ស្រមៃមើលក្រុមជាច្រើនដែលនៅរាយប៉ាយលើពពកផ្សេងៗគ្នា និងសេវាកម្មជាច្រើនជាមួយនឹងក្រុមផ្ទាល់ខ្លួនរបស់ពួកគេ និងផែនការដាក់ឱ្យប្រើប្រាស់។ GitOps ផ្តល់ជូននូវគំរូខ្នាត-មិនផ្លាស់ប្តូរសម្រាប់គ្រប់គ្រងភាពសម្បូរបែបនេះ។

PS ពីអ្នកបកប្រែ

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

• «GitOps៖ ការប្រៀបធៀបវិធីសាស្ត្រទាញ និងរុញ»
• «ការណែនាំបណ្ណាល័យ kubedog សម្រាប់ត្រួតពិនិត្យធនធាន Kubernetes»
• «ការពង្រីក និងបន្ថែម Kubernetes (របាយការណ៍ទូទៅ និងវីដេអូ)"។

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើអ្នកដឹងអំពី GitOps មុនពេលការបកប្រែទាំងពីរនេះលេចឡើងនៅលើ Habre?

• បាទ ខ្ញុំដឹងអ្វីៗទាំងអស់។

• គ្រាន់​តែ​មើល​ស្រាល​ប៉ុណ្ណោះ។

• គ្មាន

អ្នកប្រើប្រាស់ 35 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ១៤ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com