ការណែនាំអំពី GitOps សម្រាប់ OpenShift

ថ្ងៃនេះយើងនឹងនិយាយអំពីគោលការណ៍ និងគំរូនៃ GitOps ក៏ដូចជារបៀបដែលគំរូទាំងនេះត្រូវបានអនុវត្តនៅលើវេទិកា OpenShift ។ មានការណែនាំអន្តរកម្មលើប្រធានបទនេះ តំណភ្ជាប់.

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

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

មិនមាននិយមន័យសិក្សា ឬច្បាប់ដែលបានអនុម័តសម្រាប់ GitOps ទេ មានតែសំណុំនៃគោលការណ៍ដែលការអនុវត្តនេះត្រូវបានបង្កើតឡើង៖

• ការពិពណ៌នាអំពីប្រព័ន្ធត្រូវបានរក្សាទុកនៅក្នុងឃ្លាំង Git (ការកំណត់ ការត្រួតពិនិត្យ។ល។)។
• ការផ្លាស់ប្តូររដ្ឋត្រូវបានធ្វើឡើងតាមរយៈសំណើទាញ។
• ស្ថានភាពនៃប្រព័ន្ធដែលកំពុងដំណើរការត្រូវបាននាំមកស្របជាមួយនឹងទិន្នន័យនៅក្នុងឃ្លាំងដោយប្រើសំណើរជំរុញ Git ។

គោលការណ៍ GitOps

• និយមន័យប្រព័ន្ធត្រូវបានពិពណ៌នាថាជាកូដប្រភព

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

• ស្ថានភាពដែលចង់បាន និងការកំណត់រចនាសម្ព័ន្ធនៃប្រព័ន្ធត្រូវបានកំណត់ និងកំណែនៅក្នុង Git

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

• ការផ្លាស់ប្តូរការកំណត់អាចត្រូវបានអនុវត្តដោយស្វ័យប្រវត្តិតាមរយៈសំណើទាញ

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

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

• ដោះស្រាយបញ្ហានៃការកំណត់រចនាសម្ព័ន្ធដែលមិនមានការគ្រប់គ្រង

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

ម៉ូដែល GitOps សម្រាប់ OpenShift

On-Cluster Resource Reconcir

យោងតាមគំរូនេះ ចង្កោមមានឧបករណ៍បញ្ជាដែលទទួលខុសត្រូវក្នុងការប្រៀបធៀបធនធាន Kubernetes (ឯកសារ YAML) នៅក្នុងឃ្លាំង Git ជាមួយនឹងធនធានពិតនៃចង្កោម។ ប្រសិនបើភាពមិនស្របគ្នាត្រូវបានរកឃើញ ឧបករណ៍បញ្ជានឹងផ្ញើការជូនដំណឹង ហើយអាចចាត់វិធានការដើម្បីកែតម្រូវភាពមិនស្របគ្នា។ គំរូ GitOps នេះត្រូវបានប្រើនៅក្នុងការគ្រប់គ្រង Anthos Config និង Weaveworks Flux ។

អ្នកសម្រុះសម្រួលធនធានខាងក្រៅ (ជំរុញ)

គំរូនេះអាចចាត់ទុកថាជាបំរែបំរួលនៃកំណែមុន នៅពេលដែលយើងមានឧបករណ៍បញ្ជាមួយ ឬច្រើនដែលទទួលខុសត្រូវក្នុងការធ្វើសមកាលកម្មធនធាននៅក្នុងគូ "ឃ្លាំង Git - Kubernetes cluster" ។ ភាពខុសគ្នានៅទីនេះគឺថាចង្កោមដែលបានគ្រប់គ្រងនីមួយៗមិនចាំបាច់មានឧបករណ៍បញ្ជាដាច់ដោយឡែករបស់វានោះទេ។ គូចង្កោម Git - k8s ត្រូវបានកំណត់ជាញឹកញាប់ថាជា CRDs (និយមន័យធនធានផ្ទាល់ខ្លួន) ដែលអាចពណ៌នាអំពីរបៀបដែលឧបករណ៍បញ្ជាគួរធ្វើសមកាលកម្ម។ នៅក្នុងគំរូនេះ ឧបករណ៍បញ្ជាប្រៀបធៀបឃ្លាំង Git ដែលបានបញ្ជាក់នៅក្នុង CRD ជាមួយនឹងធនធាននៃចង្កោម Kubernetes ដែលត្រូវបានបញ្ជាក់ផងដែរនៅក្នុង CRD ហើយអនុវត្តសកម្មភាពសមស្របដោយផ្អែកលើលទ្ធផលនៃការប្រៀបធៀប។ ជាពិសេសម៉ូដែល GitOps នេះត្រូវបានប្រើនៅក្នុង ArgoCD ។

GitOps នៅលើវេទិកា OpenShift

ការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ Kubernetes ពហុចង្កោម

ជាមួយនឹងការរីករាលដាលនៃ Kubernetes និងការកើនឡើងនូវប្រជាប្រិយភាពនៃយុទ្ធសាស្ត្រពហុពពក និងការគណនាគែម ចំនួនមធ្យមនៃក្រុម OpenShift សម្រាប់អតិថិជនម្នាក់ៗក៏កំពុងកើនឡើងផងដែរ។

ជាឧទាហរណ៍ នៅពេលប្រើ Edge Computing ចង្កោមរបស់អតិថិជនម្នាក់អាចត្រូវបានដាក់ពង្រាយរាប់រយ ឬរាប់ពាន់។ ជាលទ្ធផល គាត់ត្រូវបានបង្ខំឱ្យគ្រប់គ្រងក្រុម OpenShift ឯករាជ្យ ឬសម្របសម្រួលមួយចំនួននៅក្នុងពពកសាធារណៈ និងនៅក្នុងបរិវេណ។

ក្នុងករណីនេះ បញ្ហាជាច្រើនត្រូវដោះស្រាយ ជាពិសេស៖

• គ្រប់គ្រងថាចង្កោមស្ថិតនៅក្នុងស្ថានភាពដូចគ្នា (ការកំណត់ ការត្រួតពិនិត្យ ការផ្ទុក។ល។)
• បង្កើតឡើងវិញ (ឬស្ដារ) ចង្កោមដោយផ្អែកលើស្ថានភាពដែលគេស្គាល់។
• បង្កើតចង្កោមថ្មីដោយផ្អែកលើរដ្ឋដែលគេស្គាល់។
• ចាប់ផ្តើមការផ្លាស់ប្តូរទៅក្រុម OpenShift ច្រើន។
• ត្រឡប់​ការ​ផ្លាស់​ប្តូ​រ​នៅ​ទូទាំង​ក្រុម OpenShift ច្រើន​។
• ភ្ជាប់​ការ​កំណត់​រចនាសម្ព័ន្ធ​គំរូ​ទៅ​បរិយាកាស​ផ្សេង​គ្នា។

ការកំណត់រចនាសម្ព័ន្ធកម្មវិធី

ក្នុងអំឡុងពេលវដ្តជីវិតរបស់ពួកគេ កម្មវិធីតែងតែឆ្លងកាត់ខ្សែសង្វាក់នៃចង្កោម (dev, stage ។ល។) មុនពេលបញ្ចប់នៅក្នុងចង្កោមផលិតកម្ម។ លើសពីនេះ ដោយសារតែភាពអាចរកបាន និងតម្រូវការនៃការធ្វើមាត្រដ្ឋាន អតិថិជនតែងតែដាក់ឱ្យប្រើប្រាស់កម្មវិធីនៅទូទាំងចង្កោមក្នុងបរិវេណ ឬតំបន់ជាច្រើននៃវេទិកាពពកសាធារណៈ។

ក្នុងករណីនេះ កិច្ចការខាងក្រោមត្រូវដោះស្រាយ៖

• ធានាឱ្យមានចលនានៃកម្មវិធី (ប្រព័ន្ធគោលពីរ ការកំណត់រចនាសម្ព័ន្ធ។ល។) រវាងចង្កោម (dev, ដំណាក់កាល។ល។)។
• ចាប់ផ្តើមការផ្លាស់ប្តូរទៅកម្មវិធី (ប្រព័ន្ធគោលពីរ ការកំណត់រចនាសម្ព័ន្ធ។ល។) នៅក្នុងក្រុម OpenShift ជាច្រើន។
• ត្រឡប់​ការ​ផ្លាស់​ប្តូ​រ​កម្មវិធី​ទៅ​ស្ថានភាព​ដែល​បាន​ស្គាល់​ពី​មុន​។

OpenShift GitOps ប្រើករណី

1. អនុវត្តការផ្លាស់ប្តូរពីឃ្លាំង Git

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

2. ការធ្វើសមកាលកម្មជាមួយអ្នកគ្រប់គ្រងសម្ងាត់

អ្នកគ្រប់គ្រងក៏នឹងទទួលបានអត្ថប្រយោជន៍ផងដែរពីសមត្ថភាពក្នុងការធ្វើសមកាលកម្មវត្ថុសម្ងាត់ OpenShift ជាមួយនឹងកម្មវិធីសមស្របដូចជា Vault ដើម្បីគ្រប់គ្រងពួកវាដោយប្រើឧបករណ៍ដែលបានបង្កើតជាពិសេសសម្រាប់រឿងនេះ។

3. ការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធរសាត់

អ្នកគ្រប់គ្រងនឹងពេញចិត្ត លុះត្រាតែ OpenShift GitOps ខ្លួនវាកំណត់អត្តសញ្ញាណ និងព្រមានអំពីភាពមិនស្របគ្នារវាងការកំណត់រចនាសម្ព័ន្ធពិត និងអ្វីដែលបានបញ្ជាក់នៅក្នុងឃ្លាំង ដូច្នេះពួកគេអាចឆ្លើយតបយ៉ាងរហ័សចំពោះការរសាត់។

4. ការជូនដំណឹងអំពីការរសាត់នៃការកំណត់រចនាសម្ព័ន្ធ

ពួកវាមានប្រយោជន៍ក្នុងករណីដែលអ្នកគ្រប់គ្រងចង់រៀនយ៉ាងឆាប់រហ័សអំពីករណីនៃការកំណត់រចនាសម្ព័ន្ធរសាត់ ដើម្បីចាត់វិធានការសមស្របយ៉ាងឆាប់រហ័សដោយខ្លួនឯង។

5. ការធ្វើសមកាលកម្មដោយដៃនៃការកំណត់រចនាសម្ព័ន្ធនៅពេលរសាត់

អនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងធ្វើសមកាលកម្មចង្កោម OpenShift ជាមួយឃ្លាំង Git នៅក្នុងព្រឹត្តិការណ៍នៃការកំណត់រចនាសម្ព័ន្ធរសាត់ ដើម្បីត្រឡប់ចង្កោមទៅស្ថានភាពដែលបានស្គាល់ពីមុនយ៉ាងឆាប់រហ័ស។

6. ការធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិនៃការកំណត់រចនាសម្ព័ន្ធនៅពេលរសាត់

អ្នកគ្រប់គ្រងក៏អាចកំណត់រចនាសម្ព័ន្ធ OpenShift cluster ដើម្បីធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិជាមួយនឹងឃ្លាំង នៅពេលដែលការរសាត់ត្រូវបានរកឃើញ ដូច្នេះការកំណត់រចនាសម្ព័ន្ធចង្កោមតែងតែត្រូវគ្នានឹងការកំណត់នៅក្នុង Git ។

7. ចង្កោមជាច្រើន - ឃ្លាំងមួយ។

អ្នកគ្រប់គ្រងអាចរក្សាទុកការកំណត់រចនាសម្ព័ន្ធនៃក្រុម OpenShift ផ្សេងៗគ្នាជាច្រើននៅក្នុងឃ្លាំង Git ហើយជ្រើសរើសពួកវាតាមតម្រូវការ។

8. ឋានានុក្រមនៃការកំណត់រចនាសម្ព័ន្ធចង្កោម (មរតក)

អ្នកគ្រប់គ្រងអាចកំណត់ឋានានុក្រមនៃការកំណត់រចនាសម្ព័ន្ធចង្កោមនៅក្នុងឃ្លាំង (ដំណាក់កាល ផលិតផល ផលប័ត្រកម្មវិធី។ ម្យ៉ាងវិញទៀត វាអាចកំណត់ថាតើការកំណត់រចនាសម្ព័ន្ធគួរតែត្រូវបានអនុវត្តចំពោះចង្កោមមួយ ឬច្រើន។

ឧទាហរណ៍ ប្រសិនបើអ្នកគ្រប់គ្រងកំណត់ឋានានុក្រម “ចង្កោមផលិតកម្ម (ផលិតផល) → ចង្កោមប្រព័ន្ធ X → ចង្កោមផលិតកម្មនៃប្រព័ន្ធ X” នៅក្នុងឃ្លាំង Git នោះការរួមបញ្ចូលគ្នានៃការកំណត់ខាងក្រោមត្រូវបានអនុវត្តចំពោះចង្កោមផលិតកម្មនៃប្រព័ន្ធ X៖

• កំណត់រចនាសម្ព័ន្ធទូទៅចំពោះក្រុមផលិតកម្មទាំងអស់។
• កំណត់រចនាសម្ព័ន្ធសម្រាប់ចង្កោម System X ។
• កំណត់រចនាសម្ព័ន្ធសម្រាប់ចង្កោមផលិតកម្មប្រព័ន្ធ X ។

9. ត្រួតលើគំរូ និងការកំណត់រចនាសម្ព័ន្ធ

ជាឧទាហរណ៍ អ្នកគ្រប់គ្រងអាចបដិសេធសំណុំនៃការកំណត់រចនាសម្ព័ន្ធដែលបានទទួលមរតក និងតម្លៃរបស់ពួកគេ ឧទាហរណ៍ ដើម្បីកែសម្រួលការកំណត់រចនាសម្ព័ន្ធសម្រាប់ចង្កោមជាក់លាក់ដែលពួកគេនឹងត្រូវបានអនុវត្ត។

10. ជ្រើសរើសរួមបញ្ចូល និងមិនរាប់បញ្ចូលសម្រាប់ការកំណត់រចនាសម្ព័ន្ធ ការកំណត់រចនាសម្ព័ន្ធកម្មវិធី

អ្នក​គ្រប់គ្រង​អាច​កំណត់​លក្ខខណ្ឌ​សម្រាប់​កម្មវិធី ឬ​ការ​មិន​អនុវត្ត​នៃ​ការ​កំណត់​រចនាសម្ព័ន្ធ​ជាក់លាក់​ចំពោះ​ចង្កោម​ដែល​មាន​លក្ខណៈ​ជាក់លាក់។

11. ការគាំទ្រគំរូ

អ្នកអភិវឌ្ឍន៍នឹងទទួលបានអត្ថប្រយោជន៍ពីសមត្ថភាពក្នុងការជ្រើសរើសរបៀបដែលធនធានកម្មវិធីនឹងត្រូវបានកំណត់ (Helm Chart, pure Kubernetes yaml ។ល។) ដើម្បីប្រើទម្រង់សមស្របបំផុតសម្រាប់កម្មវិធីជាក់លាក់នីមួយៗ។

ឧបករណ៍ GitOps នៅលើវេទិកា OpenShift

ArgoCD

ArgoCD អនុវត្តគំរូការផ្សះផ្សាធនធានខាងក្រៅ និងផ្តល់នូវ UI កណ្តាលសម្រាប់រៀបចំទំនាក់ទំនងមួយទល់នឹងច្រើនរវាងចង្កោម និងឃ្លាំង Git ។ គុណវិបត្តិនៃកម្មវិធីនេះរួមមានអសមត្ថភាពក្នុងការគ្រប់គ្រងកម្មវិធីនៅពេលដែល ArgoCD មិនដំណើរការ។

វេបសាយផ្លូវការ

ហូរ

Flux អនុវត្តគំរូ On-Cluster Resource Reconcile ហើយជាលទ្ធផល មិនមានការគ្រប់គ្រងកណ្តាលនៃឃ្លាំងនិយមន័យ ដែលជាចំណុចខ្សោយនោះទេ។ ម៉្យាងវិញទៀត ច្បាស់ណាស់ដោយសារតែខ្វះការបង្រួបបង្រួម សមត្ថភាពក្នុងការគ្រប់គ្រងកម្មវិធីនៅតែមាន ទោះបីជាចង្កោមមួយបរាជ័យក៏ដោយ។

វេបសាយផ្លូវការ

ការដំឡើង ArgoCD នៅលើ OpenShift

ArgoCD ផ្តល់នូវចំណុចប្រទាក់បន្ទាត់ពាក្យបញ្ជាដ៏ល្អឥតខ្ចោះ និងកុងសូលបណ្តាញ ដូច្នេះយើងនឹងមិនគ្របដណ្តប់ Flux និងជម្រើសផ្សេងទៀតនៅទីនេះទេ។

ដើម្បីដាក់ពង្រាយ ArgoCD នៅលើវេទិកា OpenShift 4 សូមអនុវត្តតាមជំហានទាំងនេះជាអ្នកគ្រប់គ្រងចង្កោម៖

ការដាក់ពង្រាយសមាសធាតុ ArgoCD នៅលើវេទិកា OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

ការកែលម្អម៉ាស៊ីនមេ ArgoCD ដើម្បីឱ្យវាអាចមើលឃើញដោយ OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

ការដាក់ពង្រាយឧបករណ៍ ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

ការផ្លាស់ប្តូរពាក្យសម្ងាត់អ្នកគ្រប់គ្រងម៉ាស៊ីនមេ ArgoCD

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

បន្ទាប់ពីបញ្ចប់ជំហានទាំងនេះ អ្នកអាចធ្វើការជាមួយម៉ាស៊ីនមេ ArgoCD តាមរយៈកុងសូលបណ្តាញ ArgoCD WebUI ឬឧបករណ៍បន្ទាត់ពាក្យបញ្ជា ArgoCD Cli ។
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - វាមិនដែលយឺតពេលទេ។

"រថភ្លើងបានចាកចេញ" - នេះគឺជាអ្វីដែលពួកគេនិយាយអំពីស្ថានភាពនៅពេលដែលឱកាសដើម្បីធ្វើអ្វីមួយត្រូវបានខកខាន។ ក្នុងករណី OpenShift បំណងប្រាថ្នាដើម្បីចាប់ផ្តើមភ្លាមៗដោយប្រើវេទិកាថ្មីដ៏ត្រជាក់នេះជារឿយៗបង្កើតស្ថានភាពនេះយ៉ាងពិតប្រាកដជាមួយនឹងការគ្រប់គ្រង និងថែទាំផ្លូវ ការដាក់ពង្រាយ និងវត្ថុ OpenShift ផ្សេងទៀត។ ប៉ុន្តែតើឱកាសតែងតែខកខានទាំងស្រុងទេ?

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

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

ដូច្នេះយើងមានកម្មវិធីធ្វើដោយដៃ។ ឥឡូវនេះវាត្រូវការផ្ទេរនៅក្រោមការគ្រប់គ្រង GitOps ដោយមិនបាត់បង់ភាពអាចរកបាន។ និយាយឱ្យខ្លីវាធ្វើដូចនេះ៖

• បង្កើតឃ្លាំង Git សម្រាប់កូដ។
• យើងនាំចេញវត្ថុបច្ចុប្បន្នរបស់យើង ហើយបង្ហោះវាទៅឃ្លាំង Git ។
• ការជ្រើសរើស និងប្រើប្រាស់ឧបករណ៍ GitOps ។
• យើងបន្ថែមឃ្លាំងរបស់យើងទៅប្រអប់ឧបករណ៍នេះ។
• យើងកំណត់កម្មវិធីនៅក្នុងប្រអប់ឧបករណ៍ GitOps របស់យើង។
• យើងអនុវត្តការសាកល្បងនៃកម្មវិធីដោយប្រើប្រអប់ឧបករណ៍ GitOps ។
• យើងធ្វើសមកាលកម្មវត្ថុដោយប្រើប្រអប់ឧបករណ៍ GitOps ។
• បើកដំណើរការកាត់ចេញ និងធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិនៃវត្ថុ។

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

ក្នុងឧទាហរណ៍របស់យើង យើងនឹងបង្កើតឃ្លាំងសាធារណៈថ្មីមួយនៅលើ GitHub ។ អ្នក​អាច​ហៅ​វា​តាម​អ្វី​ដែល​អ្នក​ចូលចិត្ត យើង​ប្រើ​ឈ្មោះ blogpost ។

ប្រសិនបើឯកសារវត្ថុ YAML មិនត្រូវបានរក្សាទុកក្នុងមូលដ្ឋាន ឬនៅក្នុង Git នោះអ្នកនឹងត្រូវប្រើប្រព័ន្ធគោលពីរ oc ឬ kubectl ។ នៅក្នុងរូបថតអេក្រង់ខាងក្រោម យើងកំពុងស្នើសុំ YAML សម្រាប់ទំហំឈ្មោះ ការដាក់ឱ្យប្រើប្រាស់ សេវាកម្ម និងផ្លូវរបស់យើង។ មុននេះ យើងបានក្លូនឃ្លាំងដែលបានបង្កើតថ្មី និងស៊ីឌីទៅក្នុងវា។

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

ឥឡូវនេះសូមកែសម្រួលឯកសារ deployment.yaml ដើម្បីលុបវាលដែល Argo CD មិនអាចធ្វើសមកាលកម្មបានទេ។

sed -i '/sgeneration: .*/d' deployment.yaml

លើសពីនេះទៀតផ្លូវត្រូវផ្លាស់ប្តូរ។ ដំបូង​យើង​នឹង​កំណត់​អថេរ​ច្រើន​ជួរ ហើយ​បន្ទាប់​មក​ជំនួស ingress: null ជាមួយ​នឹង​មាតិកា​នៃ​អថេរ​នោះ។

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

ដូច្នេះ យើង​បាន​តម្រៀប​ចេញ​ឯកសារ​ដែល​នៅ​សល់​គឺ​ត្រូវ​រក្សា​ទុក​វា​ទៅ​ក្នុង​ឃ្លាំង Git ។ បន្ទាប់ពីនោះឃ្លាំងនេះក្លាយជាប្រភពតែមួយគត់នៃព័ត៌មាន ហើយរាល់ការផ្លាស់ប្តូរដោយដៃចំពោះវត្ថុគួរតែត្រូវបានហាមឃាត់យ៉ាងតឹងរ៉ឹង។

git commit -am ‘initial commit of objects’
git push origin master

លើសពីនេះទៀតយើងបន្តពីការពិតដែលថាអ្នកបានដាក់ពង្រាយ ArgoCD រួចហើយ (របៀបធ្វើវា - សូមមើលមុន។ ប្រកាស) ដូច្នេះ យើង​នឹង​បន្ថែម​ទៅ​ក្នុង Argo CD នូវ​ឃ្លាំង​ដែល​យើង​បាន​បង្កើត​ដោយ​មាន​កូដ​កម្មវិធី​ពី​ឧទាហរណ៍​របស់​យើង។ គ្រាន់តែត្រូវប្រាកដថាអ្នកបញ្ជាក់ឃ្លាំងពិតប្រាកដដែលអ្នកបានបង្កើតមុន។

argocd repo add https://github.com/cooktheryan/blogpost

ឥឡូវនេះយើងបង្កើតកម្មវិធី។ កម្មវិធីកំណត់តម្លៃដើម្បីឱ្យប្រអប់ឧបករណ៍ GitOps យល់ពីឃ្លាំង និងផ្លូវដែលត្រូវប្រើ ដែល OpenShift ត្រូវការដើម្បីគ្រប់គ្រងវត្ថុ សាខាជាក់លាក់ណាមួយនៃឃ្លាំងដែលត្រូវការ និងថាតើធនធានគួរធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិដែរឬទេ។

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

នៅពេលដែលកម្មវិធីមួយត្រូវបានបញ្ជាក់នៅក្នុង Argo CD នោះ ប្រអប់ឧបករណ៍ចាប់ផ្តើមពិនិត្យមើលវត្ថុដែលបានដាក់ពង្រាយរួចហើយប្រឆាំងនឹងនិយមន័យនៅក្នុងឃ្លាំង។ ក្នុងឧទាហរណ៍របស់យើង ការធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិ និងការសម្អាតត្រូវបានបិទ ដូច្នេះធាតុមិនផ្លាស់ប្តូរនៅឡើយទេ។ សូមចំណាំថានៅក្នុងចំណុចប្រទាក់ Argo CD កម្មវិធីរបស់យើងនឹងមានស្ថានភាព "Out of Sync" ពីព្រោះមិនមានស្លាកសញ្ញាដែល ArgoCD ផ្តល់ឱ្យនោះទេ។
នេះ​ជា​មូលហេតុ​ដែល​នៅ​ពេល​ដែល​យើង​ចាប់​ផ្ដើម​ធ្វើ​សមកាលកម្ម​បន្តិច​ក្រោយ​មក វត្ថុ​នឹង​មិន​ត្រូវ​បាន​ដាក់​ឱ្យ​ប្រើ​ឡើងវិញ​ទេ។

ឥឡូវនេះ ចូរយើងធ្វើការសាកល្បង ដើម្បីប្រាកដថាមិនមានកំហុសនៅក្នុងឯកសាររបស់យើង។

argocd app sync simple-app --dry-run

ប្រសិនបើមិនមានកំហុសទេនោះ អ្នកអាចបន្តធ្វើសមកាលកម្ម។

argocd app sync simple-app

បន្ទាប់ពីដំណើរការ argocd get command នៅលើកម្មវិធីរបស់យើង យើងគួរតែឃើញថាស្ថានភាពកម្មវិធីបានផ្លាស់ប្តូរទៅជា Healthy ឬ Synced។ នេះនឹងមានន័យថាធនធានទាំងអស់នៅក្នុងឃ្លាំង Git ឥឡូវនេះត្រូវគ្នាទៅនឹងធនធានទាំងនោះដែលត្រូវបានដាក់ពង្រាយរួចហើយ។

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

ឥឡូវនេះ អ្នកអាចបើកការធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិ និងការសម្អាត ដើម្បីធានាថាគ្មានអ្វីត្រូវបានបង្កើតដោយដៃ ហើយថារាល់ពេលដែលវត្ថុត្រូវបានបង្កើត ឬធ្វើបច្ចុប្បន្នភាពទៅកន្លែងផ្ទុក ការដាក់ពង្រាយនឹងកើតឡើង។

argocd app set simple-app --sync-policy automated --auto-prune

ដូច្នេះ យើងបាននាំយកកម្មវិធីដោយជោគជ័យមួយនៅក្រោមការគ្រប់គ្រង GitOps ដែលដំបូងឡើយមិនប្រើ GitOps តាមរបៀបណាមួយឡើយ។

ប្រភព: www.habr.com