ការចេញផ្សាយ werf 1.1៖ ការកែលម្អដល់អ្នកសាងសង់ថ្ងៃនេះ និងផែនការសម្រាប់អនាគត

werf គឺជាឧបករណ៍ប្រើប្រាស់ GitOps CLI បើកចំហរបស់យើងសម្រាប់ការកសាង និងបញ្ជូនកម្មវិធីទៅ Kubernetes ។ ដូច​ដែល​បាន​សន្យា, ការចេញផ្សាយកំណែ v1.0 បានសម្គាល់ការចាប់ផ្តើមនៃការបន្ថែមលក្ខណៈពិសេសថ្មីទៅ werf និងពិនិត្យឡើងវិញនូវវិធីសាស្រ្តប្រពៃណី។ ឥឡូវនេះយើងរីករាយក្នុងការបង្ហាញការចេញផ្សាយ v1.1 ដែលជាជំហានដ៏ធំមួយក្នុងការអភិវឌ្ឍន៍ និងជាមូលដ្ឋានគ្រឹះសម្រាប់អនាគត អ្នកប្រមូល werf ។ កំណែបច្ចុប្បន្នមាននៅក្នុង ឆានែល 1.1 អ៊ី.

មូលដ្ឋាននៃការចេញផ្សាយគឺជាស្ថាបត្យកម្មថ្មីនៃការផ្ទុកដំណាក់កាល និងការបង្កើនប្រសិទ្ធភាពការងាររបស់អ្នកប្រមូលទាំងពីរ (សម្រាប់ Stapel និង Dockerfile) ។ ស្ថាបត្យកម្មការផ្ទុកថ្មីបើកលទ្ធភាពនៃការអនុវត្តការជួបប្រជុំគ្នាដែលបានចែកចាយពីម៉ាស៊ីនច្រើន និងសន្និបាតប៉ារ៉ាឡែលនៅលើម៉ាស៊ីនតែមួយ។

ការបង្កើនប្រសិទ្ធភាពការងាររួមមានការកម្ចាត់ការគណនាដែលមិនចាំបាច់នៅដំណាក់កាលនៃការគណនាហត្ថលេខាដំណាក់កាល និងការផ្លាស់ប្តូរយន្តការសម្រាប់ការគណនាការឆែកឆេរឯកសារទៅជាប្រសិទ្ធភាពជាងមុន។ ការបង្កើនប្រសិទ្ធភាពនេះកាត់បន្ថយពេលវេលាជាមធ្យមនៃការបង្កើតគម្រោងដោយប្រើ werf ។ ហើយ idle builds នៅពេលដែលដំណាក់កាលទាំងអស់មាននៅក្នុងឃ្លាំងសម្ងាត់ ដំណាក់កាល - ការផ្ទុកឥឡូវនេះពិតជាលឿនមែន។ ក្នុងករណីភាគច្រើន ការចាប់ផ្ដើមការស្ថាបនាឡើងវិញនឹងចំណាយពេលតិចជាង 1 វិនាទី! នេះក៏អនុវត្តចំពោះនីតិវិធីសម្រាប់ផ្ទៀងផ្ទាត់ដំណាក់កាលនៅក្នុងដំណើរការការងាររបស់ក្រុមផងដែរ។ werf deploy и werf run.

ផងដែរនៅក្នុងការចេញផ្សាយនេះ យុទ្ធសាស្រ្តសម្រាប់ការដាក់ស្លាករូបភាពតាមមាតិកាបានបង្ហាញខ្លួន - ការដាក់ស្លាកផ្អែកលើមាតិកាដែលឥឡូវនេះត្រូវបានបើកតាមលំនាំដើម និងតែមួយគត់ដែលបានណែនាំ។

សូមក្រឡេកមើលការច្នៃប្រឌិតសំខាន់ៗនៅក្នុង werf v1.1 ហើយនៅពេលជាមួយគ្នានេះប្រាប់អ្នកអំពីផែនការសម្រាប់អនាគត។

តើមានអ្វីផ្លាស់ប្តូរនៅក្នុង werf v1.1?

ទម្រង់នៃការដាក់ឈ្មោះដំណាក់កាលថ្មី និងក្បួនដោះស្រាយសម្រាប់ជ្រើសរើសដំណាក់កាលពីឃ្លាំងសម្ងាត់

ច្បាប់បង្កើតឈ្មោះដំណាក់កាលថ្មី។ ឥឡូវនេះការស្ថាបនាដំណាក់កាលនីមួយៗបង្កើតឈ្មោះដំណាក់កាលតែមួយគត់ដែលមាន 2 ផ្នែក៖ ហត្ថលេខា (ដូចនៅក្នុង v1.0) បូកនឹងឧបករណ៍កំណត់បណ្តោះអាសន្នតែមួយគត់។

ឧទាហរណ៍ ឈ្មោះរូបភាពពេញឆាកអាចមើលទៅដូចនេះ៖

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... ឬជាទូទៅ៖

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

នៅទីនេះ:

• SIGNATURE គឺ​ជា​ហត្ថលេខា​ដំណាក់កាល ដែល​តំណាង​ឱ្យ​អ្នក​កំណត់​អត្តសញ្ញាណ​នៃ​ខ្លឹមសារ​ដំណាក់កាល និង​អាស្រ័យ​លើ​ប្រវត្តិ​នៃ​ការ​កែសម្រួល​ក្នុង Git ដែល​នាំ​ឱ្យ​មាន​ខ្លឹមសារ​នេះ ។
• TIMESTAMP_MILLISEC គឺជាឧបករណ៍កំណត់អត្តសញ្ញាណរូបភាពតែមួយគត់ដែលត្រូវបានធានា ដែលត្រូវបានបង្កើតនៅពេលរូបភាពថ្មីត្រូវបានបង្កើតឡើង។

ក្បួនដោះស្រាយសម្រាប់ជ្រើសរើសដំណាក់កាលពីឃ្លាំងសម្ងាត់គឺផ្អែកលើការពិនិត្យមើលទំនាក់ទំនងរបស់ Git commits៖

1. Werf គណនាហត្ថលេខានៃដំណាក់កាលជាក់លាក់មួយ។
2. В ដំណាក់កាល - ការផ្ទុក វាអាចមានដំណាក់កាលជាច្រើនសម្រាប់ហត្ថលេខាដែលបានផ្តល់ឱ្យ។ Werf ជ្រើសរើសដំណាក់កាលទាំងអស់ដែលត្រូវនឹងហត្ថលេខា។
3. ប្រសិនបើដំណាក់កាលបច្ចុប្បន្នត្រូវបានភ្ជាប់ទៅ Git (git-archive ដំណាក់កាលផ្ទាល់ខ្លួនជាមួយនឹងបំណះ Git៖ install, beforeSetup, setup; ឬ git-latest-patch) បន្ទាប់មក werf ជ្រើសរើសតែដំណាក់កាលទាំងនោះដែលត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងការប្តេជ្ញាចិត្តដែលជាបុព្វបុរសនៃ commit បច្ចុប្បន្ន (ដែលការស្ថាបនាត្រូវបានគេហៅថា) ។
4. ពីដំណាក់កាលសមស្របដែលនៅសល់ មួយត្រូវបានជ្រើសរើស - ចាស់បំផុតតាមកាលបរិច្ឆេទបង្កើត។

ដំណាក់កាលសម្រាប់សាខា Git ផ្សេងគ្នាអាចមានហត្ថលេខាដូចគ្នា។ ប៉ុន្តែ werf នឹងរារាំងឃ្លាំងសម្ងាត់ដែលទាក់ទងនឹងសាខាផ្សេងៗពីការប្រើប្រាស់រវាងសាខាទាំងនេះ ទោះបីជាហត្ថលេខាត្រូវគ្នាក៏ដោយ។

→ ឯកសារ.

ក្បួនដោះស្រាយថ្មីសម្រាប់បង្កើត និងរក្សាទុកដំណាក់កាលនៅក្នុងការផ្ទុកដំណាក់កាល

ប្រសិនបើនៅពេលជ្រើសរើសដំណាក់កាលពីឃ្លាំងសម្ងាត់ werf រកមិនឃើញដំណាក់កាលដែលសមរម្យនោះដំណើរការនៃការប្រមូលផ្តុំដំណាក់កាលថ្មីមួយត្រូវបានផ្តួចផ្តើម។

ចំណាំថាដំណើរការជាច្រើន (នៅលើម៉ាស៊ីនមួយ ឬច្រើន) អាចចាប់ផ្តើមបង្កើតដំណាក់កាលដូចគ្នានៅពេលដូចគ្នានេះ។ Werf ប្រើក្បួនដោះស្រាយការទប់ស្កាត់សុទិដ្ឋិនិយម ដំណាក់កាល - ការផ្ទុក នៅពេលរក្សាទុករូបភាពដែលទើបប្រមូលបានថ្មីៗ ដំណាក់កាល - ការផ្ទុក. វិធីនេះ នៅពេលដែលការកសាងដំណាក់កាលថ្មីរួចរាល់ ប្លុក werf ដំណាក់កាល - ការផ្ទុក ហើយរក្សាទុករូបភាពដែលបានប្រមូលថ្មីៗនៅទីនោះ លុះត្រាតែរូបភាពដែលសមរម្យលែងមាននៅទីនោះ (ដោយហត្ថលេខានិងប៉ារ៉ាម៉ែត្រផ្សេងទៀត - សូមមើលក្បួនដោះស្រាយថ្មីសម្រាប់ជ្រើសរើសដំណាក់កាលពីឃ្លាំងសម្ងាត់).

រូបភាពដែលបានជួបប្រជុំគ្នាថ្មីៗត្រូវបានធានាថាមានឧបករណ៍កំណត់អត្តសញ្ញាណតែមួយគត់ដោយ TIMESTAMP_MILLISEC (សូមមើលទម្រង់ដាក់ឈ្មោះដំណាក់កាលថ្មី). ក្នុងករណីនៅក្នុង ដំណាក់កាល - ការផ្ទុក រូបភាពសមរម្យនឹងត្រូវបានរកឃើញ werf នឹងបោះបង់រូបភាពដែលបានចងក្រងថ្មីៗ ហើយនឹងប្រើរូបភាពពីឃ្លាំងសម្ងាត់។

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

→ ឯកសារ.

ធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្តកម្មវិធីបង្កើត Dockerfile

នៅពេលនេះបំពង់នៃដំណាក់កាលសម្រាប់រូបភាពដែលបានសាងសង់ពី Dockerfile មានដំណាក់កាលមួយ - dockerfile. នៅពេលគណនាហត្ថលេខា មូលប្បទានប័ត្រនៃឯកសារត្រូវបានគណនា contextដែលនឹងត្រូវបានប្រើកំឡុងពេលដំឡើង។ មុនពេលការកែលម្អនេះ werf បានដំណើរការឡើងវិញនូវឯកសារទាំងអស់ ហើយទទួលបានការពិនិត្យដោយបូកសរុបបរិបទ និងរបៀបនៃឯកសារនីមួយៗ។ ចាប់ផ្តើមជាមួយ v1.1 werf អាចប្រើ checksums ដែលបានគណនាទុកក្នុងឃ្លាំង Git ។

ក្បួនដោះស្រាយគឺផ្អែកលើ git ls-tree. ក្បួនដោះស្រាយយកទៅក្នុងគណនីកត់ត្រាក្នុង .dockerignore ហើយឆ្លងកាត់មែកធាងឯកសារឡើងវិញនៅពេលចាំបាច់។ ដូច្នេះ យើងបានបំបែកពីការអានប្រព័ន្ធឯកសារ និងការពឹងផ្អែកនៃក្បួនដោះស្រាយលើទំហំ context មិនសំខាន់ទេ។

ក្បួនដោះស្រាយក៏ពិនិត្យឯកសារដែលមិនបានតាមដាន ហើយប្រសិនបើចាំបាច់ យកពួកវាទៅក្នុងគណនីនៅក្នុងមូលប្បទានប័ត្រ។

ដំណើរការប្រសើរឡើងនៅពេលនាំចូលឯកសារ

កំណែរបស់ werf v1.1 ប្រើម៉ាស៊ីនមេ rsync នៅពេល នាំចូលឯកសារពីវត្ថុបុរាណ និងរូបភាព. ពីមុន ការនាំចូលត្រូវបានធ្វើជាពីរជំហានដោយប្រើថតឯកសារពីប្រព័ន្ធម៉ាស៊ីន។

ដំណើរការនាំចូលនៅលើ macOS មិនត្រូវបានកំនត់ដោយបរិមាណ Docker ទៀតទេ ហើយការនាំចូលបានបញ្ចប់ក្នុងចំនួនពេលវេលាដូចគ្នាជាមួយ Linux និង Windows។

ការដាក់ស្លាកផ្អែកលើខ្លឹមសារ

Werf v1.1 គាំទ្រអ្វីដែលហៅថាការដាក់ស្លាកដោយមាតិការូបភាព - ការដាក់ស្លាកផ្អែកលើមាតិកា. ស្លាកនៃរូបភាព Docker លទ្ធផលអាស្រ័យលើមាតិកានៃរូបភាពទាំងនេះ។

នៅពេលដំណើរការពាក្យបញ្ជា werf publish --tags-by-stages-signature ឬ werf ci-env --tagging-strategy=stages-signature រូបភាពដែលបានចេញផ្សាយនៃអ្វីដែលគេហៅថា ហត្ថលេខាលើឆាក រូបភាព។ រូបភាពនីមួយៗត្រូវបានដាក់ស្លាកដោយហត្ថលេខាផ្ទាល់ខ្លួននៃដំណាក់កាលនៃរូបភាពនេះ ដែលត្រូវបានគណនាដោយយោងទៅតាមច្បាប់ដូចគ្នានឹងហត្ថលេខាធម្មតានៃដំណាក់កាលនីមួយៗដាច់ដោយឡែកពីគ្នា ប៉ុន្តែជាសញ្ញាសម្គាល់ទូទៅនៃរូបភាព។

ហត្ថលេខានៃដំណាក់កាលរូបភាពអាស្រ័យលើ៖

1. មាតិកានៃរូបភាពនេះ;
2. ប្រវត្តិនៃការផ្លាស់ប្តូរ Git ដែលនាំទៅដល់ខ្លឹមសារនេះ។

ឃ្លាំង Git តែងតែមានការប្តេជ្ញាចិត្តមិនផ្លាស់ប្តូរដែលមិនផ្លាស់ប្តូរមាតិកានៃឯកសាររូបភាព។ ឧទាហរណ៍ ប្រព្រឹត្តដោយតែមតិយោបល់ ឬការប្តេជ្ញាចិត្តបញ្ចូលគ្នា ឬប្តេជ្ញាផ្លាស់ប្តូរឯកសារទាំងនោះនៅក្នុង Git ដែលនឹងមិនត្រូវបាននាំចូលទៅក្នុងរូបភាព។

នៅពេលប្រើការដាក់ស្លាកផ្អែកលើខ្លឹមសារ បញ្ហានៃការចាប់ផ្តើមឡើងវិញដែលមិនចាំបាច់នៃផតកម្មវិធីនៅក្នុង Kubernetes ដោយសារតែការផ្លាស់ប្តូរឈ្មោះរូបភាពត្រូវបានដោះស្រាយ ទោះបីជាខ្លឹមសារនៃរូបភាពមិនបានផ្លាស់ប្តូរក៏ដោយ។ និយាយអីញ្ចឹង នេះជាហេតុផលមួយដែលរារាំងការរក្សាទុក microservices ជាច្រើននៃកម្មវិធីមួយនៅក្នុងឃ្លាំង Git តែមួយ។

ដូចគ្នានេះផងដែរ ការដាក់ស្លាកផ្អែកលើមាតិកាគឺជាវិធីសាស្ត្រដាក់ស្លាកដែលអាចទុកចិត្តបានជាងការដាក់ស្លាកនៅលើសាខា Git ពីព្រោះខ្លឹមសារនៃរូបភាពលទ្ធផលមិនអាស្រ័យលើលំដាប់ដែលបំពង់ត្រូវបានប្រតិបត្តិក្នុងប្រព័ន្ធ CI សម្រាប់ការប្រមូលផ្តុំការប្រព្រឹត្តិច្រើននៃសាខាតែមួយ។

សំខាន់៖ ចាប់​ពី​ពេល​នេះ​ទៅ ដំណាក់កាល - ហត្ថលេខា - នេះ​គឺជា យុទ្ធសាស្ត្រដាក់ស្លាកតែមួយគត់ដែលបានណែនាំ. វានឹងត្រូវបានប្រើតាមលំនាំដើមនៅក្នុងពាក្យបញ្ជា werf ci-env (លុះត្រាតែអ្នកបញ្ជាក់យ៉ាងច្បាស់នូវគ្រោងការណ៍នៃការដាក់ស្លាកផ្សេង)។

→ ឯកសារ. ការបោះពុម្ភផ្សាយដាច់ដោយឡែកក៏នឹងត្រូវបានឧទ្ទិសដល់មុខងារនេះផងដែរ។ បានធ្វើបច្ចុប្បន្នភាព (ថ្ងៃទី 3 ខែមេសា)៖ អត្ថបទដែលមានព័ត៌មានលម្អិត បានផ្សព្វផ្សាយ.

កម្រិតនៃការកត់ត្រា

ឥឡូវនេះអ្នកប្រើប្រាស់មានឱកាសគ្រប់គ្រងលទ្ធផល កំណត់កម្រិតនៃការកត់ត្រា និងធ្វើការជាមួយព័ត៌មានបំបាត់កំហុស។ ជម្រើសត្រូវបានបន្ថែម --log-quiet, --log-verbose, --log-debug.

តាមលំនាំដើម លទ្ធផលមានព័ត៌មានអប្បបរមា៖

នៅពេលប្រើលទ្ធផល verbose (--log-verbose) អ្នកអាចមើលឃើញពីរបៀបដែល werf ដំណើរការ:

ទិន្នផលលម្អិត (--log-debug) បន្ថែមពីលើព័ត៌មានបំបាត់កំហុស werf ក៏មានកំណត់ហេតុនៃបណ្ណាល័យដែលបានប្រើផងដែរ។ ឧទាហរណ៍ អ្នកអាចមើលឃើញពីរបៀបដែលអន្តរកម្មជាមួយ Docker Registry កើតឡើង ហើយកត់ត្រាផងដែរនូវកន្លែងដែលត្រូវចំណាយពេលវេលាយ៉ាងច្រើន៖

គំរោង​អនាគត

សូមប្រយ័ត្ន! ជម្រើសដែលបានពិពណ៌នាខាងក្រោមត្រូវបានសម្គាល់ v1.1 នឹងមាននៅក្នុងកំណែនេះ ភាគច្រើននៃពួកវានាពេលអនាគតដ៏ខ្លីខាងមុខនេះ។ ការអាប់ដេតនឹងមកតាមរយៈការធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិ នៅពេលប្រើ multiwerf. លក្ខណៈពិសេសទាំងនេះមិនប៉ះពាល់ដល់ផ្នែកស្ថេរភាពនៃមុខងារ v1.1 ទេ រូបរាងរបស់ពួកគេនឹងមិនតម្រូវឱ្យមានការអន្តរាគមន៍ពីអ្នកប្រើប្រាស់ដោយដៃក្នុងការកំណត់ដែលមានស្រាប់នោះទេ។

ការគាំទ្រពេញលេញសម្រាប់ការអនុវត្ត Docker Registry ផ្សេងៗ (ថ្មី)

• កំណែ៖ v1.1
• កាលបរិច្ឆេទ៖ ខែមីនា
• កិច្ចការ

គោលដៅគឺសម្រាប់អ្នកប្រើប្រាស់ដើម្បីប្រើប្រាស់ការអនុវត្តផ្ទាល់ខ្លួនដោយគ្មានការរឹតបន្តឹងនៅពេលប្រើ werf ។

បច្ចុប្បន្ននេះ យើងបានកំណត់នូវដំណោះស្រាយខាងក្រោម ដែលយើងនឹងធានានូវការគាំទ្រពេញលេញ៖

• លំនាំដើម (បណ្ណាល័យ/បញ្ជីឈ្មោះ)*,
• AWS ECR
• Azure *,
• មជ្ឈមណ្ឌល Docker
• GCR*,
• កញ្ចប់ GitHub
• ការចុះឈ្មោះ GitLab *,
• កំពង់ផែ*,
• ផ្លូវ។

ដំណោះស្រាយដែលបច្ចុប្បន្នត្រូវបានគាំទ្រយ៉ាងពេញលេញដោយ werf ត្រូវបានសម្គាល់ដោយសញ្ញាផ្កាយ។ សម្រាប់អ្នកផ្សេងទៀតមានការគាំទ្រ ប៉ុន្តែមានកម្រិត។

បញ្ហាចម្បងពីរអាចត្រូវបានសម្គាល់:

• ដំណោះស្រាយមួយចំនួនមិនគាំទ្រការដកស្លាកចេញដោយប្រើ Docker Registry API ដោយរារាំងអ្នកប្រើប្រាស់ពីការប្រើប្រាស់ការសម្អាតដោយស្វ័យប្រវត្តិរបស់ werf ។ នេះជាការពិតសម្រាប់ AWS ECR, Docker Hub និងកញ្ចប់ GitHub ។
• ដំណោះស្រាយមួយចំនួនមិនគាំទ្រអ្វីដែលគេហៅថា ឃ្លាំងសម្ងាត់ (Docker Hub, GitHub Packages និង Quay) ឬធ្វើ ប៉ុន្តែអ្នកប្រើប្រាស់ត្រូវតែបង្កើតពួកវាដោយដៃដោយប្រើ UI ឬ API (AWS ECR)។

យើងនឹងដោះស្រាយបញ្ហាទាំងនេះ និងបញ្ហាផ្សេងទៀតដោយប្រើ APIs ដើមនៃដំណោះស្រាយ។ កិច្ចការនេះក៏រួមបញ្ចូលទាំងការគ្របដណ្តប់វដ្តពេញលេញនៃប្រតិបត្តិការ werf ជាមួយនឹងការធ្វើតេស្តសម្រាប់ពួកគេម្នាក់ៗ។

ការបង្កើតរូបភាពចែកចាយ (↑)

• កំណែ៖ v1.2 v1.1 (អាទិភាពសម្រាប់ការអនុវត្តមុខងារនេះត្រូវបានបង្កើន)
• កាលបរិច្ឆេទ៖ ខែមីនា - មេសា មីនា
• កិច្ចការ

នៅពេលនេះ werf v1.0 និង v1.1 អាចប្រើបានតែលើម៉ាស៊ីនដែលខិតខំប្រឹងប្រែងតែមួយសម្រាប់ប្រតិបត្តិការនៃការសាងសង់ និងការបោះពុម្ពរូបភាព និងដាក់ពង្រាយកម្មវិធីទៅ Kubernetes ។

ដើម្បីបើកលទ្ធភាពនៃការងារចែកចាយរបស់ werf នៅពេលដែលការបង្កើត និងដាក់ឱ្យប្រើប្រាស់កម្មវិធីនៅក្នុង Kubernetes ត្រូវបានដាក់ឱ្យដំណើរការនៅលើម៉ាស៊ីនដែលបំពានជាច្រើន ហើយម៉ាស៊ីនទាំងនេះមិនរក្សាទុកស្ថានភាពរបស់ពួកគេរវាងការស្ថាបនា (អ្នករត់ការបណ្តោះអាសន្ន) werf តម្រូវឱ្យអនុវត្តសមត្ថភាពប្រើប្រាស់។ Docker Registry ជាហាងដំណាក់កាលមួយ។

កាលពីមុន នៅពេលដែលគម្រោង werf នៅតែត្រូវបានគេហៅថា dapp វាមានឱកាសបែបនេះ។ ទោះជាយ៉ាងណាក៏ដោយ យើងបានជួបប្រទះបញ្ហាមួយចំនួនដែលចាំបាច់ត្រូវយកមកពិចារណានៅពេលអនុវត្តមុខងារនេះនៅក្នុង werf ។

ការកត់សម្គាល់. មុខងារ​នេះ​មិន​តម្រូវ​ឱ្យ​អ្នក​ប្រមូល​ធ្វើការ​នៅ​ក្នុង​ផត Kubernetes ទេ ដោយសារ ដើម្បីធ្វើដូច្នេះ អ្នកត្រូវកម្ចាត់ការពឹងផ្អែកលើម៉ាស៊ីនមេ Docker មូលដ្ឋាន (នៅក្នុងផ្នែក Kubernetes មិនមានការចូលប្រើម៉ាស៊ីនមេ Docker មូលដ្ឋានទេ ព្រោះដំណើរការខ្លួនវាកំពុងដំណើរការក្នុងកុងតឺន័រ ហើយ werf មិនគាំទ្រទេ។ ធ្វើការជាមួយម៉ាស៊ីនមេ Docker លើបណ្តាញ) ។ ការគាំទ្រសម្រាប់ដំណើរការ Kubernetes នឹងត្រូវបានអនុវត្តដោយឡែកពីគ្នា។

ការគាំទ្រជាផ្លូវការសម្រាប់សកម្មភាព GitHub (ថ្មី)

• កំណែ៖ v1.1
• កាលបរិច្ឆេទ៖ ខែមីនា
• កិច្ចការ

រួមបញ្ចូលឯកសារ werf (ផ្នែក ឯកសារយោង и នាំ​ផ្លូវ) ក៏ដូចជាសកម្មភាព GitHub ផ្លូវការសម្រាប់ធ្វើការជាមួយ werf ។

លើសពីនេះ វានឹងអនុញ្ញាតឱ្យ werf ធ្វើការលើអ្នករត់ដែលមានភាពច្របូកច្របល់។

មេកានិកនៃអន្តរកម្មរបស់អ្នកប្រើជាមួយប្រព័ន្ធ CI នឹងផ្អែកលើការដាក់ស្លាកនៅលើសំណើរទាញ ដើម្បីផ្តួចផ្តើមសកម្មភាពជាក់លាក់ក្នុងការសាងសង់/ដំណើរការកម្មវិធី។

ការអភិវឌ្ឍន៍ក្នុងតំបន់ និងការដាក់ឱ្យប្រើប្រាស់កម្មវិធីជាមួយ werf (↓)

• កំណែ៖ v1.1
• កាលបរិច្ឆេទ៖ ខែមករា - កុម្ភៈ មេសា
• កិច្ចការ

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

werf ក៏ត្រូវបានទាមទារផងដែរដើម្បីឱ្យមានរបៀបប្រតិបត្តិការដែលវានឹងងាយស្រួលក្នុងការកែសម្រួលកូដកម្មវិធី និងទទួលបានមតិកែលម្អភ្លាមៗពីកម្មវិធីដែលកំពុងដំណើរការសម្រាប់ការកែកំហុស។

ក្បួនដោះស្រាយការសម្អាតថ្មី (ថ្មី)

• កំណែ៖ v1.1
• កាលបរិច្ឆេទ៖ ខែមេសា
• កិច្ចការ

នៅក្នុងកំណែបច្ចុប្បន្ននៃ werf v1.1 នៅក្នុងនីតិវិធី cleanup មិនមានការផ្តល់សម្រាប់ការសម្អាតរូបភាពសម្រាប់គ្រោងការណ៍ការដាក់ស្លាកផ្អែកលើមាតិកាទេ - រូបភាពទាំងនេះនឹងកកកុញ។

ផងដែរ កំណែបច្ចុប្បន្ននៃ werf (v1.0 និង v1.1) ប្រើប្រាស់គោលការណ៍សម្អាតផ្សេងៗគ្នាសម្រាប់រូបភាពដែលបានបោះពុម្ពក្រោមគ្រោងការណ៍ដាក់ស្លាក៖ សាខា Git ស្លាក Git ឬ Git commit ។

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

• រក្សារូបភាព N1 មិនលើសពីដែលភ្ជាប់ជាមួយការប្តេជ្ញាចិត្តថ្មីបំផុត N2 សម្រាប់ git HEAD នីមួយៗ (សាខា និងស្លាក)។
• រក្សាទុករូបភាពដំណាក់កាល N1 មិនលើសពីដែលទាក់ទងនឹងការប្តេជ្ញាចិត្តថ្មីបំផុត N2 សម្រាប់ git HEAD នីមួយៗ (សាខា និងស្លាក)។
• រក្សាទុករូបភាពទាំងអស់ដែលត្រូវបានប្រើនៅក្នុងធនធានចង្កោម Kubernetes ណាមួយ (បរិបទ kube ទាំងអស់នៃឯកសារកំណត់រចនាសម្ព័ន្ធ និងចន្លោះឈ្មោះត្រូវបានស្កេន។ អ្នកអាចកំណត់ឥរិយាបថនេះជាមួយនឹងជម្រើសពិសេស)។
• រក្សាទុករូបភាពទាំងអស់ដែលត្រូវបានប្រើនៅក្នុងការបង្ហាញការកំណត់រចនាសម្ព័ន្ធធនធានដែលបានរក្សាទុកនៅក្នុងការចេញផ្សាយ Helm ។
• រូបភាពអាចត្រូវបានលុបប្រសិនបើវាមិនត្រូវបានភ្ជាប់ជាមួយ HEAD ណាមួយពី git (ឧទាហរណ៍ ដោយសារ HEAD ដែលត្រូវគ្នាត្រូវបានលុប) ហើយមិនត្រូវបានប្រើនៅក្នុង manifests ណាមួយនៅក្នុងចង្កោម Kubernetes និងនៅក្នុងការចេញផ្សាយ Helm ទេ។

ការកសាងរូបភាពប៉ារ៉ាឡែល (↓)

• កំណែ៖ v1.1
• កាលបរិច្ឆេទ៖ ខែមករា ដល់ ខែកុម្ភៈ មេសា *

កំណែបច្ចុប្បន្នរបស់ werf ប្រមូលរូបភាព និងវត្ថុបុរាណដែលបានពិពណ៌នានៅក្នុង werf.yaml, ជាបន្តបន្ទាប់។ វាមានភាពចាំបាច់ដើម្បីប៉ារ៉ាឡែលដំណើរការនៃការប្រមូលផ្តុំដំណាក់កាលឯករាជ្យនៃរូបភាព និងវត្ថុបុរាណ ក៏ដូចជាផ្តល់នូវលទ្ធផលងាយស្រួល និងផ្តល់ព័ត៌មាន។

* ចំណាំ៖ ថ្ងៃផុតកំណត់ត្រូវបានផ្លាស់ប្តូរដោយសារតែការបង្កើនអាទិភាពសម្រាប់ការអនុវត្តការជួបប្រជុំគ្នាដែលបានចែកចាយ ដែលនឹងបន្ថែមសមត្ថភាពធ្វើមាត្រដ្ឋានផ្ដេកបន្ថែមទៀត ក៏ដូចជាការប្រើប្រាស់ werf ជាមួយ GitHub Actions ។ ការផ្គុំប៉ារ៉ាឡែលគឺជាជំហានបង្កើនប្រសិទ្ធភាពបន្ទាប់ ដោយផ្តល់នូវទំហំបញ្ឈរនៅពេលដំឡើងគម្រោងមួយ។

ការផ្លាស់ប្តូរទៅ Helm 3 (↓)

• កំណែ៖ v1.2
• កាលបរិច្ឆេទ៖ ខែកុម្ភៈ-មីនា ឧសភា *

រួមបញ្ចូលការផ្ទេរទៅមូលដ្ឋានកូដថ្មី។ មួកសុវត្ថិភាព ៣ និងវិធីងាយស្រួលដែលបង្ហាញឱ្យឃើញដើម្បីផ្ទេរការដំឡើងដែលមានស្រាប់។

* ចំណាំ៖ ការប្តូរទៅ Helm 3 នឹងមិនបន្ថែមលក្ខណៈសំខាន់ៗដល់ werf ទេ ពីព្រោះមុខងារសំខាន់ៗទាំងអស់របស់ Helm 3 (3-way-merge និង no tiller) ត្រូវបានអនុវត្តន៍រួចហើយនៅក្នុង werf ។ លើសពីនេះទៅទៀត werf មាន លក្ខណៈ​ពិសេស​បន្ថែម​ទៀត បន្ថែមពីលើអ្វីដែលបានបង្ហាញ។ ទោះជាយ៉ាងណាក៏ដោយ ការផ្លាស់ប្តូរនេះនៅតែមាននៅក្នុងផែនការរបស់យើង ហើយនឹងត្រូវបានអនុវត្ត។

Jsonnet សម្រាប់ពណ៌នាអំពីការកំណត់រចនាសម្ព័ន្ធ Kubernetes (↓)

• កំណែ៖ v1.2
• កាលបរិច្ឆេទ៖ មករា-កុម្ភៈ មេសា-ឧសភា

Werf នឹងគាំទ្រការពិពណ៌នាអំពីការកំណត់រចនាសម្ព័ន្ធសម្រាប់ Kubernetes ក្នុងទម្រង់ Jsonnet ។ ក្នុងពេលជាមួយគ្នានេះ werf នឹងនៅតែត្រូវគ្នាជាមួយ Helm ហើយវានឹងមានជម្រើសនៃទម្រង់ពណ៌នា។

ហេតុផលគឺថា Go templates យោងទៅតាមមនុស្សជាច្រើនមានរបាំងចូលខ្ពស់ ហើយការយល់ដឹងអំពីកូដនៃគំរូទាំងនេះក៏ទទួលរងផងដែរ។

លទ្ធភាពនៃការណែនាំប្រព័ន្ធពិពណ៌នាការកំណត់រចនាសម្ព័ន្ធ Kubernetes ផ្សេងទៀត (ឧទាហរណ៍ Kustomize) ក៏កំពុងត្រូវបានពិចារណាផងដែរ។

ធ្វើការនៅក្នុង Kubernetes (↓)

• កំណែ៖ v1.2
• កាលបរិច្ឆេទ៖ មេសា-ឧសភា ឧសភា-មិថុនា

គោលបំណង៖ ដើម្បីធានាបាននូវការបង្កើតរូបភាព និងការចែកចាយកម្មវិធីដោយប្រើកម្មវិធីរត់ក្នុង Kubernetes ។ ទាំងនោះ។ រូបភាពថ្មីអាចត្រូវបានផ្គុំ បោះពុម្ព សម្អាត និងដាក់ឱ្យប្រើប្រាស់ដោយផ្ទាល់ពី Kubernetes pods។

ដើម្បីអនុវត្តសមត្ថភាពនេះ ដំបូងអ្នកត្រូវមានលទ្ធភាពបង្កើតរូបភាពចែកចាយ (សូមមើលចំណុចខាងលើ).

វាក៏តម្រូវឱ្យមានការគាំទ្រសម្រាប់របៀបប្រតិបត្តិការរបស់អ្នកសាងសង់ដោយគ្មានម៉ាស៊ីនមេ Docker (ឧទាហរណ៍ ការបង្កើតដូច Kaniko ឬបង្កើតនៅក្នុងតំបន់អ្នកប្រើប្រាស់)។

Werf នឹងគាំទ្រការកសាងនៅលើ Kubernetes មិនត្រឹមតែជាមួយ Dockerfile ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងជាមួយឧបករណ៍សាងសង់ Stapel របស់វាជាមួយនឹងការបង្កើនការស្ថាបនាឡើងវិញ និង Ansible ផងដែរ។

ជំហានឆ្ពោះទៅរកការអភិវឌ្ឍន៍បើកចំហ

យើងស្រឡាញ់សហគមន៍របស់យើង (GitHub, Telegram) ហើយយើងចង់បានមនុស្សកាន់តែច្រើនឡើងដើម្បីជួយធ្វើឱ្យ werf កាន់តែប្រសើរឡើង យល់ពីទិសដៅដែលយើងកំពុងធ្វើដំណើរ និងចូលរួមក្នុងការអភិវឌ្ឍន៍។

ថ្មីៗនេះវាត្រូវបានសម្រេចចិត្តប្តូរទៅ ក្រុមប្រឹក្សាគម្រោង GitHub ដើម្បីបង្ហាញពីដំណើរការការងាររបស់ក្រុមរបស់យើង។ ឥឡូវនេះ អ្នកអាចមើលឃើញផែនការភ្លាមៗ ក៏ដូចជាការងារបច្ចុប្បន្ននៅក្នុងផ្នែកខាងក្រោម៖

• ឯកសារនិងគេហទំព័រ;
• ការសាកល្បង;
• កំហុស និង UX អាក្រក់;
• 1.1.

ការងារជាច្រើនត្រូវបានបញ្ចប់ជាមួយនឹងបញ្ហា៖

• ដកចេញនូវអ្វីដែលមិនពាក់ព័ន្ធ។
• ទម្រង់ដែលមានស្រាប់ត្រូវបាននាំយកទៅជាទម្រង់តែមួយ ដោយមានចំនួនគ្រប់គ្រាន់នៃព័ត៌មានលម្អិត និងព័ត៌មានលម្អិត។
• បញ្ហាថ្មីជាមួយនឹងគំនិត និងការផ្ដល់យោបល់ត្រូវបានបន្ថែម។

របៀបបើកកំណែ v1.1

កំណែបច្ចុប្បន្នមាននៅក្នុង ឆានែល 1.1 អ៊ី (នៅក្នុងឆានែល មានស្ថេរភាព и ថ្ម - រឹង ការចេញផ្សាយនឹងលេចឡើងនៅពេលដែលស្ថេរភាពកើតឡើង ea ខ្លួនវាគឺមានស្ថេរភាពគ្រប់គ្រាន់សម្រាប់ការប្រើប្រាស់រួចហើយ ពីព្រោះ បានឆ្លងកាត់ឆានែល អាល់ហ្វា и បែតា) បានធ្វើឱ្យសកម្ម តាមរយៈ multiwerf តាមវិធីដូចខាងក្រោមៈ

source $(multiwerf use 1.1 ea)
werf COMMAND ...

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

ស្ថាបត្យកម្មការផ្ទុកដំណាក់កាលថ្មី និងការបង្កើនប្រសិទ្ធភាពអ្នកបង្កើតសម្រាប់អ្នកបង្កើត Stapel និង Dockerfile បើកលទ្ធភាពនៃការអនុវត្តការស្ថាបនាដែលបានចែកចាយ និងស្របគ្នានៅក្នុង werf ។ មុខងារទាំងនេះនឹងបង្ហាញក្នុងពេលឆាប់ៗនេះនៅក្នុងការចេញផ្សាយ v1.1 ដូចគ្នា ហើយនឹងអាចប្រើបានដោយស្វ័យប្រវត្តិតាមរយៈយន្តការធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិ (សម្រាប់អ្នកប្រើប្រាស់ ពហុមុខងារ).

នៅក្នុងការចេញផ្សាយនេះ យុទ្ធសាស្ត្រដាក់ស្លាកដោយផ្អែកលើខ្លឹមសាររូបភាពត្រូវបានបន្ថែម - ការដាក់ស្លាកផ្អែកលើមាតិកាដែលបានក្លាយជាយុទ្ធសាស្ត្រលំនាំដើម។ កំណត់ហេតុពាក្យបញ្ជាសំខាន់ក៏ត្រូវបានដំណើរការឡើងវិញផងដែរ៖ werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

ជំហានសំខាន់បន្ទាប់គឺត្រូវបន្ថែមការជួបប្រជុំគ្នាដែលចែកចាយ។ ការស្ថាបនាដែលបានចែកចាយបានក្លាយជាអាទិភាពខ្ពស់ជាងការស្ថាបនាប៉ារ៉ាឡែលចាប់តាំងពី v1.0 ព្រោះវាបន្ថែមតម្លៃបន្ថែមទៀតដល់ werf: ការធ្វើមាត្រដ្ឋានបញ្ឈរនៃអ្នកសាងសង់ និងការគាំទ្រសម្រាប់អ្នកសាងសង់មិនទៀងទាត់នៅក្នុងប្រព័ន្ធ CI/CD ផ្សេងៗ ក៏ដូចជាសមត្ថភាពក្នុងការបង្កើតការគាំទ្រជាផ្លូវការសម្រាប់សកម្មភាព GitHub . ដូច្នេះ​កាល​បរិច្ឆេទ​នៃ​ការ​អនុវត្ត​សម្រាប់​សន្និបាត​ប៉ារ៉ាឡែល​ត្រូវ​បាន​ផ្លាស់​ប្តូរ។ ទោះជាយ៉ាងណាក៏ដោយ យើងកំពុងធ្វើការដើម្បីអនុវត្តលទ្ធភាពទាំងពីរឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។

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

PS

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

• «ការណែនាំ 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