ការគាំទ្រសម្រាប់ monorepo និង multirepo នៅក្នុង werf និងអ្វីដែល Docker Registry ត្រូវធ្វើជាមួយវា។

ប្រធានបទនៃឃ្លាំង mono-repository ត្រូវបានពិភាក្សាច្រើនជាងម្តង ហើយជាក្បួនបណ្តាលឱ្យមានភាពចម្រូងចម្រាសយ៉ាងសកម្ម។ ដោយការបង្កើត werf ជាឧបករណ៍ប្រភពបើកចំហដែលត្រូវបានរចនាឡើងដើម្បីកែលម្អដំណើរការបង្កើតកូដកម្មវិធីពីរូបភាព Git ទៅ Docker (ហើយបន្ទាប់មកបញ្ជូនវាទៅ Kubernetes) យើងមិនគិតច្រើនអំពីជម្រើសណាមួយដែលល្អបំផុតនោះទេ។ សម្រាប់ពួកយើង វាជាចម្បងក្នុងការផ្តល់នូវអ្វីគ្រប់យ៉ាងដែលចាំបាច់សម្រាប់អ្នកគាំទ្រនៃមតិផ្សេងគ្នា (ប្រសិនបើរឿងនេះមិនផ្ទុយនឹងសុភវិនិច្ឆ័យទេ)។

ការគាំទ្រ mono-repo ថ្មីៗនេះរបស់ werf គឺជាឧទាហរណ៍ដ៏ល្អនៃរឿងនេះ។ ប៉ុន្តែជាដំបូង ចូរយើងស្វែងយល់ពីរបៀបដែលការគាំទ្រនេះជាទូទៅទាក់ទងនឹងការប្រើប្រាស់ werf និងអ្វីដែល Docker Registry មានទំនាក់ទំនងជាមួយវា...

បញ្ហា

ចូរយើងស្រមៃមើលស្ថានភាពបែបនេះ។ ក្រុមហ៊ុនមានក្រុមអភិវឌ្ឍន៍ជាច្រើនដែលធ្វើការលើគម្រោងឯករាជ្យ។ កម្មវិធីភាគច្រើនដំណើរការលើ Kubernetes ដូច្នេះហើយត្រូវបានផ្ទុក។ ដើម្បីរក្សាទុកធុងរូបភាពអ្នកត្រូវការបញ្ជីឈ្មោះ (បញ្ជីឈ្មោះ) ។ ក្នុងនាមជាការចុះបញ្ជីបែបនេះ ក្រុមហ៊ុនប្រើប្រាស់ Docker Hub ជាមួយនឹងគណនីតែមួយ COMPANY. ស្រដៀងគ្នាទៅនឹងប្រព័ន្ធផ្ទុកកូដប្រភពភាគច្រើន Docker Hub មិនអនុញ្ញាតឱ្យមានឋានានុក្រមឃ្លាំងសម្ងាត់ទេ។, ដូចជា COMPANY/PROJECT/IMAGE. ក្នុងករណីនោះ… តើអ្នកអាចរក្សាទុកកម្មវិធីដែលមិនមែនជា monolithic នៅក្នុងបញ្ជីឈ្មោះដោយការកំណត់នេះដោយរបៀបណាដោយមិនបង្កើតគណនីដាច់ដោយឡែកសម្រាប់គម្រោងនីមួយៗ?

ប្រហែលជាស្ថានភាពដែលបានពិពណ៌នាគឺស៊ាំនឹងនរណាម្នាក់ដោយផ្ទាល់ ប៉ុន្តែសូមពិចារណាពីបញ្ហានៃការរៀបចំការផ្ទុកកម្មវិធីជាទូទៅ ពោលគឺឧ។ ដោយមិនយោងទៅលើឧទាហរណ៍ខាងលើ និង Docker Hub ។

ដំណោះស្រាយ

ប្រសិនបើកម្មវិធី monolithicមកក្នុងរូបភាពមួយ បន្ទាប់មកមិនមានសំណួរអ្វីទេ ហើយយើងគ្រាន់តែរក្សាទុករូបភាពទៅក្នុងបញ្ជីឈ្មោះកុងតឺន័ររបស់គម្រោង។

នៅពេលដែលកម្មវិធីត្រូវបានបង្ហាញជាសមាសធាតុជាច្រើន សេវាមីក្រូបន្ទាប់មកវិធីសាស្រ្តជាក់លាក់មួយត្រូវបានទាមទារ។ នៅលើឧទាហរណ៍នៃកម្មវិធីបណ្ដាញធម្មតាដែលមានរូបភាពពីរ៖ frontend и backend - ជម្រើសដែលអាចធ្វើបានគឺ៖

1. រក្សាទុករូបភាពនៅក្នុងឃ្លាំងសម្ងាត់ដាច់ដោយឡែក៖

   

2. រក្សាទុកអ្វីគ្រប់យ៉ាងនៅក្នុងឃ្លាំងមួយ ហើយពិចារណាឈ្មោះរូបភាពក្នុងស្លាក ឧទាហរណ៍ដូចខាងក្រោម៖

   

NB៖ តាមពិតទៅ មានជម្រើសមួយផ្សេងទៀតជាមួយការរក្សាទុកក្នុងឃ្លាំងផ្សេងៗគ្នា។ PROJECT-frontend и PROJECT-backendប៉ុន្តែយើងនឹងមិនពិចារណាវាទេ ដោយសារតែភាពស្មុគស្មាញនៃការគាំទ្រ ការរៀបចំ និងការចែកចាយសិទ្ធិរវាងអ្នកប្រើប្រាស់។

ការគាំទ្រ werf

ដំបូងឡើយ werf បានកំណត់ខ្លួនវាទៅឃ្លាំងសម្ងាត់ - ជាសំណាងល្អ បញ្ជីឈ្មោះភាគច្រើនគាំទ្រមុខងារនេះ។ ចាប់ផ្តើមពីកំណែ v1.0.4-alpha.3បន្ថែមការងារជាមួយការចុះបញ្ជីដែលក្នុងនោះ សំបុកមិនត្រូវបានគាំទ្រទេ។ហើយ Docker Hub គឺជាផ្នែកមួយនៃពួកគេ។ ចាប់ពីចំណុចនោះមក អ្នកប្រើប្រាស់មានជម្រើសនៃរបៀបរក្សាទុករូបភាពកម្មវិធី។

ការអនុវត្តមាននៅក្រោមជម្រើស --images-repo-mode=multirepo|monorepo (លំនាំដើម multirepo, i.e. ការផ្ទុកនៅក្នុងឃ្លាំងសម្ងាត់) ។ វាកំណត់លំនាំដែលរូបភាពត្រូវបានរក្សាទុកក្នុងបញ្ជីឈ្មោះ។ វាគ្រប់គ្រាន់ក្នុងការជ្រើសរើសរបៀបដែលចង់បាននៅពេលប្រើពាក្យបញ្ជាមូលដ្ឋាន ហើយអ្វីៗផ្សេងទៀតនឹងនៅតែមិនផ្លាស់ប្តូរ។

ដោយសារតែជម្រើស werf ភាគច្រើនអាចត្រូវបានកំណត់ អថេរ​បរិស្ថាននៅក្នុងប្រព័ន្ធ CI/CD ជាធម្មតា របៀបផ្ទុកគឺងាយស្រួលក្នុងការកំណត់ជាសកលសម្រាប់គម្រោងទាំងមូល។ ឧទាហរណ៍, ក្នុងករណី GitLab គ្រាន់តែបន្ថែមអថេរបរិស្ថាននៅក្នុងការកំណត់គម្រោង៖ ការកំណត់ -> CI / CD -> អថេរ៖ WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

អារក្សស្ថិតនៅក្នុងព័ត៌មានលម្អិត

ភាពខុសគ្នានិងការលំបាកចម្បងនៅពេលបន្ថែមវិធីសាស្ត្រផ្ទុកថ្មីគឺស្ថិតនៅក្នុងដំណើរការនៃការសម្អាតបញ្ជីឈ្មោះ (សម្រាប់មុខងារសម្អាតដែលគាំទ្រដោយ werf សូមមើល ដំណើរការសំអាត).

នៅពេលសម្អាត werf គិតគូរអំពីរូបភាពដែលបានប្រើនៅក្នុងចង្កោម Kubernetes ក៏ដូចជាគោលការណ៍ដែលបានកំណត់រចនាសម្ព័ន្ធដោយអ្នកប្រើប្រាស់។ គោលការណ៍គឺផ្អែកលើការបែងចែកស្លាកទៅជាយុទ្ធសាស្ត្រ។ យុទ្ធសាស្រ្តដែលគាំទ្របច្ចុប្បន្ន៖

1. យុទ្ធសាស្រ្ត 3 ដែលភ្ជាប់ដោយ Git primitives ដូចជា tag, branch, and commit;
2. យុទ្ធសាស្ត្រ 1 សម្រាប់ស្លាកផ្ទាល់ខ្លួនតាមអំពើចិត្ត។

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

នៅពេលរក្សាទុកក្នុងឃ្លាំងមួយ (monorepo) នៅក្នុងស្លាករូបភាព បន្ថែមពីលើស្លាកមេតា ឈ្មោះរូបភាពក៏អាចត្រូវបានរក្សាទុកផងដែរ៖ PROJECT:frontend-META-TAG. ដើម្បីបំបែកពួកវា យើងមិនបានណែនាំសញ្ញាបំបែកជាក់លាក់ណាមួយទេ ប៉ុន្តែគ្រាន់តែបន្ថែមតម្លៃចាំបាច់ទៅស្លាកនៃរូបភាពចុងក្រោយនៅពេលបោះពុម្ព។

NB៖ ប្រសិនបើអ្នកចាប់អារម្មណ៍ក្នុងការមើលអ្វីគ្រប់យ៉ាងដែលបានពិពណ៌នានៅក្នុងកូដប្រភព werf នោះចំណុចចាប់ផ្តើមអាចជា ការិយាល័យទទួលជំនួយផ្ទាល់ 1684.

នៅក្នុងអត្ថបទនេះ យើងនឹងមិនយកចិត្តទុកដាក់បន្ថែមទៀតចំពោះបញ្ហា និងយុត្តិកម្មនៃវិធីសាស្រ្តរបស់យើងទេ៖ អំពីយុទ្ធសាស្ត្រដាក់ស្លាក ការរក្សាទុកទិន្នន័យក្នុងស្លាក និងដំណើរការបោះពុម្ពទាំងមូល - ទាំងអស់នេះត្រូវបានពិពណ៌នាលម្អិតនៅក្នុងរបាយការណ៍ថ្មីៗនេះដោយ Dmitry Stolyarov៖ "werf គឺជាឧបករណ៍របស់យើងសម្រាប់ CI/CD នៅក្នុង Kubernetes"។

សង្ខេប

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

ស្នាក់នៅជាមួយយើង ហើយឆាប់ៗនេះយើងនឹងប្រាប់អ្នកអំពីការច្នៃប្រឌិតផ្សេងទៀតនៅក្នុង werf!

PS

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

• «ឥឡូវនេះអ្នកអាចបង្កើតរូបភាព Docker នៅក្នុង werf ដោយប្រើ Dockerfile ធម្មតា។»
• «werf - ឧបករណ៍របស់យើងសម្រាប់ CI / CD នៅក្នុង Kubernetes (ទិដ្ឋភាពទូទៅ និងរបាយការណ៍វីដេអូ)"។

ប្រភព: www.habr.com