ការ​ដាក់​ស្លាក​ផ្អែកលើ​ខ្លឹមសារ​ក្នុង​កម្មវិធី​បង្កើត werf៖ ហេតុអ្វី និង​របៀប​ដែល​វា​ដំណើរការ?

werf គឺជាឧបករណ៍ប្រើប្រាស់ GitOps CLI បើកចំហរបស់យើងសម្រាប់ការកសាង និងបញ្ជូនកម្មវិធីទៅ Kubernetes ។ IN ចេញផ្សាយ v1.1 មុខងារថ្មីមួយត្រូវបានណែនាំនៅក្នុងកម្មវិធីប្រមូលរូបភាព៖ ការដាក់ស្លាករូបភាពតាមខ្លឹមសារ ឬ ការដាក់ស្លាកផ្អែកលើមាតិកា. រហូតមកដល់ពេលនេះ គ្រោងការណ៍ដាក់ស្លាកធម្មតានៅក្នុង werf ពាក់ព័ន្ធនឹងការដាក់ស្លាករូបភាព Docker ដោយ Git tag, Git branch ឬ Git commit ។ ប៉ុន្តែគ្រោងការណ៍ទាំងអស់នេះមានគុណវិបត្តិដែលត្រូវបានដោះស្រាយទាំងស្រុងដោយយុទ្ធសាស្រ្តដាក់ស្លាកថ្មី។ ព័ត៌មានលម្អិតអំពីវា និងមូលហេតុដែលវាល្អខ្លាំងគឺស្ថិតនៅក្រោមការកាត់។

ការដាក់ចេញនូវសំណុំនៃសេវាកម្មមីក្រូពីឃ្លាំង Git មួយ។

ស្ថានភាពជារឿយៗកើតឡើងនៅពេលដែលកម្មវិធីមួយត្រូវបានបែងចែកទៅជាសេវាកម្មឯករាជ្យច្រើន ឬតិច។ ការចេញផ្សាយសេវាកម្មទាំងនេះអាចកើតឡើងដោយឯករាជ្យ៖ សេវាកម្មមួយ ឬច្រើនអាចត្រូវបានចេញផ្សាយក្នុងពេលតែមួយ ខណៈនៅសល់ត្រូវបន្តដំណើរការដោយគ្មានការផ្លាស់ប្តូរ។ ប៉ុន្តែតាមទស្សនៈនៃការរក្សាទុកកូដ និងការគ្រប់គ្រងគម្រោង វាកាន់តែងាយស្រួលក្នុងការរក្សាសេវាកម្មកម្មវិធីបែបនេះនៅក្នុងឃ្លាំងតែមួយ។

មានស្ថានភាពនៅពេលដែលសេវាកម្មពិតជាឯករាជ្យ និងមិនមានទំនាក់ទំនងជាមួយកម្មវិធីតែមួយ។ ក្នុងករណីនេះ ពួកគេនឹងមានទីតាំងនៅក្នុងគម្រោងដាច់ដោយឡែក ហើយការចេញផ្សាយរបស់ពួកគេនឹងត្រូវបានអនុវត្តតាមរយៈដំណើរការ CI/CD ដាច់ដោយឡែកនៅក្នុងគម្រោងនីមួយៗ។

ទោះជាយ៉ាងណាក៏ដោយ តាមការពិត អ្នកអភិវឌ្ឍន៍ជារឿយៗបំបែកកម្មវិធីតែមួយទៅជាសេវាមីក្រូជាច្រើន ប៉ុន្តែការបង្កើតឃ្លាំង និងគម្រោងដាច់ដោយឡែកសម្រាប់គ្នា ... គឺជាការហួសកម្រិតច្បាស់លាស់។ វាគឺជាស្ថានភាពនេះដែលនឹងត្រូវបានពិភាក្សាបន្ថែមទៀត៖ សេវាមីក្រូទាំងនេះជាច្រើនមានទីតាំងនៅក្នុងឃ្លាំងគម្រោងតែមួយ ហើយការចេញផ្សាយកើតឡើងតាមរយៈដំណើរការតែមួយនៅក្នុង CI/CD ។

ការដាក់ស្លាកដោយសាខា Git និងស្លាក Git

ចូរនិយាយថាយុទ្ធសាស្រ្តដាក់ស្លាកទូទៅបំផុតត្រូវបានប្រើ - ស្លាកឬសាខា. សម្រាប់សាខា Git រូបភាពត្រូវបានដាក់ស្លាកជាមួយឈ្មោះសាខា សម្រាប់សាខាមួយនៅពេលតែមួយ មានរូបភាពបោះពុម្ពតែមួយប៉ុណ្ណោះតាមឈ្មោះសាខានោះ។ សម្រាប់ស្លាក Git រូបភាពត្រូវបានដាក់ស្លាកដោយយោងទៅតាមឈ្មោះស្លាក។

នៅពេលដែលស្លាក Git ថ្មីត្រូវបានបង្កើត — ឧទាហរណ៍ នៅពេលដែលកំណែថ្មីត្រូវបានចេញផ្សាយ — ស្លាក Docker ថ្មីនឹងត្រូវបានបង្កើតឡើងសម្រាប់រូបភាពគម្រោងទាំងអស់នៅក្នុង Docker Registry៖

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

ឈ្មោះរូបភាពថ្មីទាំងនេះត្រូវបានឆ្លងកាត់គំរូ Helm ទៅកាន់ការកំណត់រចនាសម្ព័ន្ធ Kubernetes ។ នៅពេលចាប់ផ្តើមការដាក់ពង្រាយដោយប្រើពាក្យបញ្ជា werf deploy វាលកំពុងត្រូវបានធ្វើបច្ចុប្បន្នភាព image នៅក្នុងធនធាន Kubernetes បង្ហាញឱ្យឃើញ និងចាប់ផ្តើមធនធានដែលត្រូវគ្នាឡើងវិញ ដោយសារឈ្មោះរូបភាពដែលបានផ្លាស់ប្តូរ។

បញ្ហា៖ ក្នុងករណីដែលការពិត ខ្លឹមសារនៃរូបភាពមិនបានផ្លាស់ប្តូរចាប់តាំងពីការចេញផ្សាយមុន (Git tag) ប៉ុន្តែមានតែស្លាក Docker របស់វាប៉ុណ្ណោះ ដែលវាកើតឡើង នាំអោយ ចាប់ផ្តើមកម្មវិធីនេះឡើងវិញ ហើយតាមនោះ ពេលវេលារងចាំខ្លះអាចធ្វើទៅបាន។ ទោះបីជាមិនមានហេតុផលពិតប្រាកដដើម្បីដំណើរការការចាប់ផ្តើមឡើងវិញនេះក៏ដោយ។

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

ការដាក់ស្លាកដោយ Git commit

werf ក៏មានយុទ្ធសាស្រ្តដាក់ស្លាកដែលទាក់ទងនឹង Git commits ផងដែរ។

Git-commit គឺជាឧបករណ៍កំណត់អត្តសញ្ញាណសម្រាប់មាតិកានៃឃ្លាំង Git ហើយអាស្រ័យលើប្រវត្តិកែសម្រួលឯកសារនៅក្នុងឃ្លាំង Git ដូច្នេះវាហាក់ដូចជាសមហេតុផលក្នុងការប្រើវាសម្រាប់ការដាក់ស្លាករូបភាពនៅក្នុង Docker Registry ។

ទោះជាយ៉ាងណាក៏ដោយ ការដាក់ស្លាកដោយ Git commit មានគុណវិបត្តិដូចគ្នានឹងការដាក់ស្លាកដោយសាខា Git ឬ Git tags៖

• ការប្តេជ្ញាចិត្តទទេអាចត្រូវបានបង្កើតដែលមិនផ្លាស់ប្តូរឯកសារណាមួយ ប៉ុន្តែស្លាក Docker នៃរូបភាពនឹងត្រូវបានផ្លាស់ប្តូរ។
• ការរួមបញ្ចូលគ្នាអាចត្រូវបានបង្កើតឡើងដែលមិនផ្លាស់ប្តូរឯកសារ ប៉ុន្តែស្លាក Docker នៃរូបភាពនឹងត្រូវបានផ្លាស់ប្តូរ។
• ការប្តេជ្ញាចិត្តអាចត្រូវបានធ្វើឡើងដែលផ្លាស់ប្តូរឯកសារទាំងនោះនៅក្នុង Git ដែលមិនត្រូវបាននាំចូលទៅក្នុងរូបភាព ហើយស្លាក Docker នៃរូបភាពនឹងត្រូវបានផ្លាស់ប្តូរម្តងទៀត។

ការដាក់ស្លាកឈ្មោះសាខា Git មិនឆ្លុះបញ្ចាំងពីកំណែរូបភាពទេ។

មានបញ្ហាមួយទៀតដែលទាក់ទងនឹងយុទ្ធសាស្ត្រដាក់ស្លាកសម្រាប់សាខា Git ។

ការ​ដាក់​ស្លាក​តាម​ឈ្មោះ​សាខា​ដំណើរការ​ដរាបណា​ការ​ប្តេជ្ញាចិត្ត​នៅ​លើ​សាខា​នោះ​ត្រូវ​បាន​ប្រមូល​តាម​លំដាប់​តាម​លំដាប់លំដោយ។

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

លើសពីនេះទៀត ជាមួយនឹងការរុញជាបន្តបន្ទាប់ទៅក្នុងសាខាមួយជាមួយនឹងរយៈពេលខ្លីរវាងពួកវា ការប្តេជ្ញាចិត្តចាស់អាចត្រូវបានចងក្រងនៅពេលក្រោយជាងរូបភាពថ្មីជាងនេះ៖ កំណែចាស់នៃរូបភាពនឹងសរសេរជាន់លើថ្មីមួយដោយប្រើស្លាកសាខា Git ។ បញ្ហាបែបនេះអាចត្រូវបានដោះស្រាយដោយប្រព័ន្ធ CI/CD (ឧទាហរណ៍នៅក្នុង GitLab CI បំពង់បង្ហូរប្រេងចុងក្រោយត្រូវបានបើកដំណើរការសម្រាប់ការប្រព្រឹត្តជាបន្តបន្ទាប់)។ ទោះយ៉ាងណាក៏ដោយ មិនមែនគ្រប់ប្រព័ន្ធទាំងអស់គាំទ្ររឿងនេះទេ ហើយត្រូវតែមានវិធីដែលអាចទុកចិត្តបានជាងនេះ ដើម្បីទប់ស្កាត់បញ្ហាជាមូលដ្ឋានបែបនេះ។

តើ​អ្វី​ទៅ​ជា​ការ​ដាក់​ស្លាក​ផ្អែក​លើ​មាតិកា?

ដូច្នេះ អ្វី​ទៅ​ជា​ការ​ដាក់​ស្លាក​តាម​មាតិកា​គឺ​ការ​ដាក់​ស្លាក​រូបភាព​តាម​មាតិកា។

ដើម្បីបង្កើត Docker tags វាមិនមែនជា Git primitives (Git branch, Git tag...) ដែលត្រូវបានប្រើទេ ប៉ុន្តែជា checksum ដែលភ្ជាប់ជាមួយ៖

• មាតិកានៃរូបភាព. ស្លាកលេខសម្គាល់រូបភាពឆ្លុះបញ្ចាំងពីខ្លឹមសាររបស់វា។ នៅពេលបង្កើតកំណែថ្មី ឧបករណ៍កំណត់អត្តសញ្ញាណនេះនឹងមិនផ្លាស់ប្តូរទេ ប្រសិនបើឯកសារក្នុងរូបភាពមិនបានផ្លាស់ប្តូរ។
• ប្រវត្តិនៃការបង្កើតរូបភាពនេះនៅក្នុង Git. រូបភាពដែលភ្ជាប់ជាមួយសាខា Git ផ្សេងគ្នា និងប្រវត្តិបង្កើតផ្សេងគ្នាតាមរយៈ werf នឹងមានស្លាកលេខសម្គាល់ផ្សេងគ្នា។

ស្លាកសម្គាល់អត្តសញ្ញាណបែបនេះគឺជាអ្វីដែលគេហៅថា ហត្ថលេខាលើឆាករូបភាព.

រូបភាពនីមួយៗមានបណ្តុំនៃដំណាក់កាល៖ from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ល។ ដំណាក់កាលនីមួយៗមានឧបករណ៍សម្គាល់ដែលឆ្លុះបញ្ចាំងពីខ្លឹមសាររបស់វា − ហត្ថលេខាលើឆាក (ហត្ថលេខាលើឆាក).

រូបភាពចុងក្រោយដែលមានដំណាក់កាលទាំងនេះត្រូវបានដាក់ស្លាកដោយអ្វីដែលគេហៅថាហត្ថលេខានៃសំណុំនៃដំណាក់កាលទាំងនេះ - ហត្ថលេខាដំណាក់កាល, - ដែលជាទូទៅសម្រាប់គ្រប់ដំណាក់កាលនៃរូបភាព។

សម្រាប់រូបភាពនីមួយៗពីការកំណត់រចនាសម្ព័ន្ធ werf.yaml ក្នុងករណីទូទៅ វានឹងមានហត្ថលេខាផ្ទាល់ខ្លួនរបស់វា ហើយតាមនោះ ស្លាក Docker ។

ហត្ថលេខាដំណាក់កាលដោះស្រាយបញ្ហាទាំងអស់នេះ៖

• ធន់នឹងការប្រព្រឹត្ត Git ទទេ។
• ធន់នឹង Git ប្តេជ្ញាផ្លាស់ប្តូរឯកសារដែលមិនទាក់ទងនឹងរូបភាព។
• មិននាំឱ្យមានបញ្ហានៃការជួសជុលកំណែបច្ចុប្បន្ននៃរូបភាពនៅពេលចាប់ផ្តើមការស្ថាបនាឡើងវិញសម្រាប់ Git ចាស់នៃសាខាមួយ។

ឥឡូវនេះនេះគឺជាយុទ្ធសាស្ត្រដាក់ស្លាកដែលបានណែនាំ និងជាលំនាំដើមនៅក្នុង werf សម្រាប់ប្រព័ន្ធ CI ទាំងអស់។

របៀបបើក និងប្រើក្នុង werf

ពាក្យបញ្ជាឥឡូវនេះមានជម្រើសដែលត្រូវគ្នា។ werf publish: --tag-by-stages-signature=true|false

នៅក្នុងប្រព័ន្ធ CI យុទ្ធសាស្ត្រដាក់ស្លាកត្រូវបានបញ្ជាក់ដោយពាក្យបញ្ជា werf ci-env. ពីមុនប៉ារ៉ាម៉ែត្រត្រូវបានកំណត់សម្រាប់វា។ werf ci-env --tagging-strategy=tag-or-branch. ឥឡូវនេះប្រសិនបើអ្នកបញ្ជាក់ werf ci-env --tagging-strategy=stages-signature ឬមិនបញ្ជាក់ជម្រើសនេះ werf នឹងប្រើយុទ្ធសាស្ត្រដាក់ស្លាកតាមលំនាំដើម stages-signature. ក្រុម werf ci-env នឹងកំណត់ទង់ចាំបាច់សម្រាប់ពាក្យបញ្ជាដោយស្វ័យប្រវត្តិ werf build-and-publish (ឬ werf publish) ដូច្នេះមិនចាំបាច់បញ្ជាក់ជម្រើសបន្ថែមសម្រាប់ពាក្យបញ្ជាទាំងនេះទេ។

ឧទាហរណ៍ពាក្យបញ្ជា៖

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...អាចបង្កើតរូបភាពដូចខាងក្រោម៖

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

វាគឺជាការ 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d គឺជាហត្ថលេខានៃដំណាក់កាលនៃរូបភាព backendនិង f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - ហត្ថលេខានៃដំណាក់កាលរូបភាព frontend.

នៅពេលប្រើមុខងារពិសេស werf_container_image и werf_container_env មិនចាំបាច់ផ្លាស់ប្តូរអ្វីទាំងអស់នៅក្នុងគំរូ Helm៖ មុខងារទាំងនេះនឹងបង្កើតឈ្មោះរូបភាពត្រឹមត្រូវដោយស្វ័យប្រវត្តិ។

ការកំណត់រចនាសម្ព័ន្ធឧទាហរណ៍នៅក្នុងប្រព័ន្ធ CI៖

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

ព័ត៌មានបន្ថែមអំពីការកំណត់មាននៅក្នុងឯកសារ៖

• ថត → ការបោះពុម្ពផ្សាយ (បោះពុម្ព);
• ធ្វើការជាមួយ CI/CD → ព័ត៌មានទូទៅ → ដំណាក់កាល-ហត្ថលេខា;
• ការរួមបញ្ចូលជាមួយ GitLab CI/CD → .gitlab-ci.yml.

សរុប

• ជម្រើសថ្មី។ werf publish --tag-by-stages-signature=true|false.
• តម្លៃជម្រើសថ្មី។ werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ប្រសិនបើមិនបានបញ្ជាក់ទេ លំនាំដើមនឹងមាន stages-signature).
• ប្រសិនបើអ្នកធ្លាប់ប្រើជម្រើសដាក់ស្លាកសម្រាប់ Git commits (WERF_TAG_GIT_COMMIT ឬជម្រើស werf publish --tag-git-commit COMMIT) បន្ទាប់មកត្រូវប្រាកដថាប្តូរទៅយុទ្ធសាស្ត្រដាក់ស្លាក ដំណាក់កាល - ហត្ថលេខា.
• វាជាការល្អប្រសើរជាងមុនដើម្បីប្តូរគម្រោងថ្មីភ្លាមៗទៅគ្រោងការណ៍ដាក់ស្លាកថ្មី។
• នៅពេលផ្ទេរទៅ werf 1.1 វាត្រូវបានណែនាំឱ្យប្តូរគម្រោងចាស់ទៅគ្រោងការណ៍ស្លាកថ្មី ប៉ុន្តែចាស់ ស្លាកឬសាខា នៅតែត្រូវបានគាំទ្រ។

ការដាក់ស្លាកផ្អែកលើខ្លឹមសារដោះស្រាយបញ្ហាទាំងអស់ដែលមាននៅក្នុងអត្ថបទ៖

• ភាពធន់នឹងឈ្មោះស្លាក Docker ចំពោះ Git commits ទទេ។
• ភាពធន់នៃឈ្មោះស្លាក Docker ទៅ Git ប្រព្រឹត្តដែលផ្លាស់ប្តូរឯកសារដែលមិនទាក់ទងនឹងរូបភាព។
• មិននាំឱ្យមានបញ្ហានៃការជួសជុលកំណែបច្ចុប្បន្ននៃរូបភាពនៅពេលចាប់ផ្តើមការស្ថាបនាឡើងវិញសម្រាប់ Git ចាស់សម្រាប់សាខា Git ។

ប្រើ​វា! ហើយកុំភ្លេចមកលេងយើងនៅ GitHubដើម្បីបង្កើតបញ្ហា ឬស្វែងរកបញ្ហាដែលមានស្រាប់ បន្ថែមបូក បង្កើត PR ឬគ្រាន់តែមើលការអភិវឌ្ឍន៍គម្រោង។

PS

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

• «ការចេញផ្សាយ werf 1.1៖ ការកែលម្អដល់អ្នកសាងសង់ថ្ងៃនេះ និងផែនការសម្រាប់អនាគត»
• «ការណែនាំ werf 1.0 មានស្ថេរភាព៖ តើ GitOps ត្រូវធ្វើយ៉ាងណាជាមួយវា ស្ថានភាព និងផែនការ»
• «werf - ឧបករណ៍របស់យើងសម្រាប់ CI / CD នៅក្នុង Kubernetes (ទិដ្ឋភាពទូទៅ និងរបាយការណ៍វីដេអូ)»
• ស៊េរីនៃការកត់សម្គាល់អំពីការច្នៃប្រឌិតនៅក្នុង werf:
  • «ការរួមបញ្ចូលគ្នា 3 ផ្លូវទៅ werf: ការដាក់ពង្រាយ Kubernetes ជាមួយ Helm "នៅលើ steroids"»
  • «ការប្រើប្រាស់ werf ដើម្បីដាក់ចេញតារាង Helm ដ៏ស្មុគស្មាញ»
  • «ការគាំទ្រសម្រាប់ monorepo និង multirepo នៅក្នុង werf និងអ្វីដែល Docker Registry ត្រូវធ្វើជាមួយវា។»
  • «ឥឡូវនេះអ្នកអាចបង្កើតរូបភាព Docker នៅក្នុង werf ដោយប្រើ Dockerfile ធម្មតា។"។

ប្រភព: www.habr.com