ការណែនាំខ្លីៗដើម្បីប្ដូរតាមបំណង

ចំណាំ។ បកប្រែ៖ អត្ថបទនេះត្រូវបានសរសេរដោយ Scott Lowe ដែលជាវិស្វករដែលមានបទពិសោធន៍យ៉ាងទូលំទូលាយក្នុងផ្នែក IT ដែលជាអ្នកនិពន្ធ/សហអ្នកនិពន្ធសៀវភៅបោះពុម្ពចំនួនប្រាំពីរ (ភាគច្រើននៅលើ VMware vSphere)។ ឥឡូវនេះគាត់ធ្វើការឱ្យក្រុមហ៊ុនបុត្រសម្ព័ន្ធ VMware Heptio របស់ខ្លួន (ទទួលបាននៅឆ្នាំ 2016) ដែលមានឯកទេសខាងកុំព្យូទ័រលើពពក និង Kubernetes ។ អត្ថបទខ្លួនវាដើរតួជាការណែនាំសង្ខេប និងងាយយល់ចំពោះការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធសម្រាប់ Kubernetes ដោយប្រើបច្ចេកវិទ្យា ប្ដូរតាមបំណងដែលថ្មីៗនេះបានក្លាយជាផ្នែកមួយនៃ K8s ។

Kustomize គឺជាឧបករណ៍ដែលអនុញ្ញាតឱ្យអ្នកប្រើ "ប្ដូរតាមបំណងឯកសារ YAML សាមញ្ញ ដោយគ្មានគំរូសម្រាប់គោលបំណងផ្សេងគ្នា ដោយទុកឱ្យ YAML ដើមនៅដដែល និងអាចប្រើបាន" (ការពិពណ៌នាបានខ្ចីដោយផ្ទាល់ពី ប្តូរឃ្លាំងនៅលើ GitHub) ការប្ដូរតាមបំណងអាចដំណើរការដោយផ្ទាល់ ឬប្រើពី Kubernetes 1.14 kubectl -k ដើម្បីចូលប្រើមុខងាររបស់វា (ទោះបីជា Kubernetes 1.15 ក៏ដោយ ប្រព័ន្ធគោលពីរដាច់ដោយឡែកគឺថ្មីជាងសមត្ថភាពដែលបានបង្កើតនៅក្នុង kubectl)។ (ចំណាំ។ បកប្រែ៖ ហើយជាមួយនឹងការចេញផ្សាយថ្មីៗនេះ Kubernetes ១.១៤ ប្ដូរតាមបំណង គាំទ្រដោយ ផងដែរនៅក្នុងឧបករណ៍ប្រើប្រាស់ kubeadm ។ ) ក្នុងការប្រកាសនេះ ខ្ញុំចង់ណែនាំអ្នកអានអំពីមូលដ្ឋានគ្រឹះនៃ kustomize ។

នៅក្នុងទម្រង់/កម្មវិធីដ៏សាមញ្ញបំផុតរបស់វា ប្ដូរតាមបំណងគ្រាន់តែជាបណ្តុំនៃធនធាន (ឯកសារ YAML ដែលកំណត់វត្ថុ Kubernetes៖ ការដាក់ឱ្យប្រើប្រាស់ សេវាកម្ម។ល។) បូកនឹងបញ្ជីការណែនាំសម្រាប់ការផ្លាស់ប្តូរដែលត្រូវធ្វើចំពោះធនធានទាំងនោះ។ ដូចគ្នានឹងការធ្វើឱ្យប្រើសំណុំការណែនាំដែលមាននៅក្នុង Makefileហើយ Docker បង្កើតកុងតឺន័រដោយផ្អែកលើការណែនាំពី Dockerfile, ប្ដូរតាមបំណងការប្រើប្រាស់ kustomization.yaml ដើម្បីរក្សាទុកការណែនាំអំពីការផ្លាស់ប្តូរដែលអ្នកប្រើប្រាស់ចង់ធ្វើចំពោះសំណុំនៃធនធាន។

នេះគឺជាឯកសារឧទាហរណ៍ kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ខ្ញុំនឹងមិនព្យាយាមនិយាយអំពីវាលដែលអាចធ្វើបានទាំងអស់នៅក្នុងឯកសារនោះទេ។ kustomization.yaml (នេះត្រូវបានសរសេរយ៉ាងល្អអំពី នៅទីនេះ) ប៉ុន្តែខ្ញុំនឹងផ្តល់ការពន្យល់សង្ខេបអំពីឧទាហរណ៍ជាក់លាក់មួយ៖

• វាល resources បង្ហាញពីអ្វីដែល (ធនធានណាមួយ) ប្ដូរតាមបំណងនឹងផ្លាស់ប្តូរ។ ក្នុងករណីនេះ វានឹងស្វែងរកធនធាននៅក្នុងឯកសារ deployment.yaml и service.yaml នៅក្នុងថតរបស់អ្នក (អ្នកអាចបញ្ជាក់ផ្លូវពេញលេញ ឬទាក់ទងប្រសិនបើចាំបាច់)។
• វាល namePrefix ណែនាំ ប្ដូរតាមបំណង ដើម្បីបន្ថែមបុព្វបទជាក់លាក់ (ក្នុងករណីនេះ - dev-) ដើម្បីគុណលក្ខណៈ name ធនធានទាំងអស់ដែលបានកំណត់នៅក្នុងវាល resources. ដូច្នេះប្រសិនបើ Deployment មាន name ជាមួយនឹងអត្ថន័យ nginx-deployment, ប្ដូរតាមបំណងនឹងធ្វើឱ្យវា dev-nginx-deployment.
• វាល namespace ណែនាំ ប្ដូរតាមបំណង ដើម្បីបន្ថែមទំហំឈ្មោះដែលបានផ្តល់ឱ្យទៅធនធានទាំងអស់។ ក្នុងករណីនេះ ការដាក់ពង្រាយ និងសេវាកម្មនឹងធ្លាក់ចូលទៅក្នុង namespace development.
• ទីបំផុតវាល commonLabels មានសំណុំនៃស្លាកដែលនឹងត្រូវបានបន្ថែមទៅធនធានទាំងអស់។ ក្នុងឧទាហរណ៍របស់យើង kustomize នឹងកំណត់ស្លាកទៅធនធានដែលមានឈ្មោះ environment និងអត្ថន័យ development.

ប្រសិនបើអ្នកប្រើធ្វើ kustomize build . នៅក្នុងថតឯកសារ kustomization.yaml និងធនធានចាំបាច់ (ឧទាហរណ៍ឯកសារ deployment.yaml и service.yaml) បន្ទាប់មកនៅលទ្ធផល វានឹងទទួលបានអត្ថបទជាមួយនឹងការផ្លាស់ប្តូរដែលបានបញ្ជាក់នៅក្នុង kustomization.yaml.

ចំណាំ។ បកប្រែ៖ រូបភាពពីឯកសារគម្រោងស្តីពីការប្រើប្រាស់ "សាមញ្ញ" នៃ kustomize

លទ្ធផលអាចត្រូវបានបញ្ជូនបន្ត ប្រសិនបើការផ្លាស់ប្តូរចាំបាច់ត្រូវធ្វើ

kustomize build . > custom-config.yaml

ទិន្នន័យលទ្ធផលគឺកំណត់ (ទិន្នន័យបញ្ចូលដូចគ្នានឹងបង្កើតលទ្ធផលលទ្ធផលដូចគ្នា) ដូច្នេះអ្នកមិនចាំបាច់រក្សាទុកលទ្ធផលទៅក្នុងឯកសារទេ។ ជំនួសមកវិញ វាអាចត្រូវបានបញ្ជូនដោយផ្ទាល់ទៅពាក្យបញ្ជាផ្សេងទៀត៖

kustomize build . | kubectl apply -f -

មុខងារ kustomize ក៏អាចចូលប្រើបានតាមរយៈ kubectl -k (ចាប់តាំងពី Kubernetes កំណែ 1.14) ។ ទោះជាយ៉ាងណាក៏ដោយ សូមចងចាំថាកញ្ចប់ kustomize ដាច់ដោយឡែកត្រូវបានធ្វើបច្ចុប្បន្នភាពលឿនជាងកញ្ចប់ kubectl រួមបញ្ចូលគ្នា (យ៉ាងហោចណាស់នេះជាករណីជាមួយនឹងការចេញផ្សាយ Kubernetes 1.15) ។

អ្នកអានអាចសួរថា "ហេតុអ្វីបានជាភាពស្មុគស្មាញទាំងអស់នេះប្រសិនបើអ្នកអាចកែសម្រួលឯកសារដោយផ្ទាល់?" សំណួរដ៏អស្ចារ្យ។ នៅក្នុងឧទាហរណ៍របស់យើង, ជាការពិត អាចធ្វើបាន កែប្រែឯកសារ deployment.yaml и service.yaml ដោយផ្ទាល់ ប៉ុន្តែចុះយ៉ាងណាបើពួកគេជាផ្លូវបំបែកនៃគម្រោងរបស់នរណាម្នាក់? ការផ្លាស់ប្តូរឯកសារដោយផ្ទាល់ធ្វើឱ្យមានការលំបាក (ប្រសិនបើមិនអាចទៅរួច) ក្នុងការបង្កើតផ្លូវបំបែកឡើងវិញ នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងចំពោះប្រភពដើម/ប្រភព។ ការប្រើប្រាស់ kustomize អនុញ្ញាតឱ្យអ្នកធ្វើកណ្តាលការផ្លាស់ប្តូរទាំងនេះនៅក្នុងឯកសារមួយ។ kustomization.yamlដោយទុកឯកសារដើមឱ្យនៅដដែល ហើយធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការដាក់ឯកសារដើមឡើងវិញប្រសិនបើចាំបាច់។

អត្ថប្រយោជន៍នៃ kustomize ក្លាយជាជាក់ស្តែងនៅក្នុងករណីនៃការប្រើប្រាស់កាន់តែស្មុគស្មាញ។ នៅក្នុងឧទាហរណ៍ខាងលើ kustomization.yaml ហើយធនធានគឺស្ថិតនៅក្នុងថតតែមួយ។ ទោះយ៉ាងណាក៏ដោយ ប្តូរគាំទ្រករណីប្រើប្រាស់ដែលមានការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋាន និងវ៉ារ្យ៉ង់ជាច្រើនរបស់វា ដែលត្រូវបានគេស្គាល់ផងដែរថាជា ត្រួតលើគ្នា។. ឧទាហរណ៍ អ្នកប្រើប្រាស់ចង់យក Deployment and Service សម្រាប់ nginx ដែលខ្ញុំបានប្រើជាឧទាហរណ៍ ហើយបង្កើតការអភិវឌ្ឍន៍ ដំណាក់កាល និងកំណែផលិត (ឬវ៉ារ្យ៉ង់) នៃឯកសារទាំងនោះ។ ដើម្បីធ្វើដូច្នេះគាត់នឹងត្រូវការការត្រួតលើគ្នាដែលបានរៀបរាប់ខាងលើហើយជាការពិតធនធានមូលដ្ឋានដោយខ្លួនឯង។

ដើម្បីបង្ហាញពីគំនិតនៃការត្រួតលើគ្នា និងធនធានមូលដ្ឋាន (ធនធានមូលដ្ឋាន)ឧបមាថា ថតមានរចនាសម្ព័ន្ធដូចខាងក្រោម៖

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

នៅក្នុងឯកសារ base/kustomization.yaml អ្នកប្រើប្រាស់ដែលប្រើវាល resources គ្រាន់តែប្រកាសធនធានដែលប្ដូរតាមបំណងគួររួមបញ្ចូល។

នៅក្នុងឯកសារនីមួយៗ overlays/{dev,staging,prod}/kustomization.yaml អ្នកប្រើប្រាស់យោងទៅលើការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋាននៅក្នុងវាល resourcesហើយបន្ទាប់មកបង្ហាញពីការផ្លាស់ប្តូរជាក់លាក់សម្រាប់ បរិស្ថានដែលបានផ្តល់ឱ្យ. ឧទាហរណ៍ឯកសារ overlays/dev/kustomization.yaml អាច​មើល​ទៅ​ដូច​ជា​ឧទាហរណ៍​ដែល​បាន​ផ្ដល់​ឱ្យ​ខាង​ដើម៖

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ក្នុងករណីនេះឯកសារ overlays/prod/kustomization.yaml អាចខុសគ្នាទាំងស្រុង៖

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

នៅពេលអ្នកប្រើប្រាស់ដំណើរការ kustomize build . នៅក្នុងកាតាឡុក overlays/devប្ដូរតាមបំណងនឹងបង្កើតជម្រើសអភិវឌ្ឍន៍។ ប្រសិនបើអ្នករត់ kustomize build . នៅក្នុងកាតាឡុក overlays/prod - អ្នកទទួលបានជម្រើសផលិតកម្ម។ ហើយទាំងអស់នេះ - ដោយមិនធ្វើការផ្លាស់ប្តូរណាមួយទៅដើម (មូលដ្ឋាន) ឯកសារទាំងអស់នៅក្នុងវិធីប្រកាស និងកំណត់។ អ្នកអាចអនុវត្តការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋាន និងថតជាន់លើដោយផ្ទាល់ទៅការគ្រប់គ្រងកំណែ ដោយដឹងថាផ្អែកលើឯកសារទាំងនេះ អ្នកអាចបង្កើតឡើងវិញនូវការកំណត់ដែលចង់បាននៅពេលណាក៏បាន។

ចំណាំ។ បកប្រែ៖ រូបភាពពីឯកសារគម្រោងស្តីពីការប្រើប្រាស់ការត្រួតលើគ្នាក្នុងការកំណត់

ប្ដូរតាមបំណង ច្រើន ច្រើនជាងអ្វីដែលមាននៅក្នុងអត្ថបទនេះ។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំសង្ឃឹមថាវាដើរតួជាការណែនាំដ៏ល្អ។

ធនធានបន្ថែម

មានអត្ថបទ និងការបោះពុម្ពផ្សាយល្អៗជាច្រើនអំពី ប្ដូរតាមបំណង។ នេះគឺជាមួយចំនួនដែលខ្ញុំបានរកឃើញថាមានប្រយោជន៍ជាពិសេស៖

• ផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធ YAML មូលដ្ឋានសម្រាប់បរិស្ថានផ្សេងៗគ្នា prod/test ដោយប្រើ Kustomize;
• ប្ដូរតាមបំណង - វិធីត្រឹមត្រូវដើម្បីធ្វើគំរូនៅក្នុង Kubernetes;
• ការគ្រប់គ្រងការប្រកាសនៃវត្ថុ Kubernetes ដោយប្រើ ប្ដូរតាមបំណង;
• ប្ដូរតាមបំណង Upstream Helm Charts ជាមួយនឹងការប្ដូរតាមបំណង.

ចំណាំ។ បកប្រែ៖ អ្នកក៏អាចណែនាំប្លុកនៃតំណភ្ជាប់ដែលបានបោះពុម្ពផ្សាយជា ឯកសារភ្ជាប់ នៅលើគេហទំព័ររបស់ឧបករណ៍ប្រើប្រាស់ អមដោយបណ្តុំនៃវីដេអូដែលមានរបាយការណ៍ចុងក្រោយបំផុតអំពី ប្ដូរតាមបំណង។

ប្រសិនបើអ្នកមានសំណួរ ឬសំណូមពរសម្រាប់ការកែលម្អសម្ភារៈនេះ ខ្ញុំតែងតែបើកចំហចំពោះមតិកែលម្អ។ អ្នកអាចទាក់ទងខ្ញុំបាននៅ Twitter ឬ ឆានែល Kubernetes Slack. សូមរីករាយក្នុងការកែប្រែការបង្ហាញរបស់អ្នកជាមួយនឹង ប្ដូរតាមបំណង!

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

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

• «ឧបករណ៍សម្រាប់អ្នកអភិវឌ្ឍន៍កម្មវិធីដែលដំណើរការលើ Kubernetes»
• «Kubernetes 1.14៖ ទិដ្ឋភាពទូទៅនៃការច្នៃប្រឌិតសំខាន់ៗ»
• «លទ្ធផលសំខាន់ៗចំនួនប្រាំនៃកិច្ចប្រជុំកំពូល Helm 2019 នៅទីក្រុង Amsterdam»
• «ការណែនាំជាក់ស្តែងចំពោះអ្នកគ្រប់គ្រងកញ្ចប់សម្រាប់ Kubernetes - Helm"។

ប្រភព: www.habr.com