ការផ្គុំថាមវន្ត និងការដាក់ឱ្យប្រើប្រាស់រូបភាព Docker ជាមួយ werf ដោយប្រើឧទាហរណ៍នៃគេហទំព័រឯកសារដែលមានកំណែ

យើងបាននិយាយរួចហើយអំពីឧបករណ៍ GitOps របស់យើងច្រើនជាងម្តង។ werfហើយលើកនេះ យើងចង់ចែករំលែកបទពិសោធន៍របស់យើងក្នុងការប្រមូលផ្តុំគេហទំព័រជាមួយនឹងឯកសារនៃគម្រោងដោយខ្លួនឯង - werf.io (កំណែជាភាសារុស្សីគឺ en.werf.io) នេះគឺជាគេហទំព័រឋិតិវន្តធម្មតា ប៉ុន្តែការជួបប្រជុំគ្នារបស់វាគួរឱ្យចាប់អារម្មណ៍ដែលវាត្រូវបានសាងសង់ដោយប្រើចំនួនវត្ថុបុរាណថាមវន្ត។

ចូលទៅក្នុងភាពខុសប្លែកគ្នានៃរចនាសម្ព័ន្ធគេហទំព័រ៖ ការបង្កើតម៉ឺនុយទូទៅសម្រាប់គ្រប់កំណែ ទំព័រដែលមានព័ត៌មានអំពីការចេញផ្សាយ។ល។ - យើង​នឹង​មិន។ ផ្ទុយទៅវិញ ចូរយើងផ្តោតលើបញ្ហា និងលក្ខណៈពិសេសនៃការជួបប្រជុំគ្នាថាមវន្ត និងបន្តិចលើដំណើរការ CI/CD ដែលអមមកជាមួយ។

សេចក្តីផ្តើម៖ របៀបដែលគេហទំព័រដំណើរការ

ដើម្បីចាប់ផ្តើមជាមួយឯកសារ werf ត្រូវបានរក្សាទុករួមជាមួយលេខកូដរបស់វា។ នេះកំណត់តម្រូវការអភិវឌ្ឍន៍មួយចំនួនដែលជាទូទៅហួសពីវិសាលភាពនៃអត្ថបទនេះ ប៉ុន្តែយ៉ាងហោចណាស់វាអាចនិយាយបានថា:

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

ដើម្បីលាក់ "ផ្ទះបាយខាងក្នុង" ទាំងអស់នេះពីអ្នកប្រើប្រាស់ដោយផ្តល់ឱ្យគាត់នូវអ្វីមួយដែល "ទើបតែដំណើរការ" យើងបានធ្វើ ការដំឡើង werf ដាច់ដោយឡែក និងឧបករណ៍ធ្វើបច្ចុប្បន្នភាព - នេះ​គឺជា ពហុមុខងារ. អ្នកគ្រាន់តែត្រូវបញ្ជាក់លេខចេញផ្សាយ និងប៉ុស្តិ៍ស្ថេរភាពដែលអ្នករួចរាល់ក្នុងការប្រើប្រាស់ ហើយ multiwerf នឹងពិនិត្យមើលថាតើមានកំណែថ្មីនៅលើឆានែលហើយទាញយកវាប្រសិនបើចាំបាច់។

នៅក្នុងម៉ឺនុយជ្រើសរើសកំណែនៅលើគេហទំព័រ កំណែចុងក្រោយបំផុតរបស់ werf មាននៅក្នុងឆានែលនីមួយៗ។ តាមលំនាំដើម តាមអាសយដ្ឋាន werf.io/documentation កំណែនៃឆានែលដែលមានស្ថេរភាពបំផុតសម្រាប់ការចេញផ្សាយចុងក្រោយបំផុតបានបើក - វាក៏ត្រូវបានដាក់លិបិក្រមដោយម៉ាស៊ីនស្វែងរកផងដែរ។ ឯកសារសម្រាប់ឆានែលមាននៅអាសយដ្ឋានដាច់ដោយឡែក (ឧទាហរណ៍ werf.io/v1.0-beta/documentation សម្រាប់កំណែបែតា 1.0) ។

សរុបមក គេហទំព័រនេះមានកំណែដូចខាងក្រោម៖

1. root (បើកតាមលំនាំដើម),
2. សម្រាប់ឆានែលអាប់ដេតសកម្មនៃការចេញផ្សាយនីមួយៗ (ឧទាហរណ៍ werf.io/v1.0-beta).

ដើម្បីបង្កើតកំណែជាក់លាក់នៃគេហទំព័រមួយ ជាទូទៅវាគ្រប់គ្រាន់ក្នុងការចងក្រងវាដោយប្រើ Jekyllដោយដំណើរការនៅក្នុងថត /docs ពាក្យបញ្ជាដែលត្រូវគ្នានៃឃ្លាំង werf (jekyll build) បន្ទាប់ពីប្តូរទៅស្លាក Git នៃកំណែដែលត្រូវការ។

វានៅសល់តែបន្ថែមថា:

• ឧបករណ៍ប្រើប្រាស់ខ្លួនវា (werf) ត្រូវបានប្រើសម្រាប់ការជួបប្រជុំគ្នា;
• ដំណើរការ CI/CD ត្រូវបានបង្កើតឡើងដោយផ្អែកលើ GitLab CI ។
• ហើយទាំងអស់នេះ ពិតណាស់ដំណើរការនៅក្នុង Kubernetes។

ភារកិច្ច

ឥឡូវនេះ ចូរយើងបង្កើតកិច្ចការដែលគិតគូរពីភាពជាក់លាក់ដែលបានពិពណ៌នាទាំងអស់៖

1. បន្ទាប់ពីផ្លាស់ប្តូរកំណែ werf នៅលើឆានែលអាប់ដេតណាមួយ។ ឯកសារនៅលើគេហទំព័រគួរតែត្រូវបានធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិ.
2. សម្រាប់ការអភិវឌ្ឍន៍ អ្នកត្រូវមានពេលខ្លះ មើលកំណែមើលជាមុននៃគេហទំព័រ.

គេហទំព័រត្រូវតែត្រូវបានចងក្រងឡើងវិញបន្ទាប់ពីផ្លាស់ប្តូរកំណែនៅលើឆានែលណាមួយពីស្លាក Git ដែលត្រូវគ្នា ប៉ុន្តែនៅក្នុងដំណើរការនៃការបង្កើតរូបភាព យើងនឹងទទួលបានលក្ខណៈពិសេសដូចខាងក្រោមៈ

• ចាប់តាំងពីបញ្ជីកំណែនៅលើប៉ុស្តិ៍ផ្លាស់ប្តូរ វាគ្រាន់តែជាការចាំបាច់ក្នុងការកសាងឯកសារឡើងវិញសម្រាប់ប៉ុស្តិ៍ដែលកំណែបានផ្លាស់ប្តូរ។ យ៉ាងណាមិញ ការ​កសាង​អ្វីៗ​ឡើង​វិញ​ម្ដង​ទៀត​គឺ​មិន​ល្អ​ប៉ុន្មាន​ទេ។
• សំណុំនៃឆានែលសម្រាប់ការចេញផ្សាយអាចផ្លាស់ប្តូរ។ ជាឧទាហរណ៍ ក្នុងពេលណាមួយ ប្រហែលជាមិនមានកំណែនៅលើបណ្តាញដែលមានស្ថេរភាពជាងការចេញផ្សាយដំបូង 1.1 ប៉ុន្តែយូរ ៗ ទៅពួកគេនឹងលេចឡើង - ក្នុងករណីនេះអ្នកមិនគួរផ្លាស់ប្តូរការជួបប្រជុំគ្នាដោយដៃទេ?

វាប្រែថា ការជួបប្រជុំគ្នាអាស្រ័យលើការផ្លាស់ប្តូរទិន្នន័យខាងក្រៅ.

Реализация

ការជ្រើសរើសវិធីសាស្រ្ត

ជាជម្រើស អ្នកអាចដំណើរការកំណែដែលត្រូវការនីមួយៗជាផតដាច់ដោយឡែកនៅក្នុង Kubernetes។ ជម្រើសនេះបង្កប់ន័យចំនួនកាន់តែច្រើននៃវត្ថុនៅក្នុងចង្កោម ដែលនឹងកើនឡើងជាមួយនឹងការកើនឡើងនៃចំនួននៃការចេញផ្សាយ werf ដែលមានស្ថេរភាព។ ហើយនេះ, នៅក្នុងវេន, បង្កប់ន័យការថែរក្សាស្មុគ្រស្មាញបន្ថែមទៀត: កំណែនីមួយៗមានម៉ាស៊ីនមេ HTTP ផ្ទាល់ខ្លួនរបស់វាហើយជាមួយនឹងបន្ទុកតូចមួយ។ ជាការពិតណាស់ នេះក៏រួមបញ្ចូលការចំណាយធនធានកាន់តែច្រើនផងដែរ។

យើងបានដើរតាមផ្លូវដូចគ្នា។ ការប្រមូលផ្តុំកំណែចាំបាច់ទាំងអស់នៅក្នុងរូបភាពមួយ។. ឋិតិវន្តដែលបានចងក្រងនៃកំណែទាំងអស់នៃគេហទំព័រមានទីតាំងនៅក្នុងកុងតឺន័រដែលមាន NGINX ហើយចរាចរណ៍ទៅកាន់ការដាក់ពង្រាយដែលត្រូវគ្នាកើតឡើងតាមរយៈ NGINX Ingress ។ រចនាសម្ព័ន្ធសាមញ្ញ - កម្មវិធីគ្មានរដ្ឋ - អនុញ្ញាតឱ្យអ្នកងាយស្រួលធ្វើមាត្រដ្ឋានការដាក់ពង្រាយ (អាស្រ័យលើបន្ទុក) ដោយប្រើ Kubernetes ខ្លួនវាផ្ទាល់។

ដើម្បីឱ្យកាន់តែច្បាស់លាស់ យើងកំពុងប្រមូលរូបភាពពីរ៖ មួយសម្រាប់សៀគ្វីផលិតកម្ម ទីពីរគឺជារូបភាពបន្ថែមសម្រាប់សៀគ្វីអភិវឌ្ឍន៍។ រូបភាពបន្ថែមត្រូវបានប្រើប្រាស់ (បើកដំណើរការ) តែនៅលើសៀគ្វី dev រួមជាមួយនឹងរូបមេ និងមានកំណែគេហទំព័រដែលបានមកពីការពិនិត្យឡើងវិញ ហើយការបញ្ជូនរវាងពួកវាត្រូវបានអនុវត្តដោយប្រើធនធាន Ingress ។

werf vs git ក្លូន និងវត្ថុបុរាណ

ដូចដែលបានបញ្ជាក់រួចមកហើយ ដើម្បីបង្កើតឋិតិវន្តនៃគេហទំព័រសម្រាប់កំណែជាក់លាក់នៃឯកសារ អ្នកត្រូវបង្កើតដោយប្តូរទៅស្លាកឃ្លាំងដែលសមស្រប។ អ្នកក៏អាចធ្វើដូចនេះបានដោយការក្លូនឃ្លាំងរាល់ពេលដែលអ្នកបង្កើត ដោយជ្រើសរើសស្លាកដែលសមរម្យពីបញ្ជីមួយ។ ទោះជាយ៉ាងណាក៏ដោយ នេះគឺជាប្រតិបត្តិការដែលពឹងផ្អែកខ្លាំងលើធនធាន ហើយលើសពីនេះទៅទៀត ទាមទារការសរសេរការណែនាំដែលមិនមែនជារឿងតូចតាច... គុណវិបត្តិដ៏ធ្ងន់ធ្ងរមួយទៀតនោះគឺថា ជាមួយនឹងវិធីសាស្រ្តនេះ វាមិនមានវិធីដើម្បីលាក់អ្វីមួយកំឡុងពេលដំឡើងនោះទេ។

នៅទីនេះឧបករណ៍ប្រើប្រាស់ werf ខ្លួនវាមកដល់ជំនួយរបស់យើង ដោយអនុវត្ត ឃ្លាំងសម្ងាត់ឆ្លាតវៃ និងអនុញ្ញាតឱ្យអ្នកប្រើ ឃ្លាំងខាងក្រៅ. ការប្រើ werf ដើម្បីបន្ថែមកូដពីឃ្លាំងនឹងបង្កើនល្បឿនការកសាងយ៉ាងខ្លាំង ពីព្រោះ werf សំខាន់ក្លូនឃ្លាំងម្តង ហើយបន្ទាប់មកប្រតិបត្តិ តែ fetch បើចាំបាច់។ លើសពីនេះ នៅពេលបន្ថែមទិន្នន័យពីឃ្លាំង យើងអាចជ្រើសរើសបានតែថតចាំបាច់ប៉ុណ្ណោះ (ក្នុងករណីរបស់យើងនេះគឺជាថតឯកសារ docs) ដែលនឹងកាត់បន្ថយបរិមាណទិន្នន័យបន្ថែម។

ដោយសារ Jekyll គឺជាឧបករណ៍ដែលត្រូវបានរចនាឡើងសម្រាប់ការចងក្រងទិន្នន័យឋិតិវន្ត ហើយមិនត្រូវការនៅក្នុងរូបភាពចុងក្រោយ វានឹងសមហេតុផលក្នុងការចងក្រងនៅក្នុង វត្ថុបុរាណ werfហើយចូលទៅក្នុងរូបភាពចុងក្រោយ នាំចូលតែលទ្ធផលចងក្រងប៉ុណ្ណោះ។.

យើងសរសេរ werf.yaml

ដូច្នេះ យើងបានសម្រេចចិត្តថាយើងនឹងចងក្រងកំណែនីមួយៗនៅក្នុងវត្ថុបុរាណ werf ដាច់ដោយឡែកមួយ។ ទោះយ៉ាងណាក៏ដោយយើង យើង​មិន​ដឹង​ថា​តើ​វត្ថុ​បុរាណ​ទាំង​នេះ​នឹង​មាន​ប៉ុន្មាន​ក្នុង​ពេល​ជួប​ជុំ​គ្នា​នោះ​ទេ។ដូច្នេះ យើង​មិន​អាច​សរសេរ​ការ​កំណត់​រចនាសម្ព័ន្ធ​ស្ថាបនា​បាន​ទេ (និយាយ​យ៉ាង​តឹងរ៉ឹង យើង​នៅ​តែ​អាច ប៉ុន្តែ​វា​នឹង​មិន​មាន​ប្រសិទ្ធភាព​ទាំង​ស្រុង)។

werf អនុញ្ញាតឱ្យអ្នកប្រើ ទៅគំរូ នៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធរបស់អ្នក (werf.yaml) ហើយនេះធ្វើឱ្យវាអាចទៅរួច បង្កើត config ភ្លាមៗ អាស្រ័យលើទិន្នន័យខាងក្រៅ (អ្វីដែលអ្នកត្រូវការ!) ទិន្នន័យខាងក្រៅនៅក្នុងករណីរបស់យើងគឺជាព័ត៌មានអំពីកំណែ និងការចេញផ្សាយ ដោយផ្អែកលើមូលដ្ឋានដែលយើងប្រមូលចំនួនវត្ថុបុរាណដែលត្រូវការ ហើយជាលទ្ធផលយើងទទួលបានរូបភាពពីរ៖ werf-doc и werf-dev ដើម្បីដំណើរការលើសៀគ្វីផ្សេងៗ។

ទិន្នន័យខាងក្រៅត្រូវបានឆ្លងកាត់អថេរបរិស្ថាន។ នេះគឺជាសមាសភាពរបស់ពួកគេ៖

• RELEASES - បន្ទាត់ដែលមានបញ្ជីនៃការចេញផ្សាយ និងកំណែបច្ចុប្បន្នដែលត្រូវគ្នានៃ werf ក្នុងទម្រង់នៃបញ្ជីតម្លៃដែលបំបែកដោយចន្លោះនៃតម្លៃក្នុងទម្រង់ <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>។ ឧទាហរណ៍ៈ 1.0%v1.0.4-beta.20
• CHANNELS - បន្ទាត់ដែលមានបញ្ជីឆានែលនិងកំណែបច្ចុប្បន្នដែលត្រូវគ្នានៃ werf ក្នុងទម្រង់នៃបញ្ជីតម្លៃដែលបំបែកដោយដកឃ្លាក្នុងទម្រង់ <КАНАЛ>%<НОМЕР_ВЕРСИИ>។ ឧទាហរណ៍ៈ 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — កំណែចេញផ្សាយរបស់ werf ត្រូវបានបង្ហាញតាមលំនាំដើមនៅលើគេហទំព័រ (វាមិនតែងតែចាំបាច់ដើម្បីបង្ហាញឯកសារដោយលេខចេញផ្សាយខ្ពស់បំផុតទេ) ។ ឧទាហរណ៍៖ v1.0.4-beta.20
• REVIEW_SHA - hash នៃ​ការ​ពិនិត្យ​ឡើង​វិញ​ដែល​អ្នក​ត្រូវ​ការ​ដើម្បី​បង្កើត​កំណែ​សម្រាប់​រង្វិលជុំ​សាកល្បង។

អថេរទាំងនេះនឹងត្រូវបានបំពេញនៅក្នុង GitLab CI pipeline និងរបៀបពិតប្រាកដត្រូវបានសរសេរខាងក្រោម។

ជាដំបូងនៃការទាំងអស់ដើម្បីភាពងាយស្រួលយើងកំណត់នៅក្នុង werf.yaml ទៅ​អថេរ​គំរូ ដោយ​កំណត់​តម្លៃ​ពួកវា​ពី​អថេរ​បរិស្ថាន៖

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

ការពិពណ៌នាអំពីវត្ថុបុរាណសម្រាប់ការចងក្រងកំណែឋិតិវន្តនៃគេហទំព័រ ជាទូទៅគឺដូចគ្នាសម្រាប់គ្រប់ករណីដែលយើងត្រូវការ (រួមទាំងការបង្កើតកំណែជា root ក៏ដូចជាកំណែសម្រាប់សៀគ្វីអភិវឌ្ឍន៍)។ ដូច្នេះយើងនឹងផ្លាស់ទីវាទៅក្នុងប្លុកដាច់ដោយឡែកដោយប្រើមុខងារ define - សម្រាប់ការប្រើប្រាស់ឡើងវិញជាបន្តបន្ទាប់ include. យើងនឹងបញ្ជូនអាគុយម៉ង់ខាងក្រោមទៅកាន់គំរូ៖

• Version - កំណែដែលបានបង្កើត (ឈ្មោះស្លាក);
• Channel - ឈ្មោះនៃឆានែលអាប់ដេតដែលវត្ថុបុរាណត្រូវបានបង្កើត។
• Commit - ប្រព្រឹត្ត hash ប្រសិនបើវត្ថុបុរាណត្រូវបានបង្កើតសម្រាប់ការពិនិត្យឡើងវិញ។
• បរិបទ។

ការពិពណ៌នាអំពីគំរូវត្ថុបុរាណ

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

ឈ្មោះវត្ថុបុរាណត្រូវតែមានតែមួយគត់។ យើងអាចសម្រេចបានវា ជាឧទាហរណ៍ ដោយបន្ថែមឈ្មោះឆានែល (តម្លៃនៃអថេរ .Channel) ជាបច្ច័យនៃឈ្មោះវត្ថុបុរាណ៖ artifact: doc-{{ .Channel }}. ប៉ុន្តែ​អ្នក​ត្រូវ​យល់​ថា ពេល​នាំ​ចូល​វត្ថុ​បុរាណ អ្នក​នឹង​ត្រូវ​យោង​ទៅ​លើ​ឈ្មោះ​ដូច​គ្នា។

នៅពេលពិពណ៌នាអំពីវត្ថុបុរាណ មុខងារ werf ខាងក្រោមត្រូវបានប្រើ៖ ការដំឡើង. ការម៉ោនបង្ហាញបញ្ជីសេវាកម្ម build_dir អនុញ្ញាតឱ្យអ្នករក្សាទុកឃ្លាំងសម្ងាត់ Jekyll រវាងដំណើរការបំពង់ បង្កើនល្បឿនយ៉ាងសំខាន់ក្នុងការប្រមូលផ្តុំឡើងវិញ.

អ្នក​ក៏​ប្រហែល​ជា​បាន​កត់​សម្គាល់​ការ​ប្រើ​ឯកសារ​ដែរ។ releases.yml គឺជាឯកសារ YAML ដែលមានទិន្នន័យចេញផ្សាយដែលបានស្នើសុំពី github.com (វត្ថុបុរាណដែលទទួលបាននៅពេលដំណើរការបំពង់បង្ហូរប្រេង) ។ វាចាំបាច់នៅពេលចងក្រងគេហទំព័រ ប៉ុន្តែនៅក្នុងបរិបទនៃអត្ថបទវាគួរឱ្យចាប់អារម្មណ៍ចំពោះយើងព្រោះវាអាស្រ័យលើស្ថានភាពរបស់វា ប្រមូលផ្តុំវត្ថុបុរាណតែមួយគត់ - វត្ថុបុរាណនៃកំណែឫសនៃគេហទំព័រ (វាមិនត្រូវការនៅក្នុងវត្ថុបុរាណផ្សេងទៀតទេ) ។

វាត្រូវបានអនុវត្តដោយប្រើសេចក្តីថ្លែងការណ៍តាមលក្ខខណ្ឌ if ចូលទៅកាន់គំរូ និងការរចនា {{ $Root.Files.Get "releases.yml" | sha256sum }} នៅក្នុងដំណាក់កាល ដំណាក់កាល. វាដំណើរការដូចខាងក្រោម: នៅពេលបង្កើតវត្ថុបុរាណសម្រាប់កំណែជា root (អថេរ .Channel ស្មើ root) ឯកសារ hash releases.yml ប៉ះពាល់ដល់ហត្ថលេខានៃដំណាក់កាលទាំងមូល ព្រោះវាជាផ្នែកមួយនៃឈ្មោះនៃកិច្ចការ Ansible (ប៉ារ៉ាម៉ែត្រ name) ដូច្នេះនៅពេលផ្លាស់ប្តូរ មាតិកា ឯកសារ releases.yml វត្ថុបុរាណដែលត្រូវគ្នានឹងត្រូវបានរៀបចំឡើងវិញ។

សូមយកចិត្តទុកដាក់ផងដែរក្នុងការធ្វើការជាមួយឃ្លាំងខាងក្រៅ។ នៅក្នុងរូបភាពនៃវត្ថុបុរាណមួយពី ឃ្លាំង werfមានតែថតត្រូវបានបន្ថែម /docsហើយអាស្រ័យលើប៉ារ៉ាម៉ែត្រដែលបានឆ្លងកាត់ ទិន្នន័យនៃស្លាកដែលត្រូវការ ឬការត្រួតពិនិត្យឡើងវិញត្រូវបានបន្ថែមភ្លាមៗ។

ដើម្បីប្រើគំរូវត្ថុបុរាណដើម្បីបង្កើតការពិពណ៌នាអំពីវត្ថុបុរាណនៃកំណែដែលបានផ្ទេរនៃឆានែល និងការចេញផ្សាយ យើងរៀបចំរង្វិលជុំនៅលើអថេរ .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

ដោយសារតែ រង្វិលជុំនឹងបង្កើតវត្ថុបុរាណជាច្រើន (យើងសង្ឃឹមដូច្នេះ) វាចាំបាច់ក្នុងការគិតគូរពីសញ្ញាបំបែករវាងពួកវា - លំដាប់។ --- (សម្រាប់ព័ត៌មានបន្ថែមអំពីវាក្យសម្ព័ន្ធឯកសារកំណត់រចនាសម្ព័ន្ធ សូមមើល ឯកសារ) ដូចដែលបានកំណត់ពីមុន នៅពេលហៅគំរូក្នុងរង្វិលជុំ យើងឆ្លងកាត់ប៉ារ៉ាម៉ែត្រកំណែ URL និងបរិបទឫស។

ស្រដៀងគ្នានេះដែរ ប៉ុន្តែដោយគ្មានរង្វិលជុំ យើងហៅគំរូវត្ថុបុរាណសម្រាប់ "ករណីពិសេស"៖ សម្រាប់កំណែជា root ក៏ដូចជាកំណែដែលបានមកពីការពិនិត្យឡើងវិញ៖

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

សូមចំណាំថាវត្ថុបុរាណសម្រាប់គណៈកម្មការត្រួតពិនិត្យនឹងត្រូវបានបង្កើតឡើងលុះត្រាតែអថេរត្រូវបានកំណត់ .WerfReviewCommit.

វត្ថុបុរាណបានត្រៀមរួចរាល់ហើយ - ដល់ពេលចាប់ផ្តើមនាំចូលហើយ!

រូបភាពចុងក្រោយដែលត្រូវបានរចនាឡើងដើម្បីដំណើរការលើ Kubernetes គឺជា NGINX ធម្មតាដែលមានឯកសារកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេត្រូវបានបន្ថែម nginx.conf និងឋិតិវន្តពីវត្ថុបុរាណ។ បន្ថែមពីលើវត្ថុបុរាណនៃកំណែ root នៃគេហទំព័រយើងត្រូវធ្វើរង្វិលជុំម្តងទៀតនៅលើអថេរ .WerfVersions ដើម្បីនាំចូលវត្ថុបុរាណនៃឆានែល និងកំណែចេញផ្សាយ + អនុវត្តតាមច្បាប់ដាក់ឈ្មោះវត្ថុបុរាណដែលយើងបានអនុម័តមុន។ ដោយសារវត្ថុបុរាណនីមួយៗរក្សាទុកកំណែនៃគេហទំព័រសម្រាប់ពីរភាសា យើងនាំចូលពួកវាទៅក្នុងកន្លែងដែលផ្តល់ដោយការកំណត់រចនាសម្ព័ន្ធ។

ការពិពណ៌នានៃរូបភាពចុងក្រោយ werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

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

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

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

សន្និបាតបានត្រៀមរួចរាល់! ចូរបន្តទៅ CI/CD និងការ nuances សំខាន់ៗ។

បំពង់នៅក្នុង GitLab CI និងលក្ខណៈពិសេសនៃការស្ថាបនាថាមវន្ត

នៅពេលដំណើរការ build យើងត្រូវកំណត់អថេរបរិស្ថានដែលប្រើក្នុង werf.yaml. នេះមិនអនុវត្តចំពោះអថេរ REVIEW_SHA ដែលយើងនឹងកំណត់នៅពេលហៅបំពង់ពីទំពក់ GitHub ។

យើងនឹងបង្កើតទិន្នន័យខាងក្រៅចាំបាច់នៅក្នុងស្គ្រីប Bash generate_artifactsដែលនឹងបង្កើតវត្ថុបុរាណបំពង់ GitLab ពីរ៖

• ហ្វាល releases.yml ជាមួយនឹងទិន្នន័យចេញផ្សាយ,
• ហ្វាល common_envs.shដែលមានអថេរបរិស្ថានដែលត្រូវនាំចេញ។

មាតិកាឯកសារ generate_artifacts អ្នកនឹងរកឃើញនៅក្នុងរបស់យើង។ ឃ្លាំងជាមួយឧទាហរណ៍. ការទទួលទិន្នន័យខ្លួនវាមិនមែនជាកម្មវត្ថុនៃអត្ថបទនោះទេ ប៉ុន្តែជាឯកសារ common_envs.sh មានសារៈសំខាន់ចំពោះយើង ពីព្រោះ ការងាររបស់ werf អាស្រ័យលើវា។ ឧទាហរណ៍នៃខ្លឹមសាររបស់វា៖

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

អ្នកអាចប្រើលទ្ធផលនៃស្គ្រីបបែបនេះ ជាឧទាហរណ៍ ដោយប្រើមុខងារ Bash source.

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

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

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

យើង​នឹង ទទួល និងកត់ត្រាទិន្នន័យខាងក្រៅ នៅដំណាក់កាលដំបូងនៃបំពង់បង្ហូរប្រេងនៅក្នុង GitLab (សាងសង់ជាមុន) ហើយបញ្ជូនពួកវាបន្ថែមទៀតក្នុងទម្រង់ វត្ថុបុរាណ GitLab CI. វា​នឹង​អនុញ្ញាត​ឱ្យ​អ្នក​ដំណើរការ និង​ចាប់ផ្តើម​ការងារ​បំពង់​ឡើងវិញ (សាងសង់ ពង្រាយ សម្អាត) ជាមួយនឹង​ការកំណត់​ដូចគ្នា​នៅក្នុង werf.yaml.

ខ្លឹមសារនៃឆាក សាងសង់ជាមុន ឯកសារ .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

ដោយបានចាប់យកទិន្នន័យខាងក្រៅនៅក្នុងវត្ថុបុរាណ អ្នកអាចបង្កើត និងដាក់ពង្រាយដោយប្រើដំណាក់កាលស្តង់ដារ GitLab CI pipeline៖ Build និង Deploy។ យើងបើកដំណើរការបំពង់ដោយខ្លួនវាដោយប្រើទំពក់ពីឃ្លាំង GitHub werf (ឧ. នៅពេលដែលមានការផ្លាស់ប្តូរនៅក្នុងឃ្លាំងនៅលើ GitHub)។ ទិន្នន័យសម្រាប់ពួកវាអាចរកបាននៅក្នុងលក្ខណៈសម្បត្តិគម្រោង GitLab នៅក្នុងផ្នែក ការកំណត់ CI/CD -> កេះបំពង់ហើយបន្ទាប់មកបង្កើត Webhook ដែលត្រូវគ្នានៅក្នុង GitHub (ការកំណត់ -> Webhooks).

ដំណាក់កាលសាងសង់នឹងមើលទៅដូចនេះ៖

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

GitLab នឹងបន្ថែមវត្ថុបុរាណពីរពីដំណាក់កាលទៅដំណាក់កាលសាងសង់ សាងសង់ជាមុនដូច្នេះ យើងនាំចេញអថេរជាមួយនឹងទិន្នន័យបញ្ចូលដែលបានរៀបចំដោយប្រើ ស្ថាបនា source common_envs.sh. យើងចាប់ផ្តើមដំណាក់កាលសាងសង់ក្នុងគ្រប់ករណីទាំងអស់ លើកលែងតែការដាក់ឱ្យដំណើរការបំពង់បង្ហូរប្រេងតាមកាលវិភាគ។ យោងតាមកាលវិភាគយើងនឹងដំណើរការបំពង់សម្រាប់ការលាងសំអាត - ក្នុងករណីនេះមិនចាំបាច់ធ្វើការដំឡើងទេ។

នៅដំណាក់កាលដាក់ពង្រាយ យើងនឹងរៀបរាប់អំពីកិច្ចការពីរ - ដោយឡែកពីគ្នាសម្រាប់ការដាក់ពង្រាយទៅកាន់ផលិតកម្ម និងសៀគ្វីអភិវឌ្ឍន៍ ដោយប្រើគំរូ YAML៖

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

ភារកិច្ចមានភាពខុសគ្នាតែនៅក្នុងការចង្អុលបង្ហាញបរិបទចង្កោមដែល werf គួរតែអនុវត្តការដាក់ពង្រាយ (WERF_KUBE_CONTEXT) និងកំណត់អថេរបរិស្ថានរង្វិលជុំ (environment.name и environment.url) ដែលបន្ទាប់មកត្រូវបានប្រើនៅក្នុងគំរូគំនូសតាង Helm ។ យើង​នឹង​មិន​ផ្តល់​ខ្លឹមសារ​នៃ​គំរូ​ទេ ព្រោះ​... មិនមានអ្វីគួរឱ្យចាប់អារម្មណ៍នៅទីនោះសម្រាប់ប្រធានបទនៅក្នុងសំណួរនោះទេ ប៉ុន្តែអ្នកអាចស្វែងរកពួកគេនៅក្នុង ឃ្លាំងសម្រាប់អត្ថបទ.

ការប៉ះចុងក្រោយ

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

ដើម្បីអនុវត្តអ្នកនឹងត្រូវការ៖

• បន្ថែមជំហានសម្អាតទៅ .gitlab-ci.yml;
• បន្ថែមការប្រតិបត្តិតាមកាលកំណត់នៃកិច្ចការសម្អាត;
• រៀបចំអថេរបរិស្ថានជាមួយនឹងសញ្ញាសម្ងាត់ចូលដំណើរការសរសេរ។

ការបន្ថែមដំណាក់កាលសំអាត .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

យើងបានឃើញស្ទើរតែទាំងអស់របស់វាខ្ពស់ជាងបន្តិច - គ្រាន់តែដើម្បីសម្អាតវា អ្នកត្រូវចូលទៅ Docker Registry ជាដំបូងដោយប្រើសញ្ញាសម្ងាត់ដែលមានសិទ្ធិលុបរូបភាពនៅក្នុង Docker Registry (និមិត្តសញ្ញាភារកិច្ច GitLab CI ដែលចេញដោយស្វ័យប្រវត្តិមិនមាន មានសិទ្ធិបែបនេះ)។ និមិត្តសញ្ញាត្រូវតែត្រូវបានបង្កើតនៅក្នុង GitLab ជាមុន ហើយតម្លៃរបស់វាត្រូវតែបញ្ជាក់នៅក្នុងអថេរបរិស្ថាន WERF_IMAGES_CLEANUP_PASSWORD គម្រោង (ការកំណត់ CI/CD -> អថេរ).

ការបន្ថែមកិច្ចការសម្អាតជាមួយនឹងកាលវិភាគដែលត្រូវការគឺរួចរាល់ CI/CD ->
កាលវិភាគ.

នោះហើយជាវា៖ គម្រោងមួយនៅក្នុង Docker Registry នឹងលែងរីកចម្រើនឥតឈប់ឈរពីរូបភាពដែលមិនប្រើ។

នៅចុងបញ្ចប់នៃផ្នែកជាក់ស្តែង ខ្ញុំសូមរំលឹកអ្នកថា បញ្ជីពេញលេញពីអត្ថបទមាននៅក្នុង Git:

• .gitlab-ci.yml;
• werf.yaml.

លទ្ធផល

1. យើងបានទទួលរចនាសម្ព័ន្ធការផ្គុំឡូជីខល៖ វត្ថុបុរាណមួយក្នុងមួយកំណែ។
2. ការជួបប្រជុំគ្នាមានលក្ខណៈជាសកល ហើយមិនតម្រូវឱ្យមានការផ្លាស់ប្តូរដោយដៃនៅពេលដែលកំណែថ្មីនៃ werf ត្រូវបានចេញផ្សាយ៖ ឯកសារនៅលើគេហទំព័រត្រូវបានធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិ។
3. រូបភាពពីរត្រូវបានផ្គុំឡើងសម្រាប់វណ្ឌវង្កផ្សេងគ្នា។
4. វាដំណើរការយ៉ាងឆាប់រហ័ស, ដោយសារតែ ឃ្លាំងសម្ងាត់ត្រូវបានប្រើតាមដែលអាចធ្វើទៅបាន - នៅពេលដែលកំណែថ្មីនៃ werf ត្រូវបានចេញផ្សាយ ឬទំពក់ GitHub ត្រូវបានហៅឱ្យធ្វើការពិនិត្យឡើងវិញ មានតែវត្ថុបុរាណដែលត្រូវគ្នាជាមួយនឹងកំណែដែលបានផ្លាស់ប្តូរប៉ុណ្ណោះដែលត្រូវបានសាងសង់ឡើងវិញ។
5. មិនចាំបាច់គិតអំពីការលុបរូបភាពដែលមិនប្រើទេ៖ ការសម្អាតតាមគោលការណ៍ werf នឹងរក្សា Docker Registry ឲ្យមានសណ្តាប់ធ្នាប់។

ការរកឃើញ

• ការប្រើប្រាស់ werf អនុញ្ញាតឱ្យការជួបប្រជុំគ្នាដំណើរការបានយ៉ាងឆាប់រហ័សដោយសារតែការរក្សាទុកទាំងការជួបប្រជុំគ្នាដោយខ្លួនឯង និងឃ្លាំងសម្ងាត់នៅពេលធ្វើការជាមួយឃ្លាំងខាងក្រៅ។
• ការធ្វើការជាមួយឃ្លាំង Git ខាងក្រៅលុបបំបាត់តម្រូវការក្នុងការក្លូនឃ្លាំងទាំងមូលរាល់ពេល ឬបង្កើតកង់ឡើងវិញជាមួយនឹងតក្កវិជ្ជាបង្កើនប្រសិទ្ធភាពដ៏លំបាក។ werf ប្រើឃ្លាំងសម្ងាត់ ហើយធ្វើការក្លូនតែម្តងប៉ុណ្ណោះ ហើយបន្ទាប់មកប្រើ fetch ហើយនៅពេលចាំបាច់តែប៉ុណ្ណោះ។
• សមត្ថភាពក្នុងការប្រើគំរូ Go នៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធសំណង់ werf.yaml អនុញ្ញាតឱ្យអ្នកពិពណ៌នាអំពីការជួបប្រជុំគ្នាដែលលទ្ធផលរបស់វាអាស្រ័យលើទិន្នន័យខាងក្រៅ។
• ការប្រើប្រាស់ម៉ោននៅក្នុង werf បង្កើនល្បឿនការប្រមូលផ្តុំវត្ថុបុរាណយ៉ាងខ្លាំង - ដោយសារតែឃ្លាំងសម្ងាត់ដែលជារឿងធម្មតាសម្រាប់បំពង់ទាំងអស់។
• werf ធ្វើឱ្យវាងាយស្រួលក្នុងការកំណត់រចនាសម្ព័ន្ធការសម្អាត ដែលមានសារៈសំខាន់ជាពិសេសនៅពេលសាងសង់ថាមវន្ត។

PS

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

• «កំពុងដំណើរការពាក្យបញ្ជាខណៈពេលកំពុងផ្តល់ការចេញផ្សាយកម្មវិធីថ្មីទៅ Kubernetes»
• «បង្កើត និងប្រើប្រាស់សេវាកម្មខ្នាតតូចដែលមានប្រភេទដូចគ្នាជាមួយ werf និង GitLab CI»
• «ការប្រើប្រាស់ werf ដើម្បីដាក់ចេញតារាង Helm ដ៏ស្មុគស្មាញ»
• «ការណែនាំ werf 1.0 មានស្ថេរភាព៖ តើ GitOps ត្រូវធ្វើយ៉ាងណាជាមួយវា ស្ថានភាព និងផែនការ"។

ប្រភព: www.habr.com