បញ្ហានៃការសម្អាត "ឆ្លាតវៃ" នៃរូបភាពកុងតឺន័រ និងដំណោះស្រាយរបស់វានៅក្នុង werf

អត្ថបទពិភាក្សាអំពីបញ្ហានៃការសម្អាតរូបភាពដែលកកកុញនៅក្នុងការចុះបញ្ជីកុងតឺន័រ (Docker Registry និង analogues របស់វា) នៅក្នុងការពិតនៃបំពង់បង្ហូរ CI/CD ទំនើបសម្រាប់កម្មវិធីដើមលើពពកដែលបានបញ្ជូនទៅ Kubernetes ។ លក្ខណៈវិនិច្ឆ័យចម្បងសម្រាប់ភាពពាក់ព័ន្ធនៃរូបភាព និងការលំបាកជាលទ្ធផលក្នុងការសម្អាតដោយស្វ័យប្រវត្តិ ការសន្សំទំហំ និងការបំពេញតម្រូវការរបស់ក្រុមត្រូវបានផ្តល់ឱ្យ។ ជាចុងក្រោយ ដោយប្រើឧទាហរណ៍នៃគម្រោង Open Source ជាក់លាក់ យើងនឹងប្រាប់អ្នកពីរបៀបដែលការលំបាកទាំងនេះអាចត្រូវបានយកឈ្នះ។

សេចក្តីណែនាំ

ចំនួនរូបភាពនៅក្នុងបញ្ជីឈ្មោះកុងតឺន័រអាចកើនឡើងយ៉ាងឆាប់រហ័ស ដោយយកទំហំផ្ទុកកាន់តែច្រើន ហើយដូច្នេះវាបង្កើនការចំណាយរបស់វាយ៉ាងខ្លាំង។ ដើម្បីគ្រប់គ្រង កម្រិត ឬរក្សាកំណើនដែលអាចទទួលយកបាននៃទំហំដែលបានកាន់កាប់នៅក្នុងបញ្ជីឈ្មោះ វាត្រូវបានទទួលយក៖

1. ប្រើចំនួនថេរនៃស្លាកសម្រាប់រូបភាព;
2. សម្អាតរូបភាពតាមរបៀបណាមួយ។

ការកំណត់ដំបូងគឺជួនកាលអាចទទួលយកបានសម្រាប់ក្រុមតូចៗ។ ប្រសិនបើអ្នកអភិវឌ្ឍន៍មានស្លាកអចិន្រ្តៃយ៍គ្រប់គ្រាន់ (latest, main, test, boris ល) បញ្ជីឈ្មោះនឹងមិនហើមក្នុងទំហំទេ ហើយក្នុងរយៈពេលយូរ អ្នកនឹងមិនចាំបាច់គិតអំពីការសម្អាតវាទាល់តែសោះ។ យ៉ាងណាមិញ រូបភាពដែលមិនពាក់ព័ន្ធទាំងអស់ត្រូវបានលុបចេញ ហើយមិនមានការងារអ្វីនៅសល់សម្រាប់ការសម្អាតទេ (អ្វីៗទាំងអស់គឺធ្វើឡើងដោយអ្នកប្រមូលសំរាមធម្មតា)។

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

ដោយសារការជួសជុលកំហុស និងការបង្កើតមុខងារថ្មីត្រូវបានអនុវត្តស្របគ្នា ហើយការចេញផ្សាយអាចត្រូវបានអនុវត្តច្រើនដងក្នុងមួយថ្ងៃ វាច្បាស់ណាស់ថាដំណើរការអភិវឌ្ឍន៍ត្រូវបានអមដោយចំនួននៃការប្តេជ្ញាចិត្តជាច្រើន ដែលមានន័យថា រូបភាពមួយចំនួនធំនៅក្នុងបញ្ជីឈ្មោះ. ជាលទ្ធផលបញ្ហានៃការរៀបចំការសម្អាតប្រកបដោយប្រសិទ្ធភាពនៃបញ្ជីឈ្មោះកើតឡើង, i.e. ការលុបរូបភាពដែលមិនពាក់ព័ន្ធ។

ប៉ុន្តែ​តើ​អ្នក​កំណត់​ថា​តើ​រូបភាព​មួយ​ពាក់ព័ន្ធ​ដោយ​របៀប​ណា?

លក្ខណៈវិនិច្ឆ័យសម្រាប់ភាពពាក់ព័ន្ធនៃរូបភាព

ក្នុងករណីភាគច្រើន លក្ខណៈវិនិច្ឆ័យចម្បងនឹងមានៈ

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

2. ទីពីរ (មិនសូវច្បាស់ទេ ប៉ុន្តែក៏សំខាន់ខ្លាំងដែរ ហើយម្តងទៀតទាក់ទងនឹងការកេងប្រវ័ញ្ច) - រូបភាពនោះ។ ទាមទារសម្រាប់ការវិលត្រឡប់មកវិញ ក្នុងករណីរកឃើញបញ្ហាធ្ងន់ធ្ងរ នៅក្នុងកំណែបច្ចុប្បន្ន។ ឧទាហរណ៍ ក្នុងករណី Helm ទាំងនេះគឺជារូបភាពដែលត្រូវបានប្រើនៅក្នុងកំណែដែលបានរក្សាទុកនៃការចេញផ្សាយ។ (ដោយវិធីនេះ តាមលំនាំដើមនៅក្នុង Helm ដែនកំណត់គឺ 256 ការកែប្រែ ប៉ុន្តែវាមិនទំនងថានរណាម្នាក់ពិតជាត្រូវការរក្សាទុកទេ។ បែបនេះ មួយចំនួនធំនៃកំណែ?..) បន្ទាប់ពីទាំងអស់, ជាពិសេស, យើងរក្សាទុកកំណែដូច្នេះយើងអាចប្រើពួកវានៅពេលក្រោយ, i.e. "ត្រឡប់" ទៅពួកគេប្រសិនបើចាំបាច់។

3. ទីបី - តម្រូវការអ្នកអភិវឌ្ឍន៍៖ រូបភាពទាំងអស់ដែលទាក់ទងនឹងការងារបច្ចុប្បន្នរបស់ពួកគេ។ ឧទាហរណ៍ ប្រសិនបើយើងកំពុងពិចារណា PR នោះវាសមហេតុផលក្នុងការទុករូបភាពដែលត្រូវនឹងការប្តេជ្ញាចិត្តចុងក្រោយ ហើយនិយាយថាការប្តេជ្ញាចិត្តពីមុន៖ វិធីនេះអ្នកអភិវឌ្ឍន៍អាចត្រលប់ទៅកិច្ចការណាមួយបានយ៉ាងឆាប់រហ័ស ហើយធ្វើការជាមួយការផ្លាស់ប្តូរចុងក្រោយបំផុត។

4. ទីបួន - រូបភាពនោះ។ ត្រូវគ្នាទៅនឹងកំណែនៃកម្មវិធីរបស់យើង។, i.e. គឺជាផលិតផលចុងក្រោយ៖ v1.0.0, 20.04.01/XNUMX/XNUMX, សៀរ៉ា។ល។

NB: លក្ខណៈវិនិច្ឆ័យដែលបានកំណត់នៅទីនេះត្រូវបានបង្កើតឡើងដោយផ្អែកលើបទពិសោធន៍ដែលមានទំនាក់ទំនងជាមួយក្រុមអភិវឌ្ឍន៍រាប់សិបនាក់មកពីក្រុមហ៊ុនផ្សេងៗគ្នា។ ទោះជាយ៉ាងណាក៏ដោយ អាស្រ័យលើភាពជាក់លាក់នៅក្នុងដំណើរការអភិវឌ្ឍន៍ និងហេដ្ឋារចនាសម្ព័ន្ធដែលបានប្រើ (ឧទាហរណ៍ Kubernetes មិនត្រូវបានប្រើទេ) លក្ខណៈវិនិច្ឆ័យទាំងនេះអាចខុសគ្នា។

សិទ្ធិទទួលបាន និងដំណោះស្រាយដែលមានស្រាប់

សេវាកម្មពេញនិយមជាមួយនឹងការចុះបញ្ជីកុងតឺន័រ ជាក្បួនផ្តល់នូវគោលការណ៍សម្អាតរូបភាពផ្ទាល់ខ្លួនរបស់ពួកគេ៖ នៅក្នុងពួកវាអ្នកអាចកំណត់លក្ខខណ្ឌដែលស្លាកមួយត្រូវបានដកចេញពីបញ្ជីឈ្មោះ។ ទោះយ៉ាងណាក៏ដោយ លក្ខខណ្ឌទាំងនេះត្រូវបានកំណត់ដោយប៉ារ៉ាម៉ែត្រដូចជាឈ្មោះ ពេលវេលាបង្កើត និងចំនួនស្លាក*។

* អាស្រ័យលើការអនុវត្តការចុះបញ្ជីកុងតឺន័រជាក់លាក់។ យើងបានពិចារណាពីលទ្ធភាពនៃដំណោះស្រាយដូចខាងក្រោម៖ Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - គិតត្រឹមខែកញ្ញាឆ្នាំ 2020 ។

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

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

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

រូបភាពនៃលំហូរការងារនៅក្នុង Git

ចូរនិយាយថាអ្នកកំពុងធ្វើការអ្វីមួយដូចនេះនៅក្នុង Git៖

រូបតំណាងដែលមានក្បាលក្នុងដ្យាក្រាមបង្ហាញពីរូបភាពកុងតឺន័រដែលបច្ចុប្បន្នត្រូវបានដាក់ឱ្យប្រើប្រាស់ក្នុង Kubernetes សម្រាប់អ្នកប្រើប្រាស់ណាមួយ (អ្នកប្រើប្រាស់ចុងក្រោយ អ្នកសាកល្បង អ្នកគ្រប់គ្រង។ល។) ឬត្រូវបានប្រើប្រាស់ដោយអ្នកអភិវឌ្ឍន៍សម្រាប់ការកែកំហុស និងគោលបំណងស្រដៀងគ្នា។

តើមានអ្វីកើតឡើងប្រសិនបើគោលការណ៍សម្អាតអនុញ្ញាតឱ្យរក្សាទុកតែរូបភាព (មិនត្រូវបានលុប) ដោយឈ្មោះស្លាកដែលបានផ្តល់ឱ្យ?

ជាក់ស្តែង សេណារីយ៉ូបែបនេះនឹងមិនពេញចិត្តនរណាម្នាក់ឡើយ។

តើ​នឹង​មាន​អ្វី​ប្រែប្រួល​ប្រសិនបើ​គោលការណ៍​មិន​អនុញ្ញាត​ឱ្យ​រូបភាព​ត្រូវ​បាន​លុប? យោងទៅតាមចន្លោះពេលដែលបានផ្តល់ឱ្យ / ចំនួននៃការប្រព្រឹត្តចុងក្រោយ?

លទ្ធផល​បាន​ក្លាយ​ជា​ល្អ​ប្រសើរ​ជាង​មុន ប៉ុន្តែ​នៅ​ឆ្ងាយ​ពី​ឧត្តមគតិ​នៅឡើយ។ យ៉ាងណាមិញ យើងនៅតែមានអ្នកអភិវឌ្ឍន៍ដែលត្រូវការរូបភាពនៅក្នុងបញ្ជីឈ្មោះ (ឬសូម្បីតែត្រូវបានដាក់ឱ្យប្រើប្រាស់ក្នុង K8s) ដើម្បីបំបាត់កំហុស...

ដើម្បីសង្ខេបស្ថានភាពទីផ្សារបច្ចុប្បន្ន៖ មុខងារដែលមាននៅក្នុងការចុះបញ្ជីកុងតឺន័រមិនផ្តល់ភាពបត់បែនគ្រប់គ្រាន់នៅពេលសម្អាតទេ ហើយមូលហេតុចម្បងសម្រាប់បញ្ហានេះគឺ គ្មានមធ្យោបាយទាក់ទងជាមួយពិភពខាងក្រៅទេ។. វាបង្ហាញថាក្រុមដែលត្រូវការភាពបត់បែនបែបនេះត្រូវបានបង្ខំឱ្យអនុវត្តការលុបរូបភាពដោយឯករាជ្យ "ពីខាងក្រៅ" ដោយប្រើ Docker Registry API (ឬ API ដើមនៃការអនុវត្តដែលត្រូវគ្នា) ។

ទោះជាយ៉ាងណាក៏ដោយ ពួកយើងកំពុងស្វែងរកដំណោះស្រាយជាសកល ដែលនឹងធ្វើឱ្យការសម្អាតរូបភាពដោយស្វ័យប្រវត្តិសម្រាប់ក្រុមផ្សេងៗគ្នាដោយប្រើការចុះឈ្មោះផ្សេងៗគ្នា...

ផ្លូវរបស់យើងទៅកាន់ការសម្អាតរូបភាពជាសកល

តើតម្រូវការនេះមកពីណា? ការពិតគឺថា យើងមិនមែនជាក្រុមអ្នកអភិវឌ្ឍន៍ដាច់ដោយឡែកនោះទេ ប៉ុន្តែជាក្រុមដែលបម្រើពួកគេជាច្រើនក្នុងពេលតែមួយ ដោយជួយដោះស្រាយបញ្ហា CI/CD យ៉ាងទូលំទូលាយ។ ហើយឧបករណ៍បច្ចេកទេសសំខាន់សម្រាប់នេះគឺឧបករណ៍ប្រើប្រាស់ប្រភពបើកចំហ werf. ភាពពិសេសរបស់វាគឺថាវាមិនដំណើរការមុខងារតែមួយទេ ប៉ុន្តែភ្ជាប់ជាមួយដំណើរការចែកចាយបន្តនៅគ្រប់ដំណាក់កាលទាំងអស់៖ ពីការជួបប្រជុំគ្នារហូតដល់ការដាក់ពង្រាយ។

ការបោះពុម្ពរូបភាពទៅបញ្ជីឈ្មោះ* (ភ្លាមៗបន្ទាប់ពីពួកវាត្រូវបានសាងសង់) គឺជាមុខងារជាក់ស្តែងនៃឧបករណ៍ប្រើប្រាស់បែបនេះ។ ហើយចាប់តាំងពីរូបភាពត្រូវបានដាក់នៅទីនោះសម្រាប់ការផ្ទុកបន្ទាប់មក - ប្រសិនបើការផ្ទុករបស់អ្នកមិនមានដែនកំណត់ - អ្នកត្រូវទទួលខុសត្រូវចំពោះការសម្អាតជាបន្តបន្ទាប់របស់ពួកគេ។ របៀបដែលយើងសម្រេចបានជោគជ័យក្នុងរឿងនេះ ដោយបំពេញតាមលក្ខណៈវិនិច្ឆ័យដែលបានបញ្ជាក់ទាំងអស់ នឹងត្រូវបានពិភាក្សាបន្ថែមទៀត។

* ទោះបីជាការចុះបញ្ជីខ្លួនឯងអាចខុសគ្នា (Docker Registry, GitLab Container Registry, Harbor ។ល។) អ្នកប្រើប្រាស់របស់ពួកគេប្រឈមនឹងបញ្ហាដូចគ្នា។ ដំណោះស្រាយជាសកលនៅក្នុងករណីរបស់យើងមិនអាស្រ័យលើការអនុវត្តនៃការចុះបញ្ជីនោះទេព្រោះ ដំណើរការនៅខាងក្រៅបញ្ជីឈ្មោះខ្លួនឯង និងផ្តល់នូវអាកប្បកិរិយាដូចគ្នាសម្រាប់មនុស្សគ្រប់គ្នា។

ទោះបីជាយើងកំពុងប្រើ werf ជាការអនុវត្តឧទាហរណ៍ក៏ដោយ យើងសង្ឃឹមថាវិធីសាស្រ្តដែលបានប្រើនឹងមានប្រយោជន៍សម្រាប់ក្រុមផ្សេងទៀតដែលជួបប្រទះនឹងការលំបាកស្រដៀងគ្នានេះ។

ដូច្នេះ​យើង​រវល់ ខាងក្រៅ ការអនុវត្តយន្តការសម្រាប់ការសម្អាតរូបភាព - ជំនួសឱ្យសមត្ថភាពទាំងនោះដែលត្រូវបានបង្កើតឡើងរួចហើយនៅក្នុងបញ្ជីឈ្មោះសម្រាប់ធុង។ ជំហានដំបូងគឺត្រូវប្រើ Docker Registry API ដើម្បីបង្កើតគោលការណ៍បឋមដូចគ្នាសម្រាប់ចំនួនស្លាក និងពេលវេលានៃការបង្កើតរបស់ពួកគេ (ដែលបានរៀបរាប់ខាងលើ)។ បានបន្ថែមទៅពួកគេ។ អនុញ្ញាតបញ្ជីដោយផ្អែកលើរូបភាពដែលបានប្រើនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធដែលបានដាក់ពង្រាយ, i.e. Kubernetes ។ សម្រាប់ពេលក្រោយ វាគ្រប់គ្រាន់ក្នុងការប្រើ Kubernetes API ដើម្បីធ្វើឡើងវិញតាមរយៈធនធានដែលបានដាក់ពង្រាយទាំងអស់ និងទទួលបានបញ្ជីតម្លៃ image.

ដំណោះស្រាយដ៏កម្រនេះបានដោះស្រាយបញ្ហាសំខាន់បំផុត (លក្ខណៈវិនិច្ឆ័យលេខ 1) ប៉ុន្តែគ្រាន់តែជាការចាប់ផ្តើមនៃការធ្វើដំណើររបស់យើងដើម្បីកែលម្អយន្តការសម្អាត។ ជំហានបន្ទាប់ - និងគួរឱ្យចាប់អារម្មណ៍ជាងនេះ - ជំហានគឺការសម្រេចចិត្ត ភ្ជាប់រូបភាពដែលបានបោះពុម្ពផ្សាយជាមួយប្រវត្តិ Git.

គ្រោងការណ៍ដាក់ស្លាក

ដើម្បីចាប់ផ្តើម យើងបានជ្រើសរើសវិធីសាស្រ្តមួយដែលរូបភាពចុងក្រោយគួរតែរក្សាទុកព័ត៌មានចាំបាច់សម្រាប់ការសម្អាត និងបង្កើតដំណើរការលើគ្រោងការណ៍ដាក់ស្លាក។ នៅពេលបោះពុម្ពរូបភាព អ្នកប្រើប្រាស់បានជ្រើសរើសជម្រើសដាក់ស្លាកជាក់លាក់មួយ (git-branch, git-commit ឬ git-tag) ហើយបានប្រើតម្លៃដែលត្រូវគ្នា។ នៅក្នុងប្រព័ន្ធ CI តម្លៃទាំងនេះត្រូវបានកំណត់ដោយស្វ័យប្រវត្តិដោយផ្អែកលើអថេរបរិស្ថាន។ តាមពិតទៅ រូបភាពចុងក្រោយត្រូវបានភ្ជាប់ជាមួយ Git primitive ជាក់លាក់រក្សាទុកទិន្នន័យចាំបាច់សម្រាប់ការសម្អាតនៅក្នុងស្លាក។

វិធីសាស្រ្តនេះបានបណ្តាលឱ្យមានសំណុំនៃគោលនយោបាយដែលអនុញ្ញាតឱ្យ Git ត្រូវបានប្រើជាប្រភពតែមួយនៃការពិត:

• នៅពេលលុបសាខា/ស្លាកនៅក្នុង Git រូបភាពដែលពាក់ព័ន្ធនៅក្នុងបញ្ជីឈ្មោះត្រូវបានលុបដោយស្វ័យប្រវត្តិ។
• ចំនួនរូបភាពដែលភ្ជាប់ជាមួយស្លាក Git និងការប្តេជ្ញាចិត្តអាចត្រូវបានគ្រប់គ្រងដោយចំនួនស្លាកដែលបានប្រើនៅក្នុងគ្រោងការណ៍ដែលបានជ្រើសរើស និងពេលវេលាដែលការប្តេជ្ញាចិត្តដែលពាក់ព័ន្ធត្រូវបានបង្កើតឡើង។

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

ក្បួនដោះស្រាយថ្មី។

ហេតុអ្វី? ជាមួយនឹងការដាក់ស្លាកផ្អែកលើមាតិកា ស្លាកនីមួយៗអាចបំពេញការប្តេជ្ញាចិត្តជាច្រើននៅក្នុង Git ។ នៅពេលសម្អាតរូបភាព អ្នកមិនអាចសន្មត់បានទៀតទេ តែ ពីការប្តេជ្ញាដែលស្លាកថ្មីត្រូវបានបន្ថែមទៅបញ្ជីឈ្មោះ។

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

• ការប្តេជ្ញាចិត្តដែលការបោះពុម្ពត្រូវបានអនុវត្ត (វាមិនមានបញ្ហាថាតើរូបភាពត្រូវបានបន្ថែម ផ្លាស់ប្តូរ ឬនៅដដែលក្នុងបញ្ជីឈ្មោះកុងតឺន័រ) ។
• និងឧបករណ៍កំណត់អត្តសញ្ញាណខាងក្នុងរបស់យើងដែលត្រូវគ្នានឹងរូបភាពដែលបានជួបប្រជុំគ្នា។

នៅក្នុងពាក្យផ្សេងទៀតវាត្រូវបានផ្តល់ឱ្យ ភ្ជាប់ស្លាកដែលបានបោះពុម្ពផ្សាយជាមួយនឹងការសន្យានៅក្នុង Git.

ការកំណត់រចនាសម្ព័ន្ធចុងក្រោយ និងក្បួនដោះស្រាយទូទៅ

នៅពេលកំណត់រចនាសម្ព័ន្ធការសម្អាត អ្នកប្រើប្រាស់អាចចូលប្រើគោលការណ៍ដែលជ្រើសរើសរូបភាពបច្ចុប្បន្ន។ គោលការណ៍នីមួយៗត្រូវបានកំណត់៖

• ឯកសារយោងជាច្រើន, i.e. ស្លាក Git ឬសាខា Git ដែលត្រូវបានប្រើកំឡុងពេលស្កេន។
• និងដែនកំណត់នៃរូបភាពដែលបានស្វែងរកសម្រាប់ឯកសារយោងនីមួយៗពីសំណុំ។

ដើម្បីបង្ហាញ នេះជាអ្វីដែលការកំណត់រចនាសម្ព័ន្ធគោលការណ៍លំនាំដើមបានចាប់ផ្តើមមើលទៅដូច៖

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ការកំណត់រចនាសម្ព័ន្ធនេះមានគោលការណ៍បីដែលអនុលោមតាមវិធានខាងក្រោម៖

1. រក្សាទុករូបភាពសម្រាប់ស្លាក Git ចុងក្រោយចំនួន 10 (តាមកាលបរិច្ឆេទបង្កើតស្លាក) ។
2. រក្សាទុករូបភាពមិនលើសពី 2 ដែលត្រូវបានបោះពុម្ពក្នុងសប្តាហ៍ចុងក្រោយសម្រាប់មិនលើសពី 10 ខ្សែដែលមានសកម្មភាពក្នុងសប្តាហ៍ចុងក្រោយ។
3. រក្សាទុករូបភាពចំនួន 10 សម្រាប់សាខា main, staging и production.

ក្បួនដោះស្រាយចុងក្រោយដំណើរការទៅជំហានដូចខាងក្រោមៈ

• ការទាញយក manifests ពីការចុះបញ្ជីកុងតឺន័រ។
• មិនរាប់បញ្ចូលរូបភាពដែលប្រើក្នុង Kubernetes ទេ ព្រោះ យើងបានជ្រើសរើសពួកវាជាមុនរួចហើយដោយការស្ទង់មតិ K8s API។
• ការស្កេនប្រវត្តិ Git និងការមិនរាប់បញ្ចូលរូបភាពដោយផ្អែកលើគោលការណ៍ដែលបានបញ្ជាក់។
• ការលុបរូបភាពដែលនៅសល់។

ត្រលប់ទៅការប្រៀបធៀបរបស់យើង នេះជាអ្វីដែលកើតឡើងជាមួយ werf៖

ទោះយ៉ាងណាក៏ដោយ ទោះបីជាអ្នកមិនប្រើ werf ក៏ដោយ វិធីសាស្រ្តស្រដៀងគ្នាទៅនឹងការសម្អាតរូបភាពកម្រិតខ្ពស់ - នៅក្នុងការអនុវត្តមួយ ឬមួយផ្សេងទៀត (យោងទៅតាមវិធីសាស្រ្តដែលពេញចិត្តចំពោះការដាក់ស្លាករូបភាព) - អាចត្រូវបានអនុវត្តទៅប្រព័ន្ធ/ឧបករណ៍ប្រើប្រាស់ផ្សេងទៀត។ ដើម្បីធ្វើដូចនេះវាគ្រប់គ្រាន់ហើយក្នុងការចងចាំបញ្ហាដែលកើតឡើងហើយស្វែងរកឱកាសទាំងនោះនៅក្នុងជង់របស់អ្នកដែលអនុញ្ញាតឱ្យអ្នកបញ្ចូលដំណោះស្រាយរបស់ពួកគេឱ្យរលូនតាមដែលអាចធ្វើទៅបាន។ យើងសង្ឃឹមថាផ្លូវដែលយើងបានធ្វើដំណើរនឹងជួយអ្នកមើលករណីជាក់លាក់របស់អ្នកជាមួយនឹងព័ត៌មានលម្អិត និងគំនិតថ្មីៗ។

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

• មិនយូរមិនឆាប់ ក្រុមភាគច្រើនជួបប្រទះបញ្ហានៃការលើសចំណុះ។
• នៅពេលស្វែងរកដំណោះស្រាយជាដំបូងចាំបាច់ត្រូវកំណត់លក្ខណៈវិនិច្ឆ័យសម្រាប់ភាពពាក់ព័ន្ធនៃរូបភាព។
• ឧបករណ៍ដែលផ្តល់ដោយសេវាកម្មចុះបញ្ជីកុងតឺន័រដ៏ពេញនិយមអនុញ្ញាតឱ្យអ្នករៀបចំការសម្អាតដ៏សាមញ្ញបំផុតដែលមិនគិតពី "ពិភពខាងក្រៅ"៖ រូបភាពដែលបានប្រើនៅក្នុង Kubernetes និងលក្ខណៈពិសេសនៃដំណើរការការងាររបស់ក្រុម។
• ក្បួនដោះស្រាយដែលអាចបត់បែនបាន និងមានប្រសិទ្ធភាពត្រូវតែមានការយល់ដឹងអំពីដំណើរការ CI/CD និងដំណើរការមិនត្រឹមតែជាមួយទិន្នន័យរូបភាព Docker ប៉ុណ្ណោះទេ។

PS

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

• «ការ​ដាក់​ស្លាក​ផ្អែកលើ​ខ្លឹមសារ​ក្នុង​កម្មវិធី​បង្កើត werf៖ ហេតុអ្វី និង​របៀប​ដែល​វា​ដំណើរការ?»
• «ការរួមបញ្ចូលគ្នា 3 ផ្លូវទៅ werf: ការដាក់ពង្រាយ Kubernetes ជាមួយ Helm "នៅលើ steroids"»
• «ការគាំទ្រសម្រាប់ monorepo និង multirepo នៅក្នុង werf និងអ្វីដែល Docker Registry ត្រូវធ្វើជាមួយវា។»
• «ការចេញផ្សាយ werf 1.1៖ ការកែលម្អដល់អ្នកសាងសង់ថ្ងៃនេះ និងផែនការសម្រាប់អនាគត"។

ប្រភព: www.habr.com