🥇សេចក្តីណែនាំអំពីមួកសុវត្ថិភាព 3

ចំណាំ។ បកប្រែ៖ ថ្ងៃទី 16 ខែឧសភា ឆ្នាំនេះ គឺជាព្រឹត្តិការណ៍ដ៏សំខាន់មួយក្នុងការអភិវឌ្ឍន៍កម្មវិធីគ្រប់គ្រងកញ្ចប់សម្រាប់ Kubernetes - Helm ។ នៅថ្ងៃនេះ ការចេញផ្សាយអាល់ហ្វាដំបូងនៃកំណែសំខាន់នាពេលអនាគតនៃគម្រោង - 3.0 - ត្រូវបានបង្ហាញ។ ការចេញផ្សាយរបស់វានឹងនាំមកនូវការផ្លាស់ប្តូរដ៏សំខាន់ និងរង់ចាំជាយូរមកហើយចំពោះ Helm ដែលមនុស្សជាច្រើននៅក្នុងសហគមន៍ Kubernetes មានក្តីសង្ឃឹមខ្ពស់។ ខ្លួនយើងជាមនុស្សម្នាក់ក្នុងចំណោមអ្នកទាំងនេះ ដោយសារយើងប្រើ Helm យ៉ាងសកម្មសម្រាប់ការដាក់ឱ្យប្រើប្រាស់កម្មវិធី៖ យើងបានបញ្ចូលវាទៅក្នុងឧបករណ៍របស់យើងសម្រាប់ការអនុវត្ត CI/CD werf ហើយពីពេលមួយទៅពេលមួយ យើងធ្វើការរួមចំណែករបស់យើងក្នុងការអភិវឌ្ឍន៍ទឹកទន្លេ។ ការបកប្រែនេះរួមបញ្ចូលគ្នានូវកំណត់ចំណាំចំនួន 7 ពីប្លុកផ្លូវការរបស់ Helm ដែលត្រូវបានឧទ្ទិសដល់ការចេញផ្សាយអាល់ហ្វាដំបូងនៃ Helm 3 ហើយនិយាយអំពីប្រវត្តិនៃគម្រោង និងលក្ខណៈពិសេសសំខាន់ៗរបស់ Helm 3។ អ្នកនិពន្ធរបស់ពួកគេគឺ Matt “bacongobbler” Fisher ដែលជាបុគ្គលិករបស់ Microsoft និងអ្នកថែរក្សាដ៏សំខាន់ម្នាក់របស់ Helm ។

នៅថ្ងៃទី 15 ខែតុលា ឆ្នាំ 2015 គម្រោងដែលត្រូវបានគេស្គាល់ថាជា Helm បានកើត។ គ្រាន់តែមួយឆ្នាំបន្ទាប់ពីការបង្កើតរបស់ខ្លួន សហគមន៍ Helm បានចូលរួមជាមួយ Kubernetes ខណៈពេលដែលកំពុងធ្វើការយ៉ាងសកម្មនៅលើ Helm 2 ។ នៅខែមិថុនា ឆ្នាំ 2018 Helm បានចូលរួមជាមួយ CNCF ជាគម្រោងអភិវឌ្ឍន៍ (បង្កើត) ។ ឆ្ពោះទៅមុខយ៉ាងលឿនទៅបច្ចុប្បន្ន ហើយការចេញផ្សាយអាល់ហ្វាដំបូងនៃ Helm 3 ថ្មីកំពុងដំណើរការហើយ។ (ការចេញផ្សាយនេះ។ បានកើតឡើងរួចហើយ នៅពាក់កណ្តាលខែឧសភា - ប្រហែល។ បកប្រែ។ ).

នៅក្នុងបំណែកនេះ ខ្ញុំនឹងនិយាយអំពីកន្លែងដែលវាបានចាប់ផ្តើម របៀបដែលយើងបានទៅដល់កន្លែងដែលយើងនៅសព្វថ្ងៃនេះ ណែនាំលក្ខណៈពិសេសមួយចំនួនដែលមាននៅក្នុងការចេញផ្សាយអាល់ហ្វាដំបូងនៃ Helm 3 និងពន្យល់ពីរបៀបដែលយើងគ្រោងឆ្ពោះទៅមុខ។

សង្ខេប៖

ប្រវត្តិសាស្រ្តនៃការបង្កើត Helm;
ការលាគ្នាដ៏ទន់ភ្លន់ទៅកាន់ Tiller;
ឃ្លាំងគំនូសតាង;
ការគ្រប់គ្រងការចេញផ្សាយ;
ការផ្លាស់ប្តូរភាពអាស្រ័យគំនូសតាង;
តារាងបណ្ណាល័យ;
មានអ្វីបន្ទាប់?

ប្រវត្តិសាស្រ្តរបស់ Helm

កំណើត

Helm 1 បានចាប់ផ្តើមជាគម្រោង Open Source ដែលបង្កើតឡើងដោយ Deis ។ យើងជាការចាប់ផ្តើមតូចមួយ ស្រូប ក្រុមហ៊ុន Microsoft នៅនិទាឃរដូវឆ្នាំ 2017 ។ គម្រោងប្រភពបើកចំហផ្សេងទៀតរបស់យើងដែលមានឈ្មោះថា Deis មានឧបករណ៍មួយ។ deisctlដែលត្រូវបានប្រើ (ក្នុងចំណោមរបស់ផ្សេងទៀត) ដើម្បីដំឡើង និងដំណើរការវេទិកា Deis នៅក្នុង ចង្កោមកងនាវា. នៅពេលនោះ Fleet គឺជាវេទិការវង់តន្រ្តីដំបូងបង្អស់មួយ។

នៅពាក់កណ្តាលឆ្នាំ 2015 យើងបានសម្រេចចិត្តផ្លាស់ប្តូរវគ្គសិក្សា ហើយបានផ្លាស់ប្តូរ Deis (នៅពេលនោះប្តូរឈ្មោះជា Deis Workflow) ពី Fleet ទៅ Kubernetes ។ មួយក្នុងចំណោមដំបូងគេដែលត្រូវបានរចនាឡើងវិញគឺឧបករណ៍ដំឡើង។ deisctl. យើងបានប្រើវាដើម្បីដំឡើង និងគ្រប់គ្រង Deis Workflow នៅក្នុងក្រុម Fleet ។

Helm 1 ត្រូវបានបង្កើតឡើងក្នុងរូបភាពរបស់អ្នកគ្រប់គ្រងកញ្ចប់ដ៏ល្បីល្បាញដូចជា Homebrew, apt និង yum ។ គោលដៅចម្បងរបស់វាគឺដើម្បីសម្រួលកិច្ចការដូចជាការវេចខ្ចប់ និងការដំឡើងកម្មវិធីនៅលើ Kubernetes ។ Helm ត្រូវបានណែនាំជាផ្លូវការនៅក្នុងឆ្នាំ 2015 នៅក្នុងសន្និសីទ KubeCon នៅ San Francisco។

ការប៉ុនប៉ងលើកដំបូងរបស់យើងជាមួយ Helm បានដំណើរការ ប៉ុន្តែវាមិនមែនដោយគ្មានដែនកំណត់ធ្ងន់ធ្ងរមួយចំនួននោះទេ។ គាត់បានយកឈុតរបស់ Kubernetes manifests ដែលមានរសជាតិជាមួយម៉ាស៊ីនភ្លើងជាប្លុក YAML ណែនាំ (បញ្ហាមុខ)* ហើយបានផ្ទុកលទ្ធផលទៅក្នុង Kubernetes ។

* ចំណាំ។ បកប្រែ៖ ពីកំណែដំបូងនៃ Helm វាក្យសម្ព័ន្ធ YAML ត្រូវបានជ្រើសរើសដើម្បីពិពណ៌នាអំពីធនធាន Kubernetes ហើយគំរូ Jinja និងអក្សរ Python ត្រូវបានគាំទ្រនៅពេលសរសេរការកំណត់រចនាសម្ព័ន្ធ។ យើងបានសរសេរបន្ថែមអំពីរឿងនេះ និងរចនាសម្ព័ន្ធនៃកំណែដំបូងនៃ Helm ជាទូទៅនៅក្នុងជំពូក "A Brief History of Helm" សម្ភារៈនេះ។.

ឧទាហរណ៍ ដើម្បីជំនួសវាលក្នុងឯកសារ YAML អ្នកត្រូវបន្ថែមសំណង់ខាងក្រោមទៅ manifest៖

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

វាអស្ចារ្យណាស់ដែលម៉ាស៊ីនគំរូមានសព្វថ្ងៃនេះ មែនទេ?

សម្រាប់ហេតុផលជាច្រើន កម្មវិធីដំឡើង Kubernetes ដើមដំបូងនេះតម្រូវឱ្យមានបញ្ជី hard-coded នៃឯកសារ manifest ហើយបានដំណើរការតែព្រឹត្តិការណ៍តូចមួយ និងលំដាប់ថេរប៉ុណ្ណោះ។ វាពិតជាលំបាកណាស់ក្នុងការប្រើប្រាស់ដែលក្រុម Deis Workflow R&D មានការលំបាកនៅពេលដែលពួកគេព្យាយាមផ្ទេរផលិតផលរបស់ពួកគេទៅកាន់វេទិកានេះ - ទោះជាយ៉ាងណា គ្រាប់ពូជនៃគំនិតនេះត្រូវបានសាបព្រោះរួចហើយ។ ការប៉ុនប៉ងលើកដំបូងរបស់យើងគឺជាឱកាសសិក្សាដ៏ល្អមួយ៖ យើងបានដឹងថាយើងពិតជាងប់ងល់ក្នុងការបង្កើតឧបករណ៍ជាក់ស្តែងដែលដោះស្រាយបញ្ហាប្រចាំថ្ងៃសម្រាប់អ្នកប្រើប្រាស់របស់យើង។

ដោយផ្អែកលើបទពិសោធន៍នៃកំហុសកន្លងមក យើងបានចាប់ផ្តើមអភិវឌ្ឍ Helm 2 ។

ធ្វើមួក ២

នៅចុងឆ្នាំ 2015 ក្រុមការងារ Google បានទាក់ទងមកយើង។ ពួកគេកំពុងធ្វើការលើឧបករណ៍ស្រដៀងគ្នាសម្រាប់ Kubernetes ។ កម្មវិធីគ្រប់គ្រងការដាក់ឱ្យប្រើប្រាស់សម្រាប់ Kubernetes គឺជាច្រកនៃឧបករណ៍ដែលមានស្រាប់ដែលត្រូវបានប្រើសម្រាប់ Google Cloud Platform ។ ពួកគេបានសួរថា "តើយើងចង់ចំណាយពេលពីរបីថ្ងៃដើម្បីពិភាក្សាអំពីភាពស្រដៀងគ្នា និងភាពខុសគ្នាដែរឬទេ?"

នៅខែមករា ឆ្នាំ 2016 ក្រុម Helm និង Deployment Manager បានជួបគ្នានៅទីក្រុង Seattle ដើម្បីផ្លាស់ប្តូរគំនិត។ ការចរចាបានបញ្ចប់ដោយផែនការមហិច្ឆតាមួយ៖ ដើម្បីបញ្ចូលគ្នានូវគម្រោងទាំងពីរដើម្បីបង្កើត Helm 2។ រួមជាមួយ Deis និង Google បុរសមកពី SkippBox (ឥឡូវជាផ្នែកនៃ Bitnami - ប្រហែលបកប្រែ។ )ហើយយើងបានចាប់ផ្តើមធ្វើការលើ Helm 2 ។

យើងចង់រក្សាភាពងាយស្រួលនៃការប្រើប្រាស់របស់ Helm ប៉ុន្តែបន្ថែមដូចខាងក្រោម៖

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

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

ចាប់តាំងពីការចេញផ្សាយ Helm 2 ក្នុងឆ្នាំ 2016 Kubernetes បានបន្ថែមការច្នៃប្រឌិតសំខាន់ៗមួយចំនួន។ បានបន្ថែមការគ្រប់គ្រងការចូលប្រើដោយផ្អែកលើតួនាទី (RBAC) ដែលនៅទីបំផុតបានជំនួស Attribute-Based Access Control (ABAC)។ ប្រភេទធនធានថ្មីត្រូវបានណែនាំ (ការដាក់ឱ្យប្រើប្រាស់នៅតែស្ថិតក្នុងបេតានៅពេលនោះ)។ និយមន័យធនធានផ្ទាល់ខ្លួន (ពីដើមហៅថា ធនធានភាគីទីបី ឬ TPR) ត្រូវបានបង្កើតឡើង។ ហើយសំខាន់បំផុតនោះ សំណុំនៃការអនុវត្តល្អបំផុតបានលេចចេញមក។

ចំពេលការផ្លាស់ប្តូរទាំងអស់នេះ Helm បានបន្តបម្រើអ្នកប្រើប្រាស់ Kubernetes យ៉ាងស្មោះត្រង់។ បន្ទាប់ពីបីឆ្នាំ និងការបន្ថែមថ្មីជាច្រើន វាច្បាស់ណាស់ថាវាដល់ពេលដែលត្រូវធ្វើការផ្លាស់ប្តូរដ៏សំខាន់ចំពោះមូលដ្ឋានកូដ ដើម្បីធានាថា Helm អាចបន្តបំពេញតម្រូវការដែលកំពុងកើនឡើងនៃប្រព័ន្ធអេកូដែលកំពុងវិវត្ត។

ការលាគ្នាដ៏ទន់ភ្លន់ទៅកាន់ Tiller

ក្នុងអំឡុងពេលនៃការអភិវឌ្ឍន៍ Helm 2 យើងបានណែនាំ Tiller ជាផ្នែកមួយនៃការរួមបញ្ចូលរបស់យើងជាមួយនឹងកម្មវិធីគ្រប់គ្រងការចែកចាយរបស់ Google ។ Tiller បានដើរតួនាទីយ៉ាងសំខាន់សម្រាប់ក្រុមដែលធ្វើការនៅក្នុងចង្កោមទូទៅមួយ៖ វាអនុញ្ញាតឱ្យអ្នកឯកទេសផ្សេងៗគ្នាដែលប្រតិបត្តិការហេដ្ឋារចនាសម្ព័ន្ធដើម្បីធ្វើអន្តរកម្មជាមួយនឹងសំណុំនៃការចេញផ្សាយដូចគ្នា។

ចាប់តាំងពីការគ្រប់គ្រងការចូលប្រើដោយផ្អែកលើតួនាទី (RBAC) ត្រូវបានបើកតាមលំនាំដើមនៅក្នុង Kubernetes 1.6 ការធ្វើការជាមួយ Tiller ក្នុងការផលិតកាន់តែពិបាក។ ដោយសារតែចំនួនដ៏ច្រើននៃគោលការណ៍សុវត្ថិភាពដែលអាចកើតមាន ទីតាំងរបស់យើងគឺដើម្បីផ្តល់នូវការកំណត់រចនាសម្ព័ន្ធអនុញ្ញាតតាមលំនាំដើម។ នេះអនុញ្ញាតឱ្យអ្នកថ្មីអាចសាកល្បងជាមួយ Helm និង Kubernetes ដោយមិនចាំបាច់ចូលទៅក្នុងការកំណត់សុវត្ថិភាពជាមុន។ ជាអកុសល ការកំណត់រចនាសម្ព័ន្ធការអនុញ្ញាតនេះអាចផ្តល់ឱ្យអ្នកប្រើប្រាស់នូវជួរនៃការអនុញ្ញាតដ៏ធំទូលាយពេកដែលពួកគេមិនត្រូវការ។ វិស្វករ DevOps និង SRE ត្រូវរៀនជំហានប្រតិបត្តិការបន្ថែមនៅពេលដំឡើង Tiller នៅក្នុងចង្កោមអ្នកជួលច្រើន។

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

គោលដៅចម្បងរបស់ Tiller អាចសម្រេចបានដោយគ្មាន Tiller ដូច្នេះការសម្រេចចិត្តដំបូងរបស់យើងទាក់ទងនឹង Helm 3 គឺបោះបង់ Tiller ទាំងស្រុង។

ជាមួយនឹង Tiller បានបាត់បង់ គំរូសុវត្ថិភាពរបស់ Helm ត្រូវបានសម្រួលយ៉ាងសាមញ្ញ។ ឥឡូវនេះ Helm 3 គាំទ្ររាល់វិធីសាស្រ្តសុវត្ថិភាព អត្តសញ្ញាណ និងការផ្តល់សិទ្ធិទំនើបទាំងអស់របស់ Kubernetes បច្ចុប្បន្ន។ ការអនុញ្ញាតមួកសុវត្ថិភាពត្រូវបានកំណត់ដោយប្រើ ឯកសារ kubeconfig. អ្នកគ្រប់គ្រងចង្កោមអាចដាក់កម្រិតសិទ្ធិអ្នកប្រើចំពោះកម្រិតនៃការលម្អិតណាមួយ។ ការចេញផ្សាយនៅតែត្រូវបានរក្សាទុកនៅក្នុងចង្កោម ហើយមុខងារដែលនៅសល់របស់ Helm នៅតែរក្សាដដែល។

ឃ្លាំងគំនូសតាង

នៅកម្រិតខ្ពស់ ឃ្លាំងគំនូសតាងគឺជាកន្លែងដែលគំនូសតាងអាចត្រូវបានរក្សាទុក និងចែករំលែក។ កញ្ចប់អតិថិជន Helm និងផ្ញើតារាងទៅឃ្លាំង។ និយាយឱ្យសាមញ្ញ ឃ្លាំងគំនូសតាងគឺជាម៉ាស៊ីនមេ HTTP បឋមដែលមានឯកសារ index.yaml និងគំនូសតាងខ្ចប់មួយចំនួន។

ខណៈពេលដែលមានគុណសម្បត្តិមួយចំនួនចំពោះ Charts Repository API ដែលបំពេញតម្រូវការផ្ទុកមូលដ្ឋានភាគច្រើន វាក៏មានគុណវិបត្តិមួយចំនួនផងដែរ៖

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

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

ប៉ុន្តែតើអ្នកដឹងទេថា គម្រោងចែកចាយត្រូវបានបង្កើតឡើងដើម្បីចែកចាយទម្រង់ណាមួយនៃមាតិកា មិនត្រឹមតែរូបភាពកុងតឺន័រប៉ុណ្ណោះទេ?

សូមអរគុណចំពោះការខិតខំប្រឹងប្រែង គំនិតផ្តួចផ្តើមកុងតឺន័របើក (ឬ OCI) គំនូសតាង Helm អាចត្រូវបានដាក់នៅលើឧទាហរណ៍ការចែកចាយណាមួយ។ សម្រាប់ពេលនេះ ដំណើរការនេះគឺជាការពិសោធន៍។ ការគាំទ្រការចូល និងមុខងារផ្សេងទៀតដែលត្រូវការសម្រាប់ Helm 3 ពេញលេញគឺជាការងារដែលកំពុងដំណើរការ ប៉ុន្តែយើងពិតជារំភើបក្នុងការរៀនពីការរកឃើញដែលក្រុម OCI និង Distribution បានធ្វើក្នុងរយៈពេលជាច្រើនឆ្នាំកន្លងមកនេះ។ ហើយតាមរយៈការណែនាំ និងការណែនាំរបស់ពួកគេ យើងរៀនពីរបៀបដើម្បីដំណើរការសេវាកម្មដែលមានកម្រិតខ្ពស់។

ការពិពណ៌នាលម្អិតបន្ថែមទៀតនៃការផ្លាស់ប្តូរនាពេលខាងមុខចំពោះឃ្លាំងគំនូសតាង Helm គឺអាចរកបាន តំណភ្ជាប់.

ការគ្រប់គ្រងការចេញផ្សាយ

នៅក្នុង Helm 3 ស្ថានភាពកម្មវិធីត្រូវបានតាមដាននៅក្នុងចង្កោមដោយវត្ថុមួយគូ៖

វត្ថុចេញផ្សាយ - តំណាងឱ្យឧទាហរណ៍កម្មវិធី;
ការចេញផ្សាយកំណែសម្ងាត់ - តំណាងឱ្យស្ថានភាពដែលចង់បាននៃកម្មវិធីនៅចំណុចជាក់លាក់មួយនៅក្នុងពេលវេលា (ឧទាហរណ៍ការចេញផ្សាយកំណែថ្មី) ។

បញ្ហាប្រឈម helm install បង្កើតវត្ថុចេញផ្សាយមួយ និងបញ្ចេញកំណែសម្ងាត់។ ហៅ helm upgrade តម្រូវឱ្យមានវត្ថុចេញផ្សាយ (ដែលវាអាចផ្លាស់ប្តូរ) និងបង្កើតការសម្ងាត់កំណែចេញថ្មីដែលមានតម្លៃថ្មី និងការបង្ហាញដែលបានរៀបចំ។

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

ការចេញផ្សាយកំណែសម្ងាត់ភ្ជាប់ការចេញផ្សាយជាមួយនឹងការកែប្រែជាបន្តបន្ទាប់ (ការដំឡើង ការអាប់ដេត ការត្រឡប់ថយក្រោយ ការលុប)។

នៅក្នុង Helm 2 ការកែប្រែមានភាពស៊ីសង្វាក់គ្នាយ៉ាងខ្លាំង។ ហៅ helm install បានបង្កើត v1 ការធ្វើបច្ចុប្បន្នភាពជាបន្តបន្ទាប់ (ធ្វើឱ្យប្រសើរឡើង) - v2 ហើយដូច្នេះនៅលើ។ ការចេញផ្សាយ និងការចេញផ្សាយកំណែសម្ងាត់ត្រូវបានបង្រួមចូលទៅក្នុងវត្ថុតែមួយដែលគេស្គាល់ថាជាការកែប្រែ។ ការកែប្រែត្រូវបានរក្សាទុកក្នុង namespace ដូចគ្នានឹង Tiller ដែលមានន័យថាការចេញផ្សាយនីមួយៗគឺ "សកល" ទាក់ទងនឹង namespace ។ ជាលទ្ធផល មានតែឧទាហរណ៍មួយនៃឈ្មោះប៉ុណ្ណោះដែលអាចប្រើបាន។

នៅក្នុង Helm 3 ការចេញផ្សាយនីមួយៗត្រូវបានភ្ជាប់ជាមួយនឹងអាថ៌កំបាំងកំណែចេញផ្សាយមួយ ឬច្រើន។ វត្ថុចេញផ្សាយតែងតែពិពណ៌នាអំពីការចេញផ្សាយបច្ចុប្បន្នដែលបានដាក់ឱ្យប្រើប្រាស់ជាមួយ Kubernetes ។ កំណែចេញផ្សាយនីមួយៗសម្ងាត់ពិពណ៌នាតែកំណែមួយនៃការចេញផ្សាយនោះ។ ជាឧទាហរណ៍ ការអាប់ដេតនឹងបង្កើតកំណែចេញផ្សាយថ្មីសម្ងាត់ ហើយបន្ទាប់មកផ្លាស់ប្តូរវត្ថុចេញផ្សាយដើម្បីចង្អុលទៅកំណែថ្មីនោះ។ នៅក្នុងករណីនៃការ rollback មួយ អ្នកអាចប្រើការសម្ងាត់កំណែចេញផ្សាយមុនដើម្បីត្រឡប់ការចេញផ្សាយទៅស្ថានភាពមុន។

បន្ទាប់ពី Tiller ត្រូវបានបោះបង់ចោល ហាង Helm 3 បញ្ចេញទិន្នន័យក្នុងចន្លោះឈ្មោះដូចគ្នានឹងការចេញផ្សាយ។ ការផ្លាស់ប្តូរនេះអនុញ្ញាតឱ្យអ្នកដំឡើងគំនូសតាងដែលមានឈ្មោះចេញផ្សាយដូចគ្នានៅក្នុង namespace ផ្សេងគ្នា ហើយទិន្នន័យត្រូវបានរក្សាទុករវាង cluster updates/reboots in etcd។ ឧទាហរណ៍ អ្នកអាចដំឡើង WordPress នៅក្នុង namespace "foo" ហើយបន្ទាប់មកនៅក្នុង "bar" namespace ហើយការចេញផ្សាយទាំងពីរអាចត្រូវបានគេហៅថា "wordpress" ។

ការផ្លាស់ប្តូរទៅភាពអាស្រ័យគំនូសតាង

គំនូសតាងខ្ចប់ (ដោយប្រើ helm package) សម្រាប់ប្រើជាមួយ Helm 2 អាចត្រូវបានដំឡើងជាមួយ Helm 3 ទោះជាយ៉ាងណាក៏ដោយ ដំណើរការការងារអភិវឌ្ឍន៍គំនូសតាងត្រូវបានជួសជុលទាំងស្រុង ដូច្នេះការផ្លាស់ប្តូរមួយចំនួនត្រូវតែធ្វើឡើង ដើម្បីបន្តការអភិវឌ្ឍន៍គំនូសតាងជាមួយ Helm 3។ ជាពិសេស ប្រព័ន្ធគ្រប់គ្រងភាពអាស្រ័យគំនូសតាងបានផ្លាស់ប្តូរ។

ប្រព័ន្ធគ្រប់គ្រងភាពអាស្រ័យរបស់គំនូសតាងបានផ្លាស់ប្តូរពី requirements.yaml и requirements.lock នៅលើ Chart.yaml и Chart.lock. នេះមានន័យថាគំនូសតាងដែលបានប្រើពាក្យបញ្ជា helm dependencyទាមទារការដំឡើងមួយចំនួនដើម្បីដំណើរការនៅក្នុង Helm 3 ។

សូមក្រឡេកមើលឧទាហរណ៍មួយ។ ចូរបន្ថែមភាពអាស្រ័យទៅលើតារាងនៅក្នុង Helm 2 ហើយមើលថាតើមានការផ្លាស់ប្តូរអ្វីខ្លះនៅពេលផ្លាស់ទីទៅ Helm 3 ។

នៅក្នុង Helm 2 requirements.yaml មើលទៅដូចនេះ៖

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

នៅក្នុង Helm 3 ភាពអាស្រ័យដូចគ្នានឹងត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងរបស់អ្នក។ Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

គំនូសតាងនៅតែត្រូវបានទាញយក និងដាក់ក្នុងថត charts/ដូច្នេះ តារាងរង (គំនូសតាងរង), កុហកនៅក្នុងកាតាឡុក charts/នឹងបន្តធ្វើការដោយគ្មានការផ្លាស់ប្តូរ។

ការណែនាំតារាងបណ្ណាល័យ

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

គំនូសតាងបណ្ណាល័យត្រូវបានប្រកាសនៅក្នុងផ្នែក dependencies នៅក្នុងឯកសារ Chart.yaml. ការដំឡើង និងគ្រប់គ្រងពួកវាមិនខុសពីគំនូសតាងផ្សេងទៀតទេ។

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

យើងរំភើបចំពោះករណីប្រើប្រាស់ សមាសធាតុនេះនឹងបើកសម្រាប់អ្នកអភិវឌ្ឍន៍គំនូសតាង ក៏ដូចជាការអនុវត្តល្អបំផុតដែលអាចផុសចេញពីគំនូសតាងបណ្ណាល័យ។

តើមានអ្វីជាបន្ទាប់?

Helm 3.0.0-alpha.1 គឺជាមូលដ្ឋានគ្រឹះដែលយើងចាប់ផ្តើមបង្កើតកំណែថ្មីនៃ Helm ។ នៅក្នុងអត្ថបទដែលខ្ញុំបានពិពណ៌នាអំពីលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍មួយចំនួននៃ Helm 3. ពួកគេជាច្រើននៅតែស្ថិតក្នុងដំណាក់កាលដំបូងនៃការអភិវឌ្ឍន៍ ហើយនេះគឺជារឿងធម្មតា។ ចំណុចនៃការចេញផ្សាយអាល់ហ្វាគឺដើម្បីសាកល្បងគំនិត ប្រមូលមតិកែលម្អពីអ្នកប្រើប្រាស់ដំបូង និងបញ្ជាក់ពីការសន្មត់របស់យើង។

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

ខ្ញុំបានព្យាយាមគូសបញ្ជាក់ពីការកែលម្អសំខាន់ៗមួយចំនួនដែលនឹងមកដល់ Helm 3 ប៉ុន្តែបញ្ជីនេះគឺមិនពេញលេញទេ។ ផែនទីបង្ហាញផ្លូវពេញលេញសម្រាប់ Helm 3 រួមមានលក្ខណៈពិសេសដូចជាយុទ្ធសាស្រ្តអាប់ដេតដែលប្រសើរឡើង ការរួមបញ្ចូលកាន់តែស៊ីជម្រៅជាមួយការចុះបញ្ជី OCI និងការប្រើប្រាស់គ្រោងការណ៍ JSON ដើម្បីធ្វើសុពលភាពតម្លៃតារាង។ យើងក៏មានគម្រោងសម្អាតមូលដ្ឋានកូដ និងធ្វើបច្ចុប្បន្នភាពផ្នែកខ្លះរបស់វាដែលមិនយកចិត្តទុកដាក់ក្នុងរយៈពេលបីឆ្នាំកន្លងមកនេះ។

ប្រសិនបើអ្នកមានអារម្មណ៍ថាយើងខកខានអ្វីមួយ យើងចង់ស្តាប់គំនិតរបស់អ្នក!

ចូលរួមការពិភាក្សាអំពីពួកយើង ឆានែលខ្ជិល។:

#helm-users សម្រាប់សំណួរ និងការទំនាក់ទំនងសាមញ្ញជាមួយសហគមន៍។
#helm-dev ដើម្បីពិភាក្សាអំពីសំណើទាញ កូដ និងកំហុស។

អ្នកក៏អាចជជែកនៅក្នុងការហៅអ្នកអភិវឌ្ឍន៍សាធារណៈប្រចាំសប្តាហ៍របស់យើងនៅថ្ងៃព្រហស្បតិ៍នៅម៉ោង 19:30 MSK។ កិច្ចប្រជុំត្រូវបានឧទ្ទិសដល់ការពិភាក្សាអំពីបញ្ហាដែលអ្នកអភិវឌ្ឍន៍សំខាន់ៗ និងសហគមន៍កំពុងធ្វើការ ក៏ដូចជាប្រធានបទនៃការពិភាក្សាសម្រាប់សប្តាហ៍នេះ។ អ្នកណាក៏អាចចូលរួម និងចូលរួមក្នុងការប្រជុំបាន។ តំណភ្ជាប់មាននៅក្នុងឆានែល Slack #helm-dev.

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

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

ប្រភព: www.habr.com

ការណែនាំ Helm 3